1. 为什么我要手搓一个时间管理APP的Demo
先交代背景。我在移动端开发这条线上摸爬滚打有些年头了，做过工具类、社交类、效率类各种App，但一直有个心结：市面上绝大多数时间管理App，要么功能堆到臃肿得像个企业级OA系统，要么简单到只剩一个番茄钟计时器。真正能让人“愿意每天打开、打开后不焦虑、用完确实有产出”的产品，少之又少。
于是去年年底我给自己立了个小项目：从零做一个时间管理类APP的Demo版本。注意，是Demo，不是要上架的商业产品。目标很明确——用最小的成本，把“任务收集→优先级排序→时间块规划→执行反馈”这条核心链路跑通，验证交互逻辑是否顺畅，顺便把几个技术选型上的疑问一次性解决掉。
这个Demo适合谁看？如果你是独立开发者，想快速验证一个效率工具的产品想法；如果你是移动端新手，想找一个有完整业务闭环的练手项目；或者你只是对时间管理方法论感兴趣，想看看一个App是怎么把GTD、番茄工作法、时间块这些概念落到代码里的——那这篇内容应该能给你不少参考。
我全程用的是跨平台方案，一套代码同时跑Android和iOS，本地数据存储，没有后端。整个Demo从设计到能跑通核心流程，大概花了三周左右的业余时间。下面我把设计思路、技术选型、核心模块实现、踩过的坑，全部摊开来讲。
2. 整体设计与技术选型拆解
2.1 核心功能边界怎么划
做Demo最容易犯的错，就是什么都想做。我一开始列了个功能清单，写着写着发现已经能对标一个成熟商业产品了——任务管理、日历视图、番茄钟、数据统计、标签系统、提醒推送、云同步……这要是全做，三个月都收不了尾。
所以我给自己定了一条铁律：Demo只验证一条主链路，其余全部砍掉或做最简实现。最终确定的核心功能只有四个：
- 任务快速录入：支持标题、预估时长、优先级三个字段，其他一律不要
- 今日视图：按优先级和时间块展示当天要做的任务
- 专注计时：选中一个任务，启动倒计时，结束后记录实际用时
- 简单回顾：当天完成了几个任务、实际用时和预估用时的对比
砍掉的功能包括：账号体系、云同步、多设备、复杂标签、子任务、协作。这些不是不重要，而是它们不影响主链路验证，等核心逻辑跑通了再逐步加。
这里有个经验：Demo阶段每增加一个功能，你的调试成本不是线性增长，而是指数增长。因为功能之间会产生交互，状态管理会迅速复杂化。宁可功能少而精，也不要多而乱。
2.2 技术选型背后的取舍逻辑
技术选型我主要考虑三个维度：开发效率、跨平台一致性、以及后续可扩展性。最终方案如下：
| 维度 | 选型 | 理由 |
|---|---|---|
| 开发框架 | Flutter | 一套代码双端一致，UI渲染性能好，热重载开发快 |
| 状态管理 | Provider | 轻量，学习成本低，Demo阶段够用，不引入过度设计 |
| 本地存储 | SQLite（sqflite） | 结构化数据，支持复杂查询，比键值对存储更适合任务数据 |
| 时间处理 | 系统原生DateTime + intl | 不引入重型日期库，减少依赖 |
| 通知提醒 | flutter_local_notifications | 本地通知，无需后端推送 |
为什么不用React Native？我两个都用过，RN在复杂列表和动画上偶尔会有性能抖动，而时间管理App里任务列表滚动、计时器动画都是高频操作，Flutter的自绘引擎在这块更稳。为什么不用原生分别开发？因为这是Demo，双端各写一遍的时间成本我承担不起，跨平台方案能让我把精力集中在业务逻辑上。
状态管理这块我要多说一句。很多人一上来就上Riverpod、Bloc，甚至自己搭一套架构。对于Demo来说，这是典型的过度工程。Provider的ChangeNotifier模式，对于“任务列表变化→UI刷新”这种场景，简单直接，代码量少，调试也直观。等产品真的复杂到需要更细粒度的状态隔离时，再迁移也不迟。
2.3 数据模型设计的关键决策
数据模型是整个App的地基，设计不好后面改起来很痛苦。我最终设计了两个核心表：
任务表（tasks）字段包括：id、title、priority（0/1/2对应低中高）、estimated_minutes、actual_minutes、status（待办/进行中/已完成）、created_at、completed_at、scheduled_date。
专注记录表（focus_sessions）字段包括：id、task_id、start_time、end_time、duration_minutes、completed（是否完整走完计时）。
这里有个设计决策值得展开说：为什么把专注记录单独建表，而不是直接在任务表里加个字段？因为一个任务可能被多次专注（比如一个预估2小时的任务，你可能分四次、每次30分钟来完成）。单独建表能记录每一次专注的明细，后续做统计时能算出“平均单次专注时长”“中断次数”这类有价值的指标。如果只存一个总时长，这些信息就丢失了。
另外，priority我用整数0/1/2而不是字符串，是为了排序方便——SQL里直接ORDER BY priority DESC就行，不用做字符串映射。这种小细节在Demo阶段可能感觉不到好处，但养成习惯后，代码会干净很多。
3. 核心模块的实操实现细节
3.1 任务快速录入的交互设计
任务录入看起来简单，但它是用户最高频的操作，体验好坏直接决定用户愿不愿意用。我的设计原则是：三秒内完成一条任务录入。
具体实现上，我用了一个底部弹出的输入面板，而不是跳转新页面。为什么？因为跳转页面有转场动画，心理上会觉得“重”，而底部弹出面板感觉“轻”，更符合快速记录的场景。面板里只有三个输入项：标题（文本输入）、预估时长（滑动选择，15分钟到4小时）、优先级（三个按钮切换）。
这里有个细节：标题输入框自动聚焦，键盘弹起。用户打开App，点一下加号，直接就能打字，不需要再点一下输入框。这个小小的优化，实测能省掉用户大概0.5秒的操作时间，但心理感受上的流畅度提升很明显。
代码层面，我用了一个showModalBottomSheet来承载输入面板，配合TextEditingController管理输入状态。预估时长用Slider组件，设置divisions为15（因为范围是15到240分钟，步长15分钟，共15个档位）。优先级用ToggleButtons，三个选项互斥。
// 预估时长滑块的核心配置 Slider( value: _estimatedMinutes.toDouble(), min: 15, max: 240, divisions: 15, label: '${_estimatedMinutes}分钟', onChanged: (value) { setState(() { _estimatedMinutes = value.round(); }); }, )注意：Slider的divisions参数如果不设置，滑动是连续的，用户很难精确选到想要的数值。设置成15之后，每滑动一格就是15分钟，手感清晰很多。这个参数很多人会忽略，但对体验影响不小。
3.2 今日视图的排序与分组逻辑
今日视图是用户打开App后看到的第一个界面，它要回答一个问题：“我现在该做什么？”所以排序逻辑至关重要。
我的排序规则是这样的：先按状态分组（进行中的任务排最前，然后是待办，最后是已完成），同组内按优先级降序，优先级相同再按创建时间升序。这样用户一眼就能看到“正在做的事”和“接下来最该做的事”。
分组展示上，我用了一个ListView配合SliverStickyHeader，让分组标题在滚动时吸顶。已完成的任务默认折叠，点击才展开，避免已完成任务占据太多视觉空间造成干扰。
这里有个我踩过的坑：一开始我按优先级排序，结果高优先级的任务永远排在最上面，用户每天看到的都是同样的几个“重要任务”，反而产生了压迫感。后来我改成“进行中优先”，只要用户开始了一个任务，它就自动置顶，这样视觉焦点跟着用户的实际行动走，而不是跟着抽象的优先级走。这个改动之后，我自己用起来舒服多了。
排序的SQL实现大概是这样：
SELECT * FROM tasks WHERE scheduled_date = ? ORDER BY CASE status WHEN 'doing' THEN 0 WHEN 'todo' THEN 1 WHEN 'done' THEN 2 END, priority DESC, created_at ASC用CASE WHEN做自定义排序，比在Dart层做排序更高效，尤其是任务量大的时候。而且SQLite对CASE WHEN的支持很好，不用担心兼容性。
3.3 专注计时器的实现与状态保持
专注计时是时间管理App的核心功能，也是最容易出bug的地方。核心难点有三个：计时精度、后台运行、状态恢复。
计时精度方面，我没有用Timer.periodic每秒减一的方式，因为这种方式在App卡顿或系统调度延迟时会累积误差。我的做法是记录开始时间戳，每次刷新时用当前时间 - 开始时间计算已过去多久，然后算出剩余时间。这样即使刷新有延迟，显示的时间也是准确的。
// 计算剩余时间的核心逻辑 final elapsed = DateTime.now().difference(_startTime); final remaining = _totalDuration - elapsed; if (remaining <= Duration.zero) { _completeSession(); } else { setState(() { _remainingSeconds = remaining.inSeconds; }); }后台运行方面，Flutter的Timer在App进入后台后会被系统挂起，这是所有移动端开发者都会遇到的问题。我的处理方式是：在App生命周期回调里监听AppLifecycleState，当App进入后台时，记录当前时间戳；回到前台时，重新计算已经过去的时间，更新计时器状态。这样即使用户切出去刷了十分钟消息再回来，计时器显示的时间也是对的。
状态恢复方面，我把计时器的开始时间、总时长、关联任务ID存到了本地存储里。如果App被系统杀掉后重新打开，能从存储里恢复计时状态。这个功能在Demo阶段其实可以不做，但我还是加上了，因为“计时到一半App崩了，进度全丢”是用户最不能忍受的体验之一。
实操心得：计时器这类功能，一定要用“时间戳差值”而不是“累加计数”的方式来实现。累加计数在理想环境下没问题，但真实设备上，系统调度、内存回收、后台限制都会导致计数不准。时间戳差值是幂等的，无论中间发生什么，结果都是对的。
3.4 数据统计与回顾的轻量实现
回顾功能我做得非常克制，只展示三个数字：今日完成任务数、今日专注总时长、预估准确率（实际用时/预估用时的比值）。
预估准确率这个指标我觉得特别有价值。很多人做时间管理失败，根本原因不是不努力，而是对自己完成任务所需时间的预估严重偏离实际。有人觉得自己写一份报告只要1小时，实际花了3小时，然后产生挫败感。通过记录预估和实际的差异，用户能逐渐校准自己的时间感知，这才是时间管理App真正的价值所在。
统计数据的查询我用了一条聚合SQL搞定：
SELECT COUNT(CASE WHEN status = 'done' THEN 1 END) as completed_count, SUM(actual_minutes) as total_minutes, AVG(CASE WHEN actual_minutes > 0 THEN CAST(actual_minutes AS REAL) / estimated_minutes END) as accuracy_ratio FROM tasks WHERE scheduled_date = ?用一条SQL算出所有指标，比多次查询再在代码里合并要高效。而且SQLite的聚合函数性能很好，即使几千条数据也是毫秒级返回。
4. 开发过程中踩过的坑与排查实录
4.1 常见问题速查表
| 问题现象 | 可能原因 | 排查思路 | 解决方案 |
|---|---|---|---|
| 任务列表滚动卡顿 | 列表项重建开销大 | 用Flutter DevTools的Performance面板抓帧 | 给列表项加const构造，用ListView.builder懒加载 |
| 计时器后台回来时间不对 | Timer被系统挂起 | 打日志确认前后台切换时间点 | 改用时间戳差值计算，监听生命周期回调 |
| 数据保存后重启App丢失 | 数据库路径错误或未await | 检查getDatabasesPath返回值 | 确保数据库初始化在App启动时完成，操作加await |
| 通知不触发 | 权限未申请或通道未创建 | 检查系统通知权限和通知通道配置 | 在App启动时申请权限，创建高优先级通知通道 |
| 优先级排序结果不符合预期 | 排序字段类型不一致 | 打印排序前后的数据 | 统一用整数存储优先级，SQL排序时确认字段类型 |
4.2 几个让我印象深刻的坑
第一个坑：SQLite的并发写入问题。我在测试时发现，快速连续添加多条任务时，偶尔会有任务丢失。排查后发现是多个数据库操作并发执行导致的。SQLite在移动端默认是串行执行的，但如果多个Future同时发起写操作，可能会互相干扰。解决方案是用一个队列来串行化数据库写操作，或者用事务包裹批量操作。
第二个坑：Flutter的热重载和状态管理冲突。开发过程中我频繁使用热重载，但发现有时候热重载后Provider里的状态会重置，导致界面显示异常。后来才明白，热重载会保留Widget树但重建State，如果状态存在StatefulWidget里而不是Provider里，就会出现不一致。解决方案是把所有需要跨页面共享的状态都放到Provider里，StatefulWidget只管理纯UI状态。
第三个坑：时间块的边界处理。我最初设计时间块时，假设用户会严格按照规划执行。但实际使用中，用户经常提前完成或超时。如果时间块是固定不可变的，用户就会频繁手动调整，体验很差。后来我改成了“软时间块”——时间块只是建议，用户可以随时拖动调整，系统会自动重新计算后续时间块的位置。这个改动让整个规划流程灵活了很多。
避坑技巧：Demo阶段一定要自己当用户，每天用自己做的App。很多问题不是代码层面的，而是交互逻辑层面的。比如我用了三天才发现，每次完成任务后需要手动切换到“已完成”标签才能看到完成记录，这个操作路径太长了。后来改成完成任务后自动在列表里标记为完成状态并淡出，用户不需要任何额外操作。
4.3 性能优化的几个实用手段
Demo虽然用户量小，但性能问题该注意还是要注意，因为这些问题在产品化之后会被放大。
列表渲染优化：任务列表用ListView.builder而不是ListView，前者只构建可见区域的item，后者会一次性构建所有item。任务量上百条时，差距非常明显。另外，列表项的Widget尽量用const构造，减少重建开销。
数据库索引：在scheduled_date和status字段上建了索引。虽然Demo数据量小，查询快慢感觉不出来，但养成建索引的习惯很重要。一条CREATE INDEX idx_tasks_date ON tasks(scheduled_date)就能让查询从全表扫描变成索引查找。
图片和资源：Demo里没有用图片资源，所有图标都用Flutter内置的Material Icons。这既减小了包体积，也避免了图片加载带来的性能开销。如果后续要加自定义图标，建议用SVG而不是PNG，矢量图在任何分辨率下都清晰，而且文件更小。
启动时间优化：App启动时只做必要的初始化——数据库连接、Provider注册、通知权限申请。其他非紧急的初始化（比如统计数据的预加载）放到首帧渲染之后再做。这样用户感觉App启动很快，实际上是把耗时操作延后了。
5. 如果要把这个Demo继续做下去
Demo跑通之后，我认真想过后续的扩展方向。这里分享几个我觉得最有价值的方向，也是我自己接下来可能会做的。
第一个方向是数据导出与备份。现在数据全在本地SQLite里，用户换设备就全丢了。最简单的方案是支持导出为CSV或JSON文件，用户自己保存。稍微复杂一点的是接入系统级的备份机制。这个功能不需要后端，实现成本低，但对用户价值很大。
第二个方向是时间感知的个性化校准。现在预估准确率只是一个展示指标，如果能让它反过来影响用户体验就更有价值了。比如用户预估一个任务要1小时，但系统根据历史数据发现他同类任务平均要1.5小时，可以给出一个温和的提示。这种“系统比你更了解你自己”的体验，是时间管理App的差异化竞争力。
第三个方向是专注模式与系统联动。现在专注计时只是一个App内的计时器，如果能在专注期间自动开启系统免打扰、屏蔽其他App通知，那专注体验会好很多。这需要调用系统级的API，不同平台实现方式不同，但技术上可行。
第四个方向是极简的数据可视化。现在回顾页面只有三个数字，如果加一个简单的周视图柱状图，展示每天专注时长的变化趋势，用户能更直观地看到自己的进步。图表库我倾向于用轻量的fl_chart，不引入重型图表方案。
不过话说回来，Demo阶段最重要的不是功能多，而是核心链路是否顺畅。我现在每天用自己做的这个Demo管理任务，虽然功能简陋，但“录入→规划→专注→回顾”这条链路跑下来很顺，没有明显的卡顿和逻辑断裂。这对我来说，Demo的目标就已经达到了。
最后分享一个我在做这个项目时最大的体会：时间管理App的本质不是管理时间，而是管理注意力。用户打开App的那一刻，他的注意力是有限的、易碎的。每一个多余的点击、每一次不必要的等待、每一处让人困惑的交互，都在消耗他的注意力。所以做这类产品，克制比丰富更重要，流畅比强大更重要。这个原则贯穿了我整个Demo的设计和开发过程，也是我觉得最值得分享给同行的一点。
