ArcBlock Android App 架構介紹

目前 ArcBlock Android App 採用的是 元件化 + MVP 的基礎架構，下面將分兩個部分分別介紹它們。

Why 元件化？

為什麼要用元件化？放眼整個前端開發，元件化開發的思想已經深入各個框架，前端兩個著名的框架 React，Vue 是最成功的代表。

元件化的核心思想是將複雜的應用拆分為不同的模組，讓每個模組儘量做到“高內聚，低耦合”，從而增加元件的複用性，靈活性，最終幫助我們提高開發效率。

分析自己之前做過的 App 專案，腦海裡可以很快得到一個將 App 元件化的思路：

元件化可以幫助我們更好的設計組織程式碼，這和我們會為了程式碼看起來更清晰，將不同的業務模組程式碼放到不同包名下的目的一樣。只不過，元件化可以幫我們把這一切做到更進一步。

拿最通用的登入註冊元件來說，在開發設計之初就將這個元件單獨開發，然後以依賴的方式給宿主 App 使用，這樣做在程式碼量上其實和之前把所有模組揉合在一塊開發並沒有太多區別，但是無形中它已經幫我們做到了以下兩點：

公司大機率不可能只有一個前端 App，這個時候元件化的優勢就顯現出來了，如果哪天領導說我們需要快速調整產品方向，在原有的 A 產品基礎上快速開發一款 B 產品出來，除了核心業務模組不一樣，登入註冊，個人中心等模組和 A 產品保持一致。

此時可能你會有這樣的疑慮，我花個半天時間 copy 一下之前程式碼修改修改不也一樣嗎？copy 是簡單，可是維護才是最頭疼的，因為採用 copy 的形式，後期你將要維護兩套甚至更多套一模一樣的程式碼，那無疑是個災難。

元件化的實施越早越好，在一個舊的專案上嘗試做元件化方案的精力不亞於重新起一條線去開發一個元件化的版本。所以如果你已經看到了元件化的種種好，那麼最好在專案啟動之初就搭建好完整的可擴充套件的元件化架構。

我們正是這麼做的！下圖是 ArcBlock Android App 整體架構圖：

Why MVP？

為什麼使用 MVP 架構？先看一下 MVP 分別指的是什麼：

MVP = Model + View + Presenter

說到 MVP 就不得不提一下 MVC 的架構，在 MVP 流行之前，MVC 無疑是最火的 Android 技術框架。

Android 早期 MVC 框架的時候，Activity 和 Fragment 這層基本充當兩個角色 View 和 Controller，這麼做好處是定位問題的時候比較方便，基本哪個頁面出了問題，直接去那個頁面找就可以了，不過缺點也很明顯，簡單的頁面還好，如果是業務複雜點的程式碼，整個類的程式碼量會十分龐大，讓後期新進的維護人員無法忍受。

View 和 Model 的各種交叉互調也是一個隱患，給除錯和 Test 都帶來了困擾。

再來看看 MVP 的呼叫關係：

兩個關鍵點：

這樣的模式隔絕了 View 和 Model 互相修改的情況，也就是上面 MVC 中 View 和 Controller 互相呼叫的情況。

Android MVP 架構思想和 React Flux 框架的單向資料流思想有些相似的地方，在 Flux 中，有下面幾個角色：

View 的更新依賴 Store，Store 的更新依賴 Dispatcher 去分發一個 Action，View 不允許直接修改 Store。

Android MVP 的 Presenter 的作用和 Flux 中的 Dispathcer 作用類似，都是為了切斷 View 和 Model（or Store）交叉互動的情況，使資料流的邏輯變簡單清晰。

另外，使用 Android App 採用 MVP 框架之後，單元測試也會變得簡單，核心邏輯都在每個頁面的 Presenter 中，只要將測試中心放在這裡面即可，而 Activity 和 Fragment 負責 View 的渲染， Model 負責資料的互動，分工明確，解構清晰。