AprilProfiler——简单的安卓端UE4性能分析器
在魔方实习的第二个星期，当我了解完UE引擎的执行流程（game render rhi多线程tick）之后亲爱的导师提出了下一个课题：
把玩一下adb（安卓调试桥），然后试试看在游戏屏幕上实时显示一些数据（内存，CPU占用率，GPU Time）
经过痛苦的一个月（写了十天其余时间都在苦痛debug）
最后写出来的也算是比较完整的玩具了（能不能跑动随缘）
最终仓库URL：AprilNAVI/April-Profiler at master (github.com)
简述
得益于手机proc伪文件系统的存在，许多手机进程相关以及当前整体手机runtime的软硬件信息我们都能从中拿到
我们的许多信息便是从此中提取然后加工得到的
不过在未root的手机上，许多文件的没有读写权限的，我们能获取的信息极为有限，不过对我们来说已经足够了
<hr/>整个profiler涉及到一个subsystem的编写（subsystem全局单例的特性符合我们的需求）
以及RHI上的OpenGL分支修改和插桩，一些实现过程借鉴了UE4的disjoint query和一些unity的插件实现
主要的难点在于实现过程的idea（完全没有写这方面的经验）还有安卓端的麻烦调试和bug的排除
（虽然鉴于本人教菜的项目经验，代码可能并不是那么的符合规范，但还是有尽量的朝正常的项目规格靠）
其余在编码的数据结构组织以及方法的组织上来说，过程还算轻松
（基本功能可以较快写完，只是跑不动而已2333）
<hr/>测试样机：小米9Pro 5g版（骁龙855,8+256）<—这玩意是真的又烫又卡
<hr/>整体设计
在subsystem中设Start方法，其中设timer定时运行函数查询
（如果后边证实放tick里面不大影响性能也会考虑放tick）
其中为了支持timer使用，所以用的是WorldSubsystem而非EngineSubSystem
（一开始用的EngineSubSystem会不明crash）
GPU time的部分则插在RHI中，伴随着渲染帧的结束每次更新全局变量GPU Time，我在tick中拿取
这也是为什么后文提到由于渲染帧和逻辑帧的差异，要给query做缓存操作
<hr/>进程id和内存率
在proc系统中，目录：进程ID/Stat 中存放着的信息有助于我们获取到进程和内存相关的信息
有助于一个叫self的目录也能让我们快速定位到当前进程的stat文件，而无须进程ID
一个pid/stat中的文件如下所示
（这里以运行崩坏3为例，在游戏项目中获取只需要获取self/stat就行，无须进程ID）：
从前往后的24个参数分别是（我们所能用到的）：
pid stat参数
从前往后便是这些参数的含义，我们会在运行时将其读取并导入我们的数据结构
如图所示，第一个参数就是我们当前进程的进程id，这是我们所需要的值之一
在导入数据时为了方便操作，我是以原生是string类型来导入这些数据的
因此最后进程ID的转化以这样的方式：
int32 ProcessId=std::stoi(this->PidStat.pid.c_str());一般来说，在手机的内存管理中，以Pss（实际使用的物理内存，比例分配共享库占用的内存）是更加合理的
但为了便于计算我这里只计算了RSS（Resident Set Size 实际使用物理内存）
在安卓内存中，默认分配一页是4KB，因此我们最终拿到当前进程的占用内存（kb）的代码是这样的
总内存的获取则是存放在proc/meminfo内，也可以用一样的方法（c++的原生io）读取获得
将内存占用除以总的内存便能得到我们当前进程的内存占用率
这些数据通过adb都能拿到，实测在手机ue4项目runtime时也能直接读取相应目录得到
<hr/>CPU占用率
CPU占用率的计算只需要一个很简单的公式：USAGE=ACTIVE_TIME/TOTAL_TIME
拿到计算所需参数的过程则更为复杂一些，我们需要读取计算每个核心的信息录入我们的数据结构
读取每个核心ACTIVE_TIME和TOTAL_TIME，相加它们得到总的时间再相除
核心相关的信息存放在proc/stat（存放系统进程整体的统计信息）中，如图所示：
这里我用一个结构体CPU data和枚举来管理各个字段：
在读入数据时，使用的是c++原生的io和字符串相关函数，函数会将十个字段按序放入我们的CPU data中
并会自动根据proc/stat中的数据来判断CPU的数量，用一个vector来储存当前所有核的信息，将这个整体返回
计算过程则会读入前后两次不同的Entity数据，以两次数据的差量作为最后用于计算的数据
其中Active Time由字段USER，NICE，SYSTEM，IRQ，SOFTIRQ相加得到
Idle Time由字段IDLE，IOWAIT相加得到，Active Time和Idle Time相加便得到
两次的数据相减便是这两次读取期间的CPU用量数据，稍加计算便能得到最终结果：
这里计算出来的是总体的CPU用量和占用率，对于特定进程的占用率的计算暂时没有写出，但思路同样很简单
对于在上一步的proc/pid/stat文件中存在字段utime、stime、cutime、cstime的四元组
某进程的Process Cpu Time = utime + stime+ cutime + cstime，该值包括了其他所有线程的cpu时间
同样取一段时间内读取的差量，用来除以Total CPU Time就能得到当前进程的CPU占用率
在数据的读取和管理方面，我们在每次计算中将其读取进我们的数据结构
然后与原本储存的上一次读取的状态进行比对和计算
在计算完毕后我们会弃置旧的CPU data（类成员），并将新的写入以供下一次运算：
<hr/>GPU Time
GPU Time的测量在Android端则是比较不方便的，过程碰了很多壁用了很多时间，但最终还是得以成功实现
（ue自己写的在移动端跑不了，原因未知）
最终的实现过程参照了一个unity插件和UE自带的disjoint query实现
其实回头看来虽然几乎是把人家的版本copy了一遍，但确实大家写出来最终都是这个样子的
（毕竟学习的最快方式就是抄）
思路也很简单，在RHI的OpenGL分支用gl指令做插桩操作就能拿到，反而是debug的过程花了比较多的时间
首先对于这方面确实不了解，不知道安卓上哪些不了解的地方会影响到gl指令结果的返回
我不知道用ue原生的跨平台函数，会跳到哪个奇怪的地方然后给个奇怪的crash
因此我先是把默认的开关全打开（我不清楚哪一步是必要的，但最终可以取到结果）
AndroidOpenGL：
OpenGL.h：
紧接着，为了方便之后test，我不想直接改变引擎自带的全局变量GGPU Time的值
（我可能用这个变量也做一些test）
总而言之一个是不够我用的，因此我在EngineGlobal中增加了新的同为unit32类型的全局变量：
（当然这么做的代价是一次全量编译，但换了SSD之后编译整个引擎的速度还是可观的）
对于GPU profiler的部分，我的数据结构和可能用到的init和release方法是直接照抄ue
UE的实现分为一个Timing（使用glQuerycounter指令）的实现和disjoint（glBeginQuery）的实现
其余部分做了一些简化，我去掉了加锁的部分，去掉了Event Node的统计，只留下Disjoint的实现方案：
采用的查询和计算的数据结构直接用的UE自己写的FOpenGLDisjointTimeStampQuery
因为渲染帧和逻辑帧不是一一对应的，我们在读数据的时候拿的不一定是确切的渲染帧
因此我们在Profiler中构建了一个数组来存放每次渲染帧中query的结果
（UE用了4个buffer，但实际上用2个就够了，因为game线程只会比渲染线程快1到2帧）
对于每一个单独的query结构而言，数据结构的布局是这样的，这方面和另一个unity插件也是差不多的
一个上下文，一个储存内容，一个bool记录资源可用性，精简且使实用
初始化阶段，会调用每个query的init函数，实际上做的是调用UE封装的函数PlatformGetNewRenderQuery
这个函数封装了使用gl指令来生成query查询结构的过程
我不知道这个函数能不能放心用，所以还是亲自把它搬出来了：
在渲染帧开始的时候（RHIBeginFrame）和渲染帧结束的时候（RHIEndFrame）插入我们的profiler函数
实际上架构方面的东西也很取巧，UE往哪插我就往哪插，省了很多研究这部分架构的时间
对于Begin来说，做的是确认初始化，然后确定查询的index调用查询函数
tracking方面则是简单的调用了glBeginQuery和glEndQuery指令
其中我会在EndTracking时尝试获取当前操作是否成功，并返回相应的错误代码（在debug阶段帮了大忙）
对于EndFrame来说，除了停止tracking之外，还会根据确切的index对应的query结果来计算这个渲染帧的GPU Time
查询query结果时使用的glGetQueryObjectui64v指令很有意思，会根据传入的枚举值不同然后执行不同的操作
UE也对此操作做了封装，改为使用UE的枚举而非OpenGL的枚举
亲测使用OpenGL的枚举在Android上打包会因识别不出来而失败
之后会返回一个未经加工的时间，一般来说将其除以1e9就能得到最后所需的单位ms（下图算完就是1.05ms）：
我们将其写入我们的全局变量中（这样我在另一个profiler Subsystem中就可以直接拿到）
这样我们测量GPU Time的部分也完成了
<hr/>难点及解决方案
实现过程的Idea
由于本身一开始对于Android这块领域的知识是很空白的，因此Idea的构思花了比较多的时间
对于Android来说，许多信息都需要计算得来，不像pc平台例如进程id这种数据可以直接用一个api拿到
一开始我对于adb，shell，Android memory，proc这些概念是完全空白的不了解的
甚至对于c++的输入输出以及文件读写的api操作用的都还不是很熟练
在实现功能的时候碰了很多和最终结果完全不着调的壁（当时甚至还想到hook方面还有接入安卓sdk）
后面经过一些其他同学和前辈的指点和开导，对于Android和linux的共通性有了一些脑中的概念
通过KM还有一些其他地方零零碎碎的资料，对于不同种类的内存（pss，vss，rss）也有了一定的了解
proc中一些闻所未闻的参数也和我之前所学OS的概念能慢慢对应上
最终是借鉴了一个linux上计算cpu和memory的方案（实际上proc也是linux的东西）
代码的编写过程没有遇到什么太大的阻碍，反而是借机还学习了一下正规项目的代码规范和命名规则
其实最后总结的时候看来，要写出一个同款profiler的思路还是很简单很好借鉴的
不过思考问题寻求答案的过程对我来说感觉还是很有意义的（每次问导师有没有提示都说先Google一下）
<hr/>Android端读写proc的Debug（艰苦卓绝的代码和编译环境）
PC不是linux或者安卓平台，不存在proc可以直接读写调试
因此确定能不能拿到proc的值并且成功计算，就成了一件很麻烦的事情
本身改引擎用的cpp，然后初学时又经常不小心动到头文件（有时候确实会用到）
再加上硬盘是HDD，CPU性能也比较羸弱，编译和打包要花很长很长的等待时间
每次改代码都到手机上打包去看一眼结果，最后带来的就是地狱级的体验
有时候加一行log编译再打包就能花半小时
后来善用adb将proc内的文件数据进行cat，copy到PC上存进txt一定程度上的方便了读数据功能时的调试
然后我也能拿到UE在Android端的log数据（之前请教很多大佬不知道目录最后还是导师告诉的我）
最后还是顺利完成了有关proc方面相关的功能（比较尴尬的就是runtime时proc/stat好像在项目上拿不到）
<hr/>Android端的OpenGL Debug
OpenGL在Android上的限制比较多，例如很多查询功能在源码内默认是关的
对于以前简单的用win32 c++配置搭个框架就能写shader的环境
在安卓上虽然不做什么开发操作反而感觉举步维艰，有很多限制
最尴尬的就是每次glGetError结果都是1182_GL_INVALID_OPERATION
然后查各种手机GPU的文档还有Android的文档都发现没问题（Android确实支持OpenGL的）
然后每天盯着屏幕插log都快把ue插成海绵了还找不出问题
最后导师提醒可能是我的query和ue自带的query产生了冲突（刚好我插桩代码的地方每次ue的代码都比我先跑）
然后卡了十几天破案了我只觉得特别震撼（总的花了一个月左右，1/4想，1/4敲代码，1/4卡在查询指令）
中间还一直很怀疑自己，就简简单单的一个指令的事情做不好，导师会不会觉得我是笨蛋哈哈哈
<hr/>参数带引用的函数无法正确的改写参数值
编写相关函数需要拿一些数的时候，经常会用到传引用进函数的情况
例如void GetXXXFunc (Type &a,Type &b)这样的函数原型
这样拿数往往比直接返回值要利索的许多
但在写返回GPU time相关函数的时候，突然间那个值就因为不明原因赋不了
甚至中间在函数里面嵌了log把里面那个地址直接解引用出来都是赋好了值的
但是回到函数外层的时候就没了，最后也卡了很久然后莫名其妙的就好了
函数问了导师还有很多人也说写的没有问题是正常写法（关键是之前都是这么写的）
<hr/>后记
写这篇后记的时候距离这个课题弄完已经过了很久了
当时写这个课题的时候应该很多地方应该有更成熟的写法的
对UE引擎的理解还很幼稚，对Cpp特别是字符匹配读写那方面也不是太熟悉
整篇文章也夹杂着很多当时的个人主观的想法
欢迎评论区大佬指出我思想上的局限和错误，以及友善的河里讨论
总体而言虽然花了很多时间遇到了各种奇奇怪怪的bug（甚至中间编译器出bug函数不返回）
但一边补知识框架，一边写功能的开发过程给我带来的收益，让我感到发自内心的喜悦
此时正在进行Fmalloc的分割和打tag的工作
讲真目前不太顺利但也还是痛并快乐着（应该.......快乐吧）
（指走了很多弯路，看了什么内存分配器，然后恶补了一堆底子然后走了一堆弯路发现还是不会）
（然后真的真的很抱歉我的导师这个不会那个不会的）
许愿希望之后的实习，秋招，转正生涯都可以一帆风顺（过必还愿）
页:
[1]