DroidMeter: A Measurement Tool to Study Embedded Web Pages

TL;DR

DroidMeter is a tool designed to automatically identify embedded Web pages within mobile apps, measure their load performance, and provide insights into their prevalence and efficiency in mobile browsing.

Contribution

This paper introduces DroidMeter, a novel measurement tool that automates the detection and performance analysis of embedded Web pages in mobile applications.

Findings

Embedded Web pages are prevalent in mobile apps.

Performance varies significantly across different embedded Web pages.

DroidMeter enables large-scale analysis of embedded Web browsing performance.

Abstract

Traditional Web browsing involves typing a URL on a browser and loading a Web page. In contrast, there is another form of Web browsing on mobile devices, i.e., embedded Web browsing, which occurs when mobile apps embed a Web page within the app. When the user navigates to the specific page in the app, the Web page is loaded from within the app. However, little is known about the prevalence or performance of these embedded Web pages. To analyze the embedded Web browsing performance at scale, we design and implement DroidMeter, a tool that can automatically search for embedded Web pages inside apps, trigger page loads, and retrieve performance metrics.

Figures

Full text

**DroidMeter: A Measurement Tool to Study Embedded Web Pages **

Deyu Tian1, tiandeyu@pku.edu.cn

**1 Key Lab of High-Confidence Software Technology, MoE (Peking University), Beijing, China

**

Abstract

Traditional Web browsing involves typing a URL on a browser and loading a Web page. In contrast, there is another form of Web browsing on mobile devices, i.e., embedded Web browsing, which occurs when mobile apps embed a Web page within the app. When the user navigates to the specific page in the app, the Web page is loaded from within the app. However, little is known about the prevalence or performance of these embedded Web pages. To analyze the embedded Web browsing performance at scale, we design and implement DroidMeter, a tool that can automatically search for embedded Web pages inside apps, trigger page loads, and retrieve performance metrics.

1 Introduction

Native mobile applications (a.k.a., apps) and mobile Web pages are two of the most popular ways for users to access mobile content [25, 19]. While these two medium of access may seem distinct, it is becoming increasingly common for mobile apps to embed a Web page within them.

We call Web pages embedded in mobile apps, embedded Web pages, in the rest of this paper. When users navigate to the embedded Web page inside an app, they can interact with the page as they usually do on their browser. Figure 1 shows an example of embedded pages for the app All Football. Interestingly, part of the screen (indicated by the red dashed lines) is a Web page loaded in the embedded browser, while the rest of the screen is rendered using the native app. Mobile apps embed Web pages for various reasons including portability across platforms, reusing third-party content easily, and for uniform interface for the users.

Unfortunately, characterizing the performance of the embedded Web page loads is inherently not straightforward but quite challenging. Traditional Web page load performance can be studied at scale by loading the Web page URL on the browsers programmatically. However, loading an embedded Web page requires that we navigate to the application page that contains the embedded Web page. Triggering this embedded page load involves navigating through multiple UI screens on the app, requiring user inputs that are not known a-priori. Further, embedded browsers do not support APIs for developer tools that are available in most modern browsers, making performance analysis more challenging.

To address the issue, we design and implement DroidMeter, an automation tool of measuring the performance of embedded Web browsing for Android apps. DroidMeter first explores the app by clicking on UI elements to navigate to various pages, searching for embedded Web pages. After exploration, for each visited embedded Web page, DroidMeter generates a replay script that contains the sequence of UI events to trigger the embedded Web page. The key idea of DroidMeter is that we use the structure of UI tree to identify different app pages and thus every single event can be correctly triggered even when there are trivial UI changes during the replay phase. As for retrieving embedded page’s information, we port existing developer tools that are available for traditional browsers to DroidMeter. Specifically, we re-implement the Chrome remote debugging [1] and expose the APIs. This porting allows us to collect performance metrics about the embedded page load, including the load time and the information about Web resources that are loaded.

The remainder of this paper is organized as follows. Section 2 shows some background knowledge of how Web pages are embedded on Android. Section 3 describes the DroidMeter tool that we design for measuring embedded Web browsing. Section 4 shows the usage and behavior of DroidMeter by examining its execution procedure. Section 5 surveys related work, and Section 6 concludes the paper.

2 Background

Modern mobile OSes such as Android and iOS provide a special UI framework to display Web pages from within an app. For example, Android apps embed, WebView [10], a framework to load Web pages. Using this framework, one can display Web pages from within the apps using either the Chromium browser engine (after Android 4.4) or the WebKit engine (before Android 4.4). Figure 1 shows an example of an app page with WebView. The part highlighted by a dashed line box is an embedded Web page, showing the events of a football match.

Android Webview has been a critical component in Android System for long. The Android Webview is supported by WebKit [8] engine until Android 4.3. Starting from Android 4.4 Kitkat, the Android Webview uses the chromium [9] engine, which is similar to Google Chrome. After Android 5.0 Lollipop, Android Webview becomes a separate app and gets its update via App Store like normal apps. Such modification is aimed to fix some security vulnerabilities noticed in older version.

Figure 2 shows how an Android app embeds a WebView in an app page. Each page in an Android app is an instance of activity and there is one or more layout files corresponding to the activity. To embed a Webpage, developers first declare a WebView in the layout file. As shown in Figure 2 (a), a WebView with the id “web” is declared in webLayout.xml file. Then in the onCreate() method of the activity, the developer retrieves the WebView instance and loads the page http://www.example.com.

3 Methodology

Given the prevalence of embedded Web pages, it is important to study the performance and characteristics of embedded Web pages. There are several developer tools available to measure the performance of traditional browsers. Unfortunately, measuring the performance of embedded Web pages is more challenging.

First, embedded Web browsing is triggered only if the user reaches the specific activity in the app through a series of UI interactions. These UI interactions are different for different apps, and cannot be obtained a priori. Second, the developer tools designed to analyze Web performance cannot be directly used to analyze embedded browsing. Although the Chrome browser provides a GUI-based tool to remotely debug embedded pages, they cannot be accessed programmatically.

3.1 DroidMeter Architecture

We address these two challenges by building an automation tool DroidMeter to analyze the performance of embedded pages. Figure 3 shows the architecture of DroidMeter, which consists of three components: explorer, replayer, and page collector.

Given an app under analysis, the explorer launches the app and traverse to app pages. During the traversal, the explorer builds a state machine of page transition. If the tool lands on an activity that embeds a Web page (for example, pages P4 and P5 shown in dashed line), the tool generates a replay script. This replay script records the set of steps from the beginning of the app to the activity with the embedded Web page. Using the script, the replayer can trigger the embedded Web page. Meanwhile, the page collector retrieves performance metrics about the embedded Web pages. We give the details of each component as follows.

3.1.1 Explorer

The explorer is a modified version of the Monkey tool [6] provided by the Android SDK. The Monkey tool is an automation tool that can traverse through the different activities of the app but randomly clicking and typing on the UI of the app. Similar to the Monkey tool, the explorer launches the app and performs a depth-first search to traverse the app activities. Searching essentially involves clicking on various UI elements to either trigger a change in UI or trigger a navigation to a different activity. The explorer performs dynamic analysis to identify embedded Web pages in an activity. Specifically the explorer parses the UI structure of each activity to identify if the activity contains an embedded Web page.

There are two key problems with existing automation tools such as the Monkey tool [6]. The first is coverage and the second is repeated traversal to the same activity. The DroidMeter explorer avoid both by (a) maintaining a state machine and (b) using the UI structure of each activity to distinguish between the activities. DroidMeter build a page transition model. The model is a state machine where each node represents an app page and the edge represents the page transition via events.

DroidMeter is able to differentiate between the activities using the structure of the UI tree [2]. The UI tree consists of UI elements of an app page similar to a DOM tree of Web pages. Since the structure does not change significantly during replay, DroidMeter is able to faithfully reach the target embedded Web pages.

3.1.2 Replayer

At the end of the exploration, DroidMeter generates a script to reach all activities with an embedded Web page. For example, in Figure 3 page P4 is an app page with embedded Web page, and the replay script of P4 is to first trigger event e1 on page P1 and then trigger event e3 on page P2. To open the page, the replayer component triggers each event according to the script. The state machine we built as part of the explorer is used to locate the UI elements that will trigger each transformation.

3.1.3 Page Collector

During the replay, the page collector retrieves information about the loading procedure of both the embedded Web page and the Android native activity. To retrieve information of embedded Web pages, we port the chrome debugging tools, specifically to expose debug APIs. The debugging port on the mobile device is forwarded to a local port from which we obtain information about resources downloaded, timing information, and information about HTTP request/response.

3.2 Measuring Metrics

In order to compare the performance of mobile apps with and without embedded Web pages, DroidMeter measures the page load time of both embedded Web pages and native apps. The page collector ports the chrome debugging tools that provides information about the page load time.

DroidMeter uses the APIs in the network domain of Chrome remote debugging protocol [4]. Network domain provides APIs to track network activities of the Web page. It exposes information about http, file, data and other requests and responses, their headers, bodies, timing, etc. We organize the retrieved information based on the HAR (HTTP ARchive) specification [3] for analysis.

To measure the equivalent of the page load time of mobile apps, we need to measure the time that elapses between the beginning of the activity and the time when the callback method onCreate() finishes executing. We use the Xposed Framework to inject some code before and after the onCreate() method to perform this measurement. To get the timestamp of when the application activity launches, we use the method reportFullyDrawn(). This method is designed for debugging and optimizing purpose and does not affect the behavior of the activity. But in each activity, this method can be called only once. Repeated calls to this method will lead to all the calls except the first one being ignored. We inject this method call into activities just before the activity’s onCreate() method is called, alongside with codes which will print the current timestamp into logcat. With these two timing data, we can calculate the timestamp of the very beginning of an activity, then we can know the activity’s timing information.

To measure the SpeedIndex [5] of loadings of both embedded web pages and native app pages, DroidMeter just records the screen and calculates the SpeedIndex from the recorded video. DroidMeter uses the shell command screenrecord to record the screen, and uses the utility visualmetrics [7] to calculate the SpeedIndex value.

The flexible architecture of DroidMeter makes it easy for users to extend it to support new measurement or new metrics.

4 Case Study

In this section, we study a real-life execution of DroidMeter over an Android App, to illustrate the usage and bahavior of DroidMeter.

4.1 Searching for Embedded Web Pages

We use the app All Football as the app being studied. First, we set up the running environment of DroidMeter. Before experiment we should connect a mobile phone and a computer by a USB wire and install the target app in the mobile phone. To configure the testing target for DroidMeter, we specify the mobile device and mobile app in a configuration file. We leave some other trivial options as their default values. After we have well prepared the input for DroidMeter, we execute DroidMeter in one shell command.

When DroidMeter starts, it reads the configuration file to get the basic information. Then, DroidMeter controls the mobile device to start the app to be tested. Once the app is started, DroidMeter browses the app and checks the layout of the on-screen activity. If DroidMeter finds a WebView widget in the layout of current activity, it records some basic information of the WebView and the activity, and generate a replay script which directly leads to this activity. When DroidMeter meets the same activity twice, it will recognize the identity of the activity and avoid conducting redundant tests. When the maximum exploration time reached, DroidMeter stops the exploration, saves the exploration result into a specified folder and exits. After it exits, user can manually check the output folder and analyze the exploration results. These results are also needed when DroidMeter replays operations and collects metrics.

Figure 5 shows the command line output of DroidMeter when it is exploring the app All Football. When started, DroidMeter reads the configuration file, obtains the entry activity of the app All Football, then it browses the app and records the activities that it meets. Meanwhile, DroidMeter listens to a specific TCP port, so a user can send command to DroidMeter. A user can let DroidMeter save the result by sending a “save” command, and stop DroidMeter by pressing the “Ctrl-C” key.

4.2 Replaying and Measurement

After DroidMeter explores an app and saves the replay scripts, DroidMeter can replay the operation and navigate to some specific activity in the app again according to the replay scripts. After a user triggers DroidMeter and orders it to replay, DroidMeter reads the replay scripts, constructs an “operation sequence” which leads to an activity that contains a WebView. Then DroidMeter perform the operation sequence to reach the target activity, or the target WebView. During the replaying, DroidMeter checks whether the app state is correct. If the app state is inconsistent with the recorded state, DroidMeter rewinds the last operation and retries it. Finally, DroidMeter will reach the target activity, or DroidMeter will report that the target activity is unreachable.

DroidMeter measures the user-specified metrics while DroidMeter replays the operations. During replaying, before each operation, DroidMeter prepares to measure; after each operation, DroidMeter start to measure; then after a while DroidMeter save the metrics into a folder.

Figure 5 shows the command line output of DroidMeter when it is replaying script which leads to the recorded WebView in the app All Football. DroidMeter replays the operation saved in the scripts and prints some information in command line.

Figure 6 shows the output of DroidMeter. Currently, for each activity, DroidMeter records the screenshot of the activity and some other basic information. User can easily extend DroidMeter to support other metrics.

5 Related Work

In this section, we survey the related research efforts on characterizing Web browsing performance and studying Android WebView.

5.1 Web Browsing Measurement Studies

Understanding the characteristic and performance of Web browsing is essential for providing better user experience. For desktop browsing, there has been considerable effort on studying Web traffic [15, 11] over the Internet and the characterizing Web page resources [14]. Wang et al. [27] designed WProf to analyze the dependency of the activities in a page load and identify the critical path.

In terms of mobile browsers, measurement studies focus especially on resource utilization [24], caching mechanism [23, 20], and energy consumption [26, 13]. Nejati et al. [21] designed WProf-M to analyze the key bottlenecks in mobile browsers.

There are a lot of performance metrics which reflect page loading performance in many aspects. Bocchi et al. [12] summarize many useful metrics reveal the relationships among them. Netravali et al. [22] propose a new metric called Ready Index, which captures the load time of a Web page with respect to its interactivity.

5.2 Web Browsing Optimization Studies

There are many works concentrating on improving the performance of Web Browsing.

Liu et al. [16] propose a method that leverages resource-packaging to reduce the redundant transfers in mobile Web browsing. They  [18] also optimize the resource loading procedure in mobile Web browsing. Ma et al. [20] measures and analyzes the performance of Web cache in mobile browsing. Surprisingly, they find that the utilization of Web cache in Web browsing is fairly low. Further, Liu et al. [17] study the reason of the bad performance of Web cache.

6 Conclusion

The goal of this work is to characterize the performance and resource usage of embedded Web pages. Embedded Web pages are pages that are embedded within mobile apps. Although the security of embedded Web pages are well-studied, little is known about their performance characteristics. We have built tools to study the characteristics of embedded Web pages at scale.