本文作者 ：Shopee Games 前端团队。

摘要

Shopee Games 团队致力于丰盛 Shopee 电商内的互动性和娱乐性，让用户在购物之余取得更多愉悦感，同时游戏也能为 Shopee 带来继续的沉闷用户和更多的优惠券发放渠道。在这个背景下，从游戏诞生之初，咱们心愿游戏足够轻量，而且可能疾速迭代，继续给用户提供多种多样的游戏体验，同时又不会对 Shopee App 的体积造成较大影响。因而，咱们须要抉择适合的游戏引擎，并打造适宜 Shopee Games 的工具链。

本文将介绍 Shopee Games 团队如何抉择游戏引擎，如何扩大游戏引擎以进步生产效率，如何让游戏开发流程和成熟的前端工程化体系联合，实现游戏规范化和研发品质的晋升。Shopee Games 是内嵌在 Shopee App 的游戏，所以对于有同样内嵌游戏需要的业务团队，本文总结的教训会有肯定借鉴意义。

1. 游戏引擎选型

Shopee Games 以后以休闲类游戏为主，为了缩小对 Shopee App 体积的影响，技术选型上会偏差于 H5 游戏。而如何抉择 H5 游戏引擎，咱们次要考量以下几个方面的因素：

• 2D 还是 3D 游戏？
• 是否对开发敌对？包含是否反对 TypeScript、文档是否欠缺、研发流程是否适宜以开发为主导。
• 性能和兼容性如何？
• 官网工具链是否欠缺？
• 是否开源？
• 是否有胜利的游戏案例？
• 官网是否有客服反对？
• 官网是否有继续更新？

首先，咱们的休闲类游戏次要为 2D 游戏，所以咱们先聚焦在针对 2D 设计的游戏引擎上。尽管 3D 引擎能够通过正交视角来实现 2D 成果，但渲染性能和轻量化都不如专门的 2D 引擎，所以咱们先把 3D 为主的引擎排除掉，例如 Unity3D、LayaBox、Three.js、Babylon.js。而 2D 引擎，国内次要有老一些的 lufylegend.js、Cocos2d-JS 和继续更新的 Egret、Cocos Creator，国外有 Phaser/Pixi 和 CreateJS。

接着，从可持续性、性能方面思考，能够先把较老的 lufylegend.js、Cocos2d-JS 排除。而 CreateJS 理论并不是一个残缺的游戏引擎，它更靠近于一个精简的渲染引擎，短少整体的工具配套，难以反对大型游戏，也排除。

那么，最初咱们重点比照 Egret、Cocos Creator 和 Phaser。Phaser 的渲染引擎就是 Pixi，后续用 Phaser 代表这两者。

以上三款游戏引擎都反对 TypeScript 和 WebGL，性能差别不大。对于 Shopee Games 团队而言，Egret 有较大劣势：

• Egret 反对 canvas 模式，因而东南亚市场中的一些低端手机用户也可能运行咱们的游戏；
• Egret 的理念是面向开发者的，而咱们团队有较强的研发能力，以开发者为导向可能让整个游戏性能更好；
• 在工具链上，Egret 有自研的龙骨动画和编辑器，非常适合咱们的游戏开发。

因而，综上所述，咱们抉择 Egret 作为支流引擎，并在 Egret 的生态根底上，继续优化和打造可能进步游戏开发效率的工具链。

2. Egret 引擎优化和公共库

2.1 Egret 引擎优化

Egret Engine 是白鹭时代研发的遵循 HTML5 规范的开源游戏引擎，蕴含 2D/3D 渲染外围、EUI 体系、音频治理、资源管理等游戏引擎的罕用模块。

目前咱们应用 Egret Engine 开发了 Shopee Candy、Shopee Pet、Shopee Fruit、Shopee Link 这四款游戏，在我的项目开发和迭代过程中，咱们发现官网引擎存在一些问题，无奈齐全满足业务需要和性能规范。于是，咱们对 Egret 引擎做了定制开发，下文称之为“定制化引擎”。

2.1.1 性能上报

针对游戏的一些数据指标，如 FPS、DrawCall、First Paint、GPU Size 等等性能指标进行上报。

上报流程如下：

通过剖析上报的游戏性能数据，咱们能更好地剖析性能瓶颈，从而有偏重性地晋升游戏性能。其中，波及到的具体性能指标如下：

2.1.2 性能优化

咱们在官网引擎根底上针对性能做了一些优化，帮忙开发人员晋升游戏性能。

动态合图

在开发过程中将散图合成一张大图的图集，达到升高 DrawCall 的目标。

动静合图

在我的项目运行时，动静地将贴图合并到一张大贴图中。当渲染一张贴图的时候，动静合图零碎会自动检测这张贴图是否曾经被合并到了图集（图片汇合）中。如果没有，并且此贴图合乎动静合图的条件，就会将此贴图合并到图集中。

动静合图是依照渲染程序来选取要将哪些贴图合并到一张大图中的，这样就能确保相邻的 DrawCall 能合并为一个 DrawCall。

和后面的动态合图原理一样，都是以合图纹理代替碎图纹理，从而缩小 DrawCall。而动静合图最大益处是进步了一些无奈提前动态合图的场景，例如用户的打扮。

节点程序调整

引擎底层的性能优化，目标是保障雷同纹理的渲染程序。例如在同级 addChild 时，如果原始程序为 img1>text>img1，引擎能主动优化成 img1>img1>text，升高 DrawCall。

DrawCall 优化工具开启

游戏 Main 函数开启 Benchmark.init(null,null,true)；或者 Benchmark.optimizeDc 设为 true 即可。

2.1.3 引擎瘦身

官网引擎默认蕴含所有模块，其中有一些在咱们的理论我的项目中应用不到。因而，为了缩小引擎包体积大小，须要剔除掉用不到的代码，例如：

• Native 代码；
• Runtime 代码；
• WX 等小游戏端兼容代码；
• KTX 纹理相干代码；
• ETC Loader 代码。

批改前后比照：

最终，游戏前端 JS 加载量共缩小 16KB，约 7%。尽管这个体积看起来很小，但对于局部网络较差的地区，大量的体积优化也是有价值的。

2.1.4 Bug 修复

对于我的项目遇到的一些引擎层面的 bug，因为引擎官网可能会更新修复不及时，很多时候须要咱们本人去修复。例如：iOS 14/15 渲染卡顿问题、龙骨库渲染问题、网络以及音效问题等等。其中，咱们解决 iOS 14/15 卡顿问题后，很荣幸奉献了代码帮忙 Egret 官网团队解决这个问题。

2.1.5 API 加强

官网引擎的一些用法过于繁琐，不够敌对，如设置节点宽低等。因而咱们在官网引擎根底上，扩大了方便快捷的 API，供大家应用。

2.2 公共库

为了进步开发效率，防止大家反复造轮子，基于优化后的 Egret 引擎，咱们做了公共库的开发，封装通用工具类、通用模块、通用 UI 组件等等。

2.2.1 工具库

咱们封装游戏中罕用的一些工具库：

• SoundUtil：音乐播放工具类，反对音效 / 背景音乐的播放 / 暂停 / 倍数播放等；
• DragonUtil：龙骨工具类，负责龙骨动画的创立 / 销毁等，暗藏龙骨创立细节，简化龙骨动画应用难度；
• ResUtil：游戏资源管理类，不便开发者加载 / 开释游戏资源；
• SmartEvent：封装的音讯告诉类库，不便大家应用，便于模块之间的解耦，蕴含自定义事件 /UI 事件的监听和移除；

封装工具库是为了升高开发难度，以及防止不同团队反复造轮子。目前已在 Shopee Games 的四款 Egret 游戏中应用，均匀节约人力 2 周以上。

2.2.2 根底 UI 组件

咱们对 Egret 根底组件进行了扩大，并提供了生命周期等一系列钩子函数，升高开发难度，晋升开发效率；同时，提供了一些各我的项目通用的组件，如：分享界面 / 好友界面 / 小怪兽弹窗等公共 UI 组件。

Egret 根底组件扩大

咱们为 UI 组件提供了一些生命周期的钩子函数不便游戏业务应用，开发者实现每个 UI 类时不用再独自实现事件监听和移除。同时，内置的事件治理也防止了开发者可能因开发脱漏而导致的内存透露问题。

具体的钩子函数如下：

2.3 定制化引擎同步更新

随着定制化引擎的批改越来越多，随之而来的问题是：如果官网引擎更新了，咱们怎么疾速合并官网引擎版本？

这里采纳的计划是 git 双 remote 的计划，流程图如下：

具体步骤如下：

• 为了示意不便，咱们把 Egret 引擎开源库定义为 A，咱们本人的定制化引擎仓库为 B；
• 通过 git clone B，拉取批改我的项目 B；
• 通过 git remote add A repository，以及 git fetch A，减少 A 近程并获取 A 的仓库信息；
• 假如 B 的开发分支是 dev，切换到此分支；
  假如咱们须要合并的是 A 的一个 tag，如 v5.4.0，应用 git merge v5.4.0 --allow-unrelated-histories，强制合并。

因为须要同步源框架我的项目代码，咱们的改变会受到一些限度，否则每次合并都会有反复的工作量：

• 尽量不要重命名或者删除本来的文件，或者改变代码外面的函数及变量名；
• 如果须要拓展一个类的性能，尽量采纳原型链拓展的模式；
• 自定义外部工具类能够外部自行定义，只有不重名即可；
• 行内代码尽量采纳减少的模式，尽量不改变本来的代码；
• 有些库代码会减少很多渠道兼容的代码，咱们能够适当缩小，合并时会基于从独特先人剖析扭转的机制，因而不会每次都要 diff。

通过以上计划，咱们就能够实现官网仓库和定制化引擎的疾速同步。

3. 游戏研发工程化

尽管 Egret 引擎能满足 Shopee Games 的根本业务需要，官网也提供了一系列工具来满足开发者的开发需要。但在应用 Egret 引擎的过程中，咱们还是遇到了以下一些痛点：

• 不足模块概念 ：采纳默认的 TypeScript 形式编译，不反对文件顶层 import 和 export，所有编译文件内容被视为全局可见，容易造成变量净化以及平安问题；
• 无奈应用 npm：业务我的项目根目录下不反对 package.json 文件，不反对模块化的第三方库；
• 不足工程化计划 ：没有提供工程化的相干计划，如代码审查、单元测试等，我的项目也无奈轻易接入惯例的 Web 前端工程化计划；
• 部署流程简单 ：代码编译工具依赖于官网工具，没有提供命令行版本，无奈在服务器上独自部署。

显然 Egret 工程无奈满足咱们的工程需要。即使当初的 Web 前端工程化技术非常成熟，咱们仍处于石器化时代，因而决定把 Egret 工程前端工程化。

3.1 Egret 前端工程化

3.1.1 反对根目录 package.json

package.json 文件能够说是目前前端我的项目必备的一个文件，Egret 引擎起家比拟早，过后的前端工程化还没有那么成熟，Egret 引擎的构建是官网本人写的一套构建零碎。

不反对根目录下 package.json 文件，很多事件也很难执行上来，还好 Egret 引擎的构建工具代码也是通过 JS 编写，而且跟引擎代码一样开源。

通过源码断点调试，咱们发现 Egret 我的项目不反对根目录下 package.json 的起因是：Egret 构建的时候，通过判断根目录下是否存在 package.json 来辨别工程项目和库我的项目，从而应用不同的构建流程，构建出不同的产物。

为了做到最小化的改变，且也能反对工程项目根目录下存在 package.json，咱们把构建我的项目的判断批改为判断 package.json 内自定义字段的值，来辨别是否为工程项目。

反对根目录下存在 package.json，后续的一些工程化革新就比拟容易进行上来了。

3.1.2 引擎 npm 包

官网构建依赖于本地机器上的构建工具，每次的部署公布，都须要在本地构建实现后再上传到服务器上，与 Shopee 业务的部署标准和流程不太相符，并且重大妨碍了我的项目疾速迭代的节奏。

为了使构建可能反对在服务器上独自部署，咱们把定制化引擎的代码进行革新和封装，公布成一个 npm 包的模式，我的项目依赖从一个本地的构建工具变成 npm 包。

  "dependencies": {"@egret-engine/egret-core": "1.6.2-alpha.1",}

npm 包次要蕴含两局部：

• build 目录：引擎相干的库文件；
• tools 目录：构建编译相干工具。

公布成 npm 不仅使得我的项目的编译运行脱离本地环境，也能更好地去做我的项目的版本治理。然而仅公布成 npm 包是不够的，还须要联合以下的 Webpack 打包构建能力达到咱们的目标。

3.1.3 Webpack 打包构建

为了反对模块化编译以及在服务器上独自部署，咱们抉择了成熟的 Webpack 构建计划接入到 Egret 我的项目中。

革新 Egret 我的项目构建前，首先须要剖析一下 Egret 我的项目的依赖以及构建产物：

• *.js：代码构建产物。
• *.ts：TypeScript 业务代码文件。
• res：我的项目资源文件。例如：图片、音频、JSON 文件等。
• egret libs：Egret 我的项目依赖模块，即相干的 JS 库文件。
• *.exml：Egret 特有的标签语言文件类型，用作 UI 布局，可编译成 JS 文件和 JSON 文件。

官网的构建相似于 gulp，依照肯定的程序执行每个工作。尽管官网也提供了自定义工作插件的形式，让开发者自定义构建流程，但这都须要开发者从新去开发，比拟消耗人力。

exml 文件类型是 Egret 引擎特有的文件类型，目前前端生态没有相干的解析编译工具；res 文件解决也没有必要从新造轮子，所以咱们沿用官网的工具，封装到 @egret-egine/egret-core/tools 上，作为构建工具的一个依赖。

而 egret libs 依赖解决和 *.ts 代码编译，咱们都能在前端生态上找到更好的计划，依据需要应用即可。

通过 Webpack 去打包 Egret 我的项目，构建依赖来源于 npm，这样就能够脱离本地环境，间接在服务器上部署构建。而且产物也跟官网打包产物保持一致，做到良好兼容。

3.1.4 工程化配置

通过以上革新，其实 Egret 工程项目跟一般的 Web 前端工程没有太大区别，成熟的 Web 前端工程化计划在咱们的我的项目中能失去很好的实际，不仅可能实现在服务器上独自部署，也能轻松接入品质把控的工具，例如 eslint、jest 等，进步代码品质。

3.2 Egret-Webpack-CLI 实现

在我的项目初期，咱们次要依据业务和工程需要，基于 Egret 和 Webpack 搭建了我的项目脚手架模版。但在创立新我的项目和创立 demo 我的项目的时候，仍须要从仓库 clone 模版仓库下来，并且依据我的项目进行肯定的人工配置。在目前的应用上看，问题不大，但依然比拟繁琐，也有可能会脱漏一些配置，新建我的项目不能做到开箱即用。因而开发脚手架工具，可能疾速生成对应的模版我的项目。

3.2.1 CLI

个别脚手架工具次要分为 CLI 和 Template 两局部。脚手架模版内容并没有与 CLI 一起放到同一个仓库，而是别离放到不同的仓库进行治理和迭代。通过拆散，能够确保两局部独立保护，不会相互烦扰；模版配置或依赖更新只须要更新我的项目模版即可，无需影响 CLI 局部，导致从新发包。

参考其余脚手架的思路，模版作为独立资源公布到近程仓库上，而后运行的时候通过 CLI 工具下载下来，通过 CLI 的交互信息，作为交互的输出元信息渲染我的项目模版。

终端执行 egret-cli 后，即可依据交互信息，生成对应的 Egret 工程项目。

3.2.2 Template

因为咱们须要对应不同的需要，且业务相干的配置较多，导致模版业务配置差别比拟大，暂不能齐全做到一个对立的模版。同时，为了保障一个模版内没有冗余的配置，咱们做了辨别，次要提供了 base、standard、Shopee、native 四种我的项目模版。

须要做小 demo 的时候，能够间接应用 base 模版，比拟简洁；如果须要钻研跟业务无关的性能，能够抉择 Shopee 模版；如果是新我的项目的成立，则间接应用 native 模版。

3.3 最终 Egret 游戏开发流程

Egret 我的项目与惯例 Web 前端工程接轨，既解决了开发痛点，满足了工程需要，也让咱们从石器时代正式步入工业时代，从开发到部署都有很好的工具去辅助执行，进步了代码品质和开发效率，新来的同学也能很好地上手我的项目。

成熟的 Web 前端工程不仅有利于咱们的业务扩大，也赋予了我的项目更多的可能性。一些在前端很容易实现而在原来游戏引擎比拟难实现的性能，例如动静逻辑代码加载、多页利用、Egret+React 混合页面等，在咱们的我的项目中也失去了很好的实际。

4. 更多研发问题

4.1 iOS 审核问题背景

在 Shopee Games 推出晚期，用户量和访问量都不大，苹果公司没有着重针对 HTML5 版本的 Shopee Games 提出意见。然而，随着 Shopee 业务一直倒退，用户量和访问量继续减少，2021 年初，苹果公司对 Shopee 内嵌的 HTML5 游戏提出了意见，认为 Shopee App 违反了《App Store Review Guidelines》的 4.7 条款。

苹果公司的审查条款原文是这样的：

4.7.1 Software offered under this rule must:
- be free or purchased using in-app purchase;
- only use capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); and use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software;
- be offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement;
- not provide access to real money gaming, lotteries, or charitable donations;
- adhere to the terms of these App Store Review Guidelines (e.g. do not include objectionable content); and
- not offer digital goods or services for sale.

归纳起来，蕴含以下几点要求：

• 全免费的 H5 游戏或应用苹果领取；
• 仅应用 WebKit 自带性能，不容许扩大，例如 JSBridge；
• H5 开发者须要退出苹果开发者打算；
• 不容许涉足金钱赌博，而且内容要合乎其余审查条款个别限定。

而 Shopee Games 内嵌在 Shopee App 内，天生须要和 Shopee 深度联合，必然波及 JSBridge（例如登录、跳转电商店铺）。并且，Shopee Games 还应用了 Shopee Coins 作为游戏中的货币，而 Shopee Coins 并不是通过苹果领取失去的，是用户在电商购物中累积获取的。从这两个角度来看，Shopee Games 应用 HTML5 技术必然触犯以上的苹果审查条款。

咱们参考了 Egret 引擎官网的倡议，扭转了 iOS 平台上 Shopee Games 的技术架构，从原来的 HTML5 改为了 Native，应用的是 Egret Native Runtime。Egret 官网工具反对一键生成 iOS 工程并公布对应的 App 安装包，这可能满足独立游戏的需要。然而 Shopee Games 须要内嵌在 Shopee App 中，并不是独立的游戏 App，所以无奈间接简略应用官网的一键公布机制，咱们须要进一步钻研 Egret Native 的原理，从而和 Shopee App 做整合。

4.2 Egret Native 原理

剖析 Egret Native 工具创立的 iOS 模板工程，能够发现：

• Egret Native Runtime 依赖一系列的零碎库和独立封装的 libEgretNativeIOS.a，次要外围逻辑和网络性能都在这个库中。因为 Egret Native 并不开源，从模板工程无奈得悉这里的具体实现；
  
• 固定以 App 根目录的 assets 文件夹作为资源目录，H5 版本的生成文件须要固定存在此处，而且这里只反对一个游戏；
• 通过 libEgretNativeIOS 库，能够创立相应的 EgretNativeIOS 实例和对应的 view。

尽管 Egret Native 并不开源，但依据官网文档，再联合模拟器断点调试剖析，还是能够对 Egret Native 有进一步的发现。

Egret Native 游戏架构包含三层：前端游戏层、Egret Native Runtime 和 iOS Native 层。

• 前端游戏层放弃和 H5 版本的文件内容统一；
• Egret Native Runtime 是外围的适配层，它应用 JSCore 对游戏包内的 JS 文件进行解析，搭建 JSBridge 实现 JS 和 Native 两侧的通信。运行时渲染的形式和 Web 有所区别，Egret Native 有一个针对 Native 的 JS Polyfill 和 JS Engine 补充，并不是在 Runtime 层实现了全副浏览器性能；
• iOS Native 层，次要是治理 Egret Native Runtime 生命周期和治理视图。

启动 Egret Native 游戏时，先从 iOS Native 层初始化 Egret Native 实例，并创立对应的游戏 view，挂载到主界面上。而后，Egret Native 初始化 JS 引擎，绑定 JSBridge，读取前端游戏层的游戏资源，解析 HTML 和 JS，调用 OpenGL 接口，最终显示游戏画面。

4.3 Egret Native 和 Shopee App 联合

从模板工程来看，把 Egret Native 游戏内嵌到 Shopee App 的形式是比拟清晰的，把 libEgretNativeIOS.a 和其余必要的依赖库增加到 Shopee App 我的项目工程中，再把游戏包寄存到 assets 目录中，最初绑定必须的 Shopee JSBridge，供游戏逻辑实现登录、领取、跳转等操作，整个联合工作就残缺了。

然而，在最终实现过程中，发现一些深层次问题，须要通过业务侧的形式解决或躲避。这些问题包含：

1）模板工程不反对多个游戏

Shopee Games 蕴含多个游戏，而上述 assets 目录只反对寄存一个游戏的资源。并且 Egret Native Runtime，也就是上述的 libEgretNativeIOS.a 没有开源，无奈做针对性的批改。

最初，咱们在官网的《热更新计划阐明》中，发现了 Egret Native 能够设置 preload 目录门路，而 preload 目录内的资源优先级比 assets 目录高。

于是，咱们能够在 Shopee App 内置多个游戏，别离寄存于一个独自的目录中，在启动 Egret Native 前设置 preload 门路为对应游戏的门路。Egret Native 启动后会优先读取 preload 目录的资源来启动游戏，疏忽后续 assets 的内容。

2）网络缓存文件有限增大

Egret Native Runtime 对网络申请做了缓存，但没有欠缺的清理机制，导致本地缓存目录会随着游戏下载的资源增多而有限增大。这部分须要在 Shopee App iOS Native 逻辑层面进行补齐。

3）局部第三方库命名抵触

libEgretNativeIOS.a 自带了一些第三方库，例如 SocketRocket，而 Shopee App 也引入了这个库，单方都没有对这个库做别名解决，导致命名抵触编译失败。因为 libEgretNativeIOS.a 无奈批改，只能在 Shopee App 业务层面自行批改 SocketRocket。

4）Egret Native 存在内存透露

因为在 Shopee App 中，Egret Native Runtime 须要重复启动和销毁，只有 Egret Native Runtime 对对象、纹理解决稍有不当，都会引起内存透露。而对于 Egret Native 独立游戏来说，这个问题就不存在，因为每次敞开游戏都是整个 App 的销毁。这个问题曾经反馈给 Egret 官网，但因为官网团队不会专门针对咱们的应用场景做解决，所以目前暂无停顿。庆幸的是，这部分内存透露很小，临时不形成大的问题。

通过解决上述一系列问题，最终咱们实现了 Egret Native 和 Shopee App 的联合，可能在 Shopee App 上运行多款自研游戏。在苹果审核的角度，咱们这个形式脱离了 Webkit，而且所有代码逻辑内置在提审的安装包中，完全符合审查条款的要求。因而，计划上线后，Shopee App 和 Shopee Games 顺利通过了 App Store 的审核。

4.4 将来布局

尽管 Egret Native 曾经可能联合在 Shopee App 中，但在继续经营半年后，咱们发现 Egret Native 还是存在一些问题：

• Runtime 不开源，存在无奈解决的问题；
• Runtime 只反对 Egret 游戏，无奈反对其余游戏引擎。尤其是，Egret 引擎对 3D 游戏开发来说，临时还不是最佳抉择。

于是，咱们正在策划更久远的解决方案——自研的 Native Runtime，可能同时反对多家 H5 游戏引擎。

这个解决方案采纳相似微信小游戏的整体架构，但在 JS 层面会做进一步的封装，不便 Shopee 内各个游戏团队疾速接入。技术层面概要来说，就是 Native 基于 JS 引擎向 JS 侧裸露对齐 WebGL 规范的接口和必要的 BOM 接口，从而一般 H5 游戏引擎就能够无缝运行在浏览器和咱们自研的 Runtime 上。

这个计划的益处有：

• 兼容性好，能同时反对多家游戏引擎；
• 不便存量 H5 游戏转移；
• 能利用各家引擎成熟的开发工具链。

然而，相应也存在劣势：

• iOS 12 之后的版本正逐渐放弃对 OpenGL 的反对；
• 因为兼容多家引擎，难以使用新的图形图像规范，例如 Metal、WebGL2、Vulkan。

目前 iOS 曾经迭代到 15，OpenGL 和 WebGL 还是可能安稳运行，而要反对多款 H5 游戏引擎，WebGL 规范是无奈绕过的，所以这些劣势临时不得不承受。另外，微信小游戏也会面临一样的问题，置信将来会有苹果官网的迁徙计划，可能在 Metal 下层封装类 OpenGL 的接口。

目前这套计划还在预研开发中，预计 2022 年内会实现并全面应用。之后不单是 Shopee Games，咱们心愿在更多的电商场景也能复用这套 3D/GPU 渲染的计划，给用户发明更丰富多彩的互动玩法。

4. 总结

通过在多款 H5 游戏引擎中做比拟，Shopee Games 抉择了更适宜业务特点和团队人才特点 Egret 引擎。

在长期的业务开发经营中，咱们为了更好地反对业务需要，对 Egret 引擎进行了定制化革新，包含 bug 修复和公共库的批改。

优化引擎的同时，为了和官网仓库放弃同步，咱们利用了 git 多 remote 仓库的个性，实现了双仓库代码合并。

再进一步，为了复用成熟的前端 Webpack 构建体系和 CI/CD 流程，咱们自研了 Egret-Webpack-CLI，把 Egret 游戏从原来单机本地打包的模式，改为了服务器 Webpack 打包，从而不便复用大量的优良前端 npm 库。上述这些翻新，都给 Shopee Games 的研发带来了重大提效。

在 iOS 审核问题上，咱们遇到了一些艰难，最终通过深度整合 Egret Native 和 Shopee App，顺利实现游戏的 Native 化，通过了 App Store 的审核。