搬运来的一些注意事项：
1.页面跳转
页面跳转解决方案与业务组件之间通信问题是一样的。
但是需要注意的是，你一个业务组件内部的页面跳转也请使用URL+Router的方式跳转，而不要自己直接pushViewController。
这样的好处是：如果将来某些内部跳转页面需要给其他业务组件调用，你就不需要再注册个URL了。因为本来就有。
2.是否去Model化
去Model化主要体现在业务组件间通信，要不要传一个Model过去(传过去的Dictionary中的某个键是Model)。
如果去Model化，这个业务组件的开发者如何确定Dictionary里面有哪些内容分别是什么类型呢？那需要有个地方传播这些信息，比如写在头文件，wiki等等。
如果不去Model化的话，就需要把这个Model做成Pod库。两个业务组件都去依赖它。
最后决定不去Model。因为实际上有一些Model就是在各个业务组件之间公用的（比如User），所以肯定就会有Model做成Pod库。我们可以把它做成重Model，Model里可以带网络请求和本地存储的方法。唯一不能避免的问题是，两个业务组件的开发者都有可能去改这个Model的Pod库。
3.信息的披露
不同业务开发者如何知晓这些信息。 使用去Model化和不使用去Model化，我们都有各自的方案。 去Model化，则披露头文件，在头文件里面写详细的注释。
如果不去Model化，则就看Model就可以了。如有特殊情况，那也是文档写在头文件内。 总结的话：信息披露的方式就是把注释文档写在头文件内。
4.组件的生命周期
业务组件的生命周期和App一样。它本身就是个类，只暴露类方法，不存在需要实例，所以其实不存在生命周期这个概念。而它可以使用类方法创建很多ViewController，ViewController的生命周期由App管理。哪怕这些ViewController之间需要通信，你也可以使用Bus/YTXModule/协议等等方式来做，而不应该让业务组件这个类来负责他们之间的通信；也不应该自己持有ViewController；这样增加了耦合。
弱业务组件的生命周期由创建它的对象来管理。按需创建和ARC自动释放。 基础功能组件和第三方的生命周期由创建它的对象来管理。按需创建和ARC自动释放。
5.版本规范
所有Pod库都只依赖到minor
"~> 2.3"
主App中精确依赖到patch
"2.3.1"
主App中的业务组件版本号的Main.Minor要和主App版本保持一致。
参考： Semantic Versioning(https://semver.org), RubyGems Versioning Policies(http://guides.rubygems.org/patterns/#semantic-versioning)
6.单元测试
单元测试我们用的是 Kiwi 。 结合MVVM模式，对每一个业务组件的ViewModel都进行单元测试。每次push代码，gitlab-runner都会自动跑测试。一旦开发人员发现测试挂了就能够及时找到问题。也可以很容易的追溯哪次提交把测试跑挂了。
7.持续集成
原来的App就是持续集成的。想当然的，我们希望新的组件化开发的App也能够持续集成。 Podfile应该是这样的：这里面出现的全是私有Pod库。
pod 'YTXRequest', '2.0.1' pod 'YTXUtilCategory', '1.6.0' pod 'PBBasicProviderModule', '0.2.1' pod 'PBBasicChartAndSocketModule', '0.3.1' pod 'PBBasicAppInitModule', '0.5.1' ... pod 'PBBasicHomepageBusinessModule', '1.2.15' pod 'PBBasicMeBusinessModule', '1.2.10' pod 'PBBasicLiveBusinessModule', '1.2.1' pod 'PBBasicChartBusinessModule', '1.2.6' pod 'PBBasicTradeBusinessModule', '1.2.7' ...
持续集成(工具：gitlab runner)的整个流程是：
第一步：
使用template创建Pod。像这样：
pod lib create <Pod库名称> --template-url="http://gitlab.baidao.com/pods/ytx-pod-template"
第二步：
创建dev分支。用来开发。
第三步：
每次push dev的时候会触发runner自动跑Stage: Init Lint(中的test)
第四步：
1.准备发布Pod库。修改podspec的版本号，打上相应tag。
2.使用merge_request.sh向master提交一个merge request。
第五步：
1.其他有权限开发者code review之后，接受merge request。
2.master合并这个merge request 3.master触发runner自动跑Stage: Init Package Lint ReleasePod UpdateApp
第六步：
如果第五步正确。主App的dev分支会收到一个merge request，里面的内容是修改Podfile。 图中内容出现了AFNetworking等是因为这个时候在做测试。
第七步：
主App触发runner，会构建一个ipa自动上传到 fir 。
以上注意内容来自：https://blog.csdn.net/u013602835/article/details/52668894，还没机会实践，先存着
参考来源
本文整理内容参考了以下文章，在此对原作者们表示感谢：
- 《iOS应用架构谈 组件化方案》（https://casatwy.com/iOS-Modulization.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io）
- 《路由设计思路分析》（https://juejin.cn/post/6844903465072721927）
- 《iOS 组件化方案探索》（http://blog.cnbang.net/tech/3080/）
- 《iOS App组件化开发实践》（http://www.infoq.com/cn/articles/ios-app-component-development-practice）
- 《iOS 业务模块间互相跳转的解耦方案》（https://blog.csdn.net/cuibo1123/article/details/51017376）
