一、Web APP 和 Native APP
Web APP的优势非常明显：
- 跨平台：所有的系统都能运行
- 免安装：打开浏览器就能使用
- 快速部署：升级只需要在服务器更新代码
- 超链接：可以与其他互联网互联，可以被搜索引擎检索
Web APP的劣势然让人难过：
- 体验差：展示比原生慢，且操作流畅性差
-
业界不支持：几乎所有公司主营产品都以
app方式实现 - 用户较少：用户肯定是哪个好用用哪个
二、Web APP 的瓶颈
Web app输给Native app的地方，不是界面（UI），而是操作性能；主要是互动(interaction)和动画(animation)这两个方面，会出现卡顿(jank)，用户会感到明显的迟滞，有时甚至难以忍受。
Web app的性能瓶颈，主要有以下原因：
1. Web基于DOM，而DOM很慢。 浏览器打开网页时，需要解析文档，在内存中生成DOM结构，如果遇到复杂的结构，这个过程是很慢的，可以想像一下，如果网页有上万个、甚至上十几万个形状（不论是图片还是css）生成DOM需要多久？就更不用说与DOM互动了。
2. DOM拖慢了javaScript。 所有的DOM操作都是同步的，会堵塞浏览器，javaScript操作DOM时，必须等待前一个操作结束，才能执行后一个操作。只要有一个DOM出现卡顿，整个网页就会短暂的失去响应。浏览器重绘网页的频率是60FPS（16毫秒/帧），javaScript做不到16毫秒内完成DOM操作，因此产生了跳帧。用户体验不流畅，不连贯，就是这个原因。
3. 网页是单线程的。 现在的浏览器对于一个网页，只用一个线程处理。所有的工作都在这一个线程上完成，包括布局，渲染，javaScript执行，图形解码等等，自然就慢下来了。
4. 网页没有硬件加速。 网页都是有CPU处理的，没有GPU进行图形加速。
这些问题，对于pc来说，还不至于造成多少严重的问题，但是对于手机的硬件资源十分有限，用户互动又相对频繁来说，web App 和 Native App相比，就显得输人一截了。
三、FlipBoard的优化方案
FlipBoard原本是一个手机App，最近开始部署Web版本，结果就遇到了上面的问题：Web版的上手体验不佳。
上周，他们将解决方案公布在网站上，结果引起了业界轰动，因为这是一个史无前例的解决方案：
他们没有使用DOM，而是将整个网站用canvas输出
这个方案的出发点是这样的：如果将网页变成了一个个canvas，用户就等于在跟图片互动，这样就绕开了DOM，降低了操作时滞.
而且，canvas可以被硬件加速，这样就提高了性能。具体的技术细节，可以参考原文。canvas的转化基于React框架实现，FlipBoard 开发了一个专门的库React-canvas，已经开源。
这个方案引发了很多争议（这里和这里），主要是canvas只是一个位图，本身没有语义，如果要在它上面实现UI，等于HTML语言已有的东西都要再发明一遍，比如如何实现超链接、如何实现CSS效果等等。一些最简单的东西都变得很麻烦，因为canvas不是自适应的（responsive），文字在哪里断行，都要自己计算，而且用户也无法选中文本。另外，怎么让搜索引擎检索网页，解决起来也不是很容易。
但是不管怎样，这是一个有意义的尝试
网友评论