如何让service不被杀死，针对主流机型和android版本-android100学习网
如何让service不被杀死，针对主流机型和android版本
论Service为什么会被杀死android对于进程的杀死是有优先级的： 1. 前台进程，也就是前台activity 2. 可见进程，就是一个透明的activity下面覆盖着的那个activi
论Service为什么会被杀死android对于进程的杀死是有优先级的： 1. 前台进程，也就是前台activity 2. 可见进程，就是一个透明的activity下面覆盖着的那个activity就属于可见的，但是这个透明的activity才属于前台 3. 服务进程，也就是service 4. 后台进程 5. 空进程 而且android系统在内存紧张的时候会回收那些内存占用较高的进程，而我们的app在实际场景中被杀的原因主要有一下几点： 1. 我们的APP进程启动后占用内存太大了，基本是打开APP就，然后到应用程序管理里面一看，有60到70MB 2. 有些android深度定制系统的杀死策略太严格，进程清理的太彻底，导致我们APP的service很容易被杀杀杀，基本是手机一锁屏，过几分钟之后立刻就被杀死了 3. 我们的Service重启做的不够好，在某些手机上按下home键后手机锁屏，过一会儿就死了，但是毕竟我们是有遇到那种在按下home键后，手机锁屏，后台服务常驻的APP，例如在魅族5.0系统上的UC就能做到，甚至于有些APP的service被杀死后还能重启，我实在不知道他们是怎么实现的，要不就是深入底层对service做重启，要不就是APP相互唤醒关于service被杀死的做法我一直是不建议这么做的，但是推送这种东西特殊，要求消息即时到达，所以service要尽量保持常驻后台最近一直在做公司的推送android端sdk，我们是把tcp连接写在了java层，然后开一个service来维护这个tcp长连接，那么问题来了，如何尽量让这个service常驻在后台？针对原声的android系统这是容易的，最常用的就是守护进程的做法了，有两种： 1. 一种是用c在底层fork一个进程出来定时扫描，采用am命令启动service； 2. 一种是fork一个进程出来，然后把fork出来的进程和app主进程建立一条本地长连接来监听两个进程之间的状态，一旦其中一个进程断掉之后另一个进程就能检测到tcp连接断掉了，然后采用am命令拉起service 3. 上述做法在android系统是5.0以下的手机运行良好，因为就算是手机一键清理的时候也只是清理app主进程，而不会清理fork出来的进程，所以service会被成功拉起；而在android5.0以上的手机中，一旦系统一键清理，或者系统后台自动清理，那么会杀死跟app进程有关的进程组，也包括fork出来的进程，所以android5.0以上的手机这个fork进程就貌似是一个鸡肋，增加了耗电，增加了内存消耗，甚至增加了service会被系统清理的概率而在应用层，通常降低service被杀死的概率有： 1. 在onDestroy方法里面重启service，或者发个广播出来触发启动service；onStartCommand中的flag设置成START_STICKY，或者直接return START_STICKY，关于这个在部分手机一键清理后service会被杀死，不会被杀死后又会被重启；配置文件里面加入android:persistent=”true”可让进程不被杀？说是这么说，该死的照样死，肯在原生android系统还有用，但是一些定制系统就没用了 2. 尽量让维护tcp长连接的service运行在自己独立的进程中，然后这个进程尽量做小，只负责维护数据转发，从而降低android系统的内存回收时杀死service进程的概率，android内存回收策略应该都是检测某个后台进程占用的内存超过了一个阀值就立马杀死回收，而当手机锁屏后，所有的app都是后台进程，因此都有可能被杀死 3. 使用心跳定期检测service，心跳是采用系统闹钟来实现的，隔一个指定周期会发一次心跳，那么可以把心跳的发送做到service里面，然后发心跳只要start service，这样既能发心跳也能启动service即使在手机休眠，心跳依然会定时发送 4. 将service设置成前台service，就像音乐播放器一样，可以设置一个空的通知，在有些手机上空的通知并不显示在通知栏，而在有些手机空的通知也会显示通知栏，目前我遇到的是android5.0以下会显示，5.0以上不会显示，但是这种做法是不好的，用户会说好端端的在通知栏一直看到一个通知很别扭 5. 采用bind service加上start service，因为bing service之后即时stop service那service也还是存在，不会调用onDestroy，只有等service被解绑之后才用调用onDestroy 6. 其实最根本的还是手机设置白名单，你们看微信QQ为什么能那么完美的收发消息，因为大多数手机厂商在手机系统里面已经把它们默认成白名单了，而普通的app只能用户自己去设置，设置了白名单之后就能保持app后台运行而不被杀死 7. 跨进程通信在我们的sdk里面是采用aidl和广播实现，但是aidl有时候会有问题，在service被杀死的时候会爆出DeadObjectException，就是表示service已经被杀死了，但是可能程序依然在执行aidl的方法 8. 了解了下市面上的友盟，事实上我测了下友盟的service守护在一些定制系统上也是基本无用，例如魅族的flyme，手机一键清理，不留下一片云彩。。。但是友盟采用了长连接多路复用，在一台设备上，就算有多款app集成友盟推送，但是他们是共享一条连接，只有一个宿主app，所有的数据推送都通过宿主app来路由，这么做确实很好，首先是省电省资源，第二就是app之间可以相互唤醒，像友盟推送这种有大量用户群体的app，这种方法简直碉堡了，UC，高德，支付宝，淘宝等都可以拉起，无语了吧？以为这些都是使用频率超高的app，随时可能点开，一点开就唤醒其他app，市面上的第三方推送服务现在大多使用长连接多路复用技术了 9. 监听广播：开机自启广播，网络变换广播，USB接入和拔出的广播，系统屏幕解锁广播，这几个广播都是静态注册的广播；但是这种方式也是不可靠的，因为有些手机在程序停止运行之后连静态广播都不能收到了。。。增加广播监听只是在一定程度上降低service被杀后重新拉起的概率 10. 接入第三方推送服务，但是我们不用他们的推送，我们还是用我们自己的推送，不过我们可以捕捉到他们的一些广播，service启动的action等来让它们来触发拉起我们的程序，比如说集成友盟推送，当启动uc的时候可能会发一些广播，通过action启动一些service，我们就专门监听这种广播，监听这些action就能成功的拉起我们的服务，这种办法是通过第三方推送来触发我们的推送服务，人家是专门做推送的，更专业，那我们就直接用呗，达到不使用他们的推送，但是们的app也加入了互相唤醒的app 的行列中去了针对不同定制系统的问题： 1. 小米MIUI和魅族flyme是两个比较深android定制系统，超级坑超级坑，系统清理策略太特么严格了，一清全死，怎么起都起不来，秒杀一切推送，针对这种机型我们只能说，可以的话默默的加入白名单吧，亲，要不你就去跟手机厂商谈合作，要不你就用他们家的推送，例如MiPush 2. 三星手机倒是还好，基本按照以上的做法在大部分5.0一下的系统都可以在很大程度上保持service常驻，因为三星的android系统是比较纯净的 3. 华为的手机系统也是定制的，不过也不知道为啥，我们的c守护进程在其他手机上跑得好好的，在华为手机上跑超级耗电，而且无法start service，因为这个c程序是网上大牛写的，不是我写的，我也找不到原因所在，甚至于在华为某些机型上面会导致超级耗电，要不就是导致手机超级卡顿，要重启才能使用，所以华为的定制机我们是把守护进城去掉了，所以我们的service变得非常脆弱 4. 市面上的主流手机就是小米，三星，华为，魅族，vivo，oppo了，但是当我们专门针对这些进行做适配的时候，版本正式发布了，你会发现反馈问题的用户往往都不是使用这些手机。。。都是使用什么联想，htc等等好坑的手机，有广播发送需要一两分钟才能收到 5. 根据手机渠道来分版本发布，小米版，魅族版等等经过测试采用上述方式后，只要不使用手机自身的一键清除，按下home键后service常驻情况后台的机型： 1. 小米4C——4.4Android系统——service可以常驻（但是守护进程无效，因为小米的一键清理太彻底） 2. 魅族MX5——5.0Android系统——service在手机锁屏后几分钟就被杀死并且无法重启（守护进程无效，魅族一键清理更彻底） 3. 华为荣耀6，6plus——5.0Android系统——service在手机锁屏后马上就被杀死并无法重启（守护进程无效，守护进程导致严重耗电，守护进程无法正常运行） 4. 华为很旧的机型—–4.4Android系统——service常驻后台，就算被杀死或者手机一键清理也会被守护进程拉起（守护进程有效，守护进程基本不会被杀死） 5. 华为meta7——4.4Android系统——service常驻后台（未知守护进程是否有效，待测） 6. 三星部分机型service可以常驻，但是部分机型service无法常驻并且守护进程无效，具体待测 7. vivo和oppo的手机上service基本无法常驻，死的一干二净明明白白，丝毫没有任何挣扎的痕迹 8. android5.0以上系统守护进程据说是无效，但是我没有亲测，因为5.0以下的android系统只是杀死App主进程，但是5.0以上的android系统是杀死跟App有关的所有进程组，所以game over。。。 9. 但是最最特么坑爹的是居然能看到确实有些app可以在各种各样的机型上保持service常驻。。。我也是醉了，虽然有些是跟厂商合作，但是我觉的应该还是有其他办法能再次提升service常驻的概率，至少保持按下home键后手机锁屏service不被杀死吧，看到这里要是有大神知道的是什么方式的请指导指导，分享分享，给小弟一个方向，多谢不同的andorid系统版本： 1. android5.0开始系统做的越来越安全了，5.0以下start service可以隐式启动，就是不设置intent的package，但是5.0开始就必须要设置了 2. 最近刚出的android N已经把静态广播网络变换广播去掉了。。。这个对我们来说实在是巨大的打击，编程了只能动态注册。。。 3. 哇靠，头好晕，感冒了。。。拜拜如何提高Service的优先级避免被杀死或者杀死后如何再次重启Service_百度知道
如何提高Service的优先级避免被杀死或者杀死后如何再次重启Service
提问者采纳
persistent=&quot.;.。 1，当进程长期不活动时. 添加android，但是每一种方法都有不同的适用环境，都能搜到好几种方法，随便在网上搜一下，如果系统资源吃紧。 如何避免Service被系统杀死，或不可见的Activity等所在的进程，会杀死一些Service我们知道
其他类似问题
为您推荐：
优先级的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁4327人阅读
重写的方法。
@Override& &
public int onStartCommand(Intent intent, int flags, int startId) {
& && &&&return START_STICKY;& &
& &简单介绍下这个方法，在开发的过程中，每次调用的时候，都会调用该对象的方法，然后在方法中做一些处理。然后我们注意到这个函数有一个的返回值，这篇文章就是简单地讲讲返回值的作用。&
& 从官方文档中，我们知道有种返回值：
& & START_STICKY：如果进程被掉，保留的状态为开始状态，但不保留递送的对象。随后系统会尝试重新创建，由于服务状态为开始状态，所以创建服务后一定会调用方法。如果在此期间没有任何启动命令被传递到，那么参数将为。
& & START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完后，服务被异常掉，系统不会自动重启该服务。
& & START_REDELIVER_INTENT：重传。使用这个返回值时，如果在执行完后，服务被异常掉，系统会自动重启该服务，并将的值传入。
START_STICKY_COMPATIBILITY：的兼容版本，但不保证服务被后一定能重启。
当然也还有其他解决方案，但是或多或少都会出现一些弊端或者相对来说比较麻烦。在这里举几个最常见的例子
1.在方法中重启服务，一般来说，这样做是可以的。但是如果这样》设置下载强制停止。则不会执行方法，或者通过别人应用，如直接掉我的应用时，也是不会调用的方法的。
&manifest&&xmlns:android=&/apk/res/android&
& && &&&android:sharedUserId=&android.uid.system&&& &&&
&application android:icon=&@drawable/icon&
android:label=&@string/app_name& android:allowClearUserData=&false&
& && && & android:process=&system&&&android:killAfterRestore=&false&&
如果在加入了此部分代码，表示该程序运行在进程组中，进程组是没有权限访问卡的，而且是不会自动重启的。
3.提高的优先级别不管你的优先级别有多高用户都是可以手动杀死的
等等还有其他很多种方式，这里就不一一列举了。
& & 所以如果要使自己的能够一直运行重写onStartCommand方法就好了但是千万不要做坏事不要做被用户鄙视的恶意程序
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：404635次
积分：4423
积分：4423
排名：第4593名
原创：17篇
转载：324篇
评论：103条
(1)(1)(2)(7)(4)(3)(9)(12)(16)(16)(8)(1)(21)(10)(4)(10)(1)(9)(11)(34)(26)(73)(14)(3)(4)(3)(1)(4)(5)(14)(15)求助大牛！如何使service不被kill或者被kill后马上重启
[问题点数：100分，结帖人nthmlyc]
求助大牛！如何使service不被kill或者被kill后马上重启
[问题点数：100分，结帖人nthmlyc]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2012年1月 移动平台大版内专家分月排行榜第三
2010年12月 多媒体/设计/Flash/Silverlight 开发大版内专家分月排行榜第二
2011年4月 多媒体/设计/Flash/Silverlight 开发大版内专家分月排行榜第三2011年3月 多媒体/设计/Flash/Silverlight 开发大版内专家分月排行榜第三2010年11月 多媒体/设计/Flash/Silverlight 开发大版内专家分月排行榜第三2010年10月 多媒体/设计/Flash/Silverlight 开发大版内专家分月排行榜第三
本帖子已过去太久远了，不再提供回复功能。怎么让Service不被kill掉或能自动重启
[问题点数：50分]
怎么让Service不被kill掉或能自动重启
[问题点数：50分]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2015年2月 移动开发大版内专家分月排行榜第二
2015年4月 移动开发大版内专家分月排行榜第三2015年1月 移动开发大版内专家分月排行榜第三
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。}