對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、 自己實現一套