Android使用指定TTF字体搭配U+2019字符时出现文本截断异常

该故障是TTF字体文件垂直度量配置错误，叠加Android文本排版引擎的字体度量缓存机制缺陷共同导致。iOS端未复现是因为Apple CoreText排版引擎会自动校正字体文件内不合理的度量参数，不会直接信任文件内写入的配置值。

• 首屏触发+全局污染：Android的Typeface实例在首次实际渲染字符时，会一次性计算并缓存整套字体的ascent（上沿高度）、descent（下沿高度）、行高度量值，缓存生成后不会再重新计算。如果首次渲染命中的U+2019字形边界超出了字体文件预设的度量范围，引擎会把错误的度量值写入缓存，后续所有复用该Typeface实例渲染的文本都会调用这个错误值，直接出现基线上移、顶部截断的问题。
• Compose与XML异常互不影响：传统XML View调用的是系统框架层android.graphics.Typeface的全局缓存池，Jetpack Compose（1.3及以上版本）使用独立维护的TypefaceAdapter字体缓存，两套缓存完全隔离，因此一侧的度量缓存污染不会传导到另一侧。
• 首屏无该字符则全局正常：如果字体首次渲染时加载的是度量符合预设值的字符（比如U+0027普通单引号、常规英文字母、数字），引擎计算出的全局度量值是正确的，后续哪怕加载U+2019，也不会触发全局度量重算，仅会在已确定的行高范围内渲染该字符，不会出现截断。
• U+2019单独触发问题：你使用的TTF文件中，U+2019（右弯单引号）的字形大概率做了偏高的设计，字形上边界超出了字体头表配置的全局ascent上限，首次渲染时引擎误将这个超界的字形边界作为整个字体的度量计算基准，直接算偏了全局baseline位置。

• 用免费字体编辑工具FontForge打开目标TTF文件，定位到U+2019字形查看其边界坐标，对比字体hhea、OS/2表中配置的全局Ascent值，即可看到该字形顶部超出了预设的上沿范围。
• 临时测试可给使用该字体的文本控件手动设置固定行高，或给XML TextView配置android:includeFontPadding="false"、给Compose Text配置includeFontPadding = false，如果截断问题消失，即可确认是度量配置+缓存导致的问题。

按优先级从高到低选择：

1. 根治方案：修正字体文件。用字体编辑工具调整U+2019的字形位置，使其落在字体预设的垂直度量范围内；或直接调整字体hhea、OS/2表的全局垂直度量参数，将Ascent值增大到可覆盖所有字形的上边界，重新导出TTF文件即可，该方案双端通用。
2. 代码层规避缓存缺陷：在App启动、任何业务页面加载前，用该自定义Typeface渲染一段包含常规字母、数字的不可见文本，主动触发字体度量的首次计算，提前将正确的度量值写入缓存，后续加载U+2019时就不会触发错误计算。
3. 临时兜底：所有使用该字体的文本控件手动设置合理行高，关闭默认字体内边距，避免文本被布局阶段截断。

内容的提问来源于stack exchange，提问作者Tommy Jackson