一、背景介紹

隨著小紅書用戶規模的不斷增長，App 性能對用戶體驗的影響顯得越來越重要，例如頁面的打開速度、App 的啟動速度等，幾十毫秒的提升都能帶來業務數據上比較顯著的收益。今天要介紹的是對一個官方框架的實踐以及優化，期間踩了不少坑，但收益也很可觀。

AsyncLayoutInflater 最早于 2015 年出現在 support.v4 包中，用來異步 inflate 布局。通常來講 inflate 需要在主線程執行，所以是一個頁面初始化過程中的耗時主要部分，這個工具提供了可以在異步 inflate 的能力，進而減少主線程堵塞。本文主要介紹工具的使用以及如何改進，以及改進中遇到的一些問題。

二、使用

AsyncLayoutInflater 的使用非常簡單，只需要加入一個依賴即可。

同時在代碼中的使用如下：

在異步 inflate 好之后會有回調，這時候就可以使用 view 了。

三、源碼分析

這個工具最厲害的地方就在于異步 inflate view 居然沒有出現線程安全相關的一些問題，下面我們就來看看它是怎么處理線程安全的問題的。

首先，里面有一個 Thread 的單例，單例里有一個線程安全的阻塞隊列和一個線程安全的對象池。

這個單例里有個方法是 enqueue 方法，會調用阻塞隊列的 put，將 request 插入隊列中。因為是一個線程安全的隊列+線程安全的對象池，所以這一系列操作就保證了線程安全。

下面是inflate的流程，inflate的時候會通過 mInflateThread.obtainRequest 從對象池里拿到一個 request，然后再將這個 request 插入隊列中。

下面是一個簡化過的代碼，run 中有一個死循環，通過阻塞隊列的 take 元素進行 inflate 的操作。

以上這個簡單的工具就分析完了。這部分基本就回答了線程間如何同步數據的一個問題，在一個典型的生產者消費者模型中加入線程安全的容器即可保證。

四、問題與改進

在使用中還是遇到很多線程相關的問題，以下列舉幾點相對重要的問題進行闡述。

4.1 單線程與多線程

InflateThread 在這里的設計是一個單例單線程，當需要對線程有一些定制或者收攏的話，改動就有些麻煩了，這里可以通過開放一個設置線程池的方法來提供一些線程管理和定制的能力，默認可以內置一個單線程的線程池。

通過比較長時間的實驗我們發現，在主線程比較空閑的時候，單線程的效果會好一些，因為都在大核上執行了，效率更高。主線程繁忙的時候，例如冷啟階段，多線程會有更好的效率。

4.2 ArrayMap 與線程安全

我們在實際使用中發現，在一些自定義 View 的構造函數中和 darkmode 的實現中使用了 SimpleArrayMap 或 ArrayMap，ArrayMap 是 SimpleArrayMap 的子類，本身 SimpleArrayMap 是用過兩個 static 的數組來實現對象的緩存，從而起到復用的作用，在多線程的情況下會有線程安全問題，這里會出現復用對象不匹配導致的 crash。一個簡單的方式就是當出現 crash 的時候講對應的 cache 數組清空，即可避免。

4.3 inflate、鎖與線程安全

LayoutInflater 的 inflate 方法中有一個鎖，這個導致了如果你想多線程去調用 inflate 的時候，起不到多線程的效果，如果是單線程的情況下，還可能遇到和主線程在 inflate 時同樣等待鎖的問題。這里 mConstructorArgs 是一個成員變量，通過重寫 LayoutInflater 中的 cloneInContext 方法，配合對象池就可以避開這里鎖的問題。

同時 inflate 過程中用到的這些數組和容器類型，都不是線程安全的，如果想要去掉 inflate 方法開頭的 synchronize 的限制，這些線程不安全的容器類也是需要特別注意的。

4.4 BasicInflater 改造

AsyncLayoutInflater 本身有一個 BasicInflater，根據以上的一些改進點，我們在實踐中對其做了一些改造，擴展出了可以設置線程池的接口，使用了基礎架構提供的線程池，做到了對線程的統一管理。實踐下來，在CPU比較繁忙的時候，多線程的線程池效果要好于單線程，當 CPU 比較空閑的時候，單線程的效果會更好一些，因為可以更好的利用釋放出來的CPU 大核的性能。

同時重寫了 ArrayMap 中線程不安全的一些處理方式，使得在多線程使用 ArrayMap 或者使用依賴 ArrayMap 的功能時不會出現 crash，這里涉及到了我們的一些自定義 View 和我們的 darkmode 的實現。

在對于 inflate 的鎖和一些線程不安全的容器處理上，重寫了LayoutInflater 的 cloneInContext 方法去掉了 synchronized 的限制，同時在 onCreateView 的流程中加入了線程安全的容器來保障 inflate 過程的線程安全。

綜合來說就是重寫了 AsyncLayoutInflater，ArrayMap 和 LayoutInflater，以達到線程安全的目的，同時將這些融入到我們的業務框架中，使得使用成本更低。

4.5  ViewCache

另一個實踐是在業務側做了進一步的封裝，通過一個 ViewCache  的單例，提前將一些模塊化的 View 提前 inflate 好，存在 ViewCache 中，在后續需要使用的時候從 ViewCache 中在獲取，這樣就避免了用的時候再 inflate 導致的耗時問題了。這塊整體的代碼比較簡單，就不單獨展開講了，需要注意的點是有些 View 沒有被使用需要及時釋放，避免內存泄漏。

五、總結

AsyncLayoutInflater 的實踐與優化，前后持續了半年左右，我們在 App 冷啟動和筆記詳情頁的性能優化中獲得了超過的 20% 的性能收益以及顯著的業務收益。同時，我們也將這個能力沉淀了到了業務框架中，方便了后續的接入和使用成本，通過 ViewCache 和業務框架，基本做到了可以覆蓋大部分業務需求的能力。未來，我們將會在框架的易用性以及一些場景的使用上做進一步的優化，結合其他的優化手段給業務方提供更多的選擇，使其能在寫業務的同時無需關注這部分的耗時與復雜度，從而提升開發效率。

六、作者信息

殤不患

小紅書商業技術 Android 工程師，曾負責業務架構設計與性能優化，目前專注于交易鏈路的迭代與優化。