Android的文字渲染 _渲染器

一种使用渲染文字的常用方法，是计算出一个包含了显示文字的纹理图片，这通常是使用相当复杂的打包算法来最小化纹理中的冗余部分，在创建这样的图片之前必须清楚应用运行时使用的字体，包括了字体形状，尺寸和其他的一些属性。
在上，提前生成文字纹理图片是不太实际的，因为没有方法提前知道应用使用了哪些字体和字形，应用甚至可以在运行时加载自定义字体，这是许多限制因素中的主要一个，字体渲染必须实现下面的工作：
实现文字渲染
在我们查看低级别的字体渲染是如何工作之前，我们先从应用直接使用的高级别API开始，这些API对于理解的工作是非常重要的。
Text APIs
应用主要使用下面的四个API来布局和绘制文字：
和.text是在Paint和上面的高级别实现。直到 3.0，Paint和是直接在Skia上面实现的，Skia是一个软件渲染库，它提供了一个非常好的（非常流行的文字光栅化开源代码）抽象。

文章插图
到了4.4过程变得更加复杂了，Paint和使用内部的JNI接口来处理复杂文字的，这个API依赖于（一个开源的文字成型引擎），的输入是一个font和一个Java UTF-16的，输出是包含x，y位置的字形标识符列表。
是正确支持许多非拉丁语言的关键，比如阿拉伯语、希伯来语、泰语等。绘制文字比简单的从左到右一个接一个的放置文字复杂的多，一些语言比如阿拉伯语，是从右到左的，泰语甚至需要文字被放置到前一个文字的上面或者下面。

文章插图
这意味这当你调用.()方法时，渲染引擎不会直接或者间接的接收到你发送的参数，但是会收到字形标识符数组和x/y位置数组
光栅化与缓存
字体渲染的每一次draw调用都是和一个单独的font关联的，font是用来缓存各个字形，字形反过来被存储在一个缓存结构中（cache ），这个缓存结构可以用来包含多种字体的字形。cache 是一个非常重要的对象，它有多种缓存：空闲块列表，像素缓存，纹理句柄，顶点缓存（the mesh，网格,构成图形的基本单位）。

文章插图
用来存储这些对象的数据结构是相当简单的：

文章插图
当字体渲染器初始化的时候，它创建了两种类型的cache ：alpha和RGBA 。Alpha 用来存储正常的字形，因为字体不包含颜色信息，我们只需要存储抗锯齿信息。RGBA缓存被用来存储表情符号。
对每一种类型的cache ，字体渲染器创建一些不同尺寸大小的实例，根据设备的不同缓存的大小也不同，下面是一些默认的尺寸：
当一个被创建的时候，底层的缓存并没有被自动分配，字体渲染器在需要的时候才会进行分配，除了缓存，它总是被分配的。
字形在以列的形式进行打包，当渲染器遇到一个没有缓存的字形，它会按照上面列出来的顺序寻找合适的缓存字形。
这就是块列表使用的地方，它包含了cache 的当前分配列和可用的空闲位置。如果字形符合存在的列，它会被添加到该列所占空间的末尾。
如果所有的列都被占用了，一个新的列会在剩余空间的左侧划分出来。因为很少的字体是等宽的，渲染器分配每一个字形的宽度为4像素的倍数。这是对列的重用和打包的好的折衷方案。打包不是最佳的，但是它提供了快速实现。
所有的字形周围都有一个像素的空边界，它们都存储在中，对于采取双重线性采样的font 来说，这么做可以避免人工处理。
知道text在渲染的时候是否进行尺寸变换是非常重要的，变换被提交给Skia/，这意味着cache 里的字形存储了变换，这在性能消耗方面提高了渲染质量。幸运的是，text是很少动态缩放的，即使有，也只有很少的字形被影响到。还有其他的paint属性可以影响字形的光栅化和存储：仿粗体，文字偏斜， X缩放，风格和线宽。
预先缓存
由于是延迟渲染的，和Skia的直接模式相反，在一帧开始的时候，已经知道需要被绘制到屏幕上的字形了，在显示列表操作排序的时候，字体渲染器会尽可能多的预缓存字形。这样做的好处是会完全避免或者最小化在帧中间上传的数量。上传是非常耗资源的操作，会导致CPU或者GPU暂停，更糟糕的是，在帧中间修改会对一些GPU产生严重的内存压力。
的 SGX GPU在帧中间修改的时候，会强制驱动复制每一个修改的，因为一些font的是非常大的，如果不小心上传的话，会更加容易导致oom 。paly上面有一个计算器应用出现过这种情况，它用数学符号和数字绘制按钮，在字体渲染的时候，可能会出现oom ，因为按钮的绘制是一个接一个的，每一次绘制都会触发上传，这导致了整个font缓存的复制，系统没有那么多的内存来放置这么多份缓存的拷贝。
刷新缓存
用来缓存字形的是相当大的，所以当其他应用需要更多内存的时候它们可能会被系统回收。当用户隐藏当前应用的时候，系统会发消息通知应用释放尽可能多的内存，应用在大部分情况下会摧毁最大的缓存。在设备上，除了第一个被创建的（默认为）其他所有的缓存都被认为是大的。
当没有所有的缓存中都没有空间的时候，会被刷新， font渲染器会保持一个LRU(最近最少使用)的列表，但是没有使用它做任何事情，如果需要的话，通过刷新很少使用的内存来是缓存的刷新更加智能，目前位置还没有需要这样做，但是要记住它是潜在的优化方向。
批量处理与合并

文章插图
4.3介绍了绘制操作的批处理与合并，一个非常重要的优化是大幅减少了传递给驱动的命令数。
为了实现合并， font渲染器缓存了多个绘制命令的文本几何数据。每一个缓存有一个客户端数组，里面包含了2048个四边形（1四边形 = 1 字形），他们都共享一个独立的索引缓冲（在GPU中以VBO存在）。
当执行一个文字绘制命令时，文字渲染器会为每一个字形获取合适的mesh(网格,构成图形的基本单位)并会将位置和u/v坐标写进去。Mesh会在一批结束或者quad缓存满了之后传送到GPU 。渲染一个单独的可能需要多个mesh ，每个缓存有一个mesh 。
这个优化是比较容易实现，并且会极大的提高性能。由于文字渲染器使用多个缓存，有可能会出现中的大部分字形是一个的一部分，而一些字形是另一个的一部分。如果没有批处理和合并操作，在每一次文字渲染器需要切换到不同的缓存时，都会给GPU提交一个绘制命令。
我曾经在一个test的app中碰到过这种问题，这个应用只是渲染不同风格和尺寸的“hello world”，在“o”字母和其他的字形被存在不同的中的特定情况下。这会导致文字渲染器会先渲染“hell” ，然后“o”，然后“w”，然后“o” ，然后“rld”，总共执行了5个绘制命令和5个绑定，而实际上两个都之需要2次，现在的渲染器先绘制“hell w rld”然后一块绘制两个“o” 。
优化上传
前面曾经提过文字渲染器会在更新缓存时尝试尽可能少的上传数据，通过跟踪每一个的被变动的部分（dirty rect），可惜的时这种方法有两个限制。
首先， ES2.0不允许上传一个随意的子矩形。允许你指定矩形的x/y和width/来更新的一部分，但是它是假设存在于主内存数据的（步幅）是矩形的宽度。这个可以通过创建合适尺寸的CPU缓存来实现，但前提是必须知道变动矩形的大小。一个比较好的折中方法是上传一个最小的包含dirty rect的像素带，因为这个像素带的宽度是和一样的，所以我们可能会浪费一些带宽，但还是比上传整个好。
第二个问题是，上传是同步的操作，这可能会导致cpu长时间的等待，对于已经预先缓存的其实影响不大。但是对于使用了很多文字的应用或者有很多字形的语言环境，比如中文，这个问题可能会被用户感觉到。
幸运的是，ES3.0对这两个问题提供了解决方法，现在可以使用新的像素存储属性上传字矩形了。这个属性指定了或者内存中的源数据，但是要小心的是：这个属性影响当前的全局状态。
在上传期间的CPU等待可以通过使用像素缓存对象(PBO)来避免，就想中所有的对象，PBO存在与GPU，但可以被映射进内存。PBO有很多有趣的属性但是我们关心的是在从内存中取消映射后，它可以异步上传，这样操作的顺序就变成了：
→ writeto→→ () →
现在调用会直接返回，而不是阻塞渲染器。文字渲染器现在将整个映射进内存，尽管它看起来没有引起性能问题，但是将需要更新的cache 的范围映射进来而不是全部会更好。
阴影
文字通常是和阴影一起渲染的，一个相当耗费资源的操作。由于相邻的字形会模糊进彼此，文字渲染器不能独立的预先模糊字形。有许多方法来实现模糊，但是要在一帧中最小化混合操作和纹理采样，阴影被以存储并且会在多个帧中存在。
【Android的文字渲染】翻译自@/-font--,转载本文请标明出处，谢谢！