一、背景介紹

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

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

二、使用

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

同時(shí)在代碼中的使用如下：

在異步 inflate 好之后會(huì)有回調(diào)，這時(shí)候就可以使用 view 了。

三、源碼分析

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

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

這個(gè)單例里有個(gè)方法是 enqueue 方法，會(huì)調(diào)用阻塞隊(duì)列的 put，將 request 插入隊(duì)列中。因?yàn)槭且粋€(gè)線程安全的隊(duì)列+線程安全的對(duì)象池，所以這一系列操作就保證了線程安全。

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

下面是一個(gè)簡化過的代碼，run 中有一個(gè)死循環(huán)，通過阻塞隊(duì)列的 take 元素進(jìn)行 inflate 的操作。

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

四、問題與改進(jìn)

在使用中還是遇到很多線程相關(guān)的問題，以下列舉幾點(diǎn)相對(duì)重要的問題進(jìn)行闡述。

4.1 單線程與多線程

InflateThread 在這里的設(shè)計(jì)是一個(gè)單例單線程，當(dāng)需要對(duì)線程有一些定制或者收攏的話，改動(dòng)就有些麻煩了，這里可以通過開放一個(gè)設(shè)置線程池的方法來提供一些線程管理和定制的能力，默認(rèn)可以內(nèi)置一個(gè)單線程的線程池。

通過比較長時(shí)間的實(shí)驗(yàn)我們發(fā)現(xiàn)，在主線程比較空閑的時(shí)候，單線程的效果會(huì)好一些，因?yàn)槎荚诖蠛松蠄?zhí)行了，效率更高。主線程繁忙的時(shí)候，例如冷啟階段，多線程會(huì)有更好的效率。

4.2 ArrayMap 與線程安全

我們在實(shí)際使用中發(fā)現(xiàn)，在一些自定義 View 的構(gòu)造函數(shù)中和 darkmode 的實(shí)現(xiàn)中使用了 SimpleArrayMap 或 ArrayMap，ArrayMap 是 SimpleArrayMap 的子類，本身 SimpleArrayMap 是用過兩個(gè) static 的數(shù)組來實(shí)現(xiàn)對(duì)象的緩存，從而起到復(fù)用的作用，在多線程的情況下會(huì)有線程安全問題，這里會(huì)出現(xiàn)復(fù)用對(duì)象不匹配導(dǎo)致的 crash。一個(gè)簡單的方式就是當(dāng)出現(xiàn) crash 的時(shí)候講對(duì)應(yīng)的 cache 數(shù)組清空，即可避免。

4.3 inflate、鎖與線程安全

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

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

4.4 BasicInflater 改造

AsyncLayoutInflater 本身有一個(gè) BasicInflater，根據(jù)以上的一些改進(jìn)點(diǎn)，我們在實(shí)踐中對(duì)其做了一些改造，擴(kuò)展出了可以設(shè)置線程池的接口，使用了基礎(chǔ)架構(gòu)提供的線程池，做到了對(duì)線程的統(tǒng)一管理。實(shí)踐下來，在CPU比較繁忙的時(shí)候，多線程的線程池效果要好于單線程，當(dāng) CPU 比較空閑的時(shí)候，單線程的效果會(huì)更好一些，因?yàn)榭梢愿玫睦冕尫懦鰜淼腃PU 大核的性能。

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

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

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

4.5  ViewCache

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

五、總結(jié)

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

六、作者信息

殤不患

小紅書商業(yè)技術(shù) Android 工程師，曾負(fù)責(zé)業(yè)務(wù)架構(gòu)設(shè)計(jì)與性能優(yōu)化，目前專注于交易鏈路的迭代與優(yōu)化。