打开 Android Studio 准备做新项目的时候，其实大多数人的状态都是“功能先跑起来再说”。我自己在做一款待办管理 App 时，也是抱着这个心态起步的。等真正跑到 day 5.6 这个节点——功能主干已经接通，界面能看、数据能存、列表能刷——我才发现，决定一个 App 最终交付质量的，往往是前期那些没被重视的细节：包结构怎么分、表格字段怎么定、状态到底该放哪、打包之前有没有做过稳定性检查。这篇文章就把我从架构选型到数据层、UI 状态管理再到打包优化这一整段实践，按真实开发顺序梳理出来。适合那些已经会用四大组件、写过几个 Demo，但想搞清楚一个完整 App 从“能跑”到“能交付”之间有哪些关键操作的开发者；如果你完全没接触过安卓开发，也可以把它当成一份完整流程概览来看。
1. 先想清楚再动手：模块边界与架构选型
1.1 为什么非要先定边界
写 App 最怕的不是功能复杂，而是功能多起来以后，代码已经不知道往哪里放了。我做这个待办 App 时，一开始就给自己定了三条硬规矩：任何界面逻辑不能直接访问数据库；数据库、网络相关的类全部放在 data 包；能被多个页面复用的业务能力必须下沉到 domain 层。这三条规矩看起来简单，但实际作用很大——哪怕隔了两周再看代码，我也不用靠回忆去猜“这个操作应该写在哪”。
我还干过一件很多人觉得没必要的事：写正式代码之前，先把包结构画出来。
app/src/main/java/... ├── data │ ├── local │ ├── repository ├── domain │ ├── model │ ├── usecase ├── ui │ ├── theme │ ├── todo │ │ ├── list │ │ ├── detail │ │ ├── add关注点不只是分层，而是单向依赖：ui 依赖 domain，data 实现 domain 里定义的 Repository 接口。这样做的好处是，如果某天我把本地数据库换成服务端接口，只需要改 data 层，UI 完全不用动。很多项目后期改起来费劲，问题就出在开始的时候没做这一层隔离。
页面的组织方式上，我选择了单 Activity 加 Compose 导航，而不是多 Activity。理由很实际：待办 App 页面数量不多，但页面之间共享的数据（比如当前选中的清单、待办列表状态）很多。单 Activity 让整个导航图更清晰，ViewModel 的共享范围也更好控制。如果你还在用传统 View 体系，等价的做法是把主要业务页面都放进 Fragment，让 Activity 只承担容器角色。我在早期项目里吃过“每个页面一个 Activity”的亏——页面间要传大量参数，Intent 的序列化代码写起来又臭又长，回头维护非常痛苦。
这里还有一个很常见的坑：直接在 ViewModel 里持有 DAO。我当时检查了一遍自己的代码，发现有个页面为了图省事，确实绕过了 Repository，直接在 ViewModel 里调 DAO。短期运行没问题，但一旦要加缓存、加数据转换，就必须改 ViewModel。这种“临时方便”会在后期付出更大代价，所以我后来强制规定 ViewModel 只能依赖 ViewModel 层或 usecase 层定义的接口，绝不访问具体数据源。
1.2 协程、Flow 与 MVVM 的落地方式
架构选型里最核心的决策是：UI 层和数据层之间用什么方式通信。我最终用了 MVVM + 协程 + Flow 这套组合，完全放弃 LiveData 作为主数据通道。
先解释一下为什么不用 LiveData。LiveData 的优势是生命周期感知，但它在 Compose 里的体验其实一般：操作符太少，遇到组合多个数据源的场景写起来很别扭。Flow 则配合协程可以做 map、combine、flatMapLatest 这类操作，数据管道更灵活。尤其 Room 自带 Flow 支持，数据库一变化，查询自动重跑，UI 不用手动刷新，这个是待办列表最需要的特性。
具体到代码组织上，我习惯把一个页面的状态建模成独立的 data class：
data class TodoListUiState( val items: List<TodoItemUi> = emptyList(), val isLoading: Boolean = true, val errorMessage: String? = null, val filter: TodoFilter = TodoFilter.ALL )ViewModel 里用一个 MutableStateFlow 持有这个状态，UI 通过collectAsStateWithLifecycle收集。所有用户操作都通过 ViewModel 对外暴露的方法触发，不在 Composable 里直接改状态。这样做最大的收益是状态来源单一——界面崩溃、数据异常时，只要盯着 ViewModel 查状态变化就行。
数据层到 UI 层的完整链路是：Room 返回 Flow 列表，Repository 把 Entity 映射成 Model，ViewModel 收集后合并到 UiState。写操作则用 suspend 函数实现，配合viewModelScope.launch调用。我在项目里验证过，这个链路在旋转屏幕、切后台回前台时都不会丢数据，因为 StateFlow 天然保存最新值，Room 的 Flow 也总会在重新订阅时发出当前数据。
有一点要特别强调：不要在 ViewModel 里用GlobalScope做异步任务。必须用viewModelScope，因为它在 ViewModel 销毁时自动取消协程，不会白白耗资源。我见过不少内存泄漏问题，追根溯源都是协程作用域用错了地方，这个细节一定要养成习惯。
2. 数据先行：Room 表结构设计与数据流实现
2.1 数据表字段设计：从需求逆推
数据层是所有功能的底座，表结构一旦定错，后面改起来代价极大。我在设计待办事项表时，不是上来就建表，而是先写了一遍完整的用户需求：用户可以创建待办、设置提醒时间、标记优先级、勾选完成、按清单分类。把这些需求一条条列出来，字段表就自然形成了。
@Entity( tableName = "todo_item", indices = [ Index(value = ["due_time"]), Index(value = ["completed"]) ] ) data class TodoEntity( @PrimaryKey(autoGenerate = true) val id: Long = 0, val title: String, val description: String? = null, val dueTime: Long? = null, val priority: Int = 0, val completed: Boolean = false, @ColumnInfo(name = "created_at") val createdAt: Long = System.currentTimeMillis(), @ColumnInfo(name = "updated_at") val updatedAt: Long = System.currentTimeMillis() )字段选择的几个关键点你可能会忽略，这里展开说一下。
第一，时间字段一律存 Long 时间戳，不要存字符串。有人喜欢存“2025-05-06 10:30”这种格式，看着直观，但排序、比较“是否已过期”、跨时区处理都非常麻烦。用System.currentTimeMillis()存 Long，需要展示时再格式化，需要计算差值时直接做数值运算，省心得多。
第二，优先级用 Int，不要用中文或英文枚举字符串。数据库里存字符串“高/中/低”虽然可读，但排序必须按自定义规则处理；存 0、1、2 这类整数，天然支持数值排序，UI 层再根据数值映射成文案和颜色即可。
第三，createdAt 和 updatedAt 要有默认值，但 updatedAt 必须手动更新。Room 不会像某些后端框架一样自动维护这两个字段。我当时就在编辑待办功能里漏了 updatedAt，导致“按更新时间排序”的列表一片混乱，查了很久才意识到是字段根本没人更新。
第四，不要图省事把所有结构塞进一个 JSON 字段。比如一个待办多个提醒时间，有人会用一个 String 字段存 JSON 数组，短期确实快。但后续一旦要查询“今天有哪些待办需提醒”，这个字段毫无办法进行数据库检索，只能全表拉出来再解析 JSON，性能差到难以接受。该拆表就拆表，该建关联就建关联。
2.2 DAO、Repository 与数据管道
表结构定好之后，紧接着就是 DAO 层。我之前写过不少“Google 官方示例风格”的 DAO，核心接口基本就是增删改查加观察。这里给出这个项目里最常用的一组：
@Dao interface TodoDao { @Query("SELECT * FROM todo_item WHERE completed = :completed ORDER BY due_time DESC, priority DESC") fun observeByCompleted(completed: Boolean): Flow<List<TodoEntity>> @Query("SELECT * FROM todo_item WHERE id = :id") fun observeById(id: Long): Flow<TodoEntity?> @Insert(onConflict = OnConflictStrategy.REPLACE) suspend fun insert(entity: TodoEntity): Long @Update suspend fun update(entity: TodoEntity) @Delete suspend fun delete(entity: TodoEntity) @Query("UPDATE todo_item SET completed = :completed, updated_at = :updatedAt WHERE id = :id") suspend fun updateCompleted(id: Long, completed: Boolean, updatedAt: Long) }可以看到返回结果基本都包了 Flow。这是 Room 最强大的地方：只要表数据发生变化，Flow 就会重新发射数据，界面无需主动调用刷新。列表页界面收到新数据后，自动重组更新，体验上非常顺滑。
Repository 这一层我坚持使用“页面只认 Repository，不认识 DAO”的原则。虽然多个页面共享同一个 DAO，但 Repository 可以统一处理 Entity 到 Model 的转换，还能在这里做业务校验。举个例子，当用户创建一个标题为空、时间又是过去的待办时，Repository 完全可以抛错拦截，避免脏数据进库。这个校验放到 ViewModel 里当然也行，但放到 Repository 的好处是：将来如果增加了其他入口（比如 Widget 快速添加），同样能复用。
还有一个容易踩的坑：批量写数据时不要在一个循环里逐条调insert()。每调一次 insert 都是一次事务，几百条数据就慢得肉眼可见。正确做法是定义带@Transaction的批量插入方法，把所有数据放在一个事务里写完。这个优化我是在测试时发现的——当时导入一批演示数据，循环插入磨了十几秒，改成批量事务后瞬间完成。
2.3 索引、迁移与性能经验
很多新手写建表语句时从不考虑索引，表数据量小的时候确实无所谓。但待办 App 的数据量会随着时间增长，一旦用户坚持记录两三年，每天的提醒和已完成事项累积到数千条甚至上万条，不带索引的查询就开始肉眼可见地变慢。我在创建表时给due_time和completed单独加了索引：因为列表页最常见的筛选就是“只显示未完成”和“按到期时间倒序”，有索引以后查询走索引扫描，比全表遍历快非常多。
需要提醒一点：索引不是越多越好。加索引会拖慢插入和更新速度，因为每次写数据时要同步维护索引。对待办这种低频写入高频查询的表，给常用查询字段加索引是划算的；但如果你把 description 这种长文本字段也建了索引，那纯属浪费空间。
再聊一下数据库升级时必踩的坑：表结构一变，千万不要直接删库重装。我在新功能里给待办增加“所属清单”字段时，最开始偷懒卸载重装 App，自己用倒是没问题，但真实用户的本地数据全没了，这在线上是不可接受的。正确方案是给 Room 配置 Migration：
val MIGRATION_1_2 = object : Migration(1, 2) { override fun migrate(db: SupportSQLiteDatabase) { db.execSQL("ALTER TABLE todo_item ADD COLUMN list_id INTEGER NOT NULL DEFAULT 0") } } Room.databaseBuilder(context, AppDatabase::class.java, "todo.db") .addMigrations(MIGRATION_1_2) .build()Migration 的核心价值是保留旧数据的前提下平滑升级。ALGTER TABLE 加字段是最简单的迁移；如果涉及改表结构、拆分表、合并表，一般要先去建临时表、拷贝数据、删除旧表、再重命名，这个过程最好在测试机上反复验证后再发布。
关于数据量级，我实际压过一万条待办数据，在加了索引的前提下，Flow 查询 + 列表滚动都保持流畅。如果未来数据更多，就要考虑分页加载或者按时间范围归档，这是后话，但架构上要预留好切换的余地。
3. UI 层不炫技：Compose 状态管理与事件交互
3.1 状态提升：单一数据源
如果说数据层解决的是“数据从哪来”，UI 层解决的就是“状态往哪放”。我在做 UI 时反复提醒自己的原则只有一条：所有跨页面的状态，必须放在 ViewModel；所有一次性输入状态，才放在 Composable 里。
什么是跨页面状态？比如待办列表的筛选条件、列表当前的数据快照，这些离开页面后还想保留；什么是临时状态？比如添加页面的标题输入框内容、日期选择器是否展开，这些页面销毁后无所谓。前者放 ViewModel，后者用rememberSaveable保存即可。
我用一个例子说明状态建模的差别。添加待办页面的标题输入框，我用的是rememberSaveable { mutableStateOf("") }，因为用户旋转屏幕时系统会自动帮你恢复字符串内容，不需要 ViewModel 参与。但“当前正在编辑的待办实体”这种数据，就必须放到 ViewModel，因为它是跨页面（从列表页跳转到编辑页）的共享数据。
UI 状态我统一封装成了前面那节的TodoListUiState。这里特别强调一下，列表页面还需要区分加载中、空数据、正常数据、错误这几种状态，而不是只放一个items列表。空数据展示一个“暂无待办”的提示，加载中显示进度条，错误时显示重试按钮，这些在 UiState 里都预先声明好。好处是 UI 逻辑变成纯分支判断，写起来很清晰。
实际操作时我还发现一个细节：StateFlow 的初始值要尽量真实。如果初始isLoading = true，但 items 有历史缓存，页面启动就会先闪一下加载动画再显示列表。这种情况下更合理的设计是isLoading = items.isEmpty()，或者用一个独立的isInitialLoading字段，避免界面闪烁。这种体验细节往往决定用户对 App 的第一印象。
3.2 列表、输入与多选操作
列表页是这个 App 的主战场，写起来有很多容易忽略的细节。先看一个最基础的 LazyColumn 写法：
LazyColumn( modifier = Modifier.fillMaxSize(), contentPadding = PaddingValues(16.dp), verticalArrangement = Arrangement.spacedBy(8.dp) ) { items( items = uiState.items, key = { it.id } ) { item -> TodoRow( item = item, onToggle = { viewModel.toggleCompleted(item.id) }, onClick = { onOpenDetail(item.id) } ) } }key参数极其重要。如果你不传 key，Compose 会使用索引来标识列表项；一旦列表项顺序变化（比如筛选后删除一条、勾选完成导致置底），已展开的输入状态、动画状态就会错乱。传了稳定 id 后，Compose 才能精确复用对应的组合项，这也是避免列表异常闪烁的关键。
多选操作是待办类 App 的常见需求。我的实现是让 ViewModel 持有一个selectedIds: Set<Long>，列表项点击时切换选中状态。这里要注意的是，切换操作不能在 Composable 里直接改集合——Set 不可变集合的+/-操作会创建新集合，如果把这段逻辑写在 UI 层，重组次数一多很容易出现状态不同步。放到 ViewModel 的updateSelectedIds()方法里管理，数据源才可控。
还有一个现实问题：快速点击“完成”按钮，可能触发两次更新。由于数据库更新操作本身是幂等的（把 completed 置为 true 两次结果一样），本地场景一般不会出大问题，但如果未来要同步到服务端，就必须在 ViewModel 里做防抖或者请求中状态标记，避免重复网络请求。我建议现在就把这个习惯养成：所有按钮的“正在处理中”状态要在 UiState 里体现，比如updatingIds: Set<Long>，正在更新的条目显示进度圈，同时禁掉重复点击。
滑动删除我用的是 Compose Material 3 的 SwipeToDismissBox。这里有个版本坑：不同 Material3 版本里这个组件的 API 变化很大，较早版本的SwipeToDismiss和后来的SwipeToDismissBox参数完全不同。如果你照着老教程写，编译会直接报错。我的建议是锁定 compose BOM 版本后去查对应版本的官方文档，别在组件 API 上浪费时间。另外，滑动删除时要弹确认对话框，用户误滑后还有反悔的机会，这个体验细节值得保留。
3.3 深浅色与动态字体适配
现在的 App 如果还只适配浅色模式，用户换到深色模式后屏幕会非常刺眼。好在 Compose 里做深浅色适配成本很低：主题直接用 Material3 的lightColorScheme()和darkColorScheme()，系统切换时通过isSystemInDarkTheme()判断，一套语义颜色变量自动映射到两套实际色值。
但这里有个实际问题：深色模式下，很多人简单地把白色背景换成黑色，结果文字、卡片、分割线对比度全都乱了。我建议从一开始就定义一套语义色，比如surface、surfaceVariant、primary、onSurface，所有组件都引用语义色而不是直接写死颜色值。这样切深色模式时，整个界面自动跟着变，不会有局部“反黑”的突兀感。
动态字体也是很容易忽略的崩溃来源。用户把系统字体调到最大后，很多原来固定高度的 Row 里的文字会被截断，甚至部分文本因为放不下而直接被裁剪。我的处理方案是所有列表项的高度都由内容撑开，不写固定height(56.dp)；标题文字超过两行时显示省略号，而不是强制单行截断。如果有多行标签排在一条水平 Row 里，优先用FlowRow让它自动换行，否则布局在超大字体下必崩。
平板或者分屏场景也不能不考虑。我遇到过用户在大屏设备上使用 App，列表内容拉得特别长，观感很糟糕。针对这种场景，我在列表外层套了一个Box，用Modifier.widthIn(max = 480.dp).align(Alignment.TopCenter)约束最大宽度，让内容在大屏上保持舒适阅读宽度。这个处理方式成本极低，但实际体验提升非常明显。
4. 能用不代表好交付：稳定、打包与发布前检查
4.1 内存、卡顿与协程泄漏
功能做出来之后，我给自己留了一个专门的时间段做稳定性排查。这个阶段不是拍脑袋找茬，而是有一套相对固定的检查流程。
第一件事排查卡顿。待办列表本身数据量不大，但我在测试时发现一个诡异的问题：列表滚动一段时间后会明显掉帧。事后定位到原因是列表项里的日期文本每次都重新格式化，而这个格式化操作里有比较重的SimpleDateFormat初始化。这个问题的教训是：所有高频调用的格式化操作，必须提前准备好变量，不要在列表项渲染时现场创建。改成在 Repository 映射 Model 时统一格式化后，掉帧问题直接消失。
第二件事排查协程泄漏。协程泄漏比内存泄漏隐蔽得多，因为你不会立刻看到 OOM，但它会一直浪费资源。一个典型场景：自定义 Composable 里创建了remember { CoroutineScope(SupervisorJob() + Dispatchers.Main) }，用户离开页面后没有取消这个 scope，里面的循环任务就一直跑。正确做法是使用rememberCoroutineScope()，它会自动跟随组合生命周期取消，或者自己接管 scope 并在DisposableEffect里 cancel。
第三件事做工具排查。LeakCanary 我建议直接集成进 debug 版本，装到测试机上跑一天日常操作，如果内存泄漏，它会直接弹通知告诉你泄漏位置。在正式发布前，这个工具能帮你拦截掉至少一半的内存问题。Profiler 则适合做定向分析，比如反复进出同一个页面，观察内存曲线是否不断爬升不回落。
我还有一个经验：给列表项的数据类做稳定性标记。Compose 中参数类型不稳定的情况会导致局部重组蔓延到整个列表。使用不可变数据类并且加@Immutable注解，能显著减少无谓重组。这个优化的收益在列表项数量超过一屏后非常明显。
4.2 权限、通知与后台限制
待办 App 的核心价值在于“到点提醒用户”，这就绕不开通知权限。Android 13 及以上版本把通知权限改成了运行时权限，必须动态申请，否则通知直接发不出去。
if (Build.VERSION.SDK_INT >= 33 && ContextCompat.checkSelfPermission(this, Manifest.permission.POST_NOTIFICATIONS) != PackageManager.PERMISSION_GRANTED ) { requestPermissions(arrayOf(Manifest.permission.POST_NOTIFICATIONS), 101) }这里有个体验细节：不要一进 App 就弹权限框，用户会反感。比较好的方式是在第一次创建带提醒的待办时，先解释“需要通知权限来提醒您完成任务”，再引导用户授权。如果用户拒绝，要保留一个“去设置页开启”的入口，因为系统权限框只能弹一次，再次申请必须跳到系统设置。
接着是“到点提醒”到底怎么实现。我一开始想得很简单——AlarmManager 设一个精确闹钟，时间到了发通知。实际在部分设备上一跑，发现系统省电策略会延迟甚至杀掉这个闹钟。这个问题在依赖系统厂商的定制 ROM 上尤其严重，你没法控制用户的系统设置。
我的最终方案是分场景处理：提醒精度要求高的场景用AlarmManager.setExactAndAllowWhileIdle()，能保证多数设备按时触发，但需要动态检查设备是否支持精确闹钟权限；对精度要求不高的场景（比如每天固定时间汇总），用 WorkManager 排一次性任务或周期任务更省电。而且 WorkManager 有一定容错能力，即使任务被系统延迟，最终也会补执行，适合“晚一会儿提醒也没关系”的场景。
测试的时候有个容易被忽略的点：把应用从最近任务里划掉后，通知是否还能正常发布。这个场景和进程被系统杀死是两回事，很多生产环境的问题都是这么复现出来的。如果断言发现应用被划掉后通知失效，就要考虑用前台服务保持进程关键任务，但长时间保活会牺牲电池，需要权衡业务价值。待办提醒这种场景，我不会过度设计，保持通知触发的可靠性即可。
4.3 构建、签名与多渠道打包
发布前的最后一道工序是构建配置。不少个人开发者把 App 装到手机上就完事了，但从“自用”到“给别人用”之间，还差一个体面的 release 包。
Gradle 配置里我最常用的是多渠道和构建类型分离：
android { defaultConfig { applicationId = "com.example.todotoday" versionCode = 2 versionName = "0.5.6" } productFlavors { create("dev") { applicationIdSuffix = ".dev" versionNameSuffix = "-dev" } create("prod") { // 正式包，不额外加后缀 } } buildTypes { release { isMinifyEnabled = true isShrinkResources = true proguardFiles( getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro" ) } } }dev和prod两种 flavor 的最大用途是隔离环境：开发包可以连测试服务器、输出详细日志、使用 Debug 签名；正式包则完全切断这些。不要小看这个区分，我见过有人在正式包里忘记关日志输出，结果线上用户一操作，关键业务数据全打到系统日志里了。
R8 混淆和资源压缩建议线上包打开。打开isMinifyEnabled后会去掉无用代码，isShrinkResources进一步去掉无用资源，包体积能缩小 20% 到 30%。但混淆有个经典问题：反射、序列化的类会被错误移除。比如你用 Gson 反序列化一个 Model 类，不加 keep 规则，R8 可能会把 Model 的字段名改乱，运行期直接崩溃。我的做法是在proguard-rules.pro里维护一份 keep 列表，把所有参与反射/序列化的类和成员加进去。
签名这件事必须反复强调：安卓应用签名 keystore 文件千万不能提交到版本库。我的做法是把签名配置通过环境变量传入 Gradle，keystore 放在本机固定目录，并加入.gitignore。一旦 keystore 丢失，你已经发布的 App 就永远无法用同一个包名升级，因为签名不一致，系统会拒绝覆盖安装，这对开发者来说是致命的。
最后是崩溃日志收集。个人项目初期不建议直接上重型平台，我自己的做法是先实现一个最简单本地方案：在Application里设置Thread.setDefaultUncaughtExceptionHandler，把未捕获异常写入本地文件，下次启动上传到自己的服务器。等用户量上来以后再考虑成熟平台。不要觉得这个不重要——没有崩溃日志，线上问题就只能靠用户口述“闪退了”，很难定位。
再分享一个我在 day 5.6 这个节点悟到的经验：如果你把应用发布出去了，一定要在某个隐藏入口保留一版“打印全部数据库诊断信息”的功能。我在某个版本里给 App 加了一个启动时健康检查：统计逾期未完成数量、检测数据表中是否存在明显异常值，一旦异常就输出到日志并自动清理部分缓存。这个功能看起来简单，却在用户端帮我避免了不少诡异问题。很多稳定性问题不是靠“提前预判”解决的，而是靠一个可靠的问题观测入口快速定位的。这个习惯，我建议你从第一个发布版本就开始养成。
