益达游戏平台《永劫无间手游》客户端性能监测工具
1、益达平台游戏数据驱动的智能画质调节
1.1 背景介绍
动作游戏虽然强调的是玩家反应能⼒和⼿眼的配合，但是画⾯的流畅程度对玩家的操作有很大的影响。其中，衡量画⾯流畅度的主要指标为 FPS；衡量画质通常与游戏中设置的图形参数有关，⽐如模型质量、阴影质量、特效、曲⾯、渲染、分辨率等等，不同的游戏可能存在部分相同的参数，但是实际实现过程又会有所差异。
具体来说：
从玩家角度看
图形配置参数多，对画质和帧率的影响如何确定
不同的游戏图形配置参数并不相同，按经验迁移是否可靠
从游戏的角度看
样机数量，测试覆盖，硬件与游戏迭代的同步
多目标优化问题，游戏流畅度，画质，移动端的发热（负载）等
我们的解决方案是：基于玩家当前的设备，自动推荐最佳体验的游戏设置，在设备层面对游戏配置进行推荐；同时基于游戏数据驱动和版本迭代，低成本覆盖全量设备，最后数据闭环验证推荐效果是否达到预期。
1.2 益达平台多端多平台硬件数据集的构建
多端指的是 PC 端、移动端的手机/平板，在移动端我们整合了设备的评测跑分数据，并将评测数据通过典型设备进行对齐，并在新设备未收集到跑分之前，通过横向对比和纵向对比来进行跑分预估，横向指的是相同芯片，纵向指的是同一厂商的同一个系列。
其中，d 表示多端设备， j 表示平台 id，Slj 和 Slo 表示 d 在某个平台或基础平台上的得分。基础平台上未出现的特定设备的得分将通过 αi 进行转换，S(d) 是最终评分。
另一个问题是我们熟知的商品名比如 Apple iPhone 16，与 Unity 拿到的设备信息不同，这个信息主要是 device model，一款手机可能会具有多个不同的 device model。此外，一款手机可能由于发行地区的差异，厂商在不同地区发行的设备芯片也不相同。
设备名与商品名（宣传名）的对应关系：
设备名 Devide Model
iPhone17,3
vivo 2426A
...
宣传名/商品名
Apple iPhone 16
vivo iQOO Neo10 Pro
...
不同游戏对于同一款设备的性能要求不一而足，需要在硬件跑分的基础上，不断的通过真机实验室的真机跑测和游戏数据来构建一份适配当前游戏的硬件数据集。目前，我们构建的硬件数据集在机型覆盖和玩家覆盖上均有不错的表现。
移动端、GPU、CPU 数据集分别包括 4200+、900+、3300+ 种型号，100% 覆盖骁龙 865、GTX 650 Ti、Intel i3 同等性能及以上的设备
在玩家覆盖方面，数据集正确匹配比例都在 93% 以上，大部分厂商都在 97% 以上
真机跑测一般有两种跑测策略：
电池温度XX度以下开始，跑战斗录像一局（约15分钟），大厅休息5分钟，重复多次
电池温度XX度以下开始，连续跑战斗录像多局
第一种用于内部跑测，第二种是用于和品牌方对齐，跑测方式会更为严格。
1.3 益达平台画质适配与设备负载建模
在数据预处理阶段，通过对 FPS 每隔固定时间进行采样，可以获得包括 FPS、FPS3、FPS99 等数据序列，其中 FPS99 是采样间隔内最差的数值。此外，还可以增加一些额外的信息作为补充，比如玩家状态，玩家状态可以用于区分多种游戏模式，或者不同场景等，还有一些实时设备信息，如游戏占用内存大小，剩余内存大小，CPU 使用率、GPU 使用率等等。
在建模过程中，还需要关注 FPS 序列的有效性，可以通过战斗状态，有效长度等来进行过滤和筛选。由于 FPS 是一个序列，还需要将其转换成标量用于后续的预测工作。
在设备负载建模的工作中，输入主要包括两大类，设备性能相关和配置参数相关，而模型输出是耗电情况，如果对 CPU、 GPU 有要求，也可以将其作为建模的输出。
其中，R，D，F 和 S 代表用户、设备、FPS 统计数据（平均值、中值、分位数）和图形设置的数据。 L 表示建模误差。一旦 R，D 确定后，F 可以从历史 n 个版本中得到，S 为推荐的图形设置。
1.4 性能效果评估
我们分别针对数据大盘和具体机型设计了多张报表，比如玩家选择的配置和推荐配置的人次占比，以及推荐配置下，FPS 在不同区间内的占比情况，用于评估当前设备的实际帧率表现。此外，对全量设备进行负载条跑测，可以在游戏外放前确认每一款设备外放效果是否符合预期。
2、益达平台客户端性能监测
本文章第一部分硬件数据集构建与画质适配的项目主要侧重于，如何从数据的角度给玩家提供最优的帧率和画质设置建议。当前所介绍的客户端性能监测工具主要侧重于对局过程中的各个指标进行监测和分析，主动发现可能存在的性能问题并优化，两个工具相辅相成为游戏客户端性能监测提供最优的解决方案。
2.1 背景介绍
游戏客户端性能监测存在的问题主要分为以下几点：
影响客户端性能表现的因素非常多样，包括设备型号、CPU、内存、客户端配置以及游戏本身的资源开销，甚至手机的电量和温度等外部环境因素都会对性能产生影响。
日志的数据规模庞大，仅FPS日志每天产生的数量就达到上亿级别。
针对上述问题，本文的产品采用了以下的解决思路：
明确卡顿问题的度量标准，通过定量观察帧率数据来为客户端性能设定量化标准。
分析可能导致卡顿的各种因素，并明确数据来源，确保信息含义的一致性，实现实时数据采集和处理。
利用获取的数据指标进行宏观数据分析与微观数据细查，以更好地理解和优化客户端性能。
2.2 产品功能介绍
本文所提客户端性能监测工具所提供的功能主要分为以下六大方面，包括：
宏观大盘数据分析：主要从机型与设备统计、画质与分辨率统计以及帧率分析统计三个方面进行分析。比如机型与设备统计，设备的芯片厂商分布、设备等级分布以及机型芯片分布等，提供了全面的设备信息洞察。
对局信息统计：以列表形式展示每场对局的关键统计指标，包括总人数、决赛圈人数、帧率异常人数以及降频指标异常人数。指标支持维度下钻，能够详细展示一场对局中的具体指标变化，便于分析具体设备表现和潜在问题。
微观层面的战斗对局可视化：直观展示了相关指标随时间变化的趋势，包括帧率、自适应降频、CPU使用率、GPU使用率、内存使用情况和设备电量等。
游戏录像回放：支持在web端对游戏对局的录像进行即点即播，同时支持多人在线播放，方便快速定位问题。
游戏数据实时：所有的数据均使用流式处理方案，达到了秒级延迟，能给快速反映游戏对局的最新变化。
2.3 平台关键技术分析-游戏数据高性能的读写架构
2.3.1 平台数据流转架构设计
当前章节介绍了从数据采集到数据最终应用过程中，平台整体数据流转的架构设计。此架构综合利用了各个大数据组件，确保了数据流转的高效性和灵活性，为游戏方提供了强有力的数据分析和决策支持。
使用日志采集工具，性能相关的数据实时上报至平台进行缓存。
基于业界主流的大数据流式处理引擎Flink对数据进行各种加工和计算。
根据不同应用场景和数据特点，存储到多种大数据组件中，主要包括HBase、Elasticsearch、Doris和TiDB等。
在数据应用层，通过一个Web服务器将各个上游系统的数据整合，提供统一的入口，以便在下游不同的应用场景中为用户进行使用。
2.3.2 大规模游戏对局序列数据处理
在游戏对局可视化的应用场景中，主要具有以下几个特点：
数据分布具有明显的时序性：游戏对局数据通常是按时间顺序生成和记录的，时序特性显著。
低延迟、实时获取与更新数据：对于游戏场景而言，能够及时获取和更新数据对于用户体验至关重要。
数据量级庞大，需达到秒级查询：随着玩家数量和游戏数据的增加，系统必须能够处理大规模的数据，并支持秒级查询响应。
当前场景的查询方式较为简单：在可视化场景中，用户并不需要复杂的检索条件，查询方式相对简单。
不需要支持复杂的联表和聚合能力：游戏数据的查询需求相对直接，不涉及复杂的数据关系操作。
而HBase是Hadoop生态系统中非常主流的NoSQL数据库，其主要特点是提供大规模数据集的随机读写能力和实时分析能力，非常适合处理时序数据。基于上述考虑，采用了HBase作为方案设计的基础。
在设计过程中，主要考虑了以下四个因素：
行键设计：行键作为表的主键，确保数据的唯一性。HBase的快速查询能力也建立在行键的基础之上。
二级索引设计：由于HBase不支持内置的二级索引，如需要基于其他字段加速查询，必须手动设计二级索引。
行键加盐以避免读写热点问题：HBase作为分布式大数据组件，数据的均匀分布直接影响读写性能。为行键前缀加盐，可以增强前缀的散列性。
预分区设计：HBase在默认情况下会将数据写入单个节点，达到一定阈值后进行分区重分配与迁移。如果预期的数据量较大且写入频繁，分区的调整频率可能会很高。通过预分区，可以提前评估表的数据量，并合理分配分区数量，从而提升读写性能，避免不必要的I/O开销。
针对当前应用场景，我们设计了一张主表和多张二级索引表，以优化数据查询与管理。充分利用HBase的特点，为游戏对局可视化提供高效、实时的数据支持。
1. 主表设计：主表通过用户ID、对局ID和时间戳三者组合，确保每条记录的唯一性。各类指标值（如帧率、降频、CPU使用率、GPU使用率等）被纳入普通字段中。此外，为了保证数据的散列分布，对用户ID和对局ID进行了MD5加盐处理，这可有效减少读写热点问题。
2. 二级索引表设计：二级索引表允许开发者基于非行键字段进行高效查询，这对于需要通过多个属性进行检索的场景非常有用。在二级索引表中，需要先基于需要检索的字段设计行键，然后将主表的行键信息作为二级索引表的目标数据进行存储。当进行查询时，需要开发者手动实现回表的逻辑，先基于检索条件从二级索引表中定位对应的主键，然后基于主键在原始表中检索实际数据。
2.3.3 海量数据的混合事务与分析处理
在玩家对局信息统计的应用场景中需要以对局为粒度进行数据明细的存储，其应用场景特点如下：
汇总每场对局的指标信息，要求支持数据的实时写入与查询分析。
针对《永劫手游》庞大的玩家基数和对局数量，系统需能够高效存储亿级数据并实现秒级响应查询。
需要进行多表联接和复杂的聚合操作，以提取更深层次的信息。
同时支持在线事务处理（OLTP）与在线分析处理（OLAP），适应多样化的数据处理需求。
除了存储数值型数据外，当前场景还需将大量信息汇总并保存为多个文本类型字段。使用传统的行式存储数据库（如MySQL）会面临明显的性能瓶颈。
TiDB组件特别适合需要存储和查询大规模数据集并进行实时分析的应用，能够恰到好处地满足当前的使用场景。
在对局信息统计的流式数据处理过程中：首先，系统消费多个日志来源，以对局为维度进行实时数据关联。通过开窗与聚合的方法，计算出各个对局的指标，最终将多条数据以批量的方式写入TiDB。用户可在页面上实时分析对局信息，获得及时的反馈与洞察。
2.4 益达平台关键技术分析-即点即播的游戏录像回放系统
2.4.1 游戏录像回放存在问题
快速便捷的游戏录像回放能力对于游戏客户端的问题排查至关重要，对于游戏录像回放需求的技术实现，现存的主要问题如下：
游戏录像与普通视频文件（如MP4格式）存在显著不同。游戏录像并不保存完整的视频画面，而是仅保存元数据，比如玩家的动作和状态，不包含地图资源。此外，游戏录像需要支持多种交互操作，而不仅仅是简单的画面展示。
由于录像文件只保留元数据，用户必须依赖游戏客户端加载许多额外的场景资源才能进行播放。
这使得游戏录像的播放过程变得相对繁琐：用户必须先手动下载录像文件，然后登录客户端进行播放，并且需要手动维护和更新客户端版本。
基于上述问题，本文着重考虑如何在浏览器上实现游戏录像的播放功能，以真正做到“一键播放、即开即用”。
2.4.2 基于Web端的远程桌面控制
最初，平台计划采用基于Web端的远程桌面控制方案。具体实现为事先在Windows主机上安装好游戏客户端和VNC远程连接工具。用户通过WebSocket协议，可以在浏览器中直接进行远程桌面控制，从而观看远程主机的游戏录像画面。
然而，这一方案存在以下几个问题，导致难以在实际场景中进行应用：
尽管无需用户自行维护游戏客户端，但整个播放流程仍显得相对繁琐。
远程桌面的网络延迟较高，可能导致播放过程中的卡顿现象。
连接容易中断，从而影响用户的使用体验。
安全性问题显著，此方式相当于将Windows主机的所有权限交给用户，存在潜在的安全隐患。
2.4.3 基于在线直播的录像回放方案
经过一段时间的探索与研究，团队创新性提出了一种基于在线直播的录像回放方案。这一方案实现了“一键播放、即开即用”的目标，并且避免了安全性问题，因为用户仅需接触到少数录像操作的接口。
该方案的实现过程如下：
首先，利用OBS直播推流软件实时采集游戏画面，并将采集到的画面推送到提前部署好的流媒体服务上。
用户在浏览器端通过指定的流媒体协议拉取直播画面，从而以直播的方式播放录像。
在播放过程中，用户可以进行播放、停止录像、切换视角和调整视频进度等操作。
前端通过HTTP请求将这些操作发往后端，后端再通过TCP协议向游戏服务器发送GM指令，最终控制客户端完成相应的录像操作。
针对多用户同时播放录像的需求，本文设计了多用户播放的并发处理策略，保证了在游戏客户端资源有限情况下，所有用户可以有序访问客户端资源。具体的设计思路如下：
独占直播间：系统支持用户独占直播间，每个用户观看的对局可能不同，甚至同一场对局中不同用户的视角也可能有所不同，因此必须为每个用户分配独立的游戏客户端以进行独立操作。
多台Windows主机：为了满足这一需求，需要准备多台Windows主机，每台主机启动多个游戏客户端，确保每个客户端都能独立采集画面进行推流。
并发资源控制：采取必要技术手段来有效控制并发资源，确保多个用户不会占用同一个游戏客户端，同时也防止同一用户同时占用多个游戏客户端。
心跳检查机制：该机制旨在避免用户长时间占用游戏客户端资源而未实际使用，导致其他用户无法获得客户端资源，从而造成资源浪费。在录像播放期间，浏览器与服务端之间会维持一个心跳连接。如果用户长时间占用直播间却未进行实际操作，服务端可以主动释放长时间未连接的资源。
在录像播放和关闭过程中，系统各个模块的依赖关系与具体流程设计如下：
当用户点击播放录像时，前端向后端发送HTTP请求，包含玩家ID和对局ID。后端接收到请求后，将访问关系型数据库以申请空闲的客户端资源。
为实现并发控制，所有游戏客户端被编号并抽象为一组并发资源记录在关系型数据库中。数据库返回一个最久未使用且空闲的客户端ID。
后端服务基于对局ID、用户ID、录像URL和客户端ID等信息构造GM指令，并发送给游戏服务器。游戏服务器根据指令中的客户端ID与指定游戏客户端进行通信，完成录像播放操作。
随后，OBS直播软件会采集到游戏客户端中录像播放的画面，并推流至流媒体服务器。为了区分不同的游戏客户端，每个流都有唯一的推流码进行标识。
后端服务在收到游戏服务器的响应后，将推流码返回给前端。前端根据接收到的推流码从流媒体服务器获取指定画面，在浏览器中完成录像的播放。
当用户点击关闭录像时，前端会发送停止录像的请求，后端根据客户端ID构造停止录像的GM指令并发送给游戏服务器。游戏服务器控制指定的游戏客户端停止播放。后端服务在收到响应后，从数据库释放当前资源并向前端发送释放成功的消息，前端在收到响应后与流媒体服务断开连接，关闭播放窗口。
2.4.4 游戏录像时间戳对齐方案
录像时间戳对齐方案是整个系统中一个关键的功能特性。在游戏对局的可视化图表中，各种可视化指标是基于时间戳进行展示的。然而，游戏对局的画面中并没有时间戳信息，只有房间的倒计时信息。
由于房间倒计时与对局时间戳这两个维度无法直接关联，玩家在某个时间点注意到掉帧的情况时，无法直观地将此时间点与录像画面对应起来。这一问题成为开发人员排查问题的一个重要痛点。
为了满足时间戳对齐的需求，平台采用了实时捕获游戏画面结合图像识别的方式完成了录像时间戳的实时显示：
WebSocket插件服务：每个OBS实例都会运行一个WebSocket插件服务，通过WebSocket接口低延迟地获取游戏客户端的画面截图。由于存在多个游戏客户端，Web侧需要维护多个WebSocket客户端，以便对多个直播流进行画面截图。
图像识别：通过大模型对录像截图进行图像识别，以提取游戏画面中的倒计时信息。通过一定的换算，我们能够推导出当前倒计时所对应的时间戳信息。
实时时间戳展示：最新的时间戳信息会通过OBS提供的WebSocket接口进行文本推流，从而将最新的时间戳实时展示到游戏画面中，前端最终获取到的就是包含时间戳的信息视频流。
资源按需使用：由于截图和图像识别的过程资源消耗较大，系统只在播放录像和调整时间进度时进行截图识别倒计时。在其他情况下，仅需定时每秒在本地更新时间戳。Web服务器与OBS插件的连接也仅在播放录像时保持，停止播放时则释放WebSocket客户端。
延迟优化：我们力求在获取游戏画面帧、进行图像识别倒计时信息、计算时间戳以及将新的时间戳展示到直播画面之间实现毫秒级的延迟。即便倒计时识别偶尔出现秒级的延迟，也可通过异步更新等手段使用户无感知。
该方案的效果展示如下所示，通过这一方案，用户能够直观关联游戏画面与时间戳，使得在观看录像时，可以更轻松地定位到特定事件发生的具体时刻，显著提升了用户体验和对游戏对局的分析能力。
3、总结
数据驱动的智能画质调节，主要是通过构建多端多平台的硬件数据集，再加上游戏数据、真机跑测来训练预测模型，并结合数据报表和监控指标，数据闭环验证推荐效果，以此来简化新玩家的配置操作，优化玩家体验。
客户端性能监测，则是通过高性能的读写架构和游戏录像回放系统，在保证数据流转的高效性和灵活性的同时，主动监测和分析对局过程中的各个指标，还原游戏场景，为永劫手游开发团队快速定位玩家反馈的问题提供数据分析和决策支持。
以上就是全部分享内容，希望本文的分享能够对大家有所帮助。
