前言在平時的開發過程中，難免會遇到這樣那樣的難題，或者一些繁瑣且不想純手工完成的功能，對於這些問題，解決的姿勢有很多種，可以通過同事間的交流、上網查資料、去官網找文檔等，隨著開源的推動和完善，尋找合適的開源項目支持，絕對是一個很好的方法。
　　
　　如今市面上的開源項目魚龍混雜，並且有一些項目早已停止更新維護，跑demo的時候，怎麽用怎麽正確，一放入項目，卻發現哪哪都不合適，比如低版本下才可以運行，高版本刪去一些方法，再或者與一些新技術的包沖突等，在眾多開源項目中，我們應該以何種姿勢去選擇最佳方案？且聽我慢慢道來。
　　
　　PS：目前我主要是做手機客戶端開發，以下的例子會舉一些日常開發的例子。
　　
　　這裏寫圖片描述正確理解、確定需求“我喜歡蘋果，可是你給了我一車香蕉，然後你說你被自己感動了，問我為什麽不感動。我無言以對，然後你告訴全世界，你花光了所有的錢給我買了一車香蕉，可是我卻沒有一點點感動，我一定是一個鐵石心腸的人！我的人品確定是有問題的！我只是喜歡蘋果而已啊”。
　　
　　對於這樣的問題，在我們的開發過程中也經常遇到，產品經理只是想要一個蘋果，而我們卻給他送來了一大包香蕉，後來發現哪哪不合適，又去和產品經理確定需求，才發現自己想的是錯的，相信這樣的例子，在每個人身邊都有過，因為沒有及時溝通，造成後期維護成本大大提高，如果發現的早還好，在面臨上線出現這樣的問題，這一定是晴天大霹靂。
　　
　　正確理解、確定需求，對開發中選取第三方開源或者原生都是有很大幫助，可以大大降低後期維護成本。
　　
　　前段時間公司要接入攝像頭來完成視頻直播功能，采用m3u8格式實現，後期也不會有其它格式接入，從開發者文檔中看到，Android原生控件僅支持MP4格式，對於其它格式的兼容，還存在很大問題，也就是說沒法完美兼容m3u8。此時，我們僅需要找到m3u8格式支持的方案就好，在搜索的征途中，我們大大地縮小的範圍。
　　
　　兼容性做客戶端開發，對於兼容性的話題，總是有千言萬語，從最初寫布局到後來的集成，再到後來系統的升級，無時無刻不在與兼容性打交道，尤其是在swift剛誕生的那一兩年，每個大版本都會大改api，這就有點扯淡了，搞的開發者心力交瘁，企業也不敢輕易嘗試使用。
　　
　　對於布局的適配的兼容性，今天不做討論，接著上面視頻對接的話題繼續擼下去，經過一番對比，我把目標鎖定在了Google的ExoPlayer和bilibili的ijkplayer，這兩個都是開源項目，都可以在github找到源碼，地址如下，點擊可跳轉：的github地址：的github地址：我最初的選擇方案更是傾向於ijkplayer，對國內開源項目本來就有一種特別的情感，國貨當自強，和朋友討論的時候，幾個朋友也是推薦我ijkplayer，這其中也有B站的哥們，但他沒參與到這個開源項目中，在最初跑demo的時候，確實可以完美播放m3u8 www.rbuluoyl.cn/，當我把他放到我們項目中去的時候，發現報錯了，再次檢查下導入的包，如下：}發現導入的包沒問題，打開源碼看了下，是包的內部有沖突了，如下：}最低支持21的版本，和項目有沖突，解決方案有三種，不導入64位的包，或者自己修改源碼後重新編譯，最後一種不現實，就是改公司項目的最低版本，我們目前還是有一部分Android 4.3的用戶。
　　
　　一定會有更好的方案，嗯，一定會有的，抱著試試看的態度，無意間發現了ExoPlayer。
　　
　　通過一番查閱資料，在ExoPlayer的開發者文檔中可看到最低支持的版本是Android 4.1，公司目前項目，最低支持是Android 4.2，挺符合我們的口味。
　　
　　總結：兼容性一直是一個很繁瑣的問題，版本更新太快，技術不斷更新換代，一些不安全或者沒必要的方法，不斷的從API中刪去，接著迎來了一些新加入的API，合理的考察和調研，可以省去很多彎路。
　　
　　這裏寫圖片描述健全性對於健全性，主要體現在文檔的健全性和資料的健全性，如果是一個全新的技術，官方沒有提供健全的API，市面上還沒有一些集成文檔，這類的開源項目，最好別介入到項目中，作為第一個嘗試吃蜘蛛的人，可以吃到的是一嘴的苦水。
　　
　　最初我在測試ijkplayer的時候，首先，簡單瀏覽了下內容，知道了個大概采用什麽技術，接著就去找文檔，天哪，我只看到了集成時候需要導入的包和編譯采用的環境、工具，還有，就是我只找到了simple。這就尷尬了，這麽大而優秀的項目，居然沒有官方文檔，瞬間好感下降到了負一層，去網上搜了下資料，資料還是很健全的，有很多優秀的開發者在集成後，把一些必要的註釋就加上去了，看起來一目了然。
　　
　　後來在調研Google的ExoPlayer的時候，發現有了質的差距，如下：源碼地址：地址：開發者指南：這真的太棒了，集成的時候，可以解決少走很多彎路，遇到問題，也有了一些解決方案，擴展的時候，也為自己增加了幾分信心。
　　
　　想起了中學時候學校的一句標語：“細節決定成敗，態度決定高度”。在平時使用或者學習第三方開源項目的時候，實現功能並不是第一要素，更應該關註API和資料的健全性，這點，我一直很欣賞Google和square，Google先不提，在學習square的www.hnktv.cn retrofit的時候，API還是給了我很大的幫助，裏面寫的確實挺詳細，一目了然，每個註解都有詳細的說明，讓學習者感到更加親切。
　　
　　實現原理對於實現原理，一些初、中級開發者並不關註這個話題，總覺得自己看不懂源碼，看不懂那些所謂的高深技術，這個就是一個錯誤的態度，源碼看不懂也很正常，諸如ijkplayer通過封裝、修改和擴展FFmpeg去實現，FFmpeg，這個確實比較高深，雖然學過一段時間C語言，搞過一段時間FFmpeg，但對於內部一些代碼，看的同樣很吃力，但文檔總可以看得懂的，再或者網上那麽多資料，總可以了解個大概，至少可以知道ijkplayer支持的格式、采用的技術、解碼的方式、需要的包…之前一個前輩給我的忠告，如果一項技術，一個團隊沒人很熟悉，沒人閱讀和了解過源碼，最好不要使用，一旦使用了，以後很可能會帶來一大堆繁瑣的問題。
　　
　　確實是這樣子的，就像三年多前在一家外包公司的時候，那時候市面上還沒有太多關於即時聊天的文檔，當時的第三方也沒那麽多選擇，公司決定使用xmpp + openfire去實現，而那時候我們團隊沒人接觸過這一塊內容，項目在爬行中推動，一個加好友的功能，把一個同事搞了好幾天（這不否認那位同事的能力和粗心，因為英語的問題，沒去看官方文檔，同時也沒過多的做調研）。
　　
　　我很欣賞曹操，很欣賞他的疑人不用，用人不疑。如果曹操是一個程序員，一定是一位很優秀的代碼家，以曹操的性格，一定會把一門技術吃透，然後再學以致用，舉一反三，盡可能把一門技術發揮到極致。
　　
　　性能不管采用什麽樣的開源項目，性能絕對是一個很重要的參考，就算這個項目寫得再好，功能齊全，一旦性能有問題，這將是致命一擊，就像一個失去雙手的運動員，長、短跑都是第一，此時讓他去參加乒乓球比賽，再牛逼的教練也是一臉懵逼。
　　
　　回到剛才的話題，再ExoPlayer和ijkplayer中的選擇，一大部分原因是因為性能方面的問題，性能問題，直接把矛頭指向了硬解碼和軟解碼的區別。
　　
　　硬解碼：就是調用GPU的專門模塊進行解碼，由顯卡核心GPU來對視頻進行解碼工作。
　　
　　軟解碼：通過軟件讓CPU來對視頻進行解碼處理。
　　
　　相信對於軟解碼和硬解碼，大部分人都不陌生，這裏不做多與贅述。
　　
　　一圖勝千言，做了一下對比：對比上面對比中一個是功耗一個是總功耗，這個也很容易理解，GPU的電路更復雜，並行運算能力要遠遠高於CPU，於是耗電量就更高，GPU功耗大，但運行速度提升更多，功耗 = 功率 * 時間，所以就算功率乘個4，但是時間除以個10，總耗能還是降低。
　　
　　對於硬解碼和軟解碼的選擇，這個真心說不上哪個更好，根據項目的需要，現在幾乎所有的設備都支持硬解碼和軟解碼，僅支持一種的Android移動設備已經屬於古董級的，我是沒見到過，之前更多的人願意選擇軟解碼，更大的原因是因為硬件解碼支持的格式較少，而軟解碼對於格式是不受限制的。
　　
　　現在隨著硬件的不斷提高，解碼技術的不斷成熟和完善，我是更傾向硬解碼，但硬件提升的同時，CPU也在不斷的優化和提高，現在也不需要像之前那樣盡可能節省CPU，現在處於性能過剩的時代，CPU已經很難處於負荷狀態，選擇軟解碼或者硬解碼都是沒有誰對誰錯，剛剛圖上已經貼出和標記兩者的優點，根據項目需要選擇。
　　
　　當時選擇硬解碼的ExoPlayer，是因為只需要播放m3u8格式的視頻，畫面上沒有那麽高的追求，對於這樣的需求，硬解碼更符合公司的口味和用戶的體驗，至少可以節省更多的電量。
　　
　　功能與擴展對於產品經常改需求，這是常有的事，我們更多的時間不應該是放在和產品經理撕逼，而是如何更好的應對這個問題。
　　
　　剛學軟件開發的時候，書上就提到，好的程序員，會更好的考慮代碼的可維護性、可重用性、可擴展性和靈活性。
　　
　　再接入一個第三方之前，熟悉它的功能是在所難免的事，就是因為某個和某幾個功能吸引才導致我們采用這個第三方，為了方便以後擴展，還是應該多讀幾遍開發者文檔，盡可能多的了解和熟悉內部結構，在開發者文檔，一般都會有詳細的說明。
　　
　　對於擴展性，這個就離不開文檔和源碼了，總不能自己莫名其妙的寫代碼，這不現實，我覺得每個合格的程序員都應該養成閱讀源碼的好習慣，這對自身的提高和功能的擴展都有很大的幫助。
　　
　　集成性對於集成性，我第一反應就是想到了微信和支付寶支付，這簡直就是天壤之別，兩年前的時候，我和一個同事分別接入支付寶和微信支付，我接入支付寶，加上閱讀文檔和跑www.yunduanpingtai.cn demo，不到一個小時就跑通了，而他接入微信支付的時候，接了一天還沒搞定，然後和我說微信支付的各種坑，當時也是半信半疑，就算坑了點，也不至於需要一天多吧，就這麽點內容。後來有一次接了個私活，也是需要接入支付寶和微信支付，支付寶的文檔很全很詳細，微信的文檔亂七八糟，更惡心的是回調的類還必須是一個固定包下面的固定類名，嚴重破壞了項目的包結構，深深的鄙視。
　　
　　對於開放的SDKwww.t1yule.com ，我覺得應該給接入者提供更加全面的文檔，站在別的位置考慮下問題。
　　
　　這裏寫圖片描述總結如何更加安全、高效地利用第三方開源項目，為了提高以後代碼的可維護性和可擴展性，我們應該更多的去調研和閱讀開發者文檔，磨刀不誤砍柴工，一個好的開發者，應該把更多的時間放在思考和調研，而不是速度完成需求，然後把更多的時間放在改bug。

如何更加安全、高效地選擇開源項目（內附詳解）