Android实现双进程守护

如何保证Service不被Kill

有关Service的知识请参考Android Service全面解析这篇文章，写的很详细。

（1）onStartCommand方法，返回START_STICKY

@Override  
public int onStartCommand(Intent intent, int flags, int startId) {  
    flags = START_STICKY;  
    return super.onStartCommand(intent, flags, startId);  
}  

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

正常运行：

杀进程：

进程自动重启：

重启成功：

（2）Application加上Persistent属性
看Android文档知道，当进程长期不活动，或系统需要资源时，会自动清理门户，杀死一些Service，和不可见的Activity等所在的进程。但是如果某个进程不想被杀死（如数据缓存进程，或状态监控进程，或远程服务进程），可以这么做：

"true"  
    android:icon="@drawable/ic_launcher"  
    android:label="@string/app_name"  
    android:persistent="true" //设置Persistent
    android:theme="@style/AppTheme" >  
</application>

据说这个属性不能乱设置，不过设置后，的确发现优先级提高不少，或许是相当于系统级的进程，但是还是无法保证存活。

（3）提升service优先级
在AndroidManifest.xml文件中对于intent-filter可以通过android:priority = “1000”这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时适用于广播。

<service  
    android:name="com.hx.doubleprocess.MyService"  
    android:enabled="true" >  
    <intent-filter android:priority="1000" >  
        <action android:name="com.hx.myservice" />  
    intent-filter>  
service>

目前看来，priority这个属性貌似只适用于broadcast，对于Service来说可能无效。

（4）提升service进程优先级
Android中的进程是托管的，当系统进程空间紧张的时候，会依照优先级自动进行进程的回收。Android将进程分为5个等级,它们按优先级顺序由高到低依次是：

• 前台进程 Foreground process
• 可见进程 Visible process
• 服务进程 Service process
• 后台进程 Background process
• 空进程 Empty process

当service运行在低内存的环境时，将会kill掉一些存在的进程。因此进程的优先级将会很重要，可以使用startForeground 将service放到前台状态。这样在低内存时被kill的几率会低一些。

@Override  
    public void onCreate() {  
        super.onCreate();
        Intent notificationIntent = new Intent(this, MainActivity.class);  
        PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, notificationIntent, PendingIntent.FLAG_UPDATE_CURRENT);  
        Notification notification = new Notification.Builder(this)
            .setSmallIcon(R.drawable.ic_launcher)
            .setWhen(System.currentTimeMillis())
            .setTicker("有通知到来") 
            .setContentTitle("这是通知的标题") 
            .setContentText("这是通知的内容")
            .setOngoing(true)
            .setContentIntent(pendingIntent)
            .build();
        /*使用startForeground,如果id为0，那么notification将不会显示*/
        startForeground(1, notification);
    }

注意在onDestroy里还需要stopForeground(true)。
如果在极度极度低内存的压力下，该service还是会被kill掉，并且不一定会restart。

（5）onDestroy方法里重启service
service +broadcast 方式，就是当service走ondestory的时候，发送一个自定义的广播，当收到广播的时候，重新启动service；

<receiver android:name="com.hx.doubleprocess.BootReceiver" >  
    <intent-filter>  
        <action android:name="android.intent.action.BOOT_COMPLETED" />  
        <action android:name="android.intent.action.USER_PRESENT" />  
        <action android:name="com.hx.destroy"/> //这个就是自定义的action  
    intent-filter>  
receiver> 

在onDestroy时：

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

在BootReceiver里：

public class BootReceiver extends BroadcastReceiver {    
    @Override  
    public void onReceive(Context context, Intent intent) {  
        if (intent.getAction().equals("com.hx.destroy")) {  
            //在这里写重新启动service的相关操作  
            startUploadService(context);  
        }    
    }    
}  

也可以直接在onDestroy()里startService：

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

当使用类似360管家等第三方应用或是在setting里-应用-强制停止时，APP进程可能就直接被干掉了，onDestroy方法都进不来，所以还是无法保证。

（6）监听系统广播判断Service状态
通过系统的一些广播，比如：手机重启、界面唤醒、应用状态改变等等监听并捕获到，然后判断我们的Service是否还存活，别忘记加权限啊。

<receiver android:name="com.hx.doubleprocess.BootReceiver" >  
    <intent-filter>  
        <action android:name="android.intent.action.BOOT_COMPLETED" />  
        <action android:name="android.intent.action.USER_PRESENT" />  
        <action android:name="android.intent.action.PACKAGE_RESTARTED" />  
        <action android:name="com.hx.destroy" />
    intent-filter>  
receiver> 

BroadcastReceiver中：

@Override  
public void onReceive(Context context, Intent intent) {  
    if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) {  
        System.out.println("手机开机了....");  
        startUploadService(context);  
    }  
    if (Intent.ACTION_USER_PRESENT.equals(intent.getAction())) {  
        startUploadService(context);  
    }  
}  

这也能算是一种措施，不过感觉监听多了会导致Service很混乱，带来诸多不便。

（7）将APK安装到/system/app，变身系统级应用
这种方式适合调试来用，并不算是一种解决办法，不推荐使用，因为你的APP是给用户使用的。
需要root权限的手机，将APK文件拷贝到/system/app目录下，重启手机。设置-应用程序管理，可以看到我们的APP已经无法卸载了，只能停用。系统级的APP，这样一些第三方的管家软件，就无法杀掉我们，除非自己把APP停用掉，或是强制停止。
即使成为系统应用，被杀死之后也不能自动重新启动。但是如果对一个系统应用设置了persistent=”true”，情况就不一样了。实验表明对一个设置了persistent属性的系统应用，即使kill掉会立刻重启。一个设置了persistent=”true”的系统应用，在android中具有core service优先级，这种优先级的应用对系统的low memory killer是免疫的！

双进程守护

如果从进程管理器观察会发现新浪微博、支付宝和QQ等都有两个以上相关进程，其中一个就是守护进程，由此可以猜到这些商业级的软件都采用了双进程守护的办法。

什么是双进程守护呢？顾名思义就是两个进程互相监视对方，发现对方挂掉就立刻重启！不知道应该把这样的一对进程是叫做相依为命呢还是难兄难弟好呢，但总之，双进程守护的确是一个解决问题的办法！相信说到这里，很多人已经迫切的想知道如何实现双进程守护了。这篇文章就介绍一个用NDK来实现双进程保护的办法，不过首先说明一点，下面要介绍的方法中，会损失不少的效率，反应到现实中就是会使手机的耗电量变大！但是这篇文章仅仅是抛砖引玉，相信看完之后会有更多高人指点出更妙的实现办法。

需要了解些什么？
这篇文章中实现双进程保护的方法基本上是纯的NDK开发，或者说全部是用C++来实现的，需要双进程保护的程序，只需要在程序的任何地方调用一下JAVA接口即可。下面几个知识点是需要了解的：

• 1.linux中多进程；
• 2.unix domain套接字实现跨进程通信；
• 3.linux的信号处理；
• 4.exec函数族的用法；

其实这些东西本身并不是多复杂的技术，只是我们把他们组合起来实现了一个双进程守护而已，没有想象中那么神秘！在正式贴出代码之前，先来说说几个实现双进程守护时的关键点：

• 1.父进程如何监视到子进程（监视进程）的死亡？
  很简单，在linux中，子进程被终止时，会向父进程发送SIG_CHLD信号，于是我们可以安装信号处理函数，并在此信号处理函数中重新启动创建监视进程；
• 2.子进程（监视进程）如何监视到父进程死亡？
  当父进程死亡以后，子进程就成为了孤儿进程由Init进程领养，于是我们可以在一个循环中读取子进程的父进程PID，当变为1就说明其父进程已经死亡，于是可以重启父进程。这里因为采用了循环，所以就引出了之前提到的耗电量的问题。
• 3.父子进程间的通信
  有一种办法是父子进程间建立通信通道，然后通过监视此通道来感知对方的存在，这样不会存在之前提到的耗电量的问题，在本文的实现中，为了简单，还是采用了轮询父进程PID的办法，但是还是留出了父子进程的通信通道，虽然暂时没有用到，但可备不时之需！

OK， 下面就贴上代码！首先是Java部分，这一部分太过简单，只是一个类，提供了给外部调用的API接口用于创建守护进程，所有的实现都通过native方法在C++中完成！

/**
 * 监视器类，构造时将会在Native创建子进程来监视当前进程
 */

public class Watcher {

    public void createAppMonitor(String userId) {
        if (!createWatcher(userId)) {
            MainActivity.showlog("<>");
        } else {
            MainActivity.showlog("<>");
        }
        if (!connectToMonitor()) {
            MainActivity.showlog("<>");
        } else {
            MainActivity.showlog("<>");
        }   
    }

    /**
     * Native方法，创建一个监视子进程.
     *
     * @param userId
     *            当前进程的用户ID,子进程重启当前进程时需要用到当前进程的用户ID.
     * @return 如果子进程创建成功返回true，否则返回false
     */
    private native boolean createWatcher(String userId);

    /**
     * Native方法，让当前进程连接到监视进程.
     *
     * @return 连接成功返回true，否则返回false
     */
    private native boolean connectToMonitor();

    /**
     * Native方法，向监视进程发送任意信息
     *
     * @param 发给monitor的信息
     * @return 实际发送的字节
     */
    private native int sendMsgToMonitor(String msg);

    static {
        System.loadLibrary("monitor");
    }
}

只需要关心createAppMonitor这个对外接口就可以了，它要求传入一个当前进程的用户ID，然后会调用createWatcher本地方法来创建守护进程。还有两个方法connectToMonitor用于创建和监视进程的socket通道，sendMsgToMonitor用于通过socket向子进程发送数据。由于暂时不需要和子进程进行数据交互，所以这两个方法就没有添加对外的JAVA接口，但是要添加简直是轻而易举的事！

JAVA只是个壳，内部的实现还得是C++，为了让程序更加的面向对象，在实现native时，我们用一个ProcessBase基类来对父子进程进行一个抽象，把父子进程都会有的行为抽象出来，而父子进程可以根据需要用自己的方式去实现其中的接口，先来看看这个抽象了父子进程共同行为的ProcessBase基类：

#ifndef _PROCESS_H
#define _PROCESS_H

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
//#include "constants.h"

#define LOG_TAG "Native"

#define LOGE(...) __android_log_print(ANDROID_LOG_ERROR,LOG_TAG,__VA_ARGS__)

/**
 * 功能:对父子进程的一个抽象
 * @author wangqiang
 * @date 2014-03-14
 */
class ProcessBase {
public:

    ProcessBase();

    /**
     * 父子进程要做的工作不相同,留出一个抽象接口由父子进程
     * 自己去实现.
     */
    virtual void do_work() = 0;

    /**
     * 进程可以根据需要创建子进程,如果不需要创建子进程,可以给
     * 此接口一个空实现即可.
     */
    virtual bool create_child() = 0;

    /**
     * 捕捉子进程死亡的信号,如果没有子进程此方法可以给一个空实现.
     */
    virtual void catch_child_dead_signal() = 0;

    /**
     * 在子进程死亡之后做任意事情.
     */
    virtual void on_child_end() = 0;

    /**
     * 创建父子进程通信通道.
     */
    bool create_channel();

    /**
     * 给进程设置通信通道.
     * @param channel_fd 通道的文件描述
     */
    void set_channel(int channel_fd);

    /**
     * 向通道中写入数据.
     * @param data 写入通道的数据
     * @param len  写入的字节数
     * @return 实际写入通道的字节数
     */
    int write_to_channel(void* data, int len);

    /**
     * 从通道中读数据.
     * @param data 保存从通道中读入的数据
     * @param len  从通道中读入的字节数
     * @return 实际读到的字节数
     */
    int read_from_channel(void* data, int len);

    /**
     * 获取通道对应的文件描述符
     */
    int get_channel() const;

    virtual ~ProcessBase();

protected:

    int m_channel;
};

只是很简单的一个类，相信看看注释就知道是什么意思了，比如父子进程可能都需要捕获他的子孙死亡的信号，于是给一个catch_child_dead_signal函数，如果对子进程的死活不感兴趣，可以给个空实现，忽略掉就可以了。由于用了纯虚函数，所以ProcessBase是一个抽象类，也就是说它不能有自己的实例，只是用来继承的，它的子孙后代可以用不同的方式实现它里面的接口从而表现出不一样的行为，这里父进程和子进程的行为就是有区别的，下面就先为诸君奉上父进程的实现：

/**
 * 功能：父进程的实现
 * @author wangqiang
 * @date 2014-03-14
 */
class Parent: public ProcessBase {
public:

    Parent(JNIEnv* env, jobject jobj);

    virtual bool create_child();

    virtual void do_work();

    virtual void catch_child_dead_signal();

    virtual void on_child_end();

    virtual ~Parent();

    bool create_channel();

    /**
     * 获取父进程的JNIEnv
     */
    JNIEnv *get_jni_env() const;

    /**
     * 获取Java层的对象
     */
    jobject get_jobj() const;

private:

    JNIEnv *m_env;

    jobject m_jobj;

};

以上是定义部分，其实JNIEnv和jobject基本上没用到，完全可以给剃掉的，大家就当这两个属性不存在就是了！实现部分如下：

#include "process.h"

extern ProcessBase *g_process;

extern const char* g_userId;

extern JNIEnv* g_env;

//子进程有权限访问父进程的私有目录,在此建立跨进程通信的套接字文件
static const char* PATH = "/data/data/com.hx.doubleprocess/my.sock";

//服务名称
static const char* SERVICE_NAME = "com.hx.doubleprocess/com.hx.doubleprocess.MyService";

bool ProcessBase::create_channel() {
}

int ProcessBase::write_to_channel(void* data, int len) {
    return write(m_channel, data, len);
}

int ProcessBase::read_from_channel(void* data, int len) {
    return read(m_channel, data, len);
}

int ProcessBase::get_channel() const {
    return m_channel;
}

void ProcessBase::set_channel(int channel_fd) {
    m_channel = channel_fd;
}

ProcessBase::ProcessBase() {

}

ProcessBase::~ProcessBase() {
    close(m_channel);
}

Parent::Parent(JNIEnv *env, jobject jobj) :
        m_env(env) {
    LOGE("<>");

    m_jobj = env->NewGlobalRef(jobj);
}

Parent::~Parent() {
    LOGE("<>");

    g_process = NULL;
}

void Parent::do_work() {
}

JNIEnv* Parent::get_jni_env() const {
    return m_env;
}

jobject Parent::get_jobj() const {
    return m_jobj;
}

/**
 * 父进程创建通道,这里其实是创建一个客户端并尝试
 * 连接服务器(子进程)
 */
bool Parent::create_channel() {
    int sockfd;

    sockaddr_un addr;

    while (1) {
        sockfd = socket(AF_LOCAL, SOCK_STREAM, 0);

        if (sockfd < 0) {
            LOGE("<>");

            return false;
        }

        memset(&addr, 0, sizeof(addr));

        addr.sun_family = AF_LOCAL;

        strcpy(addr.sun_path, PATH);

        if (connect(sockfd, (sockaddr*) &addr, sizeof(addr)) < 0) {
            close(sockfd);

            sleep(1);

            continue;
        }

        set_channel(sockfd);

        LOGE("<>", m_channel);

        break;
    }

    return true;
}

/**
 * 子进程死亡会发出SIGCHLD信号,通过捕捉此信号父进程可以
 * 知道子进程已经死亡,此函数即为SIGCHLD信号的处理函数.
 */
static void sig_handler(int signo) {
    pid_t pid;

    int status;

//调用wait等待子进程死亡时发出的SIGCHLD
//信号以给子进程收尸，防止它变成僵尸进程
    pid = wait(&status);

    if (g_process != NULL) {
        g_process->on_child_end();
    }
}

void Parent::catch_child_dead_signal() {
    LOGE("<>", getpid());

    struct sigaction sa;

    sigemptyset(&sa.sa_mask);

    sa.sa_flags = 0;

    sa.sa_handler = sig_handler;

    sigaction(SIGCHLD, &sa, NULL);
}

void Parent::on_child_end() {
    LOGE("<>");

    create_child();
}

bool Parent::create_child() {
    pid_t pid;

    if ((pid = fork()) < 0) {
        return false;
    } else if (pid == 0) //子进程
    {
        LOGE("<>", getpid());

        Child child;

        ProcessBase& ref_child = child;

        ref_child.do_work();
    } else if (pid > 0)  //父进程
    {
        LOGE("<>", getpid());
    }

    return true;
}

这里先要说明一下三个全局变量：

• g_process是父进程的指针；
• g_userId是父进程用户ID，由Java侧传递过来，我们需要把它用全局变量保存起来，因为子进程在重启父进程的时候需要用到用户ID，否则会有问题，当然这里也得益于子进程能够继承父进程的全局变量这个事实！
• g_env是JNIEnv的指针，把这个变量也作为一个全局变量，是保留给子进程用的；

父进程在create_child中用fork创建了子进程，其实就是一个fork调用，然后父进程什么都不做，子进程创建一个Child对象并调用其do_work开始做自己该做的事！

父进程实现了catch_child_dead_signal，在其中安装了SIG_CHLD信号处理函数，因为他很爱他的儿子，时刻关心着他。而在信号处理函数sig_handler中，我们留意到了wait调用，这是为了防止子进程死了以后变成僵尸进程，由于我们已经知道父进程最多只会创建一个子监视进程，所以wait就足够了，不需要waitpid函数亲自出马！而信号处理函数很简单，重新调用一下on_child_end，在其中再次create_child和他亲爱的夫人在make一个小baby就可以了！

最后要说说create_channel这个函数，他用来创建和子进程的socket通道，这个编程模型对于有网络编程经验的人来说显得非常亲切和熟悉，他遵循标准的网络编程客户端步骤：创建socket，connect，之后收发数据就OK了，只是这里的协议用的是AF_LOCAL，表明我们是要进行跨进程通信。由于域套接字用的不是IP地址，而是通过指定的一个文件来和目标进程通信，父子进程都需要这个文件，所以这个文件的位置指定在哪里也需要注意一下：在一个没有root过的手机上，几乎所有的文件都是没有写入权限的，但是很幸运的是linux的子进程共享父进程的目录，所以把这个位置指定到/data/data/下应用的私有目录就可以做到让父子进程都能访问这个文件了！

接下来是子进程的实现了，它的定义如下：

/**
 * 子进程的实现
 * @author wangqiang
 * @date 2014-03-14
 */
class Child: public ProcessBase {
public:

    Child();

    virtual ~Child();

    virtual void do_work();

    virtual bool create_child();

    virtual void catch_child_dead_signal();

    virtual void on_child_end();

    bool create_channel();

private:

    /**
     * 处理父进程死亡事件
     */
    void handle_parent_die();

    /**
     * 侦听父进程发送的消息
     */
    void listen_msg();

    /**
     * 重新启动父进程.
     */
    void restart_parent();

    /**
     * 处理来自父进程的消息
     */
    void handle_msg(const char* msg);

    /**
     * 线程函数，用来检测父进程是否挂掉
     */
    void* parent_monitor();

    void start_parent_monitor();

    /**
     * 这个联合体的作用是帮助将类的成员函数做为线程函数使用
     */
    union {
        void* (*thread_rtn)(void*);

        void* (Child::*member_rtn)();
    } RTN_MAP;
};
#endif 

注意到里面有个union，这个联合体的作用是为了辅助把一个类的成员函数作为线程函数来传递给pthread_create，很多时候我们都希望线程能够像自己人一样访问类的私有成员，就像一个成员函数那样，用friend虽然可以做到这一点，但总感觉不够优美，由于成员函数隐含的this指针，使我们完全可以将一个成员函数作为线程函数来用。只是由于编译器堵死了函数指针的类型转换，所以这里就只好用一个结构体。

废话不多说，看看子进程的实现：

bool Child::create_child() {
//子进程不需要再去创建子进程,此函数留空
    return false;
}

Child::Child() {
    RTN_MAP.member_rtn = &Child::parent_monitor;
}

Child::~Child() {
    LOGE("<<~Child(), unlink %s>>", PATH);

    unlink (PATH);
}

void Child::catch_child_dead_signal() {
//子进程不需要捕捉SIGCHLD信号
    return;
}

void Child::on_child_end() {
//子进程不需要处理
    return;
}

void Child::handle_parent_die() {
//子进程成为了孤儿进程,等待被Init进程收养后在进行后续处理
    while (getppid() != 1) {
        usleep(500); //休眠0.5ms
    }

    close (m_channel);

//重启父进程服务
    LOGE("<>");

    restart_parent();
}

void Child::restart_parent() {
    LOGE("<>");

    /**
     * TODO 重启父进程,通过am启动Java空间的任一组件(service或者activity等)即可让应用重新启动
     */
    execlp("am", "am", "startservice", "--user", g_userId, "-n", SERVICE_NAME, //注意此处的名称
            (char *) NULL);
}

void* Child::parent_monitor() {
    handle_parent_die();
}

void Child::start_parent_monitor() {
    pthread_t tid;

    pthread_create(&tid, NULL, RTN_MAP.thread_rtn, this);
}

bool Child::create_channel() {
    int listenfd, connfd;

    struct sockaddr_un addr;

    listenfd = socket(AF_LOCAL, SOCK_STREAM, 0);

    unlink (PATH);

    memset(&addr, 0, sizeof(addr));

    addr.sun_family = AF_LOCAL;

    strcpy(addr.sun_path, PATH);

    if (bind(listenfd, (sockaddr*) &addr, sizeof(addr)) < 0) {
        LOGE("<>", errno);

        return false;
    }

    listen(listenfd, 5);

    while (true) {
        if ((connfd = accept(listenfd, NULL, NULL)) < 0) {
            if (errno == EINTR)
                continue;
            else {
                LOGE("<>");

                return false;
            }
        }

        set_channel(connfd);

        break;
    }

    LOGE("<>", m_channel);

    return true;
}

void Child::handle_msg(const char* msg) {
//TODO How to handle message is decided by you.
}

void Child::listen_msg() {
    fd_set rfds;

    int retry = 0;

    while (1) {
        FD_ZERO(&rfds);

        FD_SET(m_channel, &rfds);

        timeval timeout = { 3, 0 };

        int r = select(m_channel + 1, &rfds, NULL, NULL, &timeout);

        if (r > 0) {
            char pkg[256] = { 0 };

            if (FD_ISSET(m_channel, &rfds)) {
                read_from_channel(pkg, sizeof(pkg));

                LOGE("<>", pkg);

                handle_msg((const char*) pkg);
            }
        }
    }
}

void Child::do_work() {
    start_parent_monitor(); //启动监视线程

    if (create_channel())  //等待并且处理来自父进程发送的消息
    {
        listen_msg();
    }
}

子进程在他的do_work中先创建了一个线程轮询其父进程的PID，如果发现变成了1，就会调用restart_parent，在其中调用execlp，执行一下am指令启动JAVA侧的组件，从而实现父进程的重启！这里请留意一下execlp中给am传入的参数，带了–user并加上了之前我们在全局变量中保存的user id，如果不加这个选项，就无法重启父进程，我在这花费了好长时间哦！

子进程剩余的工作很简单，创建通道，监听来自父进程的消息，这里我们用select来监听，由于实际上只有一个客户端（父进程），所以用select有点脱裤子放屁，把简单问题复杂化的嫌疑，但是实际上也没啥太大影响！

有了以上的实现，JNI的实现就相当的简单了：

#include "process.h"

/**
 * 全局变量，代表应用程序进程.
 */
ProcessBase *g_process = NULL;

/**
 * 应用进程的UID.
 */
const char* g_userId = NULL;

/**
 * 全局的JNIEnv，子进程有时会用到它.
 */
JNIEnv* g_env = NULL;

extern "C" {
JNIEXPORT jboolean JNICALL Java_com_hx_doubleprocess_Watcher_createWatcher(
        JNIEnv*, jobject, jstring);

JNIEXPORT jboolean JNICALL Java_com_hx_doubleprocess_Watcher_connectToMonitor(
        JNIEnv*, jobject);

JNIEXPORT jint JNICALL Java_com_hx_doubleprocess_Watcher_sendMsgToMonitor(
        JNIEnv*, jobject, jstring);

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM*, void*);
};

JNIEXPORT jboolean JNICALL Java_com_hx_doubleprocess_Watcher_createWatcher(
        JNIEnv* env, jobject thiz, jstring user) {
    g_process = new Parent(env, thiz);//创建父进程
    g_userId = (const char*) env->GetStringUTFChars(user,0);//用户ID
    g_process->catch_child_dead_signal();//接收子线程死掉的信号

    if (!g_process->create_child()) {
        LOGE("<>");
        return JNI_FALSE;
    }

    return JNI_TRUE;
}

JNIEXPORT jboolean JNICALL Java_com_hx_doubleprocess_Watcher_connectToMonitor(
        JNIEnv* env, jobject thiz) {
    if (g_process != NULL) {
        if (g_process->create_channel()) {
            return JNI_TRUE;
        }
        return JNI_FALSE;
    }
}

把上面这些代码整合起来，一个双进程守护的实现就完成了，只需要调用一下Watcher.java的createAppMonitor，你的应用就会有一个守护进程来监视，被杀死后也会立刻重新启动起来！是不是很有意思呢？

Demo下载地址