歡迎光臨
每天分享高質量文章

Android 技術選型閑聊

作者:DreamWinter

鏈接:https://www.jianshu.com/p/25cf7ce0d8d0

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

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

技術好只能保證做出來的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,我已經用了半年了,沒啥問題。

已同步到看一看
赞(0)

分享創造快樂