兑换码，以及我主动删掉的后台常驻

PFEx 的付费走 Google Play 商店计费。但中国大陆用不了 Google Play 服务，那边的用户只能装 APK，商店计费对他们等于不存在。所以 10 月 9 日这次做了一件补漏的事：加兑换码，给这些人一条不经过商店的权益通道。同一次提交里，我还把后台常驻的那套整个删掉了。那不是补漏，是我自己不想再要它了。

兑换码

界面上就是一个"使用兑换码"的入口。麻烦不在界面，在顺序。

我一开始把顺序做反了：先给用户授权，再去登录订阅服务。结果是后端要把权益写进订阅服务时，那个用户它还不认识，直接报 "subscriber not found"。把这个错误抄下来之后，顺序就理清楚了：先让用户登录订阅服务，权益再授权。授权是异步的，客户端得等一会儿才拿得到。

另一个坑是绑定的粒度：一个码只能绑一台设备。有人换手机想接着用，就得先迁移。提示文案我写得很直白，原文是："该兑换码已绑定其他设备。迁移后，原设备将失去专业版权限。"确认之后本地设备号重置，原来的手机下次校验就掉回免费版。

网络不通时我没做立刻踢人，专业版有 3 天离线宽限，过了才失效。

请求本身带签名。要说清楚的是：签名只是防随手改包，真正的校验在服务端。权益能不能用，取决于后端认不认，不取决于客户端本地记了什么。

删掉后台常驻这件事

先把动机说清楚：这不是为了过审。

PFEx 原先有个"智能盯盘"：后台起一个常驻服务，每一小会儿轮询一次，把通知栏里的收支识别出来，先放进本地草稿队列，再配一条常驻通知。它的成本是确定的，收益却不稳。

不稳在识别这一环。付款类通知常常只有"支付成功"几个字，金额、商户、时间这三样总要缺一样；机构改一次文案格式，之前写的解析就整片失效；有的推送纯粹是营销话术，真实扣款信息根本不在里面。缺信息就得靠猜，猜错就是记错一笔，还得用户回头改。这条链路做到最后，省下的操作还没制造的回改多。

再叠加常驻本身的代价：一个一直活着的后台服务、一条清不掉的常驻通知、各家手机系统上不确定的保活表现。一边是确定的开销，一边是缺信息的输入，算完就没有犹豫。

所以这次是整条停用，不是默认隐藏：通知监听连注册都不注册了，通知根本进不来；开机自启那条路也断了；后台依赖整个从依赖清单里去掉；原来在后台做的检查，挪成了"打开时算一次"。我需要它正确，不需要它一直醒着。

拆的过程里还踩到一个 Android 14 的坑。它跟"为什么下线"无关，只是记录一下：那个第三方插件在自己的清单里声明了一个缺必需字段的后台服务，我光把自己的调用注释掉还不够，系统启动它的时候照样报错，最后还得把合并后的那份声明也剥掉才干净。

记账 App 真的不需要常驻后台。数据都在本地，打开时算一次就对了。这是产品判断，不是审核压力。

所以别把它当成"可选功能"：自动记账目前完全不产出结果。记账还是手动的事，这也是产品一直的默认路径。

顺带一提

备份导入我加了一层行数校验。之前的判定太宽松：只要不报错就算成功，结果出现过"导入完成但账目少一截"。现在会比对导出的行数，对不上直接拒绝并提示。

另外首页"周期流水"的入口挪了位置：原来藏在生长图里，现在金额行本身可点，直接进周期流水列表。少一层菜单，多一次直觉。