Android记账本大作业：从CRUD到工程化项目的进阶指南

Android开发Repository模式MVVM架构

于 2026-08-03 04:10:26 修改

·本内容遵循CC 4.0 BY-SA版权协议

上周帮一个学弟看他的 Android 记账本毕设项目，他遇到的问题很典型：功能都实现了，但代码结构一团乱麻，数据库操作和 UI 逻辑混在一起，想加个简单的月度统计都无从下手。他问我：“学长，我这项目能过吗？” 我看了看，功能点确实都覆盖了，但距离一个“合格”的工程作品，还差着几个关键的理解。

这其实不是他一个人的问题。很多计算机专业的同学在做 AndroidStudio 期末大作业或毕设时，容易陷入一个误区：把“功能实现”等同于“项目完成”。一个记账本，从表面看，无非是增删改查（CRUD）——记录收入支出、分类展示、算个总账。但如果你只做到这一步，你的项目就只是一个演示 Demo，缺乏作为“计算机大作业”应有的技术深度和工程素养。

真正能让你的记账本在众多作业中脱颖而出的，不是界面的酷炫，而是你如何用代码清晰地表达业务逻辑，如何设计可扩展的结构，以及如何有意识地处理那些“非功能性”的细节。这篇文章，我们就以 AndroidStudio 开发记账本为例，拆解一下，如何把一个简单的想法，做成一份能体现你专业能力的“大作业”。

1. 从“功能清单”到“业务模型”：你的第一个设计决策

接到“记账本”这个题目，很多同学的第一反应是打开 AndroidStudio，新建 Activity，然后开始堆按钮和文本框。这个起点就错了。在写第一行代码之前，你应该先回答几个问题：记账的核心数据是什么？这些数据之间有什么关系？用户最核心的操作流是什么？

记账本的核心不是界面，而是数据模型。 你需要抽象出一个清晰的实体（Entity）层。通常，一个最基本的记账本至少需要两个核心实体：

账单记录（Bill/Transaction）：这是最小颗粒度的数据单元。
分类（Category）：用于对账单进行归类，如“餐饮”、“交通”、“工资”等。

它们的属性可能如下（以 Kotlin data class 为例）：

KOTLIN

// 分类实体

data class Category(

val id: Long, // 主键

val name: String, // 分类名称，如“餐饮”

val type: Int, // 类型：0-支出，1-收入

val iconResId: Int // 图标资源ID，用于UI展示

)

// 账单记录实体

data class Bill(

val id: Long, // 主键

val amount: Double, // 金额

val categoryId: Long, // 关联的分类ID

val remark: String?, // 备注（可选）

val date: Long, // 交易时间戳

val createTime: Long // 记录创建时间

)

为什么要把 Category 单独抽出来，而不是把分类名直接写在 Bill 里？这体现了数据库设计的范式思想。这样做的好处是：

数据一致性：修改分类名称时，所有关联的账单记录自动生效，避免脏数据。
扩展性：未来可以轻松地为分类增加预算、颜色等属性。
减少冗余：分类信息只存储一份。

这是你的第一个设计决策，也是向评审老师展示你理解“数据驱动”思维的关键。在项目报告或代码注释中，清晰地画出你的 E-R（实体-关系）图，并解释这样设计的理由，这比你写十行华丽的界面动画更有分量。

1.1 定义清晰的数据操作契约：Repository 模式

有了数据模型，接下来要考虑如何存取。切忌在 Activity 或 Fragment 里直接写 SQLiteOpenHelper 和一堆 execSQL。你需要引入一个中间层——Repository（仓库）。

Repository 的核心思想是为数据源提供一个统一的抽象接口。你的 Activity/Fragment 不需要知道数据是来自本地 SQLite、还是未来的网络 API，它只跟 Repository 打交道。

KOTLIN

// 账单数据仓库的接口定义

interface BillRepository {

suspend fun insertBill(bill: Bill): Long

suspend fun updateBill(bill: Bill): Int

suspend fun deleteBill(id: Long): Int

suspend fun getBillsByDateRange(start: Long, end: Long): List<Bill>

suspend fun getTotalAmountByTypeAndDate(type: Int, start: Long, end: Long): Double

// ... 其他查询方法

}

然后，你提供一个基于 SQLite 的具体实现 BillRepositoryImpl。这样做的好处是：

单一职责：数据操作逻辑被集中管理，UI 代码变得清爽。
可测试性：你可以为 Repository 编写单元测试，也可以轻松创建一个“假”的 Repository 用于 UI 测试。
为架构演进留出空间：未来若想加入 Room Persistence Library（Android 官方推荐的数据库组件），你只需要替换 Repository 的实现，而所有上层调用方无需改动。

在项目里实践 Repository 模式，是体现你具备软件设计模式意识的有力证据。

2. 界面与数据的桥梁：理解 MVVM 与 LiveData/Flow

当你的数据层（Model）通过 Repository 变得清晰后，下一个难题是如何安全、高效地将数据变化反映到界面上。传统方法是在 Activity 的 onResume 里手动查询并刷新 UI，但这会导致生命周期管理混乱、内存泄漏等问题。

这里就需要引入 MVVM（Model-View-ViewModel）架构。对于学生项目，不一定要用上 Jetpack 全家桶，但理解其核心思想并应用关键组件，能极大提升项目质量。

ViewModel 的角色是托管 UI 相关的数据，并在配置变更（如屏幕旋转）时存活下来。它持有 Repository 的引用，负责发起数据请求。

LiveData 或 Kotlin Flow 是可观察的数据持有者。当 Repository 中的数据发生变化时，ViewModel 通过它们通知 UI 更新。

以一个显示当日账单列表的页面为例：

KOTLIN

// BillViewModel.kt

class BillViewModel(private val repository: BillRepository) : ViewModel() {

// 使用 StateFlow 来持有账单列表状态（也可以是 LiveData）

private val _bills = MutableStateFlow<List<Bill>>(emptyList())

val bills: StateFlow<List<Bill>> = _bills.asStateFlow()

// 加载今日账单

fun loadTodayBills() {

viewModelScope.launch {

val todayStart = // 获取今日0点时间戳

val todayEnd = // 获取今日23:59时间戳

val result = repository.getBillsByDateRange(todayStart, todayEnd)

_bills.value = result

}

// 添加新账单

fun addBill(amount: Double, categoryId: Long) {

viewModelScope.launch {

val newBill = Bill(0, amount, categoryId, null, System.currentTimeMillis(), System.currentTimeMillis())

repository.insertBill(newBill)

// 添加成功后，重新加载数据

loadTodayBills()

}

在 Activity/Fragment 中，你只需要观察这个 bills 流：

KOTLIN

// MainActivity.kt (部分代码)

class MainActivity : AppCompatActivity() {

private lateinit var viewModel: BillViewModel

private lateinit var adapter: BillAdapter

override fun onCreate(savedInstanceState: Bundle?) {

// ... 初始化 UI 和 ViewModel

lifecycleScope.launch {

repeatOnLifecycle(Lifecycle.State.STARTED) {

// 收集 bills 流，自动更新 UI

viewModel.bills.collect { billList ->

adapter.submitList(billList)

}

// 触发初始加载

viewModel.loadTodayBills()

}

注意：使用 LiveData 或 Flow 时，务必注意生命周期。上述代码中 repeatOnLifecycle(Lifecycle.State.STARTED) 是确保只在界面可见时接收数据更新，避免资源浪费和潜在崩溃。这是很多新手容易忽略的安全实践。

采用这种模式，你的 UI 代码（Activity/Fragment）将变得非常“薄”，它只负责两件事：1. 响应用户操作，调用 ViewModel 的方法；2. 观察数据变化，更新界面。所有业务逻辑和数据处理都转移到了 ViewModel 和 Repository 中。这种清晰的职责分离，是评审中重要的加分项。

3. 超越增删改查：赋予你的记账本“思考”能力

如果记账本只能记录和查看流水，那它只是一个电子账本。作为一个计算机项目，你应该让它具备一定的“分析”和“自动化”能力。这不需要复杂的算法，但能显著体现你的编程思维。

3.1 实现有意义的统计图表

不要只用 ListView 或 RecyclerView 展示流水。引入一个图表库（如 MPAndroidChart），展示月度支出趋势、分类占比饼图等。

关键不在于图表多好看，而在于背后的数据聚合逻辑。 例如，生成月度支出趋势图：

在 Repository 中增加方法：getMonthlySummary(year: Int, month: Int): Map<Int, Double>，返回该月每日的总额。
ViewModel 调用该方法，将 Map 数据转换为图表库需要的 List<Entry>。
UI 观察数据并渲染图表。

这个过程考察了你对数据转换和第三方库集成的能力。在报告里，你可以详细说明选择该图表库的原因、集成步骤以及你是如何将原始数据适配成库所需格式的。

3.2 设计简单的预算提醒功能

这是一个能串联多个知识点的好功能。

数据层：新增一个 Budget 实体，关联 Category 和月份。
业务层：在 Repository 中编写查询，计算某分类本月已支出，并与预算对比。
后台服务：使用 WorkManager（Android Jetpack 组件）安排一个每日或每周一次的周期性任务，检查是否有分类超支。
通知：如果超支，通过 NotificationCompat 发送一个提醒通知。

这个功能涉及了定时任务、后台处理和系统通知，这些都是 Android 开发的核心知识点。实现它，表明你的项目不再是一个简单的 CRUD 练习，而是一个考虑用户场景的完整应用。

3.3 数据的导入与导出

实现将账单记录导出为 CSV 或 Excel 文件，并支持从文件导入。这考察了你对文件系统操作（Context.getExternalFilesDir）、数据序列化/反序列化（使用 Gson 或手动拼接 CSV 字符串）以及运行时权限申请（READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE）的理解。

这是一个非常实用的功能，也能为你的项目增加一个“数据持久化与迁移”的论述点。

4. 从“能运行”到“算作品”：那些必须关注的工程细节

最后，也是区分“作业”和“作品”的关键，在于你对工程细节的把握。这些地方往往代码量不大，但极其体现专业素养。

4.1 资源与配置管理

字符串资源：所有显示在 UI 上的文字，必须定义在 res/values/strings.xml 中，绝对禁止在代码里硬编码 "请输入金额"。这是国际化和维护性的基本要求。
尺寸与颜色：同理，尺寸（dimens.xml）和颜色（colors.xml）也应统一管理。
应用图标与适配：提供不同分辨率的 mipmap 图标，并确保应用名称在 AndroidManifest.xml 中正确设置。

4.2 异常处理与用户反馈

空数据状态：当账单列表为空时，显示一个友好的提示界面（Empty View），而不是一片空白或崩溃。
网络请求（如果涉及）：必须有加载中、成功、失败（网络错误、服务器错误）的状态处理。使用 Sealed Class 来优雅地封装这些状态是很好的实践。
输入验证：在添加账单时，对金额（是否为正数）、分类（是否已选择）进行验证，并使用 TextInputLayout 的 setError 等方法给用户即时反馈。
全局异常处理：可以考虑设置一个默认的 Thread.setDefaultUncaughtExceptionHandler，将崩溃信息记录到文件，方便后期调试，但至少不能让应用直接闪退到桌面。

4.3 基础性能与体验优化

列表性能：使用 RecyclerView 时，确保正确实现 ViewHolder 模式。如果图片多，考虑使用 Glide 或 Coil 等图片加载库进行异步加载和缓存。
数据库查询优化：为常用的查询字段（如 date, categoryId）建立索引。对于统计类查询，避免在 UI 线程执行。
内存泄漏预防：检查是否在 Activity/Fragment 中注册了广播、监听器但没有及时反注册；检查是否在非 UI 组件中持有了 Context 的长生命周期引用。

4.4 项目结构与文档

清晰的包结构：按功能或架构分层来组织包，例如 com.yourname.expense.data, com.yourname.expense.ui, com.yourname.expense.di 等。
有意义的提交记录：如果使用 Git，提交信息应清晰（如 “feat: 添加月度图表功能”、“fix: 修复分类选择器空指针异常”）。
README.md：项目根目录必须有一个详细的 README 文件，内容包括项目简介、功能列表、运行指南（如何导入、配置、构建）、技术栈说明以及关键模块的简要介绍。
代码注释：在关键类、复杂方法、核心算法处添加简明扼要的注释，解释“为什么这么做”，而不是重复“做了什么”。

当你把这些细节都考虑到并实现，你的记账本就不再是一个仓促完成的作业，而是一个经得起推敲、体现了软件工程基本思想的个人作品。评审老师在看的时候，不仅能运行起来，更能从代码结构、设计选择、细节处理中看到你的学习深度和工程潜力。这才是完成一份高质量计算机大作业的真正路径。