性能
gpu Instancing
在低端机型表现
实验：900个相同球体 50半透明材质球
enable:红米4x drawcall 下降100，时间上升3倍
drawMeshInsanced drawcall 下降十倍，时间下降
结论：
instanced drawcall 有额外开销
- Batch.FillInstanceProperties
半透明
- Material.enableInsatancing 需关注排序（Unity本身严格根据深度来排序，会造成穿插）
- 用drawMeshInsanced 耗时更低，需要关注dc和overdraw
不透明
- 推荐Material.enableInsatancing
CommandBuffer
官方文档： https://docs.unity3d.com/Manual/GraphicsCommandBuffers.html
限制: 无Batching
用途：自定义渲染
实验：900球 50半透明
红米4\小米5S
drawing -10% culling -75%
不透明
5s
drawing + culling +
原因：setpass call 增加
unity本身对材质排序?
一旦用了commandbuffer setpass call必然不会被优化
相同材质的连续提交不会合并 setpass call
post processing stack v2
pc较多，移动较少
bloom optimized (hidden/fastbloom)
ppsv2-bloom
fastmode
diffusion 慎重
ppsv2-uber
frag复杂度?
DEFERRED RENDERING
用途： AAA效果
限制 gpu压力
forward 三角20W 无压力
换deferred
红米4X
forward 30fps
deferred 20fps
小米5S
forward 30
defer 30
gpu busy 18.8% vs 24.3%
gpu 频率 Max 624MHz 223MHz vs 423MHz
（利用率并没有提高，所以不会明显发热，但会耗电）
渲染
Drawcall
Mask
Mask 底下是Stencil材质 不能合并
看不到的东西依然参与排序
解决思路：让Mask区域独立计算Depth
挂Canvas! = -这TM都行
RectMask
Rect MAsk 2D
- 节省dc overdraw
- 增加cull (SendWill)
- 持续开销较低
- 拖动时开销较高
- 根据实际情况 权衡
重建
Rebuild
Canvas.SendWillRenderCanvases
OUtline Tiledsprite
问题：持续重建
减少逐帧更新的元素
Rebatch
动静分离
异常情况
Canvas.SendWillRenderCanvases中有
vh.Clear() (数组的capacity不降，使得clear耗时很长)
2018已无问题? 其实是.net 4.5才无问题
100个Image修改alpha值？
……过了 todo 待更新
位置同步？
UGUIrendering.updateBatches
48% Canvas.SendWill
43% CanvasRender.SyncXXX self
100Image 不移动 vs 移动
总之少移动
过滤1.25屏
JobSystem 2018.2才有
适用：
主线程中复杂逻辑
高频调用
- 子线程开销总和 高于 主线程
- Schedule complete 时机 ??
内存优化
资源设置
纹理
- 分辨率
- 格式
- Read/Write
- Mipmap
- Texture Streaming ?
网格
- 顶点数量
- 顶点属性数量 ？
- Read/Write
- Mesh Compression
动画片段
- 片段数量
- 压缩模式/动画精度 ？
- 动画模式 Humanoid?
音频片段
- 音频数据量
- 加载方式
资源加载
同步vs异步
同步：快
异步：较快，平滑
未处理前，AB：12.9M， 内存42M，小米Mix2
292ms vs 851ms
优化后： 313.8ms ?
Async upload pipeline ?
- 异步加载 Texture&Mesh
- 通过渲染线程直接传到gpu
- 2018.3才支持到 Texture&Mesh
设置
加大Upload Buffer 增加传输数据
默认4M -> 16M
加大Upload Time Slice 加快传输速度
默认4ms -> 8ms
注意点
- 加大Upload Buffer会增加一个恒定内容，除此之外无副作用，可设置成16、32M
- Time Slice需要控制，太大会带来卡顿 (?看下原理)，合理则帧率更平滑
- 场景切换时可将time slice调高（8-16ms)，一般运行时调低（2-4ms)
BackgroundLoadingPriority
控制异步加载资源在主线程的“后加载”耗时 (?)
- 各种资源的AwakeFromLoad
- Shader.Parse
不同分档
- ThreadPriority.Low - 2ms
- ThreadPriority.BelowLow - 4ms √
- ThreadPriority.Normal - 10ms
- ThreadPriority.Low - 50ms
总结
- 调整Upload Buffer和Upload Time Slice
- 调整BackgroundLoadingPriority
- 开启多线程渲染
- 调整资源的加载顺序（比如shader) (?)
异步的不当操作
- 较大量开启RW的Texture (todo: 查下rw代表什么)
- AB异步加载
- 每帧加载数量
- 注意BackgroundLoadingPriority (？跟AB有什么关系)
- 关注实例化耗时 (?)
- 关注实例化顺序 （在某些情况 实例化A，A依赖B，B还未加载）
资源内存
纹理
memory budget、max level reduction (?)
在Memory Budget足够时
- Scene Texture 是满Mipmap加载(?)
- 动态加载的Go Texture是最低配Mipmap进行加载和实例化
- 渲染时，按照距离远近和Budget进行调整
在Memory Budget不够时 - Scene Texture 按最低配加载，已加载Streamed Texture按照距离Remove Mipmap，越远的越先Remove高Level Mipmap
- 动态加载的Go Texture只按最低配Mipmap进行加载、实例化、渲染
注意 - Mobile端: QualitySettings.streamingMipmapsActive=true
- 对于升级项目注意，会让纹理变糊
音频片段
加载方式：
- Streaming加载方式适合背景音乐
- 同时播放的小音频文件，Decompressed方式
srp
官网
https://blogs.unity3d.com/2019/02/28/srp-batcher-speed-up-your-rendering
框架
lwrp
hdrp
lwrp&hdrp
- built-in shaders srp不支持
- 自带shaders
- ?
lwrp
关注性能
单pass forward
1 Directional
不支持SH
real time shadow不支持Point
[Batching]
static bath
不支持dynamic batch
color space linear
gi enligthen realtime 不支持
shader 支持 shadergraph
[postProcessing]部分支持pps 不支持motion blur
UI 某个模式不支持
存在频繁GC开销
hdrp
the heretics 视频
关注画面 渲染工具丰富
Render loop
prepare -> depth ->DBuffer -> GBuffer -> SSR/SSAO volumetric shadow
-> deffered-\
| ↓ SSSS -> Post-processing
->forward -/
Selection
Built-in
- 高 Asset store 依赖
- 快速原型
- 进行中
LWRP
中、低性能\易拓展\支持shader graph
SRP
追求画面