组件化方案分析

蘑菇街

https://limboy.me/tech/2016/03/10/mgj-components.html https://limboy.me/tech/2016/03/14/mgj-components-continued.html

Casa

https://casatwy.com/iOS-Modulization.html

bang

http://blog.cnbang.net/tech/3080/

美团

https://tech.meituan.com/2018/12/06/waimai-ios-optimizing-startup.html

阿里巴巴

https://github.com/alibaba/BeeHive https://halfrost.com/beehive/

其他

https://nixwang.com/2017/05/06/ios-modulization/ http://blog.pengqi.me/2016/03/22/ios-routing/ https://github.com/wequick/Small

什么是路由

叫路由也罢、总线也罢、中间人也好，说白了，就是一层胶水，把两个互不认识的组件粘到了一起。

openURL方式

用来处理推送、H5跳转、支付回调、分享等。

优点

  1. 可以灵活配置，甚至从服务器下发配置项，达到动态修改行为的目的
  2. Android 和 iOS 可以统一
  3. 自动降级 老版本解析不了URL，走老的逻辑依旧可用。新版本可以解析URL，走新的逻辑。

缺点：

  1. 提供的服务信息无法从代码层面获取，需要通过其他渠道（后台系统、文档）治理。
  2. 无法传递复杂参数（如 UIImage）

注意点：

  1. 外部调用无法传递复杂参数（如 UIImage）
  2. 外部调用应该基于内部调用暴露出去
  3. 可能会有安全隐患，可能存在通过外部调用到无权限服务的情况

Protocol + Wrapper方式

优点

  1. Protocol支持一对多，任何对象都可以实现某个Protocol
  2. 同一套Protocol可以对应不同业务，满足能力相同但输出不同的业务场景
  3. 可以满足换肤或换主题的需要，相同能力，UI不同。实现方案有多种，其中一种是基于同一个Protocol更换UI Wrapper
  4. 结构清晰，可读性高

缺点

  1. 写起来有点绕，麻烦
  2. 组件多了，内存会上升
  3. 要严格根据public协议维护组件生命周期

Mediator方式

  1. 定义对外提供的能力
  2. 需要Wrapper(Category)

从这两点看，和Protocol对比，在表现方式上没有本质区别

优点

  1. 采用runtime，灵活
  2. 轻量

缺点

  1. runtime比较灵活，编译阶段无法及时暴露问题，组件漫天开花后，容易引起爆炸，无论是APP Crash还是业务服务NOT FOUND
  2. 存在一些硬编码，类名修改后，改动起来有一定工作量
  3. Target命名，要尽量抽象，比较考验程序员经验

题外话

说是争论，可能就是想说，有我没你。

技术方案、工具，本无高低，唯合适而。

做应用工程的没什么所谓的技术，挑选合适的工具即可。

大道至简，回归原始

用Flutter框架的定义，万物皆Widget，我们也可以说万物皆组件，颗粒度的区别。

举个粗点的例子：

APP = A组件 + B组件 + C组件 + …

A组件 = A1 + A2 + A3 + …

A1组件 = A11 + A12 + A13 + …