{"id":18007588,"url":"https://github.com/tianshaojie/android-modularization","last_synced_at":"2026-01-18T08:02:54.283Z","repository":{"id":67952902,"uuid":"130657210","full_name":"tianshaojie/android-modularization","owner":"tianshaojie","description":"Android组件化设计思路","archived":false,"fork":false,"pushed_at":"2018-04-23T07:34:53.000Z","size":8,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-04-04T11:47:24.007Z","etag":null,"topics":["android-architecture","android-modules"],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tianshaojie.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-04-23T07:30:23.000Z","updated_at":"2023-03-14T07:37:30.000Z","dependencies_parsed_at":null,"dependency_job_id":"657f56ac-0bf7-4d97-932c-f6e5eb9a19e3","html_url":"https://github.com/tianshaojie/android-modularization","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/tianshaojie/android-modularization","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tianshaojie%2Fandroid-modularization","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tianshaojie%2Fandroid-modularization/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tianshaojie%2Fandroid-modularization/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tianshaojie%2Fandroid-modularization/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tianshaojie","download_url":"https://codeload.github.com/tianshaojie/android-modularization/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tianshaojie%2Fandroid-modularization/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28533758,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-18T00:39:45.795Z","status":"online","status_checked_at":"2026-01-18T02:00:07.578Z","response_time":98,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["android-architecture","android-modules"],"created_at":"2024-10-30T01:13:51.668Z","updated_at":"2026-01-18T08:02:54.263Z","avatar_url":"https://github.com/tianshaojie.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Android组件化设计思路\n\n## 1. 引言\n\n思考一个问题：代码在一个工程，100%代码编译；打包时间长；业务交叉、耦合严重、代码零乱影响开发心情；非本次迭代业务代码被修改上线；如何解决？\n\n如果我们能把100%的代码中，70%的代码稳定下来，只有30%的业务代码经常改动，是否就可以降低维护成本，提高开发效率和稳定性；\n\n70%的代码中，形成各个独立的功能模块或组件沉淀稳定下来，就可极大的减小对整体代码开发和修改频率；\n\n30%的代码中，负责主要业务代码开发和产品发布，再划分为不同业务小组维护，提高了开发效率，也降低了维护成本；\n\n所有，我们可以形成一个开发思路：**稳定(大)中台(70%)，灵活(小)前台(30%)**；\n\n组件化的一个目标就是为业务代码开发减负，提高稳定性，没有修改就没有伤害，在大小团队都适用。\n\n\n## 2. 目标\n* APP\n\t* 持续集成，提高App稳定性；\n\t* 降低代码耦合度，提高编译速度和开发效率；\n\t* 快速响应，快速迭代发版和热修复，降低代码出错风险，减小开发和测试成本；\n* 组件\n\t* 独立编译和发布，组件回滚有迹可循，便于持续集成；\n\t* 高内聚低耦合，提高组件复用性；\n* 团队小组和开发人员职责明确；\n\n## 3. 问题\n1. 组件划分原则和粒度？\n\t* 组件代码分布思考；\n\t* 组件代码修改频率和稳定性思考；\n\t* 组件化改造后**开发效率的平衡**；\n\t* 对现存代码大工程的拆分思路；\n2. 组件间通信方式？\n\t* Router 维护方式；\n\t* Event；\n3. 组件的管理方式？\n\t* 远程or本地？\n4. 代码重构和文件查找？\n\n\n## 4.  组件划分原则\n**大原则：去中心化，平级组件无依赖；业务组件粗粒度；功能组件细粒度；基础组件高稳定性；**\n\n### 组件化工程结构\n```\napp  -  壳工程\napp-support  -  App支持组件\n↑\nmodule-x (A、B、C)  -  业务组件\n↑\nlibrary-x (a，b，c，d，e，f)  -  功能组件\n↑\nlibrary  -  基础组件\n```\n\n### 4.1 App壳工程\n* 命名规则：`app`\n* 目标：壳工程，负责打包；**去掉任何一个业务组件，不影响编译打包运行**；\n* 依赖关系：只依赖业务组件；\n\n### 4.2 业务组件划分规则\n* 命名规则：`module-` + `后缀名`\n* 划分规则：根据公司或部门实际业务划分，**粗粒度**，边界清晰，便于团队管理，便于组件划分，业务组件不要太多；\n* 修改频率：**高**；业务组件作为修改频次最高的组件，减少业务组件，可以提高开发效率；相反如果有拆的过于零散，会造成开发一块业务，要横跨好几个组件才能完成，如果再加上组件独立git仓库，必然影响开发效率，这也是我们在之前拆分过程吸取的教训。\n* 依赖关系：业务组件之间不能存在依赖，只能向下依赖功能组件或Base组件\n\n### 4.3 功能组件划分规则\n* 命名规则：`library-` + `后缀名`\n* 划分规则：**细粒度**，**高内聚**，为业务组件提供支撑，可以是基础服务，也可以是封装了单一功能组件；\n* 修改频率：**中**；一旦功能组件稳定，修改频率会大幅降低，向上提供稳定的服务或功能；\n* 依赖关系：功能组件之间不能依赖，只能向下依赖Base组件；\n* 主要作用：1、提供基础服务或独立功能；2、抽取封装业务组件内的通用或独立功能，**为业务组件减负**；3、作为APP的中台代码，形成沉淀，提高稳定性；\n\n### 4.4 Base组件规则\n* 命名规则：`library`，不用加后缀，如果在一个AS工程内，library可以友好的显示到上面；如果是独立git远程aar，groupId本身也可以区分；\n*  划分规则：进入Base代码要斟酌考虑，区分代码是该封装到功能组件，还是下沉到Base，判断标准是代码通用性，这部分代码是所有组件都需要依赖，还是仅仅只给某个业务组件依赖；\n* 修改频率：**低**；下沉到Base里的代码，一定要谨慎考虑，高通用性、高稳定性；\n* 主要作用：为上层组件提供基础支撑；提供App开发常用基础功能；完全非业务耦合；封装三方调用；基础工具类调用；一个APP所不可少的代码封装；\n\n### 4.5 特殊代码存放规则思考\n总有一部分代码不好安放，也是最纠结的地方，比如：启屏页，引导页，首页框架、搜索、我的、设置、关于等等，这部分代码，不属于某块业务，放到功能组件也不合适，更不能放到Base，而且每个App都需要这些代码才能运行，这部分代码一种可行的方式是，创建一个 `app-support`独立存放。\n* 命名规则： `app-support`\n* 划分规则：为App运行提供支撑；不明显属于某块独立业务；\n* 修改频率：**低**；\n* 依赖关系：可以依赖业务组件，做内容填充；比如MainActivity内依赖的Fragment，Fragment本身可以属于某块业务，比如关注列表，如果你有UGC业务，明显属于UGC业务组件 ；\n\n## 5. 组件间通信方式\n### Activity 界面之间调用\n\t* 组件对外开放的Activity界面，全部通过定义的Router协议进行跳转；\n\t* 拦截器：针对需要登录，全局Token失效踢出等进行拦截跳转；\n\t* 降级支持：页面未找到，提供Toast、空页面，H5页面等降级说明；\n\t* Router协议的存放：不建议提供中心存放，避免中心依赖；业务组件里有很多对外调用，不要直接把调用写在onClick方法内，在module内部提供一个控制类，统一调用控制即可。\n\t* https://github.com/chenenyu/Router，轻量、灵活、易懂易用；\n\t* https://github.com/alibaba/ARouter，功能更丰富强大；\n\n### 事件或消息跨组件传递\n\t* 基本原则是，全局事件要慎重考虑，过多的全局事件，必然需要中心存放和频繁修改底层组件，带来不稳定性和耦合；\n\t* 如果有中心事件源在中台，需要接收和抛出，那么设计好数据结构和接口，使用观察者模式，业务调用层扩展和处理；事件源只传递基础数据，不负责业务处理；\n\n## 6. 大工程的拆分思路\n\t* 分析业务和工程代码，形成组件化架构图，提供整体拆分依据；\n\t* 目前已独立的服务，按照组件原则拆分解耦，提供远程aar调用；\n\t* 被依赖基础组件，那些组件是不拆分，阻塞其他代码拆分，优先拆分；\n\t* 底层Base组件，优先进行；\n\t* 拆功能组件，留业务组件，业务组件后划分；\n\t* 自底向上拆分比较容易点；\n\t* 不要一下子变成远程，先再AS内独立module，再变成远程仓库；\n\t* 各module自己管理相关业务数据，不要所有http请求都放到一个类；\n\n## 7. 组件化之后的问题和思考\n* 组件不变成独立git仓库的代码查找和重构？\n可以考虑类Android源码的管理方式，通过repo来管理；编写脚本和xml来管理多个组件；\n\n\n\n\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftianshaojie%2Fandroid-modularization","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftianshaojie%2Fandroid-modularization","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftianshaojie%2Fandroid-modularization/lists"}