Android TextView.setText() 引发的卡顿问题

2024-02-22 08:52

本文主要是介绍Android TextView.setText() 引发的卡顿问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

在 Android 开发中,TextView 是一个非常基础和常用的用户界面组件,用于在屏幕上显示文本内容。TextView 继承自 View 类,并提供了展示文本以及相关样式处理的功能。

TextView 允许开发者在应用程序的用户界面中显示格式化的文本内容。它支持修改字体大小、字体颜色、文本对齐方式、行间距等多种属性来控制文本的显示样式。同时,TextView 也支持一些高级功能,如文本阴影、文本装饰(如下划线和删除线)、跑马灯效果(文本的滚动显示)等。


最近在检测性能中,发现 RecycleView 在滑动过程中的 TextView.setText() 有一些耗时,从主观上体验也会有一点卡顿,然后进入源码看看是怎么回事:

    @UnsupportedAppUsageprivate void setText(CharSequence text, BufferType type,boolean notifyBefore, int oldlen) {// ...if (mLayout != null) {checkForRelayout();}}

 setText() 的代码量还不少,看到有个 checkForRelayout(),进去看看

    @UnsupportedAppUsageprivate void checkForRelayout() {if ((mLayoutParams.width != LayoutParams.WRAP_CONTENT || //...)) {//...requestLayout();invalidate();} else {nullLayouts();requestLayout();invalidate();}}

在 checkForRelayout() 当中,是一定会调用 requestLayout() 的,也就是说 TextView.setText() 通常是会调用 requestLayout()

首先需要复习一下 Android 的布局流程


测量阶段(Measure)
在这个阶段,系统会根据视图的 LayoutParams 和父布局的规格,递归地计算出每一个视图的尺寸大小(即宽度和高度)。这个过程涉及到调用每个视图的 onMeasure(int widthMeasureSpec, int heightMeasureSpec) 方法。

布局阶段(Layout)
测量完成之后,系统会知道所有视图的大小,接下来就是确定它们在父布局中的位置。这个过程涉及到调用每个视图的 onLayout(boolean changed, int left, int top, int right, int bottom) 方法。

绘制阶段(Draw)
最后是绘制过程,系统会调用每个视图的 onDraw(Canvas canvas) 方法,将视图绘制到屏幕上。


当调用 requestLayout() 方法时,它会标记这个视图树需要一个新的布局,系统会安排一个新的布局过程,在这个过程中会重新执行测量(Measure)和布局(Layout)步骤

而测量和布局阶段都可能是耗时的操作,特别是在复杂的布局结构或大型视图树中。这是因为测量和布局阶段需要计算视图及其子视图的尺寸和位置,并且这个计算可能是递归的。

对于一个单独的 TextView 而言,调用 setText() 后重新进行测量、布局和绘制来更新视图没什么问题。但是当在 RecycleView 中,TextView 很多情况下只是单纯的更换 String,布局不会发生改动。这个时候我们就可以自定义一个在 setText() 时不会 requestLayout() 的 TextView 来优化性能


为了能和 TextView 一样在 xml 上设置属性,需要在 style 文件增加:

<resources><declare-styleable name="SimpleTextView"><attr name="android:text" format="string" /><attr name="android:textColor" format="color" /><attr name="android:textSize" format="dimension|reference" /><attr name="android:singleLine" format="boolean" /><attr name="android:textStyle"><enum name="normal" value="0" /><enum name="bold" value="1" /><enum name="italic" value="2" /></attr></declare-styleable>
</resources>

自定义的 TextView:

class SimpleTextView @JvmOverloads constructor(context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0
) : View(context, attrs, defStyleAttr) {private var text: String? = ""private var singleLine = falseprivate val textPaint = TextPaint(Paint.ANTI_ALIAS_FLAG)init {val typedArray = context.obtainStyledAttributes(attrs, R.styleable.SimpleTextView)text = typedArray.getString(R.styleable.SimpleTextView_android_text) ?: ""singleLine = typedArray.getBoolean(R.styleable.SimpleTextView_android_singleLine, false)textPaint.color = typedArray.getColor(R.styleable.SimpleTextView_android_textColor, Color.BLACK)textPaint.textSize = typedArray.getDimensionPixelSize(R.styleable.SimpleTextView_android_textSize, 40).toFloat()textPaint.typeface = Typeface.create(Typeface.DEFAULT, typedArray.getInt(R.styleable.SimpleTextView_android_textStyle, 0))typedArray.recycle()}override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {val minHeight = paddingTop + textPaint.descent() - textPaint.ascent() + paddingBottom// 设置视图大小setMeasuredDimension(widthMeasureSpec,resolveSize(minHeight.toInt(), heightMeasureSpec))}override fun onDraw(canvas: Canvas?) {super.onDraw(canvas)canvas ?: returnval baseline = paddingTop - textPaint.ascent() // 文本基线val textWidth = width - paddingLeft - paddingRight // 文本显示宽度val textToShow = if (singleLine && textPaint.measureText(text) > textWidth) {TextUtils.ellipsize(text, textPaint, textWidth.toFloat(), TextUtils.TruncateAt.END).toString()} else {text}// 绘制文本canvas.drawText(textToShow!!, paddingLeft.toFloat(), baseline, textPaint)}fun setText(text: String?) {text ?: returnthis.text = text}
}

这里我在 onMeasure 设置视图大小的时候,宽度给的是最大值,因为只测量一次,之后输入的文本长度即使是不一样的,也都能够兼容到。配合 singleLine 的效果,就能做到高性能的单行显示效果了


本片文章的核心思想是减少 RecycleView 中 TextView 不必要的测量和布局步骤,从而优化卡顿问题。若 TextView 的测量、布局和绘制都是必要的,则需要从其他方面去入手优化了

这篇关于Android TextView.setText() 引发的卡顿问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/734740

相关文章

Android kotlin中 Channel 和 Flow 的区别和选择使用场景分析

《Androidkotlin中Channel和Flow的区别和选择使用场景分析》Kotlin协程中,Flow是冷数据流,按需触发,适合响应式数据处理;Channel是热数据流,持续发送,支持... 目录一、基本概念界定FlowChannel二、核心特性对比数据生产触发条件生产与消费的关系背压处理机制生命周期

Android ClassLoader加载机制详解

《AndroidClassLoader加载机制详解》Android的ClassLoader负责加载.dex文件,基于双亲委派模型,支持热修复和插件化,需注意类冲突、内存泄漏和兼容性问题,本文给大家介... 目录一、ClassLoader概述1.1 类加载的基本概念1.2 android与Java Class

怎样通过分析GC日志来定位Java进程的内存问题

《怎样通过分析GC日志来定位Java进程的内存问题》:本文主要介绍怎样通过分析GC日志来定位Java进程的内存问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、GC 日志基础配置1. 启用详细 GC 日志2. 不同收集器的日志格式二、关键指标与分析维度1.

Java 线程安全与 volatile与单例模式问题及解决方案

《Java线程安全与volatile与单例模式问题及解决方案》文章主要讲解线程安全问题的五个成因(调度随机、变量修改、非原子操作、内存可见性、指令重排序)及解决方案,强调使用volatile关键字... 目录什么是线程安全线程安全问题的产生与解决方案线程的调度是随机的多个线程对同一个变量进行修改线程的修改操

Redis出现中文乱码的问题及解决

《Redis出现中文乱码的问题及解决》:本文主要介绍Redis出现中文乱码的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1. 问题的产生2China编程. 问题的解决redihttp://www.chinasem.cns数据进制问题的解决中文乱码问题解决总结

全面解析MySQL索引长度限制问题与解决方案

《全面解析MySQL索引长度限制问题与解决方案》MySQL对索引长度设限是为了保持高效的数据检索性能,这个限制不是MySQL的缺陷,而是数据库设计中的权衡结果,下面我们就来看看如何解决这一问题吧... 目录引言:为什么会有索引键长度问题?一、问题根源深度解析mysql索引长度限制原理实际场景示例二、五大解决

Springboot如何正确使用AOP问题

《Springboot如何正确使用AOP问题》:本文主要介绍Springboot如何正确使用AOP问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录​一、AOP概念二、切点表达式​execution表达式案例三、AOP通知四、springboot中使用AOP导出

Python中Tensorflow无法调用GPU问题的解决方法

《Python中Tensorflow无法调用GPU问题的解决方法》文章详解如何解决TensorFlow在Windows无法识别GPU的问题,需降级至2.10版本,安装匹配CUDA11.2和cuDNN... 当用以下代码查看GPU数量时,gpuspython返回的是一个空列表,说明tensorflow没有找到

解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘问题

《解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘问题》:本文主要介绍解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4... 目录未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘打开pom.XM

IDEA Maven提示:未解析的依赖项的问题及解决

《IDEAMaven提示:未解析的依赖项的问题及解决》:本文主要介绍IDEAMaven提示:未解析的依赖项的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝... 目录IDEA Maven提示:未解析的依编程赖项例如总结IDEA Maven提示:未解析的依赖项例如