Android优化进程不被杀死

1. 概述

记得前几年在公司做购物商城,有一个倒计时的功能,上头非得要实现这个功能,当时的想法就是引咎辞职,因为APP应用一退出后台启动的Service根本不管用直接被杀掉了,前几年的事今天我们就来拯救拯救。

声明:

1.文章综合了很多其他的一些资料,所以非常感谢某些哥们的分享精神;

2.不能够保证所有的机型都适用,因为我们要面对的是各大Rom厂商;

3.不想带坏大家,我们应该把更多的时间放在内存管理和性能优化上面。

效果演示.gif

所有分享大纲:2017Android进阶之路与你同行

视频讲解地址:http://pan.baidu.com/s/1pLrvFj9

2. 论Service为什么会被杀死

Service被强一般通常是三个方面,第一种现象是当手机内存不足,你的应用或者Service在后台这个时候你精力或者营养更不上可能就被强了;第二种现象是用了第三方的一些管理软件比如流氓360,腾讯管家去清理进程他们也会对你下手;第三种现象就是各大Rom厂商,在你退出应用的时候会做一些清理工作。

2.1 进程的优先级:

google的官网给进程划分了等级,并且明确告诉你哥们我不会乱来,回收进程的时候有自己套路。担心有些哥们不想翻墙这里我就Copy一下。

Android 系统将尽量长时间地保持应用进程,但为了新建进程或运行更重要的进程,最终需要移除旧进程来回收内存。 为了确定保留或终止哪些进程,系统会根据进程中正在运行的组件以及这些组件的状态,将每个进程放入“重要性层次结构”中。 必要时,系统会首先消除重要性最低的进程,然后是重要性略逊的进程,依此类推,以回收系统资源。

重要性层次结构一共有 5 级。以下列表按照重要程度列出了各类进程(第一个进程最重要,将是最后一个被终止的进程):

1.前台进程

用户当前操作所必需的进程。如果一个进程满足以下任一条件,即视为前台进程:

托管用户正在交互的Activity已调用Activity的onResume()方法

托管某个Service,后者绑定到用户正在交互的 Activity

托管正在“前台”运行的Service服务已调用startForeground()

托管正执行一个生命周期回调的Service (onCreate() 、onStart()或onDestroy())

托管正执行其onReceive()方法的BroadcastReceiver

通常,在任意给定时间前台进程都为数不多。只有在内存不足以支持它们同时继续运行这一万不得已的情况下,系统才会终止它们。 此时,设备往往已达到内存分页状态,因此需要终止一些前台进程来确保用户界面正常响应。

2.可见进程

没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。 如果一个进程满足以下任一条件,即视为可见进程:

托管不在前台、但仍对用户可见的Activity已调用其onPause()方法。例如,如果前台 Activity 启动了一个对话框,允许在其后显示上一 Activity,则有可能会发生这种情况。

托管绑定到可见(或前台)Activity 的Service。

可见进程被视为是极其重要的进程,除非为了维持所有前台进程同时运行而必须终止,否则系统不会终止这些进程。

3.服务进程

正在运行已使用startService()方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联,但是它们通常在执行一些用户关心的操作(例如,在后台播放音乐或从网络下载数据)。因此,除非内存不足以维持所有前台进程和可见进程同时运行,否则系统会让服务进程保持运行状态。

4.后台进程

包含目前对用户不可见的 Activity 的进程已调用 Activity 的onStop()方法。这些进程对用户体验没有直接影响,系统可能随时终止它们,以回收内存供前台进程、可见进程或服务进程使用。 通常会有很多后台进程在运行,因此它们会保存在 LRU (最近最少使用)列表中,以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法,并保存了其当前状态,则终止其进程不会对用户体验产生明显影响,因为当用户导航回该 Activity 时,Activity 会恢复其所有可见状态。 有关保存和恢复状态的信息,请参阅Activity文档。

5.空进程

不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存,以缩短下次在其中运行组件所需的启动时间。 为使总体系统资源在进程缓存和底层内核缓存之间保持平衡,系统往往会终止这些进程。

根据进程中当前活动组件的重要程度,Android 会将进程评定为它可能达到的最高级别。例如,如果某进程托管着服务和可见 Activity,则会将此进程评定为可见进程,而不是服务进程。

此外,一个进程的级别可能会因其他进程对它的依赖而有所提高,即服务于另一进程的进程其级别永远不会低于其所服务的进程。 例如,如果进程 A 中的内容提供程序为进程 B 中的客户端提供服务,或者如果进程 A 中的服务绑定到进程 B 中的组件,则进程 A 始终被视为至少与进程 B 同样重要。

由于运行服务的进程其级别高于托管后台 Activity 的进程,因此启动长时间运行操作的 Activity 最好为该操作启动服务,而不是简单地创建工作线程,当操作有可能比 Activity 更加持久时尤要如此。例如,正在将图片上传到网站的 Activity 应该启动服务来执行上传,这样一来,即使用户退出 Activity,仍可在后台继续执行上传操作。使用服务可以保证,无论 Activity 发生什么情况,该操作至少具备“服务进程”优先级。 同理,广播接收器也应使用服务,而不是简单地将耗时冗长的操作放入线程中。

以上是google官网的进程的优先级划分,就是说越是前面越不容易被杀,越是后面越不容易被杀,那么5是最容易被杀的,下面我们来看一看杀进程回收内存的机制Low Memory Killer 到底是怎么对我们下手的:

2.2 LowmemoryKiller的工作机制:

LowmemoryKiller会在内存不足的时候扫描所有的用户进程,找到不是太重要的进程杀死,至于LowmemoryKiller杀进程够不够狠,要看当前的内存使用情况,内存越少,下手越狠。在内核中,lowmemorykiller.c定义了几种内存回收等级如下:

static short lowmem_adj[6] = {0,1,6,12,};static int lowmem_adj_size =4;static int lowmem_minfree[6] = {3*512,2*1024,4*1024,16*1024,  };static int lowmem_minfree_size =4;

lowmem_adj中各项数值代表阈值的警戒级数,lowmem_minfree代表对应级数的剩余内存,两者一一对应,比如当系统的可用内存小于6MB时,警戒级数为0;当系统可用内存小于8M而大于6M时,警戒级数为1;当可用内存小于64M大于16MB时,警戒级数为12。LowmemoryKiller就是根据当前系统的可用内存多少来获取当前的警戒级数,如果进程的oom_adj大于警戒级数并且占内存最大,将会被优先杀死。omm_adj越小,代表进程越重要。一些前台的进程,oom_adj会比较小,而后台的服务,omm_adj会比较大,所以当内存不足的时候,Lowmemorykiller先杀掉的是后台服务而不是前台的进程。对于LowmemoryKiller的杀死,这里有一句话很重要,就是:具有相同omm_adj的进程,则杀死占用内存较多的,因此,如果我们的APP进入后台,就尽量释放不必要的资源,以降低自己被杀的风险。简单看一下实现源码:

static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask){    ...            int other_free = global_page_state(NR_FREE_PAGES);    int other_file = global_page_state(NR_FILE_PAGES);    for(i =0; i < array_size; i++) {if(other_free < lowmem_minfree[i] &&            other_file < lowmem_minfree[i]) {            min_adj = lowmem_adj[i];            break;        }    }  oomkilladj>min_adj并且oomkilladj最大,内存最大的进程-->for_each_process(p) {// 找到第一个大于等于min_adj的,也就是优先级比阈值低的if(p->oomkilladj< min_adj || !p->mm)            continue;// 找到tasksize这个是什么呢tasksize= get_mm_rss(p->mm);if(tasksize <=0)            continue;if(selected) {// 找到优先级最低,并且内存占用大的if(p->oomkilladj< selected->oomkilladj)                continue;if(p->oomkilladj== selected->oomkilladj &&                tasksize <= selected_tasksize)                continue;        }        selected = p;        selected_tasksize = tasksize;        lowmem_print(2,"select %d (%s), adj %d, size %d, to kill\n",p->pid, p->comm, p->oomkilladj, tasksize);    }if(selected != NULL) {...        force_sig(SIGKILL, selected);    }    returnrem;}

那么现在我们就可以针对性的做一些工作了比如:

1.提高进程的优先级,其实就是减小进程的p->oomkilladj(越小越重要),如启动Service调用startForeground()尽量提高进程的优先级;

2.当应用推到后台适当释放资源然后降低APP的内存占用量,因为在oom_adj相同的时候,会优先干掉内存消耗大的进程;

3.对于要一直在后台运行的Service我们一定要轻,不能太风骚。

3. 针对各大Rom厂商和清理软件:

我其实要面对的不是google原生的系统,在各大手机厂商以及各种流氓清理软件面前我们按套路出牌往往然并卵,我们要面对的也是他们,这也是说往往写的代码你会发现这里行那里不行,真是心中有一万只动物。会发现采用上面的方式根本没用,网上也有很多的解决方案,如QQ的1像素的Activity,某些第三方应用救救你,NDK方式hook子线程等等等等。我们这里决定采用双进程守护相互唤醒以及5.0以上的JobSheduler:

publicclassMessageServiceextendsService{privatestaticfinalString TAG ="MessageService";privateMessageServiceConnection mServiceConnection;privateMessageBind mMessageBind;@OverridepublicvoidonCreate(){super.onCreate();newThread(newRunnable() {@Overridepublicvoidrun(){while(true) {                    Log.e(TAG,"等待接收消息");try{                        Thread.sleep(1000);                    }catch(InterruptedException e) {                        e.printStackTrace();                    }                }            }        }).start();if(mServiceConnection ==null) {            mServiceConnection =newMessageServiceConnection();        }if(mMessageBind ==null) {            mMessageBind =newMessageBind();        }    }@OverridepublicintonStartCommand(Intent intent,intflags,intstartId){        MessageService.this.bindService(newIntent(MessageService.this, GuardService.class),                mServiceConnection, Context.BIND_IMPORTANT);returnService.START_STICKY;    }@Nullable@OverridepublicIBinderonBind(Intent intent){returnmMessageBind;    }privateclassMessageBindextendsProcessConnection.Stub{@OverridepublicvoidprocessConnected()throwsRemoteException{        }    }privateclassMessageServiceConnectionimplementsServiceConnection{@OverridepublicvoidonServiceConnected(ComponentName name, IBinder service){// 建立连接Toast.makeText(MessageService.this,"建立连接", Toast.LENGTH_LONG).show();        }@OverridepublicvoidonServiceDisconnected(ComponentName name){// 断开连接Toast.makeText(MessageService.this,"断开连接", Toast.LENGTH_LONG).show();            Intent guardIntent =newIntent(MessageService.this, GuardService.class);// 发现断开我就从新启动和绑定startService(guardIntent);            MessageService.this.bindService(guardIntent,                    mServiceConnection, Context.BIND_IMPORTANT);        }    }}

双进程守护和唤醒在5.0以下还是很爽的,至少能保证各种流氓的清理软件不能够清理掉我们的Service,但是在5.0以后就不管用了,尤其实在小米、魅族这些手机上面。不过柳暗花明又一村,我们可以利用JobSheduler。

/**

* Created by Darren on 2017/3/25.

* Email: 240336124@qq.com

* Description:

*/@TargetApi(Build.VERSION_CODES.LOLLIPOP)publicclassJobAwakenServiceextendsJobService{@OverridepublicintonStartCommand(Intent intent,intflags,intstartId){        JobInfo.Builder builder =newJobInfo.Builder(1,newComponentName(this,JobAwakenService.class));        builder.setPeriodic(500);        JobInfo jobInfo = builder.build();        JobScheduler jobScheduler = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE);        jobScheduler.schedule(jobInfo);returnSTART_STICKY;    }@OverridepublicbooleanonStartJob(JobParameters params){        Log.e("TAG","onStartJob");// boolean isGuardAlive = isServiceWork(this,GuardService.class.getName());booleanisMessageAlive = isServiceWork(this,MessageService.class.getName());if(!isMessageAlive){// startService(new Intent(this,GuardService.class));startService(newIntent(this,MessageService.class));        }returnfalse;    }@OverridepublicbooleanonStopJob(JobParameters params){returnfalse;    }/**    * 判断某个服务是否正在运行的方法    *    *@parammContext    *@paramserviceName    *            是包名+服务的类名(例如:net.loonggg.testbackstage.TestService)    *@returntrue代表正在运行,false代表服务没有正在运行    */publicbooleanisServiceWork(Context mContext, String serviceName){booleanisWork =false;        ActivityManager myAM = (ActivityManager) mContext                .getSystemService(Context.ACTIVITY_SERVICE);        List myList = myAM.getRunningServices(100);if(myList.size() <=0) {returnfalse;        }for(inti =0; i < myList.size(); i++) {            String mName = myList.get(i).service.getClassName().toString();if(mName.equals(serviceName)) {                isWork =true;break;            }        }returnisWork;    }}

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,565评论 6 479
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,021评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,003评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,015评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,020评论 5 370
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,856评论 1 283
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,178评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,824评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,264评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,788评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,913评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,535评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,130评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,102评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,334评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,298评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,622评论 2 343

推荐阅读更多精彩内容