一、前言

• 本文不討論協程、Retrofit、MVVM的原理以及基本使用，需要的可以在其他博主那兒找到很好的文章。
• 本文沒有選擇DataBinding的雙向綁定方式，因為個人覺得DataBinding汙染了xml,並且在定位錯誤問題上比較麻煩。
• 也沒有采用Flux、Redux、ReKotlin這樣的框架，因為目前還不太熟。
• 可以把本文看作是一篇實現過程紀要，歡迎交流分享，提出建議。

二、過程與思考

基本依賴

• 生命週期組件相關

implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0-beta01'
implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0-beta01"

• 協程

implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.0"

• 網絡

implementation 'com.squareup.retrofit2:retrofit:2.6.0'
implementation 'com.squareup.retrofit2:converter-gson:2.6.0'
implementation 'com.squareup.okhttp3:logging-interceptor:3.11.0'

備註:Retrofit 在2.6以後對協程有了更友好的實現方式，所以在版本選擇上是有要求的。

動手之前

因為接入協程的緣故，像以前以回調onResponse，onFailure的回調方式是不太符合協程設計的。Kotlin協程對於Retrofit的onFailure處理是直接以Trowable進行拋出的，所以在一開始就要構建好對執行Retrofit的掛機代碼塊的try..catch設計。

基本的網絡訪問封裝

基本操作還是要有的

定義基本的Api返回類

定義一個Api以便於測試

封裝BaseViewModel

網絡請求必須在子線程中進行，這是Android開發常理,使用協程進行網絡請求在代碼上可以讓異步代碼看起來是同步執行，這很大得提高了代碼得可讀性，不過理解掛起的確需要時間。BaseViewModel中最終得事情就是要搭建關於協程對於Retrofit網絡請求代碼塊得try..catch。

• 重要得try..catch

將捕獲到得異常進行下放保證執行過程中得情況都是可控得。

• main線程

• IO線程

• 不要忘記onCleared

錯誤處理

錯誤處理分為1.請求異常(及trycatch中的異常),2.服務器返回的響應體中定義的異常,這些異常只要是帶有網絡訪問性質的APP上都是常見的，所以對NetWork的異常處理我定義了一個NetWorkError.kt文件，裡面的函數為

try catch異常處理

像一般觸發的鏈接超時、解析異常都可以做出處理，如果不try catch，那麼APP有可能會崩潰，或者長時間沒有任何回執，體驗很差。

服務器定義的響應異常

一般服務器對於請求都存在響應碼，客戶端根據響應碼去做響應的處理，不同的錯誤碼會有不同的日誌回饋或者提示，但這都是建立在請求成功上的。這裡一般無非為成功和失敗。

• Http請求響應封裝

• 錯誤枚舉

• 錯誤處理

• 對HttpResponse進行處理

這裡是直接對HttpRespoonse進行處理，還需要對當前的響應內容有一個轉換

• 轉換服務器響應

暫時定義為一個擴展函數,方便結合this使用。基本封裝完成以後，開始搞一個測試類來進行測試。

測試

• client

• model

• viewModel

• 最後在LoginAct對loginState實現監聽

三、總結

這是目前自己能夠想到的一些方式，個人覺得Kotlin的確帶來很大的改觀，特別是在可讀性和維護性上。雖然在架構和整體設計這件事情上，本來就沒有標準的方式，這些問題都是相對的。

對於DataBinding的雙向綁定方式期待後期Google能有更好的實現方案，或者也可以考慮單向數據流的實現框架。

今年年初我花一個月的時間收錄整理了一套知識體系，如果有想法深入的系統化的去學習的，可以私信我【安卓】，我會把我收錄整理的資料都送給大家，幫助大家更快的進階。

重要的事說三遍，轉發+轉發+轉發，讓更多需要的朋友們都可以看到並且領到！