【浅入浅出】 讨论移动端游戏体验面对的问题2 -- 互通信息

引入

鸽了比较久，最近比较忙，搞完一阵才有些空闲便来更新了。书接上文，我们简略的聊到了移动平台大小端的历史由来，还有在这种架构下，移动端游戏体验所面临的挑战和问题。既然聊完了问题，而不去分析和解构，那问题的抛出也就没用太多意义。这一次我们就来深入聊一聊这个问题，和可能的解决思路。

资源供给

在大小核的全面普及下，游戏引擎如何更合理的去使用好系统资源，这是放在移动端游戏最重要的挑战之一。前文提到了，早期Unity和UE引擎并没有针对移动硬件这一趋势而去做引擎层的适配，因此导致了引擎在操作系统上运行会出现各种各样的体验问题。下图简单展示了现代移动端手游的各层次结构：

在这个层级架构下，底层的硬件设计公司们，会根据最新的器件发展，材料发展，结构发展，设计架构迭代等设计出高效的移动CPU/GPU等，然后编写最新的设备驱动，一般是闭源的代码，然后设计一套针对当前硬件的封装接口开放给上层的系统开发公司。并提供一些文档给到系统侧去实际建立自己的资源管控机制。

在系统开发这一层中，操作系统会根据当前软件发展的趋势，硬件提供的特性，建立起一套自己的使用框架，编写了服务框架的代码，把底层的硬件特性根据自己的理解进行封装，抽象成一个服务框架的能力，作为系统的基础能力提供给给个系统服务或者上层应用进行调用。也就是在这一层，有些公司开发自己的AI调度系统，AI供给系统 来替换主流的EAS调度。

在引擎这一层，实际上是完成了对于构建一般应用通用功能的组件框架，本质上也是应用侧。只不过完成了应用侧软件中相对底层（直接处理系统资源交互，图形API使用管理等）的操作。使用引擎来开发应用能最大限度的减少开发周期。而引擎层作为应用和系统交互的窗口，应该实现对系统的高效互通。

应用层，就是应用侧根据自己的一些业务需求，完成对于整个应用逻辑的构建，这种构建一般建立在引擎提供的基础能力上，引擎实现了对系统的低级接口的抽象，使得整个应用能够尽可能的解耦于系统版本。当然也可以完全自己实现所有的基础能力，来实现最极致的应用性能。

那么理想的交互应该如下图

从这个图我们可以了解到，在底层硬件改动后，各家操作系统服务提供商就会根据硬件的特性，设计全新的资源调度，供给，分配机制，并构建自己的消息传递框架，这么一套消息传递框架就是为架设一条通路，来提供给引擎或者应用来实现对一些资源信息感知或者资源的设置。实际上，各家也是这么做的，我们就举一个Google 的例子：

Google： Android Dynamic Performance Framework 动态性能框架，这一套框架中，引擎或者应用提供注册能够获取到系统温度和器件的热状态。然后应用侧根据这些信息调整自己的逻辑或者渲染管线。同时，这个框架也提供应用或者引擎来注册一些信息来告知系统当前的线程工作情况，工作内容。然后系统对能够更加这些信息决策线程需要的算力和资源。

OK，把整个通路简单的捋了一遍后，大家对这个问题的来源，分析和解决方案大致有一个了解。这个问题其实需要系统侧架设一条信息通路（目前绝大数系统开发商已经做了），然后应用侧或者引擎通过适配这个信息通路，来实现信息互通，这样就能把这个问题解了。遗憾的是，目前引擎侧和应用侧接入的还是比较少。

这次我们把CPU侧的情况聊了一遍，下次我们会谈谈现代GPU的一些挑战和分析。

Reference

https://developer.android.com/games/optimize/adpf#sample