[TOC] # 工業化（組件化&解耦下沉） ## 背景 原結構是一個龐大的主工程。 * 沖突多 * 模塊耦合驗證 * 編譯速度慢 * 提高迭代速度 ## 整體框架設計 1. QRoute框架層：整個模塊化的核心基礎，主要包括模塊管理、服務管理、統一路由、日志監控 2. 組件層：客戶端應用基礎組件，包括系統資源、網絡、存儲、多媒體，以及第三方開源庫等。 3. 基礎組件層：手Q抽象出的核心服務組件，與組件層的差異主要在于聚焦于某個場景的核心能力，頭像、動畫一般同時涉及前后臺。 4. 基礎Business層：大部分模塊為業務容器，比如主界面、AIO、資料卡、WebView等，他們以框架的形式提供能力，供業務進行定制邏輯開發。 5. 動態模塊層：具有動態化能力的業務模塊，可以由業務模塊改造而成。 6. 殼工程層：未來業務可以新建殼工程，實現垂直業務獨立編譯、運行、調試。 原則上，框架層、組件層、服務層都可以作為通用能力來實現，與具體業務不直接相關。 ## 改造重點： 1. （解構下沉）基礎組件 2. （雙向解構下沉）基礎Business層 3. （單向解構下沉）動態模塊層 ## 路由框架選型（不同場景使用不同） 強調可溯源，降低改造成本、輕量級 ### QAPI * 解決別人用我 * 約束命名規則，綁定接口和實現 * 適用于業務模塊對對外保留api ### 依賴注入 * 解決我用別人 * 模塊提供業務員需要實現的接口 * 業務實現接口 ### 頁面路由方案 QRoute VS ARoute ARoute強大，可配置強 QRoute用法與原生保持一致，改造成本小 ## 改造過程中的問題 ### 解構的順序 優先選擇對外依賴少的，被依賴多的模塊 ### 提供臨時api的方式 依賴的項目未解偶，影響本模塊的解構進度 提供臨時api，實現還在主干工程 ### 雙分支開發 ### Gradle文件的統一配置依賴管理 ### 被依賴module中BuildConfig.DEBUG的值總為false ## 長效監控 * 合入流水線檢查： * 監測起code.yml機制，保證模塊負責人的及時更新 * 檢查build.gralde是否合理（新引入庫和新引入依賴/model進入人工監測模塊） * 不過基礎模塊不允許新增代碼，只允許注入進來 * 主工程新增代碼需要檢查