1. 为什么“记账本”是比“小说阅读器”更合适的新手项目很多人第一次学Android开发第一个念头就是“我要写个小说阅读器”或者“做个视频播放器”。这个想法本身没问题但对于刚装好Android Studio、连Activity生命周期都没完全搞明白的新手来说这类项目涉及的技术面太宽——网络请求、数据解析、缓存策略、播放器内核适配任何一个环节出问题都能让你卡上两三天最后挫败感爆棚。记账本这个项目我愿称之为“麻雀虽小五脏俱全”。它不涉及复杂的网络通信不需要第三方的服务端支持却恰好覆盖了Android应用开发最核心的几条链路UI布局与交互事件、数据持久化SQLite增删改查、列表展示与刷新、数据统计与图表可视化、以及后期的打包发布流程。你可以用纯原生的方式把它完整做出来期间学到的每一样东西在以后的商业项目中都会反复用到。拿它和另外两个常见的入门项目做个对比你就明白了对比维度计算器待办清单记账本界面复杂度网格按钮为主简单列表列表表单图表更丰富数据存储基本不需要SharedPreferences够用SQLite数据库有完整建表和查询需求列表展示无RecyclerView基础用法列表分类筛选金额汇总数据处理简单运算字符串和布尔值金额、日期、分类聚合逻辑更贴近真实业务统计可视化无无柱状图、饼图能学到图表库接入后期扩展空间很小一般很大可以一路升级到MVVMRoom从技术覆盖面的角度来说记账本这个选题相当于用最低的复杂度换到了最完整的开发体验。我记得当时带过的一个学员做完这个项目之后再去接触电商类App的业务代码很多模块都似曾相识——订单列表不就是带状态的“账单列表”吗筛选订单不就是按时间查流水吗底层逻辑是完全相通的。还有一个很现实的原因记账本做成之后你自己真的会用它。这个正反馈太重要了。我见过太多人做完Demo就删掉因为计算器自己不用、待办清单懒得填但记账本不一样收入支出是每天都会发生的事。我自己当时做完第一版记账本之后真的坚持记了大半年一边用一边改需求这种“用自己的App管理生活”的感觉是任何课程作业都给不了的。1.1 先别贪心第一版只做这三件事新手做记账本最容易犯的错误是一上来就想把功能计划表填满多账本、预算提醒、周期记账、语音输入、指纹解锁、图标分类管理……打住。第一版只要做完下面三件事就已经超过了60%的半成品记一笔用户能填写金额、选择分类、写备注、记录日期然后保存进数据库。看明细首页用列表展示每一笔收支最新的排在最上面长按或滑动可以删除。看统计按月份汇总总收入和总支出按分类做一个占比图。我自己做过很多次项目评审可以负责任地说这三件事覆盖了Android开发入门的全部关键知识点。等这三件事都跑通了你再回头去看那些“进阶想法”自然知道哪些是真正有用的哪些只是你以为有用。1.2 技术选型的“第一个决策”第一版我建议用纯Java/Kotlin XML布局 SQLiteOpenHelper RecyclerView这套最传统的组合不要一上来就用Jetpack Compose Room Flow。为什么因为新手阶段最重要的是建立“心智模型”——你得先理解布局文件里的View怎么被Activity找出来、SQL语句的查询结果怎么一步步变成屏幕上的列表项、数据变化之后界面为什么需要刷新。这些底层逻辑一旦理解后面学任何新框架都很快。反过来说如果上来就拖一堆依赖、写一堆注解出了问题你连错误发生在哪一层都不知道。我见过一个反面教材有同学第一次做项目就用了Room结果某个查询方法死活编译不过他完全不知道问题出在DAO接口的注解语法上还是SQL语句上还是数据库版本迁移上。这就是过早引入框架的代价——在缺少底层概念的情况下框架帮你屏蔽掉的复杂性全都变成了黑盒里的玄学。SQLiteOpenHelper虽然代码写起来啰嗦一点但每一步都清清楚楚数据库什么时候创建、什么时候升级全在你掌控之中。2. 环境搭建与“Error running app”完整排查链路做Android开发第一步是装Android Studio。这个环节劝退了相当一部分人不是装不上而是装完了之后点“Run”眼睁睁看着Build窗口里冒出红字然后人傻了。我见过最多的一句报错就是Error running app: Default Activity not found这个报错的信息量其实很低它只是告诉你“系统不知道该启动哪个Activity”但造成这句话的原因可能有五六种。下面把最常见的排查链路完整过一遍。2.1 安装阶段最容易忽视的两个细节Android Studio本身安装没什么难度到官网下载对应你操作系统的版本一路Next就行。真正容易出问题的是SDK组件。建议在SDK Manager里至少勾选这三个东西Android SDK Platform-Tools包含adb等命令行工具一个你打算做最低兼容版本的Platform比如Android 8.0API 26匹配你测试设备的System Image或者直接连真机另外一个很多人忽略的点是硬件加速。如果你用Windows电脑跑模拟器务必在BIOS里确认Intel HAXM或Windows Hypervisor Platform已经打开。不然模拟器要么启动极慢要么直接报“HAXM is not installed”或者“emulator: ERROR: x86_64 emulation currently requires hardware acceleration”。2.2 Error running app的六种“真身”我整理了新手阶段最高频的六种情况每一行都是实际踩过的坑报错内容真实原因解决方法Default Activity not foundAndroidManifest.xml里没给Activity加MAIN/LAUNCHER过滤器在意图过滤器里补上ACTION_MAIN和CATEGORY_LAUNCHERError running app: No target device found没有启动模拟器也没连真机先启动一个AVD或插入开启USB调试的手机INSTALL_FAILED_UPDATE_INCOMPATIBLE手机上已装有同包名的旧版本卸载旧包或修改applicationId后重装Could not identify launch activity项目还在同步中或存在编译错误先执行Build Rebuild Project确认编译通过java.lang.ClassNotFoundException某Activity没在Manifest里注册检查AndroidManifest.xml的application节点内是否漏了activity子标签gradle sync failed网络原因拉不下来依赖改用国内镜像仓库或检查Gradle JDK版本2.3 我印象最深的一次排错有一次给自己的记账本项目加统计页改完Manifest之后一点Run直接弹了“Default Activity not found”。我第一反应是MainActivity被我不小心删了但检查源码文件都还在又以为applicationId改名搞错了检查也没问题。折腾了十分钟最后打开AndroidManifest.xml的文本视图才发现新加的统计页Activity标签里少写了一个android:name属性的点号——写成了.activity.StatisticsActivity而实际包名路径是.statistics.StatisticsActivity。就这么一个字符系统找不到启动页报的却是“Default Activity not found”这种完全看不出原因的错。这个经历说明一个事实Android Studio的报错提示很多时候只是下游现象不是根因。排错的时候不要只盯着报错文案要沿着“编译是否通过 → Manifest是否合法 → 设备是否就绪 → 应用是否安装成功”这个链路一层一层查。新手最容易犯的错是问题出在编译阶段却一直在设备连接上打转。2.4 模拟器还是真机记账本这个项目我强烈建议你准备一台真机做调试。原因有两个第一模拟器的启动速度和你电脑配置强相关很多人就是卡在“等模拟器启动”上消磨掉了热情第二记账本涉及数据库读写真机上你能更直观地感受到冷启动、页面切换这些真实性能表现。真机调试只需要两步手机上开启“开发者选项”里的“USB调试”然后用数据线连上电脑。首次连接手机会弹一个“允许USB调试吗”的对话框记得勾选“始终允许”。如果连上后adb识别不到设备去检查一下手机厂商的USB驱动有没有装好。顺带说一句不要用那种只有充电功能的数据线我至少见过三个人折腾了一晚上驱动最后发现是线的问题。3. 数据库先行账目明细的存储设计与DAO封装聊完了环境进入记账本的核心——数据。几乎所有业务功能都是围绕“账目数据从哪来、存到哪、怎么查”展开的所以先把表结构设计好后面写界面和统计的时候就会非常顺畅。3.1 表结构设计为什么分类要单独建表我的第一版记账本只设计了两张表一张category分类表一张bill账单明细表。建表SQL长这样CREATE TABLE category ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, type INTEGER NOT NULL, -- 0支出 1收入 icon_color INTEGER DEFAULT 0 ); CREATE TABLE bill ( id INTEGER PRIMARY KEY AUTOINCREMENT, type INTEGER NOT NULL, -- 0支出 1收入 amount INTEGER NOT NULL, -- 以“分”为单位存储 category_id INTEGER NOT NULL, note TEXT, bill_date TEXT NOT NULL, -- 格式: yyyy-MM-dd create_time INTEGER NOT NULL, -- 毫秒时间戳 update_time INTEGER NOT NULL, FOREIGN KEY (category_id) REFERENCES category(id) );很多人一开始会图省事在bill表里直接存一个category_name文本字段。这个设计短期看没问题但如果你后续想“把‘吃饭’改成‘餐饮’”就得写一条UPDATE语句去更新所有历史账单如果你想给每个分类配一个图标颜色那这个颜色值也得冗余在账单表里。而用category_id做外键关联改分类名只需要改一行历史数据全部自动生效。金额字段我用的是INTEGER不是REAL也不是TEXT。为什么因为浮点数的精度问题在涉及“钱”的场景里是不可接受的——0.1加0.2在浮点数体系里会变成0.30000000000000004。我们日常记账最多到分所以统一把“元”转成“分”存整数展示的时候再除以100逻辑简单、计算精确。所有涉及金额聚合的SQL比如按月统计总支出也都基于整数计算不会出现精度偏差。3.2 SQLiteOpenHelper的生命周期理解数据库的创建和升级通过继承SQLiteOpenHelper来实现这大概是Android最经典的数据库写法了public class DBHelper extends SQLiteOpenHelper { private static final String DB_NAME account_book.db; private static final int DB_VERSION 1; public DBHelper(Context context) { super(context, DB_NAME, null, DB_VERSION); } Override public void onCreate(SQLiteDatabase db) { db.execSQL(CREATE_CATEGORY_SQL); db.execSQL(CREATE_BILL_SQL); // 初始化默认分类数据 initDefaultCategories(db); } Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { // 第一版先不用迁移直接重建 db.execSQL(DROP TABLE IF EXISTS bill); db.execSQL(DROP TABLE IF EXISTS category); onCreate(db); } }这里有两个点要特别说明。第一个是“数据库版本号”的意义。DB_VERSION不是随便写的数字它决定了onUpgrade会不会被调用。你第一次写完表结构发布出去用户手机里有了一个version 1的数据库后来你改了表结构比如给bill表加了一个is_deleted字段就把DB_VERSION改成2同时把onUpgrade里的逻辑从“DROP重建”换成“ALTER TABLE”添加列。这样老用户升级App之后数据还能保留。第一版开发阶段你可以用DROP重建图省事但心里要清楚正式发布后绝不能用这套方案。第二个是“初始化默认分类”。我推荐在onCreate里就把常用分类写入category表比如支出分类餐饮、交通、购物、居住、娱乐、医疗、其他收入分类工资、奖金、理财、兼职、其他。这样首版界面做完用户一进来就有分类可选体验完整。如果放在用户操作时才人工插入多了很多边界判断。3.3 用DAO层把SQL封起来别让Activity里全是SQL新手很容易犯的一个错误是直接在Activity里写SQLiteOpenHelper的调用和游标解析。早期确实能跑但项目一复杂你就知道痛了——同一个查询逻辑要在多个界面里用改一处忘一处Activity里堆满了数据库细节阅读代码简直像考古。所以我从一开始就建议加一个DAOData Access Object层把所有的数据库操作收敛到一个类里。比如我的BillDao.java里有这些方法public long insertBill(Bill bill) { ... } public int deleteBill(long billId) { ... } public int updateBill(Bill bill) { ... } public ListBill queryBillsByMonth(String yearMonth) { ... } public ListCategoryAvgBean queryCategorySumByMonth(String yearMonth, int type) { ... }Activity和Fragment只跟DAO打交道完全不用管SQL语句长什么样。这样的好处至少有三个一是代码可读性大幅提升二是如果以后要把SQLite换成Room只需要改DAO实现界面代码一点不用动三是每一个数据库操作方法都是独立小函数很容易写单元测试。写查询方法时记得使用Cursor的getColumnIndexOrThrow而不是getColumnIndex后者在列名拼错时会静默返回-1导致后续取值全乱。前者至少会抛异常告诉你哪里写错了排查成本低得多。3.4 数据备份和导出一个不能忘的隐藏需求记账数据是用户的私密资产第一版可以在“设置”里做个简单的导出备份功能把数据库文件复制到应用的公共目录File dbFile context.getDatabasePath(account_book.db); File exportFile new File(Environment.getExternalStoragePublicDirectory( Environment.DIRECTORY_DOCUMENTS), account_book_backup_ date .db); FileInputStream fis new FileInputStream(dbFile); FileOutputStream fos new FileOutputStream(exportFile); // 循环读写文件流...这个功能本身代码不难但它体现了一个重要的产品思维用户会因为手机丢失、换机、应用闪退等原因丢失数据而记账类App的价值恰恰是长期积累的数据。基础的备份和导出能力在写数据库时就顺手留好后续再扩展“从备份文件恢复”也就十几行代码的事。顺带提醒一句如果接入了网络云备份那就要严肃对待安全问题不能直接把数据库原样传到服务器。至少要做加密密码不能硬编码在代码里。第一版没有云备份完全没关系但要做就做安全不然宁可没有。4. 界面交互从XML布局到RecyclerView列表数据库准备好了接下来是界面。记账本的界面结构很清晰首页就是账单流水列表右上或右下角一个“记一笔”的入口点击后弹出一个填写表单。这几乎是所有记账类App的通用布局。4.1 主界面布局的第一版设计主界面我用了一个标准的CoordinatorLayout结构androidx.coordinatorlayout.widget.CoordinatorLayout com.google.android.material.appbar.AppBarLayout com.google.android.material.appbar.MaterialToolbar android:idid/toolbar / /com.google.android.material.appbar.AppBarLayout androidx.recyclerview.widget.RecyclerView android:idid/recycler_bill android:layout_widthmatch_parent android:layout_heightmatch_parent android:paddingBottom80dp android:clipToPaddingfalse / com.google.android.material.floatingactionbutton.FloatingActionButton android:idid/fab_add android:layout_widthwrap_content android:layout_heightwrap_content android:layout_gravitybottom|end android:layout_margin16dp android:srcdrawable/ic_add / /androidx.coordinatorlayout.widget.CoordinatorLayout这里有两个容易被新手忽略的细节。第一个是android:clipToPaddingfalse配合paddingBottom。如果没有这行设置列表的最后一项会被FloatingActionButton挡住一部分怎么滚都滚不出那个区域。多加一个底部padding再关闭clipToPadding让列表内容可以滚动到按钮底下视觉和操作都舒服了。第二个是“列表项日期的分组逻辑”。记账列表不是每一条账单一行那么简单通常要把同一天的账单合并到同一个“日期标题”下面比如“今天”“昨天”“2024年12月1日”下面再显示这一天的支出小计。这个逻辑写起来不复杂就是遍历数据时比较相邻两条的日期是否相同。但它很能体现一个开发者的产品思维——列表不只是把数据库记录机械地映射到屏幕还要考虑用户阅读信息时的效率。4.2 RecyclerView Adapter的核心写法RecyclerView的Adapter是Android列表的重中之重我直接贴出关键代码public class BillAdapter extends RecyclerView.AdapterBillAdapter.BillViewHolder { private ListBill billList; private OnItemClickListener listener; NonNull Override public BillViewHolder onCreateViewHolder(NonNull ViewGroup parent, int viewType) { View view LayoutInflater.from(parent.getContext()) .inflate(R.layout.item_bill, parent, false); return new BillViewHolder(view); } Override public void onBindViewHolder(NonNull BillViewHolder holder, int position) { Bill bill billList.get(position); holder.tvAmount.setText(formatAmount(bill.getAmount(), bill.getType())); holder.tvCategory.setText(bill.getCategoryName()); holder.tvNote.setText(bill.getNote()); holder.ivCategoryIcon.setColorFilter(bill.getCategoryColor()); holder.itemView.setOnClickListener(v - { if (listener ! null) listener.onItemClick(bill); }); } Override public int getItemCount() { return billList null ? 0 : billList.size(); } static class BillViewHolder extends RecyclerView.ViewHolder { TextView tvAmount; TextView tvCategory; TextView tvNote; ImageView ivCategoryIcon; BillViewHolder(NonNull View itemView) { super(itemView); tvAmount itemView.findViewById(R.id.tv_amount); tvCategory itemView.findViewById(R.id.tv_category); tvNote itemView.findViewById(R.id.tv_note); ivCategoryIcon itemView.findViewById(R.id.iv_category_icon); } } }这里首当其冲的坑是onBindViewHolder里的赋值不能做耗时操作——它是运行在UI线程的。比如“根据categoryId查分类名称”这种数据库操作绝对不能在onBindViewHolder里执行。正确做法是在查到账单列表后先把categoryId映射成categoryName放进Bill实体里再交给Adapter展示。一句话总结Adapter里只做界面赋值不做业务逻辑。4.3 列表刷新的两种姿势notifyDataSetChanged与DiffUtil增删改查之后列表要刷新才能看到最新数据。最朴素的做法是重新查询一次所有账单然后调用adapter.setData(newList); adapter.notifyDataSetChanged();。notifyDataSetChanged()的优点是简单缺点是它会在列表项数量较多时带来可见的卡顿因为整个列表都会重新绘制而且会丢失滚动位置。它本质上是在告诉RecyclerView“我全部数据都变了你重新绑定一遍”。记账本的列表通常不会超过几百条用这个方法完全没问题。但如果你追求更好的体验可以用DiffUtilDiffUtil.DiffResult diffResult DiffUtil.calculateDiff( new BillDiffCallback(oldList, newList)); diffResult.dispatchUpdatesTo(adapter);DiffUtil会先计算出新老列表的差异然后只更新有变化的那几项。比如用户只是删了一条账单它不会把整个列表重新绘制一遍滚动位置也保留得很好。代码多写一点但这是RecyclerView进阶必须掌握的技能。我自己在第二版记账本里用上了DiffUtil最大的感受是“删除操作”变得极其跟手。原来的notifyDataSetChanged会让列表有一条肉眼可见的闪烁换了DiffUtil之后完全是丝滑的。4.4 金额格式化与日期显示的三个细节别小看显示层的细节这些往往是用户感知最强烈的地方。金额格式化我建议用java.text.NumberFormat配合BigDecimal避免直接对double做运算和格式化public static String formatAmount(int amountInCents) { BigDecimal amount BigDecimal.valueOf(amountInCents, 2); NumberFormat format NumberFormat.getCurrencyInstance(Locale.CHINA); return format.format(amount); }注意BigDecimal.valueOf(amountInCents, 2)的第二个参数表示小数点位数比如传入12345和2输出的就是123.45。这个方法比new BigDecimal(double)安全得多后者会因为二进制浮点数的问题产生一长串小数。日期显示的另一个坑是SimpleDateFormat的线程安全。如果你在多个线程里共享同一个SimpleDateFormat实例并发调用format或parse时偶尔会崩溃或返回错乱结果。记账本项目里虽然大部分操作在UI线程但是养成“每次用的时候new一个或者用ThreadLocal包装”的习惯能省掉很多未来的诡异bug。5. 统计图表接入与数据可视化记账本做到列表能增删改查之后已经算是一个能用的App了。但真正让它从“能用”变成“好用”的是数据统计——用户记了一个月账之后最关心的是“钱都花哪了”。这一节说说图表可视化怎么做。5.1 图表库选型为什么选MPAndroidChartAndroid生态里图表库不少有MPAndroidChart、HelloCharts、AAChartCore、WilliamChart等。综合比较下来我最推荐MPAndroidChart原因有三维护活跃度高。虽然有段时间作者更新不频繁但它在GitHub上的issue和PR处理基本没有断裂大量商业项目都在使用。功能全面。饼图、柱状图、折线图、雷达图都有而且动画效果和交互点击高亮、十字线、缩放都是开箱即用的。社区资料多。遇到问题搜一下基本都有答案这个对新手的意义极大。集成方式很简单在build.gradle里加一行implementation com.github.PhilJay:MPAndroidChart:v3.1.0同步之后就能用了。这里要注意一下v3.1.0版本对应的依赖仓库需要在根目录的build.gradle里配置一下Maven的jitpack仓库allprojects { repositories { google() mavenCentral() maven { url https://jitpack.io } } }如果只配了google和mavenCentral同步的时候大概率会报“Could not find com.github.PhilJay:MPAndroidChart”的错误。5.2 分类占比饼图的实现要点饼图是统计模块最先做的图用来回答“我这个月每一类花了多少钱、占比多少”。数据来源用一条聚合SQL就能搞定SELECT category_id, SUM(amount) AS total FROM bill WHERE type 0 AND substr(bill_date, 1, 7) ? GROUP BY category_id ORDER BY total DESC这条SQL里有几个地方值得注意substr(bill_date, 1, 7)截取日期字符串的前7位得到yyyy-MM然后和传入的月份参数比较。这比用BETWEEN 2024-12-01 AND 2024-12-31要简洁而且因为bill_date是TEXT类型字符串截取可以直接用。GROUP BY配合SUM(amount)完成分类汇总这是SQL最基础的聚合能力一定要熟练。排序用ORDER BY total DESC可以让饼图在渲染时把占比最高的分类放在最前面展示效果更好。拿到数据之后组装PieEntry列表ListPieEntry entries new ArrayList(); for (CategorySumBean bean : list) { // MPAndroidChart的饼图值默认是float这里把分转换成元 entries.add(new PieEntry(bean.getTotalAmount() / 100f, bean.getCategoryName())); } PieDataSet dataSet new PieDataSet(entries, ); dataSet.setColors(getCategoryColors(list)); // 根据分类给颜色 PieData data new PieData(dataSet); pieChart.setData(data); pieChart.invalidate(); // 刷新图表一个容易踩的坑是空数据的处理。如果某个分类在数据库里没有记录传一个0的Entry进去图表会显示一条可能看不见的扇区还可能造成交互选中的异常。应对方案是先把总数为0的分类过滤掉或者在没有数据时直接显示一个“暂无数据”的占位界面不要白屏。5.3 月度趋势柱状图日期分组的两种方案另一个常用图是柱状图按天展示整个月的每日支出。数据聚合同样用SQLSELECT substr(bill_date, 9, 2) AS day, SUM(amount) AS total FROM bill WHERE type 0 AND substr(bill_date, 1, 7) ? GROUP BY day这里有个细节问题如果某一天没有记账数据库里就查询不到这个日期柱状图的天数就不连续了。展示效果很丑——你说你统计的是一个月31天但图上只有20根柱子用户很容易疑惑。解决方案有两种第一种是在代码里预填一个“31天的空数组”把查询结果填进去没有数据的日期补0。这个方法简单直接适合第一版。第二种是“日期补全左边距处理”在X轴的ValueFormatter里动态判断当前柱子的日期并进行格式化。这个更灵活但代码量稍大。我建议新手先用第一种。等到你发现“每个月天数不一样有的30天有的31天还有28天”这个变量也掺进来之后就会自然理解为什么第二种方案存在了。5.4 图表交互体验的三个小习惯第一chart.getDescription()默认会在图表右下角画一行“Description”很影响美观。第一行代码就把它禁用掉chart.getDescription().setEnabled(false)。第二给饼图加一个选中事件让用户点击某个扇区时下方能显示该分类的所有账单。这个交互做出来之后统计页面和列表页就有了联动整个App的完成度瞬间提升。监听事件是chart.setOnChartValueSelectedListener(new OnChartValueSelectedListener() { ... })在回调里拿到Entry的getData()标记的categoryId然后跳转到筛选列表。第三关于图表动画。chart.animateY(500)这个动画虽然好看但在列表快速滚动时会频繁触发可能造成jank。建议只在页面第一次进入时播放动画之后如果数据刷新成一样的月份就不再重放。6. 记账本的进阶之路架构、性能与上架发布第一版功能跑通之后不要急着觉得“完事了”。从“能做出来”到“做得像样”中间还有很长一段路。这一节聊聊后续的优化方向和上架发布前需要注意的事情。6.1 从SQLiteOpenHelper到Room什么时候才值得换你可能会在很多地方看到“现在做Android开发已经不用SQLiteOpenHelper了都用Room”。这句话在正规商业项目里基本成立但对你个人学习项目来说我认为顺序应该是先用手写SQL把数据库整明白再迁移到Room。什么时候值得迁移当你开始遇到下面这些痛点的时候手写大量的if (cursor.moveToFirst())样板代码觉得烦。想在插入更新时做校验、想在删除时做级联处理但手写SQL的维护成本越来越高。想把数据库查询结果直接包装成LiveData或Flow让UI自动响应数据变化手写SQL要做到这件事非常别扭。想对数据库做单元测试但DAO层和SQLiteOpenHelper耦合得太紧。Room确实解决了这些问题——编译期SQL校验、DAO接口自动实现、直接衔接协程和Flow。我自己的第二版记账本就是全量迁移到Room了迁移过程其实没有想象中那么恐怖核心就是定义好Entity、Dao、Database这三个注解相关的类然后把原来BillDao里的方法逐个换成对应的注解和方法签名。迁移的时候有一个必须处理的点数据库版本升级不要让老用户升级App之后数据丢光。用Room的做法是在Database注解里写version 2然后实现一个Migrationstatic final Migration MIGRATION_1_2 new Migration(1, 2) { Override public void migrate(SupportSQLiteDatabase database) { database.execSQL(ALTER TABLE bill ADD COLUMN is_deleted INTEGER NOT NULL DEFAULT 0); } };这种“加字段、加索引”的迁移Room支持得很好。只要SQL语句本身合法升级过程就很平稳。6.2 包结构设计一个不算复杂但要有层次感的目录第一版项目里所有类都堆在同一个包下面当时觉得挺爽找什么都方便。但当你开始加统计、加设置、加导出、加小部件的时候同一个包下几十个文件会很让人崩溃每次找类都在滚动列表。一个适合小中型项目的简单包结构大概是这样的com.yourapp.accountbook ├── ui/ # Activity、Fragment、Adapter都在这里 │ ├── main/ # 主页的Activity和RecyclerView Adapter │ ├── add/ # 记一笔页面 │ ├── stats/ # 统计页面 │ └── settings # 设置页面 ├── data/ # 数据层 │ ├── db/ # 数据库帮助类、实体类、DAO │ ├── dao/ # DAO接口如果不分db/dao可以合并 │ └── repository/ # 仓库类封装数据访问逻辑 ├── utils/ # 工具类 └── model/ # 通用实体类别看这个结构简单它遵循了一个核心原则数据层和UI层分离。以后你换数据库、换网络层UI代码甚至都不用碰。这个原则放到任何规模的项目里都是成立的。说到架构模式MVP还是MVVM记账本这个体量第一版用最简单的ActivityDAO完全没问题。当你发现Activity里的代码开始超过300行、既有数据加载又有点击处理还有界面刷新的时候再考虑引入ViewModelLiveData。过早引入架构模式同样是一种负担它应该遵循“代码乱到你难受了才去重构”的节奏而不是为了“显得专业”去套一个框架。6.3 性能优化从哪几件事入手记账本的数据量级第一版的性能几乎不用太担心。但如果你想把项目做得更细致有几个点值得做数据库索引是一个高性价比的优化。像bill表里bill_date这个字段几乎所有的统计查询都拿它作为过滤条件。默认情况下SQLite是全表扫描数据量上到几万条之后会明显变慢。给bill_date建一个索引一行SQL的事效果立竿见影CREATE INDEX idx_bill_date ON bill(bill_date);分页加载是另一个点。如果你的账单列表越攒越多一次性把几万条记录全部load进内存就不太合适了。RecyclerView的分页方案是监听滚动事件当滚动到接近底部时再加载下一页。用LIMIT和OFFSET或者是更好的游标分页WHERE bill_date ?来实现。还有一个容易被忽略的坑不要在getView里做数据计算。比如金额格式化、日期格式化这些操作如果每条数据显示前都调用一次NumberFormat.getInstance().format()在列表快速滚动时会消耗不少CPU。我的做法是用一个线程安全的缓存工具或者干脆在查询完成后统一格式化好放进映射表里Adapter直接取现成的字符串。6.4 打包上架与隐私合规第一版功能稳定之后你就可以打包成APK发给朋友试用或者直接上架应用市场。打包的关键步骤是签名——没有签名的APK无法安装到真机上正式使用除了Android Studio调试签名的时候。在Android Studio里操作很直观Build Generate Signed Bundle / APK 选择APK Create new key store填好密钥库信息。之后每次打包都用同一个密钥库这个密钥库文件一定要备份好。丢失密钥库永远无法更新你已发布的App这个问题在开发者社区里每年都有很多翻车案例。隐私合规方面记账本因为涉及用户日常消费数据属于和财产安全相关的敏感个人信息。如果上架国内应用市场需要在隐私政策中明确告知收集哪些信息通常是本地存储不联网、用途是什么、如何删除。如果你的应用完全不申请任何危险权限只做本地存储审核会顺利很多。哪怕后期加了云备份功能也必须把数据传输和加密的细节写清楚。6.5 算个总账做完这个项目后你能带走什么我见过太多初学者卡在某一个“看起来很难的知识点”前面迟迟不敢动手比如网络请求、比如自定义View、比如数据同步。但做记账本这个项目的过程中你会发现真正支撑开发能力的不是某一个高精尖技术而是那些看起来平平无奇却处处都在用的基本功SQL语句写得熟不熟、列表适配器写得好不好、界面状态管没管好、异常处理到不到位。这些基本功练好了再去看那些炫酷的技术你会发现它们都只是在不同场景下对基本功的组合。最后再分享一个我自己的习惯写完第一版之后坚持用自己的记账本记一个月的账。这个过程你会发现很多自己当初没想过的使用场景——比如凌晨12点后的“今天”应该算昨天还是今天连续记了一周后想看周总结怎么办手机快没电时快速记一笔的路径是不是太长每一个问题都是一个真实需求它们远比网上搜来的“产品需求文档”更贴近用户。从这些问题出发去迭代你的记账本就会真正长成一个有生命力的作品而不仅仅是一次课堂作业。
