做安卓开发久了，基本都遇到过这种问题：一段看似普通的TextView.setText()，传入一个几十万字的字符串，界面瞬间卡死。轻则掉帧明显，重则直接弹ANR对话框。这个问题的名字很直白——TextView加载大文本卡顿。它看起来只是"文本显示"，实际上牵扯到测量、布局、绘制、内存分配、回收复用等一系列环节。这篇文章我想完整梳理一下自己验证过的处理思路：根因是什么、怎么量化卡顿、几种主流的优化手段，以及实战中最容易踩的坑。适合刚接手长文本展示类App的开发者，也适合所有想系统解决长文本显示性能问题的人。1. 先搞清楚TextView为什么会在大文本上卡死1.1 一次setText背后到底发生了什么很多同学以为setText只是把字符串丢给TextView，顶多触发一次重绘。实际上远没有这么简单。当你调用setText时，TextView内部会做几件事：替换内部保存的CharSequence、把文本封装成SpannableStringBuilder（哪怕你传的是普通String，也会被包一层）、清空旧的Layout、然后requestLayout()和invalidate()。这里最关键的是Layout重建。TextView排版文本依赖android.text.Layout，大多数情况下使用的是DynamicLayout。构建DynamicLayout时，系统要基于字符宽度、字体、换行规则、Unicode双向算法逐行计算"每行该放哪些字符、在哪里断行"。这是一个和文本总行数成正比、但单行判断非常昂贵的操作。可以通俗地理解成：TextView每次setText就像安排一位排版师傅在主线程里把整本书重新断行排版，书越厚，这个师傅忙得越久。我用一个简单的Demo实测过：一份约10万字的纯文本，直接setText到标准TextView里，设备是普通中端机，setText方法从进入到返回耗时约800毫秒到1.2秒。这期间主线程完全被占住，用户点击、滑动全部无响应。如果是200万字的小说，几秒甚至十几秒的阻塞都有可能，直接触发ANR的"Application Not Responding"弹窗。1.2 卡顿的三个主要时间损耗：测量、布局、绘制要说清楚优化方向，得先把卡顿的时间花在哪里拆开。第一个大头是测量（Measure）。TextView的onMeasure会调用Layout去计算整个文本的排版结构，也就是我们刚才说的DynamicLayout构建。这个阶段不但要逐行算，还要处理一些极端情况，比如标点不能在行首、英文单词不能随意断行、Unicode特殊字符要按Bidi逻辑调整顺序，每一条规则都意味着额外的CPU计算。文本量一大，光测量就能吃掉几百毫秒。第二个是布局（Layout）。TextView自身在onLayout里的开销通常不大，但它有连锁反应。如果你把TextView放在LinearLayout、RelativeLayout这类非精确结构里，或者嵌套太深，父容器在本次布局阶段还得重新协商所有子View的位置。大文本场景里这一点容易被忽略，但实际对掉帧影响很大。第三个是绘制（Draw）。TextView绘制时会遍历所有可见文本行，逐个调用Canvas.drawText()。屏幕内可能只有40到60行，但如果你开启了硬件加速、又给TextView设置了阴影、半透明背景或者复杂drawable，每一帧的绘制成本都会上升。滚动大文本时，GPU每帧都要重新绘制可见区域，如果文本行本身还带有多个Span（比如高亮、加粗、下划线），绘制时间更会成倍增长。还有一个经常被忽视的地方：setText内部还会做一次字符数组的拷贝和包装。文本字符会从新传入的CharSequence复制到TextView持有的内部缓冲里，这个操作在Java层看是Arrays.copyOf，底层还要分配新对象。100万个字符就是约2MB的char数组，如果老数组没有及时释放，内存峰值会非常难看。1.3 内存与对象回收的隐形炸弹大文本卡顿不只是CPU的问题，内存和GC也很致命。用一个直观的数字来说明：一个char占2个字节，10万字的文本大约是200KB的字符数据，听起来不大。但TextView内部除了char数组，还会为Layout创建行高数组int[] lineHeight、每行的视觉起点数组、字符级width数组等。再加上SpannableStringBuilder的段落对象、Span对象等，整体内存放大倍数通常在5到10倍。也就是说一个10万字的TextView，实际占用的Java堆内存可能轻松超过1MB到2MB。问题在于如果用户连续打开多篇文章，旧页面没有被回收，或者在对大文本做二次操作（比如查找替换、加Span高亮），内存里同时存在多个大对象，GC必然频繁触发。一旦GC停顿落在用户滑动过程中，即使文本渲染本身没问题，也会产生肉眼可见的掉帧。这也是为什么我们做优化时不能只看CPU忙不忙，还要盯着内存分配和回收。1.4 为什么要先把根因归到"数据量"而不是"TextView"很多优化思路一开始就错了，总想着"我换一个更快的方法调用"或者"我用一个轻量级自定义View替代TextView"。但真正的核心矛盾是：一次性把海量数据丢给一个需要全量排版的组件。只要数据还是全量的，无论你怎么优化单次排版速度，总量摆在那里，迟早会撞上性能墙。所以成熟的优化方向基本都是"把数据拆小、把排版延迟、把不必要的计算去掉"。理解了这一点，后面的一切方案都顺理成章了。2. 动手优化前：先用Profiler把卡顿量化出来2.1 搭一个可复现的测试场景很多同学拿到问题就直接开始改代码，结果改完也不知道有没有效果。我的习惯是先搭一个可复现的Demo，把"卡顿"变成一组数字。最简单的做法是构造一份大文本，比如用StringBuilder循环拼接5000行文本，总量控制在300KB到500KB左右，然后在一个按钮点击里执行setText，同时计时。需要注意，冷启动后的第一次setText可能包含类加载和JIT热身，不够准确，所以我会先跑两三次垃圾数据，再正式计时。// 构造大文本 val sb = StringBuilder() for (i in 0 until 50000) { sb.append("第").append(i).append("行：") for (j in 0 until 20) { sb.append("测试文本用于模拟真实内容") } sb.append("\n") } val bigText = sb.toString() // 计时 val start = System.nanoTime() textView.setText(bigText) val costMs = (System.nanoTime() - start) / 1_000_000f Log.d("Perf", "setText cost: $costMs ms")这一步能给你一个精确的基线，比如"900毫秒"。后续每做一个优化动作，都回到这个场景里跑一遍，用同一个指标对比。没有基线就谈不上优化。2.2 用CPU Profiler和Memory Profiler定位热点如果只想确认是measure慢还是draw慢，直接在Android Studio里用CPU Profiler抓一个Method trace。操作步骤是：打开Profiler > 选择CPU > 点击Record > 在主线程执行一次setText > 停止录制。然后按"Main thread"过滤，看TextView.onMeasure、DynamicLayout.<init>、Layout.measureText这几个方法的耗时占比。正常情况下，你会发现DynamicLayout构建占了绝大部分时间，这就能验证之前的根因判断。内存方面，用Memory Profiler抓Heap Dump，按对象大小排序查看char[]、CharArrayBuffer、DynamicLayout$Builder等类型。大文本场景里char[]会非常显眼，它提醒你：即使只是显示不出来，数据在内存里的真实存在感也比想象中大得多。定位到具体热点后，再去选型优化方案才会目标清晰。2.3 把"任务能够接受吗"写进需求还有一件容易被忽略的事：和大文本显示需求方把参数问清楚。是纯文本还是富文本？需要全文实时编辑吗？支持查找和替换吗？必须用系统TextView的吗？这些约束决定了你能走哪条优化路线。比如如果只是"只读展示"，那完全可以走RecyclerView分页甚至自绘；如果需求方坚持要原生TextView且要支持光标和编辑，那方案范围就窄很多，只能做分段加载和异步化。提前在需求层面砍掉不必要的功能，是性价比最高的一步。3. 大文本加载的三大主流优化思路3.1 方案一：分段加载，把长篇拆成多个短篇分段加载是最容易理解也最容易落地的方案。核心思路是：不把全文一次性交给TextView，而是先把文本切成若干块，初始只显示第一块；用户滚动到末尾时，再追加下一块。这样任何时候TextView要处理的文本量都是可控的。具体到实现，我建议先把全文按固定大小切块。比如每块控制在8000到12000个字符。太小的块会频繁触发追加和排版，性能反而差；太大的块又回到"一次处理过多文本"的老问题。切块时要尽量在换行符处断开，避免把一个段落切成两半。界面上可以用一个ScrollView包住TextView，监听滚动位置，当scrollY + 可见高度 >= 总内容高度时，说明用户已经接近底部，此时才textView.append(下一块文本)。// 预先分块的伪代码 val chunks = text.chunked(10_000) // 按字符数切块，也可按行切 var currentIndex = 0 fun loadNextChunk() { if (currentIndex >= chunks.size) return val next = chunks[currentIndex++] textView.append(next) // append比重新setText更自然 }这里有几个细节要提醒。第一，不要用setText去覆盖全文，而是用append保留已有内容，否则用户好不容易滑到的位置会瞬间跳回顶部，体验非常差。第二，追加本身也会触发一次完整排版，所以每次追加后要记录当前滚动位置并恢复，用scrollView.scrollBy()或者先记录textView.getScrollY()再set回去。第三，追加块的大小要与滚动速度匹配，实测中用户快速下滑时可能一口气需要补多块，所以要用循环追加，直到满足"已经预加载到屏幕外一段距离"。分段加载解决的是"一次性阻塞时间过长"的问题，但它并不能让你免除每次追加时的全量重新排版。也就是说文本总量很大但每次增量不大的情况下，它的效果才最好。所以这个方案更适合日志流、小说阅读这类增量式阅读场景。3.2 方案二：RecyclerView按行渲染，用回收复用换性能如果你不想纠缠于手动控制View的滚动逻辑，另一个非常成熟的思路是：把大文本拆成多行或多段，交给RecyclerView来展示。每一条item就是一个TextView，只显示一小段文本。RecyclerView天生就帮我们解决了View回收复用和按需加载两个问题，屏幕外的item不会创建，滑入屏幕时才绑定数据。这个方案的关键在于"如何拆行"。对于本身就是一行一条数据的文本（比如日志、诗句、歌词），直接按\n切分即可。但对于没有换行的长文，就需要按字符数或显示宽度切分。更简单的方式是让每个item内部显示固定行数，比如每个item内部用TextView显示5到10行，然后往上抛Long文本，由TextView自身去换行。这样item数量不多，TextView的排版压力也小。data class PageItem(val text: String) class PageAdapter : RecyclerView.Adapter<PageViewHolder>() { override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): PageViewHolder { val view = LayoutInflater.from(parent.context) .inflate(R.layout.item_text_page, parent, false) return PageViewHolder(view) } override fun onBindViewHolder(holder: PageViewHolder, position: Int) { holder.textView.text = pages[position].text } }使用RecyclerView时，有几处优化必须做到位，否则依然会卡。第一，item_文本页的布局层级要尽量浅，不要套多层嵌套，最好就是根节点TextView加简单背景。第二，整个RecyclerView要设置setHasFixedSize(true)，让RecyclerView知道item高度不变，避免在滚动时反复测量。第三，如果文本内容可能出现图片、代码块等富文本，图片单独异步加载，不要把图片嵌在文本Span里，否则图文混排会让TextView在滚动时的绘制成本直线上升。这个方案特别适合结构化的大文本：日志系统、聊天记录、评论列表、运营公告列表。它的天然优势是天然分页、天然回收、天然支持下拉刷新上拉加载更多。唯一的问题是如果你要做的是一款阅读器，需要连续滚动阅读、精确分页、保存阅读进度，那么用RecyclerView强行切行会让"下一页""段落定位"变得非常别扭，此时更推荐下面要讲的自绘方案。3.3 方案三：自绘View + StaticLayout，只画看得见的部分自绘View是我个人最喜欢的手段，也是长文本性能优化的终极形态。思路是：不依赖TextView，而是继承View，在内部自行创建StaticLayout来排版文本，然后在onDraw()里只绘制当前可见区域的行。为什么StaticLayout能解决TextView的痛点？因为StaticLayout本身只是一个排版结果缓存对象，它不绑定任何View，不触发measure，也不强制要求你在主线程创建。你可以把整本小说的每一页预生成StaticLayout，缓存到内存里，滑动时直接从这个缓存中把对应页面的排版结果拿出来绘制，省掉了反复重建Layout的成本。核心实现至少包含两部分。第一，根据文本和宽度构建StaticLayout：val layout = StaticLayout.Builder .obtain(text, 0, text.length, textPaint, viewWidth) .build()第二，在onDraw里计算可见行区间并只绘制这些行。StaticLayout提供了getLineTop、getLineBottom、getLineForVertical等方法，可以很精确地定位哪一行该显示：override fun onDraw(canvas: Canvas) { super.onDraw(canvas) val scrollY = scrollY val firstLine = layout.getLineForVertical(scrollY) val lastLine = layout.getLineForVertical(scrollY + height) canvas.save() canvas.translate(0f, -scrollY.toFloat()) layout.draw(canvas, null, null, firstLine, lastLine) canvas.restore() }这段代码做的事情很纯粹：只绘制从第一可见行到最后一可见行之间的文本。屏幕外哪怕有几十万行，也与本次绘制无关。StaticLayout方案做得好，性能可以做到极大提升。我实测一份200万字的文本，预生成好Layout缓存后，滑动流畅度接近一个空列表，几乎没有掉帧。它的代价是开发复杂度高：需要自己处理滚动、触摸事件、点击选中、翻页动画、文本超链接等等一系列原本TextView免费提供的能力。因此我只推荐把它用在阅读器核心正文展示、代码编辑器行号区这类对性能和精确控制要求极高的场景。如果你没有精力承接这些额外逻辑，前面的分段加载或RecyclerView方案已经能解决绝大多数问题。4. 进阶优化：缓存、绘制与特殊场景的调优细节4.1 缓存策略：Layout缓存与页面置换不管用哪种方案，缓存都可以进一步拔高性能。对于StaticLayout方案，缓存的对象就是Layout实例。建议结合LruCache管理，缓存页数根据你的可用内存来定。比如每页文本约5000字，生成一个Layout大约几十KB，那么256MB的App内存环境下缓存20到40页是安全的。面料分页数据本身也可以缓存，比如解析后的章节文本、去掉空白字符的正文、切分好的段落列表。文本内容常常是"一次加工，多次展示"，如果每次都从原始文件重新解析和切分，既浪费IO又浪费CPU。我的经验是：解析后的数据缓存一份在内存里，再用一组WeakReference或者二级磁盘缓存兜底，防止内存不足时全部丢失需要重新解析。特别提醒：任何建立缓存的地方都要考虑失效问题。字体大小变化、系统字体缩放、日间夜间模式切换、语言切换，都会导致排版结果失效。你得在onConfigurationChanged或主题变化时主动清空Layout缓存，否则就会出现旧字号旧颜色的排版结果被新文本错误复用，视觉上非常奇怪。4.2 减少绘制开销：背景、阴影、透明度与硬件加速很多人的优化只关注measure阶段，忽略了draw阶段同样会卡。绘制大文本时，有几个成本点必须刻意规避。第一，背景尽量用纯色或简单的颜色，不要用复杂shape和渐变，更不要用多层背景叠加。每增加一层背景就意味着多一遍overdraw。可以打开开发者选项里的"显示过度绘制"检查，正常情况下大文本页面的overdraw要控制在2以内。第二，避免半透明。TextView如果设置了半透明背景，或者它的父容器使用了setAlpha，GPU绘制时不能直接合并图层，每帧都要做混合运算。文本内容本来就多，混合运算会让GPU负载成倍增长。第三，阴影慎用。setShadowLayer会给每个绘制的字符额外绘制一遍或两遍，加上模糊计算，滚动时非常吃GPU。如果非要阴影，建议直接放一张九宫格背景图，而不是用代码级shadow。第四，确认硬件加速已经开启。现在的Android默认都开启硬件加速，但如果你在自定义View里自己调用Canvas.drawText，不要关闭硬件加速，也不要手动setLayerType(LAYER_TYPE_SOFTWARE)，除非你明确知道自己在做什么。软件绘制大文本几乎必卡。4.3 特殊场景调优：全文搜索、高亮、图文混排再来看几个容易把人坑住的特殊场景。全文搜索与高亮是重灾区。很多实现是搜索到所有匹配位置后，给整篇文本一次性插入几十个ForegroundColorSpan或BackgroundColorSpan。这个过程至少有两个问题：一是构建大量Span对象本身就耗时，二是Span数量暴涨后DynamicLayout排版每条文本都要逐一处理这些Span，测量时间从几百毫秒直接涨到几秒。我的建议是：不要在全文上做高亮，而是只给当前可见区域的文本做高亮。具体做法是，根据滚动的首行末行，截取当前屏对应文本段，在子线程构建Spannable，再交给可见的TextView显示。用户滚动时连续更新高亮区间，既能看到高亮效果，又不会全量处理。图文混排是另一个常见性能杀手。用系统Spannable加载网络图片时，如果图片是异步加载完成后再去更新Span对象，会造成同一段文本反复排版。建议把正文和图片彻底分离：文本流中预留图片占位符，图片单独用一个ImageView层级去呈现，滚动时异步加载并只更新ImageView。这样图片加载不影响文本排版链路。代码编辑器、Markdown预览这类场景还要额外考虑语法高亮。语法高亮本质上又是给文本不断加Span。如果全文都做，性能会很难看。这类场景我通常采用按行分词高亮：只对当前可见行做正则匹配和Span生成，文本行滚出屏幕就丢弃对应Span，行的样式尽量用LineBackgroundSpan这类不影响断行的Span，因为它们不改变字符宽度，不会引起重新排版。4.4 异步化与任务调度，把耗时移出主线程在完成方案选型和缓存之后，最终还要把所有能挪出主线程的工作全部挪出去。最大的机会点是文本解析、切块、Span构建。这些操作完全不依赖UI，可以放心放到子线程。等子线程处理完，再通过runOnUiThread或Handler.post把最终结果交给View显示。viewModelScope.launch(Dispatchers.Default) { val chunks = parseBigText(originalText) // 耗时解析 withContext(Dispatchers.Main) { adapter.submitList(chunks) // 只是绑定数据 } }但注意，子线程的任务不能无限堆积。如果用户快速滑动翻页，你不需要预生成几百页的Layout，那样反而让内存爆掉。合理的方式是：只预生成当前页和前后各两页的Layout，滑动越过阈值后再生成新的。用CoroutineScope或Executor加一个任务队列，新的任务来时取消上一次没跑完的旧任务，避免做无用功。5. 实战中的常见问题、排查技巧与检查清单5.1 怎么区分"掉帧卡顿"和"ANR"经常有同学把两者混为一谈。掉帧是主线程单帧执行时间超过16.6ms，表现为滑动不跟手、有顿挫感，但系统还能响应，过一会儿会恢复。ANR是主线程被阻塞超过一定时间（一般5秒），系统直接弹"xxx无响应"对话框。大文本的setText在文本量足够大时可能同时引发两者。排查时，用Log记录setText方法耗时，超过100ms就会明显掉帧，超过5000ms必然ANR。如果你的App经常弹ANR提示，先检查主线程是不是直接FileInputStream读了大文件，或者直接setText了大文本。读文件这个动作经常被忽略，IO耗时可能比排版还高，记得把文件读取也放到子线程。5.2 大文本场景下内存暴涨怎么排查卡顿之外最直观的问题就是内存暴涨。打开Memory Profiler，用8GB以上RAM的中端模拟器，在加载大文本前后分别做一次Heap Dump，对比java.lang.String、char[]、StaticLayout等类型的内存占用。如果char[]占用比预想高很多，说明文本对象被复制了多份：原始String一份、SpannableStringBuilder内部一份、可能还有格式化输出的一份。解决方案是统一入口：从文件读取后只保留一份原始数据，所有后续处理尽量在原对象上操作，不要反复String.replace、String.format、+=，这些操作都会产生新的大对象。5.3 滚动时仍然掉帧怎么办如果分段加载都做了、RecyclerView也用了，滚动还是掉帧，那问题大概率出在绘制层。先用Profile的GPU渲染模式确认是不是绘制超时，再重点检查这几个方向：item布局是否正确精简、文本字体是否用了过重的字重（粗体比普通字重绘制成本高）、透明背景和阴影是否清干净、是否在大列表里使用了ConstraintLayout里的复杂约束。另一个可能点是RecyclerView的item没有固定高度导致每次scroll都重新测量，设置setHasFixedSize(true)能显著减少measure次数。5.4 一个可以直接抄作业的快速检查清单文本总数据量是否超过3万字符？超过就默认不能直接全文setText。是否需要编辑？不需要编辑一律走只读展示路线，能上分页就分页。是不是长按可选择、需要光标等TextView高级特性？如果有，优先分段加载而不是自绘。文本处理（解析、切块、搜索）是否已经全部移出主线程？页面是否有复杂背景、半透明、阴影？有就清理。是否在高亮全文Span？是就改成只高亮可见区。是否在滚动回调里频繁创建对象或发消息？是就改成阈值触发。有没有用Profiler跑过优化前后的baseline对比？没有就先去跑一份。// 快速判断是否需要做分页加载 val textLength = text.length when { textLength < 3_000 -> textView.text = text textLength < 30_000 -> textView.text = text // 但仍建议用分块加载 else -> setupPagedTextView(text) }这个检查清单不追求一次性解决所有问题，但它能帮你快速判断该走哪条路，避免在最容易踩坑的地方浪费时间。个人的经验是，大文本卡顿没有一招鲜的银弹。最理想的流程是：先量化数据、再拆解结构、再选择合适的展示容器，最后用缓存和异步化反复磨。如果让我给一句最核心的总结，那就是——永远不要让一个View一次性承接它不该承接的数据量。把文本拆小、把排版延后、把绘制精确到可见区，性能就能稳定住。特别是StaticLayout自绘方案，虽然上手成本高，但做文本阅读器这类项目时，一旦把Layout缓存和可见行绘制理顺，后面几乎不会再被长文本性能问题困扰。遇到类似场景不要慌，按这个思路一步步走，基本都能拿出一份合格的性能答卷。
做安卓开发久了，基本都遇到过这种问题：一段看似普通的TextView.setText()，传入一个几十万字的字符串，界面瞬间卡死。轻则掉帧明显，重则直接弹ANR对话框。这个问题的名字很直白——TextView加载大文本卡顿。它看起来只是"文本显示"，实际上牵扯到测量、布局、绘制、内存分配、回收复用等一系列环节。这篇文章我想完整梳理一下自己验证过的处理思路：根因是什么、怎么量化卡顿、几种主流的优化手段，以及实战中最容易踩的坑。适合刚接手长文本展示类App的开发者，也适合所有想系统解决长文本显示性能问题的人。1. 先搞清楚TextView为什么会在大文本上卡死1.1 一次setText背后到底发生了什么很多同学以为setText只是把字符串丢给TextView，顶多触发一次重绘。实际上远没有这么简单。当你调用setText时，TextView内部会做几件事：替换内部保存的CharSequence、把文本封装成SpannableStringBuilder（哪怕你传的是普通String，也会被包一层）、清空旧的Layout、然后requestLayout()和invalidate()。这里最关键的是Layout重建。TextView排版文本依赖android.text.Layout，大多数情况下使用的是DynamicLayout。构建DynamicLayout时，系统要基于字符宽度、字体、换行规则、Unicode双向算法逐行计算"每行该放哪些字符、在哪里断行"。这是一个和文本总行数成正比、但单行判断非常昂贵的操作。可以通俗地理解成：TextView每次setText就像安排一位排版师傅在主线程里把整本书重新断行排版，书越厚，这个师傅忙得越久。我用一个简单的Demo实测过：一份约10万字的纯文本，直接setText到标准TextView里，设备是普通中端机，setText方法从进入到返回耗时约800毫秒到1.2秒。这期间主线程完全被占住，用户点击、滑动全部无响应。如果是200万字的小说，几秒甚至十几秒的阻塞都有可能，直接触发ANR的"Application Not Responding"弹窗。1.2 卡顿的三个主要时间损耗：测量、布局、绘制要说清楚优化方向，得先把卡顿的时间花在哪里拆开。第一个大头是测量（Measure）。TextView的onMeasure会调用Layout去计算整个文本的排版结构，也就是我们刚才说的DynamicLayout构建。这个阶段不但要逐行算，还要处理一些极端情况，比如标点不能在行首、英文单词不能随意断行、Unicode特殊字符要按Bidi逻辑调整顺序，每一条规则都意味着额外的CPU计算。文本量一大，光测量就能吃掉几百毫秒。第二个是布局（Layout）。TextView自身在onLayout里的开销通常不大，但它有连锁反应。如果你把TextView放在LinearLayout、RelativeLayout这类非精确结构里，或者嵌套太深，父容器在本次布局阶段还得重新协商所有子View的位置。大文本场景里这一点容易被忽略，但实际对掉帧影响很大。第三个是绘制（Draw）。TextView绘制时会遍历所有可见文本行，逐个调用Canvas.drawText()。屏幕内可能只有40到60行，但如果你开启了硬件加速、又给TextView设置了阴影、半透明背景或者复杂drawable，每一帧的绘制成本都会上升。滚动大文本时，GPU每帧都要重新绘制可见区域，如果文本行本身还带有多个Span（比如高亮、加粗、下划线），绘制时间更会成倍增长。还有一个经常被忽视的地方：setText内部还会做一次字符数组的拷贝和包装。文本字符会从新传入的CharSequence复制到TextView持有的内部缓冲里，这个操作在Java层看是Arrays.copyOf，底层还要分配新对象。100万个字符就是约2MB的char数组，如果老数组没有及时释放，内存峰值会非常难看。1.3 内存与对象回收的隐形炸弹大文本卡顿不只是CPU的问题，内存和GC也很致命。用一个直观的数字来说明：一个char占2个字节，10万字的文本大约是200KB的字符数据，听起来不大。但TextView内部除了char数组，还会为Layout创建行高数组int[] lineHeight、每行的视觉起点数组、字符级width数组等。再加上SpannableStringBuilder的段落对象、Span对象等，整体内存放大倍数通常在5到10倍。也就是说一个10万字的TextView，实际占用的Java堆内存可能轻松超过1MB到2MB。问题在于如果用户连续打开多篇文章，旧页面没有被回收，或者在对大文本做二次操作（比如查找替换、加Span高亮），内存里同时存在多个大对象，GC必然频繁触发。一旦GC停顿落在用户滑动过程中，即使文本渲染本身没问题，也会产生肉眼可见的掉帧。这也是为什么我们做优化时不能只看CPU忙不忙，还要盯着内存分配和回收。1.4 为什么要先把根因归到"数据量"而不是"TextView"很多优化思路一开始就错了，总想着"我换一个更快的方法调用"或者"我用一个轻量级自定义View替代TextView"。但真正的核心矛盾是：一次性把海量数据丢给一个需要全量排版的组件。只要数据还是全量的，无论你怎么优化单次排版速度，总量摆在那里，迟早会撞上性能墙。所以成熟的优化方向基本都是"把数据拆小、把排版延迟、把不必要的计算去掉"。理解了这一点，后面的一切方案都顺理成章了。2. 动手优化前：先用Profiler把卡顿量化出来2.1 搭一个可复现的测试场景很多同学拿到问题就直接开始改代码，结果改完也不知道有没有效果。我的习惯是先搭一个可复现的Demo，把"卡顿"变成一组数字。最简单的做法是构造一份大文本，比如用StringBuilder循环拼接5000行文本，总量控制在300KB到500KB左右，然后在一个按钮点击里执行setText，同时计时。需要注意，冷启动后的第一次setText可能包含类加载和JIT热身，不够准确，所以我会先跑两三次垃圾数据，再正式计时。// 构造大文本 val sb = StringBuilder() for (i in 0 until 50000) { sb.append("第").append(i).append("行：") for (j in 0 until 20) { sb.append("测试文本用于模拟真实内容") } sb.append("\n") } val bigText = sb.toString() // 计时 val start = System.nanoTime() textView.setText(bigText) val costMs = (System.nanoTime() - start) / 1_000_000f Log.d("Perf", "setText cost: $costMs ms")这一步能给你一个精确的基线，比如"900毫秒"。后续每做一个优化动作，都回到这个场景里跑一遍，用同一个指标对比。没有基线就谈不上优化。2.2 用CPU Profiler和Memory Profiler定位热点如果只想确认是measure慢还是draw慢，直接在Android Studio里用CPU Profiler抓一个Method trace。操作步骤是：打开Profiler > 选择CPU > 点击Record > 在主线程执行一次setText > 停止录制。然后按"Main thread"过滤，看TextView.onMeasure、DynamicLayout.<init>、Layout.measureText这几个方法的耗时占比。正常情况下，你会发现DynamicLayout构建占了绝大部分时间，这就能验证之前的根因判断。内存方面，用Memory Profiler抓Heap Dump，按对象大小排序查看char[]、CharArrayBuffer、DynamicLayout$Builder等类型。大文本场景里char[]会非常显眼，它提醒你：即使只是显示不出来，数据在内存里的真实存在感也比想象中大得多。定位到具体热点后，再去选型优化方案才会目标清晰。2.3 把"任务能够接受吗"写进需求还有一件容易被忽略的事：和大文本显示需求方把参数问清楚。是纯文本还是富文本？需要全文实时编辑吗？支持查找和替换吗？必须用系统TextView的吗？这些约束决定了你能走哪条优化路线。比如如果只是"只读展示"，那完全可以走RecyclerView分页甚至自绘；如果需求方坚持要原生TextView且要支持光标和编辑，那方案范围就窄很多，只能做分段加载和异步化。提前在需求层面砍掉不必要的功能，是性价比最高的一步。3. 大文本加载的三大主流优化思路3.1 方案一：分段加载，把长篇拆成多个短篇分段加载是最容易理解也最容易落地的方案。核心思路是：不把全文一次性交给TextView，而是先把文本切成若干块，初始只显示第一块；用户滚动到末尾时，再追加下一块。这样任何时候TextView要处理的文本量都是可控的。具体到实现，我建议先把全文按固定大小切块。比如每块控制在8000到12000个字符。太小的块会频繁触发追加和排版，性能反而差；太大的块又回到"一次处理过多文本"的老问题。切块时要尽量在换行符处断开，避免把一个段落切成两半。界面上可以用一个ScrollView包住TextView，监听滚动位置，当scrollY + 可见高度 >= 总内容高度时，说明用户已经接近底部，此时才textView.append(下一块文本)。// 预先分块的伪代码 val chunks = text.chunked(10_000) // 按字符数切块，也可按行切 var currentIndex = 0 fun loadNextChunk() { if (currentIndex >= chunks.size) return val next = chunks[currentIndex++] textView.append(next) // append比重新setText更自然 }这里有几个细节要提醒。第一，不要用setText去覆盖全文，而是用append保留已有内容，否则用户好不容易滑到的位置会瞬间跳回顶部，体验非常差。第二，追加本身也会触发一次完整排版，所以每次追加后要记录当前滚动位置并恢复，用scrollView.scrollBy()或者先记录textView.getScrollY()再set回去。第三，追加块的大小要与滚动速度匹配，实测中用户快速下滑时可能一口气需要补多块，所以要用循环追加，直到满足"已经预加载到屏幕外一段距离"。分段加载解决的是"一次性阻塞时间过长"的问题，但它并不能让你免除每次追加时的全量重新排版。也就是说文本总量很大但每次增量不大的情况下，它的效果才最好。所以这个方案更适合日志流、小说阅读这类增量式阅读场景。3.2 方案二：RecyclerView按行渲染，用回收复用换性能如果你不想纠缠于手动控制View的滚动逻辑，另一个非常成熟的思路是：把大文本拆成多行或多段，交给RecyclerView来展示。每一条item就是一个TextView，只显示一小段文本。RecyclerView天生就帮我们解决了View回收复用和按需加载两个问题，屏幕外的item不会创建，滑入屏幕时才绑定数据。这个方案的关键在于"如何拆行"。对于本身就是一行一条数据的文本（比如日志、诗句、歌词），直接按\n切分即可。但对于没有换行的长文，就需要按字符数或显示宽度切分。更简单的方式是让每个item内部显示固定行数，比如每个item内部用TextView显示5到10行，然后往上抛Long文本，由TextView自身去换行。这样item数量不多，TextView的排版压力也小。data class PageItem(val text: String) class PageAdapter : RecyclerView.Adapter<PageViewHolder>() { override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): PageViewHolder { val view = LayoutInflater.from(parent.context) .inflate(R.layout.item_text_page, parent, false) return PageViewHolder(view) } override fun onBindViewHolder(holder: PageViewHolder, position: Int) { holder.textView.text = pages[position].text } }使用RecyclerView时，有几处优化必须做到位，否则依然会卡。第一，item_文本页的布局层级要尽量浅，不要套多层嵌套，最好就是根节点TextView加简单背景。第二，整个RecyclerView要设置setHasFixedSize(true)，让RecyclerView知道item高度不变，避免在滚动时反复测量。第三，如果文本内容可能出现图片、代码块等富文本，图片单独异步加载，不要把图片嵌在文本Span里，否则图文混排会让TextView在滚动时的绘制成本直线上升。这个方案特别适合结构化的大文本：日志系统、聊天记录、评论列表、运营公告列表。它的天然优势是天然分页、天然回收、天然支持下拉刷新上拉加载更多。唯一的问题是如果你要做的是一款阅读器，需要连续滚动阅读、精确分页、保存阅读进度，那么用RecyclerView强行切行会让"下一页""段落定位"变得非常别扭，此时更推荐下面要讲的自绘方案。3.3 方案三：自绘View + StaticLayout，只画看得见的部分自绘View是我个人最喜欢的手段，也是长文本性能优化的终极形态。思路是：不依赖TextView，而是继承View，在内部自行创建StaticLayout来排版文本，然后在onDraw()里只绘制当前可见区域的行。为什么StaticLayout能解决TextView的痛点？因为StaticLayout本身只是一个排版结果缓存对象，它不绑定任何View，不触发measure，也不强制要求你在主线程创建。你可以把整本小说的每一页预生成StaticLayout，缓存到内存里，滑动时直接从这个缓存中把对应页面的排版结果拿出来绘制，省掉了反复重建Layout的成本。核心实现至少包含两部分。第一，根据文本和宽度构建StaticLayout：val layout = StaticLayout.Builder .obtain(text, 0, text.length, textPaint, viewWidth) .build()第二，在onDraw里计算可见行区间并只绘制这些行。StaticLayout提供了getLineTop、getLineBottom、getLineForVertical等方法，可以很精确地定位哪一行该显示：override fun onDraw(canvas: Canvas) { super.onDraw(canvas) val scrollY = scrollY val firstLine = layout.getLineForVertical(scrollY) val lastLine = layout.getLineForVertical(scrollY + height) canvas.save() canvas.translate(0f, -scrollY.toFloat()) layout.draw(canvas, null, null, firstLine, lastLine) canvas.restore() }这段代码做的事情很纯粹：只绘制从第一可见行到最后一可见行之间的文本。屏幕外哪怕有几十万行，也与本次绘制无关。StaticLayout方案做得好，性能可以做到极大提升。我实测一份200万字的文本，预生成好Layout缓存后，滑动流畅度接近一个空列表，几乎没有掉帧。它的代价是开发复杂度高：需要自己处理滚动、触摸事件、点击选中、翻页动画、文本超链接等等一系列原本TextView免费提供的能力。因此我只推荐把它用在阅读器核心正文展示、代码编辑器行号区这类对性能和精确控制要求极高的场景。如果你没有精力承接这些额外逻辑，前面的分段加载或RecyclerView方案已经能解决绝大多数问题。4. 进阶优化：缓存、绘制与特殊场景的调优细节4.1 缓存策略：Layout缓存与页面置换不管用哪种方案，缓存都可以进一步拔高性能。对于StaticLayout方案，缓存的对象就是Layout实例。建议结合LruCache管理，缓存页数根据你的可用内存来定。比如每页文本约5000字，生成一个Layout大约几十KB，那么256MB的App内存环境下缓存20到40页是安全的。面料分页数据本身也可以缓存，比如解析后的章节文本、去掉空白字符的正文、切分好的段落列表。文本内容常常是"一次加工，多次展示"，如果每次都从原始文件重新解析和切分，既浪费IO又浪费CPU。我的经验是：解析后的数据缓存一份在内存里，再用一组WeakReference或者二级磁盘缓存兜底，防止内存不足时全部丢失需要重新解析。特别提醒：任何建立缓存的地方都要考虑失效问题。字体大小变化、系统字体缩放、日间夜间模式切换、语言切换，都会导致排版结果失效。你得在onConfigurationChanged或主题变化时主动清空Layout缓存，否则就会出现旧字号旧颜色的排版结果被新文本错误复用，视觉上非常奇怪。4.2 减少绘制开销：背景、阴影、透明度与硬件加速很多人的优化只关注measure阶段，忽略了draw阶段同样会卡。绘制大文本时，有几个成本点必须刻意规避。第一，背景尽量用纯色或简单的颜色，不要用复杂shape和渐变，更不要用多层背景叠加。每增加一层背景就意味着多一遍overdraw。可以打开开发者选项里的"显示过度绘制"检查，正常情况下大文本页面的overdraw要控制在2以内。第二，避免半透明。TextView如果设置了半透明背景，或者它的父容器使用了setAlpha，GPU绘制时不能直接合并图层，每帧都要做混合运算。文本内容本来就多，混合运算会让GPU负载成倍增长。第三，阴影慎用。setShadowLayer会给每个绘制的字符额外绘制一遍或两遍，加上模糊计算，滚动时非常吃GPU。如果非要阴影，建议直接放一张九宫格背景图，而不是用代码级shadow。第四，确认硬件加速已经开启。现在的Android默认都开启硬件加速，但如果你在自定义View里自己调用Canvas.drawText，不要关闭硬件加速，也不要手动setLayerType(LAYER_TYPE_SOFTWARE)，除非你明确知道自己在做什么。软件绘制大文本几乎必卡。4.3 特殊场景调优：全文搜索、高亮、图文混排再来看几个容易把人坑住的特殊场景。全文搜索与高亮是重灾区。很多实现是搜索到所有匹配位置后，给整篇文本一次性插入几十个ForegroundColorSpan或BackgroundColorSpan。这个过程至少有两个问题：一是构建大量Span对象本身就耗时，二是Span数量暴涨后DynamicLayout排版每条文本都要逐一处理这些Span，测量时间从几百毫秒直接涨到几秒。我的建议是：不要在全文上做高亮，而是只给当前可见区域的文本做高亮。具体做法是，根据滚动的首行末行，截取当前屏对应文本段，在子线程构建Spannable，再交给可见的TextView显示。用户滚动时连续更新高亮区间，既能看到高亮效果，又不会全量处理。图文混排是另一个常见性能杀手。用系统Spannable加载网络图片时，如果图片是异步加载完成后再去更新Span对象，会造成同一段文本反复排版。建议把正文和图片彻底分离：文本流中预留图片占位符，图片单独用一个ImageView层级去呈现，滚动时异步加载并只更新ImageView。这样图片加载不影响文本排版链路。代码编辑器、Markdown预览这类场景还要额外考虑语法高亮。语法高亮本质上又是给文本不断加Span。如果全文都做，性能会很难看。这类场景我通常采用按行分词高亮：只对当前可见行做正则匹配和Span生成，文本行滚出屏幕就丢弃对应Span，行的样式尽量用LineBackgroundSpan这类不影响断行的Span，因为它们不改变字符宽度，不会引起重新排版。4.4 异步化与任务调度，把耗时移出主线程在完成方案选型和缓存之后，最终还要把所有能挪出主线程的工作全部挪出去。最大的机会点是文本解析、切块、Span构建。这些操作完全不依赖UI，可以放心放到子线程。等子线程处理完，再通过runOnUiThread或Handler.post把最终结果交给View显示。viewModelScope.launch(Dispatchers.Default) { val chunks = parseBigText(originalText) // 耗时解析 withContext(Dispatchers.Main) { adapter.submitList(chunks) // 只是绑定数据 } }但注意，子线程的任务不能无限堆积。如果用户快速滑动翻页，你不需要预生成几百页的Layout，那样反而让内存爆掉。合理的方式是：只预生成当前页和前后各两页的Layout，滑动越过阈值后再生成新的。用CoroutineScope或Executor加一个任务队列，新的任务来时取消上一次没跑完的旧任务，避免做无用功。5. 实战中的常见问题、排查技巧与检查清单5.1 怎么区分"掉帧卡顿"和"ANR"经常有同学把两者混为一谈。掉帧是主线程单帧执行时间超过16.6ms，表现为滑动不跟手、有顿挫感，但系统还能响应，过一会儿会恢复。ANR是主线程被阻塞超过一定时间（一般5秒），系统直接弹"xxx无响应"对话框。大文本的setText在文本量足够大时可能同时引发两者。排查时，用Log记录setText方法耗时，超过100ms就会明显掉帧，超过5000ms必然ANR。如果你的App经常弹ANR提示，先检查主线程是不是直接FileInputStream读了大文件，或者直接setText了大文本。读文件这个动作经常被忽略，IO耗时可能比排版还高，记得把文件读取也放到子线程。5.2 大文本场景下内存暴涨怎么排查卡顿之外最直观的问题就是内存暴涨。打开Memory Profiler，用8GB以上RAM的中端模拟器，在加载大文本前后分别做一次Heap Dump，对比java.lang.String、char[]、StaticLayout等类型的内存占用。如果char[]占用比预想高很多，说明文本对象被复制了多份：原始String一份、SpannableStringBuilder内部一份、可能还有格式化输出的一份。解决方案是统一入口：从文件读取后只保留一份原始数据，所有后续处理尽量在原对象上操作，不要反复String.replace、String.format、+=，这些操作都会产生新的大对象。5.3 滚动时仍然掉帧怎么办如果分段加载都做了、RecyclerView也用了，滚动还是掉帧，那问题大概率出在绘制层。先用Profile的GPU渲染模式确认是不是绘制超时，再重点检查这几个方向：item布局是否正确精简、文本字体是否用了过重的字重（粗体比普通字重绘制成本高）、透明背景和阴影是否清干净、是否在大列表里使用了ConstraintLayout里的复杂约束。另一个可能点是RecyclerView的item没有固定高度导致每次scroll都重新测量，设置setHasFixedSize(true)能显著减少measure次数。5.4 一个可以直接抄作业的快速检查清单文本总数据量是否超过3万字符？超过就默认不能直接全文setText。是否需要编辑？不需要编辑一律走只读展示路线，能上分页就分页。是不是长按可选择、需要光标等TextView高级特性？如果有，优先分段加载而不是自绘。文本处理（解析、切块、搜索）是否已经全部移出主线程？页面是否有复杂背景、半透明、阴影？有就清理。是否在高亮全文Span？是就改成只高亮可见区。是否在滚动回调里频繁创建对象或发消息？是就改成阈值触发。有没有用Profiler跑过优化前后的baseline对比？没有就先去跑一份。// 快速判断是否需要做分页加载 val textLength = text.length when { textLength < 3_000 -> textView.text = text textLength < 30_000 -> textView.text = text // 但仍建议用分块加载 else -> setupPagedTextView(text) }这个检查清单不追求一次性解决所有问题，但它能帮你快速判断该走哪条路，避免在最容易踩坑的地方浪费时间。个人的经验是，大文本卡顿没有一招鲜的银弹。最理想的流程是：先量化数据、再拆解结构、再选择合适的展示容器，最后用缓存和异步化反复磨。如果让我给一句最核心的总结，那就是——永远不要让一个View一次性承接它不该承接的数据量。把文本拆小、把排版延后、把绘制精确到可见区，性能就能稳定住。特别是StaticLayout自绘方案，虽然上手成本高，但做文本阅读器这类项目时，一旦把Layout缓存和可见行绘制理顺，后面几乎不会再被长文本性能问题困扰。遇到类似场景不要慌，按这个思路一步步走，基本都能拿出一份合格的性能答卷。