一个不依赖服务器的Android提醒工具

起因

我记性不太好。

妈妈生日忘了，第二天发红包补救；医生开的药漏吃，病好得慢；重要会议忘了准备，被领导点名。

试过系统闹钟——设不了"明年5月20日"这种远期日期。试过备忘录——写了等于没写，到时候根本想不起来打开。试过日历——弹一下就消失，划掉就错过。试过第三方提醒APP——要么功能臃肿，要么依赖服务端推送，网络一断、后台一杀，提醒就没了。

最膈应的是隐私：我的吃药时间、家人生日、纪念日，全存在别人的服务器上。

市面上的产品要么不够强，要么不够私。那我就自己写一个。

---

小鹊幸做了什么

核心就一句话：你设一次，到时间强制喊你，清后台/重启/断网都照样响。

技术上有几个点我觉得值得聊一下：

1. 离线强提醒

用 AlarmManager.RTC_WAKEUP + setExactAndAllowWhileIdle，提醒逻辑跑在系统层面，不依赖APP进程活着。

绕开 Doze 和厂商后台管理是关键。还要监听 BOOT_COMPLETED和 TIME_SET，手机重启后把所有未过期事件重新注册回去——不然用户设了一次，重启就没了，信任直接崩塌。

2. 纯本地架构

• 数据全在 SQLite 本地，不上传任何服务器
• 开发者（也就是我）也看不到用户数据，物理级隐私
• 不需要注册，游客模式打开就能用，微信/QQ 登录是可选的（留着做后续增值）
• 唯一网络请求是微信消息推送，旁路，不影响主体

边际成本趋近于零，用户多了我也不慌。这也是为什么敢说"设一次，用一辈子"——就算我明天消失了，用户设好的提醒照样年年响。这不是营销话术，是纯本地单机应用的客观事实。

3. 农历计算

长辈生日大多是农历的，系统闹钟和大部分提醒工具搞不定。

我一开始想接第三方库（LunarCalendar、lunar-java），后来发现要么 API 方向不对（公历→农历为主，农历→公历要扒源码），要么体积大依赖多。干脆自己写。

查表法，1900-2099 共200个 int，每个 int的 bit03 存闰月、bit415 存12个月大小月：

// 单int编码：低4位=闰月(0-12)，bit4~15=12个月大小月
private static final int[] LUNAR_INFO = {
    0x04bd8, 0x04ae0, 0x0a570, ... // 200个
};

⚠️ 踩过一个坑：一开始 getLeapMonth写成 yearData >> 16，结果所有闰月全读错。后来才确认数据表是低4位存闰月，应该 & 0xf。上线前务必用1900闰八月验证。

双向转换（农历↔公历）都支持，输出 Calendar直接喂给 AlarmManager。农历事件每年打开APP时动态算当年公历日期，重新注册闹钟——因为农历每年对应公历都变，不能简单地"每年重复"。

4. 三保险

• 第一层：APP 系统级离线唤醒
• 第二层：一键同步到系统日历
• 第三层：绑定微信后收消息推送

---

跟市面产品的差异

	系统闹钟	备忘录/日历	云端提醒APP	小鹊幸
远期日期	❌	✅	✅	✅
强制弹窗（清后台也响）	✅	❌	部分	✅
离线可靠	✅	❌	❌	✅
农历	❌	❌	少数	✅
数据不上传	✅	部分	❌	✅
无需注册	✅	部分	❌	✅

---

商业化

纯本地架构，没服务器运维成本。前期完全免费攒用户，后期开会员（一次性买断，终身），解锁农历、微信推送、高级重复规则。

不做订阅制。你买一次工具就是你的，没有"停止付费就锁功能"这种事。

收款暂时走的收款码+后台手动插单（VIP状态服务端控制，可试用7天，到期查订单→有则转正无则收回）。用户量起来之前没必要接支付，先把产品打磨好。

---

下载

👉 www.pgyer.com/xiaoquexing…

不用注册，打开就能用。提醒不准大概率是自启动权限没开，APP 内有按品牌适配的图文引导。

---

一点感想

这个项目核心代码不到3000行，但把"忘事"这个痛点解决到位了。

很多时候我们不需要复杂的架构，只需要把一个点真正做透。纯本地、离线唤醒、农历计算——这三个点每个都不算难，但凑在一起再做扎实，市面上能打的就不多了。

如果你也在做独立开发，或者对哪个技术点感兴趣（农历算法 / 离线唤醒的厂商适配），欢迎评论区聊。

---

小鹊幸——记性不好？交给我。 效果预览