PrecomputedText如字面意义一样，是用来预先计算文本的。它的诞生也是因为计算文本是一个耗时操作，它需要根据字号、字体、样式、换行等去计算，并且这个计算时间随着文字数量的增加而增加。如果这时显示的列表中恰好是这种多行的文字，那么滑动起来岂不是会掉帧，影响着用户体验。比如微博这类的产品，列表就非常的复杂。
其实在Android 4.0 中底层就有引入TextLayoutCache来解决这个问题，每个测量过的文字都被添加到缓存中，下次需要相同的文字时，可以从缓存中获取，不用在测量。不过缓存大小只有0.5 MB。并且在没有缓存之前，我们的首次滑动还是UI线程耗时的。为了解决这类问题，Android 9.0中添加了PrecomputedText 。据说测量的耗时减少了95%，具体对比可以参看文末的链接。
使用方法
-
compileSdkVersion为28以上，appcompat库28.0.0或androidx appcompat 1.0.0以上 -
使用
AppCompatTextView来替换TextView -
使用
setTextFuture替换setText方法
代码如下：
Future<PrecomputedTextCompat> future = PrecomputedTextCompat.getTextFuture(
“text”, textView.getTextMetricsParamsCompat(), null)；
textView.setTextFuture(future);
当然如果你使用kotlin，那么利用拓展方法会更加酸爽。
fun AppCompatTextView.setTextFuture(charSequence: CharSequence){
this.setTextFuture(PrecomputedTextCompat.getTextFuture(
charSequence,
TextViewCompat.getTextMetricsParams(this),
null
))
}
// 一行调用
textView.setTextFuture(“text”)
实现原理
其实PrecomputedText实现原理很简单，就是将耗时的测量放到了异步去执行。
@UiThread
public static Future<PrecomputedTextCompat> getTextFuture(@NonNull CharSequence charSequence, @NonNull PrecomputedTextCompat.Params params, @Nullable Executor executor) {
PrecomputedTextCompat.PrecomputedTextFutureTask task = new PrecomputedTextCompat.PrecomputedTextFutureTask(params, charSequence);
if (executor == null) {
Object var4 = sLock;
synchronized(sLock) {
if (sExecutor == null) {
sExecutor = Executors.newFixedThreadPool(1);
}
executor = sExecutor;
}
}
executor.execute(task);
return task;
}
通过调用consumeTextFutureAndSetBlocking方法的future.get()阻塞计算线程来获取计算结果，最终setText到对用的TextView上。
public void setTextFuture(@NonNull Future<PrecomputedTextCompat> future) {
this.mPrecomputedTextFuture = future;
this.requestLayout();
}
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
this.consumeTextFutureAndSetBlocking();
super.onMeasure(widthMeasureSpec, heightMeasureSpec);
}
private void consumeTextFutureAndSetBlocking() {
if (this.mPrecomputedTextFuture != null) {
try {
Future<PrecomputedTextCompat> future = this.mPrecomputedTextFuture;
this.mPrecomputedTextFuture = null;
TextViewCompat.setPrecomputedText(this, (PrecomputedTextCompat)future.get());
} catch (ExecutionException | InterruptedException var2) {
;
}
}
}
新的问题
在看PrecomputedText时，在Github上找到了一个相关的Demo，这其中发现使用后造成了负优化。
这个例子中，一个item上有三个AppCompatTextView并且字号都很小，导致一屏幕可以看到十段左右的文字，当然使用了PrecomputedText优化后，onBindViewHolder方法的执行时间大大的缩短了，但是却检测到了新的问题。
首先我们要了解滑动列表的速度越快，那么单位时间内测量绘制的内容也就越多。我对使用前后进行了三种速度的测试，分别是慢速（1s滑动1次，力度小）、中速（1s滑动2次，力度中）、快速（1s滑动3次，力度大）得到了下面的结论。（纯手工滑动，真的累。。。）
具体的Systrace结果图我就不全部展示了，这里展示一下中速滑动前后结果。
代表Animation和Input的浅绿色竖条增高了。
| 问题/速度 | 慢速 | 中速 | 快速 |
|---|---|---|---|
| Scheduling delay | 4 -> 46 | 5 -> 39 | 8 -> 17 |
| Long View#draw() | 18 -> 12 | 37 -> 30 | 50 -> 48 |
| Expensive measure/layout pass | 1 -> 0 | 0 | 0 |
Scheduling delay 就是一个线程在处理一块运算的时候，在很长一段时间都没有被CPU调度，从而导致这个线程在很长一段时间都没有完成工作。
可以看到使用PrecomputedText后，Scheduling delay 问题会有一定概率激增，甚至更加严重。对比发现激增点都是因为dequeueBuffer 这里等待时间过长，比如下面 dequeueBuffer 的片段cpu实际执行了0.119ms，但是总耗时了10.035ms。
其实仔细观察，dequeueBuffer 在一开始就已经执行完成，但是却处在等待cpu调度来执行下一步的地方。这里其实就是等待SurfaceFlinger执行导致的。如下图：
这里的耗时，会使通知 CPU 延迟，导致的Scheduling delay 。具体为何高概率触发这类问题的原因这里还不清楚。猜测是文本本身很复杂，一段文字中不同字号、颜色、样式，并且页面上同时存在十多个这样的段落。这样的话就短时间内会有十多次线程的切换来实现文字的异步测量，势必会有性能影响。
我后面将文字字体设置大了以后，发现这个问题就好多了。所以PrecomputedText的使用还是需要根据场景来使用，否则会矫枉过正。
总结
-
不要滥用
PrecomputedText，对于一两行文字来说并没有很大的提升，反而会造成不必要的Scheduling delay，建议文本200个字符以上使用。 -
不要在
TextViewCompat.getTextMetricsParams()方法后修改textview的属性。比如设置字号放到前面执行。 -
PrecomputedTextCompat在9.0以上使用PrecomputedText优化，5.0~9.0使用StaticLayout优化，5.0以下的不做处理。 -
如果您已禁用
RecyclerView的预取（Prefetch），则PrecomputedText无效。如果您使用自定义LayoutManager，请确保它实现collectAdjacentPrefetchPositions()以便RecyclerView知道要预取的项目。因此ListView无法享受到PrecomputedText带来的性能优化。
具体kotlin示例可以看 PrecomputedTextCompatExample ，里面也有使用协程的优化方案。我也写了一个对应的java示例。
效果如下：
| normal | PrecomputedText future | PrecomputedText coroutine |
|---|---|---|
 |
 |
 |
最后如果对你有帮助，希望点赞支持！！
