从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152573 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

49 | 谈谈App架构的演进

动态发布
静态发布
解决快速开发和低成本问题
需要掌握业界成熟的架构模式
架构设计需要遵循合适、简单、演化原则
架构设计的目的是解决复杂度问题
架构是系统的顶层结构
App架构的未来演进
React Native、Weex、Flutter
解决跨平台重复开发问题
容器化架构
组件化架构
解决超级App的可扩展性问题
根据业务要求选择不同方案
平衡用户体验和快速开发
开发成本较高
解决用户体验问题
包壳架构
架构设计关键点
思考题
跨平台App
组件化 & 容器化
Hybrid App
原生App
Web App
App架构演进

该思维导图由 AI 生成,仅供参考

专栏截止到上一期,架构设计相关的理念、技术、实践已经基本讲完,相信你一路学习过来会有一种感觉,这些内容主要都是讲后端系统的架构设计,例如存储高可用、微服务、异地多活等,都是后端系统才会涉及。事实上确实也是如此,通常情况下我们讲架构设计,主要聚焦在后端系统,但这并不意味着 App、前端就没有架构设计了,专栏所讲述的整套架构设计理念,虽然是来源于我的后端设计经验,但一旦形成完善的技术理论后,同样适应于 App 和前端。
首先,先来复习一下我的专栏所讲述的架构设计理念,可以提炼为下面几个关键点:
架构是系统的顶层结构。
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
架构设计需要遵循三个主要原则:合适原则、简单原则、演化原则。
架构设计首先要掌握业界已经成熟的各种架构模式,然后再进行优化、调整、创新。
复习完我们就可以进入今天的正题,我来谈谈 App 架构的演进,以及上面这些架构设计关键点是如何体现的。

Web App

最早的 App 有很多采用这种架构,大多数尝试性的业务,一开始也是这样的架构。Web App 架构又叫包壳架构,简单来说就是在 Web 的业务上包装一个 App 的壳,业务逻辑完全还是 Web 实现,App 壳完成安装的功能,让用户看起来像是在使用 App,实际上和用浏览器访问 PC 网站没有太大差别。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

App架构的演进是一个持续适应业务和技术发展的过程。从最早的Web App采用包壳架构,到原生App成为主流,再到Hybrid App架构的出现,以及组件化和容器化架构的应用,每一次演进都反映了架构设计的关键原则。随着移动应用的不断发展,架构设计也在不断演进,以适应不断变化的业务需求和技术发展。 除了Web App外,其他App架构都面临着跨平台需要重复开发的问题。为了减少人力投入成本,各种跨平台方案不断涌现,如Facebook的React Native、阿里的Weex、Google的Flutter。尽管这些方案在尝试使用中,但目前仍不算很成熟,且在用户体验方面与原生App还存在一定差距。因此,App架构的跨平台问题仍需要进一步探索和解决。 在前端领域,类似的情况也存在。跨平台方案的发展需要更多的技术突破和实践经验积累,以缩小与原生App的差距,提升用户体验。未来,App架构可能会朝着更成熟、更稳定的跨平台方案发展,同时也会注重提升用户体验和开发效率。随着技术的不断进步和应用场景的拓展,App架构的演进将继续适应业务和技术发展的需求。 总之,App架构的演进是一个不断探索和适应的过程,未来的发展方向将更加注重跨平台方案的成熟和用户体验的提升。随着技术的不断发展,App架构设计也将持续演进,以满足不断变化的业务需求和技术发展。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(36)

  • 最新
  • 精选
  • 李奋斗
    端上的技术,山上的天儿,都变得太快。端上的架构怎么演进?我觉得要把答案交给想象力,把时间尺度拉大看,想象力才是端上复杂度的主要来源,交互革命和场景升级是端技术栈发展的重要推动力。鼠标的发明,颠覆了命令行的交互思维,iphone的问世,分分钟让习惯了上屏下键的人们大开眼界,手机和网络的突进,解锁了一堆令人兴奋的场景。VR,混合现实,AI,5G等技术都可能极大推进端技术的变革,未来端架构怎么演进?不清楚,但有一点是清晰的,一大波复杂度,就在路上。

    作者回复: 学不动了😂😂😂

    2018-08-18
    6
    82
  • 江龙
    有个api的设计原则问题最近困扰好久,请教下,就是图中的首页其实有多个资源聚合,那是应该app端去请求多个资源服务,然后聚合出来展示;还是有个后台服务去聚合后端的各个基础服务,然后只提供一个接口给app访问?这其中的粒度如何把握?

    作者回复: 访问量大的,核心业务用服务器聚合,性能好; 访问量小的,非核心业务用app聚合,可扩展性好;

    2018-09-03
    2
    68
  • kyll
    其实,对于现在很多业务应用强制将用户绑到移动端很是反感。举个例子,第一次用丰巢寄件,竟然花了半小时,注册很麻烦。有些餐厅强制手机点餐,在pc端登录强制扫二维码,也很无语。多设备多渠道本质应该是为了方便快捷,随时随地享用服务。任何设备都有局限性,做好自己的本职即可。

    作者回复: 我也有点反感😊

    2018-08-18
    3
    18
  • feifei
    我认为这个演讲也是朝着 all in one,即平台统一化,在app与原生接口间会出现统一化一个技术,类似java与jvm 原因: 1,原生开发成本高,每个平台都需要专门的开发人员 2,手机性能的提高,能够为平台统一化提供条件 3,用户体验,苹果的生态封闭,体验相对较好,但安卓平台很多公司都封装一套 导致体验差异很大

    作者回复: 英雄所见略同😄

    2018-08-20
    3
    16
  • borefo
    一个系统架构设计出来后,如何预估这个系统能够支撑多大的请求量呢?

    作者回复: 不是先预估请求量,再设计架构么?

    2018-08-18
    14
  • 木得感情的编码机器
    曾经做过一个移动端社交项目,开始就是用react native 开发的,但是工程里还是用了些原生的库和代码,而且是IM和拍照美化这两个核心功能。所以开发时既要边学边写原生代码,还要写RN,而且一旦RN在真机上报错,debug就是一头包。项目内测时就发现了RN光启动什么也不干就用掉了100多M内存,而且拍照美化是原生加RN,性能非常差。 内测之后就抛弃了RN,两个程序员很快就把安卓和苹果两个原生版本做出来了,因为很多原生代码可以复用,而且原生也有很好的开发框架和模式,调试非常方便和清晰。 我总结一下,是否用跨平台的方案取决于业务。如果做资讯类,信息聚合类,电商类对性能不苛求的项目,用RN这类东西完全可以。如果是游戏类,协同工具类,拍照视频类这些对性能有极高要求的,还是得用原生去开发,必要时也可以配合H5混合实现活动、任务、促销等业务。 未来前端的发展肯定是越来越复杂的,但要出现真正大一统跨平台开发框架还是需要很长一段时间,但是我这个东西一定是出至谷歌或苹果,而不会是FB或者其他大厂。现在有flutter ,但是说不准哪天swift 也能写安卓。

    作者回复: 很好的案例

    2020-07-19
    9
  • Niuniu
    我的观点可能有点相反,但凡有人上来要做native app的时候,我一般都劝退不劝进。先仔细想想你需要的那些功能WebApp能不能实现,用户体验有没有差很多,没有的话,没必要做native app。能上webapp,先上webapp,人手不够时间紧,可以考虑hybrid,实在是非native app不可,才考虑写native的。

    作者回复: 赞同,新APP首要是快速验证业务,不是体验

    2019-01-16
    7
  • 大鹏
    架构设计首先要掌握业界已经成熟的各种架构模式,然后再进行优化、调整、创新。——这句话点拨了我,我自己在工作当中,往往忽略了这一点。事实大家都知道,但架构的原则会避免我们钻牛角尖

    作者回复: 架构原则除了避免钻牛角尖,还可以帮助你做架构决策

    2021-01-19
    4
  • Monday
    分久必合,安卓和IOS终将大一统为跨平台 App

    作者回复: 我看好H5,因为性能劣势被硬件的飞速发展弥补了,现在的App开发基本都是Native + H5,Native做底层,H5做业务

    2020-10-20
    4
  • H
    有一个疑问,虽然在这节中提问不太合适哈哈哈。 疑问:如果一次mysql查询中,涉及到7-8个表的联合查询。就是join查询。除了暴力查询方法外,有没有其他办法?比如合表,把多个字段数据合在一起,放在一个表中。这样子可以吗?如果不对,望作者指正

    作者回复: 可以的,这个叫做反范式设计,可以用在一些特殊场合,但不推荐普遍使用,因为数据库针对join做了非常多的优化,只要你的表设计没问题,join的性能是很高的

    2020-05-08
    4
收起评论
显示
设置
留言
36
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部