mirror of
https://github.com/smallmain/cocos-enhance-kit.git
synced 2025-11-04 22:35:24 +00:00
创建 v3.0.0 文档
This commit is contained in:
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"label": "最佳实践",
|
||||
"position": 3,
|
||||
"collapsed": false
|
||||
}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 194 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 114 KiB |
@@ -0,0 +1,48 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
description: "了解并上手社区版提供的新特性。"
|
||||
---
|
||||
|
||||
# 新引擎特性
|
||||
|
||||
社区版添加了一些实用的新特性,帮助你更好地开发游戏。
|
||||
|
||||
## 社区版设置面板
|
||||
|
||||
由于 v2.x 没有提供官方 API 往引擎原有的设置面板上添加设置项,所以我们另外增加了一个设置面板。
|
||||
|
||||
依次点击编辑器菜单项 **项目 - 社区版设置** 打开设置面板:
|
||||
|
||||

|
||||
|
||||
## 支持 SpriteFrame 给 Spine 换装
|
||||
|
||||
官方文档中介绍了替换 attachment 对象进行换装的方法,但如果动画中有切换 attachment 的关键帧,这种方法就失效了。
|
||||
|
||||
还有一种方法是修改 attachment 的 region 对象来进行换装,但这种方法引擎没有直接支持,所以社区版对其进行了支持。
|
||||
|
||||
只需要一句代码即可使用 cc.SpriteFrame 的数据修改 attachment 的 region 对象数据:
|
||||
|
||||
```js
|
||||
skeletonComponent.setRegionData('Head', 'Head', new sp.RegionData(spriteFrame));
|
||||
```
|
||||
|
||||

|
||||
|
||||
> 图片中是被换头的小男孩。
|
||||
|
||||
这样做是直接修改了 SkeletonData 的数据,所有使用该数据的 Spine 组件都会受到影响(被换头),但我们提供了克隆 SkeletonData 数据的接口,可前往 [Spine](../user-guide/spine/spine-intro.mdx) 文档了解更多详情。
|
||||
|
||||
## 支持 RichText 自定义材质
|
||||
|
||||
可前往 [RichText 自定义材质](../user-guide/text-render/text-richtext.md) 文档了解更多详情。
|
||||
|
||||
## 性能指示器增强
|
||||
|
||||
优化了引擎自带的性能指示器,增加了三个重要的性能指标:
|
||||
|
||||
- Label Canvas(Label 组件的 Canvas 数量)
|
||||
- Char Atlas(Char 字符图集使用情况)
|
||||
- Dynamic Atlas(动态图集使用情况)
|
||||
|
||||

|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
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 张都用完的情况大部分是没有合理搭配使用两种缓存模式。
|
||||
|
||||
## 进行文本渲染烘焙
|
||||
|
||||
在之前,即使没有 Drawcall 高的问题,引擎文本渲染本身的性能消耗也并不低。
|
||||
|
||||
为此,社区版新增了烘焙的相关接口,你可以通过这些接口将文本渲染的性能提升 10 倍以上!
|
||||
|
||||
可前往 [文本渲染烘焙](../user-guide/text-render/text-baking.md) 文档了解更多详情。
|
||||
|
||||
## 启用 Spine 合批
|
||||
|
||||
Spine 组件现在不仅可以参与动态合图,还能与其他渲染组件进行合批。
|
||||
|
||||
只需启用组件上的 `Enable Batch` 属性即可。
|
||||
|
||||
## 提升 TiledMap 性能
|
||||
|
||||
一个 TiledMap 可能会有很多个 TiledLayer,如果开启了 TiledMap 的 Culling 特性,则需要每个 Layer 都单独计算 Culling 数据。
|
||||
|
||||
社区版新增了在满足一定条件的情况下可以复用 Culling 数据的特性,以减少 CPU 的性能消耗。
|
||||
|
||||
可前往 [复用 Culling 数据](../user-guide/tiledmap/tiledmap-culling.md) 文档了解更多详情。
|
||||
|
||||
## 启用多线程支持
|
||||
|
||||
**现在,以下引擎的部分增加了多线程支持:**
|
||||
|
||||
- **资源管线(下载与缓存部分)**
|
||||
- **音频系统**
|
||||
- **XMLHttpRequest**
|
||||
- **WebSocket**
|
||||
|
||||
启用后可以释放其对主线程的占用,减少卡顿现象。
|
||||
|
||||
除此之外,还**支持自定义多线程扩展**,大幅简化了将项目逻辑多线程化所需的步骤!
|
||||
|
||||
并且在微信小游戏平台下还有以下改进:
|
||||
|
||||
- **默认启用网络接口和音频接口的高性能模式**
|
||||
- **网络接口支持 HTTP/2、HTTP/3(QUIC) 协议**
|
||||
|
||||
详情请阅读文档:[多线程支持](../user-guide/multithread/thread-intro)。
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
description: "提升游戏的质量。"
|
||||
---
|
||||
|
||||
# 提升游戏质量
|
||||
|
||||
社区版加入了一些新特性,使得你能提升游戏各方面的质量。
|
||||
|
||||
## 高 DPI 文本渲染
|
||||
|
||||
以前我们会使用将 Label 字号放大一倍,Label 节点缩小一倍的方式去解决字体模糊的问题。
|
||||
|
||||
而现在不需要了,你可以通过一句代码调整渲染比例:
|
||||
|
||||
```js
|
||||
cc.sp.labelRetinaScale = 2; // 渲染文本时纹理的缩放倍数,默认值为 1.
|
||||
```
|
||||
|
||||

|
||||
|
||||
> 图片中,上方的是开启后效果,下面是未开启效果。
|
||||
|
||||
**推荐你根据设备像素比(devicePixelRatio)来动态设置该值,并且该值不要大于 `2`,这不会带来更好的效果,但却将字体纹理放大了数倍,会影响到游戏整体性能。**
|
||||
|
||||
可前往 [高 DPI 支持](../user-guide/text-render/text-high-dpi.md) 文档了解更多详情。
|
||||
Reference in New Issue
Block a user