Android 9.0中的新功能 - PrecomputedText

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

最后若是对你有帮助，但愿点赞支持！！

参考

• Use Android Text Like a Pro

• What is new in Android P?—?PrecomputedText

• Prefetch Text Layout in RecyclerView