骨架屏怎么提升性能的？骨架屏的原理及实现

笔试题（6 题）

1. 骨架屏的作用

骨架屏是什么？它怎么提升性能和用户体验？从性能指标角度分析（FCP、LCP、CLS）。

【作答】：

骨架屏定义: 骨架屏（Skeleton Screen）是一种页面加载占位符技术，通过展示页面的大致结构轮廓（如灰色矩形块、圆形占位符等），模拟真实内容的布局，在数据加载完成前给用户提供视觉反馈。

提升性能的机制:

提前渲染: 骨架屏 HTML 体积小，可以快速渲染，避免白屏
减少感知延迟: 用户看到内容结构，心理上感觉加载更快
保持布局稳定: 骨架屏与真实内容布局一致，减少 CLS（累积布局偏移）
降低用户焦虑: 视觉反馈让用户知道页面正在加载，而非卡死

对性能指标的影响: FCP (First Contentful Paint):

骨架屏 HTML 体积小（通常<5KB），可以快速渲染
内联在 HTML 中时，FCP 时间可提前到 HTML 解析完成时
相比白屏，FCP 提前 200-500ms

LCP (Largest Contentful Paint):

如果骨架屏是 LCP 元素，可以提前 LCP 时间
但需要注意：真实内容加载后，LCP 会重新计算
最佳实践：确保真实 LCP 元素（如首屏图片）尽快加载

CLS (Cumulative Layout Shift):

骨架屏与真实内容布局一致时，CLS 接近 0
如果布局不匹配，会导致较大的 CLS
关键：保持骨架屏与真实内容的尺寸、位置、间距一致

用户体验提升:

减少感知等待时间: 用户看到结构，感觉加载更快
降低跳出率: 有视觉反馈，用户更愿意等待
提升品牌形象: 专业、细致的交互设计
改善弱网体验: 在慢网络下，骨架屏提供即时反馈

2. 骨架屏实现方式

骨架屏有哪些实现方式（手写、自动生成、SSR 内联、图片占位）？各自的优缺点？

【作答】：

手写骨架屏: 优点:

完全可控，可以精确匹配真实内容布局
体积小，性能最优
样式和动画可以完全自定义
不依赖额外工具，实现简单

缺点:

开发成本高，每个页面都需要单独编写
维护成本高，页面结构变化需要同步更新骨架屏
不适合动态内容或复杂布局
容易与真实内容不同步

自动生成: 优点:

开发效率高，可以批量生成
自动匹配真实内容结构
适合复杂页面和动态内容
维护成本低，可以自动化更新

缺点:

需要额外工具和构建流程
生成的代码可能不够精简
样式可能不够完美，需要手动调整
对动态内容的处理可能不够准确

SSR 内联: 优点:

首次渲染最快，无需等待 JS 执行
SEO 友好，搜索引擎可以看到内容结构
减少 FCP 时间
适合首屏关键内容

缺点:

增加 HTML 体积
需要服务端支持
缓存策略需要仔细设计
动态内容处理复杂

图片占位: 优点:

实现简单，只需替换图片 src
可以展示图片的宽高比
适合图片较多的页面

缺点:

只能占位图片，不能展示整体布局
图片加载可能影响性能
不够灵活，无法展示复杂结构
用户体验不如完整骨架屏

3. 骨架屏自动生成

如何自动生成骨架屏？Puppeteer 截图、DOM 结构分析、样式简化的原理？

【作答】：

Puppeteer 截图方案: 原理:

使用 Puppeteer 启动无头浏览器，访问目标页面
等待页面加载完成（或指定时间）
对页面进行截图，生成灰度/模糊版本
将截图转换为 SVG 或 Base64 内联图片
作为骨架屏使用

优点: 完全自动化，视觉效果好缺点: 体积大，需要服务端支持，生成时间长

DOM 结构分析: 原理:

分析真实页面的 DOM 结构
识别关键元素（文本、图片、按钮等）
提取元素的尺寸、位置、样式信息
生成对应的骨架屏 DOM 结构
简化样式（去除颜色、图片，保留布局）

实现步骤:

遍历 DOM 树，识别块级元素
提取元素的宽高、margin、padding
文本元素替换为灰色矩形
图片元素替换为灰色占位块
保留关键布局属性（flex、grid 等）

样式简化: 原理:

移除所有颜色相关属性（color、background-color、border-color 等）
统一使用灰色系（#f0f0f0、#e0e0e0 等）
移除背景图片，使用纯色或渐变
简化边框和阴影
保留布局相关属性（width、height、margin、padding、display 等）
移除动画和过渡效果（或简化为 shimmer 动画）

示例转换: 真实样式: background: linear-gradient(...), color: #333, border: 1px solid #ddd 骨架样式: background: #f0f0f0, border: none

完整流程:

开发阶段: 编写真实页面组件
构建阶段:
- 使用 Puppeteer 访问页面，或分析组件结构
- 生成骨架屏 HTML/CSS
- 内联到 HTML 或生成独立文件
运行时:
- 首次加载显示骨架屏
- 数据加载完成后，平滑过渡到真实内容
- 移除骨架屏 DOM

4. 骨架屏注入时机

骨架屏应该在什么时候注入？HTML 内联 vs JS 动态插入？SSR/SSG 下如何处理？

【作答】：

注入时机: 最佳时机: HTML 解析完成后立即显示，在 JS 执行和数据加载之前关键原则: 越早越好，减少白屏时间

HTML 内联: 实现方式:

将骨架屏 HTML 直接写在 HTML 文件的<body>中
或通过 SSR 在服务端渲染时注入
使用<style>标签内联 CSS

优点:

渲染最快，无需等待 JS
FCP 时间最短
SEO 友好
适合首屏关键内容

缺点:

增加 HTML 体积
需要服务端支持
缓存策略复杂
不适合动态路由

示例:

<html>
  <head>...</head>
  `<body>`
    <div class="skeleton">
      <div class="skeleton-header">...</div>
      <div class="skeleton-content">...</div>
    </div>
    \<script\>
      // 真实内容加载后移除骨架屏
      window.addEventListener('load', () => {
        document.querySelector('.skeleton').remove();
      });
    </script>
  </body>
</html>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

JS 动态插入: 实现方式:

在入口 JS 文件中，优先执行骨架屏渲染逻辑
使用 document.write 或 DOM 操作插入骨架屏
数据加载完成后移除

优点:

灵活，可以根据路由动态生成
不增加 HTML 体积
适合 SPA 应用
可以复用组件

缺点:

需要等待 JS 执行，FCP 稍慢
如果 JS 加载慢，可能看不到骨架屏
需要确保 JS 尽早执行

示例:

// main.js
function renderSkeleton() {
  const skeleton = document.createElement('div')
  skeleton.innerHTML = '<div class="skeleton">...</div>'
  document.body.appendChild(skeleton)
}

// 立即执行
renderSkeleton()

// 数据加载完成后
fetchData().then((data) => {
  renderRealContent(data)
  document.querySelector('.skeleton').remove()
})

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

SSR/SSG 下的处理: SSR (Server-Side Rendering):

在服务端渲染时，将骨架屏 HTML 内联到响应中
使用 React/Vue 的 SSR 能力，渲染骨架屏组件
客户端 hydration 时，平滑过渡到真实内容

SSG (Static Site Generation):

构建时生成包含骨架屏的 HTML
对于动态内容，使用占位数据渲染骨架屏
客户端激活后，替换为真实数据

Next.js 示例:

// pages/index.js
export default function Home({ initialData }) {
  const [data, setData] = useState(initialData)
  const [loading, setLoading] = useState(!initialData)

  return <div>{loading ? <SkeletonScreen /> : <RealContent data={data} />}</div>
}

// getServerSideProps 或 getStaticProps
export async function getServerSideProps() {
  // 服务端获取数据，如果慢则返回null，显示骨架屏
  const data = await fetchData()
  return { props: { initialData: data } }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

关键点:

SSR 下，如果数据获取快，直接渲染真实内容
如果数据获取慢，先渲染骨架屏，数据到达后更新
使用 React Suspense 可以更好地处理这种场景

5. 骨架屏与加载状态

骨架屏与传统 Loading（菊花图、进度条）的区别？什么场景用骨架屏，什么场景用 Loading？

【作答】：

骨架屏 vs Loading: 骨架屏:

展示页面结构轮廓，模拟真实内容布局
提供空间感知，用户知道内容的大致位置
适合内容加载场景
视觉上更自然，用户感觉内容"正在填充"

Loading (菊花图/进度条):

抽象的加载指示器，不展示内容结构
只表示"正在加载"状态
适合操作反馈（提交表单、上传文件等）
视觉上更明显，但信息量少

核心区别:

骨架屏: 展示"什么内容" + "在哪里"
Loading: 只展示"正在加载"

骨架屏适用场景:

内容展示页面: 列表页、详情页、首页等
首屏加载: 页面首次打开，数据加载中
分页加载: 列表翻页，新内容加载
路由切换: SPA 中路由切换，新页面加载
数据刷新: 下拉刷新，重新加载数据

典型场景:

电商商品列表页
新闻资讯详情页
社交媒体的信息流
后台管理的数据表格

Loading 适用场景:

操作反馈: 表单提交、文件上传、删除操作
短时加载: 加载时间<1 秒，不需要展示结构
全局加载: 整个应用初始化
不确定内容: 不知道会加载什么内容
模态操作: 弹窗、对话框中的操作

典型场景:

登录按钮点击后
文件上传进度
数据导出
API 请求（非内容展示）

组合使用: 最佳实践: 骨架屏 + 轻量 Loading 指示器

场景 1: 首屏加载

显示骨架屏（展示页面结构）
在骨架屏上叠加一个小的 loading 动画（表示正在加载）
数据到达后，平滑过渡到真实内容

场景 2: 操作反馈

用户点击"提交"按钮
按钮显示 loading 状态（防止重复提交）
如果操作会跳转页面，目标页面显示骨架屏

场景 3: 分步加载

首屏数据快速到达 → 直接显示内容
次要内容加载中 → 对应区域显示骨架屏
操作反馈 → 使用 Loading

示例代码:

function Page() {
  const [data, setData] = useState(null)
  const [submitting, setSubmitting] = useState(false)

  return (
    <div>
      {data ? (
        <Content data={data} />
      ) : (
        <SkeletonScreen>
          <LoadingSpinner size="small" /> {/* 叠加loading */}
        </SkeletonScreen>
      )}

      <button onClick={handleSubmit} disabled={submitting}>
        {submitting ? <LoadingSpinner /> : '提交'}
      </button>
    </div>
  )
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

6. 骨架屏动画效果

如何实现骨架屏的闪烁/渐变动画效果？CSS animation/shimmer 效果的实现？

【作答】：

/* 你的 CSS 实现 */

/* 方案1: Shimmer 闪烁效果（最常用） */
.skeleton {
  position: relative;
  background: #f0f0f0;
  overflow: hidden;
}

.skeleton::after {
  content: '';
  position: absolute;
  top: 0;
  left: -100%;
  width: 100%;
  height: 100%;
  background: linear-gradient(
    90deg,
    transparent,
    rgba(255, 255, 255, 0.6),
    transparent
  );
  animation: shimmer 1.5s infinite;
}

@keyframes shimmer {
  0% {
    left: -100%;
  }
  100% {
    left: 100%;
  }
}

/* 方案2: 脉冲效果 */
.skeleton-pulse {
  background: #f0f0f0;
  animation: pulse 1.5s ease-in-out infinite;
}

@keyframes pulse {
  0%,
  100% {
    opacity: 1;
  }
  50% {
    opacity: 0.6;
  }
}

/* 方案3: 渐变移动效果 */
.skeleton-gradient {
  background: linear-gradient(90deg, #f0f0f0 0%, #e0e0e0 50%, #f0f0f0 100%);
  background-size: 200% 100%;
  animation: gradient 1.5s ease-in-out infinite;
}

@keyframes gradient {
  0% {
    background-position: 200% 0;
  }
  100% {
    background-position: -200% 0;
  }
}

/* 方案4: 波浪效果 */
.skeleton-wave {
  background: #f0f0f0;
  position: relative;
  overflow: hidden;
}

.skeleton-wave::before {
  content: '';
  position: absolute;
  top: 0;
  left: -100%;
  width: 100%;
  height: 100%;
  background: linear-gradient(
    90deg,
    transparent 0%,
    rgba(255, 255, 255, 0.4) 50%,
    transparent 100%
  );
  animation: wave 2s infinite;
}

@keyframes wave {
  0% {
    left: -100%;
  }
  100% {
    left: 100%;
  }
}

/* 完整骨架屏组件示例 */
.skeleton-container {
  padding: 20px;
}

.skeleton-header {
  display: flex;
  align-items: center;
  margin-bottom: 20px;
}

.skeleton-avatar {
  width: 50px;
  height: 50px;
  border-radius: 50%;
  background: #f0f0f0;
  margin-right: 15px;
  position: relative;
  overflow: hidden;
}

.skeleton-avatar::after {
  content: '';
  position: absolute;
  top: 0;
  left: -100%;
  width: 100%;
  height: 100%;
  background: linear-gradient(
    90deg,
    transparent,
    rgba(255, 255, 255, 0.6),
    transparent
  );
  animation: shimmer 1.5s infinite;
}

.skeleton-text {
  flex: 1;
}

.skeleton-line {
  height: 16px;
  background: #f0f0f0;
  border-radius: 4px;
  margin-bottom: 10px;
  position: relative;
  overflow: hidden;
}

.skeleton-line::after {
  content: '';
  position: absolute;
  top: 0;
  left: -100%;
  width: 100%;
  height: 100%;
  background: linear-gradient(
    90deg,
    transparent,
    rgba(255, 255, 255, 0.6),
    transparent
  );
  animation: shimmer 1.5s infinite;
}

.skeleton-line.short {
  width: 60%;
}

.skeleton-line.medium {
  width: 80%;
}

.skeleton-line.long {
  width: 100%;
}

/* 性能优化：使用 will-change 和 transform */
.skeleton-optimized {
  will-change: transform;
}

.skeleton-optimized::after {
  transform: translateX(-100%);
  animation: shimmer-optimized 1.5s infinite;
}

@keyframes shimmer-optimized {
  0% {
    transform: translateX(-100%);
  }
  100% {
    transform: translateX(100%);
  }
}

/* 减少重绘：使用 opacity */
.skeleton-opacity {
  background: #f0f0f0;
  position: relative;
}

.skeleton-opacity::after {
  content: '';
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  background: rgba(255, 255, 255, 0.6);
  animation: fade 1.5s ease-in-out infinite;
}

@keyframes fade {
  0%,
  100% {
    opacity: 0;
  }
  50% {
    opacity: 1;
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221

面试题（4 题）

1. 骨架屏技术选型

给一个复杂页面设计骨架屏方案，你会如何选型（手写 vs 自动生成）？需要考虑哪些因素？

【作答】：

选型决策树:

页面复杂度
- 简单页面（<5 个区块）→ 手写
- 复杂页面（>10 个区块，动态布局）→ 自动生成
页面数量
- 少量页面（<10 个）→ 手写
- 大量页面（>20 个）→ 自动生成
更新频率
- 稳定页面（很少改动）→ 手写
- 频繁迭代 → 自动生成
团队规模
- 小团队（<5 人）→ 手写更灵活
- 大团队 → 自动生成，统一规范
性能要求
- 极致性能 → 手写（体积最小）
- 可接受稍大体积 → 自动生成

复杂页面选型方案:

方案 A: 混合方案（推荐）

首屏关键区域: 手写（精确控制，性能最优）
次要区域: 自动生成（快速开发）
动态内容: 使用通用骨架屏组件

方案 B: 分层骨架屏

Level 1: 页面级骨架屏（手写，展示整体布局）
Level 2: 组件级骨架屏（自动生成或组件库）
Level 3: 元素级骨架屏（通用组件）

具体实施:

分析页面结构
- 识别关键区块（Header、Content、Sidebar 等）
- 评估每个区块的复杂度
- 确定加载优先级
技术选型
- 核心首屏: 手写，内联 HTML
- 次要内容: 使用 React Skeleton 组件库
- 动态列表: 自动生成或模板化
工具选择
- 手写: 直接编写 HTML/CSS 或使用组件
- 自动生成:
  - page-skeleton-loader (Webpack 插件)
  - react-content-loader (React 组件)
  - vue-skeleton-webpack-plugin (Vue 插件)
实施步骤
- 第一步: 手写首屏骨架屏（MVP）
- 第二步: 评估效果，决定是否自动化
- 第三步: 建立组件库，统一规范
- 第四步: 逐步自动化非关键区域

需要考虑的因素:

开发成本
- 手写: 初期成本高，但长期维护简单
- 自动生成: 初期成本低，但需要工具维护
性能影响
- 骨架屏体积（HTML/CSS 大小）
- 渲染性能（DOM 复杂度）
- 动画性能（CSS 动画优化）
维护成本
- 页面结构变化时的同步成本
- 工具链的维护成本
- 团队学习成本
用户体验
- 骨架屏与真实内容的匹配度
- 过渡动画的流畅度
- 不同设备的适配
技术栈兼容性
- React/Vue/Angular 等框架支持
- SSR/SSG 支持
- 构建工具集成
团队能力
- 前端开发能力
- 工具开发能力
- 设计规范统一性

实际案例: 电商首页（复杂页面）:

顶部导航: 手写（固定结构）
Banner 轮播: 手写（关键首屏）
商品分类: 自动生成（动态内容）
商品列表: 使用组件库（可复用）
底部信息: 手写（简单结构）

决策结果: 混合方案

首屏手写，确保性能和体验
动态内容使用自动生成
建立组件库，提高复用性

2. 骨架屏性能优化

骨架屏本身也会影响性能（体积、渲染），如何优化？如何平衡骨架屏的精细度与性能？

【作答】：

性能问题分析:

体积问题
- HTML 体积过大，影响首屏加载
- CSS 体积过大，阻塞渲染
- 内联图片/Base64 体积大
渲染问题
- DOM 节点过多，解析慢
- 复杂 CSS 选择器，渲染慢
- 动画性能问题（重绘、重排）
内存问题
- 骨架屏 DOM 未及时清理
- 动画未正确销毁

优化策略:

体积优化
- HTML 优化: 简化 DOM 结构，减少嵌套，目标<3KB
- CSS 优化: 内联关键 CSS，压缩，目标<2KB
- 使用类名缩写
渲染优化
- 减少 DOM 节点，使用 CSS 伪元素
- 使用 transform 和 opacity（GPU 加速）
- 避免触发重排的属性
动画优化
- 使用 transform 而非 left/top
- 在低端设备上禁用动画

精细度与性能平衡:

Level 1: 极简（<1KB，性能极高，体验一般）
Level 2: 基础（2-3KB，推荐，体验良好）
Level 3: 精细（5-10KB，体验优秀）

平衡策略:

首屏精细化，非首屏简化
关键区域精细化，次要区域简化
根据网络条件和设备性能动态调整

最佳实践:

目标体积: <3KB（HTML+CSS）
DOM 节点: <50 个
动画: 使用 GPU 加速属性
性能指标: FCP<100ms, LCP<200ms, CLS=0

3. 骨架屏与真实内容过渡

骨架屏到真实内容的过渡如何做得平滑？如何避免闪烁和布局抖动（CLS）？

【作答】：

过渡问题分析:

闪烁问题: 骨架屏突然消失，颜色突变
布局抖动（CLS）: 尺寸不一致，字体/图片加载导致变化
视觉不连贯: 位置偏移，间距不一致

平滑过渡方案:

淡入淡出过渡
- 使用 opacity 过渡，时间 200-300ms
- 骨架屏淡出，真实内容淡入
交叉淡入淡出
- 骨架屏和真实内容同时存在
- 使用绝对定位重叠
渐进式替换
- 按区块逐步替换
- 使用 React Suspense

避免布局抖动（CLS）:

尺寸匹配
- 骨架屏与真实内容尺寸完全一致
- 精确测量真实内容尺寸
字体预加载
- 使用 font-display: swap
- 骨架屏使用相同字体
图片占位
- 使用 aspect-ratio 保持宽高比
- 预留图片空间
内容预留
- 文本行数预留
- 列表项数量预留
布局一致性
- 使用相同的 flex/grid 布局
- 保持相同的 gap、align-items 等

最佳实践检查清单:

✅ 骨架屏尺寸与真实内容完全一致
✅ 使用 opacity 过渡，避免 display 切换
✅ 字体已预加载或使用 fallback
✅ 图片使用 aspect-ratio 占位
✅ 布局系统完全一致
✅ 过渡时间 200-300ms
✅ 监控 CLS 指标，确保为 0

4. 骨架屏实践经验

讲一个你实现骨架屏的经验：技术方案、实施过程、效果数据、遇到的问题？

【作答】：

项目背景: 电商平台首页优化项目，目标是提升首屏加载体验和性能指标。

技术方案:

选型决策
- 首屏关键区域: 手写骨架屏
- 商品列表: 使用 react-content-loader 组件库
- 注入方式: SSR 内联 + 客户端渐进式替换
技术栈
- React + Next.js
- react-content-loader
- CSS Modules

实施过程:

阶段 1: 设计和开发（1 周）
阶段 2: 集成和优化（3 天）
阶段 3: 测试和监控（2 天）
阶段 4: 全量上线（1 天）

效果数据:

性能指标提升:

FCP: 1.2s → 0.8s (提升 33%)
LCP: 2.5s → 1.8s (提升 28%)
CLS: 0.15 → 0.02 (改善 87%)
TTI: 3.2s → 2.6s (提升 19%)

用户体验指标:

跳出率: 降低 12%
页面停留时间: 增加 18%
首屏内容点击率: 提升 25%
用户满意度: 4.2 → 4.6

业务指标:

首页转化率: 提升 8%
商品点击率: 提升 15%
订单量: 提升 5%

遇到的问题及解决方案:

问题 1: 骨架屏与真实内容尺寸不一致导致 CLS 解决: 使用 Chrome DevTools 精确测量，建立设计规范，使用 CSS 变量

问题 2: 骨架屏体积过大（8KB）解决: 简化 DOM 结构，压缩 CSS，使用类名缩写，降至 3KB

问题 3: 低端设备动画卡顿解决: 使用 transform 替代 left，添加 will-change，检测设备性能

问题 4: SSR 和客户端 hydration 不一致解决: 确保服务端和客户端使用相同组件，使用 React.hydrate

问题 5: 动态内容骨架屏生成困难解决: 使用固定数量骨架屏项，使用 react-content-loader 的 SVG 方案

经验总结:

精确的尺寸匹配是避免 CLS 的关键
混合方案（手写+组件库）平衡了质量和效率
性能优化（体积、动画）很重要
充分的测试（设备、网络）必不可少

# 骨架屏怎么提升性能的？骨架屏的原理及实现

# 笔试题（6 题）

# 1. 骨架屏的作用

# 2. 骨架屏实现方式

# 3. 骨架屏自动生成

# 4. 骨架屏注入时机

# 5. 骨架屏与加载状态

# 6. 骨架屏动画效果

# 面试题（4 题）

# 1. 骨架屏技术选型

# 2. 骨架屏性能优化

# 3. 骨架屏与真实内容过渡

# 4. 骨架屏实践经验

骨架屏怎么提升性能的？骨架屏的原理及实现

笔试题（6 题）

1. 骨架屏的作用

2. 骨架屏实现方式

3. 骨架屏自动生成

4. 骨架屏注入时机

5. 骨架屏与加载状态

6. 骨架屏动画效果

面试题（4 题）

1. 骨架屏技术选型

2. 骨架屏性能优化

3. 骨架屏与真实内容过渡

4. 骨架屏实践经验