Flipboard web移动端-打造每秒60帧的流畅体验
在智能手机和平板电脑的黎明时期， Flipboard 推出“移动先行”的体验,使我们可以重新思考页面中内容布局的原则，以及与触摸屏相关的，如何获得更好的用户体验的因素。
为了建立完整的体验，我们将 Flipboard 带到 web 端。我们在 Flipboard 所做的，在每台用户使用的设备上都拥有独立的价值:整理那些来自你最关心的主题,来源以及人的最好的故事。因此把我们的服务带到web端，也是一个合乎逻辑的延伸。
当我们开始这个项目后,认识到我们需要把源自移动体验的思考搬到 web 端,试图提升 web 端的内容布局和交互。我们想达到原生应用般的精致和性能,且仍能感知到真实的浏览器。
早些时间，经过测试大量的产品原型后，我们决定使用滚动的方式作为 web 端体验。我们的移动应用被大家所熟知的是类似翻书般的体验，在触摸屏上这很直观。但一系列的原因表明，滚动在 web 端的体验更加自然。
为了优化滚动的性能, 我们知道我们需要保证页面渲染的频率低于16ms，同时限制回流(reflow)和重绘(repaints)。这在动画中尤其重要。为了避免动画中重新渲 染，有两个属性你可以安全地作用于动画上: CSS transform 和 opacity。但这样选择余地太小了。
当你想实现元素上宽度动画效果怎么办？
一帧帧的滚动动画如何处理？
注意,在上图中,顶部的图标从白色到黑色。这里使用了两个单独的元素相互覆盖，根据下面的内容来互相裁剪)。 这些类型的动画一直在网上遭受诟病,特别是在移动设备上,只因为一个简单的原因:DOM 太慢了。
开始使用 <canvas>
大多数现代移动设备都拥有硬件加速的 canvas，我们为什么不利用起来呢？HTML5 游戏已经做到了。我们能真正在 canvas 上开发应用界面么？
立即模式与保留模式
Canvas 是一种立即模式的绘图 API,这意味着绘制时不保留所绘制对象的信息。与其相反的是保留模式,这是一种声明性的 API,维护所绘制对象的层次结构。
保留模式api的优点是，对于你的应用程序，他们通常更容易构建复杂的场景，例如 DOM。通常这都会带来性能成本,需要额外的内存来保存场景和更新场景，这可能会很慢。
Canvas 受益于立即模式,允许直接发送绘图命令到 GPU。但若用它来构建用户界面，需要进行一个更高层次的抽象。例如一些简单的处理,比如当绘制一个异步加载的资源到一个元素上时会出现问题,如在图片上 绘制文本。在HTML中，由于元素存在顺序，以及 CSS 中存在 z-index，因此是很容易实现的。
在<canvas>元素中建立UI
相比 HTML＋CSS，canvas 则有些先天不足，缺少非常多在 HTML + CSS 中理所当然的特性。
文本
canvas有一个很简单的 API 用于绘制文字：fillText(text, x, y [, maxWidth])这个函数接受三个参数：文字本身以及绘制起点的x,y坐标。但 canvas 只能一次绘制一行文字。如果你需要让文字换行，需要自己写函数。
图片
你可以使用drawImage()函数在 canvas 上绘制图片。这是个可变参数函数,你可以指定更多参数，从而控制定位和裁切。但是canvas不在乎图像是否加载，或不能确定只在图像加载事件后调用函数。
元素层叠
通过 DOM 元素的顺序或使用 CSS 的 z-index属性，在 HTML 和 CSS 指定一个元素是否在另一个上应该很容易。但请记住，canvas 是立即模式的绘图 API。当元素重叠或者其中一个需要重绘时,都必须以同一顺序重新绘制（或至少局部重绘）。
译者注 关于局部重绘提高性能的文章大家可以参考:《提高HTML5 canvas性能的几种方法（转）》
自定义字体
需要使用一个自定义 web 字体吗? canvas 的文本 API 并不在乎字体是否加载。你需要一种方法来知道一个字体是否加载，并绘制任何依赖此字体的区域。幸运的是,现代浏览器有一个基于promise的API。不幸的是, iOS WebKit (iOS 8 时)不支持它。
<canvas>的优点
鉴于所有这些缺点,人们开始质疑 canvas 来代替 DOM 这一选择。最终，我们的讨论由一个很简单的真理来决定：你不能基于 dom 建立一个60 fps的滚动列表视图。
许多人(包括我们)已经尝试过,但都失败了。可滚动的元素可以在纯 HTML 和 CSS 中通过 overflow:scroll 实现：(结合 IOS 上的 -webkit-overflow-scrolling:touch ),但这些不能在滚动动画中给予你逐帧控制，同时移动浏览器很难处理又长又复杂的内容。
为了构建一个内含相当复杂的内容的无限滚动列表,我们需要在 web 端实现一个UITableView
与 DOM 相比,今天的大多数设备都有基于硬件加速的 canvas 实现，可以直接发送绘图命令到 GPU。这意味着我们可以非常快的渲染元素;在许多情况下,我们所说的是毫秒级的范围。
相比 HTML + CSS , canvas 也是一个非常“苗条”的 API ，这减少了界面上的 bug 或浏览器之间的不一致性。有一个理由更加直接，canvas 没有 Can I Use?。
译者注 UITableView 是 IOS 控件
更快的 DOM 抽象
如前所述,为了有点效果,我们需要一个更高层次的抽象，而不是简单地绘制矩形、文本和图像。我们构建了一个非常小的抽象,允许开发人员处理一个节点树,而不是处理一个严格的绘图命令序列。
渲染层
渲染层( RenderLayer )是基本节点,其他节点建立在其上。常见的属性如 top,left,width,height,backgroundColor 和 zIndex 在这个层展现。 RenderLayer 只不过是一个普通的 JavaScript 对象，包含这些属性和一个子元素数组。
图像
我们使用图像层的附加属性来指定图像 URL 和信息。你不必担心图像加载事件的监听,图像层会处理后将一个信号发送到绘图引擎来表示图片需要更新。
文本
文本层可以显示多行文本截断,这在 DOM 里处理成本非常高。文本层还支持自定义字体,也会处理当字体加载完毕后更新的动作。
合成
这些层可以合成起来以便构建复杂的界面。下面是一个渲染层树
{
frame: [0, 0, 320, 480],
backgroundColor: '#fff',
children: [
{
type: 'image',
frame: [0, 0, 320, 200],
imageUrl: 'http://lorempixel.com/360/420/cats/1/'
},
{
type: 'text',
frame: [10, 210, 300, 260],
text: 'Lorem ipsum...',
fontSize: 18,
lineHeight: 24
}
]
}
无效层
当一个层需要重绘,例如一个图像加载后,它发送一个信号到绘图引擎表示其框架是脏( dirty )的。这些修改使用 requestAnimationFrame来批量处理，避免布局抖动，之后在下一帧画布重绘。
达到60fps的滚动
对于 web 端，也许我们最理所当然关注的，是浏览器如何来滚动网页。浏览器厂商已经竭尽全力提高滚动性能。
这其实是一个妥协。为了达到60 fps 的滚动指标，移动浏览器在执行滚动期间，停止 JavaScript 的执行，这是怕 DOM 修改导致回流。最近, IOS 和 Android 暴露了 onScroll 事件，他们的工作过程更像桌面浏览器了,但如果你试图在滚动时保持 DOM 元素的位置同步，具体的实现可能会有差别。
幸运的是,浏览器厂商已经意识到这个问题。特别是 Chrome 团队已经开放了为了改善手机端这种情况所做的工作。
回到 canvas ,简短的回答是你必须用 JavaScript 实现滚动。
你首先需要的是一种计算滚动程度的算法。如果你不想研究数学，Zynga 开源的纯滚动实现,适合任何类似此布局的情况。
我们使用一个 canvas 元素来完成滚动。在每一个触摸事件时,根据当前的滚动程度去更新渲染树。之后，整个渲染树使用新的坐标来重新渲染。
这听起来令人难以置信的慢,在 canvas 上可以使用一个重要的优化技术--画布上绘图操作的结果可以在离屏层（off-screen）canvas 被缓存。离屏层（off-screen）之后可以用来重新绘制层。
这种技术不仅可以用于图像层,文本和图形也适用。两个成本最高的绘图操作是填充文本和图像。但是一旦这些层绘制一次以后,接下来使用离屏层重新绘制他们是非常快的。
在上面的演示中,每个页面的内容分为两层:图像层和文本层。文本层包含多个元素组合在一起。每一帧滚动动画中，这两层都使用位图缓存来重绘。
对象池
在一个无限列表的滚动过程中,大量的 RenderLayers 会被建立和销毁。这会在内存中创建大量的垃圾,当进行垃圾收集时将停止主线程。
为了避免产生大量垃圾, RenderLayers 与相关对象汇集到一个池中。这意味着只有相对较少的层对象被创建。当不再需要时,它会被释放回池中,之后可以重用。
极速快照
缓存复合层的特性可以带来另一个优势:能够将渲染的部分结构作为一个位图。你有没有建立部分 DOM 结构快照的需求?当你将这些结构渲染在 canvas 时，速度会快得令人难以置信。这个将一个项目放入一本杂志的界面，利用了这种特性来执行一个时间轴维度的平稳过渡。快照包含去掉顶部和底部的整个项目。
一个声明式的 API
现在我们已经拥有了构建一个应用程序的砖块。然而,通过命令来构建 RenderLayers 可能是乏味的。如果我们有个类似于DOM工作方式的声明式 API 不是很好么?
React
我们是 React 框架的忠实粉丝。它的单一定向的数据流和声明式API已经改变了人们构建应用程序的方式。react最引人注目的特征就是虚拟 DOM (virtual DOM)。呈现为HTML容器只是它在浏览器中的一个简单实现。最近引入的 React Native 证明了这一点。
如果我们将我们的 canvas 布局引擎与 react 组件结合起来会咋样?
React Canvas简介
React Canvas 使React组件拥有了渲染到canvas的能力。
第一个版本的 canvas 布局引擎看上去很像命令式的代码。如果你做过 JavaScript DOM 操作你可能会运行过这样的代码:
// Create the parent layer
var root = RenderLayer.getPooled();
root.frame = [0, 0, 320, 480];
// Add an image
var image = RenderLayer.getPooled('image');
image.frame = [0, 0, 320, 200];
image.imageUrl = 'http://lorempixel.com/360/420/cats/1/';
root.addChild(image);
// Add some text
var label = RenderLayer.getPooled('text');
label.frame = [10, 210, 300, 260];
label.text = 'Lorem ipsum...';
label.fontSize = 18;
label.lineHeight = 24;
root.addChild(label);
当然,这样能完成效果，但是谁想这样写代码?除了容易出错,也很难想象出渲染结果
使用React Canvas则变成下面这样：
var MyComponent = React.createClass({
render: function () {
return (
<Group style={styles.group}>
<Image style={styles.image} src='http://...' />
<Text style={styles.text}>
Lorem ipsum...
</Text>
</Group>
);
}
});
var styles = {
group: {
left: 0,
top: 0,
width: 320,
height: 480
},
image: {
left: 0,
top: 0,
width: 320,
height: 200
},
text: {
left: 10,
top: 210,
width: 300,
height: 260,
fontSize: 18,
lineHeight: 24
}
};
您可能会注意到,一切都似乎是绝对定位实现的。确实是这样。我们的canvas渲染引擎的诞生，就伴随着驱动像素级布局，实现多行文本过长省略的使命。传统的CSS不能做到这一点,所以绝对定位的方式对我们来说很适合。然而,这种方法并不适合于所有应用程序。
css布局
Facebook 最近开源的CSS的JavaScript实现。他支持 CSS 的一些子集，包括 margin、padding,position 和最重要的 flexbox。
将 css 布局整合到 React Canvas 只是一个时间问题。看看这个例子,看看我们是如何改变组件样式的。
声明式的无限滚动
你如何在 React Canvas 中创建一个达到60 fps ,无限,分页的滚动列表？事实证明这实现起来非常容易,因为 react 会做虚拟 DOM 的 diff 。在render() 函数中只有当前可见的元素被返回，React负责更新滚动期间所需的虚拟 DOM 树。
var ListView = React.createClass({
getInitialState: function () {
return {
scrollTop: 0
};
},
render: function () {
var items = this.getVisibleItemIndexes().map(this.renderItem);
return (
<Group
onTouchStart={this.handleTouchStart}
onTouchMove={this.handleTouchMove}
onTouchEnd={this.handleTouchEnd}
onTouchCancel={this.handleTouchEnd}>
{items}
</Group>
);
},
renderItem: function (itemIndex) {
// Wrap each item in a <Group> which is translated up/down based on
// the current scroll offset.
var translateY = (itemIndex * itemHeight) - this.state.scrollTop;
var style = { translateY: translateY };
return (
<Group style={style} key={itemIndex}>
<Item />
</Group>
);
},
getVisibleItemIndexes: function () {
// Compute the visible item indexes based on `this.state.scrollTop`.
}
});
为了勾住（捕获）滚动,我们在列表视图组件中，调用Scroller(滚动组件)的 setState() 方法。
...
// Create the Scroller instance on mount.
componentDidMount: function () {
this.scroller = new Scroller(this.handleScroll);
},
// This is called by the Scroller at each scroll event.
handleScroll: function (left, top) {
this.setState({ scrollTop: top });
},
handleTouchStart: function (e) {
this.scroller.doTouchStart(e.touches, e.timeStamp);
},
handleTouchMove: function (e) {
e.preventDefault();
this.scroller.doTouchMove(e.touches, e.timeStamp, e.scale);
},
handleTouchEnd: function (e) {
this.scroller.doTouchEnd(e.timeStamp);
}
...
尽管这是一个简化版本，但展示了 React 一些最优秀的特性。触摸事件被声明式绑定在 render()函数中。每个 touchmove 事件被转发到 Scroller 中来计算当前滚动的偏移。每个 Scroller 发出的滚动事件则用于更新状态列表视图组件,只对当前屏幕可见的元素进行渲染。所有这一切发生在16ms以下,因为 react 的 diff 算法非常快。
你可以查看这个滚动列表完整实现的源代码。
实际应用
React Canvas 并不能完全取代 DOM。我们在我们的移动 web app 中，性能要求最关键的地方去使用，主要是滚动时间轴视图这部分。
当渲染性能不是问题的时候, Dom 可能是一个更好的方法。事实上,对某些元素输入字段和音频/视频等，这是唯一的方法
从某种意义上说, Flipboard 的移动 web 是一个混合( hybird )的应用程序。相比传统的原生应用和网络技术结合的方式, Flipboard 的内容全部是 web 内容。它的 UI 基于 dom 实现，并在适当的地方使用 canvas 渲染。
可访问性
这个领域需要进一步探索。使用降级内容( canvas 的 DOM 子树)应该允许 VoiceOver 这样的屏幕阅读器与内容交互。我们在测试的设备上看到了不同的结果。另外，关于焦点的管理也有标准，但目前暂时不被浏览器支持。
Bespin在2009年提出的一种方法,是元素渲染到 canvas 时，同时维护一个平行Dom，用于元素同步。我们正在继续研究实现可访问性的正确方法。
结论
在追求60 fps 的过程中，我们有时会采取极端措施。 Flipboard 为研究移动网络的局限性提供了一个案例。虽然这种方法可能并不适用于所有应用程序,我们将应用的交互和性能水平提升到可以与本地应用相竞争。我们希望通过开放我们在 React Canvas 中所做的工作,可以让其他引人注目的例子出现。
用手机访问flipboard.com，体验一下。或者如果你没有 Flipboard 账户,体验一下 Flipboard 上一系列的杂志。请让我们获得你的想法。
特别感谢 Charles, Eugene 和 Anh 的编辑和建议。
http://jcodecraeer.com/a/qianduankaifa/css3/2015/0305/2549.html
