第4章-ThorComponent组件化框架(基于CC)
大约 2 分钟
####1、编写框架涉及技术
| 组件化涉及技术 | 优点 | 缺点 | 是否选用 | 理由 |
|---|---|---|---|---|
| serviceload | 调用是接口形式，比较直观 | 模块间调用解耦不易 | 否 | java的serviceload并不完备，实现多采用反射与效率背道而驰 |
| weixinapi技术 | 解决部分公用代码动态下沉到base | 编写.api要注意分包摆放 | 是 | 项目稳定后，一般不会有下沉base代码，可以将base抽象成公共库，本作者实现 |
| 组件单独运行和集成发布thorAlone | 编写组件减少他们之间的依赖 | 专用sourceSet.main.debug目录，sourceSet项目中用法过于负责慎用 | 是 | module间代码隔离,与壳工程隔离 |
| P工程 | 细粒度的解耦，减少module内过度依赖 | 一般中小项目中，粒度过于细了 | 否 | 一般项目多P工程解耦成本太高 |
| asm | 动态生成字节码效率高 | 底层技术编写过于复杂 | 是 | 参照cc-register，为了效率 |
| 总线模式 | 将服务扁平化 | 改造CC过于复杂 | 是 | 本框架采用改造CC，实现扁平化 |
| RPC | 多进程间通讯快 | 涉及远程调用场景不多 | 否 | 组件化间场景并不多，建议用专门库来实现这个功能 |
| apt注解 | 编译时注解，减少编写过多模板代码 | 编写有些复杂，如果不是强烈需要，建议不要 | 是 | 组件化框架目的就是为了使用者减少不必要代码编写 |
| 反射 | 可以hack代码，也可以动态化加载 | 运行时效率低下，用户体验差 | 否 | 尽量少采用反射 |
| 线程池 | 避免new Thread方式过于浪费内存资源，复用 | 实现有技术成本且慎用 | ||