Tingxin Yan, David Chu, Deepak Ganesan, Aman Kansal, Jie Liu
As mobile apps become more closely integrated into our everyday lives, mobile app interactions ought to be rapid and responsive. Unfortunately, even the basic primitive of launching a mobile app is sorrowfully sluggish: 20 seconds of delay is not uncommon even for very popular apps.
We have designed and built FALCON to remedy slow app launch. FALCON uses contexts such as user location and temporal access patterns to predict app launches before they occur. FALCON then provides systems support for effective app-specific prelaunching, which can dramatically reduce perceived delay.
FALCON uses novel features derived through extensive data analysis, and a novel cost-benefit learning algorithm that has strong predictive performance and low runtime overhead. Trace-based analysis shows that an average user saves around 6 seconds per app startup time with daily energy cost of no more than 2% battery life, and on average gets content that is only 3 minutes old at launch without needing to wait for content to update. FALCON is implemented as an OS modification to the Windows Phone OS.
Public Review uploaded by lzhong:
This public review was prepared by Lin Zhong
Context-aware services and recommender systems have been studied for over a decade. The key contribution by this paper is to solve a new and timely problem well using context: reduce the launch time of mobile applications. The presented system, FALCON, predicts what applications a user is likely to use based on context information such as time, location and usage history and then launches a selected set of them right before the possible use. It does so using novel insight gained from analyzing long-term smartphone usage traces collected from the field. The solution was evaluated using both trace-based simulation and measurement of a realization on Windows Phone. The work represents a beautiful combination of three technologies: machine learning, user study, and system building.
The paper does fall short in a few areas. Notable unaddressed issues
include the energy overhead of context acquisition, i.e., GPS and other location methods. The reported evaluation regarding energy consumption only includes pre-launching itself, not the cost of acquiring context. The related work section could have been stronger had the authors discussed some representative work in context-aware computing. The discussion of a recent related work about prefetching web pages could have been more informative had the authors been explicit about the unique technical challenges FALCON addresses and what new technologies this work provides.
As long-term usage and context data from mobile users are becoming available like that used in this work, there is likely to be a growing interest from the research community for building context-driven services as well as systems that support context-awareness. This work's strong system emphasis and solid evaluation will help set the bar high for such future work.
We thank Lin, the reviewers and our shepherd Alex for their time and effort in improving the quality of our work. As mobile devices connect to an increasing array of context and sensors, more open opportunities will arise for the mobile operating system to foster better and faster system interactions. FALCON is a concrete step in this direction, specifically targeted at the primitive of app launching. Below, we offer commentary on two points raised by Lin.
It is sensible that a holistic cost-based prelaunch planner consider significant context acquisition costs. Of the context sources presently used by FALCON, most costs are negligible: retrieving app usage records from system logs and calculating temporal burst features are in-memory operations. FALCON's acquisition of location features can be just as lightweight for coarse geolocation such as Cell ID. While our evaluation used GPS traces, our intuition from empirical observation suggests that coarse geolocation is likely to be sufficient for prelaunch decision making. Moreover, mobile operating systems such as WP provide geolocation caches that amortize the cost of geolocation queries across applications and services. As more apps use location, FALCON's location acquisition cost will effectively dwindle.
The data reveal several notable traits that distinguish mobile app usage from mobile browsing behavior. For example, apps tend to exhibit clear trigger app -> follower app(s) usage patterns. Also, apps, particularly in the entertainment category, show temporal bursts of popularity on the timescale of days to months. On the other hand, prior work has found mobile browsing behavior to exhibit patterns such as repeated vs. spontaneous page access that has no corollary in mobile app usage. These data differences in turn yield different machine learning features, described in depth in each work.
In addition to the nature of the data, prior work on mobile browser prefetching and FALCON differ in their approach to modeling energy costs. FALCON incorporates energy cost-of-launch directly into its cost-benefit prelaunch decision making, yielding optimal latency reduction for a given energy budget and app workload distribution. In contrast, the mobile browsing prefetch scheme proposed in prior work uses a daily energy threshold and therefore is susceptible to exhausting its energy budget on webpages with middling expected latency benefit vs. energy cost.
An interesting open question from this work is how users will react to faster app launches. One might speculate that faster launch times may in fact increase app usage and engagement by lowering the inhibition to launch formerly-sluggish apps. Alternatively, prelaunch with high hit rate may simply decrease the overall time spent to complete tasks, possibly saving energy since the device can go into standby mode more quickly. These conjectures appear to be promising avenues for future exploration.
Lastly, we invite you to see a demo of FALCON in action: http://research.microsoft.com/apps/video/default.aspx?id=162795.