图片资源尺寸
ETC1、ETC2以及ASTC 4X4 要求图片宽和高可以不相等但是必须被4整除，例如512X1024 4X16
IOS的PVRTC压缩格式要求图片的宽高必须相等并且是2的整数次幂，例如512X512，如果是512X1024那么就无法压缩了
另外ETC2和ASTC 对硬件也有一些限制，ETC2只支持OpenGL ES 3.0以上的Android手机（大概2013年以后的手机都支持）ASTC只支持苹果A8以后的设备，iPhone 6 及以上的手机（大概2014年以后的手机都支持）。今天已经2019年了，我个人觉得没必要为了支持这些4、5 年以前的设备让开发变得非常麻烦。
宽高任意一边超过256的图片最好不要打进图集，容易拉大图集 反而加载会慢
界面分析工具
依赖工具插件 对界面和资源进行分析，获得优化方向
我坚信以上的对话在大多数项目组都存在，所以说我们还是需要一个UI界面的静态分析工具。
1、界面使用了多少张图集。
2、界面使用了多少张图片（图集以外的图，一般是特效或者别的对象依赖的）。
3、界面中隐藏游戏对象的数量。
不光是这个分析 ，还可以通过Prefab 来分析里面依赖的资源图片，通过MD5来确定使用使用的相同的图片，不过也有局限，很容易几乎相同的图片，美术小改动然后给到程序。这是一个坑
动态文件 outline 等注意 增加顶点数
界面变换 元素更新
界面 还是要 重视Pool的使用 尤其背包等。
UGUI 避免 频繁 setactive 控制 透明度Alpha Grouo=0 ，或者用scale=0；
setactive 是同一帧 大量的激活物体有开销，正常使用还是好
DrawCall
UGUI的 合并规则要注意 和图集相关 和元素的重叠（不规则图片），3D UI
深度z值 !=0
UI元素移到屏幕外 DrawCall的变化影响 要验证
UGUI 刷新界面 以canvas 为单位
UGUI 图集分离 （会自动把图集分多张）根据图片格式如 alpha，ect2等
界面的渲染开销点
Profiling
** DrawCall**
Mesh.CreateVBO (网格的更新)
OverDraw
UGUI 对元素的Position赋值，不论是不是数值真的改变 会导致 Canvas.buildBatch
注意的性能指标 --- Canvas.SendWillRenderCanvas
-m_LayoutRebuildQueue
-m_GraphicRebuildQueue
Canvas.BuildBatch 更新所以drawcall
---WaitingForJob
---PutGeometryJobFence
---BatchRenderer.Flush *
worldspace 替换 WorldToScreenPoint 主角单独Canvas/UIPanel
一篇很不错的优化总结 ，主要是数Shader来替换一下频繁变化重建的区域。如走UV等
优化UI
