小游戏的开发者都会非常关注新进、留存、付费等与用户体验密切相关的小游戏运营数据。
而想要数据“好看”，即用户体验更好，游戏性能就是不能忽视的一环。
在小游戏公开课上，官方团队就首次给出了“性能优化指南”，从工具助力、平台举措等，帮助开发者优化小游戏性能。
1、小游戏数据助手“性能模块”：没有接入成本，手机扫码即可进入，并提供自动的性能监控，帮助开发者更全面地把握性能数据；
2、即将发布新的服务能力“小游戏测试云服务”：将大为节省做测试的人力，也增加了测试机型的覆盖面。在测试完任务后，可以同时得到性能测试的报告以及兼容性测试的报告。
视频参上——
https://v.qq.com/x/page/x0917fc7mn2.html
此外，小游戏团队还对如何进行性能优化给出了一些实用建议：
1、下载代码包阶段可以尽量精简包内资源，可以使用平台侧提供的分包或者引擎插件能力；
2、框架、环境的准备和首屏渲染准备阶段，可以借助平台侧提供的预下载能力，尽可能地降低首屏需要的资源数目，尽快的进行渲染。
意犹未尽？小游戏性能优化实战指南全文请收好——
小游戏性能概况、性能分析工具以及未来规划
微信公开课讲师 肖海
大家好，很高兴来到这里给大家做一个技术相关的分享。今天由我和我的同事蔡凌波共同为大家分享，我们的分享主题是小游戏性能优化指南。
我们的分享主要分两部分，首先由我为大家介绍小游戏性能的概况，性能分析工具以及未来的规划；第二部分，由我的同事介绍小游戏常见的性能问题和比较好的优化手段。
作为小游戏的开发者，我们会非常关注小游戏的运营数据。比如新进、留存、付费等等。那么我们为什么要做游戏的性能优化呢？我认为这些数据背后的核心点是在于用户的体验，而从开发的角度看，游戏性能又是最能影响用户体验的部分。
举例，如果游戏启动没有优化好，需要很久才能看到游戏的画面。很有可能很多玩家在没有等到游戏加载完就已经产生了流失。
又例如我们在平台中发现有很多玩法非常有趣，品质也很不错的小游戏，但实际玩的过程中会发现玩了几分钟手机就变得非常烫。我们还发现有些场景非常精美的小游戏，但玩着玩着会突然弹出一个提示内存占过大出现闪退。
由此可见，游戏的性能是非常影响游戏体验的。因此，作为开发者需要优化游戏性能，并且也只有在比较好的游戏性能之上才能构建出更加丰富、有趣的小游戏出来。
小游戏性能概况
游戏的性能优化本身是一个非常复杂的话题。有没有一些好的优化工具能够帮助我们做游戏的性能优化呢？
首先，我为大家介绍的第一个分析工具是小游戏数据助手中的性能模块。
这个模块产生的背景是这样的，我们和开发者沟通过程中发现开发者经常会有这样一些疑问：
我的游戏已经发布到线上，现网玩家真实的用户体验是怎样的，玩家需要多少秒才能进入游戏，这个过程中又有多少用户产生了流失。
也有一些开发者给我们反馈，现在对用户体验和游戏性能缺乏一个比较好的监控手段，往往需要通过玩家的反馈来感知到游戏中不好的性能。有没有一些更加高效、可靠的性能监控手段呢？
带着这样的疑问，我们今年7月份在小游戏数据助手中增加了性能模块，从小游戏底层框架做了自动数据埋点，大家不需要做任何接入工作就可以使用这个服务，没有任何接入成本。可以通过手机扫码进入到小游戏数据助手，打开性能面板，直接看到小游戏目前的运行状况。
其次，我们的数据面向全网游戏海量玩家的真实性能采样数据，因此开发者能够对性能数据有更全面的把握。
最后，在数据之上我们做了自动的性能监控，对于出现问题的性能指标给予开发者提醒，并给出我们比较推荐的优化手段和工具指引。
实际工作中如何结合小游戏的性能模块为性能优化服务？从功能上看，小游戏数据助手的性能模块主要分概览和详情两部分。
首先可以在概览上看到目前小游戏运行的整体情况，它就像一个仪表盘，可以在其中看到一些关键性能数据。比如游戏的启动速度，游戏在启动过程中用户的留存，游戏在运行过程中的CPU、内存、网络延迟等相关数据。
我们希望开发者看到数据后对游戏运行性能有直观感受。在这些数据的背后关联的是用户体验。比如我们能够知道用户究竟需要多少秒才能打开游戏，而在每一秒钟产生用户的流失有多少。
我们也能知道用户在不同的机型情况下运行游戏的流畅程度怎么样。除了本身的数据报表外，还提供了性能监控。比如左边（见PPT）检测到游戏加载时间高于评估标准。
这种情况下，我们会发现这个问题，并且告知开发者，最后给出平台中比较好的优化实践引导开发者做这方面的优化。
小游戏性能分析工具
如果在性能概况中真的发现自己的游戏出现性能问题时，下一步该如何做这里面数据的解读和进一步的性能优化呢？
我们提供了性能详情，对数据和维度做了进一步细化和拆解。这里的目的是为了让开发者能够进一步定位性能的瓶颈。
比如性能数据为发布后，有开发者看到打开留存率只有60%。这个开发者感到非常疑惑，因为他的代码包不到2兆，为什么启动速度到十几秒，而且留存只有60%。
经过性能详情分析，发现这个游戏在代码包加载完后和首屏加载前还做了许多开发者自己资源的加载，开发者意识到代码包的重要性，但没有意识到首屏画面对于玩家的重要性。
在这个角度，微信小游戏数据助手为开发者发现了这样一个问题。
我们经常会收到开发者关于游戏内存的问题。有开发者会问到，在现网运行中，有玩家给我们反馈为什么会玩着玩着突然出现一个弹框说内存占过大出现闪退。开发者这时候没有办法判定这是个别的用户行为还是真的内存出现了问题。
通过运行性能分析，我们看到这款游戏的内存占用达到600兆，我们也可以看到在现网运行过程中有接近20%的用户是因为这个原因而产生了闪退。
因此我们可以肯定的告诉开发者，这是一个内存性能问题。由此，开发者做了更进一步的性能分析，发现是某一个资源释放的原因，由此解决了问题。
由此可见，微信小游戏性能助手可以提供自动监控手段，还能为数据进一步分析提供帮助，让我们去发现性能的瓶颈。
微信小游戏数据助手的性能模块本质是数据服务，也是性能监控工具。然而如果发现问题时仅仅靠现网数据分析是不够的，往往需要用各种性能分析工具，找到性能真正的问题所在。
在以往和开发者的沟通过程中，我们发现大家在做性能优化时，常常遇到这么一个问题：我手头上的硬件设备是不够，同时我也没有办法对每一个版本、每一个设备做相关的性能测试，尤其是对一些小的开发团队来说，这个测试是很耗费人力时间成本的。
为了解决这样一个痛点，我们即将发布新的服务能力：小游戏测试云服务。
在这个解决方案里提供了云真机测试集群，这个测试集群里涵盖了超过80%主流品牌机型。另一方面，开发者除了可以自己编写测试脚本外，也可以直接利用到平台所提供的一键测试。
以这样的方式节省了大家做测试的人力，同时也增加了测试机型的覆盖面。在测试完任务后，可以同时得到性能测试的报告以及兼容性测试的报告。
左图是特定一台机型下的性能测试报告，我们除了能知道测试过程中整体的性能概况，更重要的是知道关键指标随时间的变化趋势.
最终我们还提供了游戏出现性能异常的时候对应的截图去方便大家定位问题。右图则是兼容性测试报告，主要是用来检测小游戏在不同设备上是否出现黑屏/jserror这样一些比较严重的适配问题。
小游戏工具链未来规划
这里是微信小游戏关于性能优化工具链的规划。今年7月我们在微信小游戏性能助手给到大家基础性能指标、评价标准、优化指南，9月份会开放测试云服务为大家提供性能测试、兼容性测试，10月份会对小游戏数据助手性能模块做进一步升级和优化。
这其中也是了解到开发者的一些痛点，我们希望能够让开发者可以自定义场景做对比分析，也可以对不同的小游戏版本之间做分析，最后还会对性能监控做进一步优化，让开发者可以更加灵活的定制监控策略。
以上是我关于性能分析工具的介绍。在实际工作中，除了了解这些分析工具之外，我们又会遇到哪些实际的性能问题呢？这其中有没有一些值得推荐给大家的优化手段呢？接下来由我的同事蔡凌波为大家做进一步的分享，感谢大家收听，谢谢！
小游戏常见性能问题及优化手段
微信公开课讲师 蔡凌波
各位开发者，大家好，我是微信公开课讲师蔡凌波，今天想跟大家分享的主题是小游戏的性能。为什么要以这个主题来进行分享呢？
是因为小游戏的性能直接关乎到用户的留存和开发者直接的收益情况。
小游戏启动性能
启动性能关乎到小游戏的用户能不能真正进入到小游戏；而运行时期的性能关乎到用户在进入小游戏后会不会因为网络延迟或卡顿等现象再次流失。
我们首先来看一下启动性能，我会从背景、分析、方案、案例几方面加以阐述。
从这个折线图可以看到随着启动时间的延长，用户的流失数目越来越高，底部阴影面积是用户流失的总人数。我们如果提升了启动速度，就能降低用户流失数目，进而降低流失率。
右边的图是小游戏的启动漏斗情况。这个漏斗包含了小游戏首次启动和二次启动情况。大家可以猜测一下，如果一个小游戏启动时间大概5s左右，那它的用户流失率大概多少？会达到20%-30%。
在广告场景下，由于小游戏大部分是首次启动，所以用户流失会更多。广告场景下，小游戏启动时间7s左右时间，用户流失率会达到30%-50%。因此我们一定要优化启动性能。
那启动具体分成哪些阶段，又从哪里能看到小游戏具体的启动性能呢？
从中间的流程图可以看到，小游戏的启动主要包含了以下几个阶段，主要包含了下载代码包、框架和环境准备、js注入和首屏渲染准备阶段。
小游戏数据助手上可以看到小游戏的留存情况，各个阶段的留存率具体是什么意思呢？代码包的留存率是指我们下载或加载完代码包之后用户数与初始用户数的比值；首屏留存率则是首屏留存用户数与初始用户数的比值。
小游戏数据助手上的启动耗时具体是指什么呢？代码包加载耗时是指从启动开始到代码包下载完成阶段的耗时；
剩余阶段的耗时则会被计算成首屏渲染耗时。小游戏数据助手上面的总耗时则是指整个阶段的完整耗时。我们已经知道启动阶段具体包含什么，也知道怎么查看自己当前小游戏的性能。
那我们应该如何去提升启动性能呢？
平台侧已经有一些举措来提升启动性能。比如安卓平台会进行进程预加载，我们也会提前进行基础库的注入。安卓平台还会生成CodeCache来提升二次启动速度。
从开发者的角度可以从以下三个阶段提升启动性能，包括下载代码包、框架和环境准备以及首屏渲染阶段。首先我们来看下载代码包阶段。
从左边这张图中可以看到代码包大小和下载时间基本呈现线性分布形式（见PPT），如果我们想要优化代码包的下载耗时，就需要降低代码包的大小。
降低首包大小主要有以下几个手段：精简包内资源，包括代码资源、图片资源，比如使用图集方式；使用平台侧提供的分包能力和引擎插件能力。引擎插件能力是什么呢？
小游戏代码包构成中引擎占据了非常大的比重。 我们提供的能力呢，就是直接将这份引擎代码直接在客户端缓存，让不同的小游戏能够共用。启动一个新的小游戏时，只需要下载各自少量的业务逻辑代码就可以，这样就能极大的提升启动速度。
除了下载代码包阶段，在框架、环境准备以及首屏渲染准备阶段，我们能做一些什么事情？平台侧提供了预下载能力。
首屏渲染准备阶段主要包含文件下载、文件处理两个部分，而在框架和环境准备期间是CPU密集时期。如果把文件下载部分和框架、环境准备并行执行，就能充分利用上这段网络空闲时期，来提升大家的启动速度。预下载资源以及分包信息，可以直接在game.json里进行配置，某大dau小游戏接入预下载能力之后启动耗时降低了600毫秒。
除了接入预下载能力之外，我们还可以降低首屏渲染需要的资源数目， 尽快地进行渲染。我们已经知道了启动优化手段，接下来具体以一个案例形式看一下。
以星途为例，星途首先精简自己的代码，使用图集方式，使代码包大小从3.7兆直接降到1.6兆，启动耗时从5s降低到2.5s，流失率有50%的降低。之后星途又接入了引擎插件能力，下载耗时又有一定程度的降低，流失率降低了60%。除了技术手段进行启动优化之外，从产品或者设计角度有没有办法提升启动性能？
星途的启动流程，是一个小火箭冉冉升起的过程，星途利用这个动画时间下载自己的资源，这样就能尽可能地精简首包大小。
再简单小结一下如何提升启动性能。
首先，下载代码包阶段可以尽量精简包内资源，可以使用平台侧提供的分包或者引擎插件能力；框架、环境的准备和首屏渲染准备阶段，可以接入平台侧提供的预下载能力，也要尽可能地降低首屏需要的资源数目，尽快的进行渲染。
小游戏运行优化性能
已经优化了启动性能，运行过程中的网络延迟或卡顿等问题就成了用户流失的第二个拦路虎，我们也要尽可能优化运行时期的性能。
我将主要从CPU耗时优化、内存、网络几方面加以阐述，为大家介绍一下如何排查这些方面的问题以及具体的优化手段。
小游戏数据助手上面已经可以展示各自小游戏的CPU均值情况，接下来我们也会将卡帧和低帧的数据展示出来。
那针对卡帧的情况，如何去排查热点函数呢？
Android 7.0.6之后，开发版和体验版我们提供了CPU Profile的功能， profile文件能使用微信开发者工具或者Chrome浏览器打开，查看js函数的耗时情况。
以图中为例，可以很明显地看到updaleAnimator 这个函数耗时非常长，是我们需要重点优化的。内存方面，安卓7.0.6之后提供了内存快照，能够查看到js内存。
接下来将要发布的版本上，会在性能面板上为大家提供更多内存情况的展示，比如会展示出Graphics/Java/Native内存，能够让大家更有针对性的优化。
在知道了小游戏的内存情况之后，平台侧提供什么样的接口呢？
在切换场景等情景下，要及时调用平台层提供的triggerGC接口清理内存，同时我们也会提供onMemoryWaring的接口，为大家提供内存吃紧的预警。
在网络方面，小游戏数据助手已经有了网络性能的概览介绍，还提供错误分析功能。以某一个接口为例，错误率已经达到11%多，我们应该尽早排查问题。
除了网络接口的错误分析，小游戏数据助手上还展示了网络接口延迟情况。以某一个接口为例，延迟已经达到将近6s，大概率这个接口已经挂掉，需要提高警惕，尽早排查问题。
同时，平台侧还提供帧同步整套能力，对于RTS、MOBA、IO类的小游戏可以考虑接入。这套帧同步方案的优势在于无须开发后台，可以无缝接入。底层采用UDP实现，性能方面优异一些。
我们再简单小结一下小游戏运行时期有什么方法和手段提升性能。
在耗时方面Android平台提供了CPU Profile工具，让大家查看js的耗时。内存方面提供了js的内存快照功能，接下来的Android版本也会为大家提供更多的内存数据。
此外，平台侧还提供了内存清理和告警接口。网络方面，小游戏数据助手提供了网络接口错误以及耗时统计，平台侧也提供了帧同步整套方案。
我的分享到这里，如果大家有什么性能方面的问题，欢迎在开发者性能论坛上与我们保持沟通和联系，谢谢大家！
