[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进入人工监测模块） * 不过基础模块不允许新增代码，只允许注入进来 * 主工程新增代码需要检查