許久沒有寫技術博客了，這些時間也一直親近Android，就聊聊技術選型。
技術選型對於一個項目的發展非常重要，個人認爲：
技術決定下限，品味決定上限。
技術好只能保證做出來的App不爛，品味好了才能將有限的技術發揮到極致，將所做App提升一個檔次。
網絡框架
Retrofit + RxJava + OkHttp
這似乎沒啥可說的，已經是主流了，而且非常好用。
- Retrofit充分利用註解的靈活性，以接口的形式配置來實現解耦。與後臺溝通起來也非常方便，直接把api接口複製給他就成。
- RxJava簡直是回不去的一個偉大產物。Java的面向對象很科學，但多線程無窮回調真的要命，很簡單的邏輯常常被弄得很混亂，RxJava很好的解決了這一問題。
- OkHttp的優點我不是太瞭解，我只知道我用它之後沒啥網絡上的疑難，該有的都有，想做的都能做。
這裏有個不錯的Sample，對RxJava操作不太熟悉的同學可以瞭解下：
RxJava2-Android-Samples
熱更新
一年前（2018），我在接熱更新的時候還考慮過美團、阿里家的。現在我告訴你，全都pass，用Tinker。至於爲什麼，稍微關注下就知道哪些項目是騙業績騙star的哪些是真正爲解決問題用心維護的。
Tinker官方Wiki
爲什麼強推Tinker？首先，在我呆過的上家公司與現家，用Tinker發佈過幾十次熱更新，沒出過問題。Tinker基於bsdiff算法生成的差分包非常小，沒涉及到文件資源添加的話，大都在30k以內。補丁包自動合成後會有回調，提示用戶重啓App即可生效。
使用Tinker有幾點需要注意：
- TinkerId非常重要，最好在App內某個地方顯示出來；
- Manifest.xml最好不要去改動，雖然某些改動生成的補丁包可以合成，但不是在所有設備上都能成功；
- Tinker補丁是基於安裝時全量包的TinkerId的，所以多次改動後可能會很大，建議過大時不再維護當前版本，而是發佈一個新的全量包重新開始。（這段話比較拗口啊，慢慢理解）
- 發佈補丁時不要增加versionCode，儘管Tinker沒有限制你，但是不要增加，否則會亂掉。versionCode是在全量發佈apk時增加的。
架構
架構是個比較高大上的話題，因此經常裝逼人士誇口聊。用MVP的同學看不起用MVC的，用MVVM的看不起用MVP的，用LiveModel的看不起用MVVM的。
但是我想說的是：
一味追求鄙視鏈頂端，就好像穿上一雙不合腳的大鞋——徒增負擔。
此外，我個人很不看好MVVM，Google那DataBinding太TM卡了，嚴重影響UI開發效率，而且增加了耦合性。
至於MVP，我覺得不如Fragment好用，同樣是抽離，同樣是拆分代碼，Fragment可以做得更徹底，因爲View可以跟着走。
至於LiveModel沒用過，不做評價。但是有一個東西是真的好用——Lifecycles！這貨專治內存泄露！原理很簡單，就是觀察者模式，監聽頁面的生命週期。牛逼之處在於Google將事件發佈者集成到了Activity與Fragment，所以用起來非常方便。
總之，選架構之前一定要了解：
- 這架構能解決什麼問題？
- 這架構又會帶來哪些問題？
- 擴展性怎樣？
- 會不會影響平均開發時長？
- 對性能有沒有影響？
...
“九層之臺，起於壘土”，多花點時間思考與參照是非常有必要的。
UI適配
其實不在這範疇，但今天在首頁看到一篇蠢文，所以順帶聊聊UI。
layout選擇
我一般只用這幾個佈局：
- LinearLayout：線性佈局，直觀的上下結構或者橫豎結構，用它沒問題。
- FrameLayout：層疊佈局，其實就是設計師眼裏的“圖層”，子控件之間沒啥約束的優先用它。
- ConstraintLayout：彈性佈局，非常牛叉，適合約束比較複雜的頁面。比如複雜的item我常用這個佈局。RelativeLayout能做的它都能做，而且它自帶比例控制。用好了它你才真正知道什麼叫做“減少視圖層級”。
- CoordinatorLayout：我沒叫過它中文名，也找不到好的譯名，但在Android 5.0 Material Design興起時，它是絕對的主角，沉浸式及一個漂亮的頭部動畫都離不開它，用好它的關鍵是理解Behavior。
文字適配
挑一臺最具代表性的大衆設備，以sp爲單位適配好它就好。相同sp在不同設備，其物理大小是不一樣的。比如同樣是默認的14sp，同樣是1080p，小米的會比華爲的小一點，因爲小米的dp/sp會小一點。
注意：
dp並非物理尺寸，屏幕多少dp*dp是由廠商定義的。
Google這樣設計的好處是手機App可以直接適配電視。（想要驗證上方論述很簡單：在xml中畫一個200dp*200dp的黑框，然後用不同設備預覽）。
另外，dp儘量不要用小數（除非值很小，需控制誤差），Google設計dp就是用來適配衆多設備的，而不是絲毫不差用來適配設計稿的（因爲大部分設計稿基於iOS設計）。如果真的是強迫每個設備上顯示物理大小需要一致，那麼直接用inch就行（少部分雞賊廠商是沒有給出準確inch的），也別用什麼dp了（搬倒磚）。
劉海適配
三星之前的全面屏設備算長的了，都是沒有劉海的，比例是18.5:9。
所以，可以得出最簡單的規則：
boolean hasBang = 1f * longSide / shortSide > 18.51f / 9; //記得浮點數
該規則不會漏掉市面上任何一臺劉海屏手機。但是，它會把極少數非劉海屏手機識別爲劉海屏：OPPO、Vivo家的較新旗艦機。如果要進一步精準的話，就把那幾臺特殊的設備型號統計出來，加以判斷即可（其實不是太必要，因爲那麼長的非劉海手機被識別成劉海屏，上方留了點背景關係不大）。
版本選擇
再聊聊各種版本選擇，比如IDE啊，第三方庫啊，Android buildVersion啊。
個人偏好：
- 項目穩定性很重要的話，IDE儘量不要預覽版（讓別人去填坑吧）、各種庫也是。
- 第三方庫之類的升級不要太着急，看看版本變動與issue。
- 新開項目儘量用最新穩定版，不然以後還得適配api。
- 現在是2019年了，Android 5.0已經發布5年了，App最低兼容到api21就行了（主要是5.0相比4.+變得太大了，過多的適配影響開發效率。實在要適配的話也只適配到api19，也就是Android4.4，佔有率還是有一點的）。
- 編譯版本的話，新項目可以上Android X，我已經用了半年了，沒啥問題。
尾巴
慣例，留個尾巴。聊得比較休閒，沒打草稿，更多是一些個人偏好，如有技術上的錯誤，還請指正。