渲染大面积草地时，如何下降消耗？

1）在渲染大面积草地时，如何下降消耗
2）使用LoadFromMemory致使内存翻倍问题
3）对Android x86平台的支持问题
4）OnGUI的堆内存分配问题

---

Rendering

Q：请问下你们，渲染大面积草地时，如何下降消耗呢？

A1：回答以下：
1.使用DrawMeshInstance；
2.上面这个API是不会进行视距剔除、视锥体剔除和遮挡剔除的。

下面有两种方案：
a.将草地按区域分组，用每组的中心点计算视距，依据距离切换网格LOD或剔除；还能用向量点乘简单剔除在相机后方的草地（注意临界问题）。
b.借助CullingGroup。
CullingGroup.onStateChanged事件绑定，经过事件触发调整传入；DrawMeshInstanced的Matrix顺序和渲染数量（可是DrawMeshInstanced只能指定渲染前几个Matrix）；
经过cullingGroup.SetBoundingSpheres实现视锥体剔除和遮挡剔除；
经过cullingGroup.SetBoundingDistances实现视距剔除和LOD。
这个方案最好也进行区域分组，否则CullingGroup的事件监听占用会比较高，在中端机上4000个监听会占约2ms的大小。

之后若是有对比两种方案的性能，我再进行补充。

附：

1. 《CullingGroup API的使用说明》
2. 《Unity 3D研究院之Lightmap支持GPU Instancing》
3. 《如何高效使用GPU Instancing技术来进行草丛渲染》
4. 升级Unity 2018，DrawMeshInstanced不生效的问题

感谢题主李先生@UWA问答社区提供了回答

A2：使用Indirect模式的Instancing，配合Compute Shader实现视锥剔除和遮挡剔除。

感谢邹春毅@UWA问答社区提供了回答

---

AssetBundle

Q：UWA的几篇文章中都有说到尽可能不要用AssetBundle.LoadFromMemroy接口，由于这个接口会使得内存的占用翻倍，可是我用Unity 2017.4.5f1进行测试后，发现AssetBundle.LoadFromMemroy和AssetBundle.LoadFromFile几乎是没有差异的，由于文章中也没有关于体积具体的版本信息。因此我想问是以前的Unity 4.x或者Unity 5.x版本才有这个问题？仍是说测试用例是有要求的呢？

另外，我是在PC上进行测试的，打包出exe，直接用任务管理器查看内存占用状况，发现并无区别。

A1：应该是在C++里面直接申请一块内存用来解压，Mono占用不会变可是PSS会增大，内存峰值也会变高，使用adb shell dumpsys meminfo packageName来查看PSS。

若是目标平台是PC，那就说明内存策略多是分配后当即归还给操做系统了。若是PC不是目标平台，那么看内存就没有很大的意义。
感谢张迪@UWA问答社区提供了回答

A2：LoadFromMemroy输入的byte数组用的是Mono堆内存，哪怕这个内存有释放，但Mono堆内存总量是只升不降的，在加载资源的过程当中，一旦Mono触发GC后仍内存不够，极可能须要申请新的Mono内存，这会致使Mono内存持续升高。

并且用LoadFromMemroy没有必要性，用这个接口哪怕内存不是问题，也会在加载资源时明显比LoadFromFile慢很多，并且真的想要逆向AssetBundle资源仍是很容易的。退一步说，非要加密建议使用LoadFromStream，而后本身去实现Stream解密。
感谢loy_liu@UWA问答社区提供了回答

A3: 我以前的测试有问题，如今更正一下：LoadFromMemroy即便在PC平台也不如LoadFromFile接口。

经测试，PC上LoadFromMemroy接口内存的占用大概会高1/5左右，加载时间比LoadFromFile接口慢1/5左右，并且如loy_liu所说，LoadFromMemroy接口须要先读取byte数组，会产生Mono内存的分配问题，而LoadFromFile不会。在Android平台上，内存的对比很是夸张，我这边测试的数据翻了接近3倍。

因此尽可能不要使用LoadFromMemroy接口，我没有去测试LoadFromStream接口的性能和内存，但听说和LoadFromFile差很少。
感谢题主fdy@UWA问答社区提供了回答

A4: Lzma的资源包LoadFromMemory会致使资源自己翻倍。L4z资源包相似于管理器，自己占用内存很小，翻倍也不要紧，而内存流自己也是用完就能扔。

感谢欧月松@UWA问答社区提供了回答

---

Build

Q：目前项目发布后大于100MB，检查发现是libil2cpp.so较大，大概大于60MB，并且同时支持了ARMv七、ARM6四、x86，至关于x3的大小。因此想问一问你们，目前x86架构的机型大概占比多少？须要继续支持吗？

A1: 不必，我建议去掉。
感谢loy_liu@UWA问答社区提供了回答

A2: 大多数模拟器都是X86，能够考虑下。
感谢欧月松@UWA问答社区提供了回答

A3: 须要支持，不然模拟器会很卡。

感谢Fly@UWA问答社区提供了回答

---

Memory

Q：在PC上运行游戏，用Profile工具检测的时候，发现GUIUtility.BeginGUI内存泄漏，每次调用产生0.8KB的内存消耗，每帧调用4次，就是3.2KB。请问这是什么缘由引发的呢？

A：OnGUI必然有GC Alloc，即便是空函数。你能够拿宏括起来，用来作Profiling的包不要编译进去。

感谢littlesome@UWA问答社区提供了回答

---

今天的分享就到这里。固然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题也许都只是冰山一角，咱们早已在UWA问答网站上准备了更多的技术话题等你一块儿来探索和分享。欢迎热爱进步的你加入，也许你的方法恰能解别人的燃眉之急；而他山之“石”，也能攻你之“玉”。

官网：www.uwa4d.com
官方技术博客：blog.uwa4d.com
官方问答社区：answer.uwa4d.com
UWA学堂：edu.uwa4d.com 官方技术QQ群：793972859（原群已满员）