国人之傲骄!Cocos Creator 联手华为应用市场,一键上传AppGallery ...-技术圈

新的平台总是意味着新的机遇与挑战，Creator 2.4.1 版本现已全新支持 HUAWEI AppGallery Connect，将为开发者带来更多的用户及潜力，相信新的平台能爆发出更多优秀的游戏。

同时，Cocos Creator 在移动端游戏上与 HMS Core 进行深度合作，特别是在技术层面上，与 CG Kit 底层算法集成，挖掘 Vulkan 极限渲染能力，释放更大的图形渲染性能，提升渲染效率。

接下去，Cocos 将与华为进行全方位的合作，持续接入华为 HMS Core、AppGallery Connect 更多优质服务，助力开发者开发出更多高品质的游戏。

此版本让你的游戏可以一键接入华为 HMS Core，一键上传至 HUAWEI AppGallery Connect 快速发布到华为应用市场，省去开发过程中接入 SDK、上传平台等繁复操作，助力开发者打造高品质创新应用，提升游戏体验！

What's new

新增 HUAWEI AppGallery Connect

良好的服务是游戏不可或缺的部分，在游戏开发中，开发者常常需通过接入 SDK 使用第三方服务。但接入过程常是繁杂且易出错的部分，需耗费大量不必要的时间。

在 Creator 中，开发者基于 Cocos 的 IDE 进行游戏发布时，当选择发布到 HUAWEI AppGallery Connect，可以一键接入华为 HMS Core，当前包含账号、支付、广告和游戏等服务，近期还将支持推送、分析和定位等，可极大提升开发者的工作效率。

开发者可在服务面板中启用 SDKHub 并配置好对应的 SDK 预设。

在构建时选择 HUAWEI AppGallery Connect 平台，并选择已配置好的 SDK 预设即可。

在构建完成后，可通过上传窗口一键上传。

新增连尚小游戏发布平台

连尚小游戏是 WiFi 万能钥匙旗下的小游戏应用平台，具有便捷、轻量、免安装的特点。采用 Creator 开发的游戏，只需构建时选择连尚小游戏发布平台，就可以自动完成适配，获得 Cocos Creator 强大便捷的跨平台能力。

更多关于发布连尚小游戏的内容，请参考 [发布到连尚小游戏] 。

Bug fixes

[Engine] 修复运行时插件脚本执行顺序错误的问题。[#6983]
[Engine] 修复场景启用延迟加载可能出现加载失败的问题。[#6983]
[Native] 修复原生平台富文本组件文字排版错误的问题。[#6975]
[Editor] 修复进入 Prefab 编辑器模式时，场景视图自动切换为 2D 视图的问题。
[Editor] 修复小米小游戏、OPPO 小游戏、vivo 小游戏平台将主包配置为小游戏分包后，构建失败的问题。

Known issues

iOS 设备升级到 iOS 14 beta.2 后，Web 平台暂时会出现无法显示画面的问题，可以自定义引擎，并手动合并此改动 [#6974] 进行修复。我们将继续跟进 iOS 14 后续版本，避免造成兼容性问题。

升级提示

Cocos Creator 对项目的升级操作是不可逆的，请在升级前提交或备份旧版项目。

绝大多数项目通常都能自动升级，但因为项目难免存在特殊性，开发者应该根据项目自身需求，提前对新版本引擎进行试用和评估。
此外，出于稳定性考虑，建议即将上线或已上线的项目谨慎升级。
以下是升级说明，如果开发者们在升级中遇到困难，欢迎向我们反馈，我们会尽力协助。
从 < 2.4.0 版本升级

cc.loader 已经不建议使用，请使用最新的 cc.assetManager 来代替，请参考 [资源管理模块升级指南] 。
子包功能已升级为 Asset Bundle，请参考 [资源分包升级指南] 。
调整了项目构建后的目录结构，调整了 BuildResults 的 API，如果你使用了编辑器插件获取编辑器构建结果，请参考 [定制项目构建流程升级指南] 。
从 1.10 开始废弃的 cc.RawAsset 已被正式移除，请使用 cc.Asset 代替。由于 2.4 不再兼容原有 1.x 项目中对 RawAsset 类型的历史遗留用法，建议所有要升级到 2.4 的项目特别是从 1.9 版本一路升级上来的项目，先在任意的 1.10 ~ 2.3 版本中对编辑器编译代码时输出的所有警告或报错都正确处理完毕，再升级到 2.4。
cc.Color.fromHex 已被废弃，请使用 cc.Color.fromHEX 接口。

从 < 2.3.3 版本升级

Effect 中的 CCTexture2D、CCTexture2DRGB 方法已被废弃，请改用 CCTexture、CCTextureRGB。
Vec3.FRONT 已被废弃，请改用 Vec3.FORWARD。

从 < 2.3.0 版本升级
从 2.3.0 开始，定制安卓原生工程时，需注意 Android 与 Android Instant 使用了同一个构建模板。

如果是 Android 平台单独使用的代码请放入 app/src 目录, 单独使用的第三方库请放入 app/libs 目录。
如果是 Android Instant 单独使用的代码和第三方库请分别放入 game/src 和 game/libs 目录。
如果是 Android 和 Android Instant 共用的代码和第三方库，请分别放入 proj.android-studio 根目录底下的 src 目录和 libs 目录。
proj.android-studio 根目录底下 jni/CocosAndroid.mk、jni/ CocosApplication.mk，主要用于配置引擎相关的配置，开发者的配置，建议 Android 放到 app/jni/Android.mk 和 app/jni/Application.mk 中， Android Instant 请放入 game/jni/Android.mk 和 game/jni/Application.mk 中。

此外，在 Cocos Creator 编译 Android 时会默认执行 assembleRelease/Debug，编译 Android Instant 时会执行 in stant:assembleRelease/Debug。
如自定义了音频前后台切换时的暂停逻辑，升级到 2.3.0 后请移除。
目前 Creator 游戏在所有平台上前后台互相切换时，都会在内部自动暂停和恢复音频。
如果开发者之前有对这一块进行过定制，监听并执行了 cc.audioEngine.pause()/resume() 之类的音频操作，可能会和引擎默认行为冲突。如果有遇到相关的音频问题，只需移除相应的定制代码即可。
从 2.0 - 2.3.0 版本升级

从 2.3.0 开始，Canvas 组件不再负责将 Canvas 节点尺寸设为屏幕大小，此行为将结合 Widget 组件实现。为保证兼容性，2.0 项目升级后，Canvas 所在节点会自动添加 Widget 组件。（从 1.x 项目升级无此问题）
从 < 2.2.0 版本升级

从 2.2.0 开始，我们强化了内存管理机制，现在要求用户通过代码动态创建且独立于场景节点树的 cc.Node 必须通过 destroy() 释放，否则引擎无法知道何时回收这类节点的内存，会导致内存泄露。

如原先手动从场景中移除的节点，在不需要用到的时候也需要统一 destroy()：

 // 假设 testNode 是场景中的某个节点，若之前被手动移出场景了，如    testNode.parent = null;    // 或者    testNode.removeFromParent(true);    // 或者    parentNode.removeChild(testNode);    // 若往后 testNode 还会再次用到，则无需手动 destroy 该节点    // 否则应该手动调用    testNode.destroy();

如原先通过 cc.removeSelf 这个 action 销毁节点，请改为使用 cc.destroySelf。
如原先通过 cc.NodePool 管理节点，则不受影响。

从 2.2.0 开始，我们不再建议你使用节点的 Skew 功能。

Skew 通常用作在 2D 引擎中模拟 3D 效果，随着 Cocos Creator 对 3D 节点的深入支持，Skew 效果已经完全可以由 3D 节点来实现。
为了统一使用体验，进一步优化引擎底层实现，我们废弃了 Skew 属性。我们依旧会保留一段时间内的向下兼容，开发者可在旧项目中延续原有做法。
后续我们将进一步完善兼容方式和升级案例，择机正式移除 Skew 功能。
从 < 2.0 版本升级
打开 1.x 项目的话，场景等所有资源将会自动升级，代码中的废弃接口从 2.3.3 开始将会在保持兼容的基础上同步输出报错。
升级方式可参考 [1.10 资源升级指南] 和 [2.0 升级文档] 进行调整。

答疑

3D 项目应该用 Creator v2.x 还是 Creator 3D？

随着 Creator v2.x 对 3D 的支持越来越完善，以及 Creator 3D 自身的发展也越来越成熟，我们也遇到了不少开发者在立 3D 项目时的疑问：既然 Creator v2.x 和 Creator 3D 版都支持 3D，那么我应该选择哪一个引擎？
在这里我们统一解答下：
1. 如果需要集成 TiledMap、Box2D 或者 Spine，或者想要更稳定和高性能的 UI/2D 表现，或者想要发布到原生平台，暂时只能用 Creator v2.x。
2. 如果 3D 场景特别多或者特别大，或者有骨骼动画融合、换装、过渡等表现需求，或者需要更高级别的渲染能力，只能用 Creator 3D。
3. 简而言之，如果是 2.5D 项目，通常采用 Creator v2.x；如果是纯 3D 的轻度项目，一般两个引擎都能胜任；如果是 3D 重度项目，通常采用 Creator 3D。
当然，以上判断标准并不是绝对的。我们也遇到能力强的开发者在 2.x 上实现了大地形及次世代效果，甚至从 3D 往 2D 移植了 GPU 粒子、GPU Instancing、GPU 骨骼动画等功能。
开发者可以在立项前期对两个引擎进行充分的技术预研、压力测试，结合团队自身实际情况进行选择。
以上就是本次更新的内容，点击“阅读原文”前往官网下载更新，大家有任何意见或者建议，可以通过论坛等渠道向我们反馈喔！