背景

隨著移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展，移動(dòng)應(yīng)用越來越注重用戶體驗(yàn)。美團(tuán)技術(shù)團(tuán)隊(duì)在開發(fā)過程中也非常注重提升移動(dòng)應(yīng)用的整體質(zhì)量，其中很重要的一項(xiàng)內(nèi)容就是頁面的加載速度。如果發(fā)生冷啟動(dòng)時(shí)間過長、頁面渲染時(shí)間過長、網(wǎng)絡(luò)請求過慢等現(xiàn)象，就會直接影響到用戶的體驗(yàn)，所以，如何監(jiān)控整個(gè)項(xiàng)目的加載速度就成為我們部門面臨的重要挑戰(zhàn)。

對于測速這個(gè)問題，很多同學(xué)首先會想到在頁面中的不同節(jié)點(diǎn)加入計(jì)算時(shí)間的代碼，以此算出某段時(shí)間長度。然而，隨著美團(tuán)業(yè)務(wù)的快速迭代，會有越來越多的新頁面、越來越多的業(yè)務(wù)邏輯、越來越多的代碼改動(dòng)，這些不確定性會使我們測速部分的代碼耦合進(jìn)業(yè)務(wù)邏輯，并且需要手動(dòng)維護(hù)，進(jìn)而增加了成本和風(fēng)險(xiǎn)。于是通過借鑒公司先前的一些方案，分析其存在的問題并結(jié)合自身特性，我們實(shí)現(xiàn)了一套無需業(yè)務(wù)代碼侵入的自動(dòng)化頁面測速插件，本文將對其原理做一些解讀和分析。

現(xiàn)有解決方案

• 手動(dòng)在 Application.onCreate() 中進(jìn)行SDK的初始化調(diào)用，同時(shí)計(jì)算冷啟動(dòng)時(shí)間。 

• 手動(dòng)在Activity生命周期方法中添加代碼，計(jì)算頁面不同階段的時(shí)間。
• 手動(dòng)為 Activity.setContentView() 設(shè)置的View上，添加一層自定義父View，用于計(jì)算繪制完成的時(shí)間。
• 手動(dòng)在每個(gè)網(wǎng)絡(luò)請求開始前和結(jié)束后添加代碼，計(jì)算網(wǎng)絡(luò)請求的時(shí)間。 

本地聲明JSON配置文件來確定需要測速的頁面以及該頁面需要統(tǒng)計(jì)的初始網(wǎng)絡(luò)請求API， getClass().getSimpleName() 作為頁面的key，來標(biāo)識哪些頁面需要測速，指定一組API來標(biāo)識哪些請求是需要被測速的。 

現(xiàn)有方案問題

• 冷啟動(dòng)時(shí)間不準(zhǔn)：冷啟動(dòng)起始時(shí)間從 Application.onCreate() 中開始算起，會使得計(jì)算出來的冷啟動(dòng)時(shí)間偏小，因?yàn)樵谠摲椒▓?zhí)行前可能會有 MultiDex.install() 等耗時(shí)方法的執(zhí)行。
• 特殊情況未考慮：忽略了ViewPager+Fragment延時(shí)加載這些常見而復(fù)雜的情況，這些情況會造成實(shí)際測速時(shí)間非常不準(zhǔn)。
• 手動(dòng)注入代碼：所有的代碼都需要手動(dòng)寫入，耦合進(jìn)業(yè)務(wù)邏輯中，難以維護(hù)并且隨著新頁面的加入容易遺漏。
• 寫死配置文件：如需添加或更改要測速的頁面，則需要修改本地配置文件，進(jìn)行發(fā)版。

目標(biāo)方案效果

• 自動(dòng)注入代碼，無需手動(dòng)寫入代碼與業(yè)務(wù)邏輯耦合。
• 支持Activity和Fragment頁面測速，并解決ViewPager+Fragment延遲加載時(shí)測速不準(zhǔn)的問題。
• 在Application的構(gòu)造函數(shù)中開始冷啟動(dòng)時(shí)間計(jì)算。
• 自動(dòng)拉取和更新配置文件，可以實(shí)時(shí)的進(jìn)行配置文件的更新。

實(shí)現(xiàn)

我們要實(shí)現(xiàn)一個(gè)自動(dòng)化的測速插件，需要分為五步進(jìn)行：

• 測速定義：確定需要測量的速度指標(biāo)并定義其計(jì)算方式。
• 配置文件：通過配置文件確定代碼中需要測量速度指標(biāo)的位置。
• 測速實(shí)現(xiàn)：如何實(shí)現(xiàn)時(shí)間的計(jì)算和上報(bào)。
• 自動(dòng)化實(shí)現(xiàn)：如何自動(dòng)化實(shí)現(xiàn)頁面測速，不需要手動(dòng)注入代碼。
• 疑難雜癥：分析并解決特殊情況。

測速定義

我們把頁面加載流程抽象成一個(gè)通用的過程模型：頁面初始化 -> 初次渲染完成 -> 網(wǎng)絡(luò)請求發(fā)起 -> 請求完成并刷新頁面 -> 二次渲染完成。據(jù)此，要測量的內(nèi)容包括以下方面：

• 項(xiàng)目的冷啟動(dòng)時(shí)間：從App被創(chuàng)建，一直到我們首頁初次繪制出來所經(jīng)歷的時(shí)間。
• 頁面的初次渲染時(shí)間：從Activity或Fragment的 onCreate() 方法開始，一直到頁面View的初次渲染完成所經(jīng)歷的時(shí)間。
• 頁面的初始網(wǎng)絡(luò)請求時(shí)間：Activity或Fragment指定的一組初始請求，全部完成所用的時(shí)間。
• 頁面的二次渲染時(shí)間：Activity或Fragment所有的初始請求完成后，到頁面View再次渲染完成所經(jīng)歷的時(shí)間。

需要注意的是，網(wǎng)絡(luò)請求時(shí)間是指定的一組請求全部完成的時(shí)間，即從***個(gè)請求發(fā)起開始，直到***一個(gè)請求完成所用的時(shí)間。

根據(jù)定義我們的測速模型如下圖所示。 

配置文件

接下來要知道哪些頁面需要測速，以及頁面的初始請求是哪些API，這需要一個(gè)配置文件來定義。

<page id="HomeActivity" tag="1"> 
   <api id="/api/config"/> 
   <api id="/api/list"/> 
</page> 
<page id="com.test.MerchantFragment" tag="0"> 
   <api id="/api/test1"/> 
</page> 

我們定義了一個(gè)XML配置文件，每個(gè) 標(biāo)簽代表了一個(gè)頁面，其中 id 是頁面的類名或者全路徑類名，用以表示哪些Activity或者Fragment需要測速; tag 代表是否為首頁，這個(gè)首頁指的是用以計(jì)算冷啟動(dòng)結(jié)束時(shí)間的頁面，比如我們想把冷啟動(dòng)時(shí)間定義為從App創(chuàng)建到HomeActivity展示所需要的時(shí)間，那么HomeActivity的tag就為1;每一個(gè) 代表這個(gè)頁面的一個(gè)初始請求，比如HomeActivity頁面是個(gè)列表頁，一進(jìn)來會先請求config接口，然后請求list接口，當(dāng)list接口回來后展示列表數(shù)據(jù)，那么該頁面的初始請求就是config和list接口。更重要的一點(diǎn)是，我們將該配置文件維護(hù)在服務(wù)端，可以實(shí)時(shí)更新，而客戶端要做的只是在插件SDK初始化時(shí)拉取***的配置文件即可。

測速實(shí)現(xiàn)

測速需要實(shí)現(xiàn)一個(gè)SDK，用于管理配置文件、頁面測速對象、計(jì)算時(shí)間、上報(bào)數(shù)據(jù)等，項(xiàng)目接入后，在頁面的不同節(jié)點(diǎn)調(diào)用SDK提供的方法完成測速。

冷啟動(dòng)開始時(shí)間

冷啟動(dòng)的開始時(shí)間，我們以Application的構(gòu)造函數(shù)被調(diào)用為準(zhǔn)，在構(gòu)造函數(shù)中進(jìn)行時(shí)間點(diǎn)記錄，并在SDK初始化時(shí)，將時(shí)間點(diǎn)傳入作為冷啟動(dòng)開始時(shí)間。 

//Application 
public MyApplication(){ 
    super(); 
    coldStartTime = SystemClock.elapsedRealtime(); 
} 
//SDK初始化 
public void onColdStart(long coldStartTime) { 
    this.startTime = coldStartTime; 
} 

這里說明幾點(diǎn)：

• SDK中所有的時(shí)間獲取都使用 SystemClock.elapsedRealtime() 機(jī)器時(shí)間，保證了時(shí)間的一致性和準(zhǔn)確性。
• 冷啟動(dòng)初始時(shí)間以構(gòu)造函數(shù)為準(zhǔn)，可以算入MultiDex注入的時(shí)間，比在 onCreate() 中計(jì)算更為準(zhǔn)確。
• 在構(gòu)造函數(shù)中直接調(diào)用Java的API來計(jì)算時(shí)間，之后傳入SDK中，而不是直接調(diào)用SDK的方法，是為了防止MultiDex注入之前，調(diào)用到未注入的Dex中的類。

SDK初始化

SDK的初始化在 Application.onCreate() 中調(diào)用，初始化時(shí)會獲取服務(wù)端的配置文件，解析為 Map ，對應(yīng)配置中頁面的id和其配置項(xiàng)。另外還維護(hù)了一個(gè)當(dāng)前頁面對象的 MAP ，key為一個(gè)int值而不是其類名，因?yàn)橥粋€(gè)類可能有多個(gè)實(shí)例同時(shí)在運(yùn)行，如果存為一個(gè)key，可能會導(dǎo)致同一頁面不同實(shí)例的測速對象只有一個(gè)，所以在這里我們使用Activity或Fragment的 hashcode() 值作為頁面的唯一標(biāo)識。

頁面開始時(shí)間

頁面的開始時(shí)間，我們以Activtiy或Fragment的 onCreate() 作為時(shí)間節(jié)點(diǎn)進(jìn)行計(jì)算，記錄頁面的開始時(shí)間。 

public void onPageCreate(Object page) { 
    int pageObjKey = Utils.getPageObjKey(page); 
    PageObject pageObject = activePages.get(pageObjKey); 
    ConfigModel configModel = getConfigModel(page);//獲取該頁面的配置 
    if (pageObject == null && configModel != null) {//有配置則需要測速 
        pageObject = new PageObject(pageObjKey, configModel, Utils.getDefaultReportKey(page), callback); 
        pageObject.onCreate(); 
        activePages.put(pageObjKey, pageObject); 
    } 
} 
//PageObject.onCreate() 
void onCreate() { 
    if (createTime > 0) { 
        return; 
    } 
    createTime = Utils.getRealTime(); 
} 

這里的 getConfigModel() 方法中，會使用頁面的類名或者全路徑類名，去初始化時(shí)解析的配置Map中進(jìn)行id的匹配，如果匹配到說明頁面需要測速，就會創(chuàng)建測速對象 PageObject 進(jìn)行測速。

網(wǎng)絡(luò)請求時(shí)間

一個(gè)頁面的初始請求由配置文件指定，我們只需在***個(gè)請求發(fā)起前記錄請求開始時(shí)間，在***一個(gè)請求回來后記錄結(jié)束時(shí)間即可。 

boolean onApiLoadStart(String url) { 
    String relUrl = Utils.getRelativeUrl(url); 
    if (!hasApiConfig() || !hasUrl(relUrl) || apiStatusMap.get(relUrl.hashCode()) != NONE) { 
        return false; 
    } 
    //改變Url的狀態(tài)為執(zhí)行中 
    apiStatusMap.put(relUrl.hashCode(), LOADING); 
    //***個(gè)請求開始時(shí)記錄起始點(diǎn) 
    if (apiLoadStartTime <= 0) { 
        apiLoadStartTime = Utils.getRealTime(); 
    } 
    return true; 
} 
boolean onApiLoadEnd(String url) { 
    String relUrl = Utils.getRelativeUrl(url); 
    if (!hasApiConfig() || !hasUrl(relUrl) || apiStatusMap.get(relUrl.hashCode()) != LOADING) { 
        return false; 
    } 
    //改變Url的狀態(tài)為執(zhí)行結(jié)束 
    apiStatusMap.put(relUrl.hashCode(), LOADED); 
    //全部請求結(jié)束后記錄時(shí)間 
    if (apiLoadEndTime <= 0 && allApiLoaded()) { 
        apiLoadEndTime = Utils.getRealTime(); 
    } 
    return true; 
} 
private boolean allApiLoaded() { 
    if (!hasApiConfig()) return true; 
    int size = apiStatusMap.size(); 
    for (int i = 0; i < size; ++i) { 
        if (apiStatusMap.valueAt(i) != LOADED) { 
            return false; 
        } 
    } 
    return true; 
} 

每個(gè)頁面的測速對象，維護(hù)了一個(gè)請求url和其狀態(tài)的映射關(guān)系 SparseIntArray ，key就為請求url的hashcode，狀態(tài)初始為 NONE 。每次請求發(fā)起時(shí)，將對應(yīng)url的狀態(tài)置為 LOADING ，結(jié)束時(shí)置為 LOADED 。當(dāng)***個(gè)請求發(fā)起時(shí)記錄起始時(shí)間，當(dāng)所有url狀態(tài)為 LOADED 時(shí)說明所有請求完成，記錄結(jié)束時(shí)間。

渲染時(shí)間

按照我們對測速的定義，現(xiàn)在冷啟動(dòng)開始時(shí)間有了，還差結(jié)束時(shí)間，即指定的首頁初次渲染結(jié)束時(shí)的時(shí)間;頁面的開始時(shí)間有了，還差頁面初次渲染的結(jié)束時(shí)間;網(wǎng)絡(luò)請求的結(jié)束時(shí)間有了，還差頁面的二次渲染的結(jié)束時(shí)間。這一切都是和頁面的View渲染時(shí)間有關(guān)，那么怎么獲取頁面的渲染結(jié)束時(shí)間點(diǎn)呢? 

由View的繪制流程可知，父View的 dispatchDraw() 方法會執(zhí)行其所有子View的繪制過程，那么把頁面的根View當(dāng)做子View，是不是可以在其外部增加一層父View，以其 dispatchDraw() 作為頁面繪制完畢的時(shí)間點(diǎn)呢?答案是可以的。 

class AutoSpeedFrameLayout extends FrameLayout { 
    public static View wrap(int pageObjectKey, @NonNull View child) { 
        ... 
        //將頁面根View作為子View，其他參數(shù)保持不變 
        ViewGroup vg = new AutoSpeedFrameLayout(child.getContext(), pageObjectKey); 
        if (child.getLayoutParams() != null) { 
            vg.setLayoutParams(child.getLayoutParams()); 
        } 
        vg.addView(child, new ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT)); 
        return vg; 
    } 
    private final int pageObjectKey;//關(guān)聯(lián)的頁面key 
    private AutoSpeedFrameLayout(@NonNull Context context, int pageObjectKey) { 
        super(context); 
        this.pageObjectKey = pageObjectKey; 
    } 
    @Override 
    protected void dispatchDraw(Canvas canvas) { 
        super.dispatchDraw(canvas); 
        AutoSpeed.getInstance().onPageDrawEnd(pageObjectKey); 
    } 
} 

我們自定義了一層 FrameLayout 作為所有頁面根View的父View，其 dispatchDraw() 方法執(zhí)行super后，記錄相關(guān)頁面繪制結(jié)束的時(shí)間點(diǎn)。

測速完成

現(xiàn)在所有時(shí)間點(diǎn)都有了，那么什么時(shí)候算作測速過程結(jié)束呢?我們來看看每次渲染結(jié)束后的處理就知道了。 

//PageObject.onPageDrawEnd() 
void onPageDrawEnd() { 
    if (initialDrawEndTime <= 0) {//初次渲染還沒有完成 
        initialDrawEndTime = Utils.getRealTime(); 
        if (!hasApiConfig() || allApiLoaded()) {//如果沒有請求配置或者請求已完成，則沒有二次渲染時(shí)間，即初次渲染時(shí)間即為頁面整體時(shí)間，且可以上報(bào)結(jié)束頁面了 
            finalDrawEndTime = -1; 
            reportIfNeed(); 
        } 
        //頁面初次展示，回調(diào)，用于統(tǒng)計(jì)冷啟動(dòng)結(jié)束 
        callback.onPageShow(this); 
        return; 
    } 
    //如果二次渲染沒有完成，且所有請求已經(jīng)完成，則記錄二次渲染時(shí)間并結(jié)束測速，上報(bào)數(shù)據(jù) 
    if (finalDrawEndTime <= 0 && (!hasApiConfig() || allApiLoaded())) { 
        finalDrawEndTime = Utils.getRealTime(); 
        reportIfNeed(); 
    } 
} 

該方法用于處理渲染完畢的各種情況，包括初次渲染時(shí)間、二次渲染時(shí)間、冷啟動(dòng)時(shí)間以及相應(yīng)的上報(bào)。這里的冷啟動(dòng)在 callback.onPageShow(this) 是如何處理的呢? 

//初次渲染完成時(shí)的回調(diào) 
void onMiddlePageShow(boolean isMainPage) { 
    if (!isFinish && isMainPage && startTime > 0 && endTime <= 0) { 
        endTime = Utils.getRealTime(); 
        callback.onColdStartReport(this); 
        finish(); 
    } 
} 

還記得配置文件中 tag 么，他的作用就是指明該頁面是否為首頁，也就是代碼段里的 isMainPage 參數(shù)。如果是首頁的話，說明首頁的初次渲染結(jié)束，就可以計(jì)算冷啟動(dòng)結(jié)束的時(shí)間并進(jìn)行上報(bào)了。

上報(bào)數(shù)據(jù)

當(dāng)測速完成后，頁面測速對象 PageObject 里已經(jīng)記錄了頁面(包括冷啟動(dòng))各個(gè)時(shí)間點(diǎn)，剩下的只需要進(jìn)行測速階段的計(jì)算并進(jìn)行網(wǎng)絡(luò)上報(bào)即可。 

//計(jì)算網(wǎng)絡(luò)請求時(shí)間 
long getApiLoadTime() { 
    if (!hasApiConfig() || apiLoadEndTime <= 0 || apiLoadStartTime <= 0) { 
        return -1; 
    } 
    return apiLoadEndTime - apiLoadStartTime; 
} 

自動(dòng)化實(shí)現(xiàn)

有了SDK，就要在我們的項(xiàng)目中接入，并在相應(yīng)的位置調(diào)用SDK的API來實(shí)現(xiàn)測速功能，那么如何自動(dòng)化實(shí)現(xiàn)API的調(diào)用呢?答案就是采用AOP的方式，在App編譯時(shí)動(dòng)態(tài)注入代碼，我們實(shí)現(xiàn)一個(gè)Gradle插件，利用其Transform功能以及Javassist實(shí)現(xiàn)代碼的動(dòng)態(tài)注入。動(dòng)態(tài)注入代碼分為以下幾步：

• 初始化埋點(diǎn)：SDK的初始化。
• 冷啟動(dòng)埋點(diǎn)：Application的冷啟動(dòng)開始時(shí)間點(diǎn)。
• 頁面埋點(diǎn)：Activity和Fragment頁面的時(shí)間點(diǎn)。
• 請求埋點(diǎn)：網(wǎng)絡(luò)請求的時(shí)間點(diǎn)。

初始化埋點(diǎn)

在 Transform 中遍歷所有生成的class文件，找到Application對應(yīng)的子類，在其 onCreate() 方法中調(diào)用SDK初始化API即可。 

CtMethod method = it.getDeclaredMethod("onCreate") 
method.insertBefore("${Constants.AUTO_SPEED_CLASSNAME}.getInstance().init(this);") 

最終生成的Application代碼如下： 

public void onCreate() { 
    ... 
    AutoSpeed.getInstance().init(this); 
} 

冷啟動(dòng)埋點(diǎn)

同上一步，找到Application對應(yīng)的子類，在其構(gòu)造方法中記錄冷啟動(dòng)開始時(shí)間，在SDK初始化時(shí)候傳入SDK，原因在上文已經(jīng)解釋過。 

//Application 
private long coldStartTime; 
public MobileCRMApplication() { 
    coldStartTime = SystemClock.elapsedRealtime(); 
} 
public void onCreate(){ 
    ... 
    AutoSpeed.getInstance().init(this,coldStartTime); 
} 

頁面埋點(diǎn)

結(jié)合測速時(shí)間點(diǎn)的定義以及Activity和Fragment的生命周期，我們能夠確定在何處調(diào)用相應(yīng)的API。 

Activity

對于Activity頁面，現(xiàn)在開發(fā)者已經(jīng)很少直接使用 android.app.Activity 了，取而代之的是 android.support.v4.app.FragmentActivity 和 android.support.v7.app.AppCompatActivity ，所以我們只需在這兩個(gè)基類中進(jìn)行埋點(diǎn)即可，我們先來看FragmentActivity。 

protected void onCreate(@Nullable Bundle savedInstanceState) { 
    AutoSpeed.getInstance().onPageCreate(this); 
    ... 
} 
public void setContentView(View var1) { 
    super.setContentView(AutoSpeed.getInstance().createPageView(this, var1)); 
} 

注入代碼后，在FragmentActivity的 onCreate 一開始調(diào)用了 onPageCreate() 方法進(jìn)行了頁面開始時(shí)間點(diǎn)的計(jì)算;在 setContentView() 內(nèi)部，直接調(diào)用super，并將頁面根View包裝在我們自定義的 AutoSpeedFrameLayout 中傳入，用于渲染時(shí)間點(diǎn)的計(jì)算。

然而在AppCompatActivity中，重寫了setContentView()方法，且沒有調(diào)用super，調(diào)用的是 AppCompatDelegate 的相應(yīng)方法。 

public void setContentView(View view) { 
    getDelegate().setContentView(view); 
} 

這個(gè)delegate類用于適配不同版本的Activity的一些行為，對于setContentView，無非就是將根View傳入delegate相應(yīng)的方法，所以我們可以直接包裝View，調(diào)用delegate相應(yīng)方法并傳入即可。 

public void setContentView(View view) { 
    AppCompatDelegate var2 = this.getDelegate(); 
    var2.setContentView(AutoSpeed.getInstance().createPageView(this, view)); 
} 

對于Activity的setContentView埋點(diǎn)需要注意的是，該方法是重載方法，我們需要對每個(gè)重載的方法做處理。

Fragment

Fragment的 onCreate() 埋點(diǎn)和Activity一樣，不必多說。這里主要說下 onCreateView() ，這個(gè)方法是返回值代表根View，而不是直接傳入View，而Javassist無法單獨(dú)修改方法的返回值，所以無法像Activity的setContentView那樣注入代碼，并且這個(gè)方法不是 @CallSuper 的，意味著不能在基類里實(shí)現(xiàn)。那么怎么辦呢?我們決定在每個(gè)Fragment的該方法上做一些事情。 

//Fragment標(biāo)志位 
protected static boolean AUTO_SPEED_FRAGMENT_CREATE_VIEW_FLAG = true; 
//利用遞歸包裝根View 
public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) { 
    if(AUTO_SPEED_FRAGMENT_CREATE_VIEW_FLAG) { 
        AUTO_SPEED_FRAGMENT_CREATE_VIEW_FLAG = false; 
        View var4 = AutoSpeed.getInstance().createPageView(this, this.onCreateView(inflater, container, savedInstanceState)); 
        AUTO_SPEED_FRAGMENT_CREATE_VIEW_FLAG = true; 
        return var4; 
    } else { 
        ... 
        return rootView; 
    } 
} 

我們利用一個(gè)boolean類型的標(biāo)志位，進(jìn)行遞歸調(diào)用 onCreateView() 方法：

1. 最初調(diào)用時(shí)，會將標(biāo)志位置為false，然后遞歸調(diào)用該方法。
2. 遞歸調(diào)用時(shí)，由于標(biāo)志位為false所以會調(diào)用原有邏輯，即獲取根View。
3. 獲取根View后，包裝為 AutoSpeedFrameLayout 返回。

并且由于標(biāo)志位為false，所以在遞歸調(diào)用時(shí)，即使調(diào)用了 super.onCreateView() 方法，在父類的該方法中也不會走if分支，而是直接返回其根View。

請求埋點(diǎn)

關(guān)于請求埋點(diǎn)我們針對不同的網(wǎng)絡(luò)框架進(jìn)行不同的處理，插件中只需要配置使用了哪些網(wǎng)絡(luò)框架即可實(shí)現(xiàn)埋點(diǎn)，我們拿現(xiàn)在用的最多的 Retrofit 框架來說。

開始時(shí)間點(diǎn)

在創(chuàng)建Retrofit對象時(shí)，需要 OkHttpClient 對象，可以為其添加 Interceptor 進(jìn)行請求發(fā)起前 Request 的攔截，我們可以構(gòu)建一個(gè)用于記錄請求開始時(shí)間點(diǎn)的Interceptor，在 OkHttpClient.Builder() 調(diào)用時(shí)，插入該對象。 

public Builder() { 
  this.addInterceptor(new AutoSpeedRetrofitInterceptor()); 
    ... 
} 

而該Interceptor對象就是用于在請求發(fā)起前，進(jìn)行請求開始時(shí)間點(diǎn)的記錄。 

public class AutoSpeedRetrofitInterceptor implements Interceptor { 
    public Response intercept(Chain var1) throws IOException { 
        AutoSpeed.getInstance().onApiLoadStart(var1.request().url()); 
        return var1.proceed(var1.request()); 
    } 
} 

結(jié)束時(shí)間點(diǎn)

使用Retrofit發(fā)起請求時(shí)，我們會調(diào)用其 enqueue() 方法進(jìn)行異步請求，同時(shí)傳入一個(gè) Callback 進(jìn)行回調(diào)，我們可以自定義一個(gè)Callback，用于記錄請求回來后的時(shí)間點(diǎn)，然后在enqueue方法中將參數(shù)換為自定義的Callback，而原Callback作為其代理對象即可。 

public void enqueue(Callback<T> callback) { 
    final Callback<T> callback = new AutoSpeedRetrofitCallback(callback); 
    ... 
} 

該Callback對象用于在請求成功或失敗回調(diào)時(shí)，記錄請求結(jié)束時(shí)間點(diǎn)，并調(diào)用代理對象的相應(yīng)方法處理原有邏輯。 

public class AutoSpeedRetrofitCallback implements Callback { 
    private final Callback delegate; 
    public AutoSpeedRetrofitMtCallback(Callback var1) { 
        this.delegate = var1; 
    } 
    public void onResponse(Call var1, Response var2) { 
        AutoSpeed.getInstance().onApiLoadEnd(var1.request().url()); 
        this.delegate.onResponse(var1, var2); 
    } 
    public void onFailure(Call var1, Throwable var2) { 
        AutoSpeed.getInstance().onApiLoadEnd(var1.request().url()); 
        this.delegate.onFailure(var1, var2); 
    } 
} 

使用Retrofit+RXJava時(shí)，發(fā)起請求時(shí)內(nèi)部是調(diào)用的 execute() 方法進(jìn)行同步請求，我們只需要在其執(zhí)行前后插入計(jì)算時(shí)間的代碼即可，此處不再贅述。

疑難雜癥

至此，我們基本的測速框架已經(jīng)完成，不過經(jīng)過我們的實(shí)踐發(fā)現(xiàn)，有一種情況下測速數(shù)據(jù)會非常不準(zhǔn)，那就是開頭提過的ViewPager+Fragment并且實(shí)現(xiàn)延遲加載的情況。這也是一種很常見的情況，通常是為了節(jié)省開銷，在切換ViewPager的Tab時(shí)，才***調(diào)用Fragment的初始加載方法進(jìn)行數(shù)據(jù)請求。經(jīng)過調(diào)試分析，我們找到了問題的原因。

等待切換時(shí)間 

該圖紅色時(shí)間段反映出，直到ViewPager切換到Fragment前，F(xiàn)ragment不會發(fā)起請求，這段等待的時(shí)間就會延長整個(gè)頁面的加載時(shí)間，但其實(shí)這塊時(shí)間不應(yīng)該算在內(nèi)，因?yàn)檫@段時(shí)間是用戶無感知的，不能作為頁面耗時(shí)過長的依據(jù)。

那么如何解決呢?我們都知道ViewPager的Tab切換是可以通過一個(gè) OnPageChangeListener 對象進(jìn)行監(jiān)聽的，所以我們可以為ViewPager添加一個(gè)自定義的Listener對象，在切換時(shí)記錄一個(gè)時(shí)間，這樣可以通過用這個(gè)時(shí)間減去頁面創(chuàng)建后的時(shí)間得出這個(gè)多余的等待時(shí)間，上報(bào)時(shí)在總時(shí)間中減去即可。 

public ViewPager(Context context) { 
    ... 
    this.addOnPageChangeListener(new AutoSpeedLazyLoadListener(this.mItems)); 
} 

mItems 是ViewPager中當(dāng)前頁面對象的數(shù)組，在Listener中可以通過他找到對應(yīng)的頁面，進(jìn)行切換時(shí)的埋點(diǎn)。 

//AutoSpeedLazyLoadListener 
public void onPageSelected(int var1) { 
    if(this.items != null) { 
        int var2 = this.items.size(); 
        for(int var3 = 0; var3 < var2; ++var3) { 
            Object var4 = this.items.get(var3); 
            if(var4 instanceof ItemInfo) { 
                ItemInfo var5 = (ItemInfo)var4; 
                if(var5.position == var1 && var5.object instanceof Fragment) { 
                    AutoSpeed.getInstance().onPageSelect(var5.object); 
                    break; 
                } 
            } 
        } 
    } 
} 

AutoSpeed的 onPageSelected() 方法記錄頁面的切換時(shí)間。這樣一來，在計(jì)算頁面加載速度總時(shí)間時(shí)，就要減去這一段時(shí)間。 

long getTotalTime() { 
    if (createTime <= 0) { 
        return -1; 
    } 
    if (finalDrawEndTime > 0) {//有二次渲染時(shí)間 
        long totalTime = finalDrawEndTime - createTime; 
        //如果有等待時(shí)間，則減掉這段多余的時(shí)間 
        if (selectedTime > 0 && selectedTime > viewCreatedTime && selectedTime < finalDrawEndTime) { 
            totalTime -= (selectedTime - viewCreatedTime); 
        } 
        return totalTime; 
    } else {//以初次渲染時(shí)間為整體時(shí)間 
        return getInitialDrawTime(); 
    } 
} 

這里減去的 viewCreatedTime 不是Fragment的 onCreate() 時(shí)間，而應(yīng)該是 onViewCreated() 時(shí)間，因?yàn)閺膐nCreate到onViewCreated之間的時(shí)間也是應(yīng)該算在頁面加載時(shí)間內(nèi)，不應(yīng)該減去，所以為了處理這種情況，我們還需要對Fragment的onViewCreated方法進(jìn)行埋點(diǎn)，埋點(diǎn)方式同 onCreate() 的埋點(diǎn)。

渲染時(shí)機(jī)不固定

此外經(jīng)實(shí)踐發(fā)現(xiàn)，由于不同View在繪制子View時(shí)的繪制原理不一樣，有可能會導(dǎo)致以下情況的發(fā)生：

• 沒有切換至Fragment時(shí)，F(xiàn)ragment的View初次渲染已經(jīng)完成，即View不可見的情況下也調(diào)用了 dispatchDraw()。
• 沒有切換至Fragment時(shí)，F(xiàn)ragment的View初次渲染未完成，即直到View初次可見時(shí) dispatchDraw() 才會調(diào)用。
• 沒有延遲加載時(shí)，當(dāng)ViewPager沒有切換到Fragment，而是直接發(fā)送請求后，請求回來時(shí)更新View，會調(diào)用 dispatchDraw() 進(jìn)行二次渲染。
• 沒有延遲加載時(shí)，當(dāng)ViewPager沒有切換到Fragment，而是直接發(fā)送請求后，請求回來時(shí)更新View，不會調(diào)用 dispatchDraw() ，即直到切換到Fragment時(shí)才會進(jìn)行二次渲染。

上面的問題總結(jié)來看，就是初次渲染時(shí)間和二次渲染時(shí)間中，可能會有個(gè)等待切換的時(shí)間，導(dǎo)致這兩個(gè)時(shí)間變長，而這個(gè)切換時(shí)間點(diǎn)并不是 onPageSelected() 方法調(diào)用的時(shí)候，因?yàn)樵摲椒ㄊ窃贔ragment完全滑動(dòng)出來之后才會調(diào)用，而這個(gè)問題里的切換時(shí)間點(diǎn)，應(yīng)該是指View初次展示的時(shí)候，也就是剛一滑動(dòng)，ViewPager露出目標(biāo)View的時(shí)間點(diǎn)。于是類比延遲加載的切換時(shí)間，我們利用Listener的 onPageScrolled() 方法，在ViewPager滑動(dòng)時(shí)，找到目標(biāo)頁面，為其記錄一個(gè)滑動(dòng)時(shí)間點(diǎn) scrollToTime 。 

public void onPageScrolled(int var1, float var2, int var3) { 
    if(this.items != null) { 
        int var4 = Math.round(var2); 
        int var5 = var2 != (float)0 && var4 != 1?(var4 == 0?var1 + 1:-1):var1; 
        int var6 = this.items.size(); 
        for(int var7 = 0; var7 < var6; ++var7) { 
            Object var8 = this.items.get(var7); 
            if(var8 instanceof ItemInfo) { 
                ItemInfo var9 = (ItemInfo)var8; 
                if(var9.position == var5 && var9.object instanceof Fragment) { 
                    AutoSpeed.getInstance().onPageScroll(var9.object); 
                    break; 
                } 
            } 
        } 
    } 
} 

那么這樣就可以解決兩次渲染的誤差：

• 初次渲染時(shí)間中， scrollToTime - viewCreatedTime 就是頁面創(chuàng)建后，到初次渲染結(jié)束之間，因?yàn)榈却凉L動(dòng)而產(chǎn)生的多余時(shí)間。
• 二次渲染時(shí)間中， scrollToTime - apiLoadEndTime 就是請求完成后，到二次渲染結(jié)束之間，因?yàn)榈却凉L動(dòng)而產(chǎn)生的多余時(shí)間。

于是在計(jì)算初次和二次渲染時(shí)間時(shí)，可以減去多余時(shí)間得到正確的值。 

long getInitialDrawTime() { 
    if (createTime <= 0 || initialDrawEndTime <= 0) { 
        return -1; 
    } 
    if (scrollToTime > 0 && scrollToTime > viewCreatedTime && scrollToTime <= initialDrawEndTime) {//延遲初次渲染，需要減去等待的時(shí)間(viewCreated->changeToPage) 
        return initialDrawEndTime - createTime - (scrollToTime - viewCreatedTime); 
    } else {//正常初次渲染 
        return initialDrawEndTime - createTime; 
    } 
} 
long getFinalDrawTime() { 
    if (finalDrawEndTime <= 0 || apiLoadEndTime <= 0) { 
        return -1; 
    } 
    //延遲二次渲染，需要減去等待時(shí)間(apiLoadEnd->scrollToTime) 
    if (scrollToTime > 0 && scrollToTime > apiLoadEndTime && scrollToTime <= finalDrawEndTime) { 
        return finalDrawEndTime - apiLoadEndTime - (scrollToTime - apiLoadEndTime); 
    } else {//正常二次渲染 
        return finalDrawEndTime - apiLoadEndTime; 
    } 
} 

總結(jié)

以上就是我們對頁面測速及自動(dòng)化實(shí)現(xiàn)上做的一些嘗試，目前已經(jīng)在項(xiàng)目中使用，并在監(jiān)控平臺上可以獲取實(shí)時(shí)的數(shù)據(jù)。我們可以通過分析數(shù)據(jù)來了解頁面的性能進(jìn)而做優(yōu)化，不斷提升項(xiàng)目的整體質(zhì)量。并且通過實(shí)踐發(fā)現(xiàn)了一些測速誤差的問題，也都逐一解決，使得測速數(shù)據(jù)更加可靠。自動(dòng)化的實(shí)現(xiàn)也讓我們在后續(xù)開發(fā)中的維護(hù)變得更容易，不用維護(hù)頁面測速相關(guān)的邏輯，就可以做到實(shí)時(shí)監(jiān)測所有頁面的加載速度。

作者介紹

文杰，美團(tuán)前端Android開發(fā)工程師，2016年畢業(yè)于天津工業(yè)大學(xué)，同年加入美團(tuán)點(diǎn)評到店餐飲事業(yè)群，從事商家銷售端移動(dòng)應(yīng)用開發(fā)工作。