精华内容
下载资源
问答
  • app之 杀不死的进程

    千次阅读 2017-03-28 23:33:03
    有些需求要求app进程杀不死 我觉的扯再多都是没用的 不如 给你们看看~~~人家是如何实现的 demo是可以用的 我已经测试成功了 感觉很厉害哦~~好佩服的哦~~~哦哦哦~~~ 常驻进程 Android常驻进程,就是要让进程在...

    有些需求要求app进程杀不死 

    我觉的扯再多都是没用的  不如 给你们看看~~~人家是如何实现的

    demo是可以用的 我已经测试成功了 感觉很厉害哦~~好佩服的哦~~~哦哦哦~~~

     

     

       常驻进程

            Android常驻进程,就是要让进程在内存中永远存在,让进程保活,不被杀死。可能这时都会喷,这不是流氓软件吗?刚接触android的时候,我也是认为这是很流氓的做法,可是慢慢发现很多场景(应用),要为用户服务,就必须用到常驻进程,就好像微信,QQ,360安全手机卫士这些现在比较火,比较常用的软件来说,他们都是实现了常驻进程的。所以说,有时候常驻进程在开发中是必须的,比如锁屏应用,就必须在进程中接收锁屏的广播,因此要保证进程常驻,像QQ,微信那些IM类应用,也需要长期在后台维护一个长链接,因此进程常驻又是必须的!

            因为最近开发的应用需要用到常驻进程,因此一开始的猜想在Java层是不能解决的,必须得在native解决,可是现在对Linux和android系统理解还不够深入,而且ndk开发才刚入门,因此在网上搜了一大堆资料,总得来说,给出的解决方法不就外乎下面的几种:

     

    1、将Service设置为前台进程
           相关资料和Demo可以查看之前的博客:http://blog.csdn.net/Two_Water/article/details/52084372

     

           本质是修改了Service所在进程的进程优先级。有了前台进程的优先级,在android系统清理内存的时候,他被杀死的优先级仅高于前台的activity,也就是正在和用户交互的页面,而且使用ddms杀进程他也可以自己启动起来。首先ddms杀进程和在系统设置的正在运行中杀进程本身就不具威胁,在系统设置的所有应用中选择强行停止,仍然可以强停掉,360,cm等软杀更是能轻而易举杀死他。而且他还有一个缺点,在api17以上,设置了一个前台服务,他会以一个无法消除的notification的样式出现在用户的手机状态栏里,大大降低了用户体验。可是前台服务适合做一些音乐播放器,天气类的应用!

     

    2、在service的onStartCommand方法里返回 STATR_STICK
           主要的几个返回值:
           1. START_STICKY_COMPATIBILITY:START_STICKY的兼容版本,但不保证服务被kill后一定能重启。 
           2. START_STICKY:系统就会重新创建这个服务并且调用onStartCommand()方法,但是它不会重新传递最后的Intent对象,这适用于不执行命令的媒体播放器(或类似的服务),它只是无限期的运行着并等待工作的到来。
           3. START_NOT_STICKY:直到接受到新的Intent对象,才会被重新创建。这是最安全的,用来避免在不需要的时候运行你的服务。
           4. START_REDELIVER_INTENT:系统就会重新创建了这个服务,并且用最后的Intent对象调。等待中的Intent对象会依次被发送。这适用于如下载文件。

     

           测试的service是一个最基本的service,在相应的生命周期的触发函数上做了输出。在普通的服务使用还是可以的,做常驻进程的话就不行了,force close和一些清理软件很容易就清理掉!

     

    3、添加Manifest文件属性值为android:persistent=“true”
           app.persistent = true不仅仅标志着此apk不能轻易的被kill掉,亦或在被kill掉后能够自动restart,并且还涉及到了进程的优先级。将被设置为CORE_SERVER_ADJ,此值为-12,而核心进程init的值为-16。当前正在前台运行的进程的值为0。如果应用能设置这个属性,那就真的可以做到保活,因为他真的可以杀不死,像系统的keyguard进程,media进程,且这些进程的adj都是负数,代表了前台activity黑屏了他们也不会死。但是这个属性需要系统shareuid,然后编译不过,因为需要系统签名!
    因此,要弄这个属性需获取两个关键的信息: 
           (1).在apk的AndroidManifest.xml文件中设置android:persistent=true 
           (2).此apk需要放入到system/app目录下,成为一个systemapp

     

           最主要的是让程序成为系统程序,这个可以做到吗?如果你技术过硬是可以尝试下的!首先弄个自动root的apk,加壳放到程序中,然后程序运行的时候,自动运行自动root的apk,获取root权限,然后在native层中,使用命令的方式把程序移到system/app目录下,成为系统程序!

     

    4、覆写Service的onDestroy方法

     

          在设置里面的正在运行,注意是正在运行里面,点击关闭,会走onDestroy回调方法,你在这里可以把自己启动起来。注意是正常关闭的时候是会自己启动起来,可是使用第三方的清理软件360,root过的360,force close这些来搞,压根不会走到onDestory的方法,例子在之前service的博客中也有!可以去试试的!

     

    5、添加广播监听android.intent.action.USER_PRESENT事件以及其他一些可以允许的事件
           android.intent.action.USER_PRESENT,这是一个android解锁的广播事件。注意,这不是SCREEN_ON\SCREEN_OFF广播,,这不是SCREEN_ON\SCREEN_OFF广播,这不是SCREEN_ON\SCREEN_OFF广播。这是一个可以静态注册的广播。所以在manifest里面注册之后不需要任何前提,理论上用户每次开屏解锁都会触发我们的onReceive事件,在这里我们可以检查进程服务是否在,不在就拉起来。
    但是,这个事件只有解锁才有,如果用户的没有设置锁屏,那么这个事件就是没有的,而且我们的目标是保证进程一直存活,而不是尽可能多的活起来。所以这个当作一个补充的手段也不错,另外所有那些可以静态注册的广播都可以这样搞,前提是你不怕用户看到你申请了好多权限,当然这个USER_PRESENT事件是不需要权限的。
    以下是几个常见可以静态注册的广播
    android.intent.action.USER_PRESENT
    android.net.conn.CONNECTIVITY_CHANGE
    android.intent.action.MEDIA_MOUNTED
    android.intent.action.MEDIA_UNMOUNTED
    android.net.wifi.RSSI_CHANGED
    android.net.wifi.STATE_CHANGE

     

    android.NET.wifi.WIFI_STATE_CHANGED

     

    6、服务互相绑定

     

          这个是android里面一个特性,跨进程bind一个service之后,如果被bind的service挂掉,bind他的service会把他拉起来!可以考虑使用远程服务来实现,可是还是不能保活进程,可以被杀掉!

     

    7、设置闹钟,定时唤醒
          一开始个人认为这个效果还是可以的,个人测试的时候,使用360清理,他是可以保活的,开机也能重启,可是有时会失灵,而且面对force close直接挂掉!具体的例子和实现也就一个监听开机的广播,和一个周期性的闹钟!
    相关的知识点可以看我之前的博客:
    Android_AlarmManager(全局定时器)::http://blog.csdn.net/Two_Water/article/details/52004414
    Android_Service(2)前台服务(service)和远程服务(service):http://blog.csdn.net/Two_Water/article/details/52084372

     

    Demo的下载地址:http://download.csdn.net/detail/two_water/9595724

     

    8、账户同步,定时唤醒

          这个是找了很久才发现有这个东西的,android系统里有一个账户系统,设置一个自己的账户,android会定期唤醒账户更新服务,我们可以自己设定同步的事件间隔。且发起更新的是系统,不会受到任何限制。
    可是它还是有局限性:
          1. 用户会在系统设置的账户列表里面看到一个不认识的账户;
          2. 同步的事件间隔是有限制的,最短1分钟,见源码,如果小雨60秒,置为60秒。而且各种国产机怎么改的源码我们未可知,是不是都能用仍然未可知;
          3. 很致命,某些手机比如note3需要手动设置账户,你如何骗你的用户给你手动设置账户完了之后不卸载你;
          4. 也很致命,必须联网!google提供这个组件是让你同步账户信息,不联网你同步个鬼,我们要保活,可以不联网不做事,但是不能不联网就死

    9、native层保活(守护进程)

           至于native层保活,一开始是在github上找个这个开源项目的:https://github.com/Coolerfall/Android-AppDaemon
     Demo下载地址:http://download.csdn.net/detail/two_water/9595967
           可是这个只能在5.0以下的使用,更重要的一点是他没有进程守护,然后再寻找资源,找到了下面的这个大神的项目:
     https://github.com/Marswin/MarsDaemon
     Demo下载地址:http://download.csdn.net/detail/two_water/9595966
           这个项目的原理和他的想法都在他的博客有详细的介绍,我这个菜鸟就不作分析了:
           Android 进程常驻(0)----MarsDaemon使用说明:http://blog.csdn.net/marswin89/article/details/50917098
           Android 进程常驻(1)----开篇:http://blog.csdn.net/marswin89/article/details/48015453
           Android 进程常驻(2)----细数利用android系统机制的保活手段:http://blog.csdn.Net/marswin89/article/details/50890708
           Android 进程常驻(3)----native保活5.0以下方案推演过程以及代码详述:http://blog.csdn.net/marswin89/article/details/50899838
           Android 进程常驻(4)----native保活5.0以上方案推演过程以及代码详述:http://blog.csdn.net/marswin89/article/details/50916631
           Android 进程常驻(5)----开机广播的简单守护以及总结:http://blog.csdn.net/marswin89/article/details/50917409
          最后感谢大神,让我学习了!不过建议大家不必要使用常驻进程的软件还是不要使用!影响用户的体验,用来研究玩玩还是可以的!

         pdf:http://download.csdn.net/detail/two_water/9596051

     

    展开全文
  • Android_常驻进程(杀不死的进程)

    万次阅读 2016-08-05 14:38:23
    Android常驻进程,就是要让进程在内存中永远存在,让进程保活,杀死。可能这时都会喷,这不是流氓软件吗?刚接触android的时候,我也是认为这是很流氓的做法,可是慢慢发现很多场景(应用),要为用户服务,就...

                                                                                                      常驻进程

            Android常驻进程,就是要让进程在内存中永远存在,让进程保活,不被杀死。可能这时都会喷,这不是流氓软件吗?刚接触android的时候,我也是认为这是很流氓的做法,可是慢慢发现很多场景(应用),要为用户服务,就必须用到常驻进程,就好像微信,QQ,360安全手机卫士这些现在比较火,比较常用的软件来说,他们都是实现了常驻进程的。所以说,有时候常驻进程在开发中是必须的,比如锁屏应用,就必须在进程中接收锁屏的广播,因此要保证进程常驻,像QQ,微信那些IM类应用,也需要长期在后台维护一个长链接,因此进程常驻又是必须的!

            因为最近开发的应用需要用到常驻进程,因此一开始的猜想在java层是不能解决的,必须得在native解决,可是现在对linux和android系统理解还不够深入,而且ndk开发才刚入门,因此在网上搜了一大堆资料,总得来说,给出的解决方法不就外乎下面的几种:

    1、将Service设置为前台进程
           相关资料和Demo可以查看之前的博客:http://blog.csdn.net/Two_Water/article/details/52084372

           本质是修改了Service所在进程的进程优先级。有了前台进程的优先级,在android系统清理内存的时候,他被杀死的优先级仅高于前台的activity,也就是正在和用户交互的页面,而且使用ddms杀进程他也可以自己启动起来。首先ddms杀进程和在系统设置的正在运行中杀进程本身就不具威胁,在系统设置的所有应用中选择强行停止,仍然可以强停掉,360,cm等软杀更是能轻而易举杀死他。而且他还有一个缺点,在api17以上,设置了一个前台服务,他会以一个无法消除的notification的样式出现在用户的手机状态栏里,大大降低了用户体验。可是前台服务适合做一些音乐播放器,天气类的应用!

    2、在service的onStartCommand方法里返回 STATR_STICK
           主要的几个返回值:
           1. START_STICKY_COMPATIBILITY:START_STICKY的兼容版本,但不保证服务被kill后一定能重启。 
           2. START_STICKY:系统就会重新创建这个服务并且调用onStartCommand()方法,但是它不会重新传递最后的Intent对象,这适用于不执行命令的媒体播放器(或类似的服务),它只是无限期的运行着并等待工作的到来。
           3. START_NOT_STICKY:直到接受到新的Intent对象,才会被重新创建。这是最安全的,用来避免在不需要的时候运行你的服务。
           4. START_REDELIVER_INTENT:系统就会重新创建了这个服务,并且用最后的Intent对象调。等待中的Intent对象会依次被发送。这适用于如下载文件。

           测试的service是一个最基本的service,在相应的生命周期的触发函数上做了输出。在普通的服务使用还是可以的,做常驻进程的话就不行了,force close和一些清理软件很容易就清理掉!

    3、添加Manifest文件属性值为android:persistent=“true”
           app.persistent = true不仅仅标志着此apk不能轻易的被kill掉,亦或在被kill掉后能够自动restart,并且还涉及到了进程的优先级。将被设置为CORE_SERVER_ADJ,此值为-12,而核心进程init的值为-16。当前正在前台运行的进程的值为0。如果应用能设置这个属性,那就真的可以做到保活,因为他真的可以杀不死,像系统的keyguard进程,media进程,且这些进程的adj都是负数,代表了前台activity黑屏了他们也不会死。但是这个属性需要系统shareuid,然后编译不过,因为需要系统签名!
    因此,要弄这个属性需获取两个关键的信息: 
           (1).在apk的AndroidManifest.xml文件中设置android:persistent=true 
           (2).此apk需要放入到system/app目录下,成为一个systemapp

           最主要的是让程序成为系统程序,这个可以做到吗?如果你技术过硬是可以尝试下的!首先弄个自动root的apk,加壳放到程序中,然后程序运行的时候,自动运行自动root的apk,获取root权限,然后在native层中,使用命令的方式把程序移到system/app目录下,成为系统程序!

    4、覆写Service的onDestroy方法

          在设置里面的正在运行,注意是正在运行里面,点击关闭,会走onDestroy回调方法,你在这里可以把自己启动起来。注意是正常关闭的时候是会自己启动起来,可是使用第三方的清理软件360,root过的360,force close这些来搞,压根不会走到onDestory的方法,例子在之前service的博客中也有!可以去试试的!

    5、添加广播监听android.intent.action.USER_PRESENT事件以及其他一些可以允许的事件
           android.intent.action.USER_PRESENT,这是一个android解锁的广播事件。注意,这不是SCREEN_ON\SCREEN_OFF广播,,这不是SCREEN_ON\SCREEN_OFF广播,这不是SCREEN_ON\SCREEN_OFF广播。这是一个可以静态注册的广播。所以在manifest里面注册之后不需要任何前提,理论上用户每次开屏解锁都会触发我们的onReceive事件,在这里我们可以检查进程服务是否在,不在就拉起来。
    但是,这个事件只有解锁才有,如果用户的没有设置锁屏,那么这个事件就是没有的,而且我们的目标是保证进程一直存活,而不是尽可能多的活起来。所以这个当作一个补充的手段也不错,另外所有那些可以静态注册的广播都可以这样搞,前提是你不怕用户看到你申请了好多权限,当然这个USER_PRESENT事件是不需要权限的。
    以下是几个常见可以静态注册的广播
    android.intent.action.USER_PRESENT
    android.net.conn.CONNECTIVITY_CHANGE
    android.intent.action.MEDIA_MOUNTED
    android.intent.action.MEDIA_UNMOUNTED
    android.net.wifi.RSSI_CHANGED
    android.net.wifi.STATE_CHANGE

    android.net.wifi.WIFI_STATE_CHANGED

    6、服务互相绑定

          这个是android里面一个特性,跨进程bind一个service之后,如果被bind的service挂掉,bind他的service会把他拉起来!可以考虑使用远程服务来实现,可是还是不能保活进程,可以被杀掉!

    7、设置闹钟,定时唤醒
          一开始个人认为这个效果还是可以的,个人测试的时候,使用360清理,他是可以保活的,开机也能重启,可是有时会失灵,而且面对force close直接挂掉!具体的例子和实现也就一个监听开机的广播,和一个周期性的闹钟!
    相关的知识点可以看我之前的博客:
    Android_AlarmManager(全局定时器)::http://blog.csdn.net/Two_Water/article/details/52004414
    Android_Service(2)前台服务(service)和远程服务(service):http://blog.csdn.net/Two_Water/article/details/52084372

    Demo的下载地址:http://download.csdn.net/detail/two_water/9595724




    8、账户同步,定时唤醒

          这个是找了很久才发现有这个东西的,android系统里有一个账户系统,设置一个自己的账户,android会定期唤醒账户更新服务,我们可以自己设定同步的事件间隔。且发起更新的是系统,不会受到任何限制。
    可是它还是有局限性:
          1. 用户会在系统设置的账户列表里面看到一个不认识的账户;
          2. 同步的事件间隔是有限制的,最短1分钟,见源码,如果小雨60秒,置为60秒。而且各种国产机怎么改的源码我们未可知,是不是都能用仍然未可知;
          3. 很致命,某些手机比如note3需要手动设置账户,你如何骗你的用户给你手动设置账户完了之后不卸载你;
          4. 也很致命,必须联网!google提供这个组件是让你同步账户信息,不联网你同步个鬼,我们要保活,可以不联网不做事,但是不能不联网就死

    9、native层保活(守护进程)

           至于native层保活,一开始是在github上找个这个开源项目的:https://github.com/Coolerfall/Android-AppDaemon
     Demo下载地址:http://download.csdn.net/detail/two_water/9595967
           可是这个只能在5.0以下的使用,更重要的一点是他没有进程守护,然后再寻找资源,找到了下面的这个大神的项目:
     https://github.com/Marswin/MarsDaemon
     Demo下载地址:http://download.csdn.net/detail/two_water/9595966
           这个项目的原理和他的想法都在他的博客有详细的介绍,我这个菜鸟就不作分析了:
           Android 进程常驻(0)----MarsDaemon使用说明:http://blog.csdn.net/marswin89/article/details/50917098
           Android 进程常驻(1)----开篇:http://blog.csdn.net/marswin89/article/details/48015453
           Android 进程常驻(2)----细数利用android系统机制的保活手段:http://blog.csdn.net/marswin89/article/details/50890708
           Android 进程常驻(3)----native保活5.0以下方案推演过程以及代码详述:http://blog.csdn.net/marswin89/article/details/50899838
           Android 进程常驻(4)----native保活5.0以上方案推演过程以及代码详述:http://blog.csdn.net/marswin89/article/details/50916631
           Android 进程常驻(5)----开机广播的简单守护以及总结:http://blog.csdn.net/marswin89/article/details/50917409
          最后感谢大神,让我学习了!不过建议大家不必要使用常驻进程的软件还是不要使用!影响用户的体验,用来研究玩玩还是可以的!

         pdf:http://download.csdn.net/detail/two_water/9596051








    展开全文
  • 以前看到过别人有遇到一些有关虚拟机的问题:不报任何错误,有时候可以正常使用虚拟机,有时候会遇到在打开的过程中卡死在黑屏处,点击关机没有用,杀进程都杀不死,唯有重启电脑才能解决。 以前觉得这是因为内存...

    以前看到过别人有遇到一些有关虚拟机的问题:不报任何错误,有时候可以正常使用虚拟机,有时候会遇到在打开的过程中卡死在黑屏处,点击关机没有用杀进程都杀不死唯有重启电脑才能解决

    以前觉得这是因为内存不够了(因为遇到问题的那个人的笔记本内存只有4G),没有具体的去找解决方法。

    直到今天我自己换了电脑,32G内存,windows 10 家庭版【注意,是家庭版】,出现了类似的问题。

    问题来了,以前的笔记本,只有12G内存,都能够正常的使用,为什么换了新电脑,反而不行了呢?找了半天问题,原来是因为【家庭版】,以前用的是专业版,没有出现过这种问题,原来是windows10 与 我使用的VMware 版本有概率不兼容,那么就好解决了,更换操作系统(换成win10 专业版),或者更换 VMware版本。

    出现问题的环境:windows 10 家庭版 + VMware 14

    解决问题后的环境:windows 10 家庭版 + VMware 15  (点击获取  kc4m)

     

    更换了VMware版本后,问题解决。

     

    展开全文
  • 双进程守护,驻留,杀不死服务

    千次阅读 2016-07-19 09:33:51
    这是一个轻量级的库,配置几行... master获取root权限下都无法杀死进程 支持系统2.3到6.0 支持大部分设备,包括三星,华为,oppo,nexus,魅族等等 可以简单对开机广播进行保护 github地址: https://github.co

    这是一个轻量级的库,配置几行代码,就可以实现在Android上实现进程常驻,也就是在系统强杀下,以及360获取root权限下,clean master获取root权限下都无法杀死进程

    支持系统2.3到6.0

    支持大部分设备,包括三星,华为,oppo,nexus,魅族等等

    可以简单对开机广播进行保护


    github地址:

    https://github.com/Marswin/MarsDaemon

    原理分析:

    Android 进程常驻(0)----MarsDaemon使用说明

    Android 进程常驻(1)----开篇

    Android 进程常驻(2)----细数利用android系统机制的保活手段

    Android 进程常驻(3)----native保活5.0以下方案推演过程以及代码详述

    Android 进程常驻(4)----native保活5.0以上方案推演过程以及代码详述

    Android 进程常驻(5)----开机广播的简单守护以及总结



    正文:

    Marsdaemon配置需要三步:


    1、明确自己需要常驻的进程service,创建一个和他同进程的receiver,然后在另外一个进程中创建一个service和一个receiver,并写在Manifest中。进程名可以自定义

    见/MarsDaemon/DemoMarsdaemon/src/main/AndroidManifest.xml


    service1是应用中有业务逻辑的需要常驻进程的service,其他三个组件都是额外创建的,里面不要做任何事情,都是空实现就好了


    2、用你的Application继承DaemonApplication,然后在回调方法getDaemonConfigurations中返回一个配置,将刚才注册的进程名,service类名,receiver类名传进来。

    代码/MarsDaemon/DemoMarsdaemon/src/main/Java/com/marswin89/marsdaemon/demo/MyApplication1



    此时如果你想在自己的application里面复写attachBaseContext方法的话,发现他已经被写为final,因为我们需要抢时间,所以必须保证进程进入先加载Marsdaemon,如果你想在attchBaseContext中做一些事情的话,可以复写attachBaseContextByDaemon方法。


    如果你的Application已经继承了其他的Application类,那么可以参考Appliation2,在Application的attachBaseContext的时候初始化一个DaemonClient,然后调用他的onAttachBaseContext同样可以实现,当然了,他同样需要一个配置来告诉他我们刚才在menifest中配的信息

    代码代码/MarsDaemon/DemoMarsdaemon/src/main/java/com/marswin89/marsdaemon/demo/MyApplication2




    3、第三步就是尝试去杀掉进程

    ====

    Android 进程常驻(5)----开机广播的简单守护以及总结


    其实保活就是两个要点:

    1、怎样监听到进程挂掉

    2、怎样把进程拉起来

    把这两个点都解决,问题就解决了。

    大家把我之前的文章都看完,会发现这两个点上都有好多种策略,那么在不同的手机上,两个点的不同策略就有多种组合方式,也也是我适配手机的主要手段。

    当时我适配测试的手机有




    还要说一句,有的手机会在你系统设置force close的时候,显示已经杀掉了进程,但是其实没有真的杀掉,比如魅族。。。

    可以shell进去用命令 ps | grep mars来查看所有MarsDaemon的进程

    如果有root权限,可以使用kill -9命令来杀进程,但是效果没有force close和360\cm 杀的好



    最后要说一下,进程常驻是保证不死,但是首先要活一次才行
    换句话说好多人问我是不是要开机的时候启动一次,怎么启动
    答案肯定是开机广播
    但是现在有第三方软件获取root权限之后可以把我们的开机广播给禁掉,那么MarsDaemon的保护活也就没有意义了

    那么360/cm是怎么禁用我们的广播的呢?

    我们站在他的角度来思考这个问题:

    1、他阻止系统发出开机广播,开机之后立刻注入SystemService

    2、系统发出广播,他让我们收不到

    3、我们收到广播之后,他把我们return掉

    4、他没能return掉我们,但是立马杀掉我们


    ok,第一个太难,如果他能做到,我们没有root所以无解。

    第四个我们没有威胁,因为MarsDaemon就是用来反被杀的

    第三个他要注入我们,可以加壳之类防御

    那么第二个他是怎么做的呢? 系统方法:


    没错,他可以将一个组件设置为enable或者disable,如果把我们的开机广播设置为disable,那么无疑是用不了。

    可是这个他们调用不了的,需要系统签名才行。

    但是他们可以用android shell中的pms 的pm命令达到同样的效果:



    只要有root权限就可以使用这个pm disable componentsName命令。第三方安全软件,我们已经默认他们有root权限了,那么我们该怎么办呢?


    MarsDaemon在工程里面有这样一个类
    /MarsDaemon/LibMarsdaemon/src/main/Java/com/marswin89/marsdaemon/PackageUtils


    是的,因为是我们自己的组件,所以设置他不需要任何权限,只需要在有些时机顺便重置一下开机广播的状态就好(比如每次进程重启的时候,网络变化的时候,开关屏的时候),还有一个就是注册一个关机广播,每次关机的时候重置一下开机广播的状态,从而达到保护开机广播的作用。

    在CleanMaster ,给了root权限之后,禁用开机广播,然后重启手机,开机广播失效;然后加上我的这个方法,再禁用掉,开机广播ok!

    很简单的一个小tip

    =====

     Android 进程常驻(3)----native保活5.0以下方案推演过程以及代码详述


    我们先来讲一下他的方案。

    他是首先开启一个c进程,将需要保活的service名字传递进去


    然后定时给自己主进程发一个intent,如果主进程挂掉了,就可以顺利拉起来保证存活。



    所以他只是一个没有主动权的消息轮询器,说是守护其实很勉强

    而且,这是要建立在保证c进程不挂的基础上,才能轮询,但是就目前来看,只有5.0以下的非国产机才会有这样的漏洞。也就是说在force close的时候,系统忽略c进程的存在,5.0以上包括5.0的哪怕源生系统也会连同c进程一起清理掉,国产机就更不用说了。就算是这样,在5.0以下的非国产机上,如果安装了获取root权限的360\cm的话,也是可以直接清理掉,也就是说会失效。


    而且他不但不算守护,而且还是单向的,也就是说只能a保b,b保不了a;a保b也不是在b死了立刻拉起来,要等到了时间才会去拉。


    最后,就算把刚才说的都排除掉,在很少的一部分手机,也就是低端且没有安装安全软件的手机上,他仍然无法保证时时存活。


    技术关键点:开启native子进程,定时发intent
    结论:单杀可以杀死,force close 5.0以上无效,5.0以下部分手机无效,第三方软件下无效,且无法保证实时常驻





    ==========================分割线=========================






    好了,那么怎样才是双向的守护进程呢?

    第一,如果a守护b,则b挂掉的一瞬间,a就应该把b启动起来
    第二,a和b应该是互相守护,无论谁挂掉,对方就把他拉起来


    那么怎么样才能实现双向守护呢?首先我们想到的是fork这个函数,他会创建一个子进程,然后在父进程中调用waitpid()这个函数,这是一个阻塞函数,他会一直wait到子进程挂掉,才会继续向下执行,利用这个机制,我们可以在主进程的c层fork一个子进程,然后父进程就可以监听到子进程的死亡,死亡的时候再重启子进程。


    似乎可以用这个机制改进刚刚上面分析的那个工程,因为这样的话:1,无法直接杀掉子进程。2、子进程不死,他就会按时发intent给父进程。


    这样做,普通杀是没有问题。但是force close不会按照你的要求先杀孩子,等你把孩子启动起来,再杀父亲,然后坐视子进程在那不管,三方软件自不必说。那么先杀父进程的话,子进程就没办法监听到父进程的死亡吗?


    有朋友要说可以利用linux的进程领养机制,如果父进程挂掉,那么子进程就会被linux的init进程领养,进程所对应的父进程id也会变成1。这的确是一个很好的标示,但是要怎样监听这个状态的变化呢?轮询获取父进程id,然后判断是否等于1?那么轮询的间隔为多少合适?1秒间隔算短算长?设为1秒的话force close掉你的时候,根本不会等到你那每秒正时正点的轮询点上,会被forceclose直接干掉,我试过更短的时间,基本要小到小于10毫秒的时间间隔,才有可能再force close的时候检测到,并成功拉起父进程。注意我的关键词,小于10毫秒!才可能!对,一秒100次的检查,才有可能,只是可能!手机待机十分钟就已经可以开始烫手,三个小时电池发出了低电量警告。代码:


    (代码已经不在工程里面了,工程里的代码删除了好多,做过无数试验)

    技术关键点:fork子进程 ,waitpid监听子进程 ,通过linux进程领养机制监听父进程
    结论:保证单杀存活,保活效果与耗电成正比,得不偿失(5.0以上无效)





    ==========================分割线=========================





    好,我们继续。

    waitpid是阻塞函数,所以他一定是没有耗电问题的,即时性也没有问题。那么问题就集中在了子进程如何监听到父进程的死亡上面,把那个轮询替掉。

    然后,我想到的是管道,linux中有多种ipc通信机制,管道是最基本的一种通信方式,且这种管道只能在父子进程间建立,于是我想是否能利用这个机制呢?在父子进程间建立管道,但是并不写入数据,只是使用阻塞方法在另一端去读取管道,这样如果对方进程挂掉,管道会被破坏,那么另一端的读取方法就会执行返回,由此确定对方挂掉然后重启对方。

    代码:




    这做样确实解决了耗电问题,父子进程两端的监听都是阻塞方法,耗电基本可以忽略不记,也基本实现双向守护。(以上代码不在项目工程里)


    但是问题又来了

    1、用ps命令发现fork出来的进程内存占用很大

    2、fork出来的进程名字与父进程名字相同


    原因:

    1、fork函数调用的时候,会复制父进程的全部内存,因为父进程一定是我们需要保证常驻的Java进程,他在初始化的时候是fork的一个zygote进程,即时在应用刚初始化的时候fork,进程里面是有一个java虚拟机的内存在里面的,最少一二十兆是有了。fork出来子进程多的内存最后都会算到我们自己应用的内存中。

    2、机制如此



    技术关键点:fork子进程 ,waitpid监听子进程, 管道pipe监听父进程
    结论:保证双向守护,无耗电问题,fork出来的进程名字与父进程同名用户体验不好,而且有内存浪费(5.0以上无效)





    ==========================分割线=========================




    我们继续讨论内存的问题,如何不用fork也能建立管道呢。于是我想到了运行一个二进制可执行文件,这样他是一个相对独立的进程,但是又可以建立父子进程之间的管道。将真正用来实现的子进程写到一个二进制文件中(对应文件源码/MarsDaemon/LibMarsdaemon/jni/daemon.c),这样既解决了内存问题,又可以自己给新的进程命名。

    问题解决了吗?没有,直接execute一个binary文件之后

    1、发现代码不再继续向下执行

    2、waitpid又不能用了

    原因和解决方法:

    1、直接运行一个二进制文件,他会占用原进程,于是我们这里仅将fork用作一个启动binary的工具,fork终于回归到了Linus希望他作用的地方

    2、父子进程间的管道是单向的,于是我们可以建两根管道。ab两个进程,建12两个管道。a进程关掉管道1的写端,堵瑟调用管道2的读取方法;b进程关掉管道2的写端,堵瑟调用管道1的读取方法。这样就可以实现双向监听。任何一方监听到对方死掉就作出相应的动作,启动对方。至此,完全摒弃开始的fork方案。


    代码:

    此为最终方案,代码见下


    技术关键点:双管道互相监听
    结论:保证双向守护,无耗电问题,无内存问题,进程名自定义(5.0以上无效)




    ==========================分割线=========================


    好了,这就是我5.0以下的最终解决方案

    下面讲一下代码

    二进制文件存放在assets下面,程序第一次启动的时候会将他拷贝到手机项目/data/data/...下,然后

    源码/MarsDaemon/LibMarsdaemon/src/main/java/com/marswin89/marsdaemon/strategy/DaemonStrategyUnder21.java


    load对应c库,执行代码

    源码/MarsDaemon/LibMarsdaemon/jni/daemon_api20.c



    1、将对应的packagename,servicename以及二进制可执行文件的路径传进来

    2、清理僵尸进程,就像最开始讲的,低端手机会忽略c进程,如果我们恰巧运行在低端手机上,那么c进程得不到释放会越来越多,我们称他为僵尸进程,需要清理一下

    3、建立两条管道

    4、执行二进制文件,将上面的参数传递进去

    5、然后关掉自己管道1的写端和管道2的读端,然后阻塞读取管道1,如果读取到,则代表子进程挂掉


    再来看二进制可执行文件的代码

    源码/MarsDaemon/LibMarsdaemon/jni/daemon.c




    二进制文件在程序启动起来的时候,将参数解析出来

    关掉管道1的读端和管道2的写端,然后调用管道2的阻塞读取方法,如果执行过去,说明父进程死掉

    这里用fork是为了让他的父进程id好看一些,别无他意

    监听到之后的策略看下面。


    ==========================分割线=========================



    然后说一下监听到对方进程死后的策略

    你会说谁监听到对方死了,就直接拉起来就好了呀。

    问题:

    1、重新拉起来要重新建立双管道,子进程挂掉,父进程把他重启起来建立双管道还好说,如果父进程挂掉,子进程把父进程启动起来,他们之间就无法建立连接,而且如果中间出了差错,同步起来很费劲,于是我选择,无论谁监听到谁死了,都重启对方,然后自杀,重新初始化!

    2、如果执行force close, 系统先杀父进程,子进程监听到之后拉起父进程然后自杀,但是系统杀你两个进程的间隔时间非常非常短,父进程刚起来还没来得及初始化,系统赶过来杀父进程。有的手机强杀之后很短一段时间无法拉起父进程。于是我选择用第三个进程。

    第三个进程和之前的父子进程都没有任何关系,他的作用只是用做拉起常驻进程。父子进程无论谁监听到谁死,都拉起第三个进程,第三个进程负责拉起常驻进程,然后自杀。(用户实际上是看不到他的存在的,因为他可能只存活不到一秒就自杀了)

    代码

    /MarsDaemon/LibMarsdaemon/src/main/java/com/marswin89/marsdaemon/strategy/DaemonStrategyUnder21.java


    在常驻进程初始化的时候,初始化一个alarm,保存在内存中,以便以后使用


    监听到子进程死了时候使用闹钟拉起第三个进程,二进制文件监听到父进程死掉,直接用c代码发intent,见上面c代码


    第三进程启动起来,就是负责把常驻进程拉起来,然后自杀掉。






    ==========================分割线=========================





    好了,这只是5.0以下的策略,5.0以上,以及6.0都不好用

    下一篇我们开始分析5.0+的策略


    ========

     Android 进程常驻(4)----native保活5.0以上方案推演过程以及代码详述


    上一篇我们通过父子进程间建立双管道,来监听进程死掉,经过测试,无耗电问题,无内存消耗问题,可以在设置中force close下成功拉起,也可以在获取到root权限的360/cleanmaster下成功存活。


    可是放到5.0+的系统就不能用了,为什么呢?我们来看源码4.4系统和5.0系统在系统force close的时候都做了什么修改。


    4.4.3的ActivityManagerService

    实现在这里



    然后5.0的AMS



    实现




    可以看出来5.0的源码中系统强杀的时候会连同同group中的所有进程也一起干掉,使用上一篇的策略通过打印log我们也可以看出,在父进程被杀死的时候,子进像是被冻结了一样,做不了任何事情,拿不到监听事件。那么我们该怎么办呢?

    开始自己头脑风暴,想出以下几种解决策略:


    1、放弃Java进程,使用两个纯native的binary进程,相互保活,确保native进程常驻,然后按时拉起需要常驻的java进程。

    2、使用setsid将子进程的session改变,是否可以让系统不冻结子进程。

    3、子进程创建子进程,然后自杀,重复1000次,也就是父进程和自己子进程的子进程的子进程重复一千遍的进程之间互保,是否可以让系统不冻结子进程


    经过代码尝试,结果你可以猜到,没错,然并卵。这几种方案都无法阻挡系统的force close,就更不用说360/cm with root了。


    于是换一个思路,不再纠结于父子进程,而是两个普通进程之间是否能互保


    鉴于之前pipe管道的使用,首先想到的是fifo管道,这是linux下可以建立在两个没有关系的进程间的双向管道。同样两个进程间在c层建立fifo管道,然后阻塞读取。可问题在于,这个fifo与pipe是有本质区别的,fifo是通过一个文件做通信的,对方进程挂掉之后,自己这边既不会报错也不会返回,而是一直阻塞,直到管道里面有数据。所以,然并卵。


    那么,当进程死的时候,自己往管道里面写数据,另一边阻塞读到数据不就可以得知这边死掉了吗?当时确实有这样一瞬间的可笑想法,但是这要首先要自己知道自己的死亡啊。


    这个可笑的想法没有什么意义,但是他启发了我,当一个进程死掉的时候,他和另一个进程之间的什么会发生变化呢?


    顺着这个思路,我想到了文件锁。不论windows还是linux都会有一套文件的进程同步机制,为了各个进程间文件的同步问题,一个进程可以给一个文件上锁,操作完了之后再解锁,其他进程如果担心同步问题,会首先检查一下文件是否有锁,如果有锁,代表别人正在操作,就会延迟对文件的操作。那么当一个进程挂掉,他给文件加的锁也自然会消失。


    于是按照这个思路,进程a给文件1加锁,然后阻塞读取文件2的锁,进程b给文件2加锁,然后阻塞读取文件1的锁,如果对方进程挂掉,他所在进程所持有的文件锁会立即释放,那么另一个进程就可以读取到被释放文件锁的文件,监听到对方挂掉。


    实现这个方案,首先使用的java代码,java里是有一套文件锁的api的,但是写完之后编译时报错。我就不写demo截图了,错误的信息是死锁exception,两个进程不能互相持有对方的锁。java的编译器可真多事儿,于是我想能不能用三个进程,1拿2的锁,2拿3的锁,3拿1的锁,还是不行,deadlock exception.


    怀着忐忑的心情我用c来实现尝试,庆幸的是c中没有问题。原理通了,剩下的就是把代码写健壮,最难搞的问题就是同步问题,ab两个进程,如果b进程还没给文件加锁,a就开始读锁,那么就会误以为b进程挂掉了。需求:
    1、需要让a进程先把文件1锁了,然后不去读文件2,等b进程做同样的操作之后,两边再同时读取对方的锁。
    2、需要考虑第程序重新进入的初始化状态与单个进程等待的状态冲突问题
    3、不能耗时!!时间很重要,后面会说到


    这一块确实想了一晚上才想出来合适的解决方案,首先肯定不能用管道、信号这些进程间通信,连memset都不要考虑,因为耗时,java层的机制就更不用考虑了!那么就只能用一些标示位手段,比如一个文件在了就代表一个进程在了,一个文件没了,就代表一个进程锁好了。
    于是最后的同步方案是:

    1、4个文件,a进程文件a1,a2,b进程b1,b2


    2、a进程加锁文件a1,b进程同理


    3、a进程创建a2文件,然后轮询查看b2文件是否存在(这里可以轮询,因为时间很短),不存在代表b进程还没创建,b进程同理


    4、a进程轮询到b2文件存在了,代表b进程已经创建并可能在对b1文件加锁,此时删除文件b2,代表a进程已经加锁完毕,允许b进程读取a进程的锁,b进程同理


    5、a进程监听文件a2,如果a2被删除,代表b进程进行到了步骤4已经对b1加锁完成,可以开始读取b1文件的锁(不能直接监听a2文件删除,也就是不能跳过34步,这也是最难想的一部分,如果那样可能此时b进程还没创建,和b进程创建完成并加锁完成的状态是一样的,就会让进程a误以为进程b加锁完成),b进程同理




    看代码
    /MarsDaemon/LibMarsdaemon/jni/daemon_api21.c


    其中a和b两个进程都会执行这块代码,对于a进程来说,indicator_self_path对应a1,indicator_daemon_path对应b1,observer_self_path对应a2,observer_daemon_path对应b2,b进程同理

    首先自己加锁,然后加入同步模块notify_and_waitfor


    以上代码就是上述同步逻辑

    同步完成后,两个进程同时监听对方的锁,一方挂掉另一方立刻可以监听到。这套方案在5.0+上可以做到互相监听对方死亡状态,因为都是阻塞方法,所以无耗电效率问题。

    这里要说一下,也许你看完源码你会问为什么步在5.0以下采用这种方案,因为这种方案是需要挂两个进程的,虽然与父子进程相比,在linux下都是两个进程两个pid,但是在android系统的设置里面,父子进程中的native进程是android系统统计不到的,所以不会列出来,不会让用户觉得你为啥启这么多进程。所以从用户体验角度,5.0以下还是采用上一篇博文采用的方案。



    ok,监听成功,对方死亡就把对方拉起来,然后自杀,重新初始化。把方案替换进来之后发现5.0是ok的,360/cm with root也是ok的,但是在5.1又失效了。为什么?


    打印log我们发现,5.1上监听死亡状态是ok的,但是却无法将对方拉起来。


    好了,我们要开始第二个重点了,那就是如何启动对方。


    原先我们的方案是用一个闹钟启动对方,但是在5.1上,闹钟在force close之后,闹钟同样会被废掉,之前的拉起方案行不通了,那么开始想如何将对方的进程拉起来,想了很久也没有相出什么别的方法,发送intent似乎根本不执行,但是此时这种情形只能继续研究发的intent为什么没有执行。


    通过打印log,我们才发现,force close的时候,系统杀应用对应进程的时候,速度非常快,在a进程监听到b进程被杀的时候,系统的死亡镰刀已经伸向了a进程,大概只有几十毫秒的时间!而发送一个intent我们知道他是在自己进程中使用系统ActivityManagerService的一个代理类,通过一个binder将intent传给系统,虽然大部分操作是在ams中,但是我们这边执行时间居然也在百毫秒级的,难怪intent发不出去。


    所以时间很重要!!!我们要跟系统抢时间



    那么现在的问题是怎样才能把intent发出去,查看源码,我们可以看出intent的发送实际上是ActivityManagerNative这个类,他持有一个binder,用来与系统的ActivityManagerService通信,然后我们发送intent的时候会初始化一个Parcel,通过binder transcate过去。



    时间都消耗在了pacel的创建上。

    那么我们可不可以把这些耗时操作放在进程开始的时候就完成,等到监听到进程挂掉,直接调用。

    但是那个binder我们没法直接拿到,这里需要用到反射。

    看代码:


    代码com.marswin89.marsdaemon.strategy.DaemonStrategy22.java



     拿到ActivityManagerNative实例然后拿binder,也就是他的一个成员变量mRemote




      然后把Pacel初始化出来,这里注释掉的是我一行一行试验的,为了节省时间,在能达到目的的前提下,时间越少越好,所以参数能少传就少传。




    然后在检测到对方进程死掉的时候,直接调用transcate方法。




    ok,5.1上也可以实现双向守护。

    但是很遗憾,6.0上又跪了。

    然后经过排查,发现通过以上方式用binder transcate的方法无法启动一个service。那该怎么办呢?抱着试试看的心里尝试了broadcastreceiver,果然广播是可以的。同样的原理用ActivityManagerNative中的binder transcate一个pacel来启动一个broadcast拉起进程。

    也是仿照系统源码来做的广播的Pacel

    代码com.marswin89.marsdaemon.strategy.DaemonStrategy22.java



    ok,6.0也搞定。

    在系统force close时成功拉起对方,但是在360\clean master with root的强杀下仍然有一定的几率会跪。通过log可以看出来,在一键清理的时候是有成功拉起的,但是360\cm均会重复杀,被拉起来的新进程还没初始化完成,就又被杀掉了。



    再次,时间很重要!!!我们要跟360\cm抢时间


    这里我们在进程刚创建的时候使用多线程,将文件的同步加锁监听与启动另一个进程同时进行,从来能节约100毫秒左右的时间



    大功告成!


    从5.0到6.0,在force close和360\cm with root的一键清理下都可以实现互相守护了。


    =======

    展开全文
  • 以前看大神的博客,都说没有碰到过内存泄漏或者...(开机自启,现在大概也就只有在ARM板的原生系统里实现了…后面的杀不死的后台Service也是在原生系统上实现的)遇到的问题:app开机自启,跑了7,8个小时后app挂掉了 一
  • 杀不死进程的原因--僵尸进程的解决.txt 作者Attilax 艾龙, EMAIL:1466519819@qq.com 来源:attilax的专栏 地址:http://blog.csdn.net/attilax 1. 产生原因:  在UNIX 系统中,一个进程结束了,...
  • =====四、没有银弹,或人狼杀不死=====人狼这个动物很奇怪,皮肉坚实还是自疗系的,所以要么砍它不动,要么杀它不死。这种动物如同习得(传说中的)金钟罩功夫,刀枪不入,水火不怕。也如同金钟罩有罩门...
  • android 进程防止被杀死

    千次阅读 2016-05-27 17:13:28
    每个公司都想把自己的app时时刻刻运行在用户的手机上面,就算当用户点击清理应用时,也能够杀死。...微信,QQ,这类是怎么实现的,为什么只有这几个特别有名的app才能够实现杀死的呢?如果是说是什么特
  • =====前言=====在这与这段文字之前,我已经阅读过种种关于《人月神话》的文字。...阅读这些文字给我带来的收获是:面对《人月神话》,除了表示五体投地的诚服,能做正面言论(那是多余),也
  • 杀死线程

    千次阅读 2019-04-16 20:18:19
    当我们使用多个线程,去访问一个共享对象时,可避免的要使用锁来做线程同步(当然了,可以说用 lock-free ,但lock-free并是万金油,在逻辑上必须进行条件等待的时候还是得乖乖等待)。 当我们的一个线程...
  • CMD杀死进程

    千次阅读 2016-11-16 09:22:35
    /T Tree kill: 终止指定的进程和任何由此启动的子进程。 /? 显示帮助/用法。 4.例 taskkill /im notepad.exe–结束了记事本的进程, 也可以 taskkill /pid 608来结束进程。 im参数后面使用进程名. ...
  • 杀不死的人狼——我读《人月神话》(五)

    千次阅读 热门讨论 2007-03-16 01:17:00
    因为大家离本质的东西都很远,又从不同的角度去看这本质,故而得到的答案并相同——而且每一种答案都貌似正确。 但是我问的是“本质需求”。对此,我的答案是:本质需求是“实现(工程的目标)”。   不管工程...
  • =====  三、《人月神话》是预言了未来...然而我认为真正的可怕之处在于:如今只要论及工程(且不要让人认为是离经叛道),那么所讲述的一定是Brooks的这样的经验以及由此推出的观点,或者在违背这些经验和观
  • Service是在一段不定的时间运行在后台,和用户交互应用组件。每个Service必须在manifest中 通过来声明。可以通过contect.startservice和contect.bindserverice来启动。和其他的应用组件一样,运行在进程的主线程中...
  • linux杀死进程的五种方法

    万次阅读 多人点赞 2017-12-26 10:47:19
    方法一: Terminal终端输入: gnome-system-monitor,就可以打开system monitor 如图: 然后找到相应进程,右击选择...首先需要知道进程id, 例如,想要杀死firefox的进程,通过 ps -ef|grep firefox,可以查到firefox的进程
  • Activity杀死进程退出

    千次阅读 2014-12-21 14:49:46
    应用程序在退出杀死进程的时候,使用 1 finish();---------------关闭Activity 2 system.exit(0);----------------退出java虚拟机,每一个安卓程序打开的同时都会产生一个java虚拟机; 3 android.os....
  • Mac 查看端口占用情况及杀死进程

    万次阅读 2019-03-25 15:55:23
    在开发中经常会遇到端口占用问题,例如下面, npm start 报的错误: 1. 查看端口占用情况命令 ...在linux环境下,任何事物都以文件的形式存在 ...通过文件仅仅可以访问...,然后就是如何杀死进程: kill 11649
  • Kill杀死进程方法大全

    万次阅读 2018-11-17 18:49:43
    Kill杀死进程方法大全
  • android如何让service杀死

    千次阅读 2013-02-18 22:34:48
    ...android如何让service杀死 参考链接:http://www.eoeandroid.com/thread-120983-1-1.html 注:本文代表个人观点,仅是网上搜集的资料,在此做个笔记。 1.在service中重写下面的
  • 如何让service杀死

    千次阅读 2013-12-04 11:49:54
    但是如果某个进程想被杀死(如数据缓存进程,或状态监控进程,或远程服务进程),应该怎么做,才能使进程杀死。 add android:persistent="true" into the <application> section in your AndroidManifest....
  • Android Service服务如何杀死

    万次阅读 2017-02-11 16:38:29
    第一章 Service介绍service服务是一个应用程序的四大组件之一,可以再后台执行长时间运行的操作,提供用户界面。一个应用程序组件可以启动一个服务,它将继续在后台运行,即使用户切到另一个应用程序。此外,一个...
  • android如何保证service杀死

    万次阅读 2015-03-16 09:33:41
    Android开发之如何保证Service掉(broadcast+system/app) http://blog.csdn.net/mad1989/article/details/22492519 序言 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,...
  • 如何保证Service在后台杀死

    千次阅读 2018-03-27 21:27:26
    一、前期基础知识储备(1)为什么要保证后台Service杀死?提高应用存在感。对于大厂的应用来说,其程序“活着”不是问题,但是为了带来更好的用户体验,提高用户粘性,就需要尽可能调用程序更多的服务,这样才能...
  • 杀死linux的僵尸进程

    千次阅读 2011-05-28 16:24:00
    linux并把进程的树形结构导出给...记住:任何没有人为因素的纯技术问题都是可以解决的!如何操作呢?很简单,就三步:1.将僵尸进程从树形进程组织中摘除; 2.将僵尸进程过继给一个特定的进程; 3.该特定进程调用wai

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 89,247
精华内容 35,698
关键字:

任何杀不死你的