# Componentization

**Repository Path**: bookbuf/Componentization

## Basic Information

- **Project Name**: Componentization
- **Description**: 项目组件化实践
- **Primary Language**: Android
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2016-12-22
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 组件化实践

标签（空格分隔）： 开发设计

---


# 组件化实践
这是在不使用`黑科技`的方案情况下，将产品组件化。其所花费的成本远小于（约1/50的成本）各种使用`DexClassLoader`、`Hook`的插件化框架。

诚然，`插件化`和`组件化`是两个层面的东西，但因地制宜此刻我们需要`组件化`。**我们只解决拆分业务提供产品货架的商品，不解决插件化（动态更新插件）。**

拆分业务`module`后，对整个项目的build的时间会增加，但针对单个`module`的编译时间会减小，选择性的编译`module`可以减少不必要的完整功能编译次数。

## 为什么要组件化：
1、解决团队协作时，因为依赖其他模块而造成的闲置
2、解决因频发的安装测试（每次build约3~5min），一天大约有30min时间可以用于喝咖啡的现状
3、缓解因独立业务耦合，带给测试团队功能测试的压力（附带帮产品货架积累商品）

## 思想转变
* `module`不再只是`lib`包，`module`可以单独编译成apk并被执行
* `domain`不再`pubic`，而是`module`范围内可见
* `module`是自闭合的生态，原则上不依赖外部（如果真的需要外部触发源，请打桩）


## 前提条件
* 产品层面理解并支持产品货架的做法，愿意面向产品货架作设计
* 面向功能层面的组件（即技术货架的商品）已经拆分清晰 
* 面向业务层面的模块（即产品货架的商品）界限清晰  

## 问题列表
* 前期
    * 业务`module`的拆分粒度的决策
    * 与产品沟通`产品货架`思想
    * 原型架构的设计、实施、验证 
        *  `RPC` 定义接口远程调用  
        *  `UI Component Module` ，向外部提供UI组件资源，即换肤/主题功能（可选）
* 兼容
    * `Dagger2` Scope使用到极致
    * `DataBinding` 拆分后并重构会引起的大量XML的修正，还有`library`生成的是abstract类的问题
* 后期
    * 支持module之间互相依赖（去中心化），每个module在调试模式下为中心，在发布模式下为模块。


<!--路由规则
* `Route` 路由规则，`module`之间正常跳转 （三选一）
* `Navigation` 路由规则，`module`之间的正常跳转 （三选一）
服务调度
* `Service` 服务规则，`module`向外部暴露可提供的服务、数据 。
* `OSGi` 服务中心，`module`向`OSGi`注册本身提供的服务，第三方`module`向`OSGi`发起申请调用服务（需定义`OSGi` Scheme-->
    
## 参考资料
* [Merge Multiple Manifest Files](https://developer.android.com/studio/build/manifest-merge.html)
* [从零开始的Android新项目11 - 组件化实践](http://blog.zhaiyifan.cn/2016/10/20/android-new-project-from-0-p11/)