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 就是一個線程在處理一塊運算的時候,在很長一段時間都沒有被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帶來的性能優化。

推薦閱讀:

相關文章