精华内容
下载资源
问答
  • 主要介绍了Android Service 服务不被杀死的妙招的相关资料,需要的朋友可以参考下
  • 一个安卓demo,功能是:除了系统的任务管理器,其它软件,包括设置里的应用杀死也无法杀死服务。利用2个服务相互绑定实现。
  • Android的进程保活包括两个方面:提高进程的优先级,降低进程被杀死的概率.在进程被杀死后,进行拉活.
  • 对应博文链接:... 杀不死的服务一直是一件很头疼的问题,这边给出源码:Android 通过JNI实现双守护进程,保证服务不被杀死。完美运行在谷歌原生Android5.0系统
  • Android Service服务如何不被杀死 2017年02月11日 16:38:29 a296777513 阅读数:13890 版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/a296777513/article/details/54984935 第一...

    Android Service服务如何不被杀死

    2017年02月11日 16:38:29 阅读数:13890

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/a296777513/article/details/54984935

    第一章 Service介绍

    service服务是一个应用程序的四大组件之一,可以再后台执行长时间运行的操作,不提供用户界面。一个应用程序组件可以启动一个服务,它将继续在后台运行,即使用户切到另一个应用程序。此外,一个组件可以绑定到一个服务与它交互,甚至执行进程间的通信(IPC)。

    1.1 基础介绍

    Service中比较重要的方法有以下几个:

    • onStartCommand()
      当其他组件,如Activity请求服务启动的时候,系统会调用这个方法。一旦这个方法执行,服务就开始执行。如果实现这个方法,当服务完成任务后,需要你调用stopSelf()或者stopService()来停止服务。如果只想提供绑定,不需要自己实现这个方法。
    • onBind()
      当有其他组件想通过bindService()方法绑定这个服务时系统就会调用此方法。在实现的方法里面,必须添加一个供客户端使用的接口通过返回IBinder来与服务通信,这个方法必须实现。当然想禁止绑定的话,返回null即可。
    • onCreate()
      服务第一次建立的时候会调用这个方法,执行一次性设置程序,在上面2个方法执行前调用。如果服务已存在,则不执行该方法。
    • onDestory()
      服务不再使用则调用该方法。服务应该事先这个方法来清理诸如线程,注册的监听器等资源。这是最后调用的方法。

    Android系统只会在内存占用很高,必须回复系统资源供当前运行程序的情况下强制停掉一个运行中的服务。如果服务绑定在当前的运行程序中,就几乎不会被kill,如果服务声明了在前台运行(其实在后台,只是给系统一个错误的信息来提高优先级),就几乎不会被kill。另外,如果一个服务正在运行,且运行了很久,系统就会根据运行时间把其排在后台任务列表的后面,则这个服务很容易被杀掉。根据onStartCommand()的返回值设置,服务被杀掉后仍然可以再资源充足的条件下立即重启。

    1.2启动服务的两种方式:

    • started启动:started形式的服务是指当一个应用组件(比如activity)通过startService()方法开启服务。一旦开启,该服务就可以永久的在后台运行,哪怕开启它的组件被销毁掉。通常开启的服务执行一个单独的操作并且不向调用者返回一个结果。比如,从网络下载文件,当文件下载完成,服务就应该自己停止。
      关闭服务则需要服务自己调用方法stopSelf()或者由启动服务的地方调用stopService(Intent)方法来关闭。
    • Bound绑定:bound形式的服务是指一个应用组件通过调用bindService()方法与服务绑定。一个绑定的服务提供一个接口,允许组件与服务交互,发送请求、获得结果、甚至进行进程间通信。一个绑定的服务只和与其绑定的组件同时运行。多个组件可以同时绑定到一个服务,当全部解除绑定后,服务就会被销毁。

    虽然分为两类,但是一个服务可以同时使用这两种方式-使用started永久运行,同时允许绑定。只要在服务中实现两个回调方法:onStartCommand()允许组件开启服务,onBind()允许绑定。

    不论引用程序是怎么起服务的,任何应用程序都可以用这个服务。同样的,任何组件可以使用一个Activity通过传递Intent开启服务。你也可以在配置文件设置服务为私有来防止其他应用访问该服务。

    注意:一个服务在进程中的主线程运行,服务不会自己创建线程和进程(除非特别指定或者开启一个线程)。这意味着,如果服务需要做一些频繁占用CPU的工作或者会发生阻塞的操作,需要在服务另外开启线程。

    1.3 Service生命周期

    Service生命周期

    • 启动服务:startService()->onCreate()->onStartCommand()->running->stopService()/stopSelf()->onDestroy()->stopped,其中,服务未运行时会调用一次onCreate(),运行时不会调用。
    • 绑定服务:bindService()->onCreate()->onBind()->running->onUnbind()->onDestory()->stopped

    在上面两个过程中,只有onStart

    第二章 实现Service

    实现服务有两种方式,继承service或者IntentService。后者是前者的子类。前者包含上一章节中Service的几个重要的方法,用于普通的服务。后者可以自己开一个工作线程,串行的处理多个请求。

    2.1 继承Service

    继承Service就可以实现对请求多线程的处理,前面介绍了Service的生命周期,可以按照生命周期实现方法,就不放示例了。

    2.2 继承IntentService

    大多数服务不需要同时处理多个请求,继承IntentService是最好的选择。
    IntentService处理流程:

    1. 创建按默认的一个worker线程处理传递给onStartCommand()所有的intent,在非UI线程中区工作。
    2. 创建一个工作队列依次传递一个intent到你实现的onHandleIntent()方法,避免了多线程。
    3. 在所有启动请求被处理后自动关闭服务,不需要调用stopSelf()
    4. 默认提供onBind()的实现,并返回null
    5. 默认提供onStartCommand()的实现,实现发送intent到工作队列再到你的onHandleIntent()方法实现。

    这些都加入到IntentService中了,你需要做的就是实现构造方法和onHandleIntent(),如下:

    public class HelloIntentService extends IntentService {
    
      /**
       * A constructor is required, and must call the super IntentService(String)
       * constructor with a name for the worker thread.
       */
      public HelloIntentService() {
          super("HelloIntentService");
      }
    
      /**
       * The IntentService calls this method from the default worker thread with
       * the intent that started the service. When this method returns, IntentService
       * stops the service, as appropriate.
       */
      @Override
      protected void onHandleIntent(Intent intent) {
          // Normally we would do some work here, like download a file.
          // For our sample, we just sleep for 5 seconds.
          long endTime = System.currentTimeMillis() + 5*1000;
          while (System.currentTimeMillis() < endTime) {
              synchronized (this) {
                  try {
                      wait(endTime - System.currentTimeMillis());
                  } catch (Exception e) {
                  }
              }
          }
      }
    }

    第三章 如何保证服务不被杀死

    在有些特定的情况下,服务需要保持开启不能被杀死。主要有以下几种方法保持Service不被杀死。

    3.1 onStartCommand方法中,返回START_STICKY

    StartCommand()几个常量:

    • START_STICKY
      系统重新创建服务并且调用onStartCommand()方法,但并不会传递最后一次传递的intent,只是传递一个空的intent。除非存在将要传递来的intent,那么就会传递这些intent。这个适合播放器一类的服务,不需要执行命令,只需要独自运行,等待任务。
    • START_NOT_STICKY
      系统不重新创建服务,除非有将要传递来的intent。这是最安全的选项,可以避免在不必要的时候运行服务。
    • START_REDELIVER_INTENT
      系统重新创建服务并且调用onStartCommand()方法,传递最后一次传递的intent。其余存在的需要传递的intent会按顺序传递进来。这适合像下载一样的服务,立即恢复,积极执行。
    @Override  
    public int onStartCommand(Intent intent, int flags, int startId) {  
        flags = START_STICKY;  
        return super.onStartCommand(intent, flags, startId);  
    }  

    手动返回START_STICKY,亲测当service因内存不足被kill,当内存又有的时候,service又被重新创建,比较不错,但是不能保证任何情况下都被重建,比如进程被干掉了….

    3.2 提升Service优先级

    前台服务是被认为用于已知的正在运行的服务,当系统需要释放内存时不会优先杀掉该进程。前台进程必须发一个notification在状态栏中显示,知道进程被杀死。因为前台服务一直消耗一部分资源,但不像一般服务那样会在需要的时候被杀掉,所以为了节约资源,保护电池寿命,一定要在建前台服务的时候发送notification,提示用户。当然系统提供的方法就必须有notification参数的,所以不要想着怎么把notification隐藏掉。

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        // TODO Auto-generated method stub
        Intent notificationIntent = PendingIntent.getActivity(this, 0, notificationIntent, 0);
        Notification noti = new Notification.Builder(this)
                    .setContentTitle("Title")
                    .setContentText("Message")
                    .setSmallIcon(R.drawable.ic_launcher)
                    .setContentIntent(pendingIntent)
                    .build();
        startForeground(123456,noti);
        return Service.START_STICKY;
    }

    startForeground()方法就是将服务设置为前台服务,参数123456就是这个通知的唯一的id,只要不为0即可。

    3.3 在onDestory()中发送广播开启自己

    service+broadcast方式,就是当service调用到ondestory()的时候,发送一个自定义的广播,当收到广播的时候,重新启动service;

    <receiver android:name="com.example.demo.MyReceiver">
        <intent-filter>
            <action android:name="android.intent.action.BOOT_COMPLETED"/>
            <action android:name="android.intent.action.USER_PRESENT"/>
            <action android:name=com.example.demo.destroy"/>// 这个是自定义的action
        </intent-filter>
    </receiver>

    在service中的ondestroy()时候:

    @Override
    public void onDestroy(){
        stopForeground(true);
        Intent intent = new Intent("com.example.demo.destroy");
        sendBroadcast(intent);
        super.onDestroy();
    }

    在MyReceiver中

    public class MyReceiver extends BroadcastReceiver {
        @Override
        public void onReceive(Context context, Intent intent) {
            if(intent.getAction().equals("com.example.demo.destroy")){
                Intent sevice = new Intent(this, MyService.class);  
                this.startService(sevice); 
            }
        }
    }

    当然,从理论上来讲这个方案是可行的,实验一下结果也是可行的。但是有些情况下,发送的广播在消息队列中排的靠后,就有可能服务还没有接收到广播就销毁了(只是猜想)。所以为了能让这个机制完美运行,可以开启两个服务,相互监听,相互启动。服务A监听B的广播来启动B,服务B监听A的广播来启动A。经过实验,这个方案是可行的。

    展开全文
  • @[TOC]Android service 不被杀死“永不退出的服务”(双进程,服务,多进程,微信) Android service 不被杀死“永不退出的服务”(双进程,服务,多进程,微信) 本文是转载大佬的,后面会附带转载地址 作者:...

    @[TOC]Android service 不被杀死“永不退出的服务”(双进程,服务,多进程,微信)

    Android service 不被杀死“永不退出的服务”(双进程,服务,多进程,微信)

    本文是转载大佬的,后面会附带转载地址
    作者:robert_cysy
    原文:https://blog.csdn.net/robert_cysy/article/details/53790824

    介绍服务开发:

    介绍关于服务不被杀死,以及微信的永久驻村谜底;

    第一次做关于服务的开发,看了很多文章,终于有个大概,任后开始写程序测试并感受。在这里把学到的东西汇总一下,分享给大家。

    关于service

    随便一搜索很对关于Android开发service的文章,所以这简要说明。有一篇文章说的很好:“它是一种长生命周期的,没有可视化界面,运行于后台的一种服务程序。比如我们播放音乐的 时候,有可能想边听音乐边干些其他事情,当退出播放音乐的应用,如果不用Service,我 们就听不到歌了,所以这时候就得用到Service了。”

    我喜欢这个解释。当然除此之外,普通应用使用了service使得整个应用有好的耦合性(功能实现不互相依靠,相对比较独立)。就从字面意思来理解,提供服务的功能部分一般适合开发成一个服务。比如蓝牙连接服务。网络通信服务。音乐播放服务。当然我们自己开发的服务一般只给自己的应用使用。

    以下简单汇总一下其他文章提到的精华部分,以及不全其他文章不足的地方。

    1.Android service分类:startservice bindservice两种方式

    startservice适合服务与应用程序在一块的情况,service和调用的应用程序在同一个进程里面。一般用于执行更新,加载等费事的操作。

    Bindservice适用于完成一个独立功能的部分。不如一个蓝牙服务,需要蓝牙服务的app只需要bind服务就可以使用这个服务,相对于startservice来说,bindservice给更多调用者服务。

    生命周期,网上文章说,startservice调用者不在了,还可以继续执行,

    而,bindservice可以支持好多调用者绑定,当时一旦所有绑定者都死掉的化,bindservice也就退出了。当然startservice调用的时候会启动服务,bindservice在调用的时候如果服务还没有被启动则会启动服务。我在实际测试中,只要用清理工具清理了调用服务的软件,调用者不在了,无论那种方式启动的服务都会被关闭。

    下面专门说一下“永不退出的服务”

    为了本文方便描述:先介绍测试中用到的两种关闭服务的方法:

    在用使用清理运行软件的功能作为关闭服务的第一种测试方法:向侧面滑动应用就被关闭。即清理后台运行的软件。在这里插入图片描述

    在测试时关闭服务的第二种测试方式:在“正在运行的软件”里点击停止在这里插入图片描述

    关于周期网上有好多文章都是提到了“不死的服务”。很多文章提到了做出一个不死的服务。具体提到的方式有:

    onStartCommand方法,返回START_STICKY

    也就是在service的onstartcommand函数里返回这个值

    @Override

    public int onStartCommand(Intent intent, int flags, int startId) {

    flags = START_STICKY;  
    
    return super.onStartCommand(intent, flags, startId);  
    

    }

    这个时候如果清理的是一个设置了START_STICKY的app,用方法一和二的时候服务都会被杀掉,后来我测试多了,发现在清理软件里吧这个应用加入白名单之后。在使用方法一的时候。acrivity被清理掉了,但是服务不会被清理。,使用方法二的时候,服务会被关闭,然后一段时间又会重新自动出现。即START_STICKY产生的效果。

    1. 设置服务为前台进程。startForeground(0x111, notification);具体操作过程查看其他文章。这里说一下效果,实现了前台进程其实就是在状态栏显示一个提示,应该是用来告诉用户所执行的动作在后台还在进行者,只能说service的优先级提高了,在系统内存不足的时候不会被第一个销毁。但是用户是可以通过方法一和二关闭这个服务的。(即调用者死掉,其服务也会被杀掉)。

    **在service的ondestroy里发送开启服务的intent。以及开启两个service相互监视,谁死掉就发送intent启动谁。**本人没有测试。由于看清了服务的一些使用特性,觉得开发这样死活关不掉的应用实在是不好。

    还有就是要做成系统应用,即把手机开启root账号,然后安装app到系统到system/app目录下。以使app获取系统级别的启动权限。

    还有人为了达到不是服务真是用心良苦。居然研究了从linux底层开启进程做起,因为是看到像微信,搜狐。说实话,很佩服这些人的头脑以及技术。

    在这里插入图片描述

    以下这三篇文章讲的很好关于这方面。

    http://blog.csdn.net/ztemt_sw2/article/details/27101681

    http://download.csdn.net/detail/mihang2/9283985

    http://blog.csdn.net/huaxun66/article/details/53158162

    总结一下自己为啥放弃开发一个不死的服务。

    1. 需求方面:只有我的软件在运行的时候,我的服务才有存在的必要。

    2. 我用的是魅族和华为手机做的测试,使用清理后台应用(即:测试方法一)只要activity被杀死,那么跟着其对应的service也被杀死,对于网上来说的很多实现不被杀死方法都是因为其测试用的手机系统比较原生,一般不会强制杀死一个没有被调用的服务。当然我也没有在模拟器里运行测试,就是在两个手机上运行测试,是这样的。

    3. 发现微信也不是不死的app。发现酷狗音乐这种播放音乐的软件也会在activity死掉的时候,停止播放音乐。

    4. 关于用户体验的思考。对于普通应用没有必要在关闭activity之后仍然运行service。

    关于要不要开启一个不死的服务:看到了一片英文文章,关于要不要做一个不死服务的必要性讲的很好。

    原文大体翻译如下:

    很多开发者为了达到服务随时被启动起来的activity调用,而忽略了以下这些消耗:

    在运行的时候,尽管dalvik使用了用时复制技术来共享相同的内存。但是一个存留的服务耗费了一个进程所占用的内存。

    在运行的时候,RAM耗尽的时候,服务仍然对抗android系统不让杀掉自己

    在运行的时候,服务要对抗关闭它的用户。(用户用应用管理器或第三方管理器)

    在运行的时候,当设备睡眠的时候,CPU被关闭。即服务也被关闭了,除非这个服务开启阻挡手机睡眠选项。这就意味着电池电量的消耗。

    因此推荐的方法是:使用AlarmManager。把你的服务当成定时执行任务或者计划执行任务。而不是一个永久的服务就像windows服务那样。

    以下这样的设计方法会是的应用更好的与android系统构架和谐并存。

    1. 只有服务真的在做事情的时候才开启服务,不要让服务坐着干等

    2. 其实android杀死服务的几率很低。因为只要你正在使用服务,服务就不会变老。系统也就会杀掉其他服务而不是你正在使用的服务。

    3. 用户停掉服务的几率也在减少。因为一个好的服务不会给用户造成影响,也不会给用户导致问题。

    4. 服务在其工作期间可以使用一段时间的WakeLock来保持CPU保持运作。但用完时候马上停用WakeLock。

    我鼓励android开发者在可能的情况下尽量避免开发长时间运行的服务。

    以上是原文精华。

    那么说这样设计的例子有哪些。下面我举“酷狗音乐”的例子。

    当你打开“酷狗音乐”并且播放了一首音乐,音乐在播放,你按下home键,然后activity被放置在后天,这个时候,后台服务来播放音乐。在播放的时候会在消息栏显示一个正在播放的音乐状态,以及控制按钮,这个部分是把服务设置为前台服务。提高了服务的优先级。那么现在你使用我上面说的方法一,即把“酷狗音乐”的activity真正关闭之后,(调用者死掉)这个时候你会发现之前正在播放的音乐也会立即停止掉。即没有使用者服务就立马停掉。再进一步使用方法二手动关闭“酷狗音乐”的服务。音乐也会停止,并不再启动。这样的设计即使遵循了上面那篇英文文章所描述的方法。就是系统和用户其实在需要你服务的时候是不会把你的服务停掉的,除非系统和用户真的就是要停止你,那么你这个app为啥还不让停止的。

    Android系统不会无端停止一个正在被使用的service。除非你这service自己就自己一个人硬抗,答案是你抗不住的。无论你用什么手段。除非系统说你是个好人放过你吧。

    下面介绍微信为什么死不掉。先说结果。微信其实也是遵循英文文章提到的设计模式。即你有界面正在聊天的时候,服务也一直在后台运行。一般用户关闭微信是使用home键。即activity放在了后台,即“微信”中调用者的身份还在。

    但是,但是接下来的就是神奇的部分,无论使用方法一还是方法二,都阻止不了微信继续可以收到消息。为啥呢,微信到底是使用了什么手段。什么黑科技。而且后台确实有两个进程,每个进程里都有一个或几个服务。而且用方法二关闭服务,很快服务又会重新出现。难道这个真是有两个服务互相监视,或者是有个非常底层的一个守护进程来保持应用不退出。

    就在此时我没有写代码,而是下载了一个号称开启守护进程用jni开发的不死例子。

    例子网址如下:http://download.csdn.net/detail/mihang2/9283985

    下载下来并安装到手机上,使用方法一个和二测试。方法二的时候,“正在运行的应用程序”界面确实可以显示停止了,即在界面里面看不到这个服务的身影,但是从调试信息里看到服务仍然还在运行者,虽然“正在运行的应用程序”里看不到服务的身影。然后使用方法一的测试结果是,服务马上就死掉了。那么回头继续来总结一下,为什么方法二没有真正停止服务呢,我想是因为虽然activity被放置在后台,它是它并没有死,还在调用服务。所以服务并没有被系统正真杀掉,系统知道调用者activity还在运行。那么为啥用方法一,服务马上就死掉了,因为系统发现你这activity不在了,留下你这个服务也没啥用,浪费资源和电池干脆把你立刻就停止。(当然这里只服务和调用activity在同一个进程里,即便不在一个进程里,如果没有调用者,这个服务仍然会被杀掉)

    那么接着回来看“微信”进程为啥可以不死。我们从另一个角度观察微信的进程。

    首先从手机正在运行的程序来看是如下结果:

    在这里插入图片描述

    从上面的截图也可以看到这几个进程以及对应的服务

    大家都是Android开发者,我是在windows下开发。打开命令提示符,插入一个开启了调试模式的手机,登录运行一个微信,输入:“adb shell”这个时候你就进入了android手机的命令行终端,(linux终端)。可以执行linux命令。然后执行top命令查看当前运行的进程。执行如下命令:top –n 1 | greptencent

    在这里插入图片描述

    在这里插入图片描述

    可以看到微信有三个进程,进程pid分别是“4087”,“4221”,“29839”
    在这里插入图片描述

    在这里插入图片描述

    可以从ps的结果发现,虽然是三个独立的进程,但是他们的父进程都是396,也就是说三个进程都是由同一个进场所创建。

    继续往下看,现在查看我之前下载的那个关于使用的守护进程(使用jni开发的那个)例子http://download.csdn.net/detail/mihang2/9283985。

    运行这个软件,然后用top命令和ps命令看:

    发现问题了吗?,dameonsercice确实是有两个进程但是者两个进程的父进程居然不一样,而微信的是一样的。难道这就是其所说的守护进程。然后继续分析,看到另一个父进程不是396的进程的父进程为9846,而这个9846,是这个dameonservice进程的pid进程。也就是说。这个守护进程是有原来的进程创建而来的。,因此当我使用方法一关掉activity的时候,相当于把父进程销毁了,但是根据linux的知识,这个自进程不会被销毁,应该会被init进程收留成为正真linux下的守护进程,我查看了一下其它父进程为1的进程(linux守护进程)都是系统的软件,没有任何app是属于守护进程的。应该是Android构架限制了吧。所以这个作者做的守护进程方法,经过测试,其实是没有成功的。

    先不管这个,,先看看为啥其中一个父进程和微信的父进程一样呢。所以来看一下,关于这个“396”进程,首先根据linux,子进程都是被父进程创建(fork)而来的,也就是说微信和这个应用都有同一个父进程。使用ps | grep 396和 top –n 1 | grep396查看结果如下:
    在这里插入图片描述

    原来,所有运行的安卓app都是由zygote这个进程创建而来。仔细查看zygote的那一行。可以看到其pid即进程id为396。而其父进程为1,也就是说zygote是一个正真意义上的linux守护进程。又学习了一下。

    最后这里给解释一下微信的这么多进程到底是怎么来的,由于以上测试可知,如果用jni用c++开启来开启一个进程的话,那么其父进程就不会是zygote。但是现在我们看到的微信所有父进程都是zygote也就是说微信没有使用jni里面创建进程。也就否定了其他博客对微信开启什么守护进程的猜想了。

    那么微信的这些进程到底是怎么来的呢:

    我是从这篇文章看到的相关信息

    http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0403/2686.html

    文章提到了Androidmannifest.xml里面service部分的process元素。一下是一部分的原文:

    理解Android进程

    你应该已经知道了,安卓系统是基于Linux的。因此,每个应用程序都运行在其本身的进程(拥有一个独一无二的PID)中:这允许应用运行在一个相互隔离的环境中,不能被其他应用程序/进程干扰。通常来说,当你想启动一个应用程序,Android创建一个进程(从Zygote中fork出来的),并 创建一个主线程,然后开始运行Main Activity。

    你可能不知道的是,你可以指定应用程序的一些组件运行在不同的进程中,而不是那个被用于启动应用程序的。先来看一下这个Nice的属性:

    android:process

    该进程属性可用于activities、services、content providers和broadcast receivers 和指定的进程中应该执行的特定组件。

    在这个例子中,我指定MusicService必须执行在一个单独的“music”的进程:

    <manifest …>

    <application

    android:icon="@drawable/ic_launcher"
    
    android:label="@string/app_name"
    
    android:theme="@style/Theme.Main" >
    
    <activity
    
      android:name=".MusicActivity"
    
      />
    
    <service
    
      android:name=".MusicService"
    
      android:process=":music"
    
    />
    

    然后我们看反编译微信里的Androidmannifest.xml,当然只反编译了资源文件。
    在这里插入图片描述

    在这里插入图片描述

    从内容可以看到其中我们在之前看到的push进程是怎样来的。

    也就证明出了,微信开启进程的方法。

    接下来看看“微信”在面对两种测试方法其进程到底是怎样的。(真正的揭秘微信不死的面纱)

    先从adb shell 命令里执行top –n 1 | grep tencent来查看一下微信正常运行是的状态。

    在这里插入图片描述

    现在使用方法二来停止服务:

    我把“正在运行”里面的可以看到的服务都关闭了,然后运行top –n 1 | grep tencent结果如下:

    在这里插入图片描述

    可见服务并没有变化,当然按我的理解是,因为有一个后台的activity正在使用服务,所以服务没有被系统销毁了,因为我们自己的测试服务如果被方法二关闭的化,我们看到调试信息里,服务仍然在运行,也就是就像我们现在看到的,其实服务进程并没有被销毁。

    然后使用方法一来停止服务:
    在这里插入图片描述
    结果是,这几条服务还在,这也就是人们感觉对微信的深不可测,没有被销毁。虽然,我已经把放置到后台的activity销毁了,但是服务没停。那么接下来我是怎么样发现微信的不死秘密的呢。

    答案如下:
    在这里插入图片描述

    我以我的魅族手机为例:可以看到加速的时候(也就是我的测试方式一)其实并没有清除微信的任何进程,右面是华为的,华为的没有找到具体显示吧微信放在白名单的。但是很显然华为系统是有一个“内存加速白名单”,微信这样的应用就在白名单里。

    再看下面俩张图。显示了魅族和华为的加速白名单。微信默认就在里面。
    在这里插入图片描述

    那么按照我看到这个之后的猜想,把微信从白名单里去掉或者把我自己开发的软件放到白名单都可以验证“微信”杀不掉的原因。

    现在我吧微信从白名单里移除,然后使用方法一来测试:

    在这里插入图片描述

    可以看到,微信的进程都没有了,当然是死掉了。

    知道微信为啥不死了吧,其实我查找文章的时候,看到一个论坛提到了说“系统给微信设置了白名单,其实微信没有做什么黑科技”,我当时感觉不信,就此折腾了几天。
    当然,微信有好多服务和进程,只有当服务需要执行功能的时候,我们才可以看到服务进程,也就是说微信把暂时不用的服务都停止掉了。我的测试不能排除微信使用了双服务互相启动,虽然微信在系统白名单里。

    当然可以从Androidmannifest.xml看出微信使用了开机启动,和激活屏幕启动。当然从华为的那张截图里可以看到微信使用wakelock,就是微信在关闭屏幕之后还在后天运行。

    关于wakelock详细内容查看以下文章。

    http://blog.sina.com.cn/s/blog_4ad7c2540101n2k2.html

    其中有个选项为:PARTIAL_WAKE_LOCK:保持CPU 运转,屏幕和键盘灯有可能是关闭的。

    展开全文
  • Android Service 不被杀死

    2016-07-11 23:13:56
    1.Android:persistent=...通过 startForeground将进程设置为前台进程,做前台服务,优先级和前台应用一个级别​,除非在系统内存非常缺,否则此进程不会 kill 4.双进程Service:让2个进程互相保护,其中一个Servic

    1.Android:persistent=true
    2.Service设置成START_STICKY,kill 后会被重启(等待5秒左右),重传Intent,保持与重启前一样
    ​3.通过 startForeground将进程设置为前台进程,做前台服务,优先级和前台应用一个级别​,除非在系统内存非常缺,否则此进程不会被 kill
    4.双进程Service:让2个进程互相保护,其中一个Service被清理后,另外没被清理的进程可以立即重启进程
    5.QQ黑科技:在应用退到后台后,另起一个只有 1 像素的页面停留在桌面上,让自己保持前台状态,保护自己不被后台清理工具杀死
    在已经root的设备下,修改相应的权限文件,将App伪装成系统级的应用(Android4.0系列的一个漏洞,已经确认可行)
    Android系统中当前进程(Process)fork出来的子进程,被系统认为是两个不同的进程。当父进程被杀死的时候,子进程仍然可以存活,并不受影响。鉴于目前提到的在Android-Service层做双守护都会失败,我们可以6.fork出c进程,多进程守护。死循环在那检查是否还存在,具体的思路如下(Android5.0以下可行)

    用C编写守护进程(即子进程),守护进程做的事情就是循环检查目标进程是否存在,不存在则启动它。
    在NDK环境中将1中编写的C代码编译打包成可执行文件(BUILD_EXECUTABLE)。
    主进程启动时将守护进程放入私有目录下,赋予可执行权限,启动它即可。
    
    展开全文
  • 1.设置->应用->运行中->停止->杀死service 这样可以在service的onDestroy()方法中重启service public void onDestroy() { Intent service = new Intent(this, MyService.class); startService(service); super....

    1.设置->应用->运行中->停止->杀死service

    这样可以在service的onDestroy()方法中重启service


    public void onDestroy() {
    Intent service = new Intent(this, MyService.class);
    startService(service);
    super.onDestroy();
    }

    这种方法简单粗暴,测试有效.

    也可以用两个service,A和B.

    在服务A中监听服务B被杀死时发送的广播,然后重启服务B;同理在服务B中监听服务A被杀死时发送的广播B,然后重启A.

    这样写的代码更加健壮.

    2..设置->应用->已下载->停止运行

    这样强制停止运行,service并不会走 onDestroy()方法,所以无法保活.


    展开全文
  • Android Service服务被杀死后重启

    千次阅读 2014-11-26 10:53:07
    可以理解为android端监听推送消息的服务在启动后是一直在后台运行的,但是当内存不足时,或者第三方应用清理内存时会杀死后台服务,此时该服务需要自动重启。 该问题只需要在推送服务的onStartCommand方法返回类型...
  • 虽然不断的研究各式各样的方法,但是效果并不好,比如任务管理器把App干掉,服务就起来了... 网上搜寻一番后,主要的方法有以下几种方法,但都是治标治本: 1、提高Service的优先级:这个,也只能说...
  • [Android] Service服务详解以及如何使service服务不被杀死 转自http://www.cnblogs.com/rossoneri/p/4530216.html 阅读目录Services 创建“启动的”服务 创建“绑定的”服务 关于怎样让服务不被杀死Services ...
  • [Android] Service服务详解以及如何使service服务不被杀死 怎样使一个Android应用不被杀死?(整理)  参考: ...
  • 保证Android后台不被杀死的几种方法

    千次阅读 2016-01-27 17:03:00
    由于各种原因,在开发Android应用时会提出保证自己有一个后台一直运行的需求,如何保证后台始终运行,不被系统因为内存低杀死不被任务管理器杀死不被软件管家等软件杀死等等还是一个比较困难的问题。网上也有...
  • Bound绑定:bound形式的服务是指一个应用...多个组件可以同时绑定到一个服务,当全部解除绑定后,服务就会销毁。 虽然分为两类,但是一个服务可以同时使用这两种方式-使用started永久运行,同时允许绑定。只要在...
  • (主要是由于android自带内存清理)在进行了大量的查阅和测试后,笔者终于解决了该问题:当然,在此也要稍微提一下,笔者只测试了,在以一小时为左右的时间内可以不被杀死,还没有测试2个小时以上的情况,更没有测试...

空空如也

空空如也

1 2 3 4 5 ... 19
收藏数 363
精华内容 145
关键字:

android服务不被杀死