Web App 和 Native App，哪个是趋势？_web的体验为啥不如本地-CSDN博客

前两天刚好和一帮产品同学聊过，特指一个APP里面的各页面应该怎么做，大家的总结如下，原理一样，关键是了解Native和Web各自的优劣势：
1. 偏交互的Native，偏浏览的Web：交互指复杂操作，输入/选择什么的
2. 已稳定的Native，试错中的Web：H5页面用来做低成本验证很好
3. 访问硬件Native，信息展示Web：指手机里的各种传感器什么的
4. 核心功能Native，周边辅助Web：把工作量多投在刀刃上
5. 当时有5点，我实在想不起来了。。。

编辑于 2015-01-06 26 条评论感谢收藏 • 没有帮助 • 举报 • 申请转载

连长王江“最好的产品经理”，没有之一

203 人赞同

我是公司的CEO，但同时也是航班管家的产品经理，让我用这个目前市场上占有率最大的手机商旅应用来做个例子，说明一下我们是如何考虑web app和native app的： 1）两大核心功能：机票查询和航班动态，全部是native app，主要是为了保证速度和稳定性，因为这时… 显示全部

我是公司的CEO，但同时也是航班管家的产品经理，让我用这个目前市场上占有率最大的手机商旅应用来做个例子，说明一下我们是如何考虑web app和native app的：

1）两大核心功能：机票查询和航班动态，全部是native app，主要是为了保证速度和稳定性，因为这时候的用户对效率很敏感。

2）辅助的服务功能：我们还提供诸如“机场登机口导航”、“机场商家地图”、“航空公司服务”以及“酒店查询”等功能，这些功能由于暂时不是用户的最基本需求，同时在业务上调整和增加的内容要求很灵活，所以我们采用内嵌web网页的方式来实现，将用户引导进入我们自己和其它第三方的网站里。这些功能都统一放在“实用工具”的分类里。

3）创新型功能：在一季度末，航班管家会推出“机场漂流瓶”以及“航班同乘人”等准社区服务，这都是基于web，并已经开始采用html5的一些方法，希望能够达到两个目的：在体验上接近native app，开发上具备更多的灵活性和跨平台性。

综上，作为一个移动互联网的应用开发商，我们更倾向于看重以html5为未来的趋势！

发布于 2011-02-13 21 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

米嘉怪兽工程师

26 人赞同

Web App从实现角度是不是可以分为几种：直接使用移动设备浏览器使用；使用本地封装Embed Browser来调用Web接口使用Web技术（HTML，JavaScript，CSS）直接构建本地应用从这个角度讲，后两种很难分清Web和Native的区别，由于HTML5的支持以及现在JavaScript/C… 显示全部

Web App从实现角度是不是可以分为几种：

直接使用移动设备浏览器使用；
使用本地封装Embed Browser来调用Web接口
使用Web技术（HTML，JavaScript，CSS）直接构建本地应用

从这个角度讲，后两种很难分清Web和Native的区别，由于HTML5的支持以及现在JavaScript/CSS/DOM等性能和稳定程度越来越高，他们的表现不一定会跟Native差别太大。

从开发者的角度来看，他们对技术的选择还是要依赖于自己的习惯、开发经验和工具，而基于Web技术的开发工具和各种lib也在完善中。而最关键的是，使用Web技术最大的好处就是跨平台。

话说回来，跨平台和Native也一直是争论的焦点，:)

发布于 2011-02-11 3 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

知乎用户产品人，爱好广而不精，充满好奇心

38 人赞同

总的来说，融合是趋势。但目前来说，Native app仍然是高品质产品的首选。就好像Facebook iOS版本的开发者Joe Hewitt说的： “I want desperately to be a web developer again, but if I have to wait until 2020 for browsers to do what Cocoa can do in… 显示全部

总的来说，融合是趋势。但目前来说，Native app仍然是高品质产品的首选。
就好像Facebook iOS版本的开发者Joe Hewitt说的： “I want desperately to be a web developer again, but if I have to wait until 2020 for browsers to do what Cocoa can do in 2010, I won’t wait.”(我十分想再一次成为Web开发者，但是如果浏览器到2020年才能做到Cocoa2010年就能做到的事儿，我不愿等待。)

编辑于 2011-02-14 5 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

HokaDesigner 公众号/播客：UX Coffee

68 人赞同

最近正好在讨论这个问题，如果资源、时间充足的话，我们会想要既有native app，又有web app。但很多时候因为资源有限，PM不得不在两者中优先一个。这篇文章（ lukew.com 的页面）比较宏观地分析了两者在数据上的表现，一句话总结： Web能够reach到更多的用… 显示全部

最近正好在讨论这个问题，如果资源、时间充足的话，我们会想要既有native app，又有web app。但很多时候因为资源有限，PM不得不在两者中优先一个。

这篇文章（ lukew.com 的页面）比较宏观地分析了两者在数据上的表现，一句话总结：

Web能够reach到更多的用户，但是native能给予更好的体验，用户黏性更强。

我们来看一下数据。

Mobile web的月UV领先mobile app（8.9M vs. 3.3M）：
&lt;img src="https://i-blog.csdnimg.cn/blog_migrate/c77d762ea4d2cfd5290f65fb3de6d284.png" data-rawwidth="1500" data-rawheight="777" class="origin_image zh-lightbox-thumb" width="1500" data-original="https://pic3.zhimg.com/85596129809131dc20371491e4acb9ee_r.png"&gt;

Native app用户每个月花的时间是mobile web用户的18倍（201.8分钟 vs. 10.9分钟）。不过要注意， native app的使用时间里，有近80%是花在了某3个app上。所以也要考虑自己的产品有没有潜力进入top3，还是会是在长尾里，去跟许许多多的app竞争那剩下的40分钟（201.8分钟*20%≈40分钟）。

&lt;img src="https://i-blog.csdnimg.cn/blog_migrate/05110facf72d6bc944ed282ec67b9034.png" data-rawwidth="1500" data-rawheight="777" class="origin_image zh-lightbox-thumb" width="1500" data-original="https://pic2.zhimg.com/9d3f7562e477b4388beb3ef5721b6891_r.png"&gt;

&lt;img src="https://i-blog.csdnimg.cn/blog_migrate/dae494440753e9e0f301451ab097530e.png" data-rawwidth="617" data-rawheight="324" class="origin_image zh-lightbox-thumb" width="617" data-original="https://pic4.zhimg.com/8fa03a8a0f42b2bf0396852b67b69e93_r.png"&gt;

接下来看功能和成本，mobile web和native app算是各有千秋。先说说Mobile web的优势：

搜索引擎入口。苹果的app store搜索众所皆知不好使，Google play store或者其他第三方的安卓商店我不是很了解，但如果一个产品是内容主导的，可能很多流量是来自搜索引擎，这也可能是mobile web访问量更多的原因之一。

即时更新。如果做native app的话，每次版本更新从审核、上架到用户更新是有一个时间间隔的，很有可能用户懒得更新，就一直运行着一个很久很久以前的版本，接触不到新版本里的功能。如果ship的版本有问题的话，大量用户可能直接就流失了，不像mobile web，有比较快的补救的可能。所以一般来说，mobile native ship的标准会更高。

设计和开发成本。Native app要为不同的平台进行设计和开发，有不同的规范和语言，mobile web在这方面的工作量会小很多。

Native app的优势：

可以调用web不能调用的硬件、或者有更好的硬件体验，比如：
- 摄像头
- 麦克风，前两者现在html5均可调用，但是体验不如native，而且跨浏览器兼容性也比较麻烦
- 加速度传感器
- 屏幕（常亮）

如果有产品的核心功能会涉及这些硬件，为了更好的用户体验和留存率，可能需要开发native app。

可以使用一些非常重要的OS功能，比如
- 推送通知，不过要注意的是，31%的用户几乎从来不允许app给他们推送通知

&lt;img src="https://i-blog.csdnimg.cn/blog_migrate/242722d304b26ab7765463d5bae2c20d.png" data-rawwidth="608" data-rawheight="290" class="origin_image zh-lightbox-thumb" width="608" data-original="https://pic2.zhimg.com/756b563131a93c064c1767a39d9b5219_r.png"&gt;

但也要看具体是什么app，比如Uber之类的ride sharing app就比较容易获得用户的允许（数据来自：New data shows up to 60% of users opt-out of push notifications (Guest Post) at andrewchen）

&lt;img src="https://i-blog.csdnimg.cn/blog_migrate/0c287c4e30ec443f8fe238aa6b3e4039.png" data-rawwidth="600" data-rawheight="371" class="origin_image zh-lightbox-thumb" width="600" data-original="https://pic1.zhimg.com/aba6e69df9ef4e706b13c0d10a8e397c_r.png"&gt;

获取用户的地理位置：相比推送通知，用户对地理位置使用的接受度还是比较高的

&lt;img src="https://i-blog.csdnimg.cn/blog_migrate/c5dc21c2f057fdfcc6277d3b099dc83c.png" data-rawwidth="624" data-rawheight="298" class="origin_image zh-lightbox-thumb" width="624" data-original="https://pic3.zhimg.com/efc4de2676276bee82af991f21d196e6_r.png"&gt;

离线使用：如果你的产品涉及到大量视频和图片，在国内流量有限的现状下，可能需要允许用户将媒体文件保存到手机上，以供离线使用，这时候web就爱莫能助啦

个性化内容：这一点比较有争议，因为mobile web也不是不可以做到，但因为app可以不用反复登陆，而且能够记录用户的点击和浏览行为，所以可以更准确地进行内容定制，这一点期待有更多的讨论~。

另外， native app相比web，有着更快的反应速度、更好的性能，因为mobile native直接与操作系统对话，而web app和操作系统之间还隔着一层浏览器。

总结：如果你想做一个企业名片之类的东西，让更多人知道自家产品，那也许一个网站就够了；但如果产品核心功能只有native app才能提供，或者你想要确保用户有更好的体验、更强的黏性，那可能就需要做native app。

*引用的文章数据来自ComScore《The 2015 U.S. Mobile App Report》，有兴趣的话可以去看看，56页的ppt，信息量很大。

编辑于 2016-06-01 5 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

小郑

63 人赞同

2016年快要结束了，现在，更多的PC客户端程序开始将原生界面做成页面，这真的是一个趋势。客户端将复杂的定制化的接口导出给页面，页面在快速开发界面的同时也能够使用所有功能。之前我所经历的事情过于局限于移动端，如今PC端将会率先将Native和Web融合app… 显示全部

2016年快要结束了，现在，更多的PC客户端程序开始将原生界面做成页面，这真的是一个趋势。客户端将复杂的定制化的接口导出给页面，页面在快速开发界面的同时也能够使用所有功能。之前我所经历的事情过于局限于移动端，如今PC端将会率先将Native和Web融合app发扬光大，很快，微信小程序应该也会引爆一波移动端上这种做法的潮流。

---------------------一年前的回答--------------------------------------
已更新完成，最近做了一个纠结了这个问题很久的项目。

项目是做H5游戏的平台，然后是上头领导的点子，所以也就下头跟着尝试做做看，不行就撤，这不，4次迭代就无限期暂停了这个项目。

一说到Web App就不得不说到H5，当H5出来的时候Web App才有的说。13年下半年还去参加了H5峰会，请了好多大公司的人来上台讲解H5是多么多么好，百度的工程师还现场为我们演绎了一个神奇的Web App，不得不说如果App这么做，很多工作都可以从中解放出来了。虽然有各种专家出来演讲，但是场内的气氛一直都不是很活跃，最后到了抽大奖（乐视TV和各种平板）的时候才开始火爆起来 = =。

所以即使是那么多专家在上面巴拉巴拉不停的说H5多么多么牛，但是大家仍然感受不到H5的好，仍然很迷茫，甚至我都觉得上面演讲的都有一些迷茫，这种迷茫度过了2013，走过了2014，迎来了2015。

为什么迷茫呢？

其实就是H5每天都在鼓吹的那些东西实际上到底有没有落地实现，这个有很大很大的一个疑问。这种情况一般开发者都只会做一个demo玩玩而已。另外一个就是性能，说到底，为什么现在APP仍然是Native大行其道？即使很多产品本来就有页面的，比如知乎，但是他还是要做客户端原生的App，为什么呢？原因还是Web App的体验不好，或者说小的效果，普通的东西可以实现，但是稍微要求高一点的东西性能就下去了。

举个例子，在原生的App上，一个类似页面滑动切换的效果，Native上，反应时间绝对是毫秒级别，不会感受到延迟，你手指只要开始滑动，页面就无缝的跟着滑动，但是Web呢？大家应该都经常去看微信里面各种H5的花哨分享页面吧，那个滑动能神流畅吗？反正我的小米就不行。

这只是一个小点，如果说整个应用都用H5来实现，那么很多基础的组件会遇到这种情况。很典型的是，一个按下态的效果，原生的效果是你按到了一瞬间就会显示，没有延迟，但是Web的往往会有肉眼可见的延迟，这一点带给用户的就是感觉这个按钮“很黏”，点的感觉不好。

再有就是有些特效再花哨一点，那么Web就吃不消了，这一点更加放大就是Native的游戏和H5游戏的对比，到现在，H5游戏还是只能做很简陋的游戏，而Native已经可以完爆H5了。这也是为啥会存在Egret这个H5用的游戏引擎，其加速的核心思想就是把Web的绘制转换为Native的绘制。当然这里说的是App，默认题主想问的是轻量级的而不是游戏，游戏也没啥好说的，性能一栏就卡死了。

除去上面几点，还有一点是开发者的心腹大患。你页面写东西快了，爽了，开发效率高了，但是这些东西都是浏览器在跑，很多东西不受你的控制，比如说你要定制缓存机制，对不起，浏览器没那么高级的缓存机制。比如说你要定制内存回收机制，这个我还没去了解浏览器的内存回收能不能自己做，这个也很难。但是原生代码里，你可以尽情的去发挥你的想象，想怎么玩就怎么玩。没有做不到只有想不到。但是最终给用户带来的是良好的体验。比如你的App要联网，要下载大的图片，那么你可以规定图片下载的规则，带来流畅度和用户数据流量的优化。如果你的数据都是网络获取的，你可以把最后一次拉取到的数据缓存下来，这样用户下次打开的时候，可以先看到原来的数据，不会一直去等你的网络拉取完成才能看得到数据，也不会因为没有网络而看到的是整块的白板。

还有一点，就是Web端的API对于本地文件的权限的问题，虽然我不做Web前端，但是也明白前端的代码不能轻易触及文件的直接操作，那么好了，你的一些文件操作将会变的麻烦，这些带来的是开发中的坑，这些坑肯能就会让你的开发周期变长，任何不可预期的变长在商业产品中都是要避免的。

假设，你的Web App终于用最新的H5实现了，用户体验也很好，你也比较满意，但是慢着，你觉得浏览器不会坑你吗？我遇到不知道多少Android上浏览器内核崩溃的问题，基本都河很难去找到真正的原因。另外还有大概8%的用户使用着Android2.3的版本，你觉得你的应用能很好的在2.3的浏览器和硬件上跑吗？

虽然Native同样面临着相似的问题，但是往往人们都不太愿意做第一个吃螃蟹的人，或许哪天一个H5的App能表现的超越Native的时候，那可能将会是一个里程碑。至于现在，大家还是深深的观望，观望，然后埋头继续写自己的Java代码。程序员当然都希望自己能够开发效率够高，绩效高，奖金高，然后迎娶白富美走向人生巅峰。

编辑于 2016-12-19 21 条评论感谢收藏 • 没有帮助 • 举报 • 申请转载

知乎用户新媒体/公关狗/产品狗/网红经纪

33 人赞同

关于这两种app的体现模式哪个是趋势我想就他们的优略势进行比较一下让大家去判断 native优势： 1.在用户体验度上平均在说更加稳定 2.更能让用户记住，用户留存率比较高劣势：1.开发成本大（因为一个版本的功能出来很快就能做出其中一部分让内测人员体验。… 显示全部

        关于这两种app的体现模式哪个是趋势我想就他们的优略势进行比较一下让大家去判断

native优势： 1.在用户体验度上平均在说更加稳定 2.更能让用户记住，用户留存率比较高
劣势：1.开发成本大（因为一个版本的功能出来很快就能做出其中一部分让内测人员体验。而等我们全部做完了，已经过去一周了。然后提交给苹果审核，又要等一周。再等个良辰吉日发布，就过去了20天了。与此同时，我们有做出了更多的功能，调整了多处细节，还修复了几个bug--但用户只能再等几十天才能体验到了。而且还有的用户就是不升级。虽说我们能强制用户升级，但毕竟影响用户体验了）
2.分发的成本高（native的平台太多-主流的就有ios、android、windows三个平台，每个平台上的运营、推广都有不同的规则，三个平台就得适应三种玩法。）

web优势：相对与native的劣势：一个功能做好了就能上线，一天更新几十次都毫无压力。如果客户端只是个浏览器，那一切都会变得很简单。另外web统一性高，跨平台适用时开发量少。
劣势：由于其入口不明显（浏览器导航或者随意点击链接进入），让用户记住的门槛也随之拔高，每次推广导入的流量都可能沦为一次性努力，用户留存率低。

相比较的两者可以相互结合相互补：其实有不少的团队他们这两种模式都做了。他们先在web app上进行新版本测试，而后反哺native app的更新。或许现阶段手机浏览器的书签功能以及保存至蹦迪的功能还未被大多数用户所熟知习惯时，native app在桌面上的品牌形象还是创业者们无法舍弃的。

另外其实相对于浏览器、 微信所带来的趋势是不可忽视的。根据百度的移动互联网趋势报告显示手机浏览器的使用时长还在逐步下降，相比之下有更高使用时长的微信导流能力更强，根据之前流出的微信5.0版本，微信公众账号已经有了web app store的雏形了。而且公众微信找好呈现出很强大的表现能力，技术也没有很多人想象中那么初级。

总结趋势：
native app：更多存在的是一些用户常用的垂直领域的app（就如同我们pc端的快捷方式）
对于一些使用频率不高的app，整合或许才是他们未来的出路。微信、百度的light app平台甚至是手机桌面上的搜索框等、都是整合的方式之一，做到用户有需求时能尽快找到即可
随着随着html5、浏览器的规范统一他也将在web app呈现出很多的表现形式，到时会有更多的web app会在手机浏览器上展现

发布于 2013-06-27 2 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

胡琛互联网及营销爱好者

8 人赞同

这个和2年前讨论是否SaaS（Software as a Service) 才是趋势，是不是差不多呢？混合还是不混合，都取决于本身应用的产品设计。我不知道定义上Native app是否指不需要网络一样工作正常的app？还是说整个界面只要在本机开发运行而不是通过webview界面的，都算… 显示全部

这个和2年前讨论是否SaaS（Software as a Service) 才是趋势，是不是差不多呢？混合还是不混合，都取决于本身应用的产品设计。我不知道定义上Native app是否指不需要网络一样工作正常的app？还是说整个界面只要在本机开发运行而不是通过webview界面的，都算native app？我自己觉得，一个计算器，显然就是native app最简单，飞机上我也能算算报销；但飞机落地后我用地图察看当地最新的团购，就显然是web app才更方便。

发布于 2011-02-12 2 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

林兴陆

61 人赞同

Web的特点为业务逻辑和数据存诸基本上全在服务端，传统Web不支持离线应用，Cookies仅支持4K；而App除了能做Web能做的事，即C/S+B/S两层架构外，支持离线应用，WebKit或者说HTML5引入了数据库机制允许离线操作，未来两者可能会融合。做WebOS时的经验，整理… 显示全部

Web的特点为业务逻辑和数据存诸基本上全在服务端，传统Web不支持离线应用，Cookies仅支持4K；而App除了能做Web能做的事，即C/S+B/S两层架构外，支持离线应用，WebKit或者说HTML5引入了数据库机制允许离线操作，未来两者可能会融合。

做WebOS时的经验，整理出来几个App vs Web的主要区别：

1、App运行速度更快；
2、App可以更省带宽；
3、App支持离线操作；
4、App访问本地资源；
5、App可以去中心化；
6、Web部署成本很低；
7、Web学习成本很低；
8、Web跨平台和终端；

关于Web App vs Native App的问题，正好前段时间在iTech Club上分享了《跨平台手机应用开发》的主题演讲（ http://linxinglu.com/2011/01/24/1579.html 已整理成文章，含PPT文档）。

发布于 2011-02-18 7 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

codedump公众号codedumpnote,未来不迎,当时不杂,…

6 人赞同

其实现在已经慢慢有趋势，普通的创业团队难做native app了，原因是招人贵，适配的机器多，Ios和各种安卓系统都够折腾死了。另一方面，手机上浏览器浏览一般的网站，体验已经不差。以我个人而言，使用UC浏览知乎，觉得真心比用知乎的APP体验好。你只要做一… 显示全部

其实现在已经慢慢有趋势，普通的创业团队难做native app了，原因是招人贵，适配的机器多，Ios和各种安卓系统都够折腾死了。

另一方面，手机上浏览器浏览一般的网站，体验已经不差。以我个人而言，使用UC浏览知乎，觉得真心比用知乎的APP体验好。

你只要做一个web app，招人方便，前端人才遍地，另外轻松适配各种手机。

所以长期看，还是更看好web app，这个趋势，会跟当年PC端是一样的。

发布于 2013-07-20 7 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

丁超对于求知，永远是呼之欲出的态度

4 人赞同

1、技术角度：web app 的平台载体大部分是浏览器，依靠html5，但是由于不完善、规范不统一等，相比Native app , 后者的交互体验将得到更好的发挥。即便运用Hybird ，也由于内核支持性能差，如果遇上要求较高的应用，操作起来，也会很多bug； ps：身边一个前… 显示全部

1、技术角度：web app 的平台载体大部分是浏览器，依靠html5，但是由于不完善、规范不统一等，相比Native app , 后者的交互体验将得到更好的发挥。即便运用Hybird ，也由于内核支持性能差，如果遇上要求较高的应用，操作起来，也会很多bug；
ps：身边一个前端工程师说：“运用html5，对浏览器要求高，倘若浏览器支持力度不够，那么应用加载慢，会是用户体验最大的诟病”。

2、用户使用角度：对粘性不高，但是碎片时间会使用到的应用，比如：移动搜索、应用推荐、网址导航，web app 相比于Native app 更符合用户习惯。比如用手机查询搜索，大多数用户首先还是倾向于点击浏览器，而不是下载一个百度***；

3、微信时代：这个是微信霸占移动终端入口的特殊年代，微信不仅带来社交和关注，还充当了浏览器，web app 在其的限制也比浏览器要少；
场景：关注***公共账户，在微信内打开推荐应用，享受服务，既增加公共账户的功能扩展，又能带来增值效应，比如电商购买商品；

发布于 2014-03-10 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

mengya女硅工

10 人赞同

从工程师的角度看, 当然希望web app是主流,让广大的工程师从一个又一个的native app中释放出来,去做更多有意义的事情. 记得访问facebook cto关于11年的开发重点的时,就着重了html5, 他也提到现在为了维护一个facebook的mobile version, cost很大, 不同的pla… 显示全部

从工程师的角度看, 当然希望web app是主流,让广大的工程师从一个又一个的native app中释放出来,去做更多有意义的事情. 记得访问facebook cto关于11年的开发重点的时,就着重了html5, 他也提到现在为了维护一个facebook的mobile version, cost很大, 不同的platform至少一个, 就算是苹果一家, ipad和iphone也是两个app, 我没做过android app开发,不知道android不同version,是不是开发也有差异(写到这句让我想到了android岂不是mobile os中的ie...悲剧). 另外, web app的流行也依赖于其他技术的成熟, 当仁不让的就是html5, 怎么让offline的用户体验用好用顺很重要. 而且我想如果web app dominate的话, 是不是手机的ram和cpu的利用率会更好些, 此点属于瞎扯.
但是从现状来看, 目前肯定是native app是主流, 不得不承认, 现在的大部分web app太难用了, 甚至没法用. 前几天还见到reader上有人分享了一个可以把web转成android app的应用, 间接的说明web app实在是太难用了.

发布于 2011-02-12 1 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

陈琦手机游戏， html5跨平台游戏

10 人赞同

前几天Techcrunch上还有一个激烈的讨论，是说google的应用转向native是webapp将失败的一个证明，我觉得融合是一个真正的趋势， webapp+native的融合，现在越来越多的APP开发的趋势，当然以html5为基础的webapp目前还有不完善的地方，浏览器支持的API不够… 显示全部

前几天Techcrunch上还有一个激烈的讨论，是说google的应用转向native是webapp将失败的一个证明，我觉得融合是一个真正的趋势， webapp+native的融合，现在越来越多的APP开发的趋势，当然以html5为基础的webapp目前还有不完善的地方，浏览器支持的API不够多，调试工具的缺乏，都导致了webapp不能迅速的普及。Native的优势不言而喻，但问题就在于不能跨平台，开发成本高。对开发者来说，选择自己适合的，小快灵的往前走就好了。

发布于 2011-02-11 3 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

杜一摄影/ 生活/ 互联网

13 人赞同

Native App和web App有什么区别,请看下图： Native App的优势：1.提供最佳的用户体验，最优质的用户界面，最华丽的交互2.针对不同平台提供不同体验3.可节省带宽成本4.可访问本地资源5.盈利模式明朗 Native App的劣势：1.移植到不同平台上比较麻烦2.维持多个… 显示全部

Native App和web App有什么区别,请看下图：

&lt;img data-rawheight="254" data-rawwidth="721" src="https://i-blog.csdnimg.cn/blog_migrate/dc0d34c3693daf9410c1ec784f17a4e3.png" class="origin_image zh-lightbox-thumb" width="721" data-original="https://pic2.zhimg.com/60567e6b8dfc0e21364087166950015d_r.png"&gt;

Native App的优势：

1.提供最佳的用户体验，最优质的用户界面，最华丽的交互

2.针对不同平台提供不同体验

3.可节省带宽成本

4.可访问本地资源

5.盈利模式明朗

Native App的劣势：

1.移植到不同平台上比较麻烦

2.维持多个版本的成本比较高

3.需要通过store或market的确认

4.盈利需要与第三方分成

Native App开发

Native App开发即我们所称的传统APP开发模式(原生APP开发模式)，该开发针对IOS、Android等不同的手机操作系统要采用不同的语言和框架进行开发,该模式通常是由"云服务器数据+APP应用客户端"两部份构成,APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。

Web App的优势：

1.开发成本低

2.适配多种移动设备成本低

3.跨平台和终端

4.迭代更新容易

5.无需安装成本

Web App的劣势：

1.浏览的体验短期内还无法超越原生应用

2.不支持离线模式(html5将会解决这个问题)

3.消息推送不够及时

4.调用本地文件系统的能力弱

Web App开发

Web App开发即是一种框架型APP开发模式(HTML5 APP框架开发模式)，该开发具有跨平台的优势，该模式通常由“HTML5云网站+APP应用客户端”两部份构成，APP应用客户端只需安装应用的框架部分，而应用的数据则是每次打开APP的时候，去云端数据呈现给手机用户。

编辑于 2015-12-03 3 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

周广浩产品经理

6 人赞同

争论Web App和Native App那个是趋势其实是没有意义的。这只是技术方案不同而已。一个产品要预见到技术发展的趋势，做好两手准备。不要纠结于一个能调本地API一个要运行在浏览器里这些细节。凡是技术能解决的问题都不是问题。其实不论哪种技术方案能够赢得… 显示全部

争论Web App和Native App那个是趋势其实是没有意义的。这只是技术方案不同而已。一个产品要预见到技术发展的趋势，做好两手准备。不要纠结于一个能调本地API一个要运行在浏览器里这些细节。凡是技术能解决的问题都不是问题。
其实不论哪种技术方案能够赢得未来，App这种服务形式才是趋势。App是对URL的革命，是对搜索引擎的革命。服务App化的趋势是阻挡不了的。

发布于 2011-11-08 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

alienbat创业公司CEO

8 人赞同

答案非常简单： Native app是趋势。原因也非常简单：自古以来跨平台的解决方案（包括但不仅限于HTML）从来就无法提供最佳的用户体验。显示全部

答案非常简单：

Native app是趋势。

原因也非常简单：

自古以来跨平台的解决方案（包括但不仅限于HTML）从来就无法提供最佳的用户体验。

发布于 2014-08-22 7 条评论感谢收藏 • 没有帮助 • 举报 • 申请转载

李楠移动互联网产品总监

4 人赞同

iOS 的 App 内普遍使用了 UIWebView 。而 Web App 在发展通过 JS 调用本地功能的技术。所以相互融合是趋势。显示全部

iOS 的 App 内普遍使用了 UIWebView 。而 Web App 在发展通过 JS 调用本地功能的技术。

所以相互融合是趋势。

发布于 2011-02-10 1 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

知乎用户

11 人赞同

关于Web App和Native App的争论一直没有停过，前段时间翻译了一篇文章，还没有翻译完，但是看了好几遍，很长的文章，不妨在这里整理一下里面的观点。英文原文在这里： http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ 当然还有一篇反驳的文章： http://danbricklin.com/log/2013_06_19.htm#jsspeed 这里我只说说第一… 显示全部

关于Web App和Native App的争论一直没有停过，前段时间翻译了一篇文章，还没有翻译完，但是看了好几遍，很长的文章，不妨在这里整理一下里面的观点。
英文原文在这里： http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
当然还有一篇反驳的文章： http://danbricklin.com/log/2013_06_19.htm#jsspeed
这里我只说说第一篇文章中说到的一些观点，供参考。
========分隔君==============================================
作者在一开始提到了一个衡量标准：SunSpider
&lt;img src="https://i-blog.csdnimg.cn/blog_migrate/ad75653d81470d659ab631222307c25a.png" data-rawwidth="515" data-rawheight="351" class="origin_image zh-lightbox-thumb" width="515" data-original="https://pic2.zhimg.com/b3a191bcffe22f6222a416cafddbaf9d_r.jpg"&gt;我们会发现在移动设备上JS的性能。我们会发现在移动设备上JS的性能。
之后作者测试了原生代码和JS代码的性能差异，一个已有的测试基准： http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=spectralnorm&lang=v8&id=2&data=u32
&lt;img src="https://i-blog.csdnimg.cn/blog_migrate/091624a5913836e4c5abdf84aa1a6aae.png" data-rawwidth="515" data-rawheight="319" class="origin_image zh-lightbox-thumb" width="515" data-original="https://pic2.zhimg.com/2d3e43129c98e68bf62f8c1af9d3a0e5_r.jpg"&gt;发现LLVM保持了比Nitro快了4.5倍。发现LLVM保持了比Nitro快了4.5倍。
x86的结构对于ARM架构，更加适合于运行JS，请看对比数据。
作者加入了自己的iPhone 4S进行了对比。
&lt;img src="https://i-blog.csdnimg.cn/blog_migrate/37d361dfb410284b369566219938fa08.png" data-rawwidth="515" data-rawheight="315" class="origin_image zh-lightbox-thumb" width="515" data-original="https://pic1.zhimg.com/9d07f3fe85127ba0af12d8e0399c07bc_r.jpg"&gt;
ARM架构的程序必须保证10倍的性能提升才能和x86平台的进行对比。
从硬件角度，因为ARM发展的限制，期待摩尔定律来拉伸这部分的性能损失不太现实。
软件角度，文中说Jeff Atwood提到：

I found that the performance of JavaScript improved a hundredfold between 1996 and 2006. If Web 2.0 is built on a backbone of JavaScript, it’s largely possible only because of those crucial Moore’s Law performance improvements.

JS的性能这几年并没有大的提升，即使有也是得益于摩尔定律。
下面作者有引用了大段的“证据”说明JS“Not designed for performance”。
最后谈到了我们都知道的就是JS的垃圾回收机制，没有一个有效的垃圾回收机制。
还有就是JS的内存占用问题。
回归本质就是编译语言、JIT、解释性语言性能的讨论，对吗？
以上。

发布于 2013-09-10 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

小媒体http://xiaomeiti.com

Hybrid App初探，开发移动端App也没那么难显示全部

Hybrid App初探，开发移动端App也没那么难

发布于 2015-07-02 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

张宇iOS developer

3 人赞同

分久必合，合久必分。操作系统提供商不会坐看维护的生态环境被他人窃取。 PC时代就有类似的问题先是native的，之后出现web应用，两者共存，渐渐倾向于web，这之中网络环境、计算机速度提升占很重要的因素现在移动开发，先从native开始，但现在越来越多的… 显示全部

分久必合，合久必分。操作系统提供商不会坐看维护的生态环境被他人窃取。
PC时代就有类似的问题
先是native的，之后出现web应用，两者共存，渐渐倾向于web，这之中网络环境、计算机速度提升占很重要的因素
现在移动开发，先从native开始，但现在越来越多的应用使用web，或者混合架构
同样有合还要有分，跟中穿戴、车载、智能家电发展起来后，又是native天下