骨架屏（skeleton screen），每个前端都爱用。它不仅能提升用户体验，制作起来也简单，数据上（FP，首次渲染）也好看，基本上是无脑上不会有错的。
如今大部分关于骨架屏的探讨在于如何借助工具来快速生成骨架屏，虽然这种流水线式的骨架屏即使不借助工具，也不会耗费开发太多时间。反而大家不太会去关注，骨架屏应该做成什么样，它的底层逻辑是什么，什么是好的骨架屏？
本文通过回顾骨架屏的前世今生，并结合货拉拉的真实案例，来探讨下骨架屏背后的思想，以及如何做出更好的骨架屏。
打破沉寂
界面没有反馈，会让用户觉得不安，这是一个自人机交互诞生以来就存在的问题。这在如今移动互联网场景下，就是我们常说的「白屏」问题。所以，「自古」以来，遇到需要用户等待的场景，都要搞点小动画来打破尴尬，例如大家熟悉的「无限滚动条」和「转圈圈」：
早期的货拉拉：
一方面告诉用户「我还在运转，没有出故障」，另一方面吸引用户注意力，让等待的时间不那么无聊。
骨架屏诞生
但是时间久了，大家便不满足于这些小动画，它既不反映实际的加载进度，和后面要出现的内容也毫无关系，如果停留时间过久反而让用户更加疲惫，觉得时间过得更慢了。随着移动互联网时代到来，人们对体验越来越重视，于是体验更好的「骨架屏」就被发明了出来。
根据当前能查到的资料，最早介绍骨架屏的文章出现于 2013年：LukeW | Mobile Design Details: Avoid The Spinner
顾名思义，在数据和资源还在加载中时，先展示一个页面的「骨架」，让用户知道接下来的页面大致长什么样，然后逐步的填充里面的内容。一般来说，应用在加载数据和资源时比较耗时，但是页面的框架结构是可以预先确定好的，把这部分信息通过骨架屏尽快传达给用户，让用户感受到页面的进展，产生「页面马上就好了」的预期（为何我联想到了PDD再砍一刀），同时也使整个加载过程更连贯，界面变化不那么突兀。
总结一下，骨架屏的优势在于：
粗糙的骨架屏
以其独特的优势，骨架屏迅速开始流行起来，并且催生了看似丰富的生态。
一些 UI 库提供了现成的骨架屏组件，实现了「拿来即用」。
有人觉得组件库还是太麻烦，于是开发了自动化工具，可以根据现有的页面自动生成与之匹配的骨架屏。
这些眼花缭乱的「生态」吸引了大部分人的注意力，以至于在谈论到骨架屏时，大家都在比拼如何「快速」、「省事」地给应用装上一个骨架屏。
案例1：
一个应用原来的加载过程是：
空白 -> 转圈圈 -> 内容
老板提议用骨架屏优化一下，开发用 UI 组件库很快速的就搞定了，于是加载过程变成了：
空白 -> 转圈圈 -> 骨架屏 ->内容
老板：？？？为什么还有转圈圈
开发：你就说我做的快不快吧！
老板：能不能把转圈圈也搞成骨架屏啊？
开发：这个骨架屏是个 react 组件，你懂不？react 得在 mount 之后才能看到，mount 之前还是得用转圈圈......
老板：我虽然不懂 react 但我略懂 html，你直接把骨架屏放做到原生 html 里不行吗？
开发：得加时间...
可见，用了工具，就会受限于工具。骨架屏的意义之一就在于「以最快的速度给用户带来反馈」，好的做法是直接放到原生的 html 模板中。但是工具的泛滥让大家变懒了，于是变成了「以最快的速度应付老板的需求」。
案例2：
小程序的开发工具，也集成了自动生成骨架屏的功能：
生成的骨架屏类似这样：
这能用？好吧没关系，我们基于它生成的代码进行修改，也能省不少事，打开代码看看：
额这
小程序的包体积本来就有上限，这下雪上加霜。
...
finally 我们终于拿到了一个还不错的骨架屏，把它装上试试：
感觉有点突兀呢，而且好像等的时间更长了？
之前是哪个接口先返回就先渲染对应的模块，虽然有点杂乱吧，但好歹是渐进式的，让人能先看到一些东西。用了这个所谓「骨架屏」，反而要等到最慢的接口返回以后，才「啪的一下」全部出现。
这与其说是骨架屏，不如说是「启动屏」（splash screen），还不如转圈圈，转圈圈起码不会把整个页面都挡住。
本来是想省事，结果更加费事，效果还没有达到预期。
好的骨架屏
「什么都是现成的只会害了你」，「无脑」让人丢掉了思考，忽视了骨架屏的本意。
回顾下骨架屏的核心思想：及时反馈、连贯性，让我们以此出发来做一个真正有效的骨架屏。
更细粒度的变化
可能骨架屏的「屏」字产生了误导，让大家以为骨架屏一定是覆盖了整个屏幕。其实更应该关注的是「骨架」，即整个加载流程是一个先有骨架然后逐步的填充的过程。
如下所示（为了展示效果，特意放慢了速度）：
可以看出，我们把一个大的骨架「屏」拆分到了各个组件中，由各个模块独立控制自己的骨架屏，相较于原始的随接口实时加载，变化更加丝滑流程，让人产生确定的期望，不会有突兀感。
彩色骨架屏
骨架屏往往被设计成淡灰色，因为比较不显眼，不会占用用户过多注意力，后面无论被什么样的内容替换掉，都不会太突兀。
但如果要加载的内容本身有比较确定的颜色，那骨架屏也可以是彩色的。如下图，包括颜色和一些铁定不会变的文字，都可以是骨架屏的一部分：
这体现了骨架屏的「及时反馈」原则，只要是确定的，准备好的东西，就尽快的反馈给用户。
骨架屏动效
回顾前面说的「打破沉寂」，会动的画面会减少用户的焦虑，骨架屏如果再动起来是不是更好。
例如这种闪烁的光影，好像是比不会动的要好那么一点点？
但是这种闪烁的光影没有体现出连贯性，它只是一个大号的无限进度条或转圈圈。
一种比较好的做法是把骨架屏本身的加载也变成连贯的动画：
这个骨架屏有一个渐进出现的效果，你可能意识不到这个动画花费了400毫秒，用户往往会忽略这个时间，不认为是白等，因为他们观察到了页面在发生「进展」，这就是细粒度变化的好处。手机系统动画做得好，会让人觉得系统更流畅，也是这个道理（不信你把系统动画关了试试）。
终极骨架屏
至此，我们的骨架屏看起来已经很完美了，但，还不是最好。
骨架屏本身是一个过渡状态，是为了掩盖加载的时延。而且由于加载一个骨架本身就非常快，这会让一些性能指标非常好看，例如 FP（首次渲染），FCP（首次内容渲染）。但是用户看到骨架屏并不意味着页面加载完成，反而是「加载刚刚开始」。骨架屏不仅会麻痹用户也会麻痹开发，让他们忽略真正需要做的优化：优化接口响应速度，优化资源加载速度，优化程序运行效率，这些实实在在的优化将会使骨架屏的展示时间越来越短。
因此在上了骨架屏之后，并非就万事大吉了，骨架屏的终极目标应当是：「让骨架屏消失」。
真的能实现吗？无论怎么优化，毕竟还有网络、客户机性能等无法掌控的客观因素，让骨架屏真正消失是不现实的。那有没有办法让用户「感觉」骨架屏已经消失了呢？
一个案例：
