谈谈App开发的演进

web app

最早的 App 有很多采用这种架构，大多数尝试性的业务，一开始也是这样的架构。Web App 架构又叫包壳架构，简单来说就是在 Web 的业务上包装一个 App 的壳，业务逻辑完全还是 Web 实现，App 壳完成安装的功能，让用户看起来像是在使用 App，实际上和用浏览器访问 PC 网站没有太大差别。
Web App 这种包壳架构主要解决快速开发和低成本两个复杂度问题，设计遵循合适原则和简单原则。

原生app

Web App 虽然解决了快速开发和低成本两个复杂度问题，但随着业务的发展，Web App 的劣势逐渐成为了主要的复杂度问题，主要体现在：

• 移动设备的发展速度远远超过 Web 技术的发展速度，因此 Web App 的体验相比原生 App 的体验，差距越来越明显;
• 移动互联网飞速发展，趋势越来越明显，App 承载的业务逻辑也越来越复杂，进一步加剧了 Web App 的体验问题;
• 移动设备在用户体验方面有很多优化和改进，而 Web App 无法利用这些技术优势，只有原生 App 才能够利用这些技术优势;

所以，随着业务发展和技术演进，移动开发的复杂度从快速开发和低成本转向了用户体验，而要保证用户体验，采用原生 App 的架构是最合适的，这里遵循了演化原则。

Hybrid App

原生app开发的平台差异性，如果要全兼容则速度成本上需要额外付出，而对于实验性市场需求而言，要求是快速开发投放市场验证，这时候可以根据不同的业务要求选取不同的方案，例如对体验要求高的业务采用原生 App 实现，对体验要求不高的可以采用 Web 的方式实现，这就是 Hybrid App 架构的核心设计思想，主要遵循架构设计的合适原则。

组件化 & 容器化

Hybrid App 能够较好的平衡用户体验和快速开发两个复杂度问题（注意是平衡，不是同时解决），但对于一些超级 App 来说，随着业务规模越来越大、业务越来越复杂，虽然在用户看来可能是一个 App，但事实上承载了几十上百个业务。

例如淘宝和微信，这么多业务集中在一个 App 上，每个业务又在不断地扩展，后续又可能会扩展新的业务，并且每个业务就是一个独立的团队负责开发，面临可扩展性的复杂度问题。

可以通过拆字来处理可扩展性问题，这在后端系统中就是拆分成各种子系统(微服务架构)，但是对于app而言，对用户还是只能呈现同一个 App，不可能将一个 App 拆分为几十个独立 App，同时，App 的业务再怎么拆分，技术栈是一样的，不然没法集成在一个 App 里面。

在这种业务背景下，组件化和容器化架构应运而生，其基本思想都是将超级 App 拆分为众多组件，这些组件遵循预先制定好的规范，独立开发、独立测试、独立上线。如果某个组件依赖其他组件，组件之间通过消息系统进行通信，通过这种方式来实现组件隔离，从而避免各个团队之间的互相依赖和影响，以提升团队开发效率和整个系统的可扩展性。

组件化和容器化的出现遵循架构设计的演化原则，只有当业务复杂度发展到一定规模后才适应,一般都用不上。

跨平台 App

比较知名的有 Facebook 的 React Native、阿里的 Weex、Google 的 Flutter

Atlas：手淘 Native 容器化框架和思考

微信 Android 客户端架构演进之路

Web研发模式演变

--------来源《极客课程》∙ 学习摘要