本文主要包含HTML5,Windows,Android,NATIVE,Phone等相关知识,匿名希望在学习及工作中可以帮助到您
现在一款应用，需要做iOS、Android和Windows Phone等多个平台，每个平台做应用成本太高了，为什么不使用HTML5实现？HTML5有无法实现NATIVE应用的技术瓶颈吗？
大佬 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的脑残粉，我是吃过亏的好不好，我们用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"
回复内容：
主要还是因为 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内核直接嵌入渲染引擎，也许我想多了
——————————————————————下面反驳@水云逸
- 每次使用都要打開瀏覽器（多重的打開步驟）
- 反複讀取同樣的素材和function（花費額外的流量和等待時間，服務器壓力也會更大）（你得再等個好幾年，讓網絡上去了再說）
- 沒有或很少有足夠流暢的圖像，比如按鈕和列表效果（打斷用戶享受的心情）
- 離開網絡和瀏覽器無法工作，對於內容型的產品是個什麽效果？還是說你打算要求用戶每次保存網頁？（無法離線使用）（要是有解決方案請務必告訴我）
- 缺少與平臺相適應的功能或風格，比如手勢【1】、分享【2】（需要用戶改變使用習慣）
- 真的能夠跨平臺？現在都爲了網銀保留著IE呢，瀏覽器那不同的HTML5實現和網頁那不同的瀏覽器目標擱一起你打算怎麼辦？（跨平臺成本並不低）
————————————————————————————
好吧~ 我真的不是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"