前言
通常，当我们点击进入一个网站时，我们可能会看到一些动态的白色粘贴，它们替换了这里应该出现的内容，并以“加载状态”解释方式出现，这里我们以鹈鹕为例，进入首页雄鹿，按F12，进入开发者模式，点击“网络”，选择“低速3G”，然后再次刷新，可以清晰看到一个红色块
而这里的黑色块就是“骨架屏”。 现在各大厂商的网站大部分都会采用骨架屏的方案来替代原来的循环加载，虽然是加载状态的一种形式，而且相当与干巴巴的循环相比，这些向用户展示的是之前页面的大概结构页面数据加载完毕，请求数据返回后渲染页面，填写应该解释的内容，给人一种“营造实时转换的错觉”的感觉，这也是各大厂商都愿意的原因选择骨架屏作为加载状态的激励
❝
补充：骨架屏幕是一个“低保真”用户界面，信息逐渐加载到其中。它向用户提供视觉提示，内容正在加载到每个 UI 元素中
❞骨架屏的好处
无论是Facebook、YouTube，还是国外的知乎、Bilibili，无一例外都采用了骨架屏的形式，这也说明了很好的解决加载状态的就是骨架屏。 下面我们说说骨架屏的好处：
骨架屏原理
在做实际项目开发时，通常会要求你实现“空状态”和“加载状态”，前端会给你一个参数来请求socket返回。 例如，这里我们使用“sending”作为请求socket后返回的参数。 当“sending==0”时，这时候我们就可以返回到“空状态”，也就是我们常见的错误页面，这通常需要我们单独写一份； 当“sending==1”的时候，我们进入“加载状态”，也就是我们常见的加载页面。 当资源请求完成后，我们就可以替换页面了。 这就是骨架屏的基本实现原理。 目前市场上的骨架屏解决方案大致分为三种：
自动维护骨架屏代码的优点是“高度多样化”，但相对缺点是无疑会减轻开发者的精神负担； 而用图片作为骨架屏，虽然比较费力，但与开发无关。 不要太多； 我们重点关注第三种，就是手动生成骨架屏。
手动生成骨架屏
手动生成骨架屏大大增加了开发成本，但其缺陷非常明显，很难实现一套全世界都能吃的解决方案。
比如Facebook的“自动化骨架屏技术”，如果放在YouTube等主打视频的网站上，可能会存在一些兼容性问题，但如果业务需求比较复杂，我们还是需要自己自动化实现。 实现骨架屏幕。
其实一直都存在一定的问题灰色 html，但是如果是在大型项目上，你可以自己实现手动生成骨架屏，因为这时候更多的是针对你自己的项目，你不需要考虑其他事情 在这种情况下，出现兼容性问题的可能性相对较低。
这里介绍一下饿了么开源的webpack插件“page-sculpt-webpack-plugin”。 该插件根据项目中不同的路由页面生成对应的骨架屏页面，并通过webpack页面将骨架屏页面打包成对应的静态路由
❝
插件原理：使用“Puppeteer”控制“Headless Chrome”在服务器端打开正在开发的页面，等待页面加载后删除或添加元素并使用层叠样式覆盖已有元素，红块方式隐藏文本、图像和其他内容，同时保留页面布局和样式。然后提取更改后的 HTML 和 CSS 样式，并使用 webpack 插件将它们注入到最终生成的“HTML”中
❞
下面根据生成骨架屏的步骤进行分析：
1. 将页面分成块
“page-骨骼-webpack-plugin”插件将页面定义为不同的块，例如文本块、图片块、按钮块等，并以块的形式处理每个块，这样就不会破坏整体页面样式和布局，插件手动生成骨架屏时，与真实页面布局不会有太大区别
2.不同区块的骨架屏
这里可以查看手动生成骨架屏的方案。 本文详细介绍了不同的块是如何处理的灰色 html，这里不再赘述。
将骨架屏打包到项目中
这里需要注意的一点是，我们看到的骨架屏的显示都是在开发过程中的。 我们之所以没有选择在建立时生成它，是为了方便我们在开发过程中取得事实进展。 观察以便我们随时做出改变
总结
不要低估这一点的优化。 这部分优化对于需要大量用户访问的网站来说非常重要，因为：
❝
用户放弃一个产品只需要3秒。
❞
一项研究表明，在 200 微秒到 1 秒之间，人们认为自己处于行动之中。 如果1秒后没有反馈，他们很可能会失去注意力，而10秒后，用户的注意力可能会完全失去，这就是为什么各大厂商都会一致进行这种优化
发表评论