對App應用架構搭建的一些思考
當下隨著App開發技術的越來越成熟，多人協同開發必不可少，一個團隊中每個人的程式碼風格、技術棧都存在差異，因此統一一套成熟的開發架構必不可少，可以提高開發效率、統一程式碼風格、為項目維護提供便利。
當下App源碼工程通常採用組件化結構，將一個工程拆分為公共基礎組件、業務功能庫組件、業務數據組件、業務邏輯組件。
在CommonModel公共基礎組件裡面，依賴一些通用工具，如：圖片載入庫Glide、日誌庫Log、常用工具類utilcodex、簡單的數據存儲mmkv、下拉刷新SmartRefreshLayout、recycleview適配器baseQuickAdapter、路由庫Arouter、lifecycle、ktx、jetpack組件等，需要所有的業務邏輯模組對其進行依賴，提供給各個業務邏輯模組使用，避免各個模組重複依賴，也利於第三方庫的管理。
其它的業務專用功能庫，如影片庫（影片取流、解碼、轉碼等）、支付庫（支付寶、微信等）提供給特定的業務模組，只有相應的業務模組依賴。
業務數據Model是將對應的業務數據介面進行封裝，一般包含網路http(s)介面、websocket、socket、ftp、database等需要與遠程後端或本地數據進行數據方面操作強相關邏輯的封裝。如登錄功能，使用將登錄介面進行封裝，在數據模組定義登錄介面，接受用戶名、密碼等通過網路發送給後端進行驗證，處理返回結果，將結果回調給邏輯模組。
業務邏輯Component是負責與用戶進行交互的上層邏輯，如影片模組包含的預覽、回放介面、對業務數據模組調用獲取數據，展示數據等邏輯，一般情況下各個業務模組相互獨立，不存在依賴關係。
App殼工程，不包含任何業務相關的邏輯，依賴所有業務模組，是整個程式的入口。
以上是對整個工程結構的一些思考，那麼通常情況下，各個業務模組是需要進行通訊的，並非完全不相關的，比如業務A中有個地方需要攜帶一些數據跳轉到業務B介面進行展示，這就涉及到組件間通訊了。
組件間通訊：
業務組件間通訊通常包含介面跳轉、數據交換等，由於沒有依賴關係，不能直接調用。
那麼都有哪些解決辦法呢？
1、 採用第三路由框架
比較出名的是Arouter
2、 自己實現一套框架
