Android 技術選型閑聊

技術選型對於一個專案的發展非常重要，個人認為：

技術決定下限，品味決定上限。

技術好只能保證做出來的App不爛，品味好了才能將有限的技術發揮到極致，將所做App提升一個檔次。

網路框架

Retrofit + RxJava + OkHttp
這似乎沒啥可說的，已經是主流了，而且非常好用。

• Retrofit充分利用註解的靈活性，以介面的形式配置來實現解耦。與後臺溝通起來也非常方便，直接把api介面複製給他就成。

• RxJava簡直是回不去的一個偉大產物。Java的面向物件很科學，但多執行緒無窮回呼真的要命，很簡單的邏輯常常被弄得很混亂，RxJava很好的解決了這一問題。

• OkHttp的優點我不是太瞭解，我只知道我用它之後沒啥網路上的疑難，該有的都有，想做的都能做。

這裡有個不錯的Sample，對RxJava操作不太熟悉的同學可以瞭解下：
https%3A%2F%2Fgithub.com%2Famitshekhariitbhu%2FRxJava2-Android-Samples

熱更新

一年前（2018），我在接熱更新的時候還考慮過美團、阿裡家的。現在我告訴你，全都pass，用Tinker。至於為什麼，稍微關註下就知道哪些專案是騙業績騙star的哪些是真正為解決問題用心維護的。

Tinker官方Wiki https://github.com/Tencent/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，我已經用了半年了，沒啥問題。