起因
去年有段时间焦虑得厉害，开会前手心出汗，晚上躺床上脑子停不下来。试了几个呼吸训练 App，要么就是一个圆圈一直膨胀收缩，练完也不知道自己练了啥；要么就是上来让你订阅，月费比我一顿午饭还贵。
我想做一个自己愿意每天打开的呼吸训练工具。不要花里胡哨，要有结构化的课程体系，要能看到自己坚持了多少天。于是就有了「呼吸视界」这个项目。
目前 App Store 评分 5 分（样本量还很小，说实话没几个人评），但有个用户 @ccflower713 留了一条评价："发现了一个好用的app，可以跟随练习呼吸，保持稳定的心情"——看到这条的时候挺开心的，至少说明方向没跑偏。
核心设计：不只是一个计时器
市面上大部分呼吸 App 的产品逻辑是这样的：选一个呼吸模式 → 开始 → 跟着动画做 → 结束。
这没什么问题，但我觉得少了点东西。就像你去健身房，不能每天随便练练就走，得有个训练计划。呼吸训练也一样——4-7-8 呼吸法适合助眠，盒式呼吸适合快速镇定，这些东西应该被组织成一个课程，让用户循序渐进地走完。
所以我设计了一个 ProgramProgressRecord 的概念：每个课程计划包含多个阶段，每个阶段有若干次练习，用户每完成一次会话就推进进度。数据全部存在本地，不上传，不需要注册账号。
说白了就是一个本地的"打卡系统"，但比单纯打卡多了课程编排的层次。
技术选型上的纠结
项目用 Swift 写的 iOS 原生。在数据持久化这块，我纠结了挺久。
一开始想用 Core Data，毕竟是苹果亲儿子。但我的数据模型其实很简单——训练记录、课程进度、用户偏好设置，关系也不复杂。Core Data 那套 NSManagedObjectContext 的写法对于这种轻量场景来说太重了。
最后选了直接用 Codable + FileManager 做 JSON 文件存储。简单粗暴，但够用。训练记录按月分文件，课程进度单独一个文件，读写速度完全不是瓶颈。
struct SessionRecord: Codable, Identifiable {
let id: UUID
let techniqueId: String // 如 "box_breathing", "4_7_8"
let startedAt: Date
let durationSeconds: Int
let completedCycles: Int
let programId: String? // 关联的课程计划，可选
var monthKey: String {
let f = DateFormatter()
f.dateFormat = "yyyy-MM"
return f.string(from: startedAt)
}
}
这个 monthKey 的设计是后来加的。最早所有记录塞一个文件，用了两个月之后 JSON 文件大了，每次启动加载变慢。按月拆分之后，启动时只读当月数据，历史数据按需加载，体感上快了不少。
呼吸动画的帧率问题
呼吸引导的核心交互是一个随呼吸节奏变化的视觉动画。我一开始用 SwiftUI 的 withAnimation 来做，效果还行，但在低端设备上偶尔会掉帧。
后来我加了一套性能监控的逻辑，在开发阶段记录每帧渲染时间。这事儿其实有点过度工程了，一个呼吸 App 要啥性能监控？但当时刚好在学这块，就顺手写了。
实际有用的发现是：动画的 quality 参数需要做自适应。高端机跑高画质，检测到连续掉帧就降级。我在项目里定义了三档——high、balanced、low，根据实时帧率动态切换。
enum RenderQuality: String {
case high, balanced, low
}
// 连续 5 帧超过 20ms 就降一档
func evaluateAdaptation(recentFrameMs: [Double]) -> RenderQuality? {
let threshold = 20.0
let slowCount = recentFrameMs.suffix(5).filter { $0 > threshold }.count
if slowCount >= 4 { return .low }
if slowCount >= 2 { return .balanced }
return nil
}
说实话这个逻辑上线后几乎没被触发过，因为呼吸动画本身就不是什么高负载场景。但写这段代码的过程让我对 SwiftUI 的渲染管线理解深了不少，算是副产品吧。
国际化：被低估的工作量
我做了中英双语支持。一开始觉得不就是翻译嘛，能有多少工作量？
结果发现最烦的不是翻译本身，而是保持两份语言文件的 key 同步。加一个新功能，中文写了忘了英文，或者英文的 key 拼写跟中文对不上。我后来写了个脚本专门检查两份文件的 key 是否一致，每次提交前跑一遍。
这种事情不大，但不处理就会慢慢腐烂。到某天突然发现某个页面英文版全是 key 值没翻译，用户看到一堆 program_progress_title 之类的字符串，那就很尴尬了。
做了什么没做什么
做了的：
- 4-7-8、盒式呼吸、等比呼吸等多种训练模式
- 结构化课程系统，有进度追踪
- 训练历史记录，本地存储
- 中英双语
- 动画帧率自适应
没做的，或者说故意不做的：
社交功能。不做排行榜，不做分享打卡到朋友圈。呼吸训练是一件很私人的事，我不想让用户在练习结束后弹一个"分享到微信"的弹窗，那样会破坏刚建立起来的平静感。
云同步。目前所有数据都在本地。有用户问过能不能换手机同步数据，这个需求是合理的，但我暂时不想引入账号体系和后端服务。独立开发者维护一个后端的成本比大家想象的高得多——不是写代码的成本，是持续运维的成本。
订阅制付费。现在是一次性买断。我试过把部分课程设为订阅解锁，但转化数据很难看（说难听点就是没人买），干脆全部放开了。
一些数字和现状
坦白讲，这个 App 的商业表现很一般。最近 7 天下载量接近 0，付费也是 0。呼吸训练这个品类太小众了，而且免费替代品很多——甚至 Apple Watch 自带呼吸功能。
但我还在维护它，原因挺简单：我自己每天都在用。睡前做一组 4-7-8，开会前做 30 秒盒式呼吸，已经变成习惯了。
如果你也在做类似的小工具型 App，我觉得有一个经验值得分享：不要一开始就想着做平台、做社区、做增长飞轮。先做一个你自己离不开的东西。 用户量可以慢慢来，但如果连你自己都不用，那这个项目大概率会烂尾。
后续打算
1.9 版本刚更新完，接下来想做的事：
- 加一个 Widget，在桌面上直接显示今天有没有练习、连续打卡天数
- 试试用 HealthKit 把训练数据写入"正念分钟数"，跟系统健康数据打通
- 优化课程编辑器，让用户自定义呼吸节奏组合
对了，如果有人对呼吸训练的科学依据感兴趣：4-7-8 呼吸法是 Andrew Weil 博士推广的，核心原理是通过延长呼气时间激活副交感神经。盒式呼吸（吸-屏-呼-屏各等长）是美国海军 SEALs 的标准训练内容。这些不是玄学，是有生理学基础的。
你们平时有没有用过类似的工具？或者说，你们写代码写累了一般怎么放松？
