1）Instruments如何看Mono内存分配
2）关于Addressable v1.11.2的疑问
3）展开UV2时致使Mesh顶点数增长
4）提高Unity编辑器中代码的编译速度
5）Renderdoc调试的疑问html
这是第217篇UWA技术知识分享的推送。今天咱们继续为你们精选了若干和开发、优化相关的问题，建议阅读时间10分钟，认真读完必有收获。数组
UWA 问答社区：answer.uwa4d.com
UWA QQ群2：793972859（原群已满员）app
Memory
Q：例如在分配了一个10MB数组，对应在Unity Profiler中会看到开辟了至少10MB大小的Mono内存。编辑器
那么在Instruments中，如何查看分配的内存信息呢？Allocations中的信息是此进程中分配的全部内存信息吗，尝试分配过100MB内存，Allocations中的统计没有任何增加。ide
A：我这边也作了测试：工具
建立了100MB大小的int数组，Size实际应该是400MB。
而后到Profile观察：测试
能够看到ManagedHeap正确分配了这400MB的空间。
而后打包iOS后到Xcode运行，运行前首先把Run这个Scheme的Malloc Stack勾上。优化
RUN之后点选Memory并导出Memory Graph来观察：
因为应用程序的内存都是在VirtualMemory空间分配的，所以查看VM Regions的VM_ALLOCATE部分。
能够发现128X3+16恰好400MB的分配。
调用堆栈也很好肯定：网站
正是咱们的测试代码。
而后咱们来看Instruments。首先是Allocations部分，有一点要注意，该栏的下部有一些选项：ui
注意最后一个选项，若是选择第一个：
All Heap & Anonymous VM，All Heap对应App实际分配的物理空间，不包含VM，Anonymous VM的官方解释是：
interesting VM regions such as graphics- and Core Data-related. Hides mapped files, dylibs, and some large reserved VM regions。
所以一些比较大的预留分配空间是不会显示的。
将这个选项切换为All VM Regions，就能看到分配的400M了：
而且右边详情页面也正确显示了调用堆栈：
另外，咱们还能够从VM Tracker来观察。打开VMTracker的Snapshots：
就能看到这400MB的详细分配信息：
能够发现，Virutal Size略大于400MB，由于程序其余部分也要申请一些内存。而这400MB又分别保存在Resident和Swapped内，其中Resident部分又基本等于Dirty Size，说明这部分大小的空间被标记了Dirty是不能被交换出去的，剩下240MB左右空间是Clean空间，能够暂时被交换出去以保证有足够的物理空间能使用。这也是由于咱们只是申请了这部分空间，并无进行具体的赋值初始化和使用。
那若是赋值使用了呢？修改代码测试
运行Instruments后再观察：
能够清楚的发现这400MB都在Dirty Size内。这种状况真正会给该App和iOS之内存压力。
推荐阅读：
《写给Unity开发者的iOS内存调试指南》
感谢黄程@UWA问答社区提供了回答
Addressable
Q：关于Addressable v1.11.2开始编辑器在“Fast Mode”模式下运行会获取SubAsset失败的问题。
A：今天将项目使用Addressables系统从1.8.4升级到1.14.2。忽然发现AssetReference指向的资源进行实例化老是报Key无效的错误。调查后发现从1.11.2开始，为了给FastMode进一步加速，官方修改了流程。
以前版本即便是Fast Mode下，也是要进行一次Build，而且Play时读取Build出来的Catalog，Catalog会序列化全部的AssetEntry和SubAsset，生成ResourceLocationMap对象而后进行检索。咱们使用了很多AssetReference来指向SubAsset使用。这时使用没有问题。
1.11.2版本开始，Fast Mode直接提供编辑器环境下AddressableAssetSettings对象的GUID而非Catalog文件路径，所以Play后初始化时则会启用FastMode专用的初始化操做FastModeInitializationOperation，这时生成的不是ResourceLocationMap，而是AddressableAssetSettingsLocator，这个Locator只是遍历了编辑器Group窗口对应可见的Group内的AssetEntry，而AssetEntry内部的SubAsset则不会被遍历到，所以若是游戏中用到SubAsset，就会报Key无效的错误。
官方Changelog：
Refactored Play Mode Script for "Use Asset Database" to pull data directly from the settings. This reduces the time needed to enter play mode.建议：
- 暂时只使用v1.8.4版本（经项目长期使用，相对较为稳定）
- 不建议使用1.9.2到1.11.2期间版本，还有其余bug
- 升级到最新的状况下，使用Simulate Groups模式进行开发
- 等待官方后续改进
感谢题主黄程@UWA问答社区提供了回答
Rendering
Q：在Unity中自动展开UV2（Generate Lightmap UVs），会形成个别物体的Mesh中顶点个数增长。
我自动展开的一个地面，顶点数从134变成136，若是不展开UV2，是没有问题的。请问，有什么办法能够在展开UV2时，不增长顶点个数吗？
在导入FBX模型时，没有勾选优化Mesh和其余影响顶点的一些选项。
A：由于有时候2个面片对应到Lightmap上2个不连续区域，而这两个面片上的顶点可能共享，所以须要拆开成2个顶点，其余数据一致，可是UV2不一样。属于正常现象。
想要不增长，除非美术手动设置UV2并导出，即使如此，若是模型在一些面是包围闭合的，也很难保证顶点不重复。其实这个时候是顶点在Maya等工具内已经作了增长后导出。Unity内可能看不出变化。
感谢黄程@UWA问答社区提供了回答
Build
Q：有没有什么办法能够提高Unity编辑器中代码的编译速度？咱们如今每修改一次代码，等待的编译时间都将近半分钟。
A1：对于大型项目来讲，这确实是你们常常遇到的状况。通常来讲，Unity Editor会按照脚本的依赖关系编译代码，其主要分为如下四个步骤：
- 编译Standard Assets、Pro Standard Assets和Plugins文件夹中的Runtime Script；
- 编译以上三个文件夹中Editor文件夹下的Script；
- 编译项目中全部剩余的Runtime Script（Editor文件夹之外Script）；
- 编译剩余Script（即Editor文件夹中Script）。
知道了Unity编辑器的脚本编译特性后，咱们则建议研发团队能够将一些长时间不须要改动的脚本代码（好比各类插件代码）放入到Standard Assets、Pro Standard Assets或Plugins文件夹中，这样这些代码只须要编译一次，后续的时间就都能节省下来。
有朋友作过测试，在他们的项目中通过上面的改动，原来项目每次的编译时间从23s降低到7s。想一想看，这将节省你和你的团队多少时间！
推荐插件：Mad Compile Time Optimizer
推荐阅读：《优化Unity项目编译速度》
感谢题主Jessica@UWA问答社区提供了回答
A2：添加程序集定义：
https://docs.unity.cn/cn/2020.2/Manual/ScriptCompilationAssemblyDefinitionFiles.html
感谢wangzuxiong@UWA问答社区提供了回答
A3：拆分工程编译成不一样的DLL，Unity 2017后可使用引擎自带的工具定义成不一样的工程。
感谢mrchen@UWA问答社区提供了回答
Rendering
Q：Pixel Context是灰的：
Debug Vertex也是灰色的：
这是为何呢？
A1：像素调试的Shader里加#pragma enable_d3d11_debug_symbols。
感谢燃野@UWA问答社区提供了回答
A2：官方文档说有说明，只能在D3D11或者D3D12中进行调试：
https://renderdoc.org/docs/how/how_debug_shader.html#hlsl-debugging
感谢Xuan@UWA问答社区提供了回答
今天的分享就到这里。固然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题也许都只是冰山一角，咱们早已在UWA问答网站上准备了更多的技术话题等你一块儿来探索和分享。欢迎热爱进步的你加入，也许你的方法恰能解别人的燃眉之急；而他山之“石”，也能攻你之“玉”。
官方技术QQ群：793972859（原群已满员）