项目中可能会用到emoji表情，所以这几天针对这个模块进行了制作和整理。
首先，在网上进行简单的搜索查找现成方案，主要搜索结果为textmeshpro和github上的一些emoji项目，因为闭源的关系，这里先跳过textmeshpro（暂时不想反编译╮(╯▽╰)╭）。所以目标定为github上的emoji项目，看到了这个项目：https://github.com/coding2233/TextInlineSprite。看到了上面的示意图片，感觉基本够了，so下载下来看了看，运行了example，觉得基本也差不多，然后依赖文件不多，非常轻量，遂决定查看下代码，然后可怕的事情就发生了~：
在代码中我发现了这个：
大哥 - -，这么多foreach 你让低版本的unity开发者用了怎么玩啊，，然后清空的previousdata的时候每次new一个，而不循环复用？，那你gc可真的是很棒棒哟。。
Next:
每次都new新对象，搞个pool不是更好？还有坐标系转换的一些问题，这里也不做阐述，类似的性能问题非常严重。。代码结构问题也就不说了。。
所以直接使用它的代码是我所不能接受的，所以改！
然而改代码就需要理解原作者的思路，并没有看他的博客什么的，从源代码进行分析，思路如下：使用richtext中的quad为表情占位（这里使用预先生成好的spriteasset中存的数据信息）,然后使用spritegraphic来渲染，渲染方式则是创建mesh，刷新verts，uv，triangle信息，通过调用canvasrender的接口进行渲染（注意这里并不是常规渲染方案）。基本思路明确之后进行了代码重构和优化：
放出目前的小结果：https://github.com/cjsjy123/TextInlineSprite（从原始项目fork的项目，已经提交一个小版本给主分支，如果持续不接受，可能我会新开个项目，同时更新这个链接，存放这些代码 - -原始项目并没有开源证书信息。）
后续版本更新思路如下：
1.放弃richtext的quad占位思路，不用richtext，直接缓存一个空格的vert信息，使用多空格的方式代替quad占位。
2.目前渲染方式为两种：unit和group：unit为在每个inlinetext对象下存放渲染体，来渲染emoji，group则是将同图集的emoji放置在一个渲染体中渲染。但是这里就是需要深度思考的地方了，优化！culling!mask类型的组件，要么使用cull接口要么使用stencil，来剔除超出范围的ui，但是渲染体中拿到是整个mesh，需要对culling和ui是否超出屏幕进行判断，然后进行剔除。这里并没有想到一个特别完善和方便的方案，最初设想是将一个canvas下一组渲染体就足够了，但是由于mask等一些组件的存在，必须进行调整，至于我说的culling问题，目前暂时可以通过将inlinemanager挂在mask类型组件之下进行解决，让mask帮我们进行culling。如果你有好的想法，欢迎讨论。
最终我们和大boss ：textmeshpro进行比较：
比较结果也在这里：https://github.com/cjsjy123/TextInlineSprite
╮(╯▽╰)╭ Over
