背景

基于目前web加载Cocos游戏在低端机上流畅度等性能方面上的问题，决定尝试使用原生化渲染Cocos游戏来提高cocos游戏的性能，提升用户的游戏体验。

历程

确定Cocos的版本

开始是基于Cocos2.x版本去做的实现，但是在安卓端会有引擎资源回收的问题。后面基于Cocos3.x版本去做的实现。其中在选用3.x版本也遇到了一些问题。

由于3.x版本的Cocos引擎只提供了启动方法，没有销毁方法，也就是官方建议在一次app生命周期内，Cocos引擎只启动一次，所以对于游戏的切换我们交给前端的游戏大厅去切换。以下数据均为引擎只启动一次的数据（引擎只启动，不用销毁）

Cocos版本	3.2.0	3.5.2	3.6.1
表现	引擎内存泄漏	release模式下引擎占用的运行内存会稳定在201m	release模式下引擎占用的运行内存会稳定在102m

基于以上表现，最终我们决定使用Cocos3.6.1版本作为原生化的Cocos版本。

如何切换游戏

因为Cocos引擎只启动一次。而在Cocos启动的时候，引擎内部就已经去加载了游戏资源文件，因此加载游戏也只能加载一次。所以就面临一个问题：如何去切换加载的游戏，这里就引入游戏大厅概念

游戏大厅：也就是类似于一个指令响应池，一开始启动引擎加载的是游戏大厅。在大厅内部客户端和前端交互，告诉游戏大厅你要加载哪款游戏，游戏大厅收到指令，去加载对应的游戏。

也就是之前客户端控制加载哪款游戏，现在变成了客户端通知前端的游戏大厅去加载哪款游戏。

iOS编译Cocos引擎静态库

由于Cocos只提供了源代码给我们编译成.a的静态库，其中并不包含.h的头文件，因此我们需要将编译好的.a和头文件封装成一个组件给工程调用。在封装Cocos引擎库的时候也遇到一堆问题导致我们封装的组件无法再项目中使用。下面详细说下封装cocs引擎库的步骤：

首先把engine-native里面的Cocos、extensions和external放在classes里面作为需要保留的文件路径
把Cocos里面的.a库放在Libraries里面，然后同1一样作为需要保留的文件路径

spec.preserve_paths = [
      "libsCocos2d/Classes/engine-native/**/*",
      "libsCocos2d/Libraries/libs/**/*.{a}",
    ]

3. CocosAppDelegate放到pod编译报错，需要设置组件DEFINES_MODULE为NO

spec.pod_target_xcconfig = {'DEFINES_MODULE' => 'NO'}

4. Cocos引擎默认是使用当前window的rootviewcontroller和rootviewcontroller的view去做渲染和逻辑处理操作，因此我们需要修改源码，支持设置view和uiviewcontroller去解除这个限制

1.  因为引擎内部直接是取的UIApplication.sharedApplication.delegate.window\.rootViewController.view作为渲染view，因此直接在引擎内全局搜索.rootviewcontroller，去找出待会我们需要修改的地方

    ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/049afa23bc69429584a3157d6e67e1ca~tplv-k3u1fbpfcp-zoom-1.image#?w=3024\&h=1974\&s=1702721\&e=png\&a=1\&b=1f1f24)

2.  创建XXCocosContent类，让引擎外部对渲染view和当前的rootviewcontroller进行设置。

    ````
      #import <UIKit/UIKit.h>

      NS_ASSUME_NONNULL_BEGIN

      @interface XXCocosContent : NSObject

      @property(nonatomic, weak)UIView *renderView;
      @property (nonatomic, copy)UIViewController*(^gameVCBlock)(void);
      + (instancetype)shareInstance;

      @end

      NS_ASSUME_NONNULL_END
      ```

    ````

3.  将创建的XXCocosContent类拖进引擎内部，然后替换引擎内部获取的渲染view和当前的rootviewcontroller。

    ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/182015d756204bcb997c616959b65f68~tplv-k3u1fbpfcp-zoom-1.image#?w=1652\&h=642\&s=268532\&e=png\&b=292a2f)

    ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bd8b3f184a1049c8ab70d50fcb6ae4bc~tplv-k3u1fbpfcp-zoom-1.image#?w=1706\&h=712\&s=253766\&e=png\&b=2a2b30)

5. 添加Cocos依赖的系统库，否则会出现编译问题

spec.framework = 'CoreVideo', 'AudioToolbox', 'OpenGLES', 'CoreMotion', 'CoreText', 'CFNetwork', 'CoreFoundation', 'MobileCoreServices', 'GameController', 'WebKit', 'CoreMedia', 'AVKit', 'CoreGraphics', 'SystemConfiguration', 'QuartzCore', 'JavaScriptCore', 'Security', 'OpenAL', 'AVFoundation', 'Foundation', 'UIKit', 'Metal', 'MetalKit', 'MetalPerformanceShaders'
spec.library = 'c++', 'stdc++', 'z', 'sqlite3', 'iconv'

6. Cocos原生与前端进行交互：

主要是通过JsbBridgeWrapper。原生使用dispatchEventToScript方法去调用前端方法：

- (void)dispatchEventToScript:(NSString*)eventName arg:(NSString*)arg;

原生使用addScriptEventListener去监听前端的回调：

- (void)addScriptEventListener:(NSString*)eventName listener:(OnScriptEventListener)listener;

参考Cocos官方文档：docs.Cocos.com/creator/man…

参考游戏导出来的项目里面的Cocos静态库的配置，设置GCC_PREPROCESSOR_DEFINITIONS（GCC预编译头参）、LIBRARY_SEARCH_PATHS、OTHER_LDFLAGS、SYSTEM_HEADER_SEARCH_PATHS和HEADER_SEARCH_PATHS

注意：一定要参考你要原生化的项目里面的配置，因为该引擎是针对项目的，Cocos官方提供的引擎是标配的里面包含众多功能。而你项目打包出来的引擎会做一些优化（比如禁用骨骼动画之类的），而且也会去除无用的库。因此使用对应的项目编译出来的Cocos引擎及配置，会占用更少的内存，及打包出来的引擎体积也会更小。（我们优化了引擎配置后，运行内存在iphonexr上降低了90m）

针对Cocos引擎内部直接导入git开源库源码编译进.a和业务使用的开源库产生符号冲突问题解决方案为：将该开源库编译成framework，然后编译Cocos引擎的时候使用该framework参与编译（因为framework并不会被编译进.a里面去），然后业务就可以正常导入该开源三方库从而解决此类符号冲突的问题。

Cocos静态库接入XX的问题

因为Cocos引擎初始化没有回调，如何解决在Cocos引擎初始化没有完成之前业务调用预加载等方法。

A：采用心跳机制，在我们初始化Cocos引擎后（Cocos引擎初始的时候会主动加载游戏大厅），游戏大厅加载完成的时候主动告知原生，原生组件收到通知后需要主动告诉前端已经收到，否则前端还是会定时发送心跳，告知原生。

把Cocos组件初始化放在initsdk里面，会导致initsdk耗时过久，如何优化这个问题。

A：Cocos引擎初始化和游戏大厅加载流程单独抽出来，提前让业务调用。具体优化优化措施如下：

Cocos引擎初始化耗时和游戏大厅加载耗时暂时无法缩短（目前都没有有效的办法去优化这两个耗时），所谓复杂度不可以减少，但是我们可以转移复杂度。因此我们可以尝试提前执行Cocos引擎初始化和加载游戏大厅流程。由于XX-initsdk需要获取token等参数，因此目前业务将XX的初始化放在app启动后的1-2s处。但是Cocos引擎初始化和加载游戏大厅并不需要获取token等参数。因此我们可以把Cocos引擎初始化和游戏大厅加载单独抽成一个方法initCocos，业务在didFinishLaunchingWithOptions处执行initCocos方法。具体流程变更如下：

流程图.png

流程图 (1).png

在XXManager新增一个initCocos方法给业务在initSDK之前调用：

/// 初始化Cocos引擎
    /// - Parameters:
    ///   - getTopViewControllerBlock: 获取最顶部控制器block
    public static func initCocos(_ getTopViewControllerBlock: @escaping()->(UIViewController))

将Cocos引擎初始化和加载游戏大厅提前1.5s触发，且不阻塞主流程。这样就可以将原来XX的initsdk的3.2s的1.5s提前消耗掉。优化后XX的initsdk耗时在1.7s左右，比优化前缩短1.5s。

方法	优化前耗时/s	优化后耗时/s	优化/s
组件initSDK	3.2	1.7	1.5

Cocos静态库依赖了系统的zip类，而且是源码导入的且没有使用命名空间导致和sszip的产生了冲突，导致执行的时候崩溃，表现为编译时正常但是运行时冲突。（典型的命名空间问题，不止是sszip，openssl问题也存在）

A：有冲突的库采用命名空间去处理此项问题（比如这次就是通过升级sszip，sszip使用自己的命名空间）。

目前将前端通知的加载游戏大厅加载完成作为某个渠道初始化完成的回调，但是Cocos引擎初始化和游戏大厅加载只执行一次，切换用户需要重新初始化XX-sdk，会导致永远收不到成功回调。

A：恢复防止多次初始化渠道sdk逻辑，当某个渠道sdk初始化成功后，再次调用，直接退出初始化该渠道sdk，认为成功。

针对游戏远程资源不能做磁盘缓存？

A：cocos支持磁盘缓存

效果

原生化与非原生化性能对比

机型选择

iPhone 8 Plus（中端机型，iOS14.1）

iPhone 6（低端机型，iOS12.4.8）

游戏场景性能指标对比

FPS方面，考虑到不同机型系统锁帧问题，对高端机且高系统提升的不明显，但是对于中低端机又升级了高系统的，帧率提升会很大（推测iOS14及以上会锁帧，iOS13及以下系统不会）。
流量方面，原生化比非原生化流量平均消耗多约1.6MB，与开发确认请求量没变，预计是原来是加载2D的资源，现在改成加载3D的资源，资源数据量大了。
耗电量方面，在30分钟的游戏场景下，原生化比非原生化少消耗约3%的电量。
发热情况方面，在30分钟的游戏场景下，原生化比非原生化低约3 °C，从体感上能够明显感觉非原生化发热更加严重。

总结，原生化在FPS、耗电量和发热方面比非原生化均占优，用户游戏体验更好。

说明

"XX"为我们内部封装的组件名。

Cocos原生组件化解决方案iOS篇

背景

历程