项目背景：公司的产品主要是在*的多个国家，在经历C轮融资后，准备加快步伐占领市场。公司决定分多个APP（以前是一个APP)，同时拓展新的业务，需要开发新的APP，目前团队人数20+，人数还在不断的增加，计划35左右。分成7-10 team,为了解决多人开发的麻烦，加快开发速度，在公司只有5人的时候，我们一致同意组件化开发，哈哈哈哈哈，当时的决定感觉好搞笑，记得有次和朋友（大厂）聊天，向他取经，和他说我们5人在组件化开发，他说我们在装B。在目前看来，当时的决定真的很正确，为开发、测试节省了很多的时间
组件化定义
首先需要对组件进行定义，叫组件也好，模块也罢，我们姑且认为我们讨论的范畴是【独立的业务或者功能单位】。至于这个单位的粒度大小，
需要工程师自己把握。当我们写一个类的时候，我们会谨记高内聚，低耦合的原则去设计这个类，当涉及多个类之间交互的时候，
我们也会运用SOLID原则，或者已有的设计模式去优化设计，但在实现完整的业务模块的时候，我们很容易忘记对这个模块去做设计上的思考，
粒度越大，越难做出精细稳定的设计，我暂且把这个粒度认为是组件的粒度。组件是由一个或多个类构成，能完整描述一个业务场景，
并能被其他业务场景复用的功能单位。组件就像是PC时代个人组装电脑时购买的一个个部件，比如内存，硬盘，CPU，显示器等，
拿出其中任何一个部件都能被其他的PC所使用。
组件化是一个广泛的定义，都是开发人员根据自己在开发经验中总结出来的。我的想法：在高内聚，低耦合的设计原则的基础上，去分割项目，通过分层的思想去封装功能单元，每一个单元都是独立的，在不影响其他功能的同时，可以单独测试。说的更明白的，可以把苹果手机（4 -9）系列类比成项目A，iPhone X 系列类比成项目B，Mac系列类比成项目C，那么，手机（4-9）我们可以类比成带UI的模块，每一款的手机都有自己的特性；苹果手机的充电线可以在项目A、B、C使用，苹果耳机可以在项目A、B使用，这类二级充电线可以类比成不具备业务场景的功能模块。目前我们的项目主要将组建分为以下几类：
带UI属性的独立业务模块
带UI属性的业务组件
不具备UI属性的独立业务组件
不具备业务场景的功能组件
带UI属性的独立业务模块
这类我一般称之为模块，是较大的独立业务，具有很强的业务性，模块之间是不相互引用的，不然就失去了组件化的意义。比如一个APP的首页模块、登录模块、我的模块、购物车模块等等。一般情况可以是tabbarController的item,当然也可以是其他的，没有强制规定。具体看项目的拆分以及人员的安排。这类模块一般都有一个跳转的入口，可以是itme可以是push、可以是Present的方式；其次这类模块一般都有一系列的操作，如：购物车，选商品、下单、分期等；登录模块的忘记手机号码、忘记密码等等一系列操作。这里又设计到模块之间的跳转，这也是组件化的核心之一，既然模块之间是相互独立的，前面也说了，模块之间是不相互引用的，那么怎么跳转呢？可以通过URL方式，蘑菇街 就是通过这样的方式，目前我们的项目用的是Mediator,还有协议的方式。
带UI属性的公共组件
这类组件涉及到UI业务功能，不是很常见。刚好我在项目中遇到过，恰巧是我做的。有一个涉及到UI的功能，需要在A、B、C三个模块中使用，于是毫不犹豫地封装成组件，这类组件是最复杂、最麻烦的。带UI属性的独立业务模块我们可以在模块内"为所欲为"反正都是自己的功能，别人也管不到，但是带UI属性的业务组建，不只是你在使用，涉及到其他的组员，要考虑到其他功能的特性。总之这样的组件，即抽象又具体，我只能这样形容
#######不具备UI属性的独立业务组件
这类组件是比较常见的，它不和任何的UI相关，但是和具体的功能相关，如：分享功能，第三方登录功能等我们只要接口的返回的数据，不需要我们push或者Present,只需要一个简单的接口，内部怎么实现的不在考虑范围内。类似我们调用苹果给我们封装好的接口。如 let button = UIButton.init(type: .custom), init(type: .custom)内部怎么实现的，和你没有关系。
不具备业务场景的功能组件
这类在项目中非常的常见。但是，但是，也是非常重要的。可以说是在项目中最底层的、很少变动的。如：Database组件、网络组件、国际化等。从整个项目来说，是位于组件化分组的最底层，涉及范围广，如果改动，付出的代价太大。对待这类组件，我们的原则是指增加接口，尽量、尽量少的改动，除非不影响大家使用。
组件之间的通信
Mediator进行通信
Protocol协议方案
Mediator进行通信
针对这种方案大佬bang提出了一些问题，并且与Mediator进行通信进行了对比
需要有个地方列出各个组件里有什么 URL 接口可供调用。蘑菇街做了个后台专门管理
每个组件都需要初始化，内存里需要保存一份表，组件多了会有内存问题
参数的格式不明确，是个灵活的 dictionary，也需要有个地方可以查参数格式
在愚公编程MrPeak:iOS组件化方案中 中对3个问题进行了详细的解释
第一个问题是最明显的问题，组件的使用方必须通过查阅web文档之后，再手写string来完成调用。这种组件调用方式确实会有一定的效率问题。
第二个问题所说的表和内存问题我没理解具体是指哪一块。我算了下Router当中的额外内存开销，一个用来存储Mapping的NSMutableDictionary，iOS App当中使用Dictionary的场景会很多，Dictionary带来的内存开销主要看其所强引用的key和value。二是以URLPattern为Key的各种string，这个估计是大头，但Casa的方案里将Action以String的方式hardcode，也会导致这些String常住内存，其本质是将原本处于Text区的函数符号换成了位于Data区的string，此消彼长，这部分内存消耗也在正常范围之内，最后是handler block，这部分开销也属于常规使用，和一次函数调用并没有本质区别，看上去内存消耗总量并没有特别增长，或许还有其他我没考虑到的部分。
第三个问题其实和第一个问题是类似的，需要查阅文档来hardcode参数名称。
我们目前用的是这种方案，其他的还没有尝试过。组件A register,组件B push
Router.register(xxxxx) { (url, values, context) -> UIViewController
Router.register(xxxxx) { (url, vaules, context) -> UIViewController
Protocol协议方案
我们也考虑过这种，在拜读 Limboy // bang // 愚公编程MrPeak文章之后，我们选择了中间的方案。在以上大佬的博客中都阐明了各种组件跳转的有点和缺点。
关于私有库创建
这种问题百度或者google一下就一大片，创建私有库
