4. 移动端原生开发偏移：iOS UILabel与UITextField的基线对齐、Android TextView的padding与fontMetrics、跨平台框架的文本布局差异

移动端原生开发里，字体偏移问题其实比Web端更隐蔽。为什么？因为每个平台都有自己的文本渲染引擎，基线对齐规则、内边距计算方式都不一样。我这些年做跨平台项目，没少被这些差异坑过。今天咱们就掰开揉碎了聊聊。

4.1 iOS：UILabel与UITextField的基线对齐

iOS的文本布局核心是UILabel和UITextField。它们都继承自UIView，但基线对齐行为完全不同。

UILabel的基线对齐

UILabel默认使用NSTextAlignmentNatural，基线对齐方式取决于baselineAdjustment属性。这个属性有三个值：

我记得有一次做金融App，数字和单位混排时，数字字体比单位字体大，结果单位文字往上窜了一截。查了半天，发现是baselineAdjustment默认值是AlignBaselines，但单位字体太小，基线对齐后反而视觉上偏移了。后来改成AlignCenters才解决。

UITextField的基线对齐

UITextField比UILabel复杂得多。它内部有一个UITextFieldDelegate，还有leftView、rightView、clearButton等子视图。这些子视图的基线对齐方式各不相同。

我个人的习惯是：永远不要依赖UITextField的默认基线对齐。因为它的textRectForBounds:方法返回的文本绘制区域，和editingRectForBounds:返回的编辑区域，可能不一样。你想想看，用户输入时和显示时，文本位置居然可能不同，这多坑。

解决方案？重写textRectForBounds:和editingRectForBounds:，手动计算偏移量。比如：

- (CGRect)textRectForBounds:(CGRect)bounds {
    CGRect rect = [super textRectForBounds:bounds];
    // 手动调整偏移，补偿基线差异
    rect.origin.y += 2.0;
    return rect;
}

- (CGRect)editingRectForBounds:(CGRect)bounds {
    CGRect rect = [super editingRectForBounds:bounds];
    rect.origin.y += 2.0;
    return rect;
}

4.2 Android：TextView的padding与fontMetrics

Android的文本偏移问题，核心在于TextView的padding和FontMetrics的交互。我刚开始做Android开发时，总觉得TextView的文本位置不对，后来才发现是includeFontPadding这个属性在作怪。

includeFontPadding

这个属性默认是true。它会在文本顶部和底部额外添加一些内边距，用于容纳字体自身的上升和下降部分。但问题是，不同字体的上升下降值不一样，导致文本位置不稳定。

我曾经在一个电商项目里，商品标题用了两种字体：中文用思源黑体，英文用Roboto。结果同一行文字，中文和英文的基线对不齐。排查后发现，思源黑体的top和bottom值比Roboto大，导致includeFontPadding为true时，中文文本整体偏下。

解决方案很简单：

android:includeFontPadding="false"

但注意，关闭后文本可能紧贴边界，需要手动调整padding。

FontMetrics详解

Android的Paint.FontMetrics包含五个关键值：

我建议你在自定义View时，用Paint.getFontMetrics()获取这些值，然后手动计算文本绘制位置。比如：

Paint paint = new Paint();
paint.setTextSize(48);
Paint.FontMetrics fm = paint.getFontMetrics();
float baseline = (viewHeight - (fm.descent - fm.ascent)) / 2 - fm.ascent;
canvas.drawText("Hello", 0, baseline, paint);

这样计算出来的基线位置，在任何字体下都能保证文本垂直居中。

4.3 跨平台框架：Flutter与React Native的文本布局差异

跨平台框架的文本布局，本质上是把原生平台的渲染能力封装了一层。但封装过程中，每个框架都有自己的“理解偏差”。

Flutter的文本布局

Flutter使用自己的文本渲染引擎（基于Skia），不依赖iOS或Android的原生文本布局。这意味着Flutter的文本行为在两端是一致的，但和原生平台的行为可能不同。

Flutter的Text组件使用TextStyle控制字体属性。其中height属性（行高）的默认值是null，此时行高由字体本身决定。但如果你设置了height，它会乘以fontSize作为实际行高。

我遇到过一个问题：Flutter的Text组件在iOS和Android上，文本的垂直位置居然不一样。排查后发现，Flutter在iOS上使用了UIFont的ascender和descender，而在Android上使用了FontMetrics的ascent和descent。这两个值在不同平台上计算方式不同，导致基线偏移。

解决方案？用StrutStyle强制统一行高：

Text(
  'Hello World',
  style: TextStyle(fontSize: 16),
  strutStyle: StrutStyle(
    fontSize: 16,
    height: 1.2,
    forceStrutHeight: true,
  ),
)

React Native的文本布局

React Native的文本布局更复杂。它使用Text和TextInput组件，底层分别映射到iOS的UILabel/UITextField和Android的TextView。所以React Native的文本偏移问题，本质上是原生平台问题的“复刻”。

但React Native多了一层JavaScript的布局计算。比如lineHeight属性，在iOS上可能被解释为UILabel的lineSpacing，在Android上可能被解释为TextView的lineSpacingExtra。这两个概念不完全等价。

我建议你在React Native中，永远使用includeFontPadding: false（Android专用）和textAlignVertical: 'center'（Android专用）来统一行为。比如：

<Text style={{
  fontSize: 16,
  lineHeight: 22,
  includeFontPadding: false, // Android only
  textAlignVertical: 'center', // Android only
}}>
  Hello World
</Text>

4.4 跨平台文本偏移对比总结

为了让你更直观地理解这些差异，我画了一张对比图：

说白了，移动端文本偏移问题，根源在于每个平台对“基线”的定义不同。iOS用ascender和descender，Android用ascent和descent，Flutter用Skia的FontMetrics，React Native则两头都沾。你想想看，这么多套标准，不出问题才怪。

我的建议是：在项目初期就建立一套跨平台的文本布局规范。比如统一关闭includeFontPadding，统一使用lineHeight的百分比值，统一测试所有目标字体。这样能避免后期大量返工。

嗯，这一章的内容就这些。记住：文本偏移不是bug，是特性。理解每个平台的特性，才能写出真正适配的代码。