Loading调优：冷启动 60% 的流失率怎么降？（附Loading有效打点表）

我在 首日ROI 0.03%！真实案例解读小游戏投放测试数据 一文中聊到过，要确保测试数据有价值，先要提供足够的用户量。 对于IAA游戏，我建议的测试量级为每天 500-1000 新增。

很多新手研发会碰到另一个问题，量级进来了，但玩家在进入游戏前就离开了。这也会导致无法获取到正常的产品数据，同时影响投放结果。

这主要是两种情况导致：

1. 在买量期间服务器挂了（甚至就没开服就开买？之前我也提到过这种开服暴毙的例子关键词「终焉誓约」），或者客户端存在重大BUG，导致玩家无法正常进入游戏。
2. Loading 处理糟糕，玩家无法忍受漫长的加载过程中，在看到游戏内容前就离开了游戏。

第一种情况解决方案很简单，加班、换人、解散团队三选一 即可。

第二种情况还有救，曾老师在这篇讲一下如何发现问题和优化问题。

本文基于一个不存在的微信小游戏（A游戏）进行讲解。

目录：

• 冷启动到新手引导流失率 60%

• 微信官方文档是个好东西，要看

• 使用 We 分析查看冷启动流失率

• 解决方案

• 利用启动场景上报打点

• 绘制启动流程图

• 分析首包、分包、资源

• 更有趣/有用的进度条

• loading 有效打点表范例

• 然后呢？

冷启动到新手引导流失率 60%

微信小游戏后台的统计，A游戏11月12日的注册用户是1508人。

游戏客户端打点的数据，12日新用户注册为988人。由于：

1. 客户端打点必须要登录拿到用户的 OPENID 才可以初始化。
2. 小游戏加载了引擎后才能调用网络库进行登录。

以此分析，有 34.5% 的新用户 在登录前就关闭了游戏。关闭原因大概率是不愿意等待漫长的引擎或者代码+资源加载。

用户登录完成后，打点后台就可以记录加载完成到新手引导这两个核心步骤的数据。根据打点数据可以看出：

1. 2.3% 的用户 在等待 Loading 条的过程中流失了。作为第一次测试的游戏，这个比例暂时可以接受。
2. 37% 的用户 在进入新手引导前流失了。他们碰到了什么？愿意等待漫长的进度条，但不原因等到新手引导开始？

也就是说，在没有看到新手引导前，有60%的用户流失了！剩下40%人的在线时长、IPU都会被一个巨大的分母平摊，得出的测试数据会大幅失真。

微信官方文档是个好东西，要看

微信官方开发者文档中的 「启动时序与关键指标」「如何提升启动速度」「并行下载能力」 已经将要做的所有事情讲得清清楚楚了，开发者应该认真遵循最佳实践。

https://developers.weixin.qq.com/minigame/dev/guide/performance/perf-action-start.html

以下内容引用内容摘录自微信官方文档，更详细的内容请复制上面的链接访问：

精简首包资源
小游戏目前所有分包总大小限制不超过 30M，首包大小限制不超过 4M。精简首包为小游戏启动最为重要的手段，因为很显然其大小会影响下载时长，对于首次冷启动的玩家的影响最大。因此，我们需要精简其内容：

• 使用资源压缩、文件合并（小文件合并，图集等）的方式降低资源占用量。
• 减少不必要的资源，通常只保留首屏依赖的少量资源。

合理使用分包加载
对于代码量过大的项目，一方面由于小游戏包体大小限制需要分包，另一方面合理分包对于启动也有很重要的意义。因为如此做开发者就能减少启动时需要下载的内容，既可以是普通资源，也可以是代码。

引擎插件能力
当小游戏首次启动时，如果本地已经存在同类别游戏引擎插件，可直接复用或可通过增量下载的方式快速下载，从而提升启动速度。

并行下载能力
对于使用了代码分包能力的小游戏，可以考虑在启动流程中使用网络 I/O 去提前下载游戏所需要的分包资源，减少用户后续等待分包资源下载的时间，缩短用户进入游戏核心玩法的耗时。

降低首屏渲染所需要资源
开发者应该降低首屏的复杂度，既包含初始业务代码逻辑与资源。我们发现许多小游戏启动过慢的原因在于初始资源过于复杂，比如初始画面的资源需要从远程 CDN 获取，这对于网络状况较差的玩家会出现明显的黑屏闪烁，体验极为糟糕。因此常见的做法是降低首屏资源的复杂度，尽量将资源置于首包内。

尽快渲染
所谓的尽快渲染，指的是缩短业务代码注入完成到首屏渲染指令的时间。因此除了前面提到的优化手段外，还可以：

• 减少初始代码大小，降低代码注入时间
• 简化首屏逻辑，比如不依赖第三方引擎进行轻量渲染

并行下载能力

启动流程中，平台会在网络空闲时，自动将开发者配置好的并行下载代码分包信息提前到和小游戏主包同时下载，后续业务通过 wx.loadSubpackage 加载需并行下载的分包，若并行下载已完成，则会从缓存中直接加载；若并行下载未完成，则复用此并行下载任务，不会重复发起网络请求。并行下载能力适用于使用了代码分包的小游戏，其原理如上图。

• 游戏首帧：用户看到首帧游戏画面的时间。
• 游戏可交互：用户最早可操作游戏的时间，通常意义上指 游戏创角 或 进入游戏核心玩法（如大厅、新手指引等）

以上内容来自微信小游戏官方文档

使用 We 分析查看冷启动流失率

We 分析中的重要功能需要付费，但免费版本可以查看启动数据。我们可以用 We 分析来查看冷启动的流失率。

如果用户首次打开，或小程序销毁后被用户再次打开，此时小程序需要重新加载所有资源启动。这就是 冷启动。

• 冷启动打开率：在小程序冷启动的情况下，点击小程序到首屏渲染完成的留存率。
• 流失次数：冷启动的情况下，用户在首屏渲染完成前，就关闭小程序的累计次数。

打开 We分析 -> 性能质量 -> 性能数据 -> 启动性能 ，看到 12 日的数据：

A游戏的冷启动流失率为 21%。这也意味着 五分之一以上的用户，在首屏渲染完成前，就关闭了游戏。

进一步，可以看到资源加载完成前，用户已经流失了15%。

更好的数据是怎样的？见下图，B游戏在冷启动次数大了一个数量级的情况下，冷启动流失率在5% 以内。

解决方案

找到了出问题的地方，就能对应找到解决方案。

利用启动场景上报打点

微信小游戏官方提供的功能，可以 在加载分包的前进行场景上报。 相比自定义打点系统必须登录成功才能上报，这至少能 提前几百毫秒到几秒的时间。

用好这个时间差，能找到更多自定义打点系统发现不了的问题。以下为微信官方文档内容：

https://developers.weixin.qq.com/minigame/dev/guide/performance/perf-action-start-reportScene.html

上图来自微信官方文档

绘制启动流程图

要求客户端程序严格绘制游戏启动流程图，标注 同步 和 异步 流程。基于流程图的对耗时进行详细分析。下图为不存在的 A游戏启动流程图：

（请曾老师喝杯咖啡，支持我持续创作。付费后可获得胡扯游戏资源库访问权限）

以下仅剩余40%文章内容，请谨慎付费，避免被坑。

付费主要内容为：

• 分析首包、分包、资源
• 更有趣/有用的进度条
• Loading 有效打点表范例