1、网上找到一个大神的方案
https://github.com/jayZOU/skeleton
但是有几个比较大的缺陷：
1、生成的骨架屏是一个整体，不能做到局部渐进渲染替换；
2、只能做出小的矩形和圆形的效果，不能做出页面楼层分离的效果，也就是还原不太漂亮（不过可以通过自己修改大神的代码，逐步完善）；
3、它是一个组件，会在拿到页面模板后才开始生成骨架屏，所以有很大的性能问题，不能在一进页面就显示出来，数据请求很慢的情况下才会有比较好的作用和效果，不然根本看不到骨架屏😂。
4、业务代码侵入性较强，需要给业务代码添加class区分是矩形还是圆形，（完美的最好是根据模板的标签和内容节点来自动判断是什么形状的阴影）；
2、后来无意中发现小程序开发工具有一个生成骨架屏的功能
缺陷：
1、自动化程度太低；
2、代码增加小程序体积；
3、对于一些节点的生成很不准确，页面骨架还原效果不咋地：
生成骨架屏的按钮在这里：
最终先使用开发工具生成 的方案吧！
3、后续会研究如何做成一个：非侵入式，渐进渲染，参考imageloader加载器，的骨架屏。
参考文章：https://www.geek-share.com/detail/2776148638.html
4、另附：你需要了解的前端骨架屏注入实践
https://www.sohu.com/a/328224496_463987
通过这篇文章，可以了解：为什么要使用骨架屏？骨架屏的几种方案？
5、总结：
最棒的结果当然是页面有多个局部骨架，渐进式的渲染，并且页面图片能做到懒加载效果（微信小程序的image标签的lazy-load并不是我们期待的懒加载效果）
6、 后来发现了京东的骨架屏方案，下文节选于：凹凸实验室：京喜小程序的高性能打造之路
一方面，我们可以从降低网络请求时延、减少关键渲染的节点数这两个角度出发，缩短完成 FMP（首次有效绘制）的时间。另一方面，我们也需要从用户感知的角度优化加载体验。
“白屏” 的加载体验对于首次访问的用户来说是难以接受的，我们可以使用尺寸稳定的骨架屏，来辅助实现真实模块占位和瞬间加载。
骨架屏目前在业界被广泛应用，京喜首页选择使用灰色豆腐块作为骨架屏的主元素，大致勾勒出各模块主体内容的样式布局。由于微信小程序不支持 SSR（服务端渲染），使动态渲染骨架屏的方案难以实现，因此京喜首页的骨架屏是通过 WXSS 样式静态渲染的。
有趣的是，京喜首页的骨架屏方案经历了 “统一管理” 和 “（组件）独立管理” 两个阶段。出于避免对组件的侵入性考虑，最初的骨架屏是由一个完整的骨架屏组件统一管理的：
<!-- index.wxml -->
<skeleton wx:if="{{isLoading}}"></skeleton>
<block wx:else>
页面主体
</block>
但这种做法的维护成本比较高，每次页面主体模块更新迭代，都需要在骨架屏组件中的对应节点同步更新（譬如某个模块的尺寸被调整）。除此之外，感官上从骨架屏到真实模块的切换是跳跃式的，这是因为骨架屏组件和页面主体节点之间的关系是整体条件互斥的，只有当页面主体数据 Ready（或渲染完毕）时才会把骨架屏组件销毁，渲染（或展示）主体内容。
为了使用户感知体验更加丝滑，我们把骨架屏元素拆分放到各个业务组件中，骨架屏元素的显示/隐藏逻辑由业务组件内部独立管理，这就可以轻松实现 “谁跑得快，谁先出来” 的并行加载效果。除此之外，骨架屏元素与业务组件共用一套 WXML 节点，且相关样式由公共的 sass 模块集中管理，业务组件只需要在适当的节点挂上 skeleton 和 skeleton__block 样式块即可，极大地降低了维护成本。
<!-- banner.wxml -->
<view class="{{isLoading ? 'banner--skeleton' : ''}}">
<view class="banner_wrapper"></view>
</view>
// banner.scss
.banner--skeleton {
@include skeleton;
.banner_wrapper {
@include skeleton__block;
}
}
[图片上传失败...(image-26fccc-1591845908496)]
上面的 gif 在压缩过程有些小问题，大家可以直接访问【京喜】小程序体验骨架屏效果。
