你的業務代碼，是不是都寫在了 Activity 裏？
互聯網分層架構演進有兩條核心原則：
（1）讓上游更高效的獲取與處理數據（複用）；
（2）讓下游能屏蔽數據的獲取細節（封裝）；
數據從數據庫 / 緩存層，到微服務層，到站點應用層，最終都匯聚到客戶端。服務端的分層架構設計已經講了很多，客戶端的分層架構設計應該怎麼玩呢，服務端的分層架構設計是否有能夠借鑑的地方呢，今天和大家簡單聊一聊。
先來看小詩一首：
《Android 猿》
曾經
所有代碼
都被寫在 Activity 裏
幾乎
沒有代碼
可以複用
每當
看到 Activity 裏
2000 行的函數
我就
想要離職
上面，是團隊中一個文藝 Android 程序員的自述，表達的核心觀點是：幾乎所有代碼都寫在了 Activity 裏（不理解 Activity 的，暫且認爲是 MVC 裏的 view 層），完全沒有封裝和複用。
假設一個具體的例子，微信登錄的界面，點擊登錄按鈕，此時可能要執行：
（1）驗證用戶名密碼；
（2）拉取好友列表；
（3）拉取用戶信息；
（4）拉取好友信息；
（5）拉取離線消息；
（6）...
畫外音：那個大月亮的畫面，要卡很久。
如果把這些都寫在微信 “登錄 Activity” 裏，會發現一些很嚴重的問題：
（1）登錄整個邏輯不能複用；
（2）登錄過程中的每個子邏輯也無法複用；
假設產品裏有一個 “離線後重新登錄” 的功能，步驟與登錄相同，就需要把上述在 “重新登錄 Activity” 裏代碼複製一遍。
又假設產品裏有一個地方需要 “拉取用戶信息”，也將把 “登錄 Activity” 裏“拉取用戶信息”的代碼複製一遍。
封裝複用的道理誰都懂，拷貝代碼的壞處也誰都明白，那爲什麼大家還這麼做，代碼越來越 “腐爛” 呢？
根據個人經驗，主要是這麼幾點原因：
（1）早期業務壓力大，APP 是少數幾個同學的，沒有提前做規劃；
（2）後期代碼越來越臃腫，不敢動，一動怕影響功能，怕出問題，怕擔責任；
（3）項目中，是以功能界面進行編碼劃分的，一個同學會同時負責 MVC 三部分編碼，加之項目壓力又大，既然是一個人寫，就沒必要分層了，搞多了調用反而麻煩；
（4）項目中，有個需求好像之前做過，代碼一看，寫在 Activity 裏，糾結。抽象成函數？還得改別人的代碼，算了，還是拷貝一份吧；
（5）…
不管歷史原因，項目原因，個人的原因，大家都知道分層抽象，代碼複用是正確的，那有什麼方案能夠將這個分層抽象落地，從後端的分層架構中是否有可借鑑的地方呢？
一個典型業務系統的後端架構如上：
（1）web-server 層調用 RPC 接口，從 service 層獲取數據，拼裝 html/json，完成數據展現；
（2）biz-service/data-service 向上遊提供可複用的原子接口，實現業務邏輯，並通過 DAO 層，從 db 層獲取數據；
（3）db 層提供數據；
APP 端的分層架構不是非常相似麼？
還是以登錄業務爲例：
（1）登錄 Activity 有兩個按鈕，一個確認按鈕，一個取消按鈕，這兩個按鈕的點擊，分別只能調用一個函數：
- on_LoginConfirm_Click
- on_LoginCancel_Click
這裏相當於展現層，除了交互與展現，View 層只能調用這兩個函數。
（2）這兩個函數的實現，是通過若干可複用的 “原子業務邏輯” 函數實現的：
- 驗證用戶名密碼：bool verifyPass(name, pass)
- 拉取好友列表：ListgetFriendList(uid)
- 拉取用戶信息：Use rgetUserInfo(uid)
- 拉取好友信息：ListgetUserInfo(List<f_uid>)
- 拉取離線消息：ListgetOfflineMst(uid)
這相當於服務層，實現業務邏輯，提供封裝和複用
（3）“原子業務邏輯” 函數執行的過程中，需要訪問數據，數據的獲取又分爲兩類：
- 同步獲取：通過文件，內存，本地數據庫獲取
- 異步獲取：從 server 獲取，往往通過回調實現
這裏相當於數據層，向上遊屏蔽數據獲取的複雜性，分別用不同的 Proxy 去實現。
在這種結構下：
（1）展現層非常輕，只調用一個函數，用於展現數據；
（2）“原子業務邏輯” 可以複用，不同的展現層 Activity 可以隨意組合，實現不同的業務邏輯，用於處理數據；
（3）Proxy 對上游屏蔽的數據獲取的複雜性，向上遊提供數據獲取接口，用於獲取數據；
分層架構封裝複用的思想，前後端有共通的地方。
Activity 裏一坨坨複雜的代碼，也是你曾經的痛麼？
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/NNSkiDOiKGiiRFXfcbq2iA