性能优化学习记录

----2021.10.27
–项目优化如果没做好，会导致应用运行起来不流畅，掉帧，体验差。所以项目优化也是比较需要学习的点。

–分析工具：
–针对安卓：Snapdragon Profiler
–针对IOS:Instruments 和 XCode Frame Debugger

–关于性能分析–， 分启动时、运行时、解析脚本、资源加载四个方面的消耗。

–启动耗时 分析：
–启动时函数1：如果UnityInitApplicationGraphics耗时长，表示Resources文件夹中文件数量过多。因为此方法在初始化会加载所有资源文件的索引。
–启动时函数2：如果UnitLoadApplication耗时过长，意味着在项目的第一个场景中的Awake回调中存在执行过长的代码。需要去掉或转移到其他生命周期位置进行调用。

–运行时耗时 分析：
–运行时函数：“PlayerLoop”函数， 每帧会调用一次。
–PlayerRender:是运行Unity渲染系统的方法。包括了剔除对象、计算动态批次、向GPU提交绘制指令。 当项目进行交互时，此方法对CPU的消耗最大。
–CommonUpdate过高:主要是Update函数中运算量过多导致

–UI::CanvasManager过高， 主要是Unity UI 的批量计算和布局更新导致。
–DelayedCallManager::Update过高， 协程相关
–FixedUpdate ： 物理计算与检测相关，如刚体与碰撞体

–解析脚本方法耗时 分析：
–ScriptingInvocation 过高， 此将Unity原生代码转为脚本运行时可执行代码。
–其中的RuntimeInvoker_Void ：为每帧执行一次的交叉编译的C#脚本的一部分。
–展开可看到EventSystem.Update、PlayerShooting.Update 和其他几个 Update 方法，方法名非常易读，可直接根据耗时长度，判读哪个方法回调耗时过多。

–StandaloneInputModule.Process：逐帧对整个 UI 进行射线投射判断， 主要消耗是迭代测试鼠标的位置是否在UI 元素的边界矩形内。

–资源加载消耗 分析：
–主要方法： SerializedFile::ReadObject， 将二进制数据流（从文件）通过运行名为 Transfer 的方法连接到 Unity 的序列化系统中。

–如果SerializedFile::ReadObject消耗过大， 是资源加载耗时过长导致。 可改为异步加载，或预加载的方式。
–在通过 SceneManager、Resources 或 AssetBundle API 来请求同步的资源加载时，才能在主线程上找到 SerializedFile::ReadObject。
–加载场景文件时，Unity会读取并反序列化场景中的所有资源。 此函数也会调到Transfer。