对Native App与Web App的一些思考

时间:2021-06-21 13:02:06

前言

  Native App:C/S架构,使用原生技术(Java/Objective-C/Swift)实现。

  Web App:B/S架构,使用浏览器技术来实现,广义上也包括phoneGap以及DP正在尝试使用的EFTE框架。

  在PC上,轻量级的应用多是B/S架构,具有轻便、速度快、无需安装、易于版本控制等优点,这种思想运用到极致就是用浏览器充当操作系统(Chromium OS)。在手机上,由于网络流量、屏幕适配、机能限制等种种原因,C/S架构的Native App目前仍然是主流。因为本blog主要专注于移动开发,下面就移动平台上,两种app的优劣做一下简单的总结,个人拙见。

Web App 的不足

  相比于原生,移动平台上的Web App应用并不是十分广泛,打开应用商店,排在前十名内并无一只严格意义上的web app。大致分析其原因,可总结为以下几点:

  1. 移动网络环境的限制。传输速度慢、不稳定、资费昂贵,这些是目前中国大部分地区移动网络的现状。相较于原生应用,web app往往需要更大的流量,所达到的渲染效果却很一般。对移动应用而言,加载速度慢是致命要害。在用户体验至上的考虑下,大部分厂商都会选择native作为实现方式。
  2. 设备本身性能有限。这一点在低端android机上尤其明显,CPU、内存、存储器、图像处理能力与PC机相比,差距是相当大的。这一点反映到用户体验上,同样是不可接受的速度拖慢。而native实现则可更多利用移动平台底层API接口,作出相应的优化。
  3. 相较于浏览器,native更容易实现一些酷炫的交互。如传感器、动画、定位、陀螺仪、拍照、录音……
  4. 移动平台碎片化严重,屏幕尺寸、分辨率千差万别,导致相同的页面放在大屏手机上展示正常,在小屏幕手机上却莫名其妙地发生换行,视觉效果糟糕,影响用户体验。而native则在适配上提供了一些措施,减少了适配方面的工作量。
  5. 同样是出于网络限制,浏览器不易于控制图片等大文件的缓存,浪费流量且加载速度慢,native可以*制定缓存策略,且有sqlite等工具做数据存储。

  web app的不足,从另一角度讲,就是native app的优势所在。如果对以上5点进行分类的话,随着4G与wifi的普及,1、2在可以预见的未来里,相信会有一定改善,3、4两点恐怕需要相当的时间与努力,才可能完全克服。尤其是碎片化这点,加之GFW这一绊脚石,直接让谷歌统一android系统进入到困难模式。

Web App 的希望

  我是中国dota的希望尽管以上诸多方面表明,在十年(?)内,native仍旧会是主流,但web app仍然延续了PC时代一贯的优点,在一些场合,可以作为优于native的解决方案。下面也简单总结一下web app的闪光之处:

  1. 便于维护、升级。之所以把这个排在第一,是因为深受efte荼毒。每一次DP的app提交审核,都要冒着被App Store打回的风险,幸好天朝无需提Google play审核,不然android版本恐怕也要提心吊胆来发布了。efte则很好解决了这个问题,在后台更新相关模块的jar包后,前端无需提升版本,即可下载新功能使用。据说微信游戏也是类似的实现,没有研究过,不可妄下结论。不过站在用户的角度,隔三差五需要升级各种客户端,也是相当苦恼的,尤其是在没有wifi的环境下。
  2. PC时代,Trident/Gecko/KHTML/WebKit 等内核群雄逐鹿的场面,让不少前端工程师头痛不已。而在移动互联网时代,html、css、javascript技术,保持了高度一致。通过这些技术,可以消除移动平台的差异,作出一套东西同时运行在iOS与Android系统上。(感觉要失业的节奏)
  3. html5、css3等技术的发展与普及,为web app提供了更多的可能性。

认清自己的位置

  native也好,web也好,两者之间并不是谁取代谁,而是彼此协作相辅相成的关系。对于一名前端(客户端)工程师来讲,要吃透两个中的任何一个,都不是一朝一夕能够完成。学习的过程,更多的是一种提高自己学习能力与解决问题能力的过程,如同乐器,知识在某种程度上也都是相通的。想起前几天读过一段话,颇为有趣:人们总说小孩子学起东西来要比成年人快,也许是因为,小孩子在学习一项技能时,往往是一门心思日复一日去做,很少去考虑,这个东西我学了一周后就能掌握吗?一个月后就可以熟练吗?引以自勉。

参考资料

  1. web前端工程师在移动互联网时代里的地位问题 by 夏天的森林