Cocos 引擎真正的优势是什么？
前言
Cocos 引擎真正的优势是什么？
为了让这篇文章更多表达自己的真实想法，我先声明：本文内容仅为麒麟子个人观点，与 Cocos 引擎品牌宣传无关。
很多人都疑惑，为什么麒麟子对 Cocos 引擎的情感那么深厚，就像自家的东西一样。
非要总结个答案的话，就三个词吧：认同、感激和梦想的延续。
-
认同：是因为我认同 Cocos 引擎开放、利他、长期主义的经营理念 -
感激：是因为 Cocos Creator 让我完成了人生的第一次蜕变 -
梦想的延续：是因为，想继续在引擎领域深耕，Cocos 无疑是我最好的选择。
我和 Cocos 的往事
每一个选择的背后，都有它的合理性。请允许我一一道来。
入行
麒麟子是 2006 年进入大学之后才开始学习编程的，2008 年的时候在学校图书馆找到了《DirectX 9.0 3D游戏开发编程基础》和《计算机图形学》，才正式开启了自己的 3D 游戏开发之旅。
2009 年就在学校待不住了，大三暑假跑到成都，辗转反侧找到了第一份 3D 游戏引擎开发的工作。
后面陆续参与了 4 款 3D 引擎的维护和项目引擎技术支撑。
转折
2016年，是我编程生涯的第十年。
当时我心中有一个念想越来越强烈：总是这样反复造轮子到底有何意义？为什么不把自己对引擎的理解放入同一款引擎中，延续下去？
就在这时，我看到了刚发布的 Cocos Creator，其组件化、跨原生和 Web 平台、开源、免费、可视化编辑等特性吸引了我，和我想要的引擎简直一模一样。
在试玩一番之后，我觉得它就是 全村的希望，我写了一篇吹捧 Cocos Creator 的贴子，由此认识了 Cocos 引擎的创始人王哲。
2016 年 6 月，我因为某些原因，离开了任职的公司，在和王哲聊完后，王哲问我是否愿意加入 Cocos 团队，参与 Cocos Creator 引擎 3D 渲染部分的研发。
这与我当时的个人规划不同，我当时是准备要创业的，所以我说：哲哥，我想创业，先让我自己试试吧。
创业
结合我个人在游戏技术和团队管理方面的多年经验，再加上技术类文章编写方面的一些优势，我选择了大多数技术人员都会选择的创业方向：为创业者们做技术服务。
在经过一番调查后，我发现大部分人面临两个问题：
-
小团队很难凑齐专业的服务器程序员和客户端程序员，主要原因是因为前后端编程语言不统一。
-
App 上架和分发是最头疼的事情，很多团队在创业起步阶段，更希望能够 “借量”，通过社群转化。
于是我将整个技术框架基于 NodeJS + Cocos Creator 搭建，并做了三个重点宣传。
-
前后端统一编程语言，开发维护更方便 -
基于 Cocos 引擎，包体更小、性能更好、功耗更低 -
可发布App，H5，轻松触达更多用户。（当时还没有小游戏）
没想到，这个框架一出道就受到了广泛认可。
从最初的项目外包服务，发展到了最后的：解决方案销售+项目定制+运维托管。
后来我问客户，为什么会选择我们公司的技术方案。
得到的答案是：NodeJS + Cocos Creator可以让前后端开发人员一体化，减少沟通成本。同时，Cocos Creator 的 H5 发布能力，让他们相比老牌竞争对手，也有一战之力，有一定的想象空间。
的确，从 2016 年 H5 技术的兴起，再到后来微信小游戏的截胡，这一条技术路线持续上涨。
总的来说，小游戏本质上还是 H5 的即点即玩逻辑，只是为了对游戏内容进行监管而诞生了小游戏架构。
在经营公司的 4 年里，我也抽空写了许多 Cocos 技术文章，开源了公司的第一个版本框架源码，出席过 Cocos 沙龙，赞助过 Cocos 活动。
PS：旧图找不到了，这些都是加入Cocos后拍的照
因为除了对 Cocos 的认可，我也从 Cocos 获得了许多，也得到了王哲、林顺、Jare 等大佬的帮助（Panda 有没有在幕后帮助过我，我不知道，因为加入 Cocos 之前，没有和 Panda 直接交流过。我觉得应该有吧，哈哈）。
只是，受我个人当时浅薄的商业认知的限制，我无法构建出可持续发展的盈利模式，公司发展最好的时候也不到 20 人。并且，受市场需求减弱和同行竞争的影响，毛利在逐年下降。
于是我开始努力学习如何去经营一家公司，当我懂得了经营公司和管理技术部门的区别时，我已经救不回公司了。在 2020 年，我关闭了公司，4 年的创业生涯告一段落。
我并不认为我的第一次创业是失败的，毕竟它存续时间是中国企业平均寿命的 1.6 倍。相反，它让我成长了许多，如果时间可以再来一次，我相信我可以做得更好。
加入 Cocos
2020 年 9 月，我问王哲：现在我还有机会加入 Cocos 吗？
他说：可以啊，但是工资只有五千，干不干？
后面的事情，大家都知道咯，团队陆续加入了不少优秀的同事，有一些是默默奉献的，大家不太熟悉，比如负责文档、教程、DEMO的。而有一些是刷脸的，比如 晓衡、杜斌、江船长、玉免、孙二喵等等。
不知不觉，在 Cocos 这个大家庭已经近三年，每一天都很开心。
关于麒麟子和 Cocos 的往事，就暂时讲到这里，我们接下来看看，在 Cocos 做生态的这两年半里，我们团队收集到的一些来自开发者的心声。
开发者的心声
有好多朋友问过我一个问题：“麒麟子，你天天在社区欢天喜地地收集引擎 BUG，是自己写的 BUG 不够改吗？”
这里告诉大家一个小妙招：如果一个人乐此不疲地收集引擎的 BUG 长达数年之久，表示这个引擎的代码，他一行都没写过。
麒麟子的个人介绍中，确实有提到过，参与过多款引擎的研发，但这并不包括 Cocos。
加入 Cocos 后，麒麟子负责的是引擎生态相关工作。我和大家一样，是以开发者的身份去使用引擎，只是我在新版本早期就会开始使用，尽早发现一些需求偏差和细节问题。平时也会根据需要写代码，但并不为引擎而写，而是为开发者们而写。
接下来，我们一起看看，我从一些热心开发者那里收集到的，他们为什么选择了 Cocos Creator。
某些做 H5 和小游戏的开发者说：Cocos Creator 可以一键发布到主流平台，非常方便。如果换用其他引擎，根本做不到。
某些来自 Web 前端领域的开发者说：采用 TypeScript 编程语言，让我们 JS 党可以不用额外学习编程知识，就能圆了自己做游戏的梦。并且这个东西不仅能做游戏，还能做网页中的多媒体，比直接使用 WebGL 方便太多了。
某位 MMORPG 网络游戏项目的开发者说：当你要测试一个多人联机功能的时候，你就知道 Cocos Creator 有多方便了。这边把代码一改，保存，刷新，同事们的机器上马上就可以使用新版本了。如果某台机器上出了问题，马上就可以去浏览器的开发者工具里看错误堆栈，前期的功能开发效率简直逆天。
某些发行渠道说：App 端的优势就是留存高，但最大的不好就是新用户成本太贵了。H5 和小游戏则刚好相反。所以我们打通了一个方法，用 Cocos Creator 做项目发布到 iOS 和 Android，然后优化一套低配版，发布到 H5 和小游戏平台。借助小游戏平台的流量成本优势，快速获得用户，再将优质用户引导到 App 上。
某创业团队负责人说：其实没得选，只有上更多的平台，才能有更多的机会。国内就小游戏，出海就走 App。Facebook 也在研究，Tiktok 和 Youtube 小游戏也在等机会，希望能够把国内做得不错的产品在这些海外平台上也能再火一把。
某数字营销领域的开发者说：Flash 停更后，我们便逐渐转向使用 WebGL 来做高级效果的呈现。但直接使用 WebGL 对于大部分前端开发团队来说要求还是太高了，即使他们能学会使用 WebGL API，也很难构建出不错的渲染效果和达到性能要求。Cocos Creator 很好地填补了这个空白。
可以看到，来自不同领域，不同项目，不同身份的从业者，他们的观点主要集中在了三个方面：
-
学习成本 -
开发效率 -
平台覆盖
可以说，这是来自用户侧的真实写照。引擎官方在宣传中经常提到的：开源、免费、渲染效果、物理特性、内存开销、运行性能、加载速度、稳定性、兼容性等重要指标，他们根本不提。
不提这些，并不是他们不在意。恰好相反，他们认为，这些是引擎默认就应该做好的。做得不好会吐槽，做得好是应该的，不会夸。
SLOGAN
在继续讲后面的内容之前，我们来重温一下 Cocos 引擎的 SLOGAN。
从最初的 “让游戏开发更简单” 到 “以技术驱动数字内容行业效率提升”。可以看出，Cocos 始终是初心未改，希望在生产效率上让开发者们事半功倍。
由于游戏技术的泛化应用，特别是3D游戏技术在App和Web端的普及，使得游戏技术从游戏行业延伸到了诸多工业和商业领域。这也是为什么 SLOGAN 中，将 “游戏” 换成了 “数字内容行业”。
而 “效率提升” 相较于 “更简单”，则更加具体指出了 Cocos 引擎的定位。希望在开发效率和运行效率上为开发者带来帮助。
有人看到这个 SLOGAN 就说，Cocos 不专注游戏了？我觉得这是一个误会。Cocos 作为一个游戏引擎和图形引擎，它始终是以游戏技术作为底座来发展的。只是，游戏技术不仅可以服务游戏行业，它还可以服务电商、数字营销、车机等领域。
我们可以看一下 Cocos Creator 3.8 之后的架构图。
可以看出，行业之下，是完整的游戏引擎技术栈。
在行业扩宽方面，不仅是 Cocos 引擎，其他引擎也都在努力扩宽应用的边界。因为这不仅可以为引擎带来更多机会，也能给使用这个引擎的开发者们，生态中的合作商们带来更多机会。
我眼中 Cocos 的优势
好吧，做了这么长的铺垫，终于要说我自己的想法了。
从开发者角度来说，特别是中小团队来说，在产品开发层面，关注的是成本，在产品盈利方面，关注的是机会。
成本由生产效率决定，Cocos 的可视化编辑器，PBR 渲染标准，多平台发布等，都是想最大化提升生产效率，降低开发者的生产成本。
那机会是什么呢？机会就是流量，流量的很大一个因素就是用户覆盖率。
而为了达到更好的用户覆盖率，我们需要产品在技术层面达到要求。
比如，兼容更多的低配置机型，适配更多的平台，支撑更多的行业。总结下来就是：
-
机型覆盖率 -
平台覆盖率 -
行业覆盖率
机型覆盖率
要做到低端机型的覆盖，就必须在性能和功耗方面做到极致，关键时候，还需要针对需求进行引擎裁剪。引擎的模块裁剪，自定义管线，开放的引擎源代码，让这样的需求畅通无阻，无后顾之忧。
平台覆盖率
平台主要是三大类， 原生平台、Web 平台、小游戏平台。
而从流量上讲，Web和小游戏平台有很大的机会，微信、抖音、Facebook、Tiktok、Youtube 等超级 App，更热衷于将流量内部变现，而不再是跳出的方式。原生平台和非原生平台于用户而言，在当下都非常重要。
从架构来说， 原生平台为了极致的性能，必须尽可能使用 C++ 进行底层编写，而 Web 平台和小游戏平台，为了包体和性能的平衡，则必须使用 JS 进行编写。
因此 Cocos 引擎团队实现了双内核架构，用最直接的方式，有效地解决了各类平台的差异，确保在原生和非原生平台都能获得很好的运行效果。
行业覆盖率
很多人一提行业覆盖率，首先想到的就是引擎应该提供针对行业的工具。
这确实是一个方面，Cocos 经过几年的努力，也在车机、虚拟人、XR、数字营销等领域有了较大进展。
但回归到本质，比如车机、数字营销，它本身只是游戏技术在不同平台的应用。
车机要求的是极致的原生性能，满足高清渲染画质的同时，需要更低的内存、CPU、GPU开销，响应速度快。
数字营销，本质上追求的是在App内实现丰富多彩的画面效果，由于它是一个App的附加效果，它要求此类应用性能开销少、内存占用低、加载速度快。
最终你会发现，几个领域追求的点都集中在了下面几条：
-
渲染画质 -
内存占用低，CPU&GPU 开销少 -
响应速度快
而在这几条， Cocos 都能很好地满足。
-
在原生和非原生平台上，实现同样的渲染效果，Cocos都能做到较低的内存占用和较少的CPU,GPU开销。 -
同时，引擎的自定义管线和开放源代码，又让一些技术较强的团队，用技术优势拉开与其他团队的差距，形成竞争力。
总结
最终再总结下就是：
-
生产端：可视化编辑，标准化一站式工作流，一次开发多平台发布。 -
运行端：同样的画质下高性能、低功耗；自由可控，极致优化。
或许这个结论有些人不会认同，但从用户角度而言，我认为这是他们大部分人选择 Cocos 的原因。
各位准备好了吗，我要出来收 BUG 了。
关注、在看、转发
文章中的 PPT 截图，来自昨天参加的白鲸技术栈*技术创新与全球市场，有需要朋友可以公众号主页面发送 20230722，既可获得对应的 PDF。
往期精彩