为什么要使用组件化？？？

什么是组件化？

  在看了很多其他的方案之后，首先对组件化思想上有一个小分歧。我认为很多人对于 iOS 中组件化的理解其实是有误区的。做 Flex 开发，其中就有很多组件化的思想，加上最近在用 Vue 做 web 项目之后，更为意识到大家在 iOS 开发上说的组件化有点不合适。
  首先我认为组件是一个相对比较小的功能模块，不需要与外界有太多的通信，更不能依赖其他第三方，这一点尤为重要。比如说几乎所有 iOS 开发者知道的 MJRefresh，几乎不依赖业务，并且提供了良好的调用接口和使用体验的才能称为组件。而看了很多方案，大部分都是在讲 App 里面的业务能组件之间的通信和解耦，其实我更愿意将这些东西称为 “模块”。那如何区分这两种呢，我觉得这句话比较好理解：核心业务模块化，通用功能组件化。
  打比方说你的 App 是一个电商项目，name 你的产品详情页、列表页、购物车、搜索等页面肯定就是调用频次非常高的 VC 了，这些界面之间跳转都会非常频繁。这就造成了互相依赖并且高度耦合。如下图所示：

  像商品详情页这些通常外部调入只需要传入一个 productID 就可以，而且高度依赖自己的业务功能的模块就可以将这些当成一个模块维护。后面需要修改里面的活动的显示、业务的增删都可以单独在详情模块里面改动而不需要改动别的代码。
  而对于组件，比方说我上面提到的 IM 类型的 App 中用到的聊天键盘，或者集成支付宝、微信等支付功能的支付插件。这些可以在多个不同的项目小组内部共享。甚至可以开源到社区中提供所有开发者使用的小插件，用组件来形容更贴切。在 Flex、Vue、angular 等前端开发中提现尤为突出。

为什么要有组件化(模块化)

  客户端在公司业务发展的过程中体积越来越庞大，其中堆叠了大量的业务逻辑代码，不同业务模块的代码相互调用，相互嵌套，代码之间的耦合性越来越高，调用逻辑会越来越混乱。当某个模块需要升级的时候，改动代码的时候往往会有牵一发而动全身的感觉。特别是如果工程量出设计的时候没有考虑接口的封装，而将大量的业务代码与功能模块代码混在一起时，将来的升级就需要对代码进行大量修改及调整，带来的功工作量是非常巨大的。这就需要设计一套符合要求的组件之间通信的中间件。模块化可以将代码的功能逻辑尽量封装在一起，对外只提供接口，