简介一套覆盖常见应用场景的安卓工程示例合集包含注册界面、饭堂小广播、音乐播放器、记事本、读取手机通讯录、学生管理系统等完整项目适合学生和刚入门开发者用于巩固Android基础与综合实战。项目涉及XML布局设计、输入校验、网络通信、定时任务、多媒体播放、文件存储、Content Provider、数据库及系统权限申请等典型知识点覆盖安卓开发常用技术栈。压缩包共628个文件以260个xml布局资源、137个java源码为主搭配大量webp、png图片素材以及gradle构建脚本、mp3测试音频等整体仅6MB。目前已有226人学习。通过对照源码可以快速梳理各模块的实现脉络尤其学生管理系统综合程度较高能够串联界面、存储、网络等多方面技能适合作为课设参考或阶段练习。 六七个安卓小项目一次性攒到同一个需求清单里这种组合在课程设计和自学路线里其实特别常见。注册界面、饭堂小广播、音乐播放器、记事本、读取手机通讯录、学生管理系统乍一看都是独立的小demo但拆开看它们恰好把Android开发的几条主线全串了一遍界面控件与输入校验、本地数据持久化、媒体播放与后台服务、系统ContentProvider跨应用读取数据、多表业务建模。这篇文章我就按自己的实际开发顺序把这几个项目逐个拆开讲包括每个项目练什么、核心代码怎么落、哪些坑最容易踩以及最后怎么把它们组装成一个完整的学习闭环。如果你正在准备安卓期末大作业或者刚学完基础语法想找一组练手项目这套组合能让你把零散知识点真正焊进项目里。1. 六个小项目背后的知识点地图先明确每个项目练什么很多初学者拿到这种多项目需求时第一反应是从最简单的开始逐个做这没问题。但我更建议先花半小时把每个项目的考点列清楚因为这几个项目看起来都叫“界面”实际底层技术完全不同。1.1 每个项目对应的核心知识清单项目核心知识点主要控件 / API注册界面布局、事件监听、输入校验、轻量存储EditText、TextInputLayout、SharedPreferences记事本SQLite、列表展示、增删改查RecyclerView、SQLiteOpenHelper音乐播放器媒体播放、后台服务、通知栏MediaPlayer、Service、Notification饭堂小广播定时任务、文本播报、通知提醒AlarmManager、TTS、BroadcastReceiver读取手机通讯录系统数据读取、运行时权限ContentResolver、ContactsContract学生管理系统多表设计、页面跳转、复杂CRUDSQLite、多Activity或Fragment、Adapter这个表格我建议收藏一下。以后无论拿到什么项目需求第一步都是先把“它考什么”列出来再动手写代码。比如“饭堂小广播”这个名字很生活化但它隐藏的考点其实是定时任务调度和系统通知如果你只想着做个播放页面方向从一开始就跑偏了。1.2 项目里没写明、但必须掌握的隐性考点注册界面练的是输入控件组合与数据校验但放到真实项目里它就是登录模块的前置页面。记事本练的是单表CRUD但它的难点不在建表而在RecyclerView的数据刷新时机。音乐播放器练的是MediaPlayer的状态机但列表页到播放页的场景切换才是工程师日常写的最多的代码。饭堂小广播看起来简单实际上它需要的AlarmManager对Android 12及以上的精确闹钟权限有严格要求这部分我在第3章单独展开。把这些隐性考点列出来之后整个项目的学习顺序也就自然出来了先用注册界面熟悉控件和Activity跳转再用饭堂小广播理解后台触发机制然后记事本练数据库音乐播放器练Service读取通讯录练跨应用数据访问最后用学生管理系统把这五条线全部揉在一起。2. 注册界面与记事本本地数据存储的两种打开方式这两个项目经常被当成“开胃菜”因为它们界面简单没有复杂的后台任务。但我想说的是注册界面和记事本放在一起练恰好能搞清楚Android里两种最常见的本地存储方案分别适用于什么场景。2.1 注册界面为什么首选SharedPreferences注册界面的本质是用户填表单点按钮保存数据并跳转。保存用户名密码这种轻量级键值数据时SharedPreferences是最直接的选择不需要建数据库表也不需要定义游标映射。布局部分我用TextInputLayout包了一层输入框比裸的EditText好用很多。它自带浮动标签、错误提示和密码可见性切换这些正是注册页的核心交互。com.google.android.material.textfield.TextInputLayout android:layout_widthmatch_parent android:layout_heightwrap_content com.google.android.material.textfield.TextInputEditText android:idid/etPassword android:layout_widthmatch_parent android:layout_heightwrap_content android:hint密码 android:inputTypetextPassword / /com.google.android.material.textfield.TextInputLayout保存数据的代码非常简单SharedPreferences sp getSharedPreferences(user, MODE_PRIVATE); sp.edit().putString(username, username).apply(); sp.edit().putString(password, password).apply();这里有个非常容易踩的坑很多人连续调用两次sp.edit()然后发现密码没保存上。这是因为每次edit()返回的都是一个新的SharedPreferences.Editor对象正确做法是只调用一次然后连续put。sp.edit() .putString(username, username) .putString(password, password) .apply();比较两种提交方式commit()是同步写磁盘会阻塞调用线程apply()是异步写速度快得多。UI线程里一律用apply()。2.2 记事本的数据量决定了它必须用SQLite注册界面如果只是保存几个字符串SharedPreferences完全够用。但记事本不一样用户的每条笔记都是多条数据存在增删改查、按标题搜索、显示列表等需求这种场景就必须上SQLite。建表语句放在SQLiteOpenHelper的onCreate里Override public void onCreate(SQLiteDatabase db) { db.execSQL(create table if not exists note( id integer primary key autoincrement, title text not null, content text, update_time text)); }列表展示用RecyclerView配合一个NoteAdapter。很多人在这一步卡住其实是在插入新笔记之后忘记通知列表刷新。正确做法是在保存成功的回调里调用noteAdapter.notifyDataSetChanged();这样数据库里有数据UI也会同步刷新。如果数据量大了还可以用notifyItemInserted(position)只刷新新插入的item性能更好滚动也不会闪。2.3 这两个项目合起来的核心教训把两个项目放在一起做你会发现它们的代码风格完全不一样注册界面是“存进去就完事”记事本是“存完还要管得动”。这就是数据持久化最核心的分界线——数据是否需要结构化查询。判断标准很简单如果你只需要“按key取value”用SharedPreferences如果要做条件查询、关联查询、更新单条记录直接上SQLite不要犹豫。3. 音乐播放器和饭堂小广播媒体播放与定时播报的后台差异这两个项目是整套需求里最容易被混淆的因为都涉及“声音”。但实际上一个的重心在MediaPlayer状态管理另一个在系统定时任务调度。把它们对比着做能省掉很多绕弯的时间。3.1 音乐播放器的MediaPlayer与前台Service设计音乐播放器最容易出的问题不是界面而是跨页面播放和锁屏后被系统回收。播放的核心代码是MediaPlayer的状态切换mediaPlayer new MediaPlayer(); mediaPlayer.setDataSource(path); mediaPlayer.prepareAsync(); mediaPlayer.setOnPreparedListener(mp - mp.start());这里必须用prepareAsync()而不是prepare()。因为前者异步加载资源接口后者在主线程直接准备的话音频文件一大会卡到ANR。我在第一次写播放器时就用错了方法启动界面白屏好几秒后来才发现是把耗时操作放到了主线程。后台播放的完整方案是把MediaPlayer放在Service里Service再升级成前台服务。前台服务需要一个常驻通知这样即使应用退到后台系统也不会轻易杀掉播放进程。Notification notification new NotificationCompat.Builder(this, CHANNEL_ID) .setContentTitle(正在播放) .setContentText(songName) .setSmallIcon(R.drawable.ic_music) .setOngoing(true) .build(); startForeground(1, notification);别忘了在Android 8.0以上必须先创建通知渠道否则通知不显示。这也是很多播放器做完后锁屏界面没控制按钮的常见原因。3.2 饭堂小广播的定时触发链路饭堂小广播的需求一般是在指定时间点播报“开饭了”之类的提示。这里不涉及持续播放核心是怎么让代码在特定时间被唤起。最常用的方案是AlarmManager配合BroadcastReceiver。Intent intent new Intent(this, LunchReceiver.class); PendingIntent pi PendingIntent.getBroadcast( this, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE ); AlarmManager alarmManager (AlarmManager) getSystemService(ALARM_SERVICE); alarmManager.setRepeating( AlarmManager.RTC_WAKEUP, triggerAtMillis, AlarmManager.INTERVAL_DAY, pi );RTC_WAKEUP表示即使设备在休眠状态也会唤醒触发适合“午间定时播报”这种场景。然后在这个Receiver里发通知或者再进一步调用系统的文本转语音接口做语音播报TextToSpeech tts new TextToSpeech(context, status - { tts.speak(开饭啦请前往食堂用餐, TextToSpeech.QUEUE_FLUSH, null, 1); });Android 12及以上对精确闹钟有限制使用setRepeating已经不被推荐官方更建议用WorkManager或setExactAndAllowWhileIdle后者需要在权限列表里声明SCHEDULE_EXACT_ALARM。这个点很重要因为很多课程设计的测试机是Android 13或14直接跑旧代码会发现定时任务静默失效。3.3 两者对比后得到的关键判断音乐播放器的Service是一段持续运行的任务必须常驻饭堂小广播的Receiver是瞬态任务执行完就结束。这对组合能让你彻底搞懂Android后台执行的边界什么时候该用前台Service什么时候该用AlarmManager加Receiver。一个简单的判断标准是需要用户能感知到持续播放就选Service只需要在规定时间做一次提醒就选AlarmManager不要混用。4. 读取手机通讯录ContentProvider与运行时权限的配合读取手机通讯录和前面几个项目最大的不同在于它读取的数据不在自己应用的数据库里而是属于系统通讯录应用。这种跨应用读取数据的机制在Android里统一由ContentProvider完成。很多教程只给一段查询代码就完事但实际做起来坑基本都在权限和线程这两件事上。4.1 通讯录数据模型与查询写法通讯录的数据存在ContactsContract里最常用的读取接口是CommonDataKinds.Phone它已经帮我们把联系人和电话号码拼成了一张可查询的视图。ContentResolver resolver getContentResolver(); Cursor cursor resolver.query( ContactsContract.CommonDataKinds.Phone.CONTENT_URI, new String[]{ ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME, ContactsContract.CommonDataKinds.Phone.NUMBER }, null, null, null ); if (cursor ! null) { while (cursor.moveToNext()) { String name cursor.getString(0); String number cursor.getString(1); // 添加到列表 } cursor.close(); }这里有一个新手经常忽略的细节Cursor用完后必须close。循环读取的时候不关短时间没问题连续进入页面几次就会出现内存上涨甚至报CursorWindow相关的OOM异常。最好用try-finally包裹或者交给CursorAdapter类的组件去管理。4.2 运行时权限的处理流程从Android 6.0开始读取联系人这类危险权限必须运行时动态申请。流程三步走先检查有没有权限没有就弹窗申请然后在回调里判断结果。if (checkSelfPermission(Manifest.permission.READ_CONTACTS) ! PackageManager.PERMISSION_GRANTED) { requestPermissions( new String[]{Manifest.permission.READ_CONTACTS}, REQUEST_CODE_CONTACTS ); } else { loadContacts(); }回调里处理结果Override public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) { super.onRequestPermissionsResult(requestCode, permissions, grantResults); if (requestCode REQUEST_CODE_CONTACTS grantResults.length 0 grantResults[0] PackageManager.PERMISSION_GRANTED) { loadContacts(); } else { // 提示用户去设置页手动打开权限 } }如果用户点击了“拒绝且不再询问”后续再调用requestPermissions不会再弹窗这种情况要引导用户去应用设置页手动开启。这也是大厂应用都会做的“二次引导”逻辑实现不算复杂但能看出来对细节的把握。4.3 真实设备上的额外注意点沟通录查询不建议放在主线程。联系人多的时候查询结果会有几百上千条主线程直接跑会导致页面卡顿掉帧。正确做法是放到子线程拿到Cursor后再回主线程更新列表。还有一个很隐性的坑模拟器里默认没有联系人数据好不容易写完代码打开一片空白其实不是代码问题而是数据源为空。调试时先在模拟器通讯录里手动添加几个联系人再回来跑应用可以节省大量排查时间。5. 学生管理系统从demo到真正业务建模的分水岭前面五个项目都是单点技术练习学生管理系统才真正像企业级开发里的业务后台。它要求你把学生信息、课程信息、成绩信息串起来涉及多表关联查询和多个界面之间的数据流转。这是整套项目里最值得花时间做的一个。5.1 数据库如何用三张表解决业务关系一个可以应付答辩的数据库设计至少要三张表学生表、课程表、成绩表。学生表存基本信息课程表存课程成绩表通过外键关联学生和课程。这样设计的原因是一个学生可以选多门课一门课可以被多个学生选成绩表就是它们的中间关系表。create table student( id integer primary key autoincrement, name text not null, gender text, clazz text, phone text ); create table course( id integer primary key autoincrement, course_name text not null, teacher text ); create table score( id integer primary key autoincrement, student_id integer, course_id integer, score real, foreign key(student_id) references student(id), foreign key(course_id) references course(id) );用三张表而不是把所有信息塞进一张大表核心目的是消除数据冗余。比如某门课的授课老师信息只需要在课程表里保存一次而不是在学生表里重复存几十遍。这个思想叫“数据库规范化”答辩时老师基本都会问你应该能用自己的话讲清楚。5.2 页面组织与数据传参方式学生管理系统的功能可以按页面拆成三块学生列表页、学生编辑页、成绩统计页。这里建议用Intent传参的方式在编辑页保存后通过setResult把数据回传给列表页这样可以直观地练习Activity的生命周期交互。列表页核心代码recyclerView.setLayoutManager(new LinearLayoutManager(this)); studentAdapter new StudentAdapter(studentList); recyclerView.setAdapter(studentAdapter);编辑页保存后回传Intent intent new Intent(); intent.putExtra(student_id, studentId); setResult(RESULT_OK, intent); finish();如果你已经掌握了Fragment也可以用一个Activity嵌套三个Fragment的方式管理效果类似。但从课程设计答辩角度多Activity的方案更直观老师更容易理解你的逻辑也更容易讲清楚每个界面之间的关系。5.3 学生管理系统与前五个项目的复用关系做管理系统时你会发现自己写的很多代码都是眼熟的登录入口可以直接复用注册界面的TextInputLayout风格学生列表基本就是记事本列表的翻版如果在“学生通讯录”里接入读取通讯录的功能从联系人列表选择家长号码前一个项目写好的批量查询代码就能直接拷贝。这正是把零散项目串成体系的过程——你开始有意识地积累自己的代码资产了。这也是这套需求列表最大的价值它不是六个孤立作业而是一条由浅入深的学习路线。6. 六个项目串起来的推荐开发顺序与高频报错清单最后把这套项目按难度递增排一个实践顺序同时把我做这些项目时遇到的高频问题整理成一张清单你写的时候可以直接对照排查。6.1 推荐开发顺序我建议按这个顺序来做注册界面 → 饭堂小广播 → 记事本 → 音乐播放器 → 读取手机通讯录 → 学生管理系统。注册界面先解决Activity布局和事件监听饭堂小广播引入系统级组件AlarmManager和通知记事本把数据库CRUD补上音乐播放器把Service后台运行啃下来读取通讯录覆盖ContentResolver与运行时权限学生管理系统则是前面所有能力的大综合。这样每前一个项目都是后一个项目的地基不会出现“做到一半发现自己还没学数据库”的卡壳。6.2 高频报错排查表现象常见原因解决方式点击按钮没有反应没有setOnClickListener或按钮被其他控件遮挡检查控件的ID和布局层级RecyclerView不显示数据没设置LayoutManager或数据库更新后没通知Adapter必须setLayoutManager数据变更后调用notifyDataSetChanged()播放器中音频文件无法播放路径错误或prepare未完成就调用start在OnPreparedListener里调用start()设置完闹钟不触发Android 12以上精确闹钟权限缺失声明SCHEDULE_EXACT_ALARM权限并按需申请通讯录查询结果为空权限未授予或模拟器里没有联系人或没有 cursor.close()动态申请权限真机测试游标判空并关闭6.3 一些来自实际开发的习惯最后分享几个我个人很受用的习惯这些习惯对完成这套项目很有帮助。第一读取联系人这类数据量不确定的操作先打印Cursor的行数确认数据源有数据再写UI绑定能省掉很多无效调试。第二饭堂小广播如果要播报文字先做成通知栏提醒链路通了再替换成TTS语音渐进式开发比一步到位稳得多。第三多表数据库每次修改表结构一定要升级数据库版本号否则旧数据会直接清空这会让你在答辩演示时非常尴尬。做完这套项目后再去看任何应用你就会发现自己能看懂它们背后的模块划分了首页按钮对应注册界面的输入组合笔记列表对应记事本的RecyclerView后台播放对应音乐播放器的Service授权弹窗对应读取通讯录的权限流程。这种“看到一个App能拆出学过的技术”的感觉就是这几个小项目真正想教会你的东西。本文还有配套的精品资源点击获取
简介一套覆盖常见应用场景的安卓工程示例合集包含注册界面、饭堂小广播、音乐播放器、记事本、读取手机通讯录、学生管理系统等完整项目适合学生和刚入门开发者用于巩固Android基础与综合实战。项目涉及XML布局设计、输入校验、网络通信、定时任务、多媒体播放、文件存储、Content Provider、数据库及系统权限申请等典型知识点覆盖安卓开发常用技术栈。压缩包共628个文件以260个xml布局资源、137个java源码为主搭配大量webp、png图片素材以及gradle构建脚本、mp3测试音频等整体仅6MB。目前已有226人学习。通过对照源码可以快速梳理各模块的实现脉络尤其学生管理系统综合程度较高能够串联界面、存储、网络等多方面技能适合作为课设参考或阶段练习。 六七个安卓小项目一次性攒到同一个需求清单里这种组合在课程设计和自学路线里其实特别常见。注册界面、饭堂小广播、音乐播放器、记事本、读取手机通讯录、学生管理系统乍一看都是独立的小demo但拆开看它们恰好把Android开发的几条主线全串了一遍界面控件与输入校验、本地数据持久化、媒体播放与后台服务、系统ContentProvider跨应用读取数据、多表业务建模。这篇文章我就按自己的实际开发顺序把这几个项目逐个拆开讲包括每个项目练什么、核心代码怎么落、哪些坑最容易踩以及最后怎么把它们组装成一个完整的学习闭环。如果你正在准备安卓期末大作业或者刚学完基础语法想找一组练手项目这套组合能让你把零散知识点真正焊进项目里。1. 六个小项目背后的知识点地图先明确每个项目练什么很多初学者拿到这种多项目需求时第一反应是从最简单的开始逐个做这没问题。但我更建议先花半小时把每个项目的考点列清楚因为这几个项目看起来都叫“界面”实际底层技术完全不同。1.1 每个项目对应的核心知识清单项目核心知识点主要控件 / API注册界面布局、事件监听、输入校验、轻量存储EditText、TextInputLayout、SharedPreferences记事本SQLite、列表展示、增删改查RecyclerView、SQLiteOpenHelper音乐播放器媒体播放、后台服务、通知栏MediaPlayer、Service、Notification饭堂小广播定时任务、文本播报、通知提醒AlarmManager、TTS、BroadcastReceiver读取手机通讯录系统数据读取、运行时权限ContentResolver、ContactsContract学生管理系统多表设计、页面跳转、复杂CRUDSQLite、多Activity或Fragment、Adapter这个表格我建议收藏一下。以后无论拿到什么项目需求第一步都是先把“它考什么”列出来再动手写代码。比如“饭堂小广播”这个名字很生活化但它隐藏的考点其实是定时任务调度和系统通知如果你只想着做个播放页面方向从一开始就跑偏了。1.2 项目里没写明、但必须掌握的隐性考点注册界面练的是输入控件组合与数据校验但放到真实项目里它就是登录模块的前置页面。记事本练的是单表CRUD但它的难点不在建表而在RecyclerView的数据刷新时机。音乐播放器练的是MediaPlayer的状态机但列表页到播放页的场景切换才是工程师日常写的最多的代码。饭堂小广播看起来简单实际上它需要的AlarmManager对Android 12及以上的精确闹钟权限有严格要求这部分我在第3章单独展开。把这些隐性考点列出来之后整个项目的学习顺序也就自然出来了先用注册界面熟悉控件和Activity跳转再用饭堂小广播理解后台触发机制然后记事本练数据库音乐播放器练Service读取通讯录练跨应用数据访问最后用学生管理系统把这五条线全部揉在一起。2. 注册界面与记事本本地数据存储的两种打开方式这两个项目经常被当成“开胃菜”因为它们界面简单没有复杂的后台任务。但我想说的是注册界面和记事本放在一起练恰好能搞清楚Android里两种最常见的本地存储方案分别适用于什么场景。2.1 注册界面为什么首选SharedPreferences注册界面的本质是用户填表单点按钮保存数据并跳转。保存用户名密码这种轻量级键值数据时SharedPreferences是最直接的选择不需要建数据库表也不需要定义游标映射。布局部分我用TextInputLayout包了一层输入框比裸的EditText好用很多。它自带浮动标签、错误提示和密码可见性切换这些正是注册页的核心交互。com.google.android.material.textfield.TextInputLayout android:layout_widthmatch_parent android:layout_heightwrap_content com.google.android.material.textfield.TextInputEditText android:idid/etPassword android:layout_widthmatch_parent android:layout_heightwrap_content android:hint密码 android:inputTypetextPassword / /com.google.android.material.textfield.TextInputLayout保存数据的代码非常简单SharedPreferences sp getSharedPreferences(user, MODE_PRIVATE); sp.edit().putString(username, username).apply(); sp.edit().putString(password, password).apply();这里有个非常容易踩的坑很多人连续调用两次sp.edit()然后发现密码没保存上。这是因为每次edit()返回的都是一个新的SharedPreferences.Editor对象正确做法是只调用一次然后连续put。sp.edit() .putString(username, username) .putString(password, password) .apply();比较两种提交方式commit()是同步写磁盘会阻塞调用线程apply()是异步写速度快得多。UI线程里一律用apply()。2.2 记事本的数据量决定了它必须用SQLite注册界面如果只是保存几个字符串SharedPreferences完全够用。但记事本不一样用户的每条笔记都是多条数据存在增删改查、按标题搜索、显示列表等需求这种场景就必须上SQLite。建表语句放在SQLiteOpenHelper的onCreate里Override public void onCreate(SQLiteDatabase db) { db.execSQL(create table if not exists note( id integer primary key autoincrement, title text not null, content text, update_time text)); }列表展示用RecyclerView配合一个NoteAdapter。很多人在这一步卡住其实是在插入新笔记之后忘记通知列表刷新。正确做法是在保存成功的回调里调用noteAdapter.notifyDataSetChanged();这样数据库里有数据UI也会同步刷新。如果数据量大了还可以用notifyItemInserted(position)只刷新新插入的item性能更好滚动也不会闪。2.3 这两个项目合起来的核心教训把两个项目放在一起做你会发现它们的代码风格完全不一样注册界面是“存进去就完事”记事本是“存完还要管得动”。这就是数据持久化最核心的分界线——数据是否需要结构化查询。判断标准很简单如果你只需要“按key取value”用SharedPreferences如果要做条件查询、关联查询、更新单条记录直接上SQLite不要犹豫。3. 音乐播放器和饭堂小广播媒体播放与定时播报的后台差异这两个项目是整套需求里最容易被混淆的因为都涉及“声音”。但实际上一个的重心在MediaPlayer状态管理另一个在系统定时任务调度。把它们对比着做能省掉很多绕弯的时间。3.1 音乐播放器的MediaPlayer与前台Service设计音乐播放器最容易出的问题不是界面而是跨页面播放和锁屏后被系统回收。播放的核心代码是MediaPlayer的状态切换mediaPlayer new MediaPlayer(); mediaPlayer.setDataSource(path); mediaPlayer.prepareAsync(); mediaPlayer.setOnPreparedListener(mp - mp.start());这里必须用prepareAsync()而不是prepare()。因为前者异步加载资源接口后者在主线程直接准备的话音频文件一大会卡到ANR。我在第一次写播放器时就用错了方法启动界面白屏好几秒后来才发现是把耗时操作放到了主线程。后台播放的完整方案是把MediaPlayer放在Service里Service再升级成前台服务。前台服务需要一个常驻通知这样即使应用退到后台系统也不会轻易杀掉播放进程。Notification notification new NotificationCompat.Builder(this, CHANNEL_ID) .setContentTitle(正在播放) .setContentText(songName) .setSmallIcon(R.drawable.ic_music) .setOngoing(true) .build(); startForeground(1, notification);别忘了在Android 8.0以上必须先创建通知渠道否则通知不显示。这也是很多播放器做完后锁屏界面没控制按钮的常见原因。3.2 饭堂小广播的定时触发链路饭堂小广播的需求一般是在指定时间点播报“开饭了”之类的提示。这里不涉及持续播放核心是怎么让代码在特定时间被唤起。最常用的方案是AlarmManager配合BroadcastReceiver。Intent intent new Intent(this, LunchReceiver.class); PendingIntent pi PendingIntent.getBroadcast( this, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE ); AlarmManager alarmManager (AlarmManager) getSystemService(ALARM_SERVICE); alarmManager.setRepeating( AlarmManager.RTC_WAKEUP, triggerAtMillis, AlarmManager.INTERVAL_DAY, pi );RTC_WAKEUP表示即使设备在休眠状态也会唤醒触发适合“午间定时播报”这种场景。然后在这个Receiver里发通知或者再进一步调用系统的文本转语音接口做语音播报TextToSpeech tts new TextToSpeech(context, status - { tts.speak(开饭啦请前往食堂用餐, TextToSpeech.QUEUE_FLUSH, null, 1); });Android 12及以上对精确闹钟有限制使用setRepeating已经不被推荐官方更建议用WorkManager或setExactAndAllowWhileIdle后者需要在权限列表里声明SCHEDULE_EXACT_ALARM。这个点很重要因为很多课程设计的测试机是Android 13或14直接跑旧代码会发现定时任务静默失效。3.3 两者对比后得到的关键判断音乐播放器的Service是一段持续运行的任务必须常驻饭堂小广播的Receiver是瞬态任务执行完就结束。这对组合能让你彻底搞懂Android后台执行的边界什么时候该用前台Service什么时候该用AlarmManager加Receiver。一个简单的判断标准是需要用户能感知到持续播放就选Service只需要在规定时间做一次提醒就选AlarmManager不要混用。4. 读取手机通讯录ContentProvider与运行时权限的配合读取手机通讯录和前面几个项目最大的不同在于它读取的数据不在自己应用的数据库里而是属于系统通讯录应用。这种跨应用读取数据的机制在Android里统一由ContentProvider完成。很多教程只给一段查询代码就完事但实际做起来坑基本都在权限和线程这两件事上。4.1 通讯录数据模型与查询写法通讯录的数据存在ContactsContract里最常用的读取接口是CommonDataKinds.Phone它已经帮我们把联系人和电话号码拼成了一张可查询的视图。ContentResolver resolver getContentResolver(); Cursor cursor resolver.query( ContactsContract.CommonDataKinds.Phone.CONTENT_URI, new String[]{ ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME, ContactsContract.CommonDataKinds.Phone.NUMBER }, null, null, null ); if (cursor ! null) { while (cursor.moveToNext()) { String name cursor.getString(0); String number cursor.getString(1); // 添加到列表 } cursor.close(); }这里有一个新手经常忽略的细节Cursor用完后必须close。循环读取的时候不关短时间没问题连续进入页面几次就会出现内存上涨甚至报CursorWindow相关的OOM异常。最好用try-finally包裹或者交给CursorAdapter类的组件去管理。4.2 运行时权限的处理流程从Android 6.0开始读取联系人这类危险权限必须运行时动态申请。流程三步走先检查有没有权限没有就弹窗申请然后在回调里判断结果。if (checkSelfPermission(Manifest.permission.READ_CONTACTS) ! PackageManager.PERMISSION_GRANTED) { requestPermissions( new String[]{Manifest.permission.READ_CONTACTS}, REQUEST_CODE_CONTACTS ); } else { loadContacts(); }回调里处理结果Override public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) { super.onRequestPermissionsResult(requestCode, permissions, grantResults); if (requestCode REQUEST_CODE_CONTACTS grantResults.length 0 grantResults[0] PackageManager.PERMISSION_GRANTED) { loadContacts(); } else { // 提示用户去设置页手动打开权限 } }如果用户点击了“拒绝且不再询问”后续再调用requestPermissions不会再弹窗这种情况要引导用户去应用设置页手动开启。这也是大厂应用都会做的“二次引导”逻辑实现不算复杂但能看出来对细节的把握。4.3 真实设备上的额外注意点沟通录查询不建议放在主线程。联系人多的时候查询结果会有几百上千条主线程直接跑会导致页面卡顿掉帧。正确做法是放到子线程拿到Cursor后再回主线程更新列表。还有一个很隐性的坑模拟器里默认没有联系人数据好不容易写完代码打开一片空白其实不是代码问题而是数据源为空。调试时先在模拟器通讯录里手动添加几个联系人再回来跑应用可以节省大量排查时间。5. 学生管理系统从demo到真正业务建模的分水岭前面五个项目都是单点技术练习学生管理系统才真正像企业级开发里的业务后台。它要求你把学生信息、课程信息、成绩信息串起来涉及多表关联查询和多个界面之间的数据流转。这是整套项目里最值得花时间做的一个。5.1 数据库如何用三张表解决业务关系一个可以应付答辩的数据库设计至少要三张表学生表、课程表、成绩表。学生表存基本信息课程表存课程成绩表通过外键关联学生和课程。这样设计的原因是一个学生可以选多门课一门课可以被多个学生选成绩表就是它们的中间关系表。create table student( id integer primary key autoincrement, name text not null, gender text, clazz text, phone text ); create table course( id integer primary key autoincrement, course_name text not null, teacher text ); create table score( id integer primary key autoincrement, student_id integer, course_id integer, score real, foreign key(student_id) references student(id), foreign key(course_id) references course(id) );用三张表而不是把所有信息塞进一张大表核心目的是消除数据冗余。比如某门课的授课老师信息只需要在课程表里保存一次而不是在学生表里重复存几十遍。这个思想叫“数据库规范化”答辩时老师基本都会问你应该能用自己的话讲清楚。5.2 页面组织与数据传参方式学生管理系统的功能可以按页面拆成三块学生列表页、学生编辑页、成绩统计页。这里建议用Intent传参的方式在编辑页保存后通过setResult把数据回传给列表页这样可以直观地练习Activity的生命周期交互。列表页核心代码recyclerView.setLayoutManager(new LinearLayoutManager(this)); studentAdapter new StudentAdapter(studentList); recyclerView.setAdapter(studentAdapter);编辑页保存后回传Intent intent new Intent(); intent.putExtra(student_id, studentId); setResult(RESULT_OK, intent); finish();如果你已经掌握了Fragment也可以用一个Activity嵌套三个Fragment的方式管理效果类似。但从课程设计答辩角度多Activity的方案更直观老师更容易理解你的逻辑也更容易讲清楚每个界面之间的关系。5.3 学生管理系统与前五个项目的复用关系做管理系统时你会发现自己写的很多代码都是眼熟的登录入口可以直接复用注册界面的TextInputLayout风格学生列表基本就是记事本列表的翻版如果在“学生通讯录”里接入读取通讯录的功能从联系人列表选择家长号码前一个项目写好的批量查询代码就能直接拷贝。这正是把零散项目串成体系的过程——你开始有意识地积累自己的代码资产了。这也是这套需求列表最大的价值它不是六个孤立作业而是一条由浅入深的学习路线。6. 六个项目串起来的推荐开发顺序与高频报错清单最后把这套项目按难度递增排一个实践顺序同时把我做这些项目时遇到的高频问题整理成一张清单你写的时候可以直接对照排查。6.1 推荐开发顺序我建议按这个顺序来做注册界面 → 饭堂小广播 → 记事本 → 音乐播放器 → 读取手机通讯录 → 学生管理系统。注册界面先解决Activity布局和事件监听饭堂小广播引入系统级组件AlarmManager和通知记事本把数据库CRUD补上音乐播放器把Service后台运行啃下来读取通讯录覆盖ContentResolver与运行时权限学生管理系统则是前面所有能力的大综合。这样每前一个项目都是后一个项目的地基不会出现“做到一半发现自己还没学数据库”的卡壳。6.2 高频报错排查表现象常见原因解决方式点击按钮没有反应没有setOnClickListener或按钮被其他控件遮挡检查控件的ID和布局层级RecyclerView不显示数据没设置LayoutManager或数据库更新后没通知Adapter必须setLayoutManager数据变更后调用notifyDataSetChanged()播放器中音频文件无法播放路径错误或prepare未完成就调用start在OnPreparedListener里调用start()设置完闹钟不触发Android 12以上精确闹钟权限缺失声明SCHEDULE_EXACT_ALARM权限并按需申请通讯录查询结果为空权限未授予或模拟器里没有联系人或没有 cursor.close()动态申请权限真机测试游标判空并关闭6.3 一些来自实际开发的习惯最后分享几个我个人很受用的习惯这些习惯对完成这套项目很有帮助。第一读取联系人这类数据量不确定的操作先打印Cursor的行数确认数据源有数据再写UI绑定能省掉很多无效调试。第二饭堂小广播如果要播报文字先做成通知栏提醒链路通了再替换成TTS语音渐进式开发比一步到位稳得多。第三多表数据库每次修改表结构一定要升级数据库版本号否则旧数据会直接清空这会让你在答辩演示时非常尴尬。做完这套项目后再去看任何应用你就会发现自己能看懂它们背后的模块划分了首页按钮对应注册界面的输入组合笔记列表对应记事本的RecyclerView后台播放对应音乐播放器的Service授权弹窗对应读取通讯录的权限流程。这种“看到一个App能拆出学过的技术”的感觉就是这几个小项目真正想教会你的东西。本文还有配套的精品资源点击获取
