导读

写这个类型文章的原因是，很多时候会写代码的很多，但是如何少走弯路，做出一些有价值工具产出贡献一点绵薄之力。
在入职第二年也打算大力发展做这块（根据过往积累和经验写下了这个文章），但是后面平台化后，这件事会推研到 2022 年。
过去也是把这个工具开发方式小范围共享过，在对方公司也获得了好评和认可。
导读，可以先读这个drawcall 工具链 ，更有营养。

适合类型
3D 引擎或者 2.5D 引擎，测试时锁视角（确保每次测试的准确性和摄像机白话来说所见即所得）
游戏和个别引擎互联网都适合用。

适合条件阶段
条件 1.和 TA 有一定的共识后才去做，搭配分工明确。
条件 2.有一定建设程度以及稳定性自动化框架，以附件的形式。
条件 3.1 有小地图雷达并且有坐标的游戏，可以点开地图自动寻路的

条件 3.2 有 GM 指令可以输入：move 场景地图 Id 坐标，进行瞬移的。

使用条件引导
只有不满足条件 3.1 和条件 3.2 的，也可以继续看个热闹，满足条件 3.1 或者条件 3.2 就可以进行下去。
去对接 TA 合作的流程，当满足条件 1 之后，增强对条件 2 的建设。

文章核心

1.性能测试为啥要用热点图
热点图提供了一个对整个测试的场景（颜色的深浅来标记性能哪里更严重）。

客户端性能优化是一个比服务器优化更耗时的工作，通过热点图全局的发现场景性能最差的区域。

点的原因精髓在存储什么数据结构好提供后面复现和平台化。

绘制热点图和疑似问题一点是需要绑定 1.UI 自动化，2.引擎内置自动化来做的，前者通用性比后者强，后者 unity 需要 c# 的编程能力，在很多年前的 testerhome 社区 - 游戏测试白皮书上有作者写过 unity 内置自动化。

2.如何确定热点图的准确性

颜色深度的部分周围颜色一般会逐渐变浅（大部分情况），比如这种就是例外，后面就是一面墙，完全隔离了周围场景，游戏也只能从低往上看，啥也看不到。
热点图的存储的属性是正确的。

3.分析结果方式
选择场景内热点图颜色深度的坐标，飞过去看那块区域，然后用官方 profile 去看具体问题，都是和那块区域场景直接挂钩的，比如那边有一个深陷的大峡谷和一个瀑布，瀑布结果是用完全是用粒子效果实现的，大峡谷摄像机景深没有做处理，捂脸。
可以用空白场景复原性能最差区域，新建一个空白场景，把那个区域的场景素材导入到新场景.
对场景很熟悉的人，可以更快的猜到是哪里问题，来源于经验，有志向的可以学习知识图谱，然后每个游戏一个，把屏幕坐标-->世界坐标存在分 type，性能倾向 (比如一些 npc 激烈战斗的场景，飞过去分析某块资源是正常的) 存储属性图里面，这个都是后话。

UI 自动化的建设

选择用什么框架不重要，但是需要把这部分做成插件，用 pypiserver 搭建私有 pypi，然后改源后就可以使用。
【】里面是插件名称，后面紧跟着是插件使用方，存在-->是指最终目标用户，下面介绍几个常用的，其他按需来。

【untiy 坐标存储插件】脚本编写者->性能排查使用方：需要包含对于 Unity 引擎 Debug.log(向量) 导出日志，并且没有精度问题，坐标系处理存储到 web tracking。坐标系存储什么或者是否要转换需要和使用方沟通，来解决。

【雷达图数据存储插件】脚本编写者:UI 自动化框架获取，雷达图和 unity 坐标如果有条件，条件是指游戏有雷达图是都需要的。

【地图坐标换算插件】脚本编写者，如果满足上面条件 3.2 的，如果是世界坐标的需要换算成当前场景坐标（其实是可以不用 z，因为 3D 场景的地图本身也是个平面），最终会把整个场景要执行的位置以二维数组有序存储下来，在执行寻路时严格按这个来。
里面技巧是第一 UI 自动化本身看不到路点，也和 unity 内置的不一样，坐标和坐标之间的缝隙，拿其他框架拖拽用的 swipe([],[])，二个数组之间有关，如果有程序机器人可以给你录制一个整个场景按序跑的坐标系，自然更好。
每移动一次就采集当前场景的属性 (cpu,fps,内存)，因为 UI 自动化外部采集没有办法和 profile 拿到更多信息。
推荐方式：性能差的地方对屏幕进行高精截图，屏幕上开发那边也可以打印更多的信息。

这里和【untiy 坐标存储插件】不冲突，因为看最终目标用户，所以不是一类，强调这个是因为后面文章也是和这个有关。

结尾

晚上有人问我头发还多吗，猫回答:还有 32 位的头发。欢迎有问题留言，看到就会回复。