清华大佬耗费三个月吐血整理的几百G的资源，免费分享！....>>>

HTML5

HTML5这个概念也已经炒作了几年了，看了很多关于HTML5的文章，包括一些技术书籍，对这一概念吹的雨里雾里，说了一大堆新特性讲了一大堆抽象的概念。搞得我很长时间才搞清楚什么是HTML5。其实没什么太多的东西，就是督促各个浏览器厂商都支持一些新的比较实用的属性，大家的行为尽量保持一致。给HTML添加了一些实用的标签，让一部分以前需要写很多JS代码才能实现的效果，只需要一个标签就可以简单搞定，当然这是在得到了浏览器的底层支持的情况下，还加强了一些影音方面的支持。个人认为其实并不是革新的东西，只是朝着HTML自己的既定方向的正常发展。但是偏偏很多人喜欢炒作，什么native App的末日来了之类的论调“不绝于网”。可是三五年就这么过去了native App并没有死掉，反而还活的比以前还好（移动互联网的浪潮下，互联网时代的几乎所有网站服务都要开发iOS和Android客户端），反而感觉HTML5技术还是和几年前一样，web App也并没有取代native App成为主流。

web App VS native App

前几天看了一篇文章叫《Web App 和 Native App 不是生死之争——反思 HTML5 惨痛的 500 天和四个谎言》，感觉作者之前是被HTML5的大势鼓吹忽悠了，感觉HTML这次会出大招把native App打的落花流水，几年过去大招一点影儿都没看到，失望了，转而唱衰HTML5，自己意淫出HTML5的四个谎言。我受这篇文章激发，也想分析预测一下web App和native App的这场战争谁会是最后的赢家。我先表明立场：赢家当然是web App。下面我仔细分析为什么web App会赢得战争。我尽量不写空虚的概念，多分析一些导致web App会赢得战争的关键因素。

历史

古人云：“以史为镜，可以知兴替”，那么要分析“web App VS native App”的战争，其实有一段很近历史可以参考。我还记得2005年我上大学的时候，每一本web的技术书籍的前言里都会写一段B/S架构与C/S架构之争的故事。结局大家当然知道，最后是那个胖客户端渐渐被大家抛弃，瘦客户模式B/S架构成为业界的主流（当然可能有人会说，并没有一个明确的标准来判定C/S架构输掉了，但我想说的是很多C/S架构的软件服务逐渐转向了B/S架构，而最开始就以B/S架构起家的软件服务却鲜有转向C/S架构的，这是不争的实际）。关于B/S和C/S的优缺点大家可以参考知乎上《CS 和 BS 架构的优缺点分别是什么？》问题下面的回答。其实web App和native App的优缺点几乎就是翻版的B/S与C/S的优缺点。下面是我对web App和native App的优势劣势对比分析

用户体验

从上表用户体验的对比来看，web App明显弱于native App。只在［需要下载］项目上有优势，但是下载App对智能手机用户到底是不是一个痛点这个目前还有争论，我个人认为这并不是用户会倾向选择web App还native App的重要决定因素。［响应速度］才真正决定了用户对一款应用的印象。在这一项上web App和native App确实是存在差距，并且web App的响应速度永远不会快于native App。但是客观事实是随着手机性能的不断提高，以及浏览器的不断优化，这方面的差距正在逐渐减小，最后有希望减小到不被用户察觉的级别。

开发体验

在用户体验环节惜败的web App在开发体验环节可以说是大获全胜。在用户体验环节native App几乎在全部项目的比较上有优势，但是可以说优势不明显并且差距在不断的缩小。但是在这个环节，web App可以说是在每一个项目的比拼当中都占有绝对的优势，而且这些优势在可以预见的将来也不太可能会被缩小。

我们先来讲开发速度，很多项目组甚至用HTML来做native App的原型，供项目组内部讨论App的设计，可见开发速度方面的差距真是不可同日而语。成本方面，iOS和Android开发人员的薪资水平普遍比HTML的开发人员高，并且项目开发人员多，成本自然高，对于一般项目来说native App（包括iOS和Android两个版本的客户端）的开发预算差不多要是一个web App的三倍左右。对于native App，更大的问题是版本变更，这绝对是开发商最大的痛点，iOS方面每次版本变更都要通过苹果的审核，Android在这方面并不是很严格，但同样阻碍了程序更新的平滑过度。这里面还存在另一个问题，一旦发现过去发布的App存在bug或者设计上的缺陷，就需要发布新的版本来修正，但是并不会保证所有用户都升级到新版本（虽然可以强制用户升级程序，但这并不是互联网公司的常用手段），为了支持过去版本的客户端，服务器端的实现就变得越来越复杂（加了很针对不同版本不同的处理逻辑），这样会提高潜在bug发生的概率，对于项目维护简直就是噩梦。相比之下web App就好很多，用户访问服务器的时候自然得到是最新版本的HTML，JS代码，服务器只要一次部署就可以确保所有的用户都使用最新版本的App。虽然听说苹果也实现了App自动更新功能，不过只是听说还没看到哪个native App在用。在多平台对应方面，由于Android阵营的手机实在太多，web App在设计上需要考虑到不同设备的不同分辨率，以及Android手机中的浏览器对不同HTML属性的支持问题；而同样Native App开发也面临Android平台下不同手机的不同系统的细微差别和不同分辨率的问题，这方面两者面临的困难差不多。UI的开发方面web App还是有明显优势的，利用HTML与CSS的组合，可以很快的开发出在iOS和Android系统下风格统一的UI界面，而native App的UI开发比较费时，并且很难在两个平台下开发出风格统一的UI。

经过上面的比较可能有人会说，明明是两种类型的App在用户体验和开发体验上各下一城，为什么就断定web App会笑到最后呢？并且明明是用户体验重要，开发上慢点，难点，成本高点只要用户体验上去了，这些都值得，这么看来岂不是native App应该笑到最后？理想状况下，确实是native App相比web App有一点优势，但现实往往和理想差距很大。

在开发一个新的互联网应用的时候，最难把握的其实是用户的需求，所以应用要不断迭代，以适应用户需求。对于开发native App客户端来讲，首先投入的成本极高，在这种情况下迫于各方面的压力项目经理脑子里考虑的就不单是用户体验了，有的时候会在用户体验和开发成本中间做折中选择。并且由于项目团队过于庞大，项目的沟通协调也变成负担，往往最后得到的结构还不如当初折中选择的预期。这样照成最后的结果是实现的App质量远没有开始想的那么好。并且还有一个问题，由于native App的版本更新十分麻烦，给项目带来了相当大的风险。客户端一旦发现bug，解决bug简直就是噩梦，有的时候服务器为了迁就已经发布出去的客户端上的bug不得不加入一些比较特殊的处理（不符合正常业务逻辑的），而这些处理极有可能在未来的某一时刻照成无法预料的另一个bug。所以综合考虑开发成本和项目维护难度来看，native App的用户体验甚至低于web App（由于项目维护的难度加大，项目无法及时迭代，导致产品脱离用户需求）。所以可以预见在不远的将来，大部分应用开发商会拥抱web App就如同当年B/S和C/S之争时一样。只不过这需要标准制定方，浏览器开发商，以及系统提供商各个方面的通力合作。

各自的适用范围

上面我讲了web App由于开发维护成本方面的绝对优势，最后会取得战争的胜利，但是在某些局部领域，web App很难取代native App的。

web App很难进入的领域：

• 需要底层系统服务的领域（如支付）
• 需要后台运行的程序（如音乐播放，需要在锁屏模式下运行）
• 比较重的图形影音文字处理软件（如图片编辑）
• 实时沟通软件（比如微信）
• 业务逻辑，功能非常复杂的软件（比如微信）

这其中有一些领域web App也并不是没有进入的可能，但真的是一条非常远的路，要看以后浏览器的发展，到底能开放出多少权限。下面我再列出就目前为止非常适合web App的领域：

• 新闻客户端
• 社交软件
• 电商
• O2O

其实总结一下就是基本上只要不会调用到系统的底层服务的应用，都比较适合用web App来实现。感觉现在手机淘宝客户端就已经是native和web相结合实现的了。我认为做选择的原则是，必须调用系统服务的功能用native实现，其他全部用web实现，也就是说只要能用web实现的决不用native实现。淘宝客户端是一个很好的尝试，大部分初创企业也应该沿用这个逻辑，开发客户端的时候也可以采用web与native结合的方式。

现状

分析了这么多，但是实际上以目前的web App和native App的实力对比来看，native App还是站着绝对的优势。但是走到最后的赢家应该是有长远战略的人。好比国共内战，共产党取得胜利，但是长征的时候谁能想到共产党会走到最后，而表面上看实力雄厚，实际内部腐朽，怨声载道的国民党以后败会下阵来呢。现在的native App就好比当时的国民党，表面繁荣，但是实际上开发者也是怨声载道，而web App正在努力解决开发者面临的难题，虽然现在势单力薄，将来在大多数开发者的拥护下一定会不断壮大取得最后胜利（想想其实真的很像毛主席的农村包围城市战略，现在的web App只也确实只能“外围应用”上发力）。