最近接触了PhoneGap，也顺带了解了Mobile Web.
他们出现的目的就是为了让Web开发者使用HTML、Javascript、CSS等Web APIs开发跨平台的移动应用程序。
现在很多软件，比如说腾讯新闻，就是采用Web技术开发，然后在PhoneGap上打包成APK。
（找不到腾讯新闻的图片对比，先用个别的）:
从样式上看起来，给人的感觉和用原生技术开发的差不多嘛。而且重要的是MobileWebApp的优势真的很诱人，现在一般公司开发软件都是Android和iOS两套，成本很高。采用MobileWebApp后的确可以节省很多开销。
那么问题来了，作为正在Android原生技术开发道路上的一直菜鸟，我很担心:
会不会哪天我好不容易把原生技术学的差不多了，duang！一下子PhoneGap可以完全替代Android原生了。
我可不想像塞班垮台时那些可怜的程序员一样，苦苦修炼二十年，一夜回到解放前。
带着这种恐惧我遍访名医啊，各种百度，终于找到了让我可以心安的答案：
的确比起手机App，网站有一些明显的优点。
- 跨平台：所有系统都能运行
- 免安装：打开浏览器，就能使用
- 快速部署：升级只需在服务器更新代码
- 超链接：可以与其他网站互连，可以被搜索引擎检索
但是，现实是怎样呢？
- （1）体验差。手机App的操作流畅性，远超网站。
- （2）业界不支持。所有公司的移动端开发重点，几乎都是原生app。
- （3）用户不在乎。大多数用户都选择使用手机app，而不是网站。
如果将来有一天，Web app会成为主流，一定有一个前提，那就是它的性能可以赶上Native app。
注意了，关键在于目前移动app“性能”不足。
那么性能问题是什么原因呢？
Web app的性能瓶颈，主要有以下原因。
- （1）Web基于DOM，而DOM很慢。浏览器打开网页时，需要解析文档，在内存中生成DOM结构，如果遇到复杂的文档，这个过程是很慢的。可以想象一下，如果网页上有上万个、甚至几十万个形状（不管是图片或CSS），生成DOM需要多久？更不要提与其中某一个形状互动了。
- （2）DOM拖慢JavaScript。所有的DOM操作都是同步的，会堵塞浏览器。JavaScript操作DOM时，必须等前一个操作结束，才能执行后一个操作。只要一个操作有卡顿，整个网页就会短暂失去响应。浏览器重绘网页的频率是60FPS（即16毫秒/帧），JavaScript做不到在16毫秒内完成DOM操作，因此产生了跳帧。用户体验上的不流畅、不连贯就源于此。
- （3）网页是单线程的。现在的浏览器对于每个网页，只用一个线程处理。所有工作都在这一个线程上完成，包括布局、渲染、JavaScript执行、图像解码等等，怎么可能不慢？
- （4）网页没有硬件加速。网页都是由CPU处理的，没用GPU进行图形加速。 上面这些原因，对于PC还不至于造成严重的性能问题，但是手机的硬件资源相对有限，用户互动又相对频繁，结果跟Native app一比，就完全落在了下风。
以上几点原因好像短时间不能解决呢，我可以放心喽？
目前来看好像是的，虽然对于自己的私心来说希望他发展的慢一点。
但是站在互联网发展的角度，还是希望有一天可以实现完全替代原生，毕竟可以节省许多不必要的开销。
James Long对FlipBoard的尝试，写了一篇评论《Radical Statements about the Mobile Web》。在文中，James Long对未来的Web app提出了几点预测，我认为很值得分享。
- （1）多线程浏览器。每个网页应该由多个线程进行处理，主线程只负责布局和渲染，而且应该在16毫秒内完成，JavaScript由worker线程执行，这样就不会发生堵塞了。Mozilla正在开发的Servo就是这样一个项目。
- （2）DOM的异步操作。JavaScript对DOM的操作不再是同步的，而是触发后，交给Event Loop机制进行监听。
- （3）非DOM方案。浏览器不再将网页处理成DOM结构，而是变为其他结构。React的Virtual DOM方案就是这一类的尝试，还有更激进的方案，比如用数据库取代DOM。
