去年就开始做组件化，没啥活，就自己找的活儿，一套视频看下来，理论知识有了，但是对着自家的项目，却还是无从下手，所以搁置到现在，下定决心两个月内要把自家项目组件化好。
本文主要讲述基于cocoapods来做组件化的方案
首先针对iOS组件化，我们先针对5W+1H的问题进行分析。
什么是组件化（What）？
组件化就是将APP拆分成各个组件（或者说模块也行），同时解除这些模块之间的耦合，然后通过主工程将项目所需要的组件组合起来。这样组件化过后的项目就变成了很多小模块，如果新项目中有类似的需求，直接将模块引入稍作修改就能使用了。
这种设计是不是很像引入三方库做快速开发？其实制作组件的过程就相当于做二方库。因此常见的组件化方案大多都是使用cocoapods做依赖管理。
为什么要做组件化（Why）？
- 组件可独立运行，提高的代码的复用性和可测性，组件化的颗粒度越细，可复用度就越高。
- 当组件库的数量足够庞大时，项目只需要组合组件即可完成大部分的开发工作（当然这个时候要解决怎么把组件有序的管理起来的问题）。
- 组件化后项目的代码结构更加清晰，追踪问题、修复bug、增加需求更方便。
- 不同业务组件相互独立，明确团队开发的业务边界，增加团队协作效率。
- 减缓代码腐化过程，加快编译时间，模块分权管理，代码规范，bug 减少，独立开发、调试、自动化编译，集成等等工作。
更近一步的讲，我们需要一套自动化的系统来帮助我们完成所有的组件管理工作，让开发人员能更专注于代码层面，无需关心应用配置，渠道，以及如何集成等问题。
组件化的缺点：
增加开发人员的学习成本
增加了代码的冗余，组件化颗粒度越细，中间代码越多
增加了项目的复杂度，复杂度越高越容易出问题
应该在哪里做组件化（Where）？
一般组件化后的小组件源码放在github上(现在github私有库已经免费了，但是有限制，3人/项目的人数限制、私有项目无法使用保护分支、持续集成等高级功能)，所以还是建议放在gitlab上，或者码云也可以。
什么时候该做组件化（When）？
在一个项目越来越大，开发人员越来越多的情况下(建议团队成员超过10人的时候)，出现了以下情况，需要做组件化：
- 业务模块间划分不清晰，模块之间耦合度很大，非常难维护。
- 所有模块代码都编写在一个项目中，测试某个模块或功能，需要编译运行整个项目。
由谁来做组件化（Who）？
组件化的第一步需要代码解耦，第二步实现Cocoapods的管理。所以将一个项目组件化需要该成员具备以下技能：
- 具备良好的API设计能力，即解耦和封装的能力。
- 熟练使用Cocoapods，会cocoapods本地私有库和远程私有库的使用 Using CocoaPods
- 会常用的git命令 Git教程
- 熟练制作静态库（组件只有制作成静态库，才可以提高项目的编译速度）
- 对项目业务很熟悉
如何做组件化（How）？
组件化原则：
1. 越底层的模块，应该越稳定，越抽象，越具有高复用度。
2. 不要让稳定的模块依赖不稳定的模块， 减少依赖。
3. 提升模块的复用度，自完备性有时候要优于代码复用。
4. 每个模块只做好一件事情，不要让Common出现。
5. 按照你架构的层数从上到下依赖，不要出现下层模块依赖上层模块的现象。
模块解耦并不是说你把工程的代码拆分成 50 个 pod 或者framework就算完事了，要实现模块之间真正的解耦才算真正的模块化，否则如果模块之间还都是互相调用代码，循环依赖，那么和原本放文件夹里面没啥两样。
模块解耦的目标就是, 在基于模块设计原则上, 让模块之间没有循环依赖, 让业务模块之间解除依赖。
模块可分为基础模块和业务模块，基础模块不依赖于业务模块，业务模块之间通过中间件进行沟通。
基础模块：最稳定的代码可以作为基础模块，包括稳定的三方库，底层网络通信模块，常用的 category 等等。这些代码不会频繁改动，可以作为基础模块。
业务模块：根据业务划分，业务跟业务之间的沟通用中间件来，模块之间的通信可以参考
casa的iOS应用架构谈 组件化方案
蘑菇街 App 的组件化之路
参考文章：ios组件化/模块化
