随着業務的發展 app 開發技術也越來越成熟，對開發者來說 app 代碼量也迅速地增長到一個數量級。對于如何架構 app 已經每個開發者面臨的實際問題。好的架構可以提高開發者的效率，降低維護成本。
由于業務增長引起項目中代碼量激增，以及曆史遺留問題和結構混亂，作為一個有代碼潔癖的程式員，很早就開始思考如何組織 app 架構的問題了。目前遇到的主要有以下幾點問題：
代碼量激增引起結構混亂
各個子產品互相引用且耦合度高
無法獨立開發或者調試元件代碼
無法應對元件插拔的需求（例如：産品經理今天把這個功能加上，第二天又去掉，第三天又加回來t_t）
在閱讀了大量的文檔之後，根據實際項目開發遇到的問題，我總結了以下架構。由于水準有限，有不合理的歡迎拍磚
自下而上将 app 分為：
核心層
業務層
應用層
核心層是包含了為 app 提供公共服務的的一些庫。例如：公共資源、網絡庫、日志工具、資料庫、圖檔加載等核心庫。這些是整個 app 基礎庫。
我認為這一層是整個 app 架構的關鍵。因為根據實際業務需求，這一層會分離出許多獨立元件（其實就是對應于 android studio 的 module），但這些元件可以獨立運作，相當于一個小應用（元件如何獨立運作将在應用層中會詳細解析）。并且這些元件不再像傳統的方式進行互相引用，而是采用了元件路由進行各個元件的通信。
比如元件 a 中需要跳轉到元件 b 中的一個 activity 頁面，傳統的做法是在 moduleaactivity 中
這樣 module a 與 module b 耦合度就很強
比較好的做法應該是
當然實作上面的路由原理也有很多方式，例如可以使用 android 系統的隐式調用實作跳轉通信。
在 manifest 檔案中
實際調用
router 層目前有一個比較好的開源架構可以參考，來自 alibaba 的開源項目：arouter
業務層要實作比較好元件分離，對程式猿現在編碼思維要轉換一下，要切換到 sdk 思維。
那什麼是 sdk 思維呢？
想想項目中引用他人編寫的庫的接口使用方式，就不難了解了。即站在使用者的角度上思考：如何使用接口才是最友善的？例如公司現有好幾個 app 産品，每個 app 都需要使用同樣的授權登入。那麼這個授權登入子產品就可以獨立成一個元件。
假設将授權登入元件命名為auth。那麼其它元件在使用的時候可能類似以下代碼片段
是以，作者覺得接口設計或者提供應該是利他主義的。當然這純粹是作者的一家之言，歡迎繼續拍磚。
顧名思義，這一層是對整個 app 的整合，也是 app 的入口。這裡有 main 和 dev。其中 main 是對各個業務元件的整合，是最終打包的産品的上層應用。而元件入口是獨立運作和調試各個元件的子應用。
dev 在 android studio 中是對應一個 application 。在 gradle 中配置為
它是一個可以獨立運作的子工程，要調試 module a 那麼在 dev 中将引用該元件
這就是一個大概的思路，可以看出這個架構關鍵的部分是在于業務層的分離。需要把原來項目中的基礎子產品抽取出來，放在核心層中。那麼下一步就開始建構我們的核心層元件。
作者：angrycode
來源：51cto