APP统计过程中看的最多的要属激活，但随着运营成本的不断上升，一定程度上我们期望获得有多少用户卸载了APP。分析App卸载情况是刚需，但如何对卸载情况进行统计却没有非常成熟的解决方案。以下整理的是一些实现方案:
目录
基于系统底层的卸载统计
华为分析服务的统计逻辑
华为分析服务中包含了卸载分析服务。具体实现方案为通过分析服务系统的广播行为，准确捕捉App卸载事件。当用户卸载App之后，将卸载信息上报到云端。
需要注意的是华为分析服务中的卸载分析需要预装HMS Core的华为终端设备才支持。
此方案获取数据准确但只支持特定平台。
基于推送的卸载统计
友盟推送是如何统计卸载
如果一个设备上有多个集成友盟推送SDK的App的话（注意，必须是集成了友盟推送SDK的App），我们把这些个App称为一个群组或者联盟，同一个群组内的App在推送的通道上是做了很多互保和优化工作的，比如长连接通道就是在这多个App之间共享的。
同一个群组里面的App，如果有某个App发生卸载行为的话，那么这个卸载事件就可以被群组里其它没有卸载的App所知晓，该卸载事件就可以上报给服务器端，服务器端就可以知道哪台设备上哪个App被卸载了。同一个群组内的App之间互相检测卸载是一种常用的手段，但是这个要依赖于设备上集成友盟推送SDK的App有很多个，形成一个群组，如果只有1个App集成了友盟推送的话，那么这种手段是无法捕获到卸载的。 群组内的App越多，卸载统计收集的效果越好。如果设备上只有1个集成友盟推送SDK的App的话，那么如何统计到这个App是否被卸载了呢？ 这种情况下，我们只能判断到一部分卸载的情况，外加一些其它的辅助判断信息。
那么哪部分可以统计其实还是要依赖于App群组了，假设之前这个设备上只有App A集成了友盟推送，并且A被卸载了，假设后续又安装了集成友盟推送SDK的App B，那么如果给App A发消息，消息送达设备后(因为App B在，所以消息走的是B建立长连通道), 会尝试投递给App A，因为A已经被卸载了，所以投递是不成功的，App B就能感知到这一事件，因此也可以把该卸载信息上报回友盟服务器，服务器也就知道该设备上A App已经被卸载了，其实还是要依赖于设备上的App群组功能。
如果该台设备上后续一直没能有集成友盟推送SDK的App被安装，那么我们只能通过粗糙的看多少天不活跃，比如180天不活跃的App，我们认为这台设备上App已经被卸载了（有一定的偏差，比如某些工具类App，有可能打开频率就非常低），这个不一定准确，但是根据活跃度做用户分层多少也能看出来App的健康度。
该方案核心逻辑是每天使用一次无声推送通知来验证仍在用户设备上安装了应用程序，难点是需要独立的APP很难实现，类似第三方的PUSH服务是最合适的。
通过Linux fork()进程进行监控
具体实现方案：
- App第一次安装启动时，加载一个可执行Bin文件，在Bin文件中 fork 出一个子进程，然后让父进程先退出，子进程变为僵尸进程继续在后台监控
- 由于App被卸载的时候，其/data/data/$PkgName/ 下面的所有文件及目录都会被移除，因此可以在该目录下放一个文件，通过监控该文件是否被移除来感知App是否被卸载了。例如：/data/data/$PkgName/feedback，监控文件被移除可以用C函数：inotify_init， inotify_add_watch， inotify_rm_watch （这三个标准C函数的用法，自行脑补吧）
- 当监控到/data/data/$PkgName/feedback 被移除后，有两种可能：（1）App的确被卸载了；（2）用户在应用管理里面，手动执行了“clear data” 操作；需要对这两个情况进行判断
- 当判断App的确被卸载之后，可以直接在C层执行 “am” 命令弹出卸载反馈页面，例如 “am start -a android.intent.action.VIEW -d 卸载反馈的url”
- 下面是可执行Bin文件C代码, 编译完后命名为so，之所以后缀为.so，是为了方便APK打包，将其放到Android工程目录libs/armeabi/libfeedback.so下面，这样当APK打包之后，安装的时候会自动释放到 “/data/data/com.test.app/lib/” 目录。
即启用c语言的fork()进程，使用jni技术，监听data/data/包名 是否存在。在android5.0更新以后，这种方法失效，c语言启用的fork()进程同样被杀死，其版本做到了“同包名杀”，“同task杀”，“同进程组杀”，所以无法实现。
参考链接：
