查看原文
其他

Android 9 官方极致优化 PrecomputedText

唯鹿 鸿洋 2019-04-23

本文作者


作者:唯鹿

链接:

https://juejin.im/post/5cb3e62ae51d456e2809fb72

本文由作者授权发布。


1概述


PrecomputedText 如字面意义一样,是用来预先计算文本的。它的诞生也是因为计算文本是一个耗时操作,它需要根据字号、字体、样式、换行等去计算,并且这个计算时间随着文字数量的增加而增加。如果这时显示的列表中恰好是这种多行的文字,那么滑动起来岂不是会掉帧,影响着用户体验。比如微博这类的产品,列表就非常的复杂。


其实在Android 4.0 中底层就有引入TextLayoutCache来解决这个问题,每个测量过的文字都被添加到缓存中,下次需要相同的文字时,可以从缓存中获取,不用在测量。不过缓存大小只有0.5 MB。并且在没有缓存之前,我们的首次滑动还是UI线程耗时的。


为了解决这类问题,Android 9.0中添加了PrecomputedText 。


据说测量的耗时减少了95%,具体对比可以参看文末的链接。


2使用方法


  1. compileSdkVersion为28以上,appcompat库28.0.0或androidx appcompat 1.0.0以上

  2. 使用AppCompatTextView来替换TextView

  3. 使用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”)


3实现原理


其实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上。


@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;
}


4新的问题


在看PrecomputedText时,在Github上找到了一个相关的Demo,这其中发现使用后造成了负优化。


这个例子中,一个item上有三个AppCompatTextView并且字号都很小,导致一屏幕可以看到十段左右的文字,当然使用了PrecomputedText优化后,onBindViewHolder方法的执行时间大大的缩短了,但是却检测到了新的问题。


https://github.com/CherryPerry/PrecomputedTextDemo


首先我们要了解滑动列表的速度越快,那么单位时间内测量绘制的内容也就越多。我对使用前后进行了三种速度的测试,分别是慢速(1s滑动1次,力度小)、中速(1s滑动2次,力度中)、快速(1s滑动3次,力度大)得到了下面的结论。(纯手工滑动,真的累。。。)


具体的Systrace结果图我就不全部展示了,这里展示一下中速滑动前后结果。


 



代表Animation和Input的浅绿色竖条增高了。




最终的统计如下:


问题/速度慢速中速快速
Scheduling delay4  -> 465 -> 398 -> 17
Long View#draw()18 -> 1237 -> 3050 -> 48
Expensive measure/layout pass1 -> 000


Scheduling delay 就是一个线程在处理一块运算的时候,在很长一段时间都没有被CPU调度,从而导致这个线程在很长一段时间都没有完成工作。


可以看到使用PrecomputedText后,Scheduling delay 问题会有一定概率激增,甚至更加严重。对比发现激增点都是因为dequeueBuffer 这里等待时间过长,比如下面 dequeueBuffer 的片段cpu实际执行了0.119ms,但是总耗时了10.035ms。



其实仔细观察,dequeueBuffer 在一开始就已经执行完成,但是却处在等待cpu调度来执行下一步的地方。这里其实就是等待SurfaceFlinger执行导致的。如下图:



这里的耗时,会使通知 CPU 延迟,导致的Scheduling delay 。具体为何高概率触发这类问题的原因这里还不清楚。猜测是文本本身很复杂,一段文字中不同字号、颜色、样式,并且页面上同时存在十多个这样的段落。这样的话就短时间内会有十多次线程的切换来实现文字的异步测量,势必会有性能影响。


我后面将文字字体设置大了以后,发现这个问题就好多了。


所以PrecomputedText的使用还是需要根据场景来使用,否则会矫枉过正。


5总结


  • 不要滥用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 ,里面也有使用协程的优化方案。


https://github.com/satoshun-android-example/PrecomputedTextCompatExample


我也写了一个对应的java示例


https://github.com/simplezhli/RecyclerViewExtensionsDemo


效果如下:

normal



PrecomputedText future



PrecomputedText coroutine



最后如果对你有帮助,希望点赞支持!!


参考


  • Use Android Text Like a Pro

  • What is new in Android P?—?PrecomputedText

  • Prefetch Text Layout in RecyclerView


最近给大家申请了一波购书超级福利,可以看下:


屯书的时候又又到了...褥当当一波!



推荐阅读

Android Q (10) 适配指南  让你少走一堆弯路

ViewPager2 demo? Google官方就有呀!

这么学Android 肯定能学好~


扫一扫 关注我的公众号

如果你想要跟大家分享你的文章,欢迎投稿~


┏(^0^)┛明天见!

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存