以下是去年我自己做的一个小测试。作为见面礼，证明我会使用ue4。
寻找重庆市区内的大学同学，计算机系、软工、数学系的同学最好。本人有意参与或帮助同学完成一些耗时不多的小功能或者项目。作为交换，希望同学可以提供一些学校的情况给我，或者带我蹭一些课程。
因为不熟悉当今学校氛围，不清楚同学们的社交方式，想起“有事问baidu”，于是跑到这里发一帖。
有兴趣者，可以留下qq，我会主动加你。
UE4算力测试
影响范围：
帧数、发热、内存占用
测试算法
1. 每秒向x方向走1米，超过100米，返回0点。
2. 检测当前场景所有的相同类型的Actor（UGameplayStatics::GetAllActorsOfClass），自己和检测到的对象作10米距离判断。在距离内的，保存到TArray列表里（m_RoundActor.Contains和m_RoundActor.Emplace）。不在的，将其从列表里踢出（m_RoundActor.Contains和m_RoundActor.Remove）。
该算法在Tick里面执行
测试方案工程制作方式
1. 制作3种Actor，分别是用c++完成所有逻辑的CppActor；用BP完成所有逻辑的BPActor；将BPActor复制出来，设置此BP为转换成原生代码的BpToCppActor。
2. 在页面上设置3个按钮，分别生成CppActor、BPActor、BpToCppActor。
3. 每次生成会清理掉之前的Actor，确保当前场景只有一种Actor在运行。
测试方式
1. 使用同一台设备
2. 满电再充10分钟以上
3. 拔电启动APP，生成固定数量（如225个）的一种Actor，运行固定时间（如10分钟或者20分钟）。
4. 观察FPS及发热情况。
5. 关闭程序，记录剩余电量。
6. 充电，重复流程，测试新的Actor。
结果预期
CppActor帧数最高，耗电最低，发热最轻
BPActor帧数低，耗电高，发热严重
BpToCppActor和CppActor一致。但是在到达某一较大数值时能够明显拉开性能差距。
测试结果
测试采用的数据：密度2，数量225，时长10，15，20分钟
1. CppActor：帧数60；耗电2%，3%，4%；无明显发热感受
2. BPActor：帧数10；耗电3%，4%，5%；有明显发热感受。游戏属于烫，本次测试是温。
3. BpToCppActor：帧数60；耗电2%，3%，4%；无明显发热感受
C++数据
BP数据
Bp转C++
结论
蓝图对CPU有过高的开销，会严重影响帧数。
其主要的影响在于蓝图节点的时间开销。以GetAllActorsOfClass作为参考，蓝图和c++每次tick都只调用一次，而代码的响应时间是8.7ms，蓝图是10.1，额外增加了1.4ms的开销。而蓝图节点越多，额外开销也越多，调用次数越多，额外开销也越多。两者相乘，额外开销将非常巨大。
CPU高负荷对于发热的影响并不明显。因此发热和CPU关系不大，但是我们可以通过蓝图转c++的方式来提高游戏帧率。
寻找重庆市区内的大学同学，计算机系、软工、数学系的同学最好。本人有意参与或帮助同学完成一些耗时不多的小功能或者项目。作为交换，希望同学可以提供一些学校的情况给我，或者带我蹭一些课程。
因为不熟悉当今学校氛围，不清楚同学们的社交方式，想起“有事问baidu”，于是跑到这里发一帖。
有兴趣者，可以留下qq，我会主动加你。
UE4算力测试
影响范围：
帧数、发热、内存占用
测试算法
1. 每秒向x方向走1米，超过100米，返回0点。
2. 检测当前场景所有的相同类型的Actor（UGameplayStatics::GetAllActorsOfClass），自己和检测到的对象作10米距离判断。在距离内的，保存到TArray列表里（m_RoundActor.Contains和m_RoundActor.Emplace）。不在的，将其从列表里踢出（m_RoundActor.Contains和m_RoundActor.Remove）。
该算法在Tick里面执行
测试方案工程制作方式
1. 制作3种Actor，分别是用c++完成所有逻辑的CppActor；用BP完成所有逻辑的BPActor；将BPActor复制出来，设置此BP为转换成原生代码的BpToCppActor。
2. 在页面上设置3个按钮，分别生成CppActor、BPActor、BpToCppActor。
3. 每次生成会清理掉之前的Actor，确保当前场景只有一种Actor在运行。
测试方式
1. 使用同一台设备
2. 满电再充10分钟以上
3. 拔电启动APP，生成固定数量（如225个）的一种Actor，运行固定时间（如10分钟或者20分钟）。
4. 观察FPS及发热情况。
5. 关闭程序，记录剩余电量。
6. 充电，重复流程，测试新的Actor。
结果预期
CppActor帧数最高，耗电最低，发热最轻
BPActor帧数低，耗电高，发热严重
BpToCppActor和CppActor一致。但是在到达某一较大数值时能够明显拉开性能差距。
测试结果
测试采用的数据：密度2，数量225，时长10，15，20分钟
1. CppActor：帧数60；耗电2%，3%，4%；无明显发热感受
2. BPActor：帧数10；耗电3%，4%，5%；有明显发热感受。游戏属于烫，本次测试是温。
3. BpToCppActor：帧数60；耗电2%，3%，4%；无明显发热感受
C++数据
BP数据
Bp转C++
结论
蓝图对CPU有过高的开销，会严重影响帧数。
其主要的影响在于蓝图节点的时间开销。以GetAllActorsOfClass作为参考，蓝图和c++每次tick都只调用一次，而代码的响应时间是8.7ms，蓝图是10.1，额外增加了1.4ms的开销。而蓝图节点越多，额外开销也越多，调用次数越多，额外开销也越多。两者相乘，额外开销将非常巨大。
CPU高负荷对于发热的影响并不明显。因此发热和CPU关系不大，但是我们可以通过蓝图转c++的方式来提高游戏帧率。
