前言
微信小游戏云测试服务的开放之后,越来越多的开发者使用该功能测试自己的小游戏的性能。但是大部分小游戏的测试结果显示,启动性能得分很低,远远达不到80分的标准线,甚至难以达到60分。
根据微信小游戏文档中的启动优化最佳实践,优化思路一共有6种:
- 精简首包资源
- 分包加载
- 引擎插件
- 预下载能力
- 降低首屏渲染资源
- 尽快渲染。
常规的优化思路往往是两步:
-
- 拆分代码包,精简首包资源,使得首包只存首屏图片和一个加载进度条及相关代码;
-
- 使用分包加载。
根据小游戏的启动时序,会发现,降低代码包资源会减少了代码包下载,以及在某种程度下降低JS注入耗时。
然而,即使启动优化到这一步,很多小游戏依旧得不到理想的分数。因为使用引擎开发的小游戏,即便只留首包必要资源,也会保留引擎代码,这无非会增加很长时间的JS注入耗时,以及首屏渲染耗时也未得到优化。此时很多开发者已经非常苦恼:我该如何优化呐?
自然而然,解决思路无非是,1. 降低注入代码的大小来减少JS注入耗时; 2. 简化首屏渲染逻辑,比如不依赖第三方引擎进行轻量渲染。但是,怎么做呐?
本文,将结合上面的两个解决思路,提供一套不依赖引擎(WebGL/Canvas2D直接渲染首屏)的小游戏首包加载套路,即减少了引擎代码注入耗时,又避免了第三方引擎的重度渲染。该方式可以直接套用,使用后的小游戏的启动性能在云测试报告下的启动性能得分能达到90及以上。
背景
目前微信官方文档、微信小游戏社区和各个引擎社区已经有很多篇关于启动优化的文章。除了微信官方文档,在微信小游戏社区和cocos 社区下有两篇非常优秀的使用WebGL渲染首屏的文章:
尤其是第二篇,很多开发者都查资料时查到这一篇文章,按照这篇文章的逻辑来优化小游戏能够达到很理想的效果,本文的思路也是基于该文章之上进一步优化。这两篇文章均是直接使用WebGl渲染首屏,能够达到很理想的效果。强烈先去看一眼这两篇文章及下面的评论,基本上遇到的所有问题都有解答。
但是二者有着各自的缺陷:
第一篇文章简练地介绍了优化思路,但是直接使用的话需要理解WebGL的逻辑并进行改造,存在难度;
第二篇文章是一片很优秀的文章,大家可以先学习一下。该文章中的代码虽然可以直接使用套用,但是代码逻辑和gl渲染的使用方式存在一定的错误,比如重复创建图片,未使用rAF渲染等,这些错误会导致微信客户端统计启动耗时出现异常。然而,因为对gl改写的难度比较大,所以,本文基于第二篇文章中的WebGL渲染首屏的代码进行了改造,附上了正确的使用方式,并额外新增了一份使用Canvas2D渲染首屏的代码。
代码片段
话不多说,附上代码片段:
1. WebGL渲染
webGL代码理解起来还是有难度的,所以代码中的 webgl_first_render.js
可以直接使用,使用方式可以参考game.js
。这段代码解决了文章二中的云测启动耗时统计错误、启动黑屏、横屏渲染错误、内存泄漏、屏幕闪烁等异常情况。
代码片段如下:
https://developers.weixin.qq.com/s/tknkPjmr7Glg
2. Canvas2D渲染
Canvas2D渲染使用CanvasRenderingContext2D对象 直接渲染。实现上很简单,改造起来也很容易。其实现逻辑是和webgl是一样的。
我看了你链接的《Cocos Creator 微信小游戏平台启动与包体优化(首屏渲染耗时降低 50%)》,文章最末尾和评论区都有说到ios平台首屏渲染等待时间没有缩短的情况,但是解决方案我没看明白,请问能解释一下吗?
请问大佬,首屏渲染时间降下来了,但是下载代码包时间却上去了。
包里就多了一个加载图,整包大小从3.6M变成了3.8M。
大神,首屏渲染出来后,我调用cc.director.loadScene会黑屏一段时间,这个要周末处理?
为什么我渲染后,这张图片就不消失了
有大佬知道这是怎么回事吗,加了webgl_first_render.js后,第一张背景图正常显示,但是分包加载完,引擎开始渲染后,所有的贴图都上下反过来了,引擎是用Laya+fgui
const VERTICES = new Float32Array([
-1, 1, 0.0, 0.0,
-1, -1, 0.0, 1.0,
1, 1, 1.0, 0.0,
1, -1, 1.0, 1.0,
]);