Practice of Android automated page speed measurement in Meituan

background

With the rapid development of mobile Internet, mobile applications pay more and more attention to user experience. Meituan's technical team also pays great attention to improving the overall quality of mobile applications during the development process, and one of the most important aspects is the page loading speed. If the cold start time is too long, the page rendering time is too long, the network request is too slow, etc., it will directly affect the user experience. Therefore, how to monitor the loading speed of the entire project has become an important challenge facing our department.

When it comes to speed measurement, many students first think of adding time calculation code to different nodes in the page to calculate the length of a certain period of time. However, with the rapid iteration of Meituan's business, there will be more and more new pages, more and more business logic, and more and more code changes. These uncertainties will couple the code of our speed measurement part into the business logic and require manual maintenance, which in turn increases costs and risks. Therefore, by drawing on some of the company's previous solutions, analyzing their existing problems and combining their own characteristics, we have implemented a set of automatic page speed measurement plug-ins that do not require business code intrusion. This article will explain and analyze its principles.

Existing solutions

• Manually call the SDK initialization in Application.onCreate() and calculate the cold start time.

• Manually add code to the Activity lifecycle method to calculate the time of different stages of the page.
• Manually add a custom parent View to the View set by Activity.setContentView() to calculate the time it takes to complete the drawing.
• Manually add code before and after each network request to calculate the time of the network request.

Declare the JSON configuration file locally to determine the page that needs to be tested and the initial network request API that needs to be counted for the page. Use getClass().getSimpleName() as the key of the page to identify which pages need to be tested, and specify a set of APIs to identify which requests need to be tested.

Problems with existing solutions

• Inaccurate cold start time: The cold start start time is calculated from Application.onCreate(), which will make the calculated cold start time smaller because time-consuming methods such as MultiDex.install() may be executed before this method is executed.
• Special cases are not considered: Common and complex cases such as ViewPager+Fragment delayed loading are ignored, which will cause the actual speed measurement time to be very inaccurate.
• Manual code injection: All codes need to be written manually and coupled into the business logic, which is difficult to maintain and easy to be missed as new pages are added.
• Hard-coded configuration file: If you need to add or change the page to be tested, you need to modify the local configuration file and publish it.

Target program effect

• Automatically inject code, eliminating the need to manually write code to couple with business logic.
• Supports Activity and Fragment page speed measurement, and solves the problem of inaccurate speed measurement during ViewPager+Fragment delayed loading.
• Start the cold start time calculation in the Application constructor.
• Automatically pull and update configuration files, and update configuration files in real time.

accomplish

We need to implement an automated speed test plug-in in five steps:

• Speed ​​measurement definition: Determine the speed metric that needs to be measured and define how to calculate it.
• Configuration file: Use the configuration file to determine where in the code you want to measure speed metrics.
• Speed ​​measurement implementation: How to calculate and report time.
• Automated implementation: How to automatically implement page speed measurement without manual code injection.
• Troubleshooting: Analyze and solve special situations.

Speed ​​measurement definition

We abstract the page loading process into a general process model: page initialization -> initial rendering completed -> network request initiated -> request completed and page refreshed -> secondary rendering completed. Based on this, the content to be measured includes the following aspects:

• Cold start time of a project: the time from when the App is created until the first drawing of our homepage.
• The initial rendering time of the page: the time from the onCreate() method of the Activity or Fragment to the completion of the initial rendering of the page View.
• Initial network request time of the page: the time it takes to complete a set of initial requests specified by the Activity or Fragment.
• Second rendering time of the page: the time it takes for all initial requests of the Activity or Fragment to be completed until the page View is rendered again.

It should be noted that the network request time is the time it takes for a specified set of requests to be completed, that is, the time from the initiation of the first request to the completion of the last request.

According to the definition, our speed measurement model is shown in the figure below.

Configuration Files

The next step is to determine which pages need speed testing and which APIs are the initial requests for the pages. This requires a configuration file to define.

 <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>

We defined an XML configuration file. Each tag represents a page. The id is the class name or full path class name of the page, which is used to indicate which Activities or Fragments need to be tested. The tag represents whether it is the home page. The home page refers to the page used to calculate the cold start end time. For example, if we want to define the cold start time as the time required from App creation to HomeActivity display, then the tag of HomeActivity is 1. Each one represents an initial request for this page. For example, the HomeActivity page is a list page. When it comes in, it will first request the config interface, and then request the list interface. When the list interface comes back, it displays the list data. Then the initial request for the page is the config and list interfaces. More importantly, we maintain the configuration file on the server side, which can be updated in real time. All the client needs to do is to pull the latest configuration file when the plugin SDK is initialized.

Speed ​​measurement implementation

Speed ​​testing requires the implementation of an SDK to manage configuration files, page speed test objects, calculation time, reported data, etc. After the project is connected, the methods provided by the SDK are called at different nodes of the page to complete the speed test.

Cold start start time

The start time of the cold start is based on the time when the Application constructor is called. The time point is recorded in the constructor and passed in as the cold start start time when the SDK is initialized.

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

Here are a few points:

• All time acquisition in the SDK uses SystemClock.elapsedRealtime() machine time to ensure time consistency and accuracy.
• The initial cold start time is based on the constructor, which can include the time of MultiDex injection, and is more accurate than calculating in onCreate().
• Directly calling the Java API in the constructor to calculate the time and then passing it to the SDK instead of directly calling the SDK method is to prevent calling the class in the uninjected Dex before MultiDex is injected.

SDK Initialization

The SDK is initialized in Application.onCreate(). During initialization, the server configuration file is obtained and parsed into a Map, corresponding to the page id and its configuration items in the configuration. In addition, a MAP of the current page object is maintained, with the key being an int value instead of its class name, because the same class may have multiple instances running at the same time. If it is stored as a key, there may be only one speed measurement object for different instances of the same page. Therefore, here we use the hashcode() value of Activity or Fragment as the unique identifier of the page.

Page start time

The start time of the page, we use the onCreate() of Activtiy or Fragment as the time node for calculation and record the start time of the page.

 public void onPageCreate(Object page) {
 int pageObjKey = Utils.getPageObjKey(page);
    PageObject pageObject = activePages.get(pageObjKey);
 ConfigModel configModel = getConfigModel(page); //Get the configuration of this page
 if (pageObject == null && configModel != null ) {//Speed ​​measurement is required if there is configuration
        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();
 }

In the getConfigModel() method here, the class name or full path class name of the page is used to match the id in the configuration Map parsed during initialization. If a match is found, indicating that the page needs speed measurement, a speed measurement object PageObject will be created for speed measurement.

Network request time

The initial request for a page is specified by the configuration file. We only need to record the start time of the request before the first request is initiated and the end time after the last request comes back.

 boolean onApiLoadStart(String url) {
    String relUrl = Utils.getRelativeUrl(url);
    if (!hasApiConfig() || !hasUrl(relUrl) || apiStatusMap.get(relUrl.hashCode()) != NONE) {
 return   false ;
 }
 //Change the status of Url to executing
    apiStatusMap.put(relUrl.hashCode(), LOADING);
 //Record the starting point when the first request begins
    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 ;
 }
 //Change the status of Url to end of execution
    apiStatusMap.put(relUrl.hashCode(), LOADED);
 //Record the time after all requests are completed
    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 ;
 }

The speed test object of each page maintains a SparseIntArray mapping relationship between the request URL and its status. The key is the hashcode of the request URL, and the initial status is NONE. Each time a request is initiated, the status of the corresponding URL is set to LOADING, and when it ends, it is set to LOADED. When the first request is initiated, the start time is recorded. When the status of all URLs is LOADED, it means that all requests are completed, and the end time is recorded.

Rendering time

According to our definition of speed test, now we have the cold start start time, but we still need the end time, which is the time when the first rendering of the specified homepage ends; we have the page start time, but we still need the end time of the first rendering of the page; we have the network request end time, but we still need the end time of the second rendering of the page. All of these are related to the View rendering time of the page, so how do we get the end time of the page rendering?

From the drawing process of View, we can know that the dispatchDraw() method of the parent View will execute the drawing process of all its child Views. So if we treat the root View of the page as a child View, can we add a layer of parent View outside it and use its dispatchDraw() as the time point when the page drawing is completed? The answer is yes.

 class AutoSpeedFrameLayout extends FrameLayout {
 public   static   View wrap( int pageObjectKey, @NonNull View child) {
 ...
 //Use the root View of the page as a child View , and keep other parameters unchanged
        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; //Associated page 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);
 }
 }

We customize a layer of FrameLayout as the parent View of all page root Views. After its dispatchDraw() method executes super, it records the time point when the drawing of the relevant page ends.

Speed ​​test completed

Now that we have all the time points, when does the speed measurement process end? Let's take a look at the processing after each rendering.

 //PageObject.onPageDrawEnd()
 void onPageDrawEnd() {
 if (initialDrawEndTime <= 0) {//The initial rendering is not yet completed
        initialDrawEndTime = Utils.getRealTime();
 if (!hasApiConfig() || allApiLoaded()) { //If no request configuration is made or the request is completed, there is no secondary rendering time, that is, the initial rendering time is the entire page time, and the end page can be reported
            finalDrawEndTime = -1;
 reportIfNeed();
 }
 //First display of the page, callback, used to count the end of cold start
        callback.onPageShow(this);
 return ;
 }
 //If the second rendering is not completed and all requests have been completed, record the second rendering time and end the speed test, and report the data
    if (finalDrawEndTime <= 0 && (!hasApiConfig() || allApiLoaded())) {
        finalDrawEndTime = Utils.getRealTime();
 reportIfNeed();
 }
 }

This method is used to handle various situations after rendering is completed, including the initial rendering time, the secondary rendering time, the cold start time, and the corresponding reporting. How is the cold start handled in callback.onPageShow(this)?

 //Callback when the initial rendering is completed
 void onMiddlePageShow(boolean isMainPage) {
    if (!isFinish && isMainPage && startTime > 0 && endTime <= 0) {
        endTime = Utils.getRealTime();
        callback.onColdStartReport(this);
 finish();
 }
 }

Remember the tag in the configuration file? Its function is to indicate whether the page is the home page, which is the isMainPage parameter in the code snippet. If it is the home page, it means that the initial rendering of the home page is completed, and the time when the cold start ends can be calculated and reported.

Reporting data

When the speed test is completed, the page speed test object PageObject has recorded various time points of the page (including cold start). What remains is to perform calculations in the speed test phase and report to the network.

 //Calculate network request time
 long getApiLoadTime() {
    if (!hasApiConfig() || apiLoadEndTime <= 0 || apiLoadStartTime <= 0) {
 return -1;
 }
 return apiLoadEndTime - apiLoadStartTime;
 }

Automation

With the SDK, we need to connect it to our project and call the SDK API at the corresponding location to implement the speed measurement function. So how can we automatically call the API? The answer is to use AOP to dynamically inject code when the App is compiled. We implement a Gradle plug-in and use its Transform function and Javassist to implement dynamic code injection. Dynamic code injection is divided into the following steps:

• Initialization tracking point: Initialization of SDK.
• Cold start tracking point: the time point when the application starts cold start.
• Page tracking points: the time points of Activity and Fragment pages.
• Request tracking point: the time point of the network request.

Initialize the tracking point

Traverse all generated class files in Transform, find the subclass corresponding to Application, and call the SDK initialization API in its onCreate() method.

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

The final generated Application code is as follows:

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

Cold start tracking

As in the previous step, find the subclass corresponding to Application, record the cold start start time in its constructor, and pass it to the SDK when the SDK is initialized. The reason has been explained above.

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

Page embedding

Combining the definition of the speed measurement time point and the life cycle of Activity and Fragment, we can determine where to call the corresponding API.

Activity

For the Activity page, developers now rarely use android.app.Activity directly. Instead, they use android.support.v4.app.FragmentActivity and android.support.v7.app.AppCompatActivity. So we only need to embed points in these two base classes. Let's look at FragmentActivity first.

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

After the code is injected, the onPageCreate() method is called at the beginning of FragmentActivity's onCreate to calculate the start time of the page; inside setContentView(), super is called directly, and the root View of the page is wrapped in our custom AutoSpeedFrameLayout and passed in for the calculation of the rendering time.

However, in AppCompatActivity, the setContentView() method is overridden, and super is not called. Instead, the corresponding method of AppCompatDelegate is called.

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

This delegate class is used to adapt some behaviors of different versions of Activities. For setContentView, it is nothing more than passing the root View into the corresponding method of the delegate, so we can directly wrap the View, call the corresponding method of the delegate and pass it in.

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

What needs to be noted about the Activity's setContentView tracking point is that this method is an overloaded method, and we need to process each overloaded method.

Fragment

The onCreate() method of Fragment is the same as that of Activity, so there is no need to explain it in detail. Here we mainly talk about onCreateView(). The return value of this method represents the root View, rather than directly passing in the View. Javassist cannot modify the return value of the method alone, so it is impossible to inject code like the setContentView of Activity. In addition, this method is not @CallSuper, which means it cannot be implemented in the base class. So what should we do? We decided to do something on this method of each Fragment.

 //Fragment flag
 protected static boolean AUTO_SPEED_FRAGMENT_CREATE_VIEW_FLAG = true ;
 //Use recursion to wrap the root 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;
 }
 }

We use a boolean flag to recursively call the onCreateView() method:

1. When initially called, the flag is set to false, and then the method is called recursively.
2. When calling recursively, since the flag is false, the original logic will be called, that is, the root View will be obtained.
3. After getting the root View, wrap it in AutoSpeedFrameLayout and return it.

And because the flag is false, even if the super.onCreateView() method is called during a recursive call, the if branch will not be followed in the method of the parent class, but the root View will be returned directly.

Request a point

Regarding request tracking, we handle different requests for different network frameworks differently. The plug-in only needs to configure which network frameworks are used to implement tracking. Let's take the most commonly used Retrofit framework as an example.

Start time

When creating a Retrofit object, an OkHttpClient object is required. You can add an Interceptor to it to intercept the Request before the request is initiated. We can build an Interceptor for recording the start time of the request and insert the object when OkHttpClient.Builder() is called.

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

The Interceptor object is used to record the start time of the request before the request is initiated.

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

End time

When using Retrofit to initiate a request, we will call its enqueue() method for asynchronous request and pass in a Callback for callback. We can customize a Callback to record the time point after the request comes back, and then replace the parameter with the customized Callback in the enqueue method, and the original Callback can be used as its proxy object.

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

The Callback object is used to record the request end time point when the request succeeds or fails, and call the corresponding method of the proxy object to process the original logic.

 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);
 }
 }

When using Retrofit+RXJava, the execute() method is called internally to make a synchronous request when a request is initiated. We only need to insert the code for calculating the time before and after its execution, which will not be repeated here.

Difficult and complicated diseases

So far, our basic speed test framework has been completed. However, we have found through practice that there is a situation where the speed test data will be very inaccurate, that is, the situation mentioned at the beginning of ViewPager + Fragment and delayed loading. This is also a very common situation. Usually, in order to save costs, the initial loading method of Fragment is called first to request data when switching the ViewPager Tab. After debugging and analysis, we found the cause of the problem.

Waiting time for switching

The red time period in the figure reflects that the Fragment will not initiate a request until the ViewPager switches to the Fragment. This waiting time will extend the loading time of the entire page, but in fact this time should not be counted, because this period of time is not perceived by the user and cannot be used as a basis for the page taking too long.

So how to solve it? We all know that the Tab switching of ViewPager can be monitored through an OnPageChangeListener object, so we can add a custom Listener object to ViewPager and record a time when switching. In this way, the extra waiting time can be obtained by subtracting the time after the page is created from this time, and it can be subtracted from the total time when reporting.

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

mItems is an array of the current page objects in ViewPager. It can be used in Listener to find the corresponding page and perform switching.

 //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's onPageSelected() method records the page switching time. In this way, when calculating the total page loading speed, this period of time must be subtracted.

 long getTotalTime() {
 if (createTime <= 0) {
 return -1;
 }
 if (finalDrawEndTime > 0) {//There is a second rendering time
        long totalTime = finalDrawEndTime - createTime;
 //If there is waiting time, subtract this extra time
        if (selectedTime > 0 && selectedTime > viewCreatedTime && selectedTime < finalDrawEndTime) {
            totalTime -= (selectedTime - viewCreatedTime);
 }
 return totalTime;
 } else {//Use the initial rendering time as the overall time
 return getInitialDrawTime();
 }
 }

The viewCreatedTime subtracted here is not the onCreate() time of the Fragment, but the onViewCreated() time, because the time from onCreate to onViewCreated should also be counted in the page loading time and should not be subtracted. So in order to deal with this situation, we also need to track the onViewCreated method of the Fragment, and the tracking method is the same as that of onCreate().

Rendering timing is not fixed

In addition, it has been found in practice that different Views have different drawing principles when drawing sub-Views, which may lead to the following situations:

• When not switching to Fragment, the initial rendering of Fragment's View has been completed, that is, dispatchDraw() is called even when View is not visible.
• When not switching to Fragment, the initial rendering of Fragment's View is not completed, that is, dispatchDraw() will not be called until the View is first visible.
• When there is no delayed loading, when ViewPager does not switch to Fragment, but directly sends a request, the View is updated when the request comes back, and dispatchDraw() is called for secondary rendering.
• When there is no delayed loading, when ViewPager does not switch to Fragment, but directly sends a request, the View is updated when the request comes back, and dispatchDraw() is not called, that is, the second rendering will not be performed until switching to Fragment.

To summarize the above problems, there may be a waiting time for switching between the first rendering time and the second rendering time, which makes the two times longer. This switching time point is not when the onPageSelected() method is called, because this method is called after the Fragment is completely slid out. The switching time point in this problem should refer to the first display of the View, that is, the time point when the ViewPager reveals the target View as soon as it slides. So, analogous to the switching time of delayed loading, we use the onPageScrolled() method of Listener to find the target page when the ViewPager slides, and record a sliding time point scrollToTime for it.

 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;
 }
 }
 }
 }
 }

Then this can solve the error of two renderings:

• In the initial rendering time, scrollToTime - viewCreatedTime is the extra time generated by waiting for scrolling between the creation of the page and the end of the initial rendering.
• In the secondary rendering time, scrollToTime - apiLoadEndTime is the extra time generated by waiting for scrolling between the completion of the request and the end of the secondary rendering.

So when calculating the initial and secondary rendering times, you can subtract the extra time to get the correct value.

 long getInitialDrawTime() {
    if (createTime <= 0 || initialDrawEndTime <= 0) {
 return -1;
 }
 if (scrollToTime > 0 && scrollToTime > viewCreatedTime && scrollToTime <= initialDrawEndTime) {//Delay the initial rendering, minus the waiting time (viewCreated->changeToPage)
 return initialDrawEndTime - createTime - (scrollToTime - viewCreatedTime);
 } else {//Normal initial rendering
 return initialDrawEndTime - createTime;
 }
 }
 long getFinalDrawTime() {
    if (finalDrawEndTime <= 0 || apiLoadEndTime <= 0) {
 return -1;
 }
 //Delay the second rendering, subtract the waiting time (apiLoadEnd->scrollToTime)
    if (scrollToTime > 0 && scrollToTime > apiLoadEndTime && scrollToTime <= finalDrawEndTime) {
 return finalDrawEndTime - apiLoadEndTime - (scrollToTime - apiLoadEndTime);
 } else {//Normal secondary rendering
 return finalDrawEndTime - apiLoadEndTime;
 }
 }

Summarize

The above are some of our attempts at page speed measurement and automation. They are currently being used in projects, and real-time data can be obtained on the monitoring platform. We can analyze the data to understand the performance of the page and then optimize it, continuously improving the overall quality of the project. In addition, through practice, we have discovered some speed measurement error problems, which have been solved one by one, making the speed measurement data more reliable. The automation also makes it easier for us to maintain in subsequent development. We can monitor the loading speed of all pages in real time without maintaining the logic related to page speed measurement.

About the Author

Wenjie, a front-end Android development engineer at Meituan, graduated from Tianjin Polytechnic University in 2016. In the same year, he joined Meituan-Dianping's in-store catering business group and worked on the development of mobile applications for merchants' sales.