UGUI-图文混排方案

1、TextMeshPro
组件直接支持定义emoji和图文混排
优点：
TMP字体的优点（文字干净，渲染效果不受分辨率影响，描边、外发光等文字效果容易实现且性能很好）
不用单独开发，简单易用
缺点：
TMP字体的缺点（离线生成，字符限制，圆角）
目前还有不能支持动画（帧动画和Animation），也不太容易扩展
现在的版本生成的字体库实在太大了，比较全的汉字字库生成TextMeshPro需要的字库之后已经接近17M，如果考虑到游戏中存在2种字体，估计会超过20M的常驻内存在移动端，这个至少现在还很难接受。
文字是序列化，20M的序列化数据，移动端受IO限制，读取时间会有点长。

2、Shader实现
两张纹理（字体纹理和emoji纹理）根据当前顶点是属于文字 or 图片来选择采样，需要uv0和uv1两套uv，需要顶点数据传递一个标志来区分文字和图片
优点：
文本（字体相同）和图片可以在一个drawcall渲染
比较容易做帧动画
缺点：
与Outline、Shadow等组件不友好（对图片也应用了效果）（需要定制开发）
对所有UIBaseEffect子类都需要区分顶点是文本还是图片
无法对文本和图片单独做Animation

3、Text组件 + Image组件 + Layout
用Text组件和Image组件组合，用Layout来控制组件位置
优点：
简单粗暴，容易实现
容易做帧动画和Animation
Text和Image都是UGUI，和其他UI容易合并drawcall
缺点：
会生成很多组件，在配合List滑动等功能时，可能会导致GC的问题（可用对象池优化）
ui rebuild会非常严重，特别是有动画的情况下，layout也可能会一直持续rebuild
基于layout本身的规则，位置不好定制

4、Text组件 + Sprite组件 + Layout
用Text组件和Image组件组合，用Layout来控制组件位置
优点：
简单粗暴，容易实现
容易做帧动画和Animation
Sprite本身不是UGUI，不会引起UI的rebuild
缺点：
会生成很多组件，在配合List滑动等功能时，可能会导致GC的问题（可用对象池优化），rebuild也会有点问题。
Sprite脱离了UI，不能和UI合批，可动态合批。和UI有遮挡关系时，层级可能会增加drawcall
基于layout本身的规则，位置不好定制

5、Text组件 + 图片
与3、4方案的不同是位置计算，在Text中遇到图片就留出"合适的空间"，这样文本可用一个组件搞定。但位置计算比较麻烦一些。

6、Text组件的富文本
UGUI富文本有一个标签，它可作为一个占位符号，在Unity底层会为标签生成顶点数据（两个三角形），在上层根据标签所在位置拿到相应的顶点数据，把顶点信息转换到世界空间，然后在另一个图片组件中去渲染（取出的顶点数据本地空间-世界空间-本地空间），并设置好位置。
注意点：
Text组件没有自动换行时，富文本的标签不会生成顶点数据，有自动换行时，富文本标签会生成无用的顶点数据，两种情况下索引偏移不一样。