准备
- 测试手机的耗电量与发热量前，需要检测手机电池是否健康。健康度是否良好，是优化的前提
- 除了一些手机自带的电池健康度、温度接口外，还可通过第三方工具进行检测，如XCode的耗电量分析、UPR的耗电与电池温度监测等
功耗与发热量优化
- 功耗与手机发热的本质依旧是性能优化问题，现代手机芯片都会设定一个手机临界温度，在手机触发这个温度墙时，系统为了保护硬件，会对芯片做降频处理，这直接会导致手机运行游戏时出现掉帧的情况。一般来说，一些大型3D手游都会遇到这个温度墙。降频后，随着硬件温度的下降，系统还会让芯片恢复正常的频率。我们的优化主要是推迟触碰到温度墙后的降频发生时间，以及让这个降频时间缩短
- 温度过高是导致系统降频的直接原因，导致温度升高的原因有：
- 抛开我们控制不了的部分，针对于手机发热问题，我们只能从CPU、GPU负载、显示、GPS、网络通讯与IO、屏幕亮度方面去优化了
常规负载优化
- CPU负载
- GPU负载
- 性能优化都可以理解为是CPU负载、GPU负载的优化
- 当游戏锁60帧时，CPU开销控制在 10-12ms GPU开销控制在 6-8ms
- 当游戏锁30帧时，CPU开销控制在 18-20ms GPU开销控制在 8-10ms
几乎是不会遇到温度墙的
- 即使你的开销超过个推荐数值，也要尽量控制不让GPU的负载超出太多，CPU可以适当放宽，更高的开销带来的发热量一般GPU比CPU大
非常规优化
- 网络与IO
- 发包频率
- 需要通过端口和IP区分哪些是真正意义上的网络通讯开销
- 频繁IO读写
- 一些网络游戏本身通讯量不高，或根本就是单机游戏，但由于使用第三方的广告平台或信息收集平台的SDK后，也会开启一些网络线程，并进行非常频繁且大量的数据通讯，这块带来的发热问题也不容小觑，需要额外关注有没有一些设置来调整这些SDK
- 显示亮度与FPS
- 现在大多数高端手机都以拥有高亮度的手机屏幕为追求，其实在绝大多数手机游戏运行时，完全没有必要开启最高亮度，甚至为了减少屏幕发热，需要在开启游戏后，将屏幕亮度控制在一定范围内。在一段时间待机的情况下，甚至要大幅度调低手机屏幕亮度以节省电量、减少屏幕与电池的发热量
- 针对手机游戏显示帧率的问题，一定要按需控制帧率，有些没有必要锁60帧的游戏类型，完全可以采用锁30帧的方式
- 在全屏UI或模态对话框覆盖屏幕时，可以将原来30帧的显示帧率调整为一半，将60帧的显示帧率调整为原来的1/4
- 甚至在待机状态，屏幕亮度调暗的情况下，可以调整到个位数的帧率，更激进一点的做法，可以同时调低显示分辨率。这一方式对于一些发热严重的手机及其有效
- 调整显示帧率不要通过Application.targetFrameRate来进行调整，而是通过Unity提供的OnDemandRendering接口的renderFrameInterval来调整，因为Application.targetFrameRate调整后会导致显示频率与输入频率一起下降，一些更新逻辑也会变慢，而OnDemandRendering接口只会调整显示频率，你的输入不会感觉到有任何延迟
- 三方库
- Wwise
- 目前很多移动平台游戏都会选择Wwise作为音乐解决方案，这套库本身就很重，后台回开启多个长度线程进行解码与异步操作，并且该库在默认设置下并不会控制多音源混合个数，当混合个数较多时，开销呈指数增长，对CPU压力较大，建议将混合的音源个数控制在4个以内，基本上可以满足绝大多数的移动游戏了
- CRIWARE
- 经常用到的处理视频的解决方案库
- 这是一个更恐怖的库，默认带CAk开头的线程都是它开启的，并且每个线程的开销都很高，而且一直很高，视频播放完负载也不会降低。一般情况下，同时只开启一个视频时，可能感受还好
- 总结
- 功耗和发热问题，不仅仅需要对游戏本身做常规优化，还要关注这些三方SDK，使用时，不要用无脑的默认设置进行集成，一定要看看有没有提供优化的设置或接口，否则这些三方库和SDK也会成为一个个耗电发热的小能手，最好分别做裸包与平台包的耗电量与发热测试