49 | 谈谈App架构的演进
该思维导图由 AI 生成,仅供参考
Web App
- 深入了解
- 翻译
- 解释
- 总结
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-18682 - 江龙有个api的设计原则问题最近困扰好久,请教下,就是图中的首页其实有多个资源聚合,那是应该app端去请求多个资源服务,然后聚合出来展示;还是有个后台服务去聚合后端的各个基础服务,然后只提供一个接口给app访问?这其中的粒度如何把握?
作者回复: 访问量大的,核心业务用服务器聚合,性能好; 访问量小的,非核心业务用app聚合,可扩展性好;
2018-09-03268 - kyll其实,对于现在很多业务应用强制将用户绑到移动端很是反感。举个例子,第一次用丰巢寄件,竟然花了半小时,注册很麻烦。有些餐厅强制手机点餐,在pc端登录强制扫二维码,也很无语。多设备多渠道本质应该是为了方便快捷,随时随地享用服务。任何设备都有局限性,做好自己的本职即可。
作者回复: 我也有点反感😊
2018-08-18318 - feifei我认为这个演讲也是朝着 all in one,即平台统一化,在app与原生接口间会出现统一化一个技术,类似java与jvm 原因: 1,原生开发成本高,每个平台都需要专门的开发人员 2,手机性能的提高,能够为平台统一化提供条件 3,用户体验,苹果的生态封闭,体验相对较好,但安卓平台很多公司都封装一套 导致体验差异很大
作者回复: 英雄所见略同😄
2018-08-20316 - borefo一个系统架构设计出来后,如何预估这个系统能够支撑多大的请求量呢?
作者回复: 不是先预估请求量,再设计架构么?
2018-08-1814 - 木得感情的编码机器曾经做过一个移动端社交项目,开始就是用react native 开发的,但是工程里还是用了些原生的库和代码,而且是IM和拍照美化这两个核心功能。所以开发时既要边学边写原生代码,还要写RN,而且一旦RN在真机上报错,debug就是一头包。项目内测时就发现了RN光启动什么也不干就用掉了100多M内存,而且拍照美化是原生加RN,性能非常差。 内测之后就抛弃了RN,两个程序员很快就把安卓和苹果两个原生版本做出来了,因为很多原生代码可以复用,而且原生也有很好的开发框架和模式,调试非常方便和清晰。 我总结一下,是否用跨平台的方案取决于业务。如果做资讯类,信息聚合类,电商类对性能不苛求的项目,用RN这类东西完全可以。如果是游戏类,协同工具类,拍照视频类这些对性能有极高要求的,还是得用原生去开发,必要时也可以配合H5混合实现活动、任务、促销等业务。 未来前端的发展肯定是越来越复杂的,但要出现真正大一统跨平台开发框架还是需要很长一段时间,但是我这个东西一定是出至谷歌或苹果,而不会是FB或者其他大厂。现在有flutter ,但是说不准哪天swift 也能写安卓。
作者回复: 很好的案例
2020-07-199 - Niuniu我的观点可能有点相反,但凡有人上来要做native app的时候,我一般都劝退不劝进。先仔细想想你需要的那些功能WebApp能不能实现,用户体验有没有差很多,没有的话,没必要做native app。能上webapp,先上webapp,人手不够时间紧,可以考虑hybrid,实在是非native app不可,才考虑写native的。
作者回复: 赞同,新APP首要是快速验证业务,不是体验
2019-01-167 - 大鹏架构设计首先要掌握业界已经成熟的各种架构模式,然后再进行优化、调整、创新。——这句话点拨了我,我自己在工作当中,往往忽略了这一点。事实大家都知道,但架构的原则会避免我们钻牛角尖
作者回复: 架构原则除了避免钻牛角尖,还可以帮助你做架构决策
2021-01-194 - Monday分久必合,安卓和IOS终将大一统为跨平台 App
作者回复: 我看好H5,因为性能劣势被硬件的飞速发展弥补了,现在的App开发基本都是Native + H5,Native做底层,H5做业务
2020-10-204 - H有一个疑问,虽然在这节中提问不太合适哈哈哈。 疑问:如果一次mysql查询中,涉及到7-8个表的联合查询。就是join查询。除了暴力查询方法外,有没有其他办法?比如合表,把多个字段数据合在一起,放在一个表中。这样子可以吗?如果不对,望作者指正
作者回复: 可以的,这个叫做反范式设计,可以用在一些特殊场合,但不推荐普遍使用,因为数据库针对join做了非常多的优化,只要你的表设计没问题,join的性能是很高的
2020-05-084