企业官网建设流程全解析

如果哪天你接手一个资讯类App的详情页，发现正文区就一行tv_content.setText(massiveText)，滑动时却像在看旧版幻灯片一样一顿一顿的，不要怀疑自己眼睛——这种情况我碰到不止一次。TextView 加载大文本发生卡顿，表面上是个“性能优化”话题，骨子里其实牵涉到测量、排版、绘制和内存分配一整条链路的配合。这篇文章我会从症状分级讲起，把根因一个个刨出来，再给出几个亲测有效的优化方案和对比数据，给做阅读、资讯、长文展示、富文本渲染的 Android 开发当个参考。

我尽量不堆术语，但该讲原理的地方也不会含糊。整篇文章是老实操派的口吻，你可以直接照着里面的思路去排查自己的项目。

1. 先给卡顿定个级：你的TextView到底“大”在哪

很多人一听到“大文本卡顿”就问：多大的文本算大？这个问题其实没有标准答案，它跟机型、屏幕宽度、字体、段落结构都有关系。我通常用三条经验线来判断：2万字符以下，主流机型基本没什么感觉；5万到10万字符，中端机首帧已经能感觉到迟滞；超过20万字符，任何一个普通TextView都基本救不回来。这篇文章讨论的“大文本”，指的就是后两档——你在正常业务里能把一个TextView撑到这个量级，说明已经是长文场景了。

1.1 把大文本的卡顿形态拆成三类

同样是卡，卡的位置完全不一样。我习惯把症状分成“首帧慢、滑动掉帧、滚动后偶发卡顿”三类，这样可以快速缩小排查范围。

首帧慢最容易定位，因为问题一定出现在第一次测量的路径上。滑动掉帧则复杂一些，它可能来自绘制开销、无用布局，甚至内存抖动。偶发卡顿十有八九是 GC 和系统字体Fallback在拖后腿，后面我会展开每个场景的成因。

1.2 用Profile把锅拍到具体方法上

别上来就猜“是不是字体渲染慢”。先用一次 CPU Profiler 抓取，把责任落实到方法级别。我的标准做法是三步：

1. 在详情页打开前开始录制 CPU Profiler，从页面进入到滚动结束全程记录；
2. 看主线程时间片，重点盯着TextView.onMeasure、TextView.onDraw、StaticLayout相关方法；
3. 同时观察 Memory Profiler 里是否有频繁的 GC 抖动。

实战中你会发现一个有意思的现象：卡顿发生时，主线程的调用栈高度相似，要么堆在StaticLayout.buildTextLines，要么堆在TextLine.drawRun，再不然就是有一堆android.graphics.Paint.measureText。如果看到这些，说明问题确确实实在“排版”和“绘制”而不是网络或者图片。定位到这一步，下面讲原理你才有体感。

1.3 一个快速自查经验：先看文本里有没有Span

有一次排查某资讯App，文本才8万字符，不算极端，但打开详情页整整卡了1秒多。Profile一看，发现问题不在纯文本，而在那段文本里被铺了上千个ForegroundColorSpan——每个词一个高亮，TextView 在 layout 之后每次 draw 都要遍历整棵 Span 树做样式判断。那次之后我形成了习惯：遇到大文本卡顿，第一件事就是看它是不是“纯文本”。纯文本问题相对好治，带大量富文本的问题，方案差别很大，后面分开讲。

2. 卡顿的根子：一次setText背后发生了什么

如果你想彻底根治而不是临时缓解，就必须理解setText()之后 Android 到底干了什么。简单说，TextView 拿到一大段 CharSequence 后，并不像我们想的那样“就画一次”，它需要先构建一个排版模型，再逐行画到Canvas上，这个模型叫StaticLayout。

2.1 setText到首帧的“主线程战争”

先纠正一个常见误解：setText()本身并不是最耗时的，它只是把文本放进 TextView 内部，同时触发一个requestLayout()和invalidate()。真正的重活发生在下一帧的 measure 和 draw 阶段。

measure 阶段要做的事情，是把一整段文本按屏幕宽度断行，算出每一行的高度和位置。这段逻辑内部非常重，涉及字体排印、连字处理、断行策略、标点压缩等，一个10万字符的文本在这个阶段可能要跑几百毫秒。更麻烦的是，这一步是在主线程执行的，窗口一错过vsync就变成掉帧。

我用一个生活化类比来解释：TextView 每次测量，都像有人拿着一部长篇小说打字稿，在上台之前临时把所有文字按稿纸格子一行行誊抄一遍。只要格子宽度变了、字体变了、文本变了，哪怕只是其中一个字，整篇就得重抄。你说这部小说如果几十万字，表演开始前谁不慌？

2.2 为什么滚动时不能只怪“重新排版”

很多人以为滚动卡顿是因为每滑一帧都在“重新排版”，这个判断对一半。

只要屏幕宽度和字体参数不变，StaticLayout只在第一次时构建一次，滚动过程中并不会重排。真正的问题是：绘制路径上的逐行处理实在太贵了。TextView 的 onDraw 会对每一行调用文本绘制引擎，逐行计算字符位置、进行字形索引、必要时做字体 Fallback。当一屏内有几十行，每一帧都要重复这些工作，GPU和CPU根本没时间休息。

更隐蔽的是，如果这个大文本被放进了任何形式的滚动容器，Android 在绘制时虽然能裁剪掉不可见部分，但某些场景下 TextView 还是会维护整篇文本的排版数据。也就是说，即使你只看到其中一屏，CPU 却可能已经把整篇文本的断行结果都算了，这跟“看一章书却把整本书翻了一遍”一样耗能。这也是为什么”超大文本整页塞进去”天生不划算。

2.3 那几个被你忽略的隐形杀手

如果文本里再混入这几种东西，卡顿会成倍放大：

• Spannable 密度过高：上百个Span意味着每次绘制都要做区间查找和样式合并，逻辑看似轻，乘以上千个Span和每秒几十帧就非常可观。
• AutoLink / Linkify：setAutoLinkMask或Linkify会在整段文本上做正则匹配，这本身也是 O(n) 的字符串扫描，碰上长文本是额外的一笔重开销。
• MovementMethod：设置LinkMovementMethod后，TextView 在每次点击、触摸，甚至滚动时，都可能执行链接命中检测，算法要遍历行信息再挨个Span比对，成本跟行数和Span数量成正比。
• TextWatcher：每次 setText 或内部文本变更都会回调一堆Watcher，在列表复用场景里很容易造成重复计算。

这些隐形杀手单独拎出来都不算大，但叠在一起，大文本场景下就是压垮骆驼的最后一根稻草。所以我会说，排查大文本卡顿，光看“文本大小”远远不够，一定要看文本的“成分”。

3. 分场景治理：哪种卡就上哪种方案

原理搞清楚了，下面对症下药。我不喜欢“一套方案通吃”，因为首帧慢和滑动掉帧的优化目标完全不同。下面三个方向基本覆盖了绝大多数大文本场景，你可以按实际卡顿类型选。

3.1 首屏加载慢：PrecomputedText异步测量与缓存

如果你的症状是页面打开后白屏几百毫秒，重点应该放在“把测量和断行放到后台线程”。Android 8.0 之后提供了一个原生方案：PrecomputedText。

思路很简单：用 TextView 当前的TextPaint、BreakStrategy、TextDirection等参数，在后台线程预先断行生成一个排版结果，再在主线程直接赋给 TextView。这样打开页面时，主线程就不再需要临时誊抄整部小说，直接打印现有稿子即可。

我项目里的典型写法是：

val params = textView.textMetricsParams lifecycleScope.launch { val precomputed = withContext(Dispatchers.Default) { PrecomputedText.create(longContent, params) } textView.setText(precomputed) }

有几个使用前提必须注意：

• textMetricsParams必须在 TextView 已经确定文本尺寸、字体之后取，否则后台算出的断行和实际排版参数不匹配。
• 如果 View 的宽度、字体、字号发生变化，PrecomputedText必须重新生成，不能复用。
• API 28 以下没有这个类，需要自己判断版本做降级逻辑。

实测这类方案能把首帧从几百毫秒压低到一两百毫秒，但有一说一，它治标不治本——如果文本大到几MB，后台生成也需要大量时间，还是兜不住。

3.2 滚动掉帧：分段懒加载与轻量条目化

滑动掉帧的核心矛盾是：TextView 必须为整篇文本维护排版数据。解药也直白——别让一个 TextView 扛所有内容，把一段长文拆成多个条目丢进 RecyclerView。

做法不复杂：按章节、段落或大概一屏一个单位，把原始文本切成若干段，每一段作为列表的一个 item。滚动时，RecyclerView 只负责测量和绘制当前可见的 item，而不在“后台默默排版整本书”。这个思路跟 ViewHolder 复用的目的一致——把开销限制在可视区域内。

分段粒度建议控制在单段不超过4KB文本。太粗仍然会卡，太细则item数量爆炸，回收复用反而引入额外管理成本。我的经验是“一个自然段或2-3个自然段一个item”比较合适，文本摘要、标题、正文样式的 item 可以做多种类型。

这种方案有一个隐形成本：切分逻辑要处理好，比如不能把富文本Span孤零零切开。如果文本里有跨段的图片或表格，别硬塞给普通TextView，要单独做 item 类型来承载。

3.3 富文本/高亮：少造Spannable，把绘制逻辑下沉

如果你遇到的是“文本里大量高亮、变色、点击效果”导致的卡顿，那上面两个方案只能缓解一部分，更根本的做法是给这些富文本“减脂”。

最常见的高亮场景是给关键词上色，比如搜索关键词标红，大家通常这么做：

val spannable = SpannableString(content) for (range in keywordRanges) { spannable.setSpan(ForegroundColorSpan(Color.RED), range.start, range.end, Spanned.SPAN_EXCLUSIVE_EXCLUSIVE) } textView.setText(spannable)

这个写法在短文本里没毛病，可一旦关键词几百上千个，每次 setText 都生成这么多 Span 对象，再加上每帧绘制的区间查询，不卡才怪。

我的优化方向有三个，按改动量从小到大排：

1. 合并同色区间：把相邻的相同颜色Span合并成一个，减少Span总数；
2. 改为文本分段：一段红的一段黑的分别用普通 TextView 或者TextPaint处理，不再依赖 Span；
3. 下沉到Canvas绘制：在自定义 View 的 onDraw 里按文字区间直接上色，跳过 TextView 的 Span 机制。

第三种最彻底，但工作量大、需要处理换行问题，适合对性能极其敏感的场景。一般业务场景，做到前两步就能拿回明显收益，但也有个前提——你愿意在数据层做预处理，而不是把一行setText留在原地震撼主线程。

4. 实测对比：同一台机器上几个方案的表现

前面讲了不少理论，这里放一组我在模拟项目X里做的实测数据。文本是一篇约60KB的中英文混合资讯长文，包含部分加粗和少量高亮，界面是一台中端SoC测试机A，屏幕1080p，Android 13。为了减少偶然性，每个方案用 Profile 连续抓5次，取中位数。

4.1 测试条件怎么定

测试文本和页面布局都保持一致，只改动加载策略。评分指标定三个：首帧耗时、滑动5秒的平均帧间隔、滑动期间的GC次数。首帧从Activity开始创建算起，到第一帧真正上屏；帧间隔越小越好，超过16ms人眼就能感觉到顿挫。

4.2 数据表格与观察

表格数据很直白：光用 PrecomputedText 能大幅改善首帧，但滑动帧间隔依旧接近普通 TextView，因为绘制路径的瓶颈还在。把文本拆到 RecyclerView 后，首帧和滑动同时改善；再加上富文本减脂，GC次数被压到几乎可以忽略。这组数据也解释了为什么“只做Async计算”在长文场景里往往不够——首帧被救了，滑动手感还是难受。

4.3 怎么选：收益与成本不是线性关系

结合实测，我一般建议按需求选型：

• 只解决首帧白屏：优先上 PrecomputedText，改动最小，风险最低。
• 长文阅读、滑动场景：直接用分段懒加载，不要犹豫，收益是数量级的。
• 富文本特别密集：把“高亮Span减脂”提上日程，否则任何方案都还有隐性的绘制开销。
• 文本超大且结构复杂：进一步考虑分页或按需加载，真正让TextView每次只面对一屏内容。

选型时要克制，不要追求“把所有优化全上”，因为每加一层方案，代码复杂度、内存占用和潜在边界问题都会增加。我的经验是：先定位到具体卡顿形态，然后选一个对症的主要方案，能解决80%问题就够了，剩下20%等确认真出现再处理。

5. 那些看起来没问题其实很伤的TextView反模式

最后聊几个我踩过或帮人排查过的坑，它们表面上看跟“大文本”无关，实际经常是压垮TextView的帮凶。

5.1 setText被反复调用的隐藏入口

最常见的一种“隐性大文本”，是列表 item 里反复setText。很多人以为只有第一次打开才耗时，实际在 RecyclerView 的onBindViewHolder里，每次滚动到可见位置都会重新绑定，文本再大一点，测量开销就会成倍滚动放大。更要命的是，有些项目每次绑定都重新new SpannableStringBuilder，而旧对象的缓存又不在池里，内存抖动瞬间拉满。

我有一任同事在一个模拟项目X的列表页里，往notifyDataSetChanged()后绑定的setText()后面叠了三个TextWatcher，每秒钟活动几十次，一个列表直接卡成“拾色器”。所以排查大文本时一定要看调用频率，而不是只看单次耗时。

5.2 Html.fromHtml与多语言资源：字符串解析比你想象得贵

还有一种坑是用Html.fromHtml()把 HTML 转成 Spanned 再塞给 TextView。这个方法会做标签解析、样式处理、甚至实体转义，对一个几十KB的HTML串来说，本身就是一个不小的 CPU 负担，而且它产生的<p>等标签会额外引入复杂的 Span 结构，进一步拖累绘制。

更隐蔽的是，有些人为了支持 Android 多语言，把一篇长篇正文直接塞进strings.xml，再通过resources.getString()读取。运行时资源查找、字符串格式化、区域适配，都会在 setText 前增加额外成本。真要这么放，建议至少在后台线程处理，别在主线程里连资源解析带排版一起做。

5.3 TextView + ScrollView：最经典的身高测量型卡顿

如果说大文本卡顿有“祖传配方”，那一定是ScrollView套TextView。这个组合看起来没有错——文本太长需要滚动，外面包 ScrollView 很合理。但 ScrollView 的机制是：它需要子 View 汇报完整的测量高度，才能决定自己的滚动范围。所以即使TextView只显示一屏，它也要求TextView把整篇文本做完断行排版，把所有行的高度累加起来，作为滚动总高度。

这意味着你百分百绕不开大文本的完整排版开销。换成NestedScrollView也一样，因为滚动容器对子组件的测量契约没变。我的建议很简单：真要长文滚动，直接把正文拆进 RecyclerView 或其它懒加载列表，让容器只测量当前可见项，这才是根解。

5.4 用TextView硬扛“整本书”

最后一个误区，是把TextView当成电子书阅读器内核。一个章节几万字，放一个TextView勉强能跑；把整本书几十万字塞进去，内存、排版、绘制都是灾难级别的。有些项目为了“翻页效果”，宁可扛着这个巨头做各种 clip 动画，最终只能换来频繁 OOM。

正确路线是像电子书阅读器那样做分页：按屏幕高度把文本切成一页页，只让当前页对应的文本进入 TextView，或者干脆用多页列表 / ViewPager 框架，每页一个轻量 TextView。切页时再生成下一页的 PrecomputedText，前一页的 Layout 缓存主动释放。这样 TextView 永远面对的是“一屏文本”，自然就不会再有大文本卡顿问题。

最后分享一个小习惯：我在接大文本需求时，第一件事不是写优化代码，而是先确认数据会以什么形态、多大体积到达 TextView，用户是逐字阅读还是快速滑动，富文本是重点还是点缀。这三件事不确定，任何优化方案都只是在救火而不是根治。这个顺序，建议你做长文本性能优化时也记住。