踩坑问题：
将资源上传到服务器后，在 Remote.LoadPath 中设置了路径但是无法访问到资源 更改服务器上的资源，客户端加载还是上次的资源 构建缓存 开始研究的时候，比较绕这一部分内容，在我修改 Remote.LoadPath 后，直接启动或者打包项目会导致修改后的地址是没有生效的，需要在 Addressables Gruops 窗口中的 Builds -> Clear Build Cache -> all ，清除一下所有的构建缓存，之后就能够访问新的修改后的地址。
Build cache 会保存之前构建的中间结果和最终输出,包括编译后的脚本、处理后的资源等。这样在下次构建时，如果相关文件没有变化,就可以直接使用缓存的结果，而不需要重新处理。
HTTP 服务器 需要在服务器设置 http 服务以供 Unity 服务去访问服务器的资源，这里我简单使用 python 的 http server 简单开启一个 http 服务器。
在研究的过程中经常忘记要开启这个 http 服务器才能正常访问服务器的指定位置的资源。个人在这绕了好久(╯°□°）╯︵ ┻━┻
python 开启简易服务器的命令：python3 -m http.server 80
这里需要额外注意：
比如我实际放游戏资源的路径在 /root/DEV/UnityAddresableTest/StandaloneWindows64/ 目录下，启动 python 的 http 服务器时，这个目录就成为了服务器的根目录。因此，应该在 root（~）启动 python http 服务器，而不是实际的游戏存放资源文件夹启动。 在 Unity 中的 Project setting 设置为允许 http 访问（方便测试设置为 Always allowed）。 Addressables 的本地加载机制 上面提到的踩坑，即使关闭 http 服务器，也能加载物体，虽然可能不是服务器最新的，但是也能加载，这就稍微有点不符合逻辑，因为几乎所有的设置都设置成了从远端加载。...
性能优化问题的本质 慢与快的问题
前提
稳定性：不能因优化造成稳定性变差
兼容性：不能因优化导致兼容性变差
性价比：优化要有度，考虑成本与复杂度
性能优化的流程 发现问题（什么平台、什么操作系统、什么情况下出现问题，一般问题还是特例问题等） 定位问题（什么地方造成的性能问题，我们要用什么工具、什么方法确定瓶颈） 研究问题（确定用什么方案处理这个问题，要考虑性能优化的前提） 解决问题（按问题研究的结论去实际处理，并验证处理结果与预期的一致性） 影响性能的问题 CPU 通常，CPU 渲染时间的最大贡献者是向 GPU 发送渲染命令的成本。渲染命令包括绘制调用（绘制几何形状的命令），以及在绘制几何形状之前更改 GPU 上设置的命令
减少 Unity 渲染的对象数量 考虑减少场景中对象的总数，例如：使用 skybox 来创建遥远几何的效果 执行更严格的剔除，以便 Unity 绘制更少的对象。考虑使用遮挡剔除来防止 Unity 绘制隐藏在其他物体后面的物体，减少相机的远夹平面，以便更远的物体落在其果实之外，或者，对于更细粒度的方法，将物体放入单独的层，并使用 Camera.layerCullDistances 设置每层剔除距离 减少 Unity 渲染每个对象的次数 在适当的情况下，使用 light mapping 来烘焙（预计算）照明和阴影。这增加了构建时间、运行时内存使用和存储空间，但可以提高运行时性能 如果应用程序使用 Forward rendering，请减少影响对象的每像素实时灯光的数量 实时阴影可能是非常资源密集型，因此请谨慎而高效地使用它们 如果应用程序使用反射探针，请确保您优化其使用 GPU 填充率的限制 GPU 试图每帧绘制的像素比它所能处理的要多，如果是这种情况，请考虑以下选项：
识别并减少应用程序中的透支。透支最常见的贡献者是重叠的透明元素，如 UI、粒子和 Sprite，在 Unity 编辑器中，使用 Overdraw Draw模式 来识别有问题的区域 降低片段着色器的执行成本 如果您使用的是 Unity 的内置着色器，请从 Mobile 或 Unlit 类别中选择一个。它们也适用于非移动平台，但它们是更复杂的着色器的简化和近似版本 动态分辨率是一个 Unity 功能，允许您动态缩放单个渲染目标 内存带宽的限制 GPU 正在尝试向其专用内存读取和写入比它在帧中可以处理的更多数据。这通常意味着有太多的纹理，或者纹理太大。如果是这种情况，请考虑以下选项：...
静态优化 Import Unity 工程目录结构及用途 Asset 这是存储所有游戏资源的文件夹，包括脚本、纹理、声音和自定义编辑器脚本。文件夹的组织可能因项目而异，因组织而异。资产文件夹中可以有许多子文件夹，具体取决于项目的组织方式。例如，可能有一个用于场景的文件夹，一个用于脚本，一个用于音频，或者一个用于 Sprite，组织有多深是没有限制的
{% note primary %}
Unity 在 Assets 文件夹下保留了几个特殊文件夹名称。这些文件夹是编辑器、编辑器默认资源、Gizmos、资源、标准资产和流资产，并非每个项目都有所有这些文件夹
Assets / Editor：此文件夹用于扩展 Unity 编辑器功能的自定义编辑器脚本。这些脚本将在编辑器中运行，但在运行时不会在项目中运行。资产文件夹中可以存在多个编辑器文件夹，编辑器脚本的执行方式因编辑器文件在文件夹结构中的位置而异。
Assets / Editor Default Resources： 这是存储编辑器脚本使用的资产文件的地方。只能有一个这样的文件夹，它必须放在资产文件夹根目录中，此文件夹中可能有子文件夹
Assets / Gizmos： Gizmos 是场景视图中的图形，可以帮助可视化设计细节。此文件夹存储用于小发明的图像，只能有一个文件夹，它必须放在资产文件夹根目录中
Assets / Resources：此文件夹存储资源，以便在 Unity 项目中按需加载。可以有多个资源文件夹。按需加载有助于动态加载在设计期间没有设计师创建的实例的游戏对象。换句话说，这些资源在设计时可能没有在场景中放置相应的游戏对象，并在运行时动态加载，但现在都使用 Assets Bundle 构建
Assets / Standard Assets ：此文件夹存储已导入项目的任何标准资产包。脚本编译优先级最高，只能有一个标准资产文件夹。标准资产是由 Unity 维护的免费资产
Assets / Streaming Assets ： 此文件夹用于保留其原始格式的资产，然后流式传输到 Unity 应用程序中，而不是直接将其纳入项目的构建中。一个例子是来自文件系统的视频文件。项目中只能有 1 个流媒体资产文件夹
{% endnote %}
Library 用来存储项目内部资产数据信息的目录，即 Unity 用于导入资产的本地缓存。它可以被删除，并将由 Unity 自动重新生成，重新创建文件夹所需的只是 Assets 文件夹 和 .meta 文件。如果此文件夹被删除，Unity 将重新导入所有资产，并在下次在编辑器中打开项目时重新生成文件夹。此文件夹不应包含在版本控制中，Unity 使用这些导入的资产来节省 Unity 运行时的时间...
前言 观看 bilibili @Metaverse大衍神君 视频记录笔记，是本来作者留下的笔记经整理也有自己不太懂的地方扩展延伸，如有错误还请海涵指正！
环境搭建 使用如下命令拉起测试项目并使用 Unity 打开
git clone https://github.com/lwwhb/Unity2022_SUNTAIL_Stylized_Fantasy_Village_Optimization 个人使用的 2022.1.16 版本打开，会出现一个 com.unity.render-pipelines.universal 的包错误，个人解决方案是在 PackageManage 里删除这个包后，Unity 会自动提示升级材质，点击后会自动安装新版的 URP 包，也会自动配置好渲染管线
{% note warning%} 注意这里我将项目设置为了 URP（SRP） 渲染管线会导致下面无法查看场景 Mipmap 选项，在视频教程中的内置渲染管线（built-in）可以查看 {% endnote %}
打开项目的 Autoconnect Profiler 并在场景加入 DebugCanvas 方便移动设备的调试
关闭移动平台的 VSync Count 选项，以发挥最大性能
{% note primary %}
VSync Count：每帧之间应传递的垂直同步数量 Unity 通过将平台的默认目标帧速率除以 VSyncCount 的值来计算目标帧速率
{% endnote %}
未优化时的性能指标 生成的 Android APK大小 550M 三角形平均面熟 150-200 万，峰值 230 万 渲染批次 1500-1800 次 SetPassCall 200 次以上 小米11 ultra平均 FPS :10 FPS，iPhone XS Max 15FPS 内存 小米 11 ultra 1....
NodeCanvas 使用方法指北 推荐查看 官方文档 了解全部详情
引用我之前写过的操作文章 bilibili跳转 、csdn跳转