v2.2.1 在 v2.2.0 的基础上进行了大量的体验优化和缺陷修复，更全面地优化了性能，同时加入了支付宝小游戏的支持。建议所有版本的开发者升级，升级之前请根据项目情况进行必要的技术评估和版本备份！
随着小游戏的发展，小游戏领域也越来越被更多厂商所重视，而新的平台也意味着新的机遇。作为国内的电商巨头，支付宝近期开放了小游戏的支持，Creator 也在第一时间进行了适配，并在 v2.1.4 整合了发布到支付宝小游戏的能力。目前 Cocos Creator 2.2.1 也同步支持了支付宝小游戏，使用说明请参考《发布到支付宝小游戏》。
游戏引擎插件是微信 7.0.7 版本新增的一项功能，能极大减少游戏的下载时间。对于这个重大利好，Cocos 在第一时间就发布了对应的编辑器插件，提供了对 Creator 老版本的有力支持。目前此功能也正式合并到了 v2.2.1 中，使用起来会更加便捷。开发者们只需在 构建发布 面板中，勾选“允许分离引擎”，然后正常构建发布即可，无需其它人工操作。详见《微信小游戏引擎插件使用说明》。
// 假设 testNode 是场景中的某个节点，若之前被手动移出场景了，如testNode.parent = null;// 或者testNode.removeFromParent(true);// 或者parentNode.removeChild(testNode);// 若往后 testNode 还会再次用到，则无需手动 destroy 该节点// 否则应该手动调用testNode.destroy();
为了让你的游戏在每一个平台上都表现出色，Cocos Creator 每一天都在努力发展中。此次发布的 2.1.4 在 2.1.3 的基础上增加了支付宝小游戏的支持，欢迎大家抓住时机，抢先体验！
Cocos Creator 正式支持发布到支付宝小游戏这个全新平台。由于 Cocos Creator 为开发者抹平了平台之间的引擎差异，开发者发布到支付宝小游戏就和发布到其余平台一样轻松。关于平台接入的详细步骤，请查阅《发布到支付宝小游戏》。据悉，目前支付宝小游戏的各项平台能力正在陆续开放中，同时也对产品的合作持开放态度，大家可以提前准备，迎接新的机遇。
Cocos Creator 2.2.1 正在论坛火热公测中，欢迎体验。此版本也将集成支付宝小游戏的发布支持，并且继续提升原生平台的执行效率，优化场景切换、对象排序时的运行表现。正式版将于不久发布，敬请期待。
为了让你的游戏在每一个平台上都表现出色，Cocos Creator 每一天都在努力发展。此次更新的 v2.2 版本在大幅提升了原生平台性能的同时，也是 Cocos Creator 第一次在原生性能上超越 Cocos2d-lua 的里程碑版本！v2.2 包含了大量的功能增强和体验改进，欢迎所有版本的开发者升级感受。
What's New
大幅提升原生平台渲染性能
在此版本中，我们对渲染引擎进行了大幅度升级，在原生平台上实现了巨大的性能提升，不仅完胜了所有 Cocos Creator 过往版本，更超越了 Cocos2d-JS 和性能一贯优异的 Cocos2d-lua。因此 2.2 版本的 Cocos Creator，已经能够在原生平台上满足所有 Cocos 新老开发者的性能需求。
在这次的性能测试中，我们选取了 Android 和 iOS 两款比较有代表性的低端机型 OPPO A57 和 iPhone 6S Plus，以便贴近真实使用场景，因为通常高端机型的性能问题都不大。我们对比测试了 Cocos Creator 2.2.0、Cocos Creator 1.9.3，还有最传统和有代表性的 Cocos2d-JS 3.17.1 及 Cocos2d-lua 3.17.1。测试结果表明：
此外，2.2 版本在 iOS 不但帧率获得提升，GC 时的卡顿也大大减轻，实际体验将更加流畅。
下面是详细性能数据：
支持 3D 模型渲染合批
此版本加入了对 3D 模型的渲染合批的支持，该特性能有效降低 3D 游戏的 Drawcall。要启用此特性，你只需在 Mesh Renderer 上勾选 enableAutoBatch 属性，引擎便会根据所用材质，以及 Mesh 的顶点格式、Primitive Type 自动进行合批。为了获得更好的优化效果，建议你只对那些可以被合批并且顶点数量较少的模型启用此选项。
支持 PVR 压缩纹理的 alpha 通道分离
我们在此版本中新增了 PVR 压缩纹理的 alpha 通道分离格式（RGB+A）。
该格式使用类似 etc1 的处理方式对纹理的透明通道进行分离和压缩，压缩后纹理高度将会是原图的两倍，因此能避免常规的 PVR RGBA 格式画质很低的问题。
支持自定义浏览器预览模板
允许用户采用类似自定义构建模板的方式对浏览器预览所用的网页进行定制，支持 html、jade、ejs 三种网页格式，详见《网页预览定制工作流程》。
支持环境光设置
我们在 Light 组件中新增了环境光（ambient）类型设置，用于对 3D 场景进行基础照明，常用于解决模型背光面全黑的问题。只需要在节点创建菜单中选择“Create Light → Ambient”即可。也可以在节点上添加 Light 组件，并且设置 type 为 AMBIENT 进行创建。
进一步提升 Spine 和 DragonBones 的性能
在 2.2.0 版本中，我们再次优化了 2D 骨骼动画在各个平台上的性能。
下面是详细数据：
要启用加速模式，只需要在 Spine 或 DragonBones 组件上设置 Animation Cache Mode 为 SHARED_CACHE 或 PRIVATE_CACHE 即可。关于加速模式的更详细信息，可参考文档中的属性说明。
升级 Spine 运行库到 3.7
大幅增强 TiledMap支持
2.2 进一步完善了 TiledMap 的支持。现在可支持 grid 旋转、grid 动画、图象图层、图层偏移、object group 文本，支持单个图层多个 tileset。还支持在场景中添加子节点，并与地图产生遮挡关系。并且修复了单个地图顶点超过 65535 后渲染错误的问题。文档详见《TiledMap 组件参考》，使用案例详见引擎自带范例中的 ShieldNode。
属性检查器标签支持宽度调节
我们为属性检查器加入了宽度调整功能，用以解决在某些组件上属性名显示不全的问题。现在用户无需大幅调整整个面板的尺寸，只需要拖动属性名右侧的分割线就可以自由调节分割比例。
Release Notes
Improvements
Editor
Engine
Native
Web
Mini Game
REMOVED
BREAKING CHANGES
KNOWN ISSUES
label.enabled = false 替换为 label.node.active = false 或者 label.node.opacity = 0升级说明
此外，手动从场景中移除的节点，在不需要用到的时候也需要统一 destroy。如果通过 cc.NodePool 管理节点，则不受影响。
// 假设 testNode 是场景中的某个节点，若之前被手动移出场景了，如
testNode.parent = null;
// 或者
testNode.removeFromParent(true);
// 或者
parentNode.removeChild(testNode);
// 若往后 testNode 还会再次用到，则无需手动 destroy 该节点
// 否则应该手动调用
testNode.destroy();
自从 Cocos Creator 2.1.0 发布以来，经过了半年的更新迭代，版本已经趋于稳定，目前 2.1 的新增用户已经占据主流。因此我们计划减少 2.0 版本的后续维护力度，将分散的精力集中投入到后续发展中，力争将 Cocos Creator 打造成更加专注、开放、健康的开源平台。
本次更新的 v2.1.3 版本，旨在优化体验和修复缺陷，建议所有开发中的 v2.0、v2.1 项目升级。详细的改动说明如下：
为了支持即将发布的 iOS 13 操作系统，我们将 iOS 原生平台上的 VideoPlayer 底层实现由 MPMoviePlayerController 替换为了 AVPlayerContoller[#1831]，同时将WebView 底层由 UIWebView 替换为了 WKWebView[#1837]。
随着小游戏的玩法越来越丰富，开发者对于扩大包大小的需求越来越强烈，所以 vivo 小游戏提供了分包加载这一个功能。 所谓的分包加载，即把游戏内容按一定规则拆分为几个包，在首次启动时先下载必要的包，这个必要的包我们称为「主包」，开发者可以在主包内触发其它分包的下载，从而把首次启动的下载耗时分散到游戏运行中。详细说明请参考[分包加载]
自从 Cocos Creator 2.1.0 发布以来，经过了半年的更新迭代，版本已经趋于稳定，目前 2.1 的新增用户已经占据主流。因此我们计划减少 2.0 版本的后续维护力度，将分散的精力集中投入到后续发展中，力争将 Cocos Creator 打造成更加专注、开放、健康的开源平台。
本次更新的 v2.1.2版本，不仅包含了常规的体验优化和缺陷修复，还着重优化了纯 2D项目的包体，以及自动图集的生成尺寸，建议所有 v2.0 开发者升级。同时，该版本也合并了 v2.0.10 的所有改动，支持了小米快游戏和即刻玩小游戏这两个全新平台。详细的改动说明如下：
根据之前公开的说明，为了加快迭代速度，我们一直将 v2.1 定位为一个 3D 先行版，所以 v2.1 对纯 2D 项目的照顾是有滞后的。这一点主要体现在对 3D 新增的模块切割得不够干净，导致纯 2D 项目的包中也会加入一些些没用到的代码片段。这并不符合我们的产品理念，所以我们之前还不建议 v2.0 项目全面升级。
此次发布的 v2.1.2 经过细致优化，顺利解决了这个包体问题。现在我们正式推荐所有 v2.0 项目升级到 v2.1.2，从 v2.0 升级上来的项目将默认剔除3D 模块，确保不会对 2D 项目的包体、性能产生影响。如需增加 3D 支持请手动在"菜单 → 项目 → 项目设置 → 模块设置"中勾选 3D 模块。
Cocos Creator 正式支持发布到小米快游戏，详细用法请查阅《发布到小米快游戏》。
Cocos Creator 正式支持发布到即刻玩小游戏，详细用法请查阅《发布到即刻玩小游戏》。
从 v2.0.0 用 3D 渲染器重写底层至今，Cocos Creator 经过多个版本的稳步迭代，终于进化成了一款能无损兼顾纯 2D 和 3D 两种项目类型的游戏引擎。将来 Cocos Creator 仍会秉承“2D 优先”的理念，继续死磕 2D 游戏开发体验及基础性能，逐步引入那些适合融入 2D 游戏的 3D 特性，陪伴 2D 游戏团队共同成长。
值得一提的是，近期发布的 Cocos Creator 3D Beta，是一套独立于 Cocos Creator 2.1 的全新产品线，和目前 2.1 新增的 3D 功能在定位上有明显区别。Cocos Creator 3D 融合了 Cocos 在 3D 领域多年来的探索和积累，立足于 3D 次世代引擎的长远发展，会更加适用于对 3D 表现力有高级需求的 3D 开发团队。
本次发布的 2.0.10 重点提升了原生平台的稳定性，修复了 Spine、DragonBones 和 Label 等相关问题，建议所有 2.0 用户进行升级。此外，2.0.10 还支持发布到小米快游戏和即刻玩小游戏这两个全新平台，为开发者们带来了新的机遇。良好的品质离不开细心的打磨，非常感谢各位开发者通过社区、GitHub、Cocos 企业服务等渠道反馈的意见。
以下是相对于 2.0.9 的改动说明：
Cocos Creator 正式支持发布到小米快游戏，详细用法请查阅《发布到小米快游戏》。
Cocos Creator 正式支持发布到即刻玩小游戏，详细用法请查阅《发布到即刻玩小游戏》。
自从 Cocos Creator 2.1.0 发布以来，我们收到了来自用户大量的宝贵建议。根据之前公布的计划，我们会持续加快对 v2.1 系列的迭代，以便尽快消化用户们的建议。同时为了防止这些改动影响到老项目的稳定性，我们仅推荐有 3D 需求的项目升级到 v2.1，其它项目可以继续使用 v2.0，等到 v2.2 发布后再同时升级上来。本次 v2.1.1 的升级主要支持了 3D 场景编辑、摄像机预览和光照系统，同时也合并了最新 2.0.x 的有关改动。
场景编辑器允许一键切换至 3D 编辑模式，方便对 3D 对象、摄像机、灯光进行编辑。详见文档《3D 场景》。
新增了独立的预览面板，能够在场景编辑的过程中直观地预览摄像机看到的画面。面板打开方式：主菜单 → 面板 → 游戏预览，预览面板可置于独立窗口，也可拖进编辑器主窗口。
新增了 Light 组件，用于在场景中布置光源，还可结合MeshRenderer 设置阴影效果。详见文档《光源组件参考》。
现在用户可以单独设置 Text Label、Placeholder Label 和 Background 节点，变得更加灵活和简单，也更符合组件化的开发方式。详见文档《EditBox 组件参考》。
新增了 LabelShadow 组件，用于给 Label 组件添加阴影效果，和 LabelOutline 用法类似。详见文档《Label 组件参考》。
添加了 cc.primitive模块，用于在运行时动态创建 3D 模型，如 box、cone、cylinder、plane 等。详见文档《基础 3D 物体》。
加入了材质系统的支持，允许用户创建 Material 和 Effect（Shader）资源类型。需注意的是，目前的材质系统主要是提供给引擎内部使用，仅供开发者预览。我们计划在 2.1.2 就对材质系统进行大幅度升级，届时此版本的材质将无法升级到 2.1.2。
本次发布的 2.0.9 版本新增了对 百度小游戏 平台的支持，并且大幅优化了 Spine
和 DragonBones 在小游戏和 Web 平台上的性能，优化了微信小游戏的资源加载性能和动态文本刷新效率。同时，我们进一步完善了引擎和编辑器的兼容性、稳定性，让大家能够获得更好的开发体验。良好的品质离不开细心的打磨，非常感谢各位开发者通过社区、GitHub、Cocos 企业服务等渠道反馈的意见。
以下是相对于 2.0.8 的改动说明：
Cocos Creator 正式支持了发布到百度小游戏，详细用法请查阅 发布到百度小游戏平台。
之前 Cocos Creator 在 2.0.7 版本中，已经大幅优化过了 DragonBones 和 Spine 在原生平台上的性能，优化后的性能甚至比 1.9、1.10 还快了平均一倍。而这次发布的 2.0.9，则又针对 Web、小游戏等非原生平台，新增了SHARED_CACHE 和PRIVATE_CACHE 两种加速模式，使 DragonBones 的性能提升了 15 倍，Spine 的性能提升 3 - 6 倍。 启用加速模式后的性能测试结果：
在同屏播放三个以上的动画时，SHARED_CACHE 加速模式还能大幅降低内存开销，以下是同屏一百个动画的内存对比：
要启用极速模式，只需要在 DragonBones 或 Spine 组件上设置 Animation Cache Mode 为 SHARED_CACHE 或 PRIVATE_CACHE 即可。关于极速模式的更详细信息，可参考文档中的属性说明。
针对微信小游戏缓存资源耗时较长的问题，我们调整了资源缓存策略，将耗时较长的缓存操作自动延后（#72），缩短了资源加载所需的等待时间。
微信小游戏 7.0.3 版本开始，底层 texImage2D调用耗时过长，导致 Label 渲染系统字体或 ttf 字体时，一旦文字内容发生改变就会影响性能。为此，我们在 Label 组件上新增了一个 Cache Mode 选项，该选项设为 CHAR 模式后，就能彻底解决这个性能问题。Cache Mode 可设置的值有：
其余需要注意的是：
微信小游戏已计划在后续版本中支持开放数据域中的 WebGL 渲染模式，我们提前对其进行了适配。开发者无需做任何操作，当微信正式推出支持后，游戏就会自动在子域中启用 WebGL，获得更好的性能。不过需要注意的是，这会导致在目前版本的微信客户端中运行时出现“[GameOpenDataContext] 子域只支持使用 2D 渲染模式”的报错，该报错是引擎检测当前环境是否支持 WebGL 所产生的，不会影响到项目运行，请先无视。
在构建面板的 Android 平台下，新增了 App Bundle 选项，勾选后即可将 Android 原生游戏发布为 App Bundle。将 App Bundle 提交到 Google Play 后，Google Play 将会根据玩家手机参数的差异，动态下载不同版本的 APK，达到减少游戏的包体的目的。
最近刚刚发布的 Cocos Creator v2.0.6主要提供了在 Android 和 iOS 上快速接入 Facebook Audience Network和 Facebook Live Video的支持，同时优化了 vivo/OPPO 小游戏的构建流程。 这次发布的 2.0.7 则在 2.0.6 的基础上，进行了比较大的升级。修复了不少 2.0.5 以来遗留的问题，大幅 提高了原生平台的骨骼动画性能，同步了 2.1.0 的一些改进，建议所有平台还在开发阶段的项目进行升级。以下是相对于 2.0.6 的改动说明：
Cocos Creator 正式支持了发布到华为快游戏，详细用法请查阅发布到华为快游戏平台。
之前有不少用户反馈 Cocos Creator 升级到了 2.0 后，原生平台的骨骼动画性能很差，甚至被迫退回到 1.9 或 1.10 版本，为此我们深表歉意。为了解决这个问题，此次更新大幅优化了原生平台上的 Spine 和 DragonBones 的性能，下面是性能测试结果：
测试的分值根据帧率换算而来，值越高性能越好。可以很明显看到，优化后的性能甚至比 1.9、1.10 还快了平均一倍。另外除了性能上的优化，这个版本还支持了 DragonBones 的二进制格式（.dbbin）。
还需要注意的是，这个版本如果运行在 iOS 9 的系统上，反而会引起负优化。因为这个版本更加倚重了 JavaScript 的 TypedArray 数据结构，而 iOS 9 中的 JavaScriptCore 并不支持 TypedArray，所以性能开销反而会变大。iOS 10 或后续的系统都没有这个问题。建议如果项目一定要支持到 iOS 9，则停留在 1.x 版本。
v2.0 相比 v1.x，有一些情况引擎不会合并渲染批次，导致了 Draw Call 的增加，例如 Color 或 Opacity 不同，或者共用同一贴图的多个 Sprite 组件混用 Simple、Sliced 或 Filled 模式时的情况。这些问题在该版本都得到了优化，只要它们所在节点的 group 相同，Draw Call 都会被合并。此外，节点 Opacity 为 0 会占用 Draw Call 的问题也优化了。
之前如果场景中同时存在着不少 Label 和 Button 之类的图片，并且它们相互叠加，则会打断渲染引擎的合并操作，使得 Draw Call 升高。这个问题在这个版本中得到了进一步优化。在该版本中，如果 Label 使用的是 TTF（或系统字体），受益于增强后的 动态合图机制，这些 Label 都将尽可能与其它纹理进行批次合并。只要满足动态合图的要求，总共就只会有一个 Draw Call。该优化只适用于不会频繁更新的 Label，因此需要手动勾选 Label 上的”Batch As Bitmap”来启用。同时，由于兼容性问题，该优化在桌面端的 Chrome 和微信小游戏暂时不会启用，有需要测试 DrawCall 的话请使用真机或其它浏览器。此外，该版本也修复了 BMFont 和其它图片打包为自动图集后，仍然无法合并 Draw Call 的问题。如果 Label 使用了 BMFont，可以尝试将 BMFont 所用的图片和在场景中与其相互打断的图片设置为同一个自动图集，就能提升渲染性能。
新增了独立的一体化 服务面板，通过这个面板，用户可以快速的为游戏集成服务，详见 服务面板。
由于微信小游戏天然适合从用户的 CDN 中远程加载资源，因此在前期的版本中 Cocos Creator 仅提供了代码分包功能，资源分包还未实现。通过近期和用户的交流，以及和 Cocos 其它内部团队的合作，这个版本正式加入了资源分包的支持，使用方法和原来的代码分包完全一致，详见 分包加载。
在项目设置 - 预览运行面板中，新增了“开启模拟器调试界面”选项和“等待调试器连接”选项。前一个选项的作用是，在模拟器预览项目时将自动打开调试窗口。后一个选项的作用是，暂停启动过程直至调试器连接完成，用于调试加载过程。
安卓的 NDK 版本需要升级到 r16，否则将编译失败。
从 v2.0.1 开始，Cocos Creator 升级了开放数据域解决方案，请参阅 接入小游戏开放数据域。
详见 v2.0 升级指南。
从 v1.10 开始，Cocos Creator 对底层资源类型进行了重构，大多数项目不受影响，但有些项目可能会收到一些警告，详情请查阅 v1.10 资源升级指南。
相比 v2.0，v2.1 的提升将主要围绕 3D 领域，我们推荐有 3D 需求的新项目升级到这个版本，并且在论坛等渠道和我们建立联系，我们负责 3D 的小伙伴将提供相关支持。由于 2.1 是一个很新的版本，我们将加快迭代频率，尽量满足开发者的需求。2.1 的下一个版本是 2.1.1，该版本将支持 3D 场景编辑、摄像机预览和材质系统，同时也会合并 2.0.7 的这些改动。
根据微信团队的通知，微信 Android 端将调整小游戏“在屏Canvas” 的放缩策略。在现有的 Creator 版本中，cc.view.enableRetina(true)默认是会调用的，你无需做出任何改动，一般不会遇到适配问题。如果有需要，也可以在发布后的 main.js 中，手动修改 cc.view.enableRetina为 false。
Cocos Creator v2.0.6 基于 v2.0.5 升级而来，在保证 v2.0.5 稳定性的基础上，提供了在 Android 和 iOS 上快速接入 Facebook Audience Network和 Facebook Live Video的支持。Facebook Audience Network 是 Facebook 推出的广告平台，提供了强大的广告变现的能力。Facebook Live Video 是 Facebook 推出的直播 SDK，允许玩家在玩游戏的时候直接进行游戏直播，并且分享到 Facebook 的社交网络，有效提高了游戏的传播能力。有关这两个 SDK 的具体接入流程，请参考文档《Facebook 直播和广告》。此外，这个版本还优化了 vivo/OPPO 小游戏的构建流程，建议要发布 vivo/OPPO 小游戏的项目及时升级。
v2.0.7 即将发布，重点优化原生平台性能我们很快将对 v2.0.7 进行公测，在这个版本中我们优化了引擎的渲染性能，尤其是原生平台的 Spine 和 DragonBones，性能都有了很大幅度的提升。v2.1 的迭代将会比较激进相比 v2.0，v2.1 的提升将主要围绕 3D 领域，我们推荐有 3D 需求的新项目升级到这个版本，并且在论坛等渠道和我们建立联系，我们负责 3D 的小伙伴将提供相关支持。由于 v2.1 是一个很新的版本，我们将加快迭代频率，尽量满足开发者的需求。我们将会在近期就推出 v2.1.1 版本，用来支持 3D 场景编辑、摄像机预览和材质系统，优化 3D 开发流程。
Cocos Creator 从 v2.1 版本开始，最大的改动就是支持了 3D 模型渲染、3D Camera、3D 骨骼动画、3D 点选等 3D 特性，同时编辑器原生支持解析 FBX 格式的 3D 模型文件，不需要额外的导入流程。
在之前的 v2.0 中，Cocos Creator 就已经用上了基于 Cocos3D 的 3D 渲染器，具备了正式引入 3D 支持的基础。3D 特性的加入可以大大丰富 2D 游戏的表现力，减轻 2D 游戏的资源开销，带来更多的想象与扩展空间。不过需要强调的是，Cocos Creator 的目标用户仍然是现有的 2D 游戏开发团队，2D 游戏仍然是 Cocos Creator 2.x 时代的核心服务目标。我们会坚持优化 2D 游戏的开发体验及基础性能，逐步增加适合融入 2D 游戏的 3D 功能，陪伴 2D 游戏团队共同成长。因此，Cocos Creator 不会成为一个纯 3D 引擎，那是 Cocos3D 的目标。Cocos Creator 的发展路线更接近 2.5D。
这不是 Cocos 第一次把引擎从 2D 升级到 3D，几年前 Cocos2d-x 就在 3D 领域进行过扩展，积累了不少经验，更诞生了“剑与家园”这样非常优秀的作品。不过当时是在一套已经很重的 2D 渲染器上堆砌 3D 功能，也缺乏编辑器支持，因此最终并未得到市场的广泛认可。而这一次，Cocos Creator 是在 Cocos3D 的 3D 渲染器基础上，直接把 3D 潜能释放出来，也保证了无缝的编辑器使用体验，因此这次的改变是完全不同性质的。
v2.0 和 v2.1 将在一段时间内共同发展，v2.0 会继续维护，增加更多的性能优化和缺陷改善。我们很快将对 v2.0.7 进行公测，在这个版本中我们优化了引擎的渲染性能，尤其是原生平台的 Spine 和 DragonBones，性能都有了很大幅度的提升。
相比 v2.0，v2.1 的提升将主要围绕 3D 领域，我们推荐有 3D 需求的新项目升级到这个版本，并且在论坛等渠道和我们建立联系，我们负责 3D 的小伙伴将提供相关支持。由于 v2.1 是一个很新的版本，我们将加快迭代频率，尽量满足开发者的需求。特别是目前 v2.1.0 版本仍不支持 3D 场景编辑，仅能够在属性检查器中对节点进行 3D 参数的设置。我们将会在近期就推出 v2.1.1版本，用来支持 3D 场景编辑和材质系统，优化 3D 开发流程。
在 2.1 中，默认新创建出来的节点都仍然是 2D 的，当有需要时，只需要点击节点右上方的 2.5D 按钮就能切换成 3D 模式，切换后就能编辑 z 轴，详见 [3D Node]。
和 Node 一样，Camera 也分为了两种模式。当你把 Camera 组件添加到普通的 2D 节点上时，它就是一个 2D Camera。当你把 Node 切换到 3D 模式后，Camera 也会进入 3D 模式，3D 模式下即可编辑 Camera 的 FOV 等参数。
目前 Cocos Creator 支持导入的 3D 模型格式为使用非常广泛的 .fbx，基本上 3D 建模软件都支持导出这种格式。导入的流程很简单，只需要将 .fbx 模型资源拖入到资源管理器，等待片刻即可完成导入工作。导入完成后，在资源管理器中看到导入后的模型资源是一个可以展开的文件夹，导入模型的时候编辑器会自动解析模型的内容，并生成 Prefab、网格、骨骼动画等资源，详见[导入模型]。
Mesh Renderer 用于绘制网格资源，详见[Mesh Renderer 组件]。
骨骼动画组件继承自 Animation 组件，骨骼动画组件的使用方法与 Animation 组件没有太大区别，只是骨骼动画组件使用的剪辑只能是骨骼动画剪辑。骨骼动画组件将在导入模型时自动添加到模型的 Prefab 中，详见[骨骼动画组件]。
更多 3D 相关说明，请查阅文档[3D 系统]。
大幅优化自动图集构建速度，如果图集没有改变的话则直接使用上次构建的结果。
v2.0 相比 v1.x，有一些情况引擎不会进行渲染批处理，导致了 Draw Call 的增加。v2.1 对这些情况重新进行了优化。如之前 Color 或 Opacity 不同无法批处理，Sliced 和非 Sliced 共用同一贴图无法批处理，Opacity 为 0 的节点仍占用 Draw Call 的问题都得到了解决。
在项目设置 - 预览运行面板中，新增了“开启模拟器调试界面”选项和“等待调试器连接”选项。前一个选项的作用是，在模拟器预览项目时将自动打开调试窗口。后一个选项的作用是，暂停启动过程直至调试器连接完成，用于调试加载过程。
可以直接在编辑器中设置纹理需要的压缩方式，Creator 将在项目发布时自动对纹理进行压缩。在 Web 平台上支持同时导出多种图片格式，引擎将根据不同的浏览器自动下载合适的格式，详见[压缩纹理]。
从 v2.0.1 开始，Cocos Creator 升级了开放数据域解决方案，请参阅[接入小游戏开放数据域]。
从 v1.10 开始，Cocos Creator 对底层资源类型进行了重构，大多数项目不受影响，但有些项目可能会收到一些警告，详情请查阅[v1.10 资源升级指南]。
以上就是 Cocos Creator v2.1.0 的更新说明。各位开发者进入 Cocos 官网下载新版本，下载完毕新建一个 example 工程，打开 assets/cases/3d 下的案例即可体验。
v2.0.5 相比不久前发布的 v2.0.2，提供了发布到 OPPO 小游戏和 vivo 小游戏平台支持，修复了不少问题，进一步提升了产品稳定性，强烈建议所有 2.0 用户及时更新版本。良好的品质离不开细心的打磨，非常感谢各位开发者通过社区、GitHub、Cocos 技术服务等渠道反馈的意见。
Cocos Creator 正式支持了发布到 OPPO 小游戏，详细用法请查阅 [发布到 OPPO 小游戏平台]。
Cocos Creator 正式支持了发布到 vivo 小游戏，详细用法请查阅 [发布到 vivo 小游戏平台]。
从 v2.0.1 开始，Cocos Creator 升级了开放数据域解决方案，请参阅 [接入小游戏开放数据域]。
详见 [v2.0 升级指南]。
从 v1.10 开始，Cocos Creator 对底层资源类型进行了重构，大多数项目不受影响，但有些项目可能会收到一些警告，详情请查阅 [v1.10 资源升级指南]。
v1.10.2 是对不久前发布的 v1.10.1 的缺陷修复，建议所有 1.10 用户及时更新版本。2.0 用户无需降级，因为该版本的修复都已经包含在近期发布的 v2.0.2 中。此外，v1.10.2 并未包含 v2.0.2 中对微信小游戏和 QQ 玩一玩的完整修复，因此如果需要发布到小游戏平台，还是建议升级到最新的 v2.0.2 版本。良好的品质离不开细心的打磨，非常感谢各位开发者通过论坛、GitHub、Cocos 技术服务等渠道反馈的意见。
2.0.0 是一个经历了大量底层重构的全新版本，部分开发者在升级项目过程中遇到了一些恼人的问题，这些问题我们一一收集并尽全力解决，现在为大家带来 2.0.1 版本。这个版本除了大幅度提升稳定性和项目升级的友好度以外，我们还为开发者带来了全新的微信小游戏开放数据域方案，大幅度提升开放数据域性能和使用的灵活度。
v1.x 的大量私有以及非核心 API 被移除或废弃，详细内容可以参考升级指南.
经历了大规模的底层重构和为期两个月的稳定性迭代，Cocos Creator v2.0 终于和大家见面了。总体上来说，Cocos Creator v2.0 设计的核心目标有两点：
为了完成这个目标，我们彻底重写了底层渲染器，从结构上保障了性能的提升和渲染能力的升级。同时，为了保障用户项目可以更平滑得升级，我们几乎没有改动组件层的 API。当然，这些改动并不是对用户完全透明的，比如引擎加载流程、事件系统、引擎整体 API 的精简和重组，这些都会带来对用户层 API 的影响，我们希望通过升级指南、文档和 deprecation 信息等方式帮助大家升级。
v1.10.1 是对不久前发布的 v1.10.0 的缺陷修复，建议所有 1.10 用户及时更新版本。该版本不是 2.0 的替代版本，2.0 仍然是目前的最新版，新项目仍然建议直接上 2.0。作为 2.0 之前的最后一个大版本，我们会尽量维护到稳定为止，以支持暂时无法升到 2.0 的用户。良好的品质离不开用心的打磨，非常感谢各位开发者通过论坛、GitHub、Cocos 技术服务等渠道反馈的意见。让我们共同期待即将发布的 2.0.1！
v1.10 版本相比 v1.9 新增了大量特性，重构了引擎的资源部分，大幅度优化了 settings.js 文件的体积。此外，1.10 还在微信小游戏及 Web、原生平台上都支持了游戏代码分包功能。这样一来便能够突破微信首包 4MB 的限制，并且提升游戏载入速度，详见[代码分包加载]。与此同时，1.10 对不少编辑器代码进行了重写，提升了编辑器的使用体验和性能。
如果您的项目计划升级到之后的 v2.0，请提前升级到 v1.10，这样能保证整个升级过程尽量平滑。
从 10 开始，Cocos Creator 对底层资源类型进行了重构，大多数项目不受影响，但有些项目可能会收到一些警告，详情请查阅[v1.10 资源升级指南]。
从 v1.10 开始，安卓构建面板中的 API Level 指定的是编译出的 apk 所支持的最低 Android 版本，建议选择 14。 targetSdkVersion 、 compileSdkVersion 、 buildToolsVersion 都升级到了 26。
如果开发者有其它需要，可以手动修改 proj.android-studio/app/build.grade 和 proj.android-studio/gradle.properties 。
v1.9.3 是对不久前发布的 v1.9.2 的缺陷修复，主要完善了对微信小游戏及 QQ 玩一玩的支持，建议所有 1.9 用户及时更新引擎版本，获得更好的体验。良好的品质离不开细心的打磨，非常感谢各位开发者通过论坛、GitHub、Cocos 技术服务等渠道提交的 BUG 反馈。
v1.9.2 是对不久前发布的 v1.9.1 的小幅升级，主要提升了对微信小游戏及 QQ 玩一玩的支持，建议所有需要上微信小游戏或 QQ 玩一玩的项目进行升级。
v1.9.1 版本是对不久前发布的 v1.9.0 的一次小幅升级，主要提升了对微信小游戏及 QQ 玩一玩的支持。
- 支持将整个项目发布到微信小游戏子域，详见文档。
- 支持微信小游戏在构建面板中配置 **远程服务器地址** 选项，方便下载远程资源
- 支持在微信小游戏真机上使用 TTF 字体
- 把微信小游戏的适配层从 ES6 转成 ES5，用户可以不启用 ES6 转 ES5
- 修复微信小游戏中潜在的音频内存泄漏
- 支持 QQ 玩一玩在构建面板中配置 **远程服务器地址** 选项，方便下载远程资源。
- 修复 QQ 玩一玩上 XMLHttpRequest 的一些小 bug
- 修复 QQ 玩一玩构建时无法解析 js 路径的问题
- 完善 QQ 玩一玩上多点触摸的支持
- 增加 QQ 玩一玩对 base64 编码图片的支持
- 完善 QQ 玩一玩适配层
- 完善 QQ 玩一玩的音频支持
- 修复 QQ 勾选 MD5 Cache 后的黑屏问题
- [Editor] [Build] 修复定制项目构建模板功能在 Facebook Instant Games 平台不生效的 bug
- [Editor] [Build] 添加 build-start 事件，方便用户构建之前做一些自己想要做的处理
- [Engine] [Wechat] 修复微信小游戏音频无法停止的问题
- [Engine] [iOS] 修复 iOS 8-9 上面 isTypedArray 方法失效的问题
- [Engine] [Web] 修复粒子系统还未激活就移除的话会导致内存泄露问题
- [Engine] cc.isValid 增加了一个可选参数，传入 true 将在 destroy 的当帧开始就返回 false
- [Engine] [Android] 修复 jni 上的一个内存泄露问题
- v1.8.2 起，不再推荐使用 cc.eventManager，请用 cc.EventTarget 或 cc.systemEvent 代替，原有 API 将在 2.0 移除。
- v1.8.2 起，不再推荐使用 cc.inputManager，请用 cc.systemEvent 的相同接口代替，原有 API 将在 2.0 移除。
- v1.8.2 起，不再推荐使用 dragonBones.CCFactory.getFactory，请用 dragonBones.CCFactory.getInstance 代替，原有 API 将在 2.0 移除。
- 在资源管理器中复制粘贴资源时，资源属性仍不会跟着拷贝。(Since 1.9.0)
目前 QQ 玩一玩仍在灰度测试中，开发者也需要获取内测资格才能进行开发，而且暂时仅支持在 Mac 上进行编译。此外，我们对 QQ 玩一玩的适配工作还未完全结束，目前仍不支持以下模块：
- Label：不支持 TTF，系统字体也只能使用默认字体
- 粒子系统：不支持 plist 中存储贴图数据，只支持贴图 URL
- WebView
- VideoPlayer
- DeviceMotion
以上功能预计在以后的更新中逐个支持。我们也将持续与玩一玩工程师们紧密沟通，不断优化适配效果。
美国时间 3 月 14 日 Facebook 正式对外开放 Instant Games 平台，给所有开发者一个公平的机会可以进入和拓展海外市场。Cocos 引擎作为 Facebook Instant Games 平台的官方合作伙伴，不仅仅在技术接入方面深度合作，游戏开发上支持一键发布游戏；在内容引进方面，更是国内首家 Facebook 官方授权的 Instant Games 游戏接入合作商。所以本次发布的 v1.9.0 正式版本既是对 v1.8.2 的一次功能更新，提升了编辑器的易用性，修复了一些功能缺陷，更主要增加了 Facebook Instant Games 及 QQ 玩一玩的支持，该版本目前已经完整实现三大平台一键平滑支持。建议所有开发中的项目进行升级。
- 支持 Facebook Instant Games [详见文档]
- 支持 QQ 玩一玩
- [Editor] 资源管理器直接支持复制粘贴资源（可通过右键菜单或快捷键）
- [Editor] 在场景编辑器的 Rect 编辑模式下，支持拖动节点的空白区域，便于更改 anchor 的值
- [Editor] 在粒子组件的属性检查器上新增“同步”按钮，点击同步将把 Custom 参数设为和 File 一致。（同步按钮仅在勾选 Custom 并且设置了 File 时才可用）
- [Editor] 在 Timeline 中增加 scale 属性，便于同时编辑 scaleX 和 scaleY
- [Engine] PhysicsManager 新增 FIXED_TIME_STEP 和 MAX_ACCUMULATOR 两个参数
- [Engine] [Web] 修复在部分小米自带浏览器上输入框无法弹出的问题
- [Engine] 修复勾选 MD5 构建后音频可能无法停止的问题
- [Engine] 修复 Label 的描边可能被截断一个像素的问题
- [Engine] 修复 cc.Class 构造函数中的异常无报错信息的问题
- [Engine] [Animation] 修复当 Animation 组件切换动画或手动设置 AnimationState 时间后，会少播放一帧的问题
- [Engine] [Wechat] 修复 iOS 微信小游戏本地代码包超过 4MB 后使用远程服务加载会失败的问题
- v1.8.2 起，不再推荐使用 cc.eventManager，请用 cc.EventTarget 或 cc.systemEvent 代替，原有 API 将在 2.0 移除。
- v1.8.2 起，不再推荐使用 cc.inputManager，请用 cc.systemEvent 的相同接口代替，原有 API 将在 2.0 移除。
- v1.8.2 起，不再推荐使用 dragonBones.CCFactory.getFactory，请用 dragonBones.CCFactory.getInstance 代替，原有 API 将在 2.0 移除。
- 在资源管理器中复制粘贴资源时，资源属性仍不会跟着拷贝。(Since 1.9.0)
- 在原生平台上，调用 `action.easing(cc.ease***)` 方法的话，可能会引起节点逻辑数据不同步。请改用 `cc.ease***(action)`。(Since 1.8.2)
目前 QQ 玩一玩仍在灰度测试中，开发者也需要获取内测资格才能进行开发，而且暂时仅支持在 MacOS上进行编译。此外，我们对 QQ 玩一玩的适配工作还未完全结束，目前仍不支持以下模块：
- Label：不支持 ttf，系统字体也只能使用默认字体
- 粒子系统：不支持 plist 中存储贴图数据，只支持贴图 url
- WebView
- VideoPlayer
- DeviceMotion
其他详细功能请参考 v1.8.2 功能列表。以上暂未支持功能预计在今后的更新中逐个实现，我们也将持续与玩一玩工程师们紧密沟通，不断优化适配效果。
做为年后推出的第一个正式版本，虽然是小版本，重在修复上个版本遗留 bug，但我们还是诚意满满的做出了如下重点改动：完善微信小游戏支持、修复了这些 bug：包括 iOS 平台崩溃问题、用 OBB 替换 AABB 的包围盒检测方式、touch cancel 事件问题等，推荐正准备使用 Creator 的新用户直接开搞 v1.8.2，老用户请记得优化升级！
[Engine] [JSB] 优化原生平台导出的 jsb_polyfill 脚本体积
cc.Texture2D.initWithData 方法不再支持传入最后一个可选参数 contentSize。
在原生平台上，调用 action.easing(cc.ease***) 方法的话，可能会引起节点逻辑数据不同步。请改用 cc.ease***(action)。
如果 Mac 版下载后无法打开，提示 dmg 或者 app 文件已损坏，或者来自身份不明的开发者，这是因为我们升级了数字证书引起。
解决方法在 Finder（访达）中右键点击 dmg 或 app 文件，选择“打开”，然后在弹出对话框中再次点击打开即可。为了下一次可以直接打开，请进入系统偏好设置 -> 安全性与隐私，点击“仍要打开”。
如果这样操作仍无法打开，请联系我们。变通方法是先命令行里执行 sudo spctl --master-disable，再验证账户密码，就能打开了。
有任何安装、升级、使用过程中出现的问题，欢迎直接到社区 forum.cocos.com/c/Creator 发帖提交反馈。
当然如果你希望轻轻松松无需做任何平台移植工作就能一键编译发布到微信小游戏调试环境，那么记得在今天下载 Cocos Creator v1.8.2 试试吧！
引擎团队秉承发布小版本重在修复而不是增加大功能的一贯理念，本次发布的 v1.8.1 版本主要在 1.8 的基础上修正 bug、完善微信小游戏支持，修复了一些原生平台崩溃问题，建议所有开发中的项目进行升级。
另外，上面的改动大部分包含在了之前社区里发布的 v1.7.2 补丁版。 相比 1.7.2版本，v1.8.1 除了支持微信小游戏以外，还新增了以下改动：
[Build] 大幅优化原生平台启用脚本加密后的脚本体积
[UI] 添加 cc.ToggleContainer 组件，v2.0 中将会取代 cc.ToggleGroup。
github.com/cocos-creator/creator-docs/blob/master/zh/components/toggleContainer.md
最近微信小游戏正搞得沸沸扬扬，发布 20 多天即达到了 3.1 亿用户。而且微信方面称，“请大家在未来的一个月内随时关注 mp.weixin.qq.com ”，也许这意味着小游戏很有可能将于一个月内开放注册。
那么，为了把握住这一波浪潮，赶紧试着用「微信小游戏首发占半数的引擎」Cocos Creator 最新版做一款小游戏吧！
早在微信官方正式发布小游戏平台之前，Cocos Creator 团队就和微信开发团队合作完成了 Cocos Creator 对微信小游戏平台的支持。在小游戏正式公布之后，我们也在第一时间发布了完美支持小游戏的 Cocos Creator v1.8。这篇文档的初衷也是希望帮助开发者们在第一时间以最顺畅的方式提交游戏到小游戏平台。
这篇文档将会覆盖：
1、小游戏的运行环境介绍
2、如何使用 Cocos Creator 发布微信小游戏
3、小游戏资源管理
与这篇文档搭配的还有一段教学视频，可以结合视频中的操作来理解，更加直观。
微信小游戏是微信小程序下的游戏产品平台，它不仅提供了强大的游戏能力，还和小程序一样，提供了大量的原生接口，比如支付，社交，文件系统，照片，NFC 等。相当于同时结合了 WEB 易于传播以及 Native 功能丰富的优势。
小游戏的运行环境是小程序环境的扩展，基本思路也是封装必要的 WEB 接口提供给用户，尽可能追求和 WEB 同样的开发体验。小游戏在小程序环境的基础上提供了 WebGL 接口的封装，使得渲染能力和性能有了大幅度提升。不过由于这些接口都是微信团队通过自研的原生实现封装的，所以并不可以等同为浏览器环境。关于游戏方面，目前小游戏环境提供了 Canvas 以及 WebGL 的渲染接口，所以 Cocos Creator 引擎的两种渲染模式都是可以运行的，不过出于性能的考量，我们默认使用 WebGL 渲染游戏内容，强烈建议用户不要修改默认配置。
作为引擎方，为了尽可能简化开发者的工作量，我们为用户完成的主要工作包括：
1、引擎框架适配微信小游戏 API，纯游戏逻辑层面，用户不需要任何额外的修改
2、Cocos Creator 编辑器提供了快捷的打包流程，直接发布为微信小游戏，并自动唤起小游戏的开发者工具
3、自动加载远程资源，缓存资源以及缓存资源版本控制
除此之外，小游戏平台的游戏提交，审核和发布流程和小程序是没有区别的，都需要遵守微信团队的要求和标准流程，具体信息可以参考文末的链接。
我们从 Cocos Creator v1.8 开始，支持 Cocos Creator 游戏一键发布为微信小游戏，下面是详细的发布步骤：
1、在微信公众平台下载微信开发者工具
2、在 "Creator 偏好设置" > "原生开发环境" 中设置微信开发者工具路径
3、登陆微信公众平台，找到 appid
4、在构建面板中设置项目名和 appid
5、构建发布
6、点击 play 打开微信开发者工具
7、预览部署
按照这样的流程，项目的 build 目录下就会生成一个微信小游戏的发布包，其中已经包含了微信小游戏环境的配置文件：game.json 和 project.config.json
在小游戏环境中，资源管理是最特殊的部分，它和浏览器的不同在于下面四点：
1、小游戏的包内体积不能够超过 4mb，包含所有代码和资源，额外的资源必须通过网络请求下载。
2、对于从远程服务器下载的文件，小游戏环境没有浏览器的缓存以及过期更新机制。
3、对于小游戏包内资源，小游戏环境内并不是按需加载的，而是一次性加载所有包内资源，然后再启动页面。
4、不可以从远程服务器下载脚本文件。
这里引出了两个关键的问题，首页面加载速度和远程资源缓存及版本管理。对于首页面加载速度，我们建议用户只保存脚本文件在小游戏包内，其他资源都从远程服务器下载。而远程资源的下载、缓存和版本管理，其实在 Cocos Creator 中，已经帮用户做好了。下面我就来解释一下这部分的逻辑。
在小游戏环境中，我们提供了一个 wxDownloader 对象，给它设置了 REMOTE_SERVER_ROOT 属性后，引擎下载资源的逻辑就变成：
1、检查资源是否在小游戏包内
2、不存在则查询本地缓存资源
3、如果没有缓存就从远程服务器下载
4、下载后保存到小游戏应用缓存内供再次访问时使用
同时，当开启引擎的 md5Cache 功能后，文件的 url 会随着文件内容的改变而改变，这样当游戏发布新版本后，旧版本的资源在缓存中就自然失效了，只能从服务器请求新的资源，也就达到了版本控制的效果。
具体来说，开发者需要做的是：
1、构建时，勾选 md5Cache 功能。
2、将小游戏发布包中的 res 文件夹完整得上传到服务器。
3、删除发布包内的 res 文件夹。
4、在 main.js 中，找到对应代码段并添加 REMOTE_SERVER_ROOT 的设置
5、对于测试阶段来说，可能你无法部署到正式服务器上，需要用本地服务器来测试，那么请在微信开发者工具中打开详情页面，勾选项目设置中的 不检验安全域名、TLS 版本以及 HTTPS 证书 选项。
除了纯游戏内容以外，其实微信小游戏环境还提供了非常强大的原生 SDK 接口，其中最重要的就是用户、社交、支付等，这些接口都是仅存在于微信小游戏环境中的，等同于其他平台的第三方 SDK 接口。这类 SDK 接口的移植工作在现阶段还是需要开发者自己处理。下面列举一些微信小游戏所提供的强大 SDK 能力：
1、用户接口：登陆，授权，用户信息等
2、微信支付
3、转发以及获得转发信息
4、文件上传下载
5、媒体：图片、录音、相机等
6、其他：位置、设备信息、扫码、NFC、等等