WebApp与Native App再战一轮？
文/龙翔历史的车轮Web app向Native app发起挑战已经有好些年了。以各大公司志向宏大的操作系统为例就有：名噪一时现在栖身于 TV的WebOS， 力推在教育领域还算混的不错的ChromeOS， 和主导但是一直雷声大雨点小的Tizen, Mozilla面向低端设备的FirefoxOS。还有各种开发、打包web/hybrid应用的产品：Cordova, Crosswalk，nw.js，Electron。它们也许在各自领域有所成功，但整体的现状和处境很难说web app对native app的世界造成了足够威胁。但Web app也在不断反思和演进，近来一系列技术革新与发展让web app成为操作系统头等公民的目标变得不同以往的清晰。让我们看看“扬长避短”之后的web app是不是真的可以开始跟native app掰掰手腕了。“扬长”Web app之长首先源自web。Web不是于某家藩篱之内的封闭花园，它是一个任意提供了标准支持的终端都可以平等访问的野蛮生长的开放大草原。Web协议栈让全世界的网页成为即时更新并通过URL相互联系的网络。回顾W3C Packaged App(Widget)标准和SysApps(System Application Working Group)的衰落很大程度上也在于放弃了web的这些核心竞争力。Web app之长也源自HTML，CSS，JavaScript。它们虽然招到很多诟病，但它们也是最广泛使用的开发工具。而新的ES6，Web Components标准也在让它们变得具有更强的开发、表达能力。当然HTML的语义话表达也是搜索的基石之一，这让web app易于被索引和发现。“避短”Web app之短首先在于能力的缺失。虽然有Cordova之类工具架起和native API之间桥梁，但打包之后web app的“长”呢？所以web标准化组织一方面在努力提供各种硬件访问的接口。另一方面提出了Service Worker来解决web app本身存在的无法通过简单增加API来处理的关键问题：其一，web app缺少在后台运行的能力，Web Worker可以在后台运行，但是它依赖于页面，不能在页面不存在的时候运行；其二，通过URL访问的web 页面是彼此孤立的，虽然可以通过Web Messaging来相互通信，但是这是一种弱联系，并需要消息传递之间的页面有关联。Service Worker通过一个新的web app编程模型和一套API统一解决了这两个问题。简单的说service worker就是一个生命周期短暂的、事件驱动的后台线程，它处理来自系统和被其控制的页面的事件。目前可以通过Service Worker实现的功能包括：替代坑坑洼洼的Application Cache的可编程离线缓存，Push Notification（消息推送），Background Sync（后台同步）。Service Worker能成为诸多需要跨越页面处理能力的入口。比如如果你怀念Web Intents的话，Service Worker也许也能成为它复活的平台：通过Service Worker注册某个intent事件，在事件到来时worker被启动，针对不同的intent worker可以选择打开不同的页面或重新聚焦某个已经打开的页面。辅助以W3C Manifest标准，web app有了理论上足以超脱浏览器成为系统一部分的能力。Web app之短也在性能。当然性能的问题不在于比较和native app跑分一较高下，而在于用户体验。在JavaScript方面各个浏览器厂商一直在挖掘更高的性能，而近日多个巨头同时参与的Web Assembly的提出更让业界更是充满期望。请想象一下，浏览器直接执行的游戏引擎代码是优化过的二进制中间表达形式(IR)，甚至是可能是缓存下来的后端转换过的机器码。另外在渲染引擎方面，60FPS的性能也一直是近一年来Blink的主要目标，相信Edge、WebKit等也不会被拉在后面。渐进式web app“扬长避短”之后的web app应该以一种怎样的形式进入系统并成为系统一员呢？Alex Russell最近就提出了一种渐进式web app的理念，而且这一理念已经可以在上看到萌芽。在Android Chrome上通过搜索或者链接发现了并使用了某个页面。当这个页面或者某个域范围内的页面在一定时间内被多次访问后，浏览器会认为这些网页是可以被升级成app的，并弹出对话框让用户选择是否安装这个web app到系统。这个web app可以享有和native app类似的权利，比如主界面启动，独立的应用选择栏。目前在Chrome上指定了只有使用了Service Worker 和 Manifest 的网页能够升级成web app被安装，用来保证app的质量。这种渐进式web app的理念在我看来可以用人和人的交往来类比，一个人从陌生，到熟悉，再到相信。展开想象，是不是web app的权限管理也可以渐进呢？ 安全、隐私级别高的API访问控制会随着你对这个app的相信程度来适配。总结各种web操作系统和hybrid打包工具已经向native app主导的世界发起了挑战，随着web技术的进一步成熟，open web也逐渐能通过渐进的方式像native app一样成为系统的一部分。我期望着某一天自由、平等、开放的web能成为开发者的首选平台。
作者：龙翔，现为Intel开源软件中心资深软件开发工程师，从事多年web平台开发，也是Chromium开源项目的Committer。注：本文为作者独立观点，不代表网易科技立场。《易语中的》为网易科技旗下重点打造的专栏作者平台，欢迎投稿！投稿通道:tougao@
本文来源：网易科技报道
关键词阅读：
不做嘴炮 只管约到
跟贴热词：
文明上网，登录发贴
网友评论仅供其表达个人看法，并不表明网易立场。
热门产品:　　　
:　　　　　　　　
:　　　　　　　　　
热门影院：
用微信扫描二维码分享至好友和朋友圈3736人阅读
& & & & & 不管做什么，我们都希望避免重复劳动。而在移动app平台上，存在这两驾马车并驾齐驱的ios和android，并且两个平台使用的语言以及系统的架构都有着明显的差别。而程序员不希望在开发了ios的app之后，又继续开发出android的app，反之也觉得特别不爽。而HTML5的出现似乎给程序员带来了福音，能够只需要一次开发适应不同的移动平台，甚至还能够支持处于摇篮的win
& & & &&基于HTML5的app，实际上是WEB APP，它的跨平台特性确实吸引了不少人，甚至有人喊出了HTML5将统治世界的说法。而实际的用户体验上，大家普遍都认为WEB
APP在目前软硬件环境下，还是不如Native APP。&这其中的原因不管是硬件的配置（很明显android的速度赶不上iphone），还是软件的原因（画面的渲染速度以及网页的解析速度）暂不好说明。但是native app还是有着明显的优点，下面说说根据两个方面说明我们不得不选择Native app的原因：
技术原因：
1.进程切换和互动
不管机器性能和网速怎么样，Native App可以随意切换不同进行，而WEB APP只能通过网页的跳转。
在Native APP中，进程的切换可能只需要250ms，而通过网页的跳转则可能需要两倍的时间。或许一个简单的切换动作，用户不会察觉什么，但是积累起来，那么用户会越来越感觉到应用的缓慢，从而会彻底的抛弃缓慢的应用。例如，native
app的切换效果，很轻松流畅，给用户一种愉快的感觉；而web app的切换只能通过CSS3和JS模拟出来，显然流畅性要差。
而进程间通信，例如我们经常需要在微博中添加图片，在Native app 比较容易实现而且速度快，而用web app则比较麻烦。
2.Natvie APP能够监测外设的情况，而WEB APP无法访问本地的外设
原生的APP可以随意监测、访问设备的外设，比如：USB接口，通讯录，录音设备等一些数据采集设备等等。同时一些作用的临时文件都可以存储在本机种，同时本机存储的文件也可以随意读取的。而WEB
APP是无法做到这些，只能通过保存cookie以及HTML提供的缓存机制来实现。
3.智能应用
通过语音操作，语音设别，复杂一些手势操作（例如摇一摇），这些在native app上轻松实现，而在WEB APP上都是比较困难。
其实设备上提供的很多感应操作，例如陀螺仪，都是只能选择&Natvie APP。
4.网页的快捷方式
web app没有原生APP的支持，是无法把打开指定网页的快捷方式放入启动栏或者桌面的。具体的实现方式可以参考&
5.网络状况
虽然HTML5的离线存储能够一定的解决网络延时问题，不过网络状况对于app来说还是一个非常大的问题。不过比较核心的问题是，即使储存了全部网页显示的数据，JavaScript的执行效率还是没法和本地代码相提并论。
前面说了技术原因，主要是代码执行的效率问题。下面说说非技术原理。
非技术原因
1.盈利模式
如果是web app，那么开发者如何去盈利呢？需要用手机登陆网银，去更多的网站进行充值。很明显，这样子的效率是比较底的。用户还是希望能够在app store里面进行安全的付费。通过苹果也希望在自己这里进行交易，这样即能保持自己的用户忠诚度，又可以避免第三方交易带来的纠纷。
2.用户习惯
用户对于原生的app比较信赖，而对于web app则有种天生的恐惧感，担心自己密码会在web 应用中被盗。并且对于用户来说，根据1984年的麦金塔GUI多年以来给大家装下的观念，真正的软件就是那种自己单独一个窗口（而不是一个标签页），单独一个图标（而不是诸如Firefox图标中的一个）的东西。这种使用习惯和信任也是人心里认知上的一个壁垒。
3.政策原因
对于更外的一些优秀的应用，在国内随时会有被墙掉的可能，而Native APP则完全不会。
说了这么多，我们不禁要怀疑web app的前景是否光明了。但是不管怎么说WEB APP是趋势，&就像伟大的精神导师马先生说的：一旦有适当的利润，资本家就会大胆起来。有百分之五十的利润，它就铤而走险；为了百分之一百的利润，它就敢践踏一切人间法律；有百分之三百的利润，它就敢犯任何罪行，甚至冒绞死的危险。而web
app 能够减少工作量，这对于移动互联网的至高境界“天下武功，唯快不破”不谋而合。所以web app随着发展还是有发展空间的。现在的舞台是属于Native APP，将来一段时间是WEB APP和 Native APP的融合的舞台，结合他们能够减少开发量，扬长避短，未来会是web
更多关于web app和native app的问题可以一起讨论，也可以参考下面的文章：
web app vs. native app
Web App和 Native App，哪个是趋势？
跨平台手机应用开发
Native APP 和 WEB APP 在用户体验上的差别
http://chenxiang5789407./blog/static//
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：828597次
积分：7909
积分：7909
排名：第2014名
原创：123篇
转载：35篇
评论：65条
(2)(2)(5)(8)(1)(1)(1)(1)(1)(1)(1)(4)(2)(5)(3)(12)(6)(8)(24)(26)(17)(33)轻应用、Web App、Native App三者有什么区别？
我的图书馆
轻应用、Web App、Native App三者有什么区别？
首先，先说说我们现在正在使用，大家都了解的Native App。
一、什么是Native app
Native App是一种基于智能手机本地操作系统如IOS、Android、WP并使用原生程式编写运行的第三方应用程序,也叫本地app。
Native App因为位于平台层上方，向下访问和兼容的能力会比较好一些，可以支持在线或离线，消息推送或本地资源访问，摄像拨号功能的调取。其实也就是我们现在使用的基于本地（Andriod\IOS\Metro）运行的APP。
Native App的优势：
1.提供最佳的用户体验，最优质的用户界面，最华丽的交互2.针对不同平台提供不同体验3.可节省带宽成本4.可访问本地资源5.盈利模式明朗
Native App的劣势：
1.移植到不同平台上比较麻烦2.维持多个版本的成本比较高3.需要通过store或market的确认4.盈利需要与第三方分成
其实，只要现在从事移动互联网的CP们，能深深体会到目前原生应用遇到的三大困境：1、虽然用户手机里的Native APP数量在增多，但日均启动个数却在减少；2、用户的使用时长不断向高频Native APP集中，加剧了头部效应；3、对于低频和不知名的Native App，则面临着更严峻的“分发”和“使用”长尾困境。这三大困境对开发者形成了较大的挑战。其中，大部分低频和不知名Native App在应用商店少人问津，无法到达用户手机。
二、什么是Web app
Web无需安装，对设备碎片化的适应能力优于App，它只需要通过XHTML、CSS和JavaScript就可以在任意移动浏览器中执行。随着iPhone带来的WebKit浏览体验升级，使得专为iPhone等有WebKit浏览内核的移动设备开发的Web应用，也有了如App一般流畅的用户体验。（就是一种基于浏览的应用，技术咱就不管了）。
Web App的优势：
1.开发成本低2.适配多种移动设备成本低3.跨平台和终端4.迭代更新容易5.无需安装成本
Web App的劣势：
1、Web App自身能力不全面2、无法调用语音、摄像头、定位等能力，体验比较差；3、用户很难沉淀下来，建立较为稳固的联系。
针对Native app 和 web app的分析，应该也可以大概理解出什么是轻应用了吧！~一般在这种情况下，就会出来另外的一种概念叫融合。记得，曾经乔布斯老爷子有一次谈到这个问题，他说Web是未来，虽然现阶段Native给了用户更好的体验。如果现在的开发者不有效的利用Web技术，那他就落伍了。但如果过分依赖Web，完全不用Native那也未必就是好事。
三、什么是轻应用？
轻应用是无需下载、即搜即用的全功能 App，既有媲美甚至超越native app的用户体验，又具备webapp的可被检索与智能分发的特性，将有效解决优质应用和服务与移动用户需求对接的问题。2013年 8月22日，百度在2013年百度世界大会上宣布推出“轻应用”，可实现无需下载，即搜即用和通过移动搜索智能分发。（注：其它早前360就提出过轻应用概念，更可笑的是当天老周在微博上发了这么一句话：一个认为移动互联网是酒驾的兄弟，一直找不到方向，所以跟在360屁股后面。原谅这个醉汉吧！~至少是否抄袭不是咱关心的事儿，继续捋该捋的！~~~）
轻应用的特点：
1、破壳检索，智能分发简单理解就是通过之前应用商店以名称进行检索的方式，现在可以更精确的通过内部内容来匹配搜索，实现长尾搜索。2、无需下载，即搜即用无需安装，节省存储空间，使用方便，简直轻得不能再轻。3、订阅推送，个性提醒帮助用户不搜即得，获得个性化服务。举个简单例子吧：你关注了'91运营网“，而91运营网的内容主要是针对移动互联网的，你在关注这些阅读应用自媒体的时候设置条件是移动互联网的新闻时，那91运营网就有可能被推送。4、云端一体，能力增强提供了多种增强能力：LBS、语音输入输出、订阅推送、电话拨打、摄像头调起、分享评论等。
总之，针对轻应用来说，就好比web app native app的另一种解决方案。“轻应用”无需下载、即搜即用，既有类似Native App的用户体验，又具备Web App可被检索与智能分发的特性，可解决优质应用和服务与移动用户需求对接问题，这无疑满足了移动搜索的需求。在这里，更关注的其实是能不能通过“轻应用”，让我们这些没有预算的苦逼们，让我们那些使用率低的应用，用户无需下载就可以通过长尾搜索到相应应用，破壳精确的到达用户手机。能不能不被那些巨头app压制，形成头部效应。让我们低频的app也能崭露头脚，让我们这些cp们不用看store或market的嘴脸，来一下霸气侧露呢？！~
发表评论：
TA的最新馆藏}