49谈谈App架构的演进Word文档下载推荐.docx
《49谈谈App架构的演进Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《49谈谈App架构的演进Word文档下载推荐.docx（3页珍藏版）》请在冰点文库上搜索。
合适原则、简洁原则、演化原则。
架构设计首先要把握业界已经成熟的各种架构模式，然后再进行优化、调整、创新。
复习完们就可以进入今日的正题，来谈谈App架构的演进，以及上面这些架构设计关键点是如何体现的。
WebApp
最早的App有许多采纳这种架构，大多数尝试性的业务，一开头也是这样的架构。
WebApp架构又叫包壳架构，简洁来说就是在Web的业务上包装一个App的壳，业务规律完全还是Web实现，App壳完成安装的功能，让用户看起来像是在使用App，实际上和用扫瞄器访问PC网站没有太大差别。
为何早期的App或者尝试新的业务采纳这种架构比较多呢？
简洁来说，就是当时业务面临的简单度打算的。
们以早期的App为例，大约在2022年前后，移动互联网虽然进展很快速，但受限于用户的设备、移动网络的速度等约束，PC互联网还是主流，移动互联网还是一个新奇事物，将来的进展前景和进展趋势，其实当年大家也不肯定能完全看得清晰。
例如淘宝也是在2022年才开头打算"
Allin无线'
的，在这样的业务背景下，当时的业务重心还是在PC互联网上，移动互联网更多是尝试性的。
既然是尝试，那就要求快速和低成本，虽然当时的Android和iOS已经都有了开发App的功能，但原生的开发成本太高，因此自然而然，WebApp这种包壳架构就被大家作为首选尝试架构了，其主要解决"
快速开发'
和"
低成本'
两个简单度问题，架构设计遵循"
合适原则'
简洁原则'
。
原生App
WebApp虽然解决了"
两个简单度问题，但随着业务的进展，WebApp的劣势渐渐成为了主要的简单度问题，主要体现在：
移动设备的进展速度远远超过Web技术的进展速度，因此WebApp的体验相比原生App的体验，差距越来越明显。
移动互联网飞速进展，趋势越来越明显，App承载的业务规律也越来越简单，进一步加剧了WebApp的体验问题。
移动设备在用户体验方面有许多优化和改进，而WebApp无法利用这些技术优势，只有原生App才能够利用这些技术优势。
因此，随着业务进展和技术演进，移动开发的简单度从"
转向了"
用户体验'
，而要保证用户体验，采纳原生App的架构是最合适的，这里的架构设计遵循"
演化原则'
原生App解决了用户体验问题，没记错的话大约在2022年前后开头快速进展，那个时候的Android工程师和iOS工程师就像现在的人工智能工程师一样特别抢手，许多同学也是那时候从后端转行到App开发的。
HybridApp
原生App很好的解决了用户体验问题，但业务和技术也在进展，移动互联网此时已经成为明确的大趋势，团队需要考虑的不是要不要转移动互联网的问题，而是要考虑如何在移动互联网更具竞争力的问题，因此各种基于移动互联网特点的功能和体验方式不断被制造出来，大家拼的竞争方式就是看谁更快抓住用户需求和痛点。
因此，移动开发的简单度又回到了"
，这时就发觉了原生App开发的痛点：
由于Android、iOS、WindowsPhone（你没看错，当年的确是这三个主流平台）的原生开发完全不能兼容，同样的功能需要三个平台重复开发，每个平台还有一些差异，因此自然快不起来。
为了解决"
的简单度问题，大家自然又想到了Web的方式，但Web的体验还是远远不如原生，怎么解决这个问题呢？
其实没有方法完善解决，但可以依据不同的业务要求选取不同的方案，例如对体验要求高的业务采纳原生App实现，对体验要求不高的可以采纳Web的方式实现，这就是HybridApp架构的核心设计思想，主要遵循架构设计的"
组件化容器化
HybridApp能够较好的平衡"
两个简单度问题（留意是"
平衡'
，不是"
同时解决'
），但对于一些超级App来说，随着业务规模越来越大、业务越来越简单，虽然在用户看来可能是一个App，但事实上承载了几十上百个业务。
以手机淘宝为例，阿里确认"
战略后，手机淘宝定位为阿里集团移动端的"
航空母舰'
，上面承载了特别多的子业务，下图是淘宝的首页第一屏，相关的子业务初步估量就有10个以上。
再以微信为例，作为腾讯在移动互联网的"
，其业务也是特别的多，如下图，"
发觉'
tab页就有7个子业务。
这么多业务集中在一个App上，每个业务又在不断地扩展，后续又可能会扩展新的业务，并且每个业务就是一个独立的团队负责开发，因此整个App的可扩展性引入了新的简单度问题。
在专栏第32期提到，可扩展的基本思想就是"
拆'
，但是这个思想应用到App和后端系统时，详细的做法就明显不同了。
简洁来说，App和后端系统存在一个本质的区分，App是面对用户的，后端系统是不面对用户的，因此App再怎么拆，对用户还是只能呈现同一个App，不行能将一个App拆分为几十个独立App；
而后端系统就不一样了，采纳微服务架构后，后端系统可以拆分为几百上千个子服务都没有问题。
同时，App的业务再怎么拆分，技术栈是一样的，不然没法集成在一个App里面；
而后端就不同了，不同的微服务可以用不同的技术栈开发。
在这种业务背景下，组件化和容器化架构应运而生，其基本思想都是将超级App拆分为众多组件，这些组件遵循预先制定好的规范，独立开发、独立测试、独立上线。
假如某个组件依靠其他组件，组件之间通过消息系统进行通信，通过这种方式来实现组件隔离，从而避开各个团队之间的相互依靠和影响，以提升团队开发效率和整个系统的可扩展性。
组件化和容器化的架构消失遵循架构设计的"
，只有当业务简单度进展到肯定规模后才适应，因此们会看到大厂应用这个架构的比较多，而中小公司的App，业务没那么简单，其实并不肯定需要采纳组件化和容器化架构。
对于组件化和容器化并没有特别严格的定义，理解两者在规范、拆分、团队协作方面都是一样的，区分在于发布方式，组件化采纳的是静态发布，即全部的组件各自独自开发测试，然后跟随App的某个版本统一上线；
容器化采纳的是动态发布，即容器可以动态加载组件，组件预备好了直接发布，容器会动态更新组件，无需等待某个版本才能上线。
关于手机淘宝App更具体的架构演进可以参考《Atlas：
手淘Native容器化框架和思索》，微信App的架构演进可以参考《微信Android客户端架构演进之路》。
跨平台App
前面介绍的各种App架构，除了WebApp外，其他都面临着同一个问题：
跨平台需要重复开发。
同一个功能和业务，Android开发一遍，iOS也要开发一遍，这里其实存在人力投入的问题，违反了架构设计中的"
站在企业的角度来讲，当然盼望能够削减人力投入成本（虽然站在程序员的角度来讲是不盼望程序员被削减的），因此最近几年各种跨平台方案不断涌现，比较知名的有Facebook的ReactNative、阿里的Weex、Google的Flutter。
虽然也有许多公司在尝试使用，但目前这几个方案都不算很成熟，且在用户体验方面与原生App还是有肯定差距，例如Airbnb就宣布放弃使用ReactNative，回归使用原生技术（
前端的状况也是类似的，有爱好的同学可以看看玉伯的文章《Web研发模式演化》，专栏里就不在赘述了。
小结
今日为你讲了App架构演进背后的缘由和架构分析，盼望对你有所关心。
这就是今日的全部内容，留一道思索题给你吧，你认为App架构接下来会如何演进？
谈谈你的思索和分析。
欢迎你把答案写到留言区，和一起争论。
信任经过深度思索的回答，也会让你对学问的理解更加深刻。
（编辑乱入：
精彩的留言有机会获得丰厚福利哦！
）
升级会员 