背景
隨著移動網際網路的快速發展，移動應用越來越注重使用者體驗。美團技術團隊在開發過程中也非常注重提升移動應用的整體質量，其中很重要的一項內容就是頁面的載入速度。如果發生冷啟動時間過長、頁面渲染時間過長、網路請求過慢等現象，就會直接影響到使用者的體驗，所以，如何監控整個專案的載入速度就成為我們部門面臨的重要挑戰。
對於測速這個問題，很多同學首先會想到在頁面中的不同節點加入計算時間的程式碼，以此算出某段時間長度。然而，隨著美團業務的快速迭代，會有越來越多的新頁面、越來越多的業務邏輯、越來越多的程式碼改動，這些不確定性會使我們測速部分的程式碼耦合進業務邏輯，並且需要手動維護，進而增加了成本和風險。於是通過借鑑公司先前的方案Hertz(移動端效能監控方案Hertz)，分析其存在的問題並結合自身特性，我們實現了一套無需業務程式碼侵入的自動化頁面測速外掛，本文將對其原理做一些解讀和分析。
現有解決方案Hertz(移動端效能監控方案Hertz)
- 手動在
Application.onCreate()中進行SDK的初始化呼叫，同時計算冷啟動時間。
- 手動在Activity生命週期方法中新增程式碼，計算頁面不同階段的時間。
- 手動為
Activity.setContentView()設定的View上，新增一層自定義父View，用於計算繪製完成的時間。 - 手動在每個網路請求開始前和結束後新增程式碼，計算網路請求的時間。
- 本地宣告JSON配置檔案來確定需要測速的頁面以及該頁面需要統計的初始網路請求API，
getClass().getSimpleName()作為頁面的key，來標識哪些頁面需要測速，指定一組API來標識哪些請求是需要被測速的。
現有方案問題
- 冷啟動時間不準：冷啟動起始時間從
Application.onCreate()中開始算起，會使得計算出來的冷啟動時間偏小，因為在該方法執行前可能會有MultiDex.install()等耗時方法的執行。 - 特殊情況未考慮：忽略了ViewPager+Fragment延時載入這些常見而複雜的情況，這些情況會造成實際測速時間非常不準。
- 手動注入程式碼：所有的程式碼都需要手動寫入，耦合進業務邏輯中，難以維護並且隨著新頁面的加入容易遺漏。
- 寫死配置檔案：如需新增或更改要測速的頁面，則需要修改本地配置檔案，進行發版。
目標方案效果
- 自動注入程式碼，無需手動寫入程式碼與業務邏輯耦合。
- 支援Activity和Fragment頁面測速，並解決ViewPager+Fragment延遲載入時測速不準的問題。
- 在Application的建構函式中開始冷啟動時間計算。
- 自動拉取和更新配置檔案，可以實時的進行配置檔案的更新。
實現
我們要實現一個自動化的測速外掛，需要分為五步進行：
- 測速定義：確定需要測量的速度指標並定義其計算方式。
- 配置檔案：通過配置檔案確定程式碼中需要測量速度指標的位置。
- 測速實現：如何實現時間的計算和上報。
- 自動化實現：如何自動化實現頁面測速，不需要手動注入程式碼。
- 疑難雜症：分析並解決特殊情況。
測速定義
我們把頁面載入流程抽象成一個通用的過程模型：頁面初始化 -> 初次渲染完成 -> 網路請求發起 -> 請求完成並重新整理頁面 -> 二次渲染完成。據此，要測量的內容包括以下方面：
- 專案的冷啟動時間：從App被建立，一直到我們首頁初次繪製出來所經歷的時間。
- 頁面的初次渲染時間：從Activity或Fragment的
onCreate()方法開始，一直到頁面View的初次渲染完成所經歷的時間。 - 頁面的初始網路請求時間：Activity或Fragment指定的一組初始請求，全部完成所用的時間。
- 頁面的二次渲染時間：Activity或Fragment所有的初始請求完成後，到頁面View再次渲染完成所經歷的時間。
需要注意的是，網路請求時間是指定的一組請求全部完成的時間，即從第一個請求發起開始，直到最後一個請求完成所用的時間。
根據定義我們的測速模型如下圖所示。
配置檔案
接下來要知道哪些頁面需要測速，以及頁面的初始請求是哪些API，這需要一個配置檔案來定義。
<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>
複製程式碼我們定義了一個XML配置檔案，每個 <page/> 標籤代表了一個頁面，其中 id 是頁面的類名或者全路徑類名，用以表示哪些Activity或者Fragment需要測速； tag 代表是否為首頁，這個首頁指的是用以計算冷啟動結束時間的頁面，比如我們想把冷啟動時間定義為從App建立到HomeActivity展示所需要的時間，那麼HomeActivity的tag就為1；每一個 <api/> 代表這個頁面的一個初始請求，比如HomeActivity頁面是個列表頁，一進來會先請求config介面，然後請求list介面，當list介面回來後展示列表資料，那麼該頁面的初始請求就是config和list介面。更重要的一點是，我們將該配置檔案維護在服務端，可以實時更新，而客戶端要做的只是在外掛SDK初始化時拉取最新的配置檔案即可。
測速實現
測速需要實現一個SDK，用於管理配置檔案、頁面測速物件、計算時間、上報資料等，專案接入後，在頁面的不同節點呼叫SDK提供的方法完成測速。
冷啟動開始時間
冷啟動的開始時間，我們以Application的建構函式被呼叫為準，在建構函式中進行時間點記錄，並在SDK初始化時，將時間點傳入作為冷啟動開始時間。
//Application
public MyApplication(){
super();
coldStartTime = SystemClock.elapsedRealtime();
}
//SDK初始化
public void onColdStart(long coldStartTime) {
this.startTime = coldStartTime;
}
複製程式碼這裡說明幾點：
- SDK中所有的時間獲取都使用
SystemClock.elapsedRealtime()機器時間，保證了時間的一致性和準確性。 - 冷啟動初始時間以建構函式為準，可以算入MultiDex注入的時間，比在
onCreate()中計算更為準確。 - 在建構函式中直接呼叫Java的API來計算時間，之後傳入SDK中，而不是直接呼叫SDK的方法，是為了防止MultiDex注入之前，呼叫到未注入的Dex中的類。
SDK初始化
SDK的初始化在 Application.onCreate() 中呼叫，初始化時會獲取服務端的配置檔案，解析為 Map<String,PageObject> ，對應配置中頁面的id和其配置項。另外還維護了一個當前頁面物件的 MAP<Integer, Object> ，key為一個int值而不是其類名，因為同一個類可能有多個例項同時在執行，如果存為一個key，可能會導致同一頁面不同例項的測速物件只有一個，所以在這裡我們使用Activity或Fragment的 hashcode() 值作為頁面的唯一標識。
頁面開始時間
頁面的開始時間，我們以Activtiy或Fragment的 onCreate() 作為時間節點進行計算，記錄頁面的開始時間。
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() 方法中，會使用頁面的類名或者全路徑類名，去初始化時解析的配置Map中進行id的匹配，如果匹配到說明頁面需要測速，就會建立測速物件 PageObject 進行測速。
網路請求時間
一個頁面的初始請求由配置檔案指定，我們只需在第一個請求發起前記錄請求開始時間，在最後一個請求回來後記錄結束時間即可。
boolean onApiLoadStart(String url) {
String relUrl = Utils.getRelativeUrl(url);
if (!hasApiConfig() || !hasUrl(relUrl) || apiStatusMap.get(relUrl.hashCode()) != NONE) {
return false;
}
//改變Url的狀態為執行中
apiStatusMap.put(relUrl.hashCode(), LOADING);
//第一個請求開始時記錄起始點
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的狀態為執行結束
apiStatusMap.put(relUrl.hashCode(), LOADED);
//全部請求結束後記錄時間
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;
}
複製程式碼每個頁面的測速物件，維護了一個請求url和其狀態的對映關係 SparseIntArray ，key就為請求url的hashcode，狀態初始為 NONE 。每次請求發起時，將對應url的狀態置為 LOADING ，結束時置為 LOADED 。當第一個請求發起時記錄起始時間，當所有url狀態為 LOADED 時說明所有請求完成，記錄結束時間。
渲染時間
按照我們對測速的定義，現在冷啟動開始時間有了，還差結束時間，即指定的首頁初次渲染結束時的時間；頁面的開始時間有了，還差頁面初次渲染的結束時間；網路請求的結束時間有了，還差頁面的二次渲染的結束時間。這一切都是和頁面的View渲染時間有關，那麼怎麼獲取頁面的渲染結束時間點呢？
由View的繪製流程可知，父View的 dispatchDraw() 方法會執行其所有子View的繪製過程，那麼把頁面的根View當做子View，是不是可以在其外部增加一層父View，以其 dispatchDraw() 作為頁面繪製完畢的時間點呢？答案是可以的。
class AutoSpeedFrameLayout extends FrameLayout {
public static View wrap(int pageObjectKey, @NonNull View child) {
...
//將頁面根View作為子View，其他引數保持不變
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;//關聯的頁面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() 方法執行super後，記錄相關頁面繪製結束的時間點。
測速完成
現在所有時間點都有了，那麼什麼時候算作測速過程結束呢？我們來看看每次渲染結束後的處理就知道了。
//PageObject.onPageDrawEnd()
void onPageDrawEnd() {
if (initialDrawEndTime <= 0) {//初次渲染還沒有完成
initialDrawEndTime = Utils.getRealTime();
if (!hasApiConfig() || allApiLoaded()) {//如果沒有請求配置或者請求已完成，則沒有二次渲染時間，即初次渲染時間即為頁面整體時間，且可以上報結束頁面了
finalDrawEndTime = -1;
reportIfNeed();
}
//頁面初次展示，回撥，用於統計冷啟動結束
callback.onPageShow(this);
return;
}
//如果二次渲染沒有完成，且所有請求已經完成，則記錄二次渲染時間並結束測速，上報資料
if (finalDrawEndTime <= 0 && (!hasApiConfig() || allApiLoaded())) {
finalDrawEndTime = Utils.getRealTime();
reportIfNeed();
}
}
複製程式碼該方法用於處理渲染完畢的各種情況，包括初次渲染時間、二次渲染時間、冷啟動時間以及相應的上報。這裡的冷啟動在 callback.onPageShow(this) 是如何處理的呢？
//初次渲染完成時的回撥
void onMiddlePageShow(boolean isMainPage) {
if (!isFinish && isMainPage && startTime > 0 && endTime <= 0) {
endTime = Utils.getRealTime();
callback.onColdStartReport(this);
finish();
}
}
複製程式碼還記得配置檔案中 tag 麼，他的作用就是指明該頁面是否為首頁，也就是程式碼段裡的 isMainPage 引數。如果是首頁的話，說明首頁的初次渲染結束，就可以計算冷啟動結束的時間並進行上報了。
上報資料
當測速完成後，頁面測速物件 PageObject 裡已經記錄了頁面（包括冷啟動）各個時間點，剩下的只需要進行測速階段的計算並進行網路上報即可。
//計算網路請求時間
long getApiLoadTime() {
if (!hasApiConfig() || apiLoadEndTime <= 0 || apiLoadStartTime <= 0) {
return -1;
}
return apiLoadEndTime - apiLoadStartTime;
}
複製程式碼自動化實現
有了SDK，就要在我們的專案中接入，並在相應的位置呼叫SDK的API來實現測速功能，那麼如何自動化實現API的呼叫呢？答案就是採用AOP的方式，在App編譯時動態注入程式碼，我們實現一個Gradle外掛，利用其Transform功能以及Javassist實現程式碼的動態注入。動態注入程式碼分為以下幾步：
- 初始化埋點：SDK的初始化。
- 冷啟動埋點：Application的冷啟動開始時間點。
- 頁面埋點：Activity和Fragment頁面的時間點。
- 請求埋點：網路請求的時間點。
初始化埋點
在 Transform 中遍歷所有生成的class檔案，找到Application對應的子類，在其 onCreate() 方法中呼叫SDK初始化API即可。
CtMethod method = it.getDeclaredMethod("onCreate")
method.insertBefore("${Constants.AUTO_SPEED_CLASSNAME}.getInstance().init(this);")
複製程式碼最終生成的Application程式碼如下：
public void onCreate() {
...
AutoSpeed.getInstance().init(this);
}
複製程式碼冷啟動埋點
同上一步，找到Application對應的子類，在其構造方法中記錄冷啟動開始時間，在SDK初始化時候傳入SDK，原因在上文已經解釋過。
//Application
private long coldStartTime;
public MobileCRMApplication() {
coldStartTime = SystemClock.elapsedRealtime();
}
public void onCreate(){
...
AutoSpeed.getInstance().init(this,coldStartTime);
}
複製程式碼頁面埋點
結合測速時間點的定義以及Activity和Fragment的生命週期，我們能夠確定在何處呼叫相應的API。
Activity
對於Activity頁面，現在開發者已經很少直接使用 android.app.Activity 了，取而代之的是 android.support.v4.app.FragmentActivity 和 android.support.v7.app.AppCompatActivity ，所以我們只需在這兩個基類中進行埋點即可，我們先來看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 一開始呼叫了 onPageCreate() 方法進行了頁面開始時間點的計算；在 setContentView() 內部，直接呼叫super，並將頁面根View包裝在我們自定義的 AutoSpeedFrameLayout 中傳入，用於渲染時間點的計算。
然而在AppCompatActivity中，重寫了setContentView()方法，且沒有呼叫super，呼叫的是 AppCompatDelegate 的相應方法。
public void setContentView(View view) {
getDelegate().setContentView(view);
}
複製程式碼這個delegate類用於適配不同版本的Activity的一些行為，對於setContentView，無非就是將根View傳入delegate相應的方法，所以我們可以直接包裝View，呼叫delegate相應方法並傳入即可。
public void setContentView(View view) {
AppCompatDelegate var2 = this.getDelegate();
var2.setContentView(AutoSpeed.getInstance().createPageView(this, view));
}
複製程式碼對於Activity的setContentView埋點需要注意的是，該方法是過載方法，我們需要對每個過載的方法做處理。
Fragment
Fragment的 onCreate() 埋點和Activity一樣，不必多說。這裡主要說下 onCreateView() ，這個方法是返回值代表根View，而不是直接傳入View，而Javassist無法單獨修改方法的返回值，所以無法像Activity的setContentView那樣注入程式碼，並且這個方法不是 @CallSuper 的，意味著不能在基類裡實現。那麼怎麼辦呢？我們決定在每個Fragment的該方法上做一些事情。
//Fragment標誌位
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;
}
}
複製程式碼我們利用一個boolean型別的標誌位，進行遞迴呼叫 onCreateView() 方法：
- 最初呼叫時，會將標誌位置為false，然後遞迴呼叫該方法。
- 遞迴呼叫時，由於標誌位為false所以會呼叫原有邏輯，即獲取根View。
- 獲取根View後，包裝為
AutoSpeedFrameLayout返回。
並且由於標誌位為false，所以在遞迴呼叫時，即使呼叫了 super.onCreateView() 方法，在父類的該方法中也不會走if分支，而是直接返回其根View。
請求埋點
關於請求埋點我們針對不同的網路框架進行不同的處理，外掛中只需要配置使用了哪些網路框架即可實現埋點，我們拿現在用的最多的 Retrofit 框架來說。
開始時間點
在建立Retrofit物件時，需要 OkHttpClient 物件，可以為其新增 Interceptor 進行請求發起前 Request 的攔截，我們可以構建一個用於記錄請求開始時間點的Interceptor，在 OkHttpClient.Builder() 呼叫時，插入該物件。
public Builder() {
this.addInterceptor(new AutoSpeedRetrofitInterceptor());
...
}
複製程式碼而該Interceptor物件就是用於在請求發起前，進行請求開始時間點的記錄。
public class AutoSpeedRetrofitInterceptor implements Interceptor {
public Response intercept(Chain var1) throws IOException {
AutoSpeed.getInstance().onApiLoadStart(var1.request().url());
return var1.proceed(var1.request());
}
}
複製程式碼結束時間點
使用Retrofit發起請求時，我們會呼叫其 enqueue() 方法進行非同步請求，同時傳入一個 Callback 進行回撥，我們可以自定義一個Callback，用於記錄請求回來後的時間點，然後在enqueue方法中將引數換為自定義的Callback，而原Callback作為其代理物件即可。
public void enqueue(Callback<T> callback) {
final Callback<T> callback = new AutoSpeedRetrofitCallback(callback);
...
}
複製程式碼該Callback物件用於在請求成功或失敗回撥時，記錄請求結束時間點，並呼叫代理物件的相應方法處理原有邏輯。
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時，發起請求時內部是呼叫的 execute() 方法進行同步請求，我們只需要在其執行前後插入計算時間的程式碼即可，此處不再贅述。
疑難雜症
至此，我們基本的測速框架已經完成，不過經過我們的實踐發現，有一種情況下測速資料會非常不準，那就是開頭提過的ViewPager+Fragment並且實現延遲載入的情況。這也是一種很常見的情況，通常是為了節省開銷，在切換ViewPager的Tab時，才首次呼叫Fragment的初始載入方法進行資料請求。經過除錯分析，我們找到了問題的原因。
等待切換時間
該圖紅色時間段反映出，直到ViewPager切換到Fragment前，Fragment不會發起請求，這段等待的時間就會延長整個頁面的載入時間，但其實這塊時間不應該算在內，因為這段時間是使用者無感知的，不能作為頁面耗時過長的依據。
那麼如何解決呢？我們都知道ViewPager的Tab切換是可以通過一個 OnPageChangeListener 物件進行監聽的，所以我們可以為ViewPager新增一個自定義的Listener物件，在切換時記錄一個時間，這樣可以通過用這個時間減去頁面建立後的時間得出這個多餘的等待時間，上報時在總時間中減去即可。
public ViewPager(Context context) {
...
this.addOnPageChangeListener(new AutoSpeedLazyLoadListener(this.mItems));
}
複製程式碼mItems 是ViewPager中當前頁面物件的陣列，在Listener中可以通過他找到對應的頁面，進行切換時的埋點。
//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() 方法記錄頁面的切換時間。這樣一來，在計算頁面載入速度總時間時，就要減去這一段時間。
long getTotalTime() {
if (createTime <= 0) {
return -1;
}
if (finalDrawEndTime > 0) {//有二次渲染時間
long totalTime = finalDrawEndTime - createTime;
//如果有等待時間，則減掉這段多餘的時間
if (selectedTime > 0 && selectedTime > viewCreatedTime && selectedTime < finalDrawEndTime) {
totalTime -= (selectedTime - viewCreatedTime);
}
return totalTime;
} else {//以初次渲染時間為整體時間
return getInitialDrawTime();
}
}
複製程式碼這裡減去的 viewCreatedTime 不是Fragment的 onCreate() 時間，而應該是 onViewCreated() 時間，因為從onCreate到onViewCreated之間的時間也是應該算在頁面載入時間內，不應該減去，所以為了處理這種情況，我們還需要對Fragment的onViewCreated方法進行埋點，埋點方式同 onCreate() 的埋點。
渲染時機不固定
此外經實踐發現，由於不同View在繪製子View時的繪製原理不一樣，有可能會導致以下情況的發生：
- 沒有切換至Fragment時，Fragment的View初次渲染已經完成，即View不可見的情況下也呼叫了
dispatchDraw()。 - 沒有切換至Fragment時，Fragment的View初次渲染未完成，即直到View初次可見時
dispatchDraw()才會呼叫。 - 沒有延遲載入時，當ViewPager沒有切換到Fragment，而是直接傳送請求後，請求回來時更新View，會呼叫
dispatchDraw()進行二次渲染。 - 沒有延遲載入時，當ViewPager沒有切換到Fragment，而是直接傳送請求後，請求回來時更新View，不會呼叫
dispatchDraw()，即直到切換到Fragment時才會進行二次渲染。
上面的問題總結來看，就是初次渲染時間和二次渲染時間中，可能會有個等待切換的時間，導致這兩個時間變長，而這個切換時間點並不是 onPageSelected() 方法呼叫的時候，因為該方法是在Fragment完全滑動出來之後才會呼叫，而這個問題裡的切換時間點，應該是指View初次展示的時候，也就是剛一滑動，ViewPager露出目標View的時間點。於是類比延遲載入的切換時間，我們利用Listener的 onPageScrolled() 方法，在ViewPager滑動時，找到目標頁面，為其記錄一個滑動時間點 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;
}
}
}
}
}
複製程式碼那麼這樣就可以解決兩次渲染的誤差：
- 初次渲染時間中，
scrollToTime - viewCreatedTime就是頁面建立後，到初次渲染結束之間，因為等待滾動而產生的多餘時間。 - 二次渲染時間中，
scrollToTime - apiLoadEndTime就是請求完成後，到二次渲染結束之間，因為等待滾動而產生的多餘時間。
於是在計算初次和二次渲染時間時，可以減去多餘時間得到正確的值。
long getInitialDrawTime() {
if (createTime <= 0 || initialDrawEndTime <= 0) {
return -1;
}
if (scrollToTime > 0 && scrollToTime > viewCreatedTime && scrollToTime <= initialDrawEndTime) {//延遲初次渲染，需要減去等待的時間(viewCreated->changeToPage)
return initialDrawEndTime - createTime - (scrollToTime - viewCreatedTime);
} else {//正常初次渲染
return initialDrawEndTime - createTime;
}
}
long getFinalDrawTime() {
if (finalDrawEndTime <= 0 || apiLoadEndTime <= 0) {
return -1;
}
//延遲二次渲染，需要減去等待時間(apiLoadEnd->scrollToTime)
if (scrollToTime > 0 && scrollToTime > apiLoadEndTime && scrollToTime <= finalDrawEndTime) {
return finalDrawEndTime - apiLoadEndTime - (scrollToTime - apiLoadEndTime);
} else {//正常二次渲染
return finalDrawEndTime - apiLoadEndTime;
}
}
複製程式碼總結
以上就是我們對頁面測速及自動化實現上做的一些嘗試，目前已經在專案中使用，並在監控平臺上可以獲取實時的資料。我們可以通過分析資料來了解頁面的效能進而做優化，不斷提升專案的整體質量。並且通過實踐發現了一些測速誤差的問題，也都逐一解決，使得測速資料更加可靠。自動化的實現也讓我們在後續開發中的維護變得更容易，不用維護頁面測速相關的邏輯，就可以做到實時監測所有頁面的載入速度。
參考文獻
作者介紹
文傑，美團前端Android開發工程師，2016年畢業於天津工業大學，同年加入美團點評到店餐飲事業群，從事商家銷售端移動應用開發工作。