android apk卸载监控调研与分析（1）

因工作上的需要，需要对自己的apk做卸载监控，在这个过程中遇到了很多的问题，虽然实现了功能，不过个人觉得不够完善。先记录下来以便后续尝试优化。

一。基本思路分析：

   由于android并没有自监控是否卸载的接口，网上有yiixe方法，包括监控系统日志，启用子进程的方式来监控等。个人觉得360的卸载自监控做的很好，虽然可以知道是通过子进程的方式来监控，但是其子进程的名称，包括子进程的所用的资源都与父进程不同，通过fork()方式创建的子进程完全无法达到这个效果，虽然查了一些资料想达到类似的效果，可惜一直没有结果。

    通过尝试监控系统日志与子进程监控两种方式，个人觉得子进程监控的方式更好，日志监控的不稳定性教过，而且为了保证监听的效果，很耗资源与电量。

    总的来说思路如下：

    主进程启动时，通过ndk的方式启动一个子进程，该子进程首先使用目录监听器用来监听apk资源目录的状态，判断是否出现了delete操作，如出现，则检查apk包是否还存在，如果不存在，则表明出现了卸载操作。（当然，这个里边还涉及到时间间隔的控制）

二。遇到问题与解决方案：

    1.apk多次启动时，子进程重复创建的问题。

      这个问题是通过文件锁来进行的，子进程创建时在apk资源目录下创建一个lockfile，通过检查lockfile的状态来判断子进程是否存在，如果存在则不重复创建。

      ps:这里又会出现在使用了清理数据的操作后，由于资源目录被delete，因此子进程又被重复创建的问题，这里似乎陷入了一个循环无解的地步。

    2.子进程与父进程资源共享的问题。

       fork出的子进程与父进程共享资源，这就存在一个问题，当父进程结束时该如何处理？父进程结束时，子进程会被系统的inti接管，但是如果是父进程整在使用时被意外kill掉，由于子进程被init进程接管，因此父进程与子进程的共享资源还没有释放，就会导致手机卡在父进程的界面中，由于父进程已经结束，因此你无法做任何操作，除非系统会受到子进程，将资源释放掉后才可。当然这个情况不确实是否多见，不过对于一个桌面软件来说这个问题就比较严重了。

       尝试过通过singal的方式使得父进程结束时通知子进程，子进程自行结束，虽然可以避免这个问题，但是需要的卸载监听效果就不够了。你没办法保证用户在卸载APK时你的父进程时是存在的。

      这里似乎又陷入了一个无解的地步。