写作网站保底和全勤的区别/seo综合查询中的具体内容有哪些

优化一个比较复杂的界面，里面有多个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渲染）。