在 2016 年學 Android 是一種什麼樣的體驗?

ace1985發表於2016-10-23

@author ASCE1885的 Github 簡書 微博 CSDN 知乎
本文由於潛在的商業目的,不開放全文轉載許可,謝謝!

white_beard.png-475.8kB

廣而告之時間:我的新書《Android 高階進階》(https://item.jd.com/10821975932.html在京東開始預售了,歡迎訂購!

TB2MnqlXH1J.eBjSszcXXbFzVXa_!!1020536390.png-39kB

轉眼間 2016 年的電量已不足 20%,不禁感慨 How Time Flies!不知不覺 Android 移動開發已經走過了八年的光陰,在這八年的時間中,Android 開發從最初的簡單呼叫系統 API,到各類框架的不斷湧現,再到如今的成熟階段,那麼作為一個想在 2016 年開始學習 Android 或者重新開始學習 Android 的開發者來說,你將看到一幅什麼樣的光景呢?

首先你會發現最新的 Android 系統版本已經是 7.0,作為大版本肯定存在很多變化和改進,開發者需要持續跟進這些變化,例如 Android 7.0 刪除了三個隱式廣播,優化記憶體使用和優化電量消耗。再往前一個版本,Android 6.0 重新設計了許可權系統,一系列的許可權不再簡單的在 AndroidManifest.xml 檔案中宣告就可以使用,而是要動態申請。再往前一個版本,Android 5.0 引入了 Material Design,從此 Android 有了自己特有的設計語言和規範。

image_1avj9nk461qdajmb17c315fm9bm29.png-172.7kB

從整合開發環境和構建工具上面看,一兩年前還在苟延殘喘的 eclipse+ant 基本絕跡了,取而代之的是流行的 Android Studio +Gradle,截至本文發稿前,Android Studio 剛剛釋出了 2.2.2 版本,對應的 Gradle 版本為 2.14.1 版本。談到 Android 的構建,除了 Gradle,你也可以嘗試 Facebook 的 Buck,雖然它的配置侵入性很強,但構建速度是比 Gradle 快很多的,當然,如果使用最新的 Android Studio+Gradle,我們可以開啟 Instant Run 模式,從而達到快速的重新構建。

image_1avj8ih4oe1m1rjgqg41pqg19vn1f.png-184.5kB

著名的 Support Library 已經更新到 25.0.0,其中 support-v4 庫從 24.2.0 版本開始就拆分成 5 個子庫,開發者可以更靈活的引用它。

image_1avj91p8i19betnn1ld42t01uc61s.png-88kB

什麼?你還在使用 ListView,GridView?是時候使用 RecyclerView 進行替換了,同時別忘了使用 Support Library 24.2.0 開始引入的 DiffUtil 來高效更新 RecyclerView。

從搭建應用的UI架構開始,我們不再考慮 MVC 模式,取而代之以 MVP 或者 MVVM 模式,Android 官方雖然對於 MVP 模式沒有統一的標準,但還是提供了一系列使用例子 供開發者作為實現參考。

image_1avj8ceqa6uc1ffr14fc1dgp10qg12.png-83.5kB

至於 MVVM 模式,Android 官方提供了一個名為 DataBinding 函式庫作為標準實現,相信後面會越來越多開發者在專案中引入。

如果你已經厭倦了使用 Java 來編寫 Android 應用,沒有關係,你可以嘗試下 Kotlin,它可以比作 Android 世界的 Swift,目前已經發布了 1.0.4 版本,支援多種現代的程式設計特性,例如函數語言程式設計。同時 100% 支援和 Java 的混合程式設計,具有 Java 程式設計基礎的開發者很容易上手。

image_1avjccovrbrspjak8a1ajpr299.png-250kB

如果你也不喜歡 Kotlin,但熟悉 Javascript 語言,那麼推薦你試用下今年非常火爆的 React Native,它不僅可以使用 Javascript 語言編寫 Android 應用,而且可以編寫 iOS 應用,而且程式碼複用高達 80% 左右,同時,新功能的上線不再需要往應用市場提交新的 APK 包,而是支援線上熱更新。當然,React Native 寫出來的介面是 Native 的體驗,不是 H5 的體驗。

image_1avjddbak1obhc9nrd76tq1p0mm.png-46.2kB

提起 React Native,我們不得不提到它的競爭者 Weex,Weex 的基本原理和 React Native 一致,也是使用 Javascript 語言編寫 Android 和 iOS 應用,不同的是,React Native 是基於 React 框架,Weex 是基於 Vue 框架。當然,目前看來,React Native 的勢頭是蓋過 Weex 的。

image_1avji66pflkivkj1sr8rvg1v0m9.png-258.8kB

前面我們提到過 Kotlin 支援函數語言程式設計,我的意思當然不是說使用 Java 語言就不能支援函式式的開發,但是就目前 Android 支援的 Java 版本,要支援函數語言程式設計我們需要引入一個知名的函式庫 RxJava,這是一個函式響應式程式設計框架,採用觀察者設計模式,最直觀的,它能讓你的程式碼避免回撥地獄的出現,使得程式碼資料流向非常清晰,在 Android 中使用 RxJava,還需要引入 RxAndroid 作為橋接,當然,還存在 RxBus,RxBinding 等等擴充套件函式庫。

說起這兩年 Android 開發的變化,你會發現熱修復框架的如春筍般湧現,你之前可能知道 Dexposed,AndFix,Nuwa 等,但最近幾個月出現的新美大 Robust,微信的 Tinker,手機 QQ 的 QFix 等方案你是否瞭解和對比過?

我們知道熱修復是用來線上修復嚴重性的 bug,那麼 Android Native 程式碼如何實現功能模組的線上更新呢?這就需要涉及外掛化框架的概念了。Android 平臺的外掛化框架也是存在多種方案,各有優劣。常見的攜程的 DynamicAPK,360 的 DroidPlugin,iReader 的 ZeusPlugin 以及 Small 等。另外,外掛化也是解決 64K 問題的一大利器。

另外一個和熱修復容易混淆的概念是應用的增量更新,增量更新的意思是應用在自動更新時下載的 APK 不是全量的,而是一個差分包,下載完成合並後再進行安裝,可以看到,熱修復和增量更新最大的區別是應用更新後是否需要重新安裝。

上面說到的熱修復,外掛化更新,增量更新,都依賴於應用啟動後去服務端下載對應的更新包,那麼如果應用啟動時去讀取本地快取或者資料庫等資料,由於檔案損壞或者資料格式不正確,可能會導致應用啟動必然閃退,因此,我們還需要引入啟動保護機制來清除快取資料從而保證應用可以正常啟動。

對了,應用底層基礎函式庫也發生了很大變化,網路通訊庫 android-async-http 已不再是流行,OkHttp+Retrofit 是主流的選擇,圖片載入和快取框架 Android-Universal-Image-Loader 也已經落伍了,Glide,Fresco 等是更優的選擇。其他流行的底層函式庫還有依賴注入框架 Dagger2,事件匯流排框架 EventBus,資料庫 ORM 框架 greenDAO,就連日誌記錄函式庫也湧現了不少,其中以 Timber,Hugo,logger 最有代表性。

2017 年還將會有哪些新技術或者新的變化出現呢?讓我們拭目以待吧!

歡迎關注我的微信公眾號 ASCE1885,專注與原創或者分享 Android,iOS,ReactNative,Web 前端移動開發領域高質量文章,主要包括業界最新動態,前沿技術趨勢,開源函式庫與工具等。

相關文章