时间是来到2020年，组件化技术已经相对成熟，对其的实现思路，核心思想也基本确定，组件化已然成了一个技术公司和技术人员都应该具备的能力。
虽然组件化技术已经趋于成熟，但对于一个项目进行组件化改革也不会是一个一蹴而就的事情。相反我认为组件化对一个项目来说他是一个过程，是一个随着需求和项目发展不断改进架构和组件化程度的过程。组件化过程中一样会面临耦合和代码复用的问题，这些问题的友好解决，也是组件化的价值和难点。
一个项目如果是发展的，那么他必然面临着如下的问题：
-
适应市场，需求越来越多，进而导致代码越来越多，模块间的耦合在所难免，耦合严重度也会随之升高。
-
项目模块增多，之前由2-3个人维护的代码开始人手不足，所以变成了多人维护多个模块。此时会出现，代码风格多样化，引入依赖库多样化，如果项目需求紧张可能存在同一功能由两个不同的依赖实现。
-
人数多了之后，人员的变动也是时常发生的事，那么可能就会产生同一模块又产生代码风格的多样化，实现思路多样化。这个问题继续发展下去就是，后面再接手的人，看了下代码，感觉哪哪都不敢改，然后想办法不动之前的代码，这样的一个项目带来的后果就是，出问题很容易，改问题很难。
-
模块的增多，耦合的增加还会产生定位时互相推诿，你说我的模块有问题，他说你的模块有问题，那么此时推断到底是那个模块的问题时间消耗又会增加。
-
另外可能有的项目有意识的将模块变成了module，然后让各自的人员去维护各自的module，这样可以一定程度的解决互相耦合的问题，不过随着开发的推进，模块之间的关联持续增加，必然会导致如基础数据，公共访问接口下沉，父类为了实现子类的功能，子类将功能放到父类中，这就产生了底层的臃肿，和逻辑混杂，说的直白点就是将之前存在于个模块的一部分耦合集合下沉了。
总之以上是五个主要的方向，实际开发这些项目的时候产生的具体问题会比这多很多，最后就是研发辛苦但是看不到成果，而且研发开销还会逐渐增长。
所以组件化的产生可以说是一个必然，也是有充分需求下产生的技术。
组件化的核心目的是隔离，这种隔离是组件间隔离，以及组件内的隔离。他是用一些代码和规则去保护另外一些代码和功能，对于一个功能他实现的是“1+1”那么组件化后他还是“1+1”，只不过他被保护了起来，不再可以直接调用。举个具体的例子，有点像网络访问，你能拿到的只是接口、字段、和访问方式，但是具体如何实现你是不知道的，也不可见，同样你只能使用开放出来的东西。
如果感觉组件化的概念没有理解深入，那么你可以把它看成在一个项目中，做应用间的通信。只是各自对应的层级下降。他的实现后的效果和AIDL是十分相似的，两个项目之间不再有任何关系彼此透明，A项目如果想访问B项目，必须按照B项目开放出来的接口和数据结构去访问。这就是组件化在组件间要做的事情，组件间不在有依赖关系，彼此透明，如果要互相访问只能按照开放出来的规则去访问。这种隔离有效的解决了组件间的耦合问题，让问题留在组件内部。
当然组件化也不是没有缺点的。
- 你需要用一部分代码和规则去保护另外一部分代码，主要体现在接口代码的实现和编译规则的编写。对于编译规则也是有一定学习成本的，当然可以输出一个模版，有需要的时候更改模版即可。
- 引进组件化后必然会增加moudle的数量，如果只是在单一项目中通过SVN的形式去打包，会在一定的程度上增加编译时间。这个问题也可以通过插件化的方式去解决。
- 组件间的通信是透明的，如果是通过scheme或者一些其他的方式实现的，这是有一定风险的，如果拼写或传参类型的错误都可能导致崩溃或失效。
总之最大的开销还是在于组件化过程中，组件建立和组件对外暴露的接口与数据模型，以及建立编译规则的实现。