Currently, the number of functions to improve user convenience in smartphone applications is increasing. In addition, more mobile applications are being loaded into mobile operating system memory for faster launches, thus increasing the memory requirements for smartphones. The memory used by applications in mobile operating systems is managed using software; allocated memory is freed up by either considering the usage state of the application or terminating the least recently used (LRU) application. As LRU-based memory management schemes do not consider the application launch frequency in a low memory situation, currently used mobile operating systems can lead to the termination of a frequently executed application, thereby increasing its relaunch time. This study proposes a memory management system that can efficiently utilize the main memory space by analyzing the application usage information. The proposed system reduces the application launch time by leaving the most frequently used or likely to be run applications in the main memory for as long as possible. The performance evaluation conducted utilizing actual smartphone usage records showed that the proposed memory management system increases the number of times the applications resume from the main memory compared with the conventional memory management system, and that the average application execution time is reduced by approximately 17%.
Various types of mobile applications are emerging with the development and widespread use of smartphones. Currently, the number of mobile applications registered in the application marketplace for mobile operating systems such as Android and iOS is approximately 2 million [
Mobile operating systems, such as Android or iOS, implement application life cycle management [
In this paper, we propose a memory management system to efficiently utilize the main memory and swap space by analyzing the application usage patterns and application execution probabilities of the user. The proposed system reduces the execution time of applications by keeping in the main memory the applications that are frequently used or that present a high probability of being relaunched. In low-memory situations, the main memory space allocated to applications is reclaimed by terminating the least likely to be reused application. Consequently, frequently used applications remain in the memory.
The remainder of this article is organized as follows. In Section 2, we summarize the existing studies on memory management for mobile operating systems. In Section 3, we introduce the proposed memory management system for efficiently managing the main memory of mobile operating systems. In Section 4, we evaluate and analyze the application launch performance of the proposed and existing memory management systems. Finally, in Section 5, we present conclusions and future research directions.
Unlike PC and HPC-based operating systems, mobile operating systems deployed in smartphones follow memory management policies that are suitable for mobile environments. Mobile applications can be cached in the main memory to reduce their launch time without the need for a high-performance processor or storage. The number of applications cached in the main memory can be increased with the use of compressed memory. Currently, users typically install dozens, and sometimes, even hundreds of applications on their smartphones [
Android is an operating system that holds approximately 70% of the mobile operating system market share [
Android can host applications written in Java and Kotlin in separate processes on the Android runtime virtual machine. It implements an application life cycle management policy [
The commonly used LRU-based memory management policies assume that recently used applications are likely to be launched again [
Other software approaches for memory management feature swap techniques utilize a part of the main memory as compressed storage space. The swap techniques use a part of the free space from the secondary storage as swap area. This allows for the use of memory resources beyond the physical memory limit of the system. When the main memory space is not sufficient to allocate a page, the memory manager migrates a page in the main memory to the swap area. The swapped-out page is brought back to the main memory when a process refers the page again. Another page is then selected to be swapped out. The swap-in and out task is frequently performed if the main memory keeps running low. Therefore, NAND flash memory based mobile devices do not present a swap feature that employs secondary storage to prevent storage wear-outs. Main memory-based swap techniques, such as ZRAM or ZSWAP, are utilized to compress and store swap data using a part of the main memory space as a block device. However, these swap techniques present compression and decompression overhead; the overhead increases with the amount of swap out/in data to/from the compressed area.
In a study using ZRAM and storage as the swap area [
In this study, we present an approach for estimating the application launch probability by collecting users’ application usage information and training a long short-term memory (LSTM) [
In this paper, we propose
The
The LSTM network is located within the
The parameters used by the LSTM network for performing application launch probability prediction are defined in
The
Symbol | Definition |
---|---|
Time at which an input vector is fed to an LSTM | |
Input vector to an LSTM at time |
|
Output vector of LSTM at time |
|
Sigmoid activation function | |
Tangent hyperbolic activation function | |
Forget gate function at time |
|
Memory cell to store data in LSTM at time |
|
Input gate function at time |
|
Input gate function at time |
|
Output gate function at time |
|
Vector weighted to |
|
Vector weighted to |
|
Bias constant for functions |
Symbol | Definition |
---|---|
Set of all applications installed on a smartphone | |
Set of all applications that a user cannot launch | |
Set of applications for which |
|
Set of cached applications that reside in system memory at time |
|
Number of elements of |
|
Launched application |
|
Set of application launch history at time |
|
Fully connected LSTM network function | |
Probability of an event |
The
Name | ID |
---|---|
Field | Description |
---|---|
Full package name of the application | |
Unique id of the application | |
Probability that the application is launched | |
List of pids of processes that belong to the application |
The
Algorithm 1 describes the task performed at time
Algorithm 2 describes the task performed when the created application process information is received. When a process is created, the corresponding
The
The training of the LSTM network by the
The
Process probability is a data structure for recording the launch probability of an application’s process. The
Field | Description |
---|---|
Unique id of the application | |
Integer probability value set by application usage predictor | |
We designed an LSTM model for AMMS by changing its hyperparameters to identify the most efficient structure for predicting mobile application usage. To establish an efficient structure of the LSTM model, the number of computations as well as the prediction performance of the model should be considered. The model validation accuracy was determined by changing the number of layers of the LSTM network from 2 to 4 and the number of LSTM neurons per layer from 10 to 100. The number of application usage records varied from 100 to 10000 in this experiment that helped determine the robustness of the model prediction accuracy. The application usage records were randomly selected from LiveLab Research’s real-world usage data [
The model validation accuracy and training loss for each number of layers and neurons is shown in
To consider a model for the mobile environment, it is necessary to identify the most computationally efficient model. We employ a method used in [
Unlike the previous work, the number of application types in the usage dataset, represented by
Based on the experimental results presented in
Algorithm 4 depicts the proposed method to evaluate an LSTM model considering its performance and computational efficiency simultaneously. To evaluate a model with
We implemented
Model | Google Nexus 6P | |
---|---|---|
Processor | Qualcomm Snapdragon 810 MSM8994 SoC ARMCortex-A57 2 |
|
Memory | 3 GB LPDDR4 SDRAM | |
Display | WQHD ( |
|
Storage | 32 GB flash storage | |
OS | Android 7.1.2 (Nougat) with Linux Kernel 3.10.73 |
There are three types of application launches: cold launch, warm launch, and hot launch [
Android logs the time interval from application launch to application screen rendering, i.e., it provides cold and warm launch information. The time is not logged for hot launches because the process is already created, and the application is already rendered. Therefore, we compared the proposed and existing methods in terms of the application launch time information provided by Android to measure the number of launch types. Algorithm 5 describes the manner in which application launch type is determined. Hot launch occurs when the Android framework does not provide the launch time of an application, as shown in lines 3–5. If the framework provides the launch time but no data is left in the main memory, cold launch occurs, as shown in lines 6–7. Otherwise, warm launch occurs. The existing memory management system is labeled
Original package name | Tested package name | Original package name | Tested package name | |
---|---|---|---|---|
com.apple.Preferences | com.android.settings | com.apple.MobileSMS | com.android.messaging | |
com.apple.mobilephone | com.android.dialer | com.apple.compass | com.vincentlee.compass | |
com.apple.weather | com.weather.Weather | com.apple.mobilemail | com.google.android.gm | |
com.apple.mobilesafari | com.android.chrome | com.apple.mobileipod-MediaPlayer | com.mxtech.videoplayer.ad | |
com.apple.calculator | com.android.calculator2 | com.apple.mobiletimer | com.android.deskclock | |
com.apple.VoiceMemos | com.splendapps.vox | com.apple.stocks | com.yahoo.mobile.client. android.finance | |
com.apple.mobileslideshow-Photos | com.android.gallery3d | com.apple.mobileslideshow-Camera | com.android.camera2 | |
com.apple.youtube | com.google.android. youtube | com.apple.AppStore | com.android.vending | |
com.apple.MobileStore | com.google.android.music | com.apple.MobileAddress-Book | com.android.contacts | |
com.apple.mobilenotes | com.socialnmobile. dictapps. notepad.color.note | com.apple.mobilecal | com.google.android.calendar | |
com.apple.Maps | com.google.android.apps. maps | com.apptomic.bugspray | com.alphapps.antiflysound | |
com.gothamwave. SubwayMap | net.orizinal.subway | com.myapps.NYSubwayApp | uk.co.mxdata.newyorksub | |
com.google.GoogleMobile | com.google.android. googlequicksearchbox | com.google.b612 | com.linecorp.b612.android | |
com.davaconsulting.ruler | org.nixgame.ruler | com.ihandysoft.carpenter. level | com.ihandysoft.carpenter.level | |
com.johnhaney.Flashlight | com.surpax.ledflashlight. panel | com.oishan.DriversEd | com.driversed.driversed | |
com.srividya.nycway | com.ulmon.android.play-newyork | com.pandora | tunein.player | |
com.rhapsody.iphone. Rhapsody | com.nhn.android.music | com.trancreative.Speller | com.nounplus.grammar checkerenglish | |
com.Epocrates.Rx | com.Epocrates.Rx | com.espn.ScoreCenter | com.espn.score_center |
In order to evaluate application launch performance, the validation dataset of 500 application records was executed in order, and the number of hot, warm, and cold launch occurrences was measured for the existing and proposed systems.
Hot launch | Warm launch | Cold launch | |
---|---|---|---|
400.6 | 14.4 | 85.0 | |
410.8 | 12.8 | 76.4 |
Next, we measured application launch time, which is the time required to completely load an application, create processes and activities, and render the initial screen; we evaluated how this parameter is affected by the application prediction accuracy of the existing and proposed systems. Application launch time was measured using the measurement tool provided by the Android framework [
Hot launch | Warm launch | Cold launch | |
---|---|---|---|
7095.8 | 106128.6 | 113224.4 | |
6302.8 | 86810.0 | 93112.8 |
The results shown in
In summary, the proposed system reclaims the memory used by the applications with the lowest launch probability in a low-memory situation, thus increasing the launch speed of more frequently used applications. Consequently, the proposed system utilizes the main memory more efficiently than the existing system.
As smartphone users install and use performance-demanding applications, significant amount memory is needed. Techniques such as ZRAM swapping or swapping using storage were developed to accommodate main memory demands; however, these techniques present limitations such as compression and decompression overhead for ZRAM and NAND flash memory wear-out problems for memory swapping using storage, thereby rendering them relatively slower than the main memory. Moreover, the performance of the existing application memory management system using LRU decreases when the number of applications used increases.
In this paper, we proposed a memory management system—