为什么移动平台还是Native更流行，较少HTML5应用？-

现在一款应用，需要做iOS、Android和Windows Phone等多个平台，每个平台做应用成本太高了，为什么不使用HTML5实现？HTML5有无法实现NATIVE应用的技术瓶颈吗？

回复内容：

主要还是因为 HTML5慢，比不上 Native App，而且这个差距永远不会被追上。

大佬 Facebook 已经承认过了:
Facebook: “Betting on HTML5 Was a Mistake”
Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5

如果有兴趣的人，强烈推荐阅读下面这篇文章，超长，但是如果读完了，you won't regret
Why mobile web apps are slow 今天2015.4.22，距离这个回答过去两年了。
mark一下。
如今WebAPP发展到啥样了呢？
现如今五六百的手机都可以流畅的跑JS动画了～ 感谢红米～
微信给H5提供了一个不错的撒欢儿打滚儿的窝～
某国内一流Android APP分发商店跟我说他们移动客户端全要换成WebAPP了～

Andy Rubin辞职Sundar Pichai接任Android，于是你已经看到chrome正式入住Android，chrome内核在Android自升级，前两天chrome有搞了一个ARC，Android APP跑到了chrome里。Sundar肯定是要把Android和Chrome揉在一起的，也许三年后我们讨论的WebAPP的概念也变了，变成啥呢？

Google把spdy推演到http2成为标准，科技还总是靠巨头推动的。

当移动互联网带宽又进一步升级的时候，也许离线的WebAPP也不需要了，c/s到b/s的转变又要像当年的pc上一样在mobile终端上演，当然历史总是相似的，总又有令人惊喜的不同。

——————————————————————
主要还是Html5 Native渲染不过关，Network Access已经不是问题了
优秀的Html5&Javascript Container出现才能根本解决问题，现在要想效果好只能拼硬件
本人经验是硬件越好效果越好，iOS webkit效果好于Android webkit，Samsung 的Rom对Browser core有优化同样的配置效果更好些
Html5渲染效果比不上Native App 跟 Android App没有iOS App流畅是一样一样滴，中间隔太多层了，除非OS内核直接嵌入渲染引擎，也许我想多了
——————————————————————下面反驳@水云逸

• 每次使用都要打開瀏覽器（多重的打開步驟）

现在Html5跨平台应用的解决方案是一次开发，分平台打包，请把思维从desktop绕过来吧

• 反複讀取同樣的素材和function（花費額外的流量和等待時間，服務器壓力也會更大）（你得再等個好幾年，讓網絡上去了再說）

Html JS Resource files 都是打包的本地的，不占流量，何况这年头的网速还不够快么

• 沒有或很少有足夠流暢的圖像，比如按鈕和列表效果（打斷用戶享受的心情）

有足够的效果，性能的确是问题，不过CSS3硬件加速提高很多

• 離開網絡和瀏覽器無法工作，對於內容型的產品是個什麽效果？還是說你打算要求用戶每次保存網頁？（無法離線使用）（要是有解決方案請務必告訴我）

请参照前两点，打包，或者以后会有Chrome App的类似方式，现在Chrome OS的App也是有离线可以用的，哪天Html5雄起了，Google Android一秒钟变 Chrome Mobile（firefox mobile os 太超前了，逃不了壮烈的命运）

• 缺少與平臺相適應的功能或風格，比如手勢【1】、分享【2】（需要用戶改變使用習慣）

去查查Html5的Touch API吧，drag神马的应有尽有，以后会更全哦

• 真的能夠跨平臺？現在都爲了網銀保留著IE呢，瀏覽器那不同的HTML5實現和網頁那不同的瀏覽器目標擱一起你打算怎麼辦？（跨平臺成本並不低）

讲Mobile您怎么能提到IE，好远古啊，想MS windows phone的browser即使是desktop的IE10，也不敢不遵循标准了，当然有的实现Chrome跟Firefox对象名都不一样，但是适配的工作比分平台开发代价低很多，何况Mobile的实现还是比较统一的
————————————————————————————
好吧~ 我真的不是Html5的脑残粉，我是吃过亏的好不好，我们用Html5做壳跨平台，下面还要跑C的协议栈，协议栈性能再高也受不了webkit总是给我卡啊！
Html5取代Native App？过五年再议吧~ 就 h5 渲染的问题说两句，CSS3 用得好，界面基本上是分不出原生还是 h5 的。以一个典型的非游戏应用来说，iPhone 4S 的时候我就可以 60fps 实现 90% 的动态 UI 需求，现在 5S 上我可以让你完全看不出是 h5 做的，甚至让你不相信是 h5 做的。Galaxy S4 或者 Nexus 5 这样的高端安卓上，尤其是 KitKat 改用 Chrome 作为 WebView 内核之后，效果也相当 ok。真正没办法的是那些渣配置、旧版本、连原生应用都要卡的安卓机…

但是，不得不承认现有的 DOM 和 CSS layout model 效率确实差得可以，因为当初就不是以 60fps 为目标来设计的… 以至于现在想要流畅的动态 UI 几乎必须全部用 CSS transform 来实现… 另外还有各种不知道就会被坑的小地方，比如 box-shadow / text-shadow 这种属性在移动设备上渲染代价相当昂贵...

再补充一下。在实际应用中，h5 比较致命的问题不是渲染，而是 DOM 元素过多带来的内存问题。当年 Facebook 抛弃 h5 其实主要就是其无限滚动导致页面内容越来越多最后越来越卡。Sencha 和 LinkedIn 都采用过管理一个可复用 DOM 元素池来规避这个问题，但在实现上就相对复杂。如果应用的设计中没有无限滚动的设定，那就基本不用操心这个问题。 部分赞同，但是不完全赞同目前最高票的 @王乐 的答案。现在我对这个问题有了更清晰的认识。
问题不仅仅在于技术，而是有更深层次的原因。
采用html5做开发，通常是因为已有程序员更熟悉web，而不熟悉移动开发。所以最初的动机，并不完全是考虑同时兼容android和iOS两套系统；隐藏在深处的动机是：对程序员来说，避免学习移动开发带来的高额成本；对于管理者来说，避免雇佣专业从事移动开发的程序员的高昂薪水。
那么，自然就会演变成了这么一种状况：开发人员基本上不懂移动开发，也不愿意学习，仍然是依照自己做web的一套理念来做移动应用。手机和网页，因为都是html, 对他们来说没什么差别；直接在pc上调试，直接在浏览器里面调试，然后套上一个手机的壳就可以了，仅仅是屏幕大小不同带来的页面大小不同而已。
其实对于专心做移动开发的人来说，不仅移动应用和web完全不同，iOS和android, iPhone和iPad, iPhone 4/4s和iPhone 5/5s, 都是完全不同的东西，必须认真对待他们之间的差别。
---------------------
评论区的同学没看明白我的意思啊。我是说，其实不是技术的问题而是理念的问题，技术好学，理念难改。 职位刚从前端转到了ios..此前最后负责的是公司某app的内嵌页面（俗称h5）。

其实h5和native各有优劣，
首先是h5的优势：
1. 用h5做的页面迭代速度快，每次就更新服务器的文件用户那头就更新了，不用好像native那样各种提交app store审核，审核不过打回来然后还继续审，万一不小心有bug带出去了又要重新更新一个版本。这是h5的一个巨大的优势——迭代迅速
2. h5现在已经能做越来越多的事，从地理位置获取到传感器获取到陀螺仪，h5的能力已经越来越大，并且相信会变得更大，这让开发者的门槛大大降低，更多的前端可以直接用js就能做出强大的东西——潜力
3. 跨平台。现在要做一个原生的app，至少要一批人做ios一批人做android，说不定做大点，windows phone又要找一批人搞，成本对小团队来说可相当不小，而h5，基本搞定一个就全部通用了。跨平台同样是h5的一个大优势——成本低

优势说完了劣势来了：
1. 说实话h5的性能真的差得可以，处女座表示实在很难接受，之前算是h5负责了比较久，想方设法开硬件加速，减少节点减少请求乱七八糟，是相对效率高了，但是离原生还有很大的距离，这个也不多说了，性能是硬伤——性能性能还是性能
2. 很多h5的页面喜欢模仿原生的来做，往往原生一两句代码就能搞定的东西，用h5做要写一堆css而且还模仿得不像，人家“啪！”那个选择框就弹出来了但在h5里面卡了2下再出来，这就是差别。而且用h5的话控件难以根据系统更改风格，例如ios6,ios7的选择框是不同的，原生的话自动适配但是h5倒没那么好搞了——界面难以做到和原生一样和手机ui统一
3. h5的bug真的呵呵呵呵呵呵，好不容易从ie6怪圈逃出来了又遇到了各种各样的android，甚至ios也会抽风。你说ie6的bug嘛还算有迹可循，百度也有很多沉淀，移动终端的我遇到好多bug根本百度不了，测试那里一堆手机一个个测总有各种各样奇怪的问题，胜在有万能的google和stackoverflow——bugs

个人拙见..万望轻喷.. 号称 “ HTML5 的正确打开方式 ” 的 HTML5 开发者是这么说的
1. 安全
2. 不同手机的 js benchmark 性能差别
3. 是否有必要有 Webapp 的应用商店 —— 我个人认为如果没有好的应用商店（如 App Store 、GOOGLE PLAY），就不会有超大批量的开发者，也就是 是小众的、无发布平台的（无传统分发平台、也就没有各种 APP 推荐网站、活跃等级会不如 Native APP，but 这对于开发者来说是好事还是坏事？）
4. 把 HTML5 包装成 Native APP 之后的执行效率
云集，让 web app 像 native app 那样运行 看样子很多（比较）高票的答案都是没做过HTML5开发也不愿意去了解的人，或者是产品经理。
目前的最高票 @王乐 的答案基本靠谱——主要原因就是渲染性能问题，这一点 @王乐已经解释得很明白，就不再多说了。补充一些我遇到的问题。

首先声明，以下的webapp是指打包成apk/ipa的所谓"Hybrid App"，不管你用phonegap也好titanium也好，甚至自己写一套简单的webapp平台也好，它具有如下特征：

1. 使用HTML5/CSS/Javascript做UI（废话，否则就不叫webapp了）
2. 所有网页和资源文件保存在本地，app启动时利用webview调用这些网页，不存在到服务器下载脚本和图片的问题
3. 可以简单地利用Ajax和服务器通信
4. 可以在网页中通过native bridge访问native app的（几乎）各种特性，如各种传感器、相机、本地存储、数据库等

WebApp标榜的好处是什么呢？跨平台，对，一次开发多次分发，这也恐怕是使用webapp的唯一理由吧。
（当然还有个“理由”是web前端工程师做起来更容易，实际上这不能成为理由。一个优秀的前端的工资并不比移动工程师少。）

那么跨平台究竟可行与否，就成了webapp的关键。我认为，webapp要想跨平台还有许多路要走。

1. 最大的难题就是设备碎片化。对，Android，说的就是你。各种屏幕大小各种硬件设备，还有各种奇葩厂商不遵循标准声称自己支持某某特性其实做得渣渣一样或者根本不支持的，连Android上的native都搞不定的问题，你能指望webapp搞定？好歹Android还有各种过滤器允许你根据不同尺寸的屏幕设计不同的界面布局，webapp只有media query这一个法宝，能走多远呢？
2. 第二个难题就是原生界面模拟。想在网页上做出跟native UI一样的界面，不是不可以，但难度相当大。当然现在iOS7采用扁平设计后UI难度小了很多，几条css规则就能搞定，以前iOS6时代做个按钮需要几张图片和各种css规则拼接，相当麻烦。——等等这句话好像有哪儿不太对？不是说webapp要跨平台嘛？怎么还要区分iOS6和iOS7？看来不同操作系统甚至同一操作系统的不同版本，界面风格都大相径庭，所以得为每种风格单独做一套样式表？三星的Android设备用的还是三星家自己的ROM，也得单独弄一套吧，要不出来个google风格的界面怎么办？
   
   要知道，native app根本不存在这个问题，写一个iOS app，一个Android App，所有版本的设备上都能跑得很漂亮。
   
   当然这个问题也不是无解，只要有个优秀的设计团队，做个通用界面就好了。当然你也可以付出性能的代价采用jQuery Mobile等庞大的界面库。

可见，其实webapp宣称的跨平台并不完美，的确不用再为每个平台写代码，但需要做的额外工作也很多，算下来实际效果如何，要看你的项目如何定义了。外加HTML5的渲染性能实在不怎么样。

那么为什么不直接写几个native app呢？ 应该说HtML5能让Native APP变得更好！而不是将Native 市场覆盖 个人觉得主要是在体验和性能上。 我觉得最根本的原因，是 html5 app 没办法常驻后台，偷偷上传你的大量隐私数据。所以互联网的大佬例如百度阿里腾讯都不喜欢直接开发 html5 app。

就我个人而言从使用的角度一般会考虑 web app，因为相对来说要轻量与清新得多。也不会需求大量的根本无理由的权限，不会在后台常驻联网跑流量而且耗电。但从开发的角度当然愿意开发原生的。

为什么有很多开发者喜欢 native app 里面套 html5 框架？只是因为他们同时想得到 html5 的开发优势，以及 native app 能够获得更多隐私数据的优势而已。他们其实比纯 web app 更流氓。

当然，那些不需求任何权限也绝不常驻后台的 native app 我还是赞赏的。

我认为，目前webapp主要是那些不靠上传用户隐私谋利不需要常驻后台的app。