优化一个比较复杂的界面,里面有多个rt和组件。
在初次打开这个界面的时候会发生1s多的卡顿,还是非常严重的。
分析
通过profiler分析
1.打开界面时卡顿。
分析:除了update和dotween相关逻辑,主要在于打开时的lua function调用。
用luaProfiler接着分析:
峰值是800ms的卡顿。
在打开时调用了两次相同方法,并且这个方法内部创建rt(同一个页面塞五个高精度rt)耗费了很长时间(370ms)。
优化
内部用了toggle,并且在start的时候初始化一整个页面,刷新了一次rt,这次的刷新是没必要的,可以直接干掉。
打开界面的时候默认执行on toggle的方法,但是会有页面优先级,SetActive时unity通过默认on toggle调用了一次RefreshData,代码侧在之后又修改了一次toggle on,这类问题也应该避免。
优化之后,加载rt仍然占用0.3s的加载时间,实际上这部分内容可以采用异步处理。
虽然yooasset开放了异步接口,但是目前项目并没有接入异步相关流程,所以没办法优化。
但是依然可以在内部做缓存,有些节点信息,rt之前的渲染信息,都可以及时存储以备后续直接调用。
剩下的卡顿时间是0.3s加载预设的时间,所以也需要对其做一些处理,比如预设的资源引用削减、特效减负。
最终结果,减负了一半加载时间。
但实际上看profiler仍然发现峰值时间偏高,原因还是有很多的Instantiate、camera.customRender。这段确实是应当要异步加载才能正式解决这个问题。
其他优化项:drawcall/batches
如果用了rt就注定其是有很多batches,rt节点开启前后相差了110.关闭rt后就剩下35了。
减少图文重叠,重叠图案或者字体是一定会增加batch数量的。
texture转换成sprite,并收录到spriteAtlas中。如果收录进去,则unity会尽可能地在一个batch中渲染出来:
如果是相同texture,也会放入一个batch中直接渲染出来:
优化之后降至25(不包括renderTexture渲染)。