为什么 Keep Alive 和其他安全应用不一样
「失联才发现」到底有多普遍
独居老人在家出事、骑手在偏僻路段遭遇意外、慢性病患者独自在家发作——这些场景的共同特点不是"没有人知道风险存在"，而是风险真正发生时，没有人第一时间收到通知。
传统的解决方案有两个极端：要么是每日打卡类应用要求"每天必须点一下确认我还活着"（Corlo、STAY 这类），用户体验重、容易养成"随手打卡"的条件反射，真出事时可能反而忘了；要么是完全被动的健康监测（智能手表心率异常报警），需要硬件持续佩戴且价格不菲。
Keep Alive 选择了第三条路：用手机本身的使用状态作为"是否活着"的信号源。
和每日打卡型安全应用的本质区别
| 对比维度 | Keep Alive | Corlo 等每日签到型 |
|---|---|---|
| 用户行为 | 完全被动、零交互 | 每天需要主动打卡一次 |
| 触发逻辑 | 长时间无操作 → 弹窗 → 超时预警 | 未打卡 → 24 小时后通知 |
| 误报风险 | 弹窗二次确认 + 休息时段过滤，双层防误报 | 漏打一次就预警，容错率低 |
| 预警速度 | 12 小时无操作 + 60 分钟确认，约 13 小时 | 24 小时 |
| 硬件要求 | 任何安卓手机 | 任何手机 |
| 数据隐私 | 完全本地运算 | 需要云端服务器存状态 |
关键差异在于：Keep Alive 不要求用户改变任何日常行为——它只"被动观察"，用户正常用手机就等于在"报平安"。这意味着它不仅适合真出事的场景，也适合日常低干扰运行。
Keep Alive 不做什么
理解它的边界很重要，避免把它当成万能方案：
- 不是一键报警：不能像 SOS 按钮那样立刻求助，它是"长期失联后自动触发"的兜底
- 不能替代 110 / 120：真到能手动打电话的地步，永远优先手动求助；Keep Alive 只在"动不了"的时候有用
- 不做健康监测：不测心率、不测血氧、不测跌倒——没有硬件传感器
- 不做云存储：没有账号、没有云端备份——配置全在本地，换手机需要重新设置
- 不跨设备联动：只盯着自己这台手机，不绑定智能手表或其他设备
谁是 Keep Alive 的理想用户
满足以下任意一条，就值得装：
- 有过"出事了没人知道"的担忧（独居、独自旅行、高危工作）
- 不想改变日常行为（每天打卡太麻烦、容易忘）
- 重视隐私（不想让健康数据上云）
- 想要一个低成本的"最后一道保险"（一台安卓手机就够，不需要额外硬件）
具体到每个场景的参数调优，见 人群与参数调优 分组。