[实践通才]-Unity性能优化之Drawcalls入门
Drawcall到底什么
CPU做渲染肯定要，而每一个Drawcall要做很多前提工作，所以减少了Drawcall等于减少了CPU工作量，从而提升了游戏流畅度
（这个逻辑。。。。网上都这么传。。。。但其实是很有有问题的，我游戏Drawcall很大，但是要是我的CPU性能够，只要游戏需要的性能不超出游戏的所需要的性能，那么游戏还是很流畅的。减少Drawcall是否那么必要?）
Drawcall对游戏的实际影响
以下所有实践都是基于这个“运行时DEBUG”
实践一：Drawcall是动态变化的
Unity本身已经提供了大量运行时Debug的工具， 基于Unity5.6
例如。右上的Stats面板可以看到Drawcalls, 据说Unity5.x将Drawcalls改成Batches
运行过程中，点击按钮，Batches会动态变化
实践结论:
实践二：Drawcall达到多少才会达到游戏卡顿感
方法很粗暴，直接克隆GameObject
直接上5W个，FPS马上掉到10
试试1W个？基本上达到30FPS
Verts，顶点个数由10几K -> 接近20M ，而Profiler虽然有峰值，基本上认为它是能达到30FPS，这时候可能马上有人跳出来说，峰值那么多0FPS都有，怎么是30FPS呢，至于1个测温计如何测量温度，随机抽样，插值法等等高深测量方法不在这里讨论，
有一个比较科学的观点是：测量方法是有很多种，有很多被一些人做科学依旧拿去用了，而正在被创造出来的测量方法也不少，
这里仅仅只是用了Unity 的Stats面板和Profiler这2个工具做了一些实践，然后告诉你结果
上面只是前菜，真正的实践才开始
实践2-1，跳到第二个地方（同一个场景）
*Draw Calls明显减少，摄影机视觉范围内没有了刚才爆测的GameObject
*但其实还有峰值，这明显也是刚才的爆测造成的，虽然已经没有了Drawcalls，这是不是可以证明GameObject对象多了，就算不是Drawcalls也可能会造成卡顿，
实践2-2，跳到第三个地方（同一场景）
*DrawCall回来了，FPS明显又掉了
实践2-3：重新跳回游戏开始第一个地方
*Drawcalls还是很大，那是因为树后面就是刚才爆测的GameObject ,所以好像你看不到，但其实摄影机看得到，而你又不确认摄影机什么时候能看到，所以网上那种优化说摄影机看不到的场景全去掉的解决方案，这种方案真得具体问题具体分析，一般是真解决不了你项目组的游戏优化
*Drawcalls优化的方法，百度能查到一大堆，就不在这里详细说了，这里真的只是做实践
Siki老师的视频试看
看了真的觉得还不错，虽然了老师可能不是故意的，有人也说很简单，但确实通过视频带大家实践了一遍，讲了Drawcalls 基本，Stats统计面板, Profiler工具等
CPU做渲染肯定要，而每一个Drawcall要做很多前提工作，所以减少了Drawcall等于减少了CPU工作量，从而提升了游戏流畅度
（这个逻辑。。。。网上都这么传。。。。但其实是很有有问题的，我游戏Drawcall很大，但是要是我的CPU性能够，只要游戏需要的性能不超出游戏的所需要的性能，那么游戏还是很流畅的。减少Drawcall是否那么必要?）
Drawcall对游戏的实际影响
以下所有实践都是基于这个“运行时DEBUG”
实践一：Drawcall是动态变化的
Unity本身已经提供了大量运行时Debug的工具， 基于Unity5.6
例如。右上的Stats面板可以看到Drawcalls, 据说Unity5.x将Drawcalls改成Batches
运行过程中，点击按钮，Batches会动态变化
实践结论:
*移动过程中，Drawcalls会达到峰值，如果玩家不操作摇杆，固定在一个画面，其实Drawcalls会达到一个固定值
*没运行时，也可以增加Drawcalls，运行后Drawcalls不见了，后来发现是静态对象，Static的是否勾选影响Drawcalls的多少
*参考的是网上的一个视频，却用的不是网上的示例，其实用自己的素材代码测试的理论其实相同，这种实践类源码用标准的示例其实也没什么作用
*所有的实践目前只是在Pc Editor上测试（选了Android平台），但并不真实代表Android 或者IOS真机的情况
实践二：Drawcall达到多少才会达到游戏卡顿感
方法很粗暴，直接克隆GameObject
直接上5W个，FPS马上掉到10
试试1W个？基本上达到30FPS
Verts，顶点个数由10几K -> 接近20M ，而Profiler虽然有峰值，基本上认为它是能达到30FPS，这时候可能马上有人跳出来说，峰值那么多0FPS都有，怎么是30FPS呢，至于1个测温计如何测量温度，随机抽样，插值法等等高深测量方法不在这里讨论，
有一个比较科学的观点是：测量方法是有很多种，有很多被一些人做科学依旧拿去用了，而正在被创造出来的测量方法也不少，
这里仅仅只是用了Unity 的Stats面板和Profiler这2个工具做了一些实践，然后告诉你结果
上面只是前菜，真正的实践才开始
实践2-1，跳到第二个地方（同一个场景）
*Draw Calls明显减少，摄影机视觉范围内没有了刚才爆测的GameObject
*但其实还有峰值，这明显也是刚才的爆测造成的，虽然已经没有了Drawcalls，这是不是可以证明GameObject对象多了，就算不是Drawcalls也可能会造成卡顿，
实践2-2，跳到第三个地方（同一场景）
*DrawCall回来了，FPS明显又掉了
实践2-3：重新跳回游戏开始第一个地方
*Drawcalls还是很大，那是因为树后面就是刚才爆测的GameObject ,所以好像你看不到，但其实摄影机看得到，而你又不确认摄影机什么时候能看到，所以网上那种优化说摄影机看不到的场景全去掉的解决方案，这种方案真得具体问题具体分析，一般是真解决不了你项目组的游戏优化
*Drawcalls优化的方法，百度能查到一大堆，就不在这里详细说了，这里真的只是做实践
Siki老师的视频试看
看了真的觉得还不错，虽然了老师可能不是故意的，有人也说很简单，但确实通过视频带大家实践了一遍，讲了Drawcalls 基本，Stats统计面板, Profiler工具等
*明天再继续实践其他的优化
*其实我这个博文，又或者知乎和其他的一些媒体，图片有点大，不但看客Load图麻烦，我自己上传也慢，但我明知道却没有优化的，其实没优化，地球还不是照样转，并不是像大家鼓吹不需要绿化，但只是想说嘴上说的容易，至于大家心里怎么想的，而且又有多少人愿意花时间去实践？