Offloadable Apps using SmartDiet: Towards an analysis toolkit for mobile application developers

Offloading work to cloud is one of the proposed solutions for increasing the battery life of mobile devices. Most prior research has focused on computation-intensive applications, even though such applications are not the most popular ones. In this paper, we first study the feasibility of method-level offloading in network-intensive applications, using an open source Twitter client as an example. Our key observation is that implementing offloading transparently to the developer is difficult: various constraints heavily limit the offloading possibilities, and estimation of the potential benefit is challenging. We then propose a toolkit, SmartDiet, to assist mobile application developers in creating code which is suitable for energy-efficient offloading. SmartDiet provides fine-grained offloading constraint identification and energy usage analysis for Android applications. In addition to outlining the overall functionality of the toolkit, we study some of its key mechanisms and identify the remaining challenges.

💡 Research Summary

The paper investigates the feasibility of method‑level offloading for network‑intensive mobile applications and introduces a developer‑oriented toolkit called SmartDiet that assists in creating energy‑efficient offloadable code. While most prior work on mobile offloading has targeted computation‑heavy workloads, the authors argue that popular apps such as Twitter and Facebook are dominated by communication costs, and that offloading communication‑related processing can yield significant battery savings if the right parts of the code are moved to the cloud.

To explore this hypothesis, the authors selected AndTweet, an open‑source Android Twitter client, and attempted to offload its network‑related methods using the ThinkAir framework. ThinkAir allows developers to mark individual methods as offloadable; at runtime the client serializes the method’s arguments, sends them to a remote server, executes the method there, and returns the result. The authors manually identified candidate methods, disabled ThinkAir’s dynamic decision engine, and performed a series of experiments under two network conditions: Wi‑Fi (low latency) and 3G (high latency).

During the offloading process several categories of obstacles emerged. First, any method that interacts directly with the UI or other hardware resources cannot be executed remotely because those resources exist only on the device. AndTweet mixes UI handling with network logic, forcing the developers to separate the two or to avoid offloading those paths. Second, many methods depend on objects that are not Java‑serializable, such as HttpClient and Android’s SharedPreferences. The authors worked around the HttpClient issue by instantiating a fresh client on the server, but SharedPreferences required a custom synchronization protocol to keep authentication tokens consistent between device and server. Third, complex dependency chains make it difficult to offload a single method in isolation; if a method calls another method that is not offloadable, the whole call chain must be moved or refactored. The more dependencies a method has, the higher the likelihood that some hidden constraint blocks offloading.

Energy measurements were performed with a Monsoon Power Monitor to capture total device power, while packet traces were collected and fed into established power models for Wi‑Fi (