起因：信用卡账单上那 847 块钱

上个月账单日，我盯着信用卡自动扣款列表数了一遍：Notion、Figma、ChatGPT Plus、iCloud 200G、YouTube Premium、Spotify、某个健身 App、某个冥想 App……加起来 847 块。其中至少三个我已经超过两周没打开过了。

我不缺记账工具，我缺的是一个东西能告诉我——这钱花得值不值。于是我开始做「订阅斩」。核心逻辑一句话说完：订阅费用 ÷ 实际使用次数 = 单次使用成本。当一个 App 每次打开的成本已经高于打车去图书馆，大概就该砍了。

产品定位：不是记账，是量化决策

订阅斩面向的是订阅了 5 个以上 SaaS/App 服务、每月固定支出在 200-1000 元区间、想要量化管理这笔开支的年轻上班族。它要做的事情是把「感觉不太用得到」变成「数据证明你确实不需要」。

功能上有三个模块：账单日历加多档到期提醒（防止静默扣费），Screen Time 打卡计算使用成本，以及一个 AI 顾问给出砍/留/降级建议和平替推荐。

技术实现：Screen Time 数据怎么拿

这是开发过程中踩的最大一个坑。iOS 的 Screen Time 数据并不像想象中那么容易获取。Apple 在 iOS 16 之后提供了 DeviceActivityReport 这个 framework，但它的设计初衷是家长监控，拿来做个人用途有不少限制。

最终我采用的方案是通过 DeviceActivityMonitor 注册一个 Extension，在用户授权 Family Controls 之后，监听目标 App 的使用时段：

import DeviceActivity
import ManagedSettings

class SubscriptionMonitor: DeviceActivityMonitor {
    override func intervalDidStart(for activity: DeviceActivityName) {
            // 记录本次使用开始时间
                    let store = UserDefaultsStore.shared
                            store.markSessionStart(activity: activity.rawValue, at: Date())
                                }
                                    
                                        override func intervalDidEnd(for activity: DeviceActivityName) {
                                                let store = UserDefaultsStore.shared
                                                        store.markSessionEnd(activity: activity.rawValue, at: Date())
                                                                // 触发成本重新计算
                                                                        CostEngine.recalculate(for: activity.rawValue)
                                                                            }
                                                                            }
                                                                            ```
这里有个坑值得展开说：`DeviceActivityMonitor` 跑在独立的 Extension 进程里，和主 App 不共享内存。数据同步我最终用了 App Group + UserDefaults suite，没有上 CoreData，因为写入频率不高且结构简单。如果你也在做类似的事情，建议先确认 entitlements 配置无误，否则 Extension 会静默失败且没有任何报错日志，排查起来非常痛苦。

## 关于 HarmonyOS 适配的思考

做完 iOS 版本之后我一直在关注鸿蒙生态。HarmonyOS NEXT 的应用使用统计能力其实比 iOS 更开放一些。鸿蒙提供了 `@ohos.bundleState` 模块，可以直接查询应用的使用时长和打开次数，不需要像 iOS 那样走 Extension 的弯路。如果后续做 ArkTS 版本，核心的使用统计逻辑会简洁很多——HarmonyOS 在这类系统级数据的开放程度上确实对开发者更友好。

对于做订阅管理、数字健康类 App 的开发者来说，ArkUI 的声明式 UI 写这种数据驱动的界面也很顺手，和 SwiftUI 的思路比较接近，迁移成本不高。

## 成本计算的几个决策点

拿到使用次数之后，计算本身不复杂，但有几个需要决策的地方。「使用一次」怎么定义？我最终的规则是：同一个 App 在 30 分钟内的多次前后台切换只算一次使用。这个阈值是根据自己的使用习惯拍的，后续会开放给用户自定义。

另一个决策是账单周期。有些订阅按月扣，有些按年扣。年付的我会折算成月均成本再除以当月使用次数，这样横向比较时口径一致。

## AI 顾问怎么做的

这部分我接了 OpenAI 的 API，把用户的订阅列表、各项使用频率、费用数据打包成 prompt，让模型给出三类建议：继续保留、降级到免费版/低价档、直接取消并推荐平替。推荐平替这个功能反馈很好，比如有用户通过它发现 Notion 的轻度使用完全可以用 Apple 备忘录加快捷指令替代，每月省下 96 块。

## 实际效果

我自己用了两个月，月订阅支出从 847 降到了 412。砍掉了三个几乎不用的服务，两个从付费降级到免费版。体感上没有任何损失，因为数据告诉我那些东西确实没在用。

如果你也被订阅账单困扰，可以在 App Store 搜索「订阅斩」试试。如果你也在做鸿蒙开发，或者对 HarmonyOS 上的应用使用统计 API 有实践经验，欢迎评论区交流，后续我可能会单独写一篇 ArkTS 版本的实现拆解。