Activity管理（二）：adj内存管理机制

2401_84123005

于 2024-04-21 21:41:09 发布

阅读量826

点赞数 21

分类专栏：程序员文章标签： linux 运维服务器

本文链接：https://blog.csdn.net/2401_84123005/article/details/138046442

版权

程序员专栏收录该内容

185 篇文章 0 订阅

订阅专栏

*三、未控制好oom_adj的案例*

*1.ui进程启动service的隐患*

*案例a：备份进程启动一个服务开始执行备份，备份服务运行在ui进程（服务未调用startForeground()）*

*隐患：备份服务一般需要较长时间，在用户按Home键退出后台后，备份进程会处于previous状态，继续使用手机其他应用，会是使得备份进程处于cch-started-ui-services的状态，即是启动了服务并且包含ui的进程退到后台状态，此时进程的adj值处于9～16，随着时间推移逐渐增大。如果在较长的备份过程中，触发了lowmemorykiller，很容易导致备份进程被杀掉，从而导致备份的失败。*

*案例b：****备份进程启动一个服务开始执行备份，备份服务运行在ui进程（服务调用了startForeground()）*****

****隐患：这种情况下备份进程会被划分为perceptible进程，基本上是不会被lowmemorykiller杀掉的，但是这也导致内存占用较大的备份常驻了，从内存管理角度来将，备份进程的UI部分是并不期望他常驻的，而大量内存的常驻也容易导致lowmemorykiller的出现，从而导致系统进入内存较低的等级，而当系统处于内存较低等级时，会触发系统回调所有进程进行进程回收动作，容易导致系统卡顿场景的出现。此外，********调用了startForeground()会导致进程被系统判定为前景进程，这样备份进程便会抢占用户操作手机时前台应用的cpu资源，增加了卡顿场景出现的几率。**************

*解决方法：将Service运行在独立的进程，这样应用退到后台后，备份服务进程会处于A-Service中（逐渐掉落到B-Service），而B-Service进程一般也是很难被lowmemorykiller砍。该独立********是否要startForeground()?如果期望保证备份尽快到完成，便可以牺牲一些用户在操作其他应用时到用户体验，将服务推为前景应用；对于很多需要保证功能的流畅运行的服务进程，例如音乐播放，录音等，则需要将这类服务进程通过********startForeground()设置为前景进程，但前提还是需要做到ui与Service分离。*********

*2.使用线程解决耗时操作造成anr问题的隐患*

*案例：短信、邮件、或笔记本应用，在用户按BACK键时存下草稿*

public class MyActivity extents Activity ｛ ` `public` `void` `onPause(){ //存储草稿 ` `}}

*问题(1):由于存储草稿定操作一般时保存到数据库，某些情况下可能会占用较长时间，这里就有可能导致anr的隐患*

*解决方案1:*

public class MyActivity extents Activity ｛ ` `public` `void` `onPause(){ new Thread() { ` `public` `void` `run() { //存储草稿 ` `} }.start() ` `}}

*问题(2):当用户以back键离开应用时（以home键离开会处于previous状态），应用退到后台处于empty-cached状态，内存不足时，可能会立刻杀。*

*解决方案2:如果线程有这问题，是否可以用服务来完成存储草稿的动作呢？*

*问题(3):如果用服务来存储草稿，即将存储草稿动作写在onStartCommand中，由于onStartCommmand操作依旧是执行在主线程的，所以在其中执行耗时操作时，依旧可能会导致ANR*

*最终解决方案：使用IntentService来执行保存草稿的动作*

public class MyActivity extents Activity ｛ ` `public` `void` `onPause(){ … ` `startService(` `new` `Intent(` `this` `, MyIntentService.` `class` `)); … ` `}} public class MyIntentService extends` `IntentService { protected void onHandleIntent(Intent intent) { ` `//保存草稿 }``}

*3.provider被binder导致的隐患*

*案例：systemui进程获取手机中的手机管家应用提供的content provider，用于获取当前应用相关信息*

*问题：管家应用的UID为System，在Android机制中，System UID进程提供的provider一旦被访问，即使访问完成关掉provider后，连接依旧存在，所有管家应用由于其provider持续被persistent进程咬住，所以管家应用便会长时间处于foreground级别的应用中，oom_adj为0，导致管家应用占用的大量内存很难被回收*

*解决方案：单独使用一个进程提供provider，提供provider进程由于占用内存较小，所以即使无法被回收也影响较小，这样管家应用的UI进程能够按照系统正常的回收流程在需要时被回收*

*四、总结一些经验*

*1.进程在启动服务后，在事情做完后，必须呼叫stopService或stopSelf通知框架，避免事情做完了，服务进程依旧常驻内存*

*2.对于需要长时间停留在后台的服务，且服务设置为具有重启特性时，需要做到ui与service分离，一避免占用内存较大的ui进程的常驻*

*3.对于需要长时间停留在后台的服务，且服务设置为具有重启特性时，不可长时间bind住其他进程的service或provider，避免其他进程常驻；*

*4.常驻性质的进程（oom_adj<=6），不可一直bind住其他进程的服务或provider，用完必须马上放掉*

*5.不可使用SystemUID进程内的provider，在Android设计中，若针对System UID的进程使用provider，即使已关掉provider，但框架仍会保持provider connection*

*6.利用onStartCommand方法回传值（START_STICKY，START_NOT_STICKY等）控制好服务的重启属性，在设计时充分考虑进程被lmk杀死的情况*

*7.IntentService继承自Service，针对CPU scheduling、工作排程等都有完整实现，建议多采用IntentnService进行功能实现*

[