profiler分析报告疑问Material.SetPassUncached

接手别人的项目后发现卡顿明显，用Profiler进行性能分析,我用这个不多，有两个问题

Material.SetPassUncached在一帧内调了好几千次，这个方法是干什么的？怎么岀现的？如何减少出现？

第二张图中BaseEntry.FixedUpdate占21.7%它下面只有一个GC.alloc为什么只占1.7%

粒子太多了，试试暂时关掉场景中的所有粒子

Material.SetPassUncached 方法是用于将材质渲染到屏幕上的方法。它的调用次数过多可能是由于在屏幕上渲染过多的材质或者使用了大量的动态材质。为了减少这个问题的出现，可以尝试减少屏幕上的材质数量、使用静态材质或者使用更高效的算法来处理材质。

对于第二个问题，BaseEntry.FixedUpdate 占用了 21.7% 的 CPU，但是它下面只有一个 GC.alloc 占用了 1.7% 的 CPU。这可能是因为 BaseEntry.FixedUpdate 方法中包含了其他的计算或者逻辑，而不仅仅是 GC.alloc 方法。

Android Profiler 内存分析器中的泄漏检测

在内存分析器中分析堆转储时，可以过滤 Android Studio 认为可能表明应用中的 Activity 和 Fragment 实例存在内存泄漏的分析数据。

过滤器显示的数据类型包括：

已销毁但仍被引用的 Activity 实例。
没有有效的 FragmentManager 但仍被引用的 Fragment 实例。
在某些情况（如以下情况）下，过滤器可能会产生误报：

已创建 Fragment，但尚未使用它。
正在缓存 Fragment，但它不是 FragmentTransaction 的一部分。
如需使用此功能，请先捕获堆转储或将堆转储文件导入 Android Studio。如需显示可能泄漏内存的 Fragment 和 Activity，请勾选内存分析器的堆转储窗格中的 Activity/Fragment Leaks 复选框，

对内存进行性能剖析的技巧

使用内存分析器时，您应对应用代码施加压力并尝试强制内存泄漏。在应用中引发内存泄漏的一种方式是，先让其运行一段时间，然后再检查堆。泄漏在堆中可能逐渐汇聚到分配顶部。不过，泄漏越小，为了发现泄漏而需要运行应用的时间就越长。

您还可以通过以下某种方式触发内存泄漏：

在不同的 activity 状态下，先将设备从竖屏旋转为横屏，再将其旋转回来，这样反复旋转多次。旋转设备经常会使应用泄漏 Activity、Context 或 View 对象，因为系统会重新创建 Activity，而如果您的应用在其他地方保持对这些对象其中一个的引用，系统将无法对其进行垃圾回收。
在不同的 Activity 状态下，在您的应用与其他应用之间切换（导航到主屏幕，然后返回到您的应用）

Material.SetPassUncached是Unity材质(Material)类中一个方法,用于设置pass是否被缓存，你可以修改材质参数后启用一个标记，根据这个标记来决定是否修改材质，BaseEntry.FixedUpdate中GC.alloc占比小，查看是否还包含其他耗时更长的任务执行

Profiler使用不当会造成严重的性能问题，比如跟踪到的SQL语句太多，筛选条件设置不当。Material.SetPassUncached 的作用是设置一个未缓存的材质。通常在渲染管线的某个阶段被调用，例如在渲染对象的多个子对象时，可以使用不同的材质来渲染每个子对象。Material.SetPassUncached 是一个比较耗时的操作，因此在使用它时需要权衡渲染效率和性能。如果可以避免使用 Material.SetPassUncached，那么最好使用缓存材质的方式来提高渲染效率。

可以通过缓存材质的方式来提供效率，同时尽量避免使用Material.SetPassUncached方法，因为该方法非常耗时

可能是因为复杂物体的属性很多或者渲染次数非常频繁，这样就会导致大量频繁的材质属性上传，从而卡顿出现。减少出现的办法可以通过优化材质属性的设置，尽量减少频繁设置的属性。