mirror of
https://github.com/smallmain/cocos-enhance-kit.git
synced 2024-12-27 12:07:53 +00:00
119 lines
5.1 KiB
Markdown
119 lines
5.1 KiB
Markdown
|
---
|
|||
|
|
sidebar_position: 1
|
|||
|
|
description: "在游戏开发中享受不用关注 Draw Call 的快乐。"
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 提升游戏性能
|
|||
|
|
|
|||
|
|
建议先阅读官方文档的 [UI 渲染批次合并指南](https://docs.cocos.com/creator/2.4/manual/zh/advanced-topics/ui-auto-batch.html) 了解一些基础知识。
|
|||
|
|
|
|||
|
|
社区版对动态合图、文本渲染等功能进行了大量的改进，现在，你只需要确保以下几点就可以大幅提升游戏的性能。
|
|||
|
|
|
|||
|
|
## 使用动态合图
|
|||
|
|
|
|||
|
|
在之前，动态合图不支持复用图集的废弃区域，所以我们通常会关闭该特性，倾向于靠静态图集或者自动图集达到降低 Draw Call 的目的。
|
|||
|
|
|
|||
|
|
现在，社区版几乎重构了整个动态合图系统，实用性得到大幅提升：
|
|||
|
|
|
|||
|
|
- 支持复用废弃区域
|
|||
|
|
- 自动参与多纹理渲染
|
|||
|
|
- 支持 Spine 参与动态合图
|
|||
|
|
|
|||
|
|
你只需要重新启用动态合图，并尽量让更多的纹理都参与合图，即可大幅降低 DrawCall 的数量。
|
|||
|
|
|
|||
|
|
我们还建议做以下调整：
|
|||
|
|
|
|||
|
|
**放宽能参与合图的纹理尺寸限制**
|
|||
|
|
|
|||
|
|
```js
|
|||
|
|
cc.dynamicAtlasManager.maxFrameSize = 1024; // 推荐 512、1024 甚至 2048
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
你可以根据游戏运行过程中所使用的动态图集数量，来逐步放宽限制，取得一个平衡点。
|
|||
|
|
|
|||
|
|
**优化动态图集的使用率**
|
|||
|
|
|
|||
|
|
当游戏使用的动态图集数量太多，你可以控制某个组件或纹理不参与动态合图：
|
|||
|
|
|
|||
|
|
- 调整纹理的 `packable` 属性
|
|||
|
|
- 调整组件的 `allowDynamicAtlas` 属性
|
|||
|
|
|
|||
|
|
通过让某些优化性价比较低的纹理不参与合图，例如：
|
|||
|
|
|
|||
|
|
- 大尺寸、单独出现的纹理：比如背景图，尺寸较大使得占用图集的空间大，并且一个场景内可能只有单个节点会显示，不存在需要大量合批的情况。
|
|||
|
|
|
|||
|
|
来优化图集的使用。
|
|||
|
|
|
|||
|
|
**及时释放无用资源**
|
|||
|
|
|
|||
|
|
由于社区版支持了图集空间的复用，所以释放资源的同时也会将其占用的图集空间释放，以提供给其它纹理使用。
|
|||
|
|
|
|||
|
|
建议在不用的时候及时释放一些冷门资源，常用的资源则不进行释放，避免频繁释放后加载导致的性能消耗。
|
|||
|
|
|
|||
|
|
## 使用 Label 缓存模式
|
|||
|
|
|
|||
|
|
在之前，引擎提供的缓存模式都各有问题，无法在实际项目中使用：
|
|||
|
|
|
|||
|
|
- Bitmap 模式：虽然能够参与动态合图，但无法复用废弃空间，随着游戏的运行，废弃字符的纹理占满图集后就失去了优化效果。
|
|||
|
|
|
|||
|
|
- Char 模式：依然是无法复用的问题，仅有一张字符纹理，当纹理被填满后甚至无法渲染出文本。
|
|||
|
|
|
|||
|
|
现在，由于社区版使动态合图支持了复用，并且还重构了 Char 模式的实现，使得 你只需要合理运用这两种缓存模式即可完成对 Label 的优化工作。
|
|||
|
|
|
|||
|
|
**首选 Char 缓存模式**
|
|||
|
|
|
|||
|
|
我们建议 Label 默认使用 Char 缓存模式，相比 Bitmap 模式，Char 模式是按字符进行复用的，有着更高的性能优势。
|
|||
|
|
|
|||
|
|
**备选 Bitmap 缓存模式**
|
|||
|
|
|
|||
|
|
如果遇到以下场景，则不适合使用 Char 模式进行渲染：
|
|||
|
|
|
|||
|
|
- 显示像 Emoji 这种字素簇的字符串，由于内部实现无法分割为单个字符，所以不能正常显示。
|
|||
|
|
- 超大字体，可能瞬间占满字符纹理。
|
|||
|
|
- 显示聊天消息、输入框、玩家名称这类不可控的内容，由于第一条限制，所以为了保证 Label 能正常显示，则不建议使用。
|
|||
|
|
|
|||
|
|
这时候就可以改用 Bitmap 模式进行渲染，依然能参与动态合图进行合批。
|
|||
|
|
|
|||
|
|
### 注意事项
|
|||
|
|
|
|||
|
|
- **勿对 `fontSize` 属性进行动画或者缓动**
|
|||
|
|
|
|||
|
|
无论是否使用缓存模式，也不建议频繁修改 `fontSize` 属性，这会导致每帧都需要重新生成文字纹理，造成大量的性能消耗，可以转为使用节点的 `scale` 来代替。
|
|||
|
|
|
|||
|
|
- **Char 缓存模式依旧不能在内部字符纹理填满时正常渲染**
|
|||
|
|
|
|||
|
|
这是引擎原本的限制，我们未对其进行修复，原因是我们认为 8 张数量已经够多了，8 张都用完的情况大部分是没有合理搭配使用两种缓存模式。
|
|||
|
|
|
|||
|
|
## 启用 Spine 合批
|
|||
|
|
|
|||
|
|
Spine 组件现在不仅可以参与动态合图，还能与其他渲染组件进行合批。
|
|||
|
|
|
|||
|
|
只需启用组件上的 `Enable Batch` 属性即可。
|
|||
|
|
|
|||
|
|
## 提升 TiledMap 性能
|
|||
|
|
|
|||
|
|
一个 TiledMap 可能会有很多个 TiledLayer，如果开启了 TiledMap 的 Culling 特性，则需要每个 Layer 都单独计算 Culling 数据。
|
|||
|
|
|
|||
|
|
社区版新增了在满足一定条件的情况下可以复用 Culling 数据的特性，以减少 CPU 的性能消耗。
|
|||
|
|
|
|||
|
|
可前往 [复用 Culling 数据](../user-guide/tiledmap/tiledmap-culling.md) 文档了解更多详情。
|
|||
|
|
|
|||
|
|
## 启用多线程支持
|
|||
|
|
|
|||
|
|
**现在，以下引擎的部分增加了多线程支持：**
|
|||
|
|
|
|||
|
|
- **资源管线（下载与缓存部分）**
|
|||
|
|
- **音频系统**
|
|||
|
|
- **XMLHttpRequest**
|
|||
|
|
|
|||
|
|
启用后可以释放其对主线程的占用，减少卡顿现象。
|
|||
|
|
|
|||
|
|
除此之外，还**支持自定义多线程扩展**，大幅简化了将项目逻辑多线程化所需的步骤！
|
|||
|
|
|
|||
|
|
并且在微信小游戏平台下还有以下改进：
|
|||
|
|
|
|||
|
|
- **默认启用网络接口和音频接口的高性能模式**
|
|||
|
|
- **网络接口支持 HTTP/2、HTTP/3(QUIC) 协议**
|
|||
|
|
|
|||
|
|
详情请阅读文档：[多线程支持](../user-guide/multithread/thread-intro)。
|