高耦和，低内聚，无重用是工程师的三大噩梦，每每工作遇到这样的代码，总会夜半惊醒。而移动软件的模块化，组件化应该是两个烂大街的词。这是一个软件的代码量和维持人数上增之后的必然结果。我们知道移动应用业务逻辑达到一定程度，项目工程的代码就需要进行划分，如微信Android早期版本使用到的架构。
从图中可以看到，在业务工程划分出多个模块，这些不同模块可能由于不同的工程师维护，如朋友圈、摇一摇、附近的人等功能依次叠加于该代码之上。
而组件化是一个更进阶的方案，组件化后每个组件都有自己独立的版本,可以独立的编译,测试,打包和部署。当然其依然依赖公共的 基础库。如蘑菇街的APP就有这样的架构。
我们可以认为模块化粒度更小，更侧重于代码的重用,而组件化粒度稍大于模块，更侧重于业务解耦。
从以上两图可以看出，模块化，组件化依然依赖我们的公共代码库的能力，比如在蘑菇家的架构上，我们可以看到基础组件，Hybird，或者是图上未表明Route设计在发挥着它的作用。但是这样的架构就够用了么？先来看看支付宝的首页
单单这个页面上有几十个功能，都是由不同团队复杂，这样的一个APP有成千上万的功能，传统的组件化无法实现这样热插拔的功能，即使内部团队能够按照设计标准完成，而外部团队呢，APP的功能如果由合作伙伴提供的话，这个又是一个问题。在Hybrid概念出来之后，借助Javascript 调用本地接口的能力，工程师们将接口一一设计出来暴露给Web应用调用。但是这里也会存在一些问题：
1、团队构建web应用方式问题。每一个团队因为其偏好的原因，使用库或者工具链完全不一致。
2、团队开发能力问题。不同团队开发能力不一样，基础不一样，开发出来的应用质量参次不齐。
3、宿主应用技术支撑问题。比如宿主应用提供了缓存能力，但是这个缓存的能力在web标准中并为涉及。那作为web应用本身是否有应用到这个能力完全由开发团队的偏好决定。
于是Web应用给予用户的产品体验完全是不可控的。