TextView 渲染机制与竖向排版

Android 开发中，最常用的控件莫过于 TextView。然而，大多数开发者只停留在调用 setText() 层面，把它当作一个黑盒。当遇到极端的性能瓶颈（如长列表中成百上千条复杂文本），或者特殊的产品需求（如古籍风格的文字竖向排版）时，原生 TextView 往往会成为阻碍。

本文将剥开 TextView 的表皮，深入 android.text.Layout 排版引擎的源码，探究 Android 是如何在底层完成文本测绘与渲染的，并从底层原理出发，彻底解决文字竖向排版的难题。

排版引擎机制：包工头与三个排版师傅

如果把 TextView 的渲染过程比作建一栋大楼，那么 TextView 本身只是一个「包工头」。它负责向系统（父 View）要地皮（onMeasure），负责打理外观（背景、边框），但真正在画布上一砖一瓦堆砌文字的，是底层的排版引擎：Layout 家族。

Android 并没有让 TextView 把活全干了，而是将复杂的文字计算逻辑抽离到了 android.text.Layout 类及其子类中。这是典型的**策略模式（Strategy Pattern）**应用。

根据传入文本的复杂程度，包工头会把活交给三位不同的排版师傅：

1. BoringLayout（单行极简师傅）：专门处理最简单的情况——只有一行、没有特殊字符（如 Emoji、Spannable）、从左到右排版。它不做复杂的换行计算，性能极高。
2. StaticLayout（主力重型师傅）：专门处理多行文本。它的核心工作是换行计算（Line Breaking）。计算每个字符的宽度，判断到了哪里该换行，是 Android UI 渲染中最消耗 CPU 的操作之一。一旦排版完成，它就变成「静态」的，不再改变。
3. DynamicLayout（动态更新师傅）：用于文本会频繁变化的场景，典型的就是 EditText。当文本发生局部改变时，它能通过内部的数据结构增量更新布局，而不是全部推倒重来。

源码视角的 Layout 决策

当调用 setText() 时，内部最终会走到构建 Layout 的核心逻辑。我们可以一窥其决策过程（简化版源码）：

// TextView.java
protected void makeNewLayout(int wantWidth, int hintWidth, ...) {
    // 1. 询问 BoringLayout，这段文本是不是"无聊"（简单）的？
    BoringLayout.Metrics boring = BoringLayout.isBoring(mText, mTextPaint);

    if (boring != null) {
        // 如果文本很简单，并且只有一行
        if (boring.width <= wantWidth) {
            mLayout = BoringLayout.make(mText, mTextPaint, wantWidth, ...);
        } else {
            // 虽然是简单文本，但是超长了需要换行，交给 StaticLayout
            mLayout = StaticLayout.Builder.obtain(mText, 0, mText.length(), mTextPaint, wantWidth).build();
        }
    } else if (shouldEnableDynamicLayout()) {
        // 如果文本是可编辑的 Spannable
        mLayout = new DynamicLayout(mText, mTextPaint, wantWidth, ...);
    } else {
        // 其他所有复杂的、多行的静态文本，全部交给 StaticLayout
        mLayout = StaticLayout.Builder.obtain(mText, 0, mText.length(), mTextPaint, wantWidth).build();
    }
}

这解释了为什么创建 TextView 的代价很高。不仅是因为 View 系统本身的开销，更因为每次文本变动，底层都要实例化复杂的 Layout 对象，进行海量的字符宽度测量（TextPaint.measureText）。

文字竖向排版：从 Hack 到官方正统

在东亚排版（中、日、韩文）中，文字竖排自上而下、行从右向左阅读是古老的传统。但 Android 底层的渲染机制——无论是 android.text.Layout 还是更底层的 Skia 图形引擎，最初都是建立在拉丁语系的横向基线（Baseline）模型之上的。

这就导致 Android 原生一直没有提供一个简单的 android:orientation="vertical" 属性来支持文字竖排。要实现竖向排版，必须从底层逻辑开刀。

方案一：Canvas 坐标系扭曲（传统黑客解法）

既然底层排版师傅（Layout）只会横着写字，最直观的暴力解法就是：让师傅正常横着写，但在他写字的那张纸（Canvas）上做手脚。通过旋转纸张，把横向的文字变成竖向的。

核心原理：自定义 View，在 onMeasure 时交换宽高的计算结果；在 onDraw 时利用矩阵变换（Matrix Transformation）将画布逆时针旋转 90 度，并向下平移填补旋转带来的位移偏移。

public class VerticalTextView extends AppCompatTextView {
    // ... 构造函数省略 ...

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        // 欺骗系统：将外部要求的宽高交换，让 TextView 以为自己是在横向排版一个很长的单行
        super.onMeasure(heightMeasureSpec, widthMeasureSpec);
        // 测量完成后，将自己的实际宽高再调换回来
        setMeasuredDimension(getMeasuredHeight(), getMeasuredWidth());
    }

    @Override
    protected void onDraw(Canvas canvas) {
        // 保存画布当前纯洁的状态
        canvas.save();
        
        // 1. 将画布坐标系平移到右上角（或者是根据具体需求平移）
        canvas.translate(getWidth(), 0);
        // 2. 将画布顺时针旋转 90 度
        canvas.rotate(90);
        
        // 此时坐标系已经发生扭曲，TextView 会"以为"自己还在正常横向绘制
        super.onDraw(canvas);
        
        // 恢复画布状态，以免影响后续 View 的绘制
        canvas.restore();
    }
}

为什么这种方案有局限？ 它只适合纯中文字符。因为英文字符（拉丁字母）本来就应该是横排的。如果你把包含英文字母的字符串通过旋转画布渲染，字母也会跟着躺平 90 度，导致无法阅读。此外，由于交换了宽高测量，当文本超长需要发生截断（Ellipsize）或多行换行时，行为会变得极其诡异且难以控制。

方案二：Jetpack text-vertical 库（正统解法）

随着全球化排版需求的增加，Google 最终给出了官方解：androidx.text:text-vertical 库。

这个库没有使用粗暴的旋转画布，而是深入了排版引擎的底层，实现了真正的竖向文本测量器（VerticalTextLayout）。

底层逻辑演进： 它基于 OpenType 字体中的竖向排版表（vhea, vmtx 等）。在排版计算时，它不再依赖横向的 Baseline，而是逐字符（Glyph）地分析。对于汉字，它保持直立并沿 Y 轴向下推进；对于英文单词，它通过字符旋转引擎让其侧翻，甚至能够处理「直向文字中的横向英文（Tate-chu-yoko）」这种极度复杂的排版。

开发者只需接入库，便能以最符合人类直觉的方式获得毫无瑕疵的竖排版面。如果在项目中需要严肃处理竖排（尤其是混排英文字母或符号），这应当是唯一的首选方案。

极限性能优化：绕过 TextView

理解了 TextView 的底层架构，我们就能在性能优化时打出「降维打击」。

如果在你的 App 中，比如一个阅读器的长列表中，有数千个只用于展示的文本（不需要点击、不需要选中、不需要编辑）。如果依然使用 TextView，系统会创建数千个庞大的 View 对象，引发严重的内存膨胀和测量耗时。

优化思路：直接使用 StaticLayout。

既然我们知道真正干活的是 StaticLayout，我们完全可以抛弃 TextView 这个「包工头」，自己充当包工头直接雇佣排版师傅。

// 在自定义的轻量级 View 中
public class FastTextView extends View {
    private StaticLayout mStaticLayout;
    private TextPaint mTextPaint;

    // ... 初始化 TextPaint ...

    public void setText(String text) {
        // 直接在非 UI 线程或初始化阶段创建 StaticLayout，剥离了 View 树的重重锁链
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
            mStaticLayout = StaticLayout.Builder.obtain(
                    text, 0, text.length(), mTextPaint, getWidth()
            ).build();
        }
        invalidate(); // 触发重绘
    }

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        if (mStaticLayout != null) {
            // 直接让师傅把字画在 Canvas 上，没有 TextView 那些乱七八糟的边距和状态计算
            mStaticLayout.draw(canvas);
        }
    }
}

这种被称作 "Text Pre-computation"（文本预计算） 的技术，是各大厂优化 Feed 流滑动的核心秘籍。甚至可以把 StaticLayout 的实例化放在子线程完成，彻底释放主线程的压力。

总结

TextView 并不是简单的文字载体，它是一套精密的排版系统的封装。从 BoringLayout 的极简哲学到 StaticLayout 的复杂断行，再到竖排版面从「画布扭曲 Hack」到「Jetpack 规范支持」的演进，无一不彰显着 Android 系统在通用性与性能之间的权衡。掌握了这些底层原理，你就不再是被 API 束缚的码农，而是能随时绕过框架限制、直击性能痛点的工程师。