进程也想长生不死

想要一个进程永远的活着不被kill掉，这个观点备受驳议。对于开发来说，想要实现的一些需求，保证消息的到达率，这一项的实现是无可厚非；对于用户来说，被不知名的服务一直生存在我的后台进程。就像隔壁老王在藏在衣柜里偷偷输出，是不是很难受！有些进程，又不能强制用户给你加入白名单，那能怎么办呢？只能用一些黑科技了。

---

但是Android系统中在没有白名单的情况下做一个任何情况下都不被杀死的应用是基本不可能的，只能大幅度提高进程的存活率。强制性的流氓手段，有些不道德。更何况我也不会QAQ～ 我也只不过看了大牛们的技术博客，自己写几个demo，演示记录一下而已。 #进程的级别 首先，要了解进程的级别。Android的应用中，进程可分为：

1. 前台进程，在手机页面可被看见的。如：正在被onResume()的Activity；绑定该Activity的Service；正执行其 onReceive()的BroadcastReceiver。
2. 可见进程，虽然可被看见，但是在执行onPause()方法中Activity。如：弹出dialog被遮挡的Activity；绑定该Activity的Service也级别也随之降低。
3. 服务进程，独立于应用的进程或者是私有进程，且正在运行 startService() 方法启动的服务。
4. 后台进程，不可见Activity，执行了onStop()方法。
5. 空进程，不包含任何活跃的应用组件的进程

   

   （盗用一下网上的图） 对应的不同级别的进程，系统都有一个oom_adj的值来标识，不同进程的级别高低。

   

   绿色标识不容易被系统回收的进程。系统当处于内存紧缺时候，需要通过Lowmemorykiller ，kill掉一些对系统来说无关紧要的进程。斩杀的规则就是，根据oom_adj大小。从最大的开始，当两个oom_adj大小一样时，先kill占用内存大的那个。 #ADB Shell使用 哇，第一次使用adb命令，感觉low爆了。要看进程活着还是死的，总得有个地方可以查看的嘛。原来Android Studio 命令框可以这么用的。用真机调试时候，adb shell 进入的并不是root，对应的角标“$”，其权限也只能看到对应进程的列表，只有手机root之后或者用模拟器才能看到进程的详细信息。角标也是“#”

   

   可以通过 cat /proc/进程id/oom_adj 来查看。返回了一个值，对应上面那张表，可直接看出对应的进程所处在的级别。我们要做的是，对我们需要的进程，希望在其被置为不可见时候，其进程级别不会被降低，或者说不被降很多。所以也就有了一下的“黑科技”。

#一个像素的Activity 这个方法，好像在网上已经人尽皆知了的样子。实现原理，也就是监听手机屏幕的开启和关闭，来打开和关闭这个1像素的Activity。这个需求只能做到，屏幕熄黑后，进程的级别不会被降低。

//屏幕点亮关闭监听
interface ScreenStateListener {
        void onScreenOn();
        void onScreenOff();
    }
    /**
     * screen状态广播接收者
     */
    private class ScreenBroadcastReceiver extends BroadcastReceiver {
        private String action = null;
        @Override
        public void onReceive(Context context, Intent intent) {
            action = intent.getAction();
            if (Intent.ACTION_SCREEN_ON.equals(action)) { // 开屏
                mListener.onScreenOn();
            } else if (Intent.ACTION_SCREEN_OFF.equals(action)) { // 锁屏
                mListener.onScreenOff();
            }
        }
    }

这个是1像素Activity创建的管理类。因为该Activity频繁被创建和销毁，所以将其放置弱引用堆栈里，便于内存回收。

public class ScreenManager {

    private Context mContext;

    //弱引用，LiveActivity在应用可视下finish，创建频繁
    private WeakReference<Activity> mActivityWref;

    public static ScreenManager gDefualt;

    public static ScreenManager getInstance(Context pContext) {
        if (gDefualt == null) {
            gDefualt = new ScreenManager(pContext.getApplicationContext());
        }
        return gDefualt;
    }
    private ScreenManager(Context pContext) {
        this.mContext = pContext;
    }

    public void setActivity(Activity pActivity) {
        mActivityWref = new WeakReference<Activity>(pActivity);
    }

    public void startActivity() {
        LiveActivity.actionToLiveActivity(mContext);
    }

    public void finishActivity() {
        //结束掉LiveActivity
        if (mActivityWref != null) {
            Activity activity = mActivityWref.get();
            if (activity != null) {
                activity.finish();
            }
        }
    }
}

LiveService 的具体操作，在应用的进程开启时候同时开启这个Service，对屏幕关闭开启进行监控

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        //屏幕关闭的时候启动一个1像素的Activity，开屏的时候关闭Activity
        final ScreenManager screenManager = ScreenManager.getInstance(LiveService.this);
        ScreenBroadcastListener listener = new ScreenBroadcastListener(this);
        listener.registerListener(new ScreenBroadcastListener.ScreenStateListener() {
            @Override
            public void onScreenOn() {
                screenManager.finishActivity();
            }
            @Override
            public void onScreenOff() {
                screenManager.startActivity();
            }
        });
        return START_REDELIVER_INTENT;
    }

主要的原理就熄屏时候，偷偷的开启着一个无界面的Activity，来告诉手机我这个进程是活跃着的。在屏幕亮起时候，则销毁这个Activity，由现有的界面UI取代。但是我发现当应用被置于后台后，应用的oom_adj直接变为6（后台进程），所以满足不了进程级别一直保持。我也很可爱的，在程序进入后台也开启这个1像素，我在Application生命周期中，对这个Activity进行一样的操作。奈何。。当我进入后台后，过了一会，app又被重新拉起，显示在页面。关不掉了哈哈～

  @Override
    public void onCreate() {
        super.onCreate();
        registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {
            @Override
            public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
            }

            @Override
            public void onActivityStarted(Activity activity) {
                final ScreenManager screenManager = ScreenManager.getInstance(this);
                screenManager.finishActivity();

            }
                        
            @Override
            public void onActivityResumed(Activity activity) {

            }

            @Override
            public void onActivityPaused(Activity activity) {

            }

            @Override
            public void onActivityStopped(Activity activity) {
               screenManager.startActivity();                   
            }
            @Override
            public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
            }
            @Override
            public void onActivityDestroyed(Activity activity) {

            }
        });
    }

既然不能满足，那只能换种方法思路。。。。。 #设置为前台服务 据说微信用的是这个方案，实现原理是利用了Android的前台漏洞。对API<180时，调用startForeground(ID， new Notification())，这样就不就有有图标显示。在API>18时，需要调用一个辅助的Service，绑定同一个ID，然后并且stop 这个辅助Service，这样通知栏也不会有任何显示

public class KeepLiveService extends Service {

    public static final int NOTIFICATION_ID=0x11;

    public KeepLiveService() {
    }

    @Override
    public IBinder onBind(Intent intent) {
        throw new UnsupportedOperationException("Not yet implemented");
    }

    @Override
    public void onCreate() {
        super.onCreate();
         //API 18以下，直接发送Notification并将其置为前台
        if (Build.VERSION.SDK_INT <Build.VERSION_CODES.JELLY_BEAN_MR2) {
            startForeground(NOTIFICATION_ID, new Notification());
        } else {
            //API 18以上，发送Notification并将其置为前台后，启动InnerService
            Notification.Builder builder = new Notification.Builder(this);
            builder.setSmallIcon(R.mipmap.ic_launcher);
            startForeground(NOTIFICATION_ID, builder.build());
            startService(new Intent(this, FuZhuService.class));
        }
    }
}

public  class  FuZhuService extends Service{
        @Override
        public IBinder onBind(Intent intent) {
            return null;
        }
        @Override
        public void onCreate() {
            super.onCreate();
            //发送与KeepLiveService中ID相同的Notification，然后将其取消并取消自己的前台显示
            Notification.Builder builder = new Notification.Builder(this);
            builder.setSmallIcon(R.mipmap.ic_launcher);
            startForeground(NOTIFICATION_ID, builder.build());
            new Handler().postDelayed(new Runnable() {
                @Override
                public void run() {
                    stopForeground(true);
                    NotificationManager manager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
                    manager.cancel(NOTIFICATION_ID);
                    stopSelf();
                }
            },100);
        }
    }

最后当应用点击后退后，退置后台时候，该应用的进程保持0变为1的程度，也就保证了进程的存活率

#系统自带的服务 在Service的onStartCommand方法中返回一个整型，系统识别这个整型，进行判断，如果被kill将会进行说明操作。

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    return START_REDELIVER_INTENT;
}

• START_STICKY 如果系统在onStartCommand返回后被销毁，系统将会重新创建服务并依次调用onCreate和onStartCommand（注意：根据测试Android2.3.3以下版本只会调用onCreate根本不会调用onStartCommand，Android4.0可以办到），这种相当于服务又重新启动恢复到之前的状态了）。

• START_NOT_STICKY 如果系统在onStartCommand返回后被销毁，如果返回该值，则在执行完onStartCommand方法后如果Service被杀掉系统将不会重启该服务。

• START_REDELIVER_INTENT START_STICKY的兼容版本，不同的是其不保证服务被杀后一定能重启。

使用后好像不怎么灵巧，保留使用。。。。 #总结

总结一波，作为一个有情怀的开发者，我们都知道每当用户关闭一个程序时，我们的程序就应该彻底地死去并释放其所占用的系统资源，这个浅显的道理不仅适用于我们移动应用开发，也适用于任何桌面程序的开发。

但是作为开发者，我们更多的是面对产品经理开发，针对各种市场资源需要，总会想尽办法。对于常驻型进程，在使用的时候，还是得三四而后行。当然特殊需求可以特殊考虑，为了用户体验更好的是没话说的。 这篇文章更多的是站在网上各路大牛们的基础上阅读，尚未达到创造的级别。慢慢努力。自此，感谢网上的大们牛写的黑科技1 黑科技2