一种自动化生成骨架屏的方案

今天分享的主题是：「一种自动化生成骨架屏的方案」， 先看下市场上常见的骨架屏优化效果。

今天的分享主要分为三个部分：

1. 首屏加载状态演进
2. 如何构建骨架屏
3. 将骨架屏打包的项目中

首屏加载的演进

我们先来看一些权威机构所做的研究报告。

一份是 Akamai 的研究报告，当时总共采访了大约 1048 名网上购物者，得出了这样的结论：

• 大约有 47% 的用户期望他们的页面在两秒之内加载完成。

• 如果页面加载时间超过 3s，大约有 40% 的用户选择离开或关闭页面。

这是 TagMan 和眼镜零售商 Glasses Direct 合作进行的测试，研究页面加载速度和最终转化率的关系：

在这份测试报告中，发现了网页加载速度和转化率呈现明显的负相关性，在页面加载时间为1~2 秒时的转化率是最高的，而当加载时间继续增长，转化率开始呈现一个下降的趋势，大约页面加载时间每增加 1s 转化率下降6.7个百分点。

另外一份研究报告是 MIT 神经科学家在 2014 年做的研究，人类可以在 13ms 内感知到离散图片的存在，并将图片的大概信息传输到我们的大脑中，在接下来的 100 到 140ms 之间，大脑会决定我们的眼睛具体关注图片的什么位置，也就是获取图片的关注焦点。从另一个角度来看，如果用户进行某项交互（比如点击某按钮），要让用户感知不到延迟或者数据加载，我们大概有 200 ms 的时间来准备新的界面信息呈现给用户。

在 200ms 到 1s 之间，用户似乎还感知不到自己处在交互等待状态，当一秒钟后依然得不到任何反馈，用户将会把其关注的焦点移到其他地方，如果等待超过 10s，用户将对网站失去兴趣，并浏览其他网站。

那么我们需要做些什么来留住用户呢？

通常方案，我们会在首屏、或者获取数据时，在页面中展现一个进度条，或者转动的 Spinner。

• 进度条：明确知道交互所需时间，或者知道一个大概值的时候我们选择使用进度条。

• Spinner：无法预测获取数据、或者打开页面的时长。

有了进度条或者 Spinner，至少告诉了用户两点内容：

• 你所进行的操作需要等待一段时间。

• 其次，安抚用户，让其耐心等待。

除此之外，进度条和 Spinner 并不能带来其他任何作用，既无法让用户感知到页面加载得更快，也无法给用户一个焦点，让用户将关注集中到这个焦点上，并且知道这个焦点即将呈现用户感兴趣的内容。

那么有没有比进度条和 Spinner 更好的方案呢？也许我们需要的是骨架屏。

其实，骨架屏（Skeleton Screen）已经不是什么新奇的概念了，Luke Wroblewski 早在 2013 年就首次提出了骨架屏的概念，并将这一概念成功得运用到他当时的产品「Polar app」中，2014 年，「Polar」加入 Google，Luke Wroblewski 本人也成为了Google 的一位产品总监。

A skeleton screen is essentially a blank version of a page into which information is gradually loaded.

他是这样定义骨架屏的，他认为骨架屏是一个页面的空白版本，通过这个空白版本传递信息，我们的页面正在渐进式的加载过程中。

苹果公司已经将骨架屏写入到了 iOS Human Interface Guidelines ,只是在该手册中，其用了一个新的概念「launch images」。在该手册中，其推荐在应用首屏中包含文本或者元素基本的轮廓。

2015 年，Facebook 也首次在其移动端 App 中使用了骨架屏的设计来预览页面的加载状态。

随后，Twitter，Medium，YouTube 也都在其产品设计中添加了骨架屏，骨架屏一时成为了首屏加载的新趋势，国内一些公司也紧随其后，饿了么、知乎、掘金、腾讯新闻等也都在其 PC 端或者移动端加入了骨架屏设计。

为什么需要骨架屏？

• 在最开始关于 MIT 2014 年的研究中已有提到，用户大概会在 200ms 内获取到界面的具体关注点，在数据获取或页面加载完成之前，给用户首先展现骨架屏，骨架屏的样式、布局和真实数据渲染的页面保持一致，这样用户在骨架屏中获取到关注点，并能够预知页面什么地方将要展示文字什么地方展示图片，这样也就能够将关注焦点移到感兴趣的位置。当真实数据获取后，用真实数据渲染的页面替换骨架屏，如果整个过程在 1s 以内，用户几乎感知不到数据的加载过程和最终渲染的页面替换骨架屏，而在用户的感知上，出现骨架屏那一刻数据已经获取到了，而后只是数据渐进式的渲染出来。这样用户感知页面加载更快了。

• 再看看现在的前端框架，