1. 项目缘起：为什么我们需要一个更“懂你”的生理期追踪工具？
在数字健康领域，生理期追踪应用早已不是什么新鲜事物。市面上从功能简单的日历记录，到集成了AI预测、社区交流、健康咨询的“全家桶”式应用，选择多到让人眼花缭乱。作为一名长期关注个人健康数据管理的开发者，我几乎试用过所有主流产品。但用了一圈下来，一个核心痛点始终挥之不去：这些应用要么过于“傻瓜”，记录几个日期就完事，预测准确度堪忧；要么过于“臃肿”，社交、电商、广告推送层出不穷，核心的追踪和预测功能反而被淹没在繁杂的界面里。
更关键的是，大多数应用对用户数据的处理方式让我感到不安。它们往往要求过多的权限，数据同步到云端后的隐私政策也语焉不详。生理周期数据是极其私密的健康信息，它不仅能反映生殖健康状态，还与情绪、精力、甚至某些慢性疾病有着千丝万缕的联系。把这些数据完全交给一个不了解其背后商业逻辑的第三方平台，风险不言而喻。
于是，一个想法诞生了：为什么不自己动手，打造一个完全由自己掌控、专注于核心追踪与预测、且足够轻量灵活的生理期追踪工具？这就是“Cylo Period Tracker”项目的起点。它的目标不是做一个功能大而全的商业应用，而是构建一个高度可定制、隐私优先、预测算法透明可调的个人健康数据助手。你可以把它看作是你的数字健康笔记本，记录什么、如何分析、数据存于何处，完全由你决定。
2. 核心设计哲学：隐私、透明与用户主权
在启动任何代码之前，明确的设计原则至关重要，这决定了产品的最终形态和用户体验。对于Cylo，我确立了三个不可妥协的核心原则。
2.1 隐私即默认
这是Cylo的基石。所有数据在默认情况下都只存储在用户的本地设备上。应用不会主动请求网络权限，更不会在后台偷偷同步数据到任何服务器。这意味着，即使你断网使用，所有功能依然完整。数据备份可以通过用户主动选择导出为加密的本地文件（如JSON或SQLite备份），然后自行通过可信渠道（如手动拷贝到电脑或加密云盘）进行管理。这种设计虽然牺牲了跨设备无缝同步的便利性，但换来了对个人数据的绝对控制权，对于注重隐私的用户来说，这是值得的。
2.2 算法透明与可干预
市面上很多应用的预测功能像个黑盒，你只知道“它说哪天来”，但不知道“它为什么这么说”。Cylo反其道而行之。其预测算法基于经典的周期追踪原理，并且向用户开放关键参数。例如，用户可以手动调整：
- 周期长度基准值：应用会根据历史数据计算一个平均周期，但用户可以基于对自己身体的了解，手动微调这个基准。
- 黄体期长度：这是一个关键但个体差异很大的参数。Cylo会提供一个医学上常见的默认值（如14天），但用户可以根据基础体温或排卵试纸的记录来校准它，从而大幅提升预测精度。
- 算法模型：初期可能采用简单的“历史平均法”，但架构上预留了接口，未来可以集成更复杂的统计模型（如移动平均、回归分析），甚至允许高级用户选择不同的预测模型。
这种透明化设计，让预测从“玄学”变成了“可理解的科学”，用户不再是被动接受结果，而是参与到预测模型的“训练”和“校准”中。
2.3 轻量、专注与可扩展
Cylo的界面将极度简洁，核心就是“记录”和“查看”。没有社交动态，没有商城入口，没有无关的健康文章推送。所有功能都围绕“周期”这个核心展开。但同时，它通过“插件化”或“模块化”的思想保持可扩展性。例如，核心应用只负责记录经期日期、流量、症状（如腹痛、情绪波动）。但如果用户想记录基础体温以更精确地锁定排卵日，这可以作为一个可选的“体温记录模块”来添加。想连接蓝牙体重秤？那可以是另一个“健康数据接入模块”。这种架构确保了核心的纯净，又能满足不同用户的深度需求。
3. 技术架构与核心模块实现
确定了理念，接下来就是将其落地。Cylo的技术选型需要兼顾跨平台能力、本地数据安全、以及良好的性能。
3.1 技术栈选型：Flutter + Hive + 原生插件
经过权衡，我选择了以下技术组合：
- 前端框架：Flutter。这是实现“一套代码，多端部署”（iOS和Android）最高效的选择。其丰富的UI组件和流畅的性能，足以构建一个体验优秀的健康类应用。Dart语言的强类型特性也有助于减少数据逻辑错误。
- 本地数据库：Hive。放弃更常见的SQLite，选择Hive，主要出于两点考虑：一是性能，Hive是一个纯Dart实现的轻量级键值数据库，在读写速度上，尤其是大量小数据操作时，比通过FFI调用SQLite的插件有优势。二是简洁性，对于周期记录这种结构相对固定的数据，用Hive的TypeAdapter进行序列化/反序列化非常直观，代码更简洁。
- 数据加密：Flutter Secure Storage + 自定义加密层。Hive本身支持AES加密，但密钥的存储是个问题。我们的方案是：使用
flutter_secure_storage插件（在iOS上利用Keychain，在Android上利用Keystore）来安全地存储加密Hive盒子的密钥。对于导出的备份文件，我们会在导出时使用用户自定义的密码进行额外的AES-256加密，确保即使文件被他人获取，也无法轻易解密。 - 图表与计算：纯Dart算法 +
charts_flutter库。所有预测计算逻辑都用纯Dart实现，确保算法透明且不依赖网络。数据可视化则使用charts_flutter这个相对底层的库，虽然需要更多配置代码，但能实现高度定制化的图表，比如在周期日历上高亮易孕期、排卵期，绘制症状趋势曲线等。
注意：选择Hive而非SQLite，在开发初期会非常高效。但当需要复杂查询（如“查询所有伴有剧烈腹痛的经期记录”）时，Hive需要手动遍历数据，此时SQLite的索引优势就体现出来了。因此，在架构设计上，数据访问层（DAO）被抽象出来，未来如果数据复杂度增长，可以平滑地将底层存储替换为SQLite而无需重写大量业务逻辑。
3.2 数据模型设计：如何科学地定义一次“周期”
这是项目的核心。一个粗糙的“开始日期-结束日期”模型远远不够。Cylo的数据模型需要能刻画周期的细微之处。
// 简化版的数据模型示例 class MenstrualCycle { String id; // 唯一标识 DateTime startDate; // 周期开始日（即经期第一天） DateTime? endDate; // 经期结束日（可选，用于计算经期长度） int flowLevel; // 流量等级，1-5，用户自定义 List<Symptom> symptoms; // 症状列表，如[‘cramps‘， ’bloating‘] String? note; // 自定义备注 // 以下字段由系统根据前后周期关系计算得出 int? cycleLength; // 本次周期长度（从上一次开始日到本次开始日） int? periodLength; // 本次经期长度 DateTime? predictedNextStart; // 预测的下次开始日 } class Symptom { String name; int intensity; // 强度等级 }这个模型的关键在于，cycleLength（周期长度）和predictedNextStart（预测日期）不是用户直接输入的，而是系统根据连续记录的startDate自动计算和预测的。这保证了数据的客观性和一致性。
3.3 预测算法实现：从简单平均到智能学习
预测功能是评判一个追踪器好坏的关键。Cylo的预测模块采用分层设计，从简单到复杂。
第一层：简单历史平均法这是基线算法。计算过去3到6个周期的平均长度，然后从最近一个周期开始日加上这个平均长度，得到预测的下次开始日。这是最直观的方法，适用于周期非常规律的用户。代码实现简单，但无法应对周期波动。
第二层：加权移动平均法为了更贴近近期趋势，我们引入加权平均。给最近的周期赋予更高的权重。例如，最近一个周期权重为0.5，前一个0.3，再前一个0.2。这样，如果用户最近周期有变短或变长的趋势，预测结果能更快地反映出来。
// 加权移动平均预测示例（简化逻辑） DateTime predictNextStart(List<MenstrualCycle> pastCycles) { if (pastCycles.length < 2) return null; // 数据不足，无法预测 List<double> weights = [0.5， 0.3， 0.2]; // 权重配置，可调 double weightedSum = 0; double weightSum = 0; for (int i = 0; i < min(weights.length， pastCycles.length - 1); i++) { int length = pastCycles[i].cycleLength; weightedSum += length * weights[i]; weightSum += weights[i]; } int predictedLength = (weightedSum / weightSum).round(); return pastCycles.last.startDate.add(Duration(days: predictedLength)); }第三层：基于黄体期校准的算法这是提升准确性的关键。女性的周期长度波动主要来自卵泡期（排卵前），而黄体期（排卵后到经期前）相对稳定，通常在12-16天。如果用户记录了基础体温或使用了排卵试纸，能大致确定排卵日，那么就可以使用“排卵日 + 固定黄体期长度（如14天）”来预测经期，这比单纯算周期长度要准确得多。Cylo的UI上会有一个“疑似排卵日”的标记（由用户根据体温曲线或身体症状手动标记），一旦标记，预测算法会优先采用此方法。
未来扩展：机器学习模型在应用内预留一个“高级预测实验室”模块。用户可以自愿选择将匿名化的、脱敏的历史周期数据用于在设备本地训练一个简单的时序预测模型（例如，使用tflite_flutter集成一个轻量级LSTM网络）。训练和预测全部在本地完成，数据不出设备。这为周期不规律的用户提供了更个性化的预测可能。
4. 用户界面与交互设计：极简背后的深思熟虑
UI设计遵循“零学习成本”原则。主界面可能就是一个大的日历视图，结合一个简洁的记录浮窗。
4.1 核心交互：快速记录与可视化反馈
- 日历视图：每一天的格子不仅是日期，也是信息载体。经期日期用色块清晰标出（颜色深浅可代表流量）。预测的经期、易孕期、排卵日分别用不同的虚线边框或浅色背景提示。长按某一天，可以快速记录或查看那天的详细症状和笔记。
- 快速记录浮窗：从屏幕边缘滑出或底部弹出，包含“经期开始/结束”、“流量”（用水滴图标选择）、“常见症状”（腹痛、胸胀、情绪低落等图标）的快速选择按钮。记录过程应在10秒内完成。
- 图表视图：除了日历，提供曲线图展示周期长度、经期长度的历史变化趋势，让用户一目了然地看到自己周期的稳定情况。症状频率也可以生成统计图表。
4.2 数据管理与备份：用户完全掌控
设置页面最重要的部分就是数据管理。
- 导出备份：一键生成一个包含所有记录、设置和模型参数的加密压缩文件。用户可以自定义加密密码（应用会强制要求密码达到一定强度）。文件可以保存到手机本地文件夹，方便用户自己通过其他工具管理。
- 导入恢复：从本地选择备份文件，输入密码解密，并预览将要恢复的数据。恢复过程提供“合并”与“覆盖”选项，防止误操作导致新数据丢失。
- 数据清除：提供“清除所有数据并重置应用”的选项。这不仅仅是删除数据库文件，还包括清除所有SharedPreferences设置和Secure Storage中的密钥，确保隐私数据被彻底移除。
5. 开发中的挑战与实战心得
在实际构建Cylo的过程中，遇到了不少预料之外的问题，也积累了一些宝贵的经验。
5.1 本地数据同步与冲突解决
虽然Cylo主打本地存储，但用户仍有在手机和平板间同步的需求。我们通过“手动导出-导入”来实现，但这引入了数据冲突的问题。例如，用户在手机A上记录了今天的经期开始，然后在手机B上（未导入最新备份）记录了今天的症状，之后将两个设备的数据分别导出，再试图合并时就会冲突。
解决方案：我们在每条记录中都增加了lastModified时间戳（精确到毫秒）和deviceId（设备标识符）。在实现“合并”功能时，采用简单的“最后修改者胜出”规则。更复杂的方案可以实现一个类似Git的三向合并，但对于个人健康数据，简单明确的规则更可取。在UI上，合并前会向用户清晰展示所有冲突条目，让用户手动选择保留哪一个。
5.2 预测算法的“冷启动”与不确定性表达
新用户安装应用后，没有任何历史数据，预测功能无法工作。如何引导用户并管理其预期？
处理方式：应用会坦诚地告知用户：“我需要至少记录2次完整的经期开始日期，才能开始学习你的模式并尝试预测。” 在等待期间，日历上可以显示基于全球女性平均周期（28天）的参考性提示，但必须明确标注为“仅供参考，非个性化预测”。当有了一些数据后，预测结果也不应是一个确切的日期，而是一个日期范围（例如“预计在10月25日至10月29日之间”），并附带一个置信度（如“基于您3个周期记录，预测置信度为中等”）。这种表达方式更科学，也避免了用户因某次预测不准而完全失去信任。
5.3 国际化与本地化的细节
生理期相关的词汇和文化习惯在不同地区差异巨大。例如，对症状的描述、对流量级别的表述、甚至日历的首日（周日或周一）都有不同偏好。
实战经验：不要硬编码任何UI字符串。所有文本都使用Flutter的intl包进行国际化。更重要的是，收集症状和流量的选项列表，应该允许用户自定义。提供一个默认的、经过医学审核的常见列表，但用户完全可以添加“腰酸”、“嗜睡”等个性化描述。日历的显示格式（是否显示农历、节日）也应可配置。这些细节决定了应用是“全球通用”还是“为你而生”。
5.4 测试策略：如何模拟千变万化的周期
测试这类应用，需要模拟大量不同规律的周期数据。手动创建费时费力。
我们的方法：编写了一个Dart脚本，作为独立的“数据生成器”。它可以模拟生成：
- 绝对规律：永远28天的周期。
- 略有波动：在26-30天之间随机波动的周期。
- 多囊卵巢综合征（PCOS）模拟：周期长度极不规律，可能在35-90天之间大幅跳跃。
- 围绝经期模拟：周期逐渐变长，然后变得不规律。
将这些模拟数据批量导入到开发中的App里，可以快速验证预测算法在不同场景下的表现，测试UI在超长周期或密集记录下的渲染性能，以及图表是否能正确展示异常趋势。这套模拟数据也成为了我们算法优化的基准测试集。
6. 隐私、伦理与未来思考
开发一个健康应用，尤其是涉及女性健康的应用，责任重大。这不仅仅是技术问题，更是伦理问题。
绝对避免的功能：我们坚决不做任何形式的“受孕概率”百分比提示。这种提示基于统计学，但对个体而言可能造成巨大的心理压力或误导。我们只提供基于生理知识的“易孕期”范围提示，并附上清晰的说明：“此提示仅基于周期推算，无法精确判断排卵，如需备孕请咨询医生并结合其他监测方法。”
数据匿名化研究：尽管Cylo数据不离设备，但我们思考过，如果未来想进行匿名化的群体趋势研究（例如，“季节变化是否影响周期规律性？”），该如何实现？一个可行的方案是，在用户明确同意并主动选择参与的前提下，应用在本地计算一些高度抽象的统计特征（如过去一年的周期长度标准差、平均经期长度），将这些特征值（而非原始日期记录）经过差分隐私技术处理后上传。这样既能保护个体隐私，又能为医学研究提供有价值的群体洞察。
开源与社区共建：Cylo的核心引擎（数据模型、预测算法、加密备份模块）计划开源。这既是为了践行透明原则，也是希望吸引更多开发者、甚至医学研究者参与进来，共同改进算法，开发新的分析模块（如与穿戴设备数据结合分析压力对周期的影响）。一个由用户和专业人士共同维护的开源项目，其可信度和长期生命力会远高于闭源的商业应用。
构建Cylo的过程，是一个将技术理性与人文关怀相结合的过程。它最终呈现的不仅仅是一个工具，更是一种态度：你的身体数据属于你，你应该能够以安全、透明、可理解的方式管理和使用它。在这个数据泛滥的时代，重新夺回对个人健康信息的控制权，或许是我们能为自己做的最重要的事情之一。这个项目还在持续迭代中，每一个设计决策和代码实现，都围绕着这个核心目标展开。
