The current algorithm of LMK kills on the basis of Least Recently Used (LRU) list [5][6]. This list is maintained in the order of which the application have been launched i.e. applications which are opened recently will remain in the list while the ones which were opened earlier will get replaced. Whenever any application is opened and used by the user, the LRU lists gets updated. The problem that may arise using the LRU list algorithm is that an application which the user uses very frequently might still get killed by LMK, if that application was not used recently. In such scenarios, when user re-opens its favorite application, the application takes more time to start as it is forking the process instead of resuming. This increased launch time is perceived as sluggishness to the user. In our proposed approach, we try to tackle such scenarios by making sure that at least user’s favorite applications are given less priority to get killed by LMK. n general scenario, user opens few applications frequently than others. Both of our proposed solutions decrease the probability of killing such important user applications by LMK in memory crunch scenarios. In our proposed solution, we have added more parameter checks to LMK algorithm to make sure killing of applications occur not only based on LRU list but also based on the importance of the application to the user. Given below are the two new approaches. we decrease the oom_adj value for certain important cached applications on the basis of their resume count. Resume Count is one parameter that has been added to check the number of times an application is opened by the user. Every time an application is opened, the corresponding resume count is increased for the application. If the application is opened for more than 15 times, we consider such application as an important user application. Hence we decrease the oom_adj value of such applications to the lowest cached application oom_adj value of 9, which in turn, lowers its priority over the other applications to get killed by LMK in memory crunch situationsIn order to avoid heavy applications falling in this category, we also keep a check for the memory proportionate set size (PSS) value [7]. Whenever the PSS value goes higher than 30 MB we don’t consider applying our algorithm to such applications. We have included this check in our algorithm in order to remove any possibility that may hamper our algorithm due to memory leak of any frequently used heavy application. As process record gets update many a times, these checks are put in the right location which doesn’t increase the overhead of calculation very much.https://codeshoppy.in/
Most users are expected to have some favorite applications which they keep on re-launching. For the solution proposed in Fig. 2, we target on improving the launch time of such 4 most frequently used applications. We keep these 4 most important applications to be always running in the background. A stack of frequently used applications is maintained which is created through learning the user’s usage. These four applications keeps getting updated according to the change in the usage of the user after every half an hour when phone is left in idle state for a little while. Mostly the update happens when the phone is kept in idle state to lower the overhead. These applications are then launched and kept at the background killing them only as a last resort. When the stack is updated, the application that gets removed from the stack becomes normal application running at the background just like others. Another advantage of DCA algorithm over DSPO algorithm is that since the boot complete it keeps basic 4 applications opened. As those basic applications are already opened, user can see a good amount of performance improvement in launch of those 4 applications after boot. .
To test our algorithms, we created the test environment in such a way that the devices undergoing the test will be in memory crunch state. We plan to take average readings of all the launch times as a measure for comparison [8]. Three Galaxy S5 phones, test devices, were put to the above mentioned testing environment. Device1 had the basic stock ROM (Android 5.0.2), Device2 had custom ROM with DSPO changes and Device3 had custom ROM with DCA changes.Firstly, the devices are flashed with the required binaries. Secondly, options such as stay awake, user debugging and allow mock locations are enabled. Thirdly, the device is loaded with 100 installed applications, 3000 contacts, 1000 messages and 7 GB of data which includes 3 GB of images, 2.5 GB of mp3 music and 1.5 GB of videos. Google, Facebook and Twitter profiles accounts are set up. After that, debug level is set to mid. In addition, as a precondition for the test, many applications are opened randomly so that enough RAM is consumed to make the device sluggish.Now few more applications are opened and their launch time is recorded. Some applications are opened more than others for the purpose of making them frequently used. Some applications apart from those whose launch time is recorded are opened to consume more RAM and make the device sluggish.
https://codeshoppy.com/shop/product/child-safety-app/
https://codeshoppy.com/shop/product/libarary-management-system/
https://codeshoppy.com/shop/product/leakage-detection-and-risk-assessment-on-privacy-for-android-applications-lrpandroid/
https://codeshoppy.com/shop/product/ediagnostic-lab-online-reporting-mobile-app/
https://codeshoppy.com/shop/product/anomaly-detection/
