对Native App与Web App的一些思考

浏览数：33 / 时间：2015年06月11日

前言

　　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。大致分析其原因，可总结为以下几点：

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

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

认清自己的位置

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