一、前言

• 本文不討論協程、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能有更好的實現方案，或者也可以考慮單向數據流的實現框架。

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

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