先用 adb shell am force-stop 包名 杀掉 app，每过一段时间用 adb shell ps 包名看看应用起来没

你让开发打日志，python 去读 logcat 不就行了

保活 不是 自启

没明白你的保活具体是啥意思。可以先详细说一下么？

我们公司这边的定义是： APP 在锁屏、退后台、自动息屏等场景下是否会被手机系统杀死

保证它活着，不被系统杀死？

那你每隔 30 秒，点它一次？？？

关于 Android 后台保活这个，搜了一下，找到了这篇：https://juejin.cn/post/7003992225575075876 。保活的难点主要在于在不同厂商系统和不同的场景下，各个保活机制确认有生效。

不知道你现在对于 android 后台保活这个，是否已经有相对固定且完善的测试场景用例（比如在各厂商的操作系统下，针对优化助手清理、针对用户自行清理、针对打开多个 app 后系统后台自动清理等，是否都能保活）？如果没有，可以先设计下这些用例；有的话，那把用例翻译成对应的自动化脚本就好。

学习了，链接的文章很赞。

app 保活的测试 是否可以通过添加心跳埋点日志 上报后对日志分析实现

我觉得这个思路也是很有用的，线上线下监控都可以用得到。

可以按设备做每个设备的心跳埋点时间间隔情况的统计，时间间隔大于 xx 次心跳间隔的视为保活失败一次。然后通过统计看各设备的保活失败率了解各系统版本的保活情况，再对失败率高的，做针对性测试和处理。

后面找到了另一篇，写得更全，也分享下：
https://github.com/LoganZy/AndroidTotal/blob/master/android%20%E8%BF%9B%E7%A8%8B%E4%BF%9D%E6%B4%BB%E6%9C%BA%E5%88%B6.md

和楼下的兄弟的意思差不多，杀死 app 一段时间后会拉活，感谢兄弟分享

这种方法可以做成通用的脚本嘛

太赞了

这个可以监控手机的 cpu、内存等使用，当你们的 APP 没有占比的时候，很明显就是被干掉了

我在 19 年时还真的测过一次保活，当时也是我第一次（唯一一次）接触这个东西，搞了两周多，大概分享一下。

1. 保活的功能测试：需要理解业务实现的保活策略，包括策略下发、策略更替、策略生效等，有能力的话需要走读代码理解实现细节更有助于抓 bug；黑盒测试局限性会大一些，主要从日志、信息数据上报、进程是否调起等方面去判断。这里面可以拓展一些异常测试，比如下发错误的策略配置、app 新安装未授予系统权限、系统低电量等都可能会有影响，具体要看业务实现。
2. 保活的兼容性测试：保活的方式有很多，细分到不同厂商的不同 Android 版本，业务锁实现的保活策略都可能存在不一致的地方，因为 “保活” 本质上就是和厂商的系统策略在对抗，而厂商的策略会一直迭代，所以兼容测试会是一个很大块的工作。
3. 保活的性能测试：其实都说不上是性能测试，当时做得很浅，就是不断去杀进程，让保活反复生效（甚至是生效了一般又被杀掉），某种程度上给予其功能正常生效的压力。
4. 保活的安全测试：这块当时没做事情，现在回想起来，在数据上报，配置落盘存储等方面可能需要额外关注一些数据安全加密等是否存在问题。
5. 其他联动测试：看业务实现了，比如和推送下发是否有联动等。

一些注意的地方：

1. 留意 Java 弱引用对象的销毁是否会成为策略 bug，当时踩过这个坑，线下测试偶现保活策略生效不合预期无法稳定给研发复现，后来保活功能上线，研发在线上观察定位到问题。
2. 策略生效需要多次观察，保活结果也要观察多一阵时间，需要很细节地抠策略生效间隔和实际拉活的间隔是否符合预期，有若干秒的差异可能就是 bug。
3. 多发挥想象力去从各个角度艹保活功能，多想想用户的使用环境。

其他要求：

1. 具备基本的 adb 命令使用能力，不会的命令要知道怎么茶
2. 具备基本的 shell 脚本编写能力，把整套的操作封装成 shell 挂机跑

APP 除非大厂的跟手机厂商合作，其他的保活手段基本上只能在规则内尽可能的来完善，具体手段针对不同品牌都不同，代码里的无非就是一搜就有的那几套方法，root 的不在此列，参考链接：https://dontkillmyapp.com/