App架构五阶段演进：复杂度驱动与架构原则的对应

架构设计相关的理念、技术、实践主要聚焦在后端系统（存储高可用、微服务、异地多活等），但这并不意味着App、前端就没有架构设计——专栏所讲的整套架构设计理念，虽然来源于后端设计经验，一旦形成完善的技术理论后，同样适用于App和前端。回顾这套理念的关键点：架构是系统的顶层结构；架构设计的主要目的是解决软件系统复杂度带来的问题；架构设计需要遵循合适原则、简单原则、演化原则；架构设计首先要掌握业界已成熟的各种架构模式，然后再优化、调整、创新。App架构的演进正是这套理念的具体体现，大致经历五个阶段。第一阶段Web App（包壳架构）：在Web业务上包装一个App壳，业务逻辑完全由Web实现，App壳只完成安装功能。约2010年前后，移动互联网还是新鲜事物、发展前景不明朗（淘宝2013年才决定”All in无线”），业务重心仍在PC互联网，移动端更多是尝试性质，因此需要”快速开发”和”低成本”，原生开发成本太高，Web App成为首选——遵循”合适原则”和”简单原则”。第二阶段原生App：随着移动设备发展速度远超Web技术、App承载的业务逻辑越来越复杂、且只有原生才能利用移动设备的用户体验优化技术，复杂度焦点从”快速开发/低成本”转向”用户体验”，原生App成为最合适的选择——遵循”演化原则”（约2013年前后快速发展）。第三阶段Hybrid App：移动互联网已成明确大趋势，竞争关键变成”谁更快抓住用户需求”，复杂度又回到”快速开发”，但原生App在Android/iOS/Windows Phone三平台间完全不兼容、同样功能要重复开发三遍；由于Web体验又不如原生，于是按业务需求分别选型——体验要求高的用原生、要求不高的用Web，这就是Hybrid App的核心设计思想，是”用户体验”和”快速开发”两个复杂度之间的平衡（不是同时解决），遵循”合适原则”。第四阶段组件化/容器化：超级App（如手机淘宝、微信）在一个App里承载几十上百个子业务，且每个业务由独立团队开发、还在不断扩展，引入了新的可扩展性复杂度；解决办法是把超级App拆分成众多遵循统一规范、可独立开发测试上线的组件，组件间通过消息系统通信实现隔离——这只在业务复杂度发展到一定规模后才适用，遵循”演化原则”，中小公司通常不需要。第五阶段跨平台App：前面除Web App外的方案都面临同一功能要在Android、iOS各开发一遍的重复投入问题，违背”简单原则”，于是React Native、Weex、Flutter等跨平台方案不断涌现，但目前都不算成熟，用户体验上也和原生App有差距（例如Airbnb已宣布放弃React Native、回归原生技术）。

结构图：

flowchart LR
  A["Web App(包壳)<br/>复杂度=快速开发+低成本<br/>合适原则+简单原则"]
  A --> B["原生App<br/>复杂度→用户体验<br/>演化原则"]
  B --> C["Hybrid App<br/>复杂度→快速开发(多平台重复)<br/>体验与开发的平衡·合适原则"]
  C --> D["组件化/容器化<br/>复杂度→超级App可扩展性<br/>演化原则(仅大厂适用)"]
  D --> E["跨平台App(RN/Weex/Flutter)<br/>复杂度→减少重复开发投入<br/>简单原则(尚不成熟)"]