這麼多開源框架，該用哪個好？想必這樣的問題，大家都有疑惑過。我想大部分的疑惑無非以下幾點：
-
這個框架穩定嗎？要是有bug怎麼辦？
-
這個框架能滿足我的所有需求嗎？如果用到一半發現不適用該怎麼辦？
-
這個框架耦合度高嗎？是否能按照需求再去定製擴展？
先不看以上幾點，我們先來說什麼樣的框架一定一定不要採納：
-
聚合型框架一定要放棄(比如Afinal，xUtils)，why？越是大而全，越容易牽一髮而動全身，而且在框架世界裏沒有1+1>2這一說。相反的可讀性差，耦合高，難擴展。是Afinal中的圖片緩存好還是fresco，Picasso等好，不言而喻了吧？
-
github上last commit超過一年以上或者issues一大堆沒fix的一定不要使用。這其中會有很多坑，要是出問題了，你都不知道找誰問。相應的，我最怕別人問的問題就是：Stay，你用過xxx框架麼？幫我看看這問題吧。。
-
仿 xxx UI效果大全，請慎重使用，如果可以，多跟產品經理溝通，儘量使用Material Design設計，另外可以參考InstaMaterial。別把大量時間跟精力花在了調UI效果上。UI性能與潛在bug是最不好調試的。大多數人對touch事件，view繪製都是一知半解。
通過上述條件，基本可以pass掉60%的開源項目。技術更新還是很快的，很多以前實現複雜或者根本無解的需求在未來都能有很好的解決方案。當你好幾天都沒找到你想要的解決方案，不妨去做溝通，選用其他替代需求。
如果你的項目在從0到1的初始階段。
不妨先花上一週時間來做調研。這是款什麼樣的產品，做做競品分析，考慮未來可能會有的擴展。根據產品業務來選擇框架纔是最優解。整體項目結構在未來重構的可能性非常小，所以一開始得儘可能得多去考慮擴展，不然會非常痛苦。
另外，你可以放心大膽的去嘗試新出的開源lib，但凡寫框架，都以簡單易用爲最根本目的，隨着技術的推進，新出的框架也會吸收前人的經驗而越來越成熟。而且用戶量還很少，前期還有很長的過渡期，你有充足的時間來驗證這個框架是否好用。
如果你的產品在從1到N的成熟階段。
這個時候每個框架的更換都需要慎重考慮了，在用戶基數大的情況下，任何一個bug都會導致嚴重的後果。儘可能的採用灰度發佈，小規模測試後再統一升級。
比方說，你覺得universal-image-loader不夠好用，經常oom，而且下載顯示速度慢，那你可以選擇fresco，picasso對吧。那麼，如果你以前沒有對圖片緩存框架進行一次再封裝，儘量在你換框架時做一下封裝。即：別在代碼中顯示的調用UniversalImageLoader.display()或fresco.display()，因爲這些代碼被調用的地方太多了，一旦你要換框架，那麼要改的地方就炒雞多。爲了以後再發生這樣的問題，不妨將它們再包一層。以後就輕鬆些。你說對吧。
或者說，IM的消息收發，現在有那麼多平臺的雲推送，如何選擇也是個問題，如果拿不準，那麼在使用之前要儘量去解耦和，別顯式調用任何雲推送API，自己再包裝一層，這樣隨便你怎麼換，都不需要去更改業務邏輯，只用替換雲平臺API就ok了。
至於類似框架之間該如何選擇，其實都差不多，有一些準則，僅供參考：
-
如果框架A依賴另外的jar比較多，謹慎使用，學習也是要成本的。
-
如果框架B沒有詳細的文檔，謹慎使用，理由同上。
-
如果框架C對你目前的App影響較大，改動的地方多，那麼謹慎使用。
-
如果框架D耦合度高，不方便擴展，謹慎使用。
差不多就這些，開源lib太多了，你mark的那些lib，能用上10%就非常不錯了，能熟讀1%的源碼並擴展，也算是個senior developer了。
說了這麼多，好像什麼也沒講，爲什麼會寫這篇文章，是有同學問我該如何選。
如果上述都不能理解，那我就直說該用什麼好了。我項目裏差不多都用自己寫的框架，除了一些UI會找lib，能自己寫的基本自己動手，畢竟架構再完善也很難去滿足一個特定的需求。
以下純推薦，不代表我用過，要是出問題了，別來責問我哈。
網絡層： Retrofit或者Volley＋OkHttp，async-http-lib儘量就別用了，比較老。另外這些都需要再進一步擴展的，可以自己搜下，有用的就集成進去。
數據庫： Ormlite或者Realm，要加密的話用SqlCipher
圖片緩存： Fresco， Picasso，如果集成的效果不理想，多看看配置參數是否正確
工具： 查內存泄漏（leakcanary）異步通知（RxJava謹慎使用）數學計算表達式（expression4j）日期處理（joda time）
至於UI層的lib我就不細說了，自行搜索。
知易行難，遇到問題耐心一些，在寫代碼之前多分析多google，務必把後期的重構花到前期去。