1. 项目全貌从课程设计到可展示的完整作品很多人拿到基于Android的电影院网上订票系统这个题目时第一反应是这不就是个CRUD吗。但实际上把这样一个系统从零搭到能演示、能写论文、能答辩的完整状态牵扯到的知识点远比想象中多。我在带学生做类似项目时经常说一句话功能谁都能写出来但能不能把每个技术选型背后的为什么讲清楚才是论文和答辩里真正拉开差距的地方。这个项目的交付物包含四个部分源码、lw即毕业设计论文或课程设计报告、部署文档、讲解视频。也就是说你不仅要把代码写出来跑通还要形成一整套可交付、可复现、可答辩的闭环材料。这套材料放到求职作品集里也是展示Android开发基础能力的好例子——它覆盖了Activity生命周期、RecyclerView列表渲染、网络请求、SQLite本地存储、SharedPreferences会话管理等Android开发的核心知识点。先说清楚系统的核心业务边界。电影院网上订票用户端的核心操作链路是注册登录 → 浏览正在热映的电影列表 → 查看电影详情海报、简介、场次、票价 → 选择场次和座位 → 生成订单 → 在线支付在本地演示项目中通常用模拟支付 → 查看我的订单。管理端的核心操作链路是电影管理上下架、场次排片 → 订单管理 → 用户管理。这里面有个容易被忽略的设计细节座位选座逻辑。它不只是简单的点一下选中还涉及二维座位的状态管理已售出/已选中/可用、多人并发下座位占用的防止、以及前端交互时的即时反馈。在本地单体项目里座位状态一般存在SQLite中配合一个简单的状态位就能实现但需要考虑用户选中后多久释放座位这类业务规则。我在做的时候是设计了选中即锁定15分钟超时自动释放的简单策略效果够用写论文的时候也有东西可聊。适合这个项目的读者主要有三类一是正在做毕业设计或课程设计的计算机专业学生需要一个完整且能讲清楚的项目二是想快速上手Android开发、想通过一个完整项目串起知识点的初学者三是需要一套教学示例的老师和培训人员。下面所有内容都是我按从零到可交付的路径整理的每一步都尽量讲清选择和理由。2. 需求分析与数据库模型设计先画清楚业务边界动手写代码之前最值钱的时间是花在需求边界和数据库表结构上的。我见过太多人上来先建工程写到一半发现漏了订单状态流转又回去改表结构改到头疼。一个合理的流程是先白纸上画出角色、画出核心流程、画出状态流转再落成表和字段。2.1 角色与核心使用流程这个项目里有两个角色普通用户和管理员。用户不登录可以浏览电影和场次但下单必须登录。管理员主要负责维护电影信息和排片场次查看整体订单情况。核心流程我梳理成以下几组写论文时的业务流程图和时序图都可以从这几条链路里画用户找片流程用户打开App → 看到首页电影列表正在热映 → 点击某个电影进入详情页 → 详情页展示影片信息 该影片的场次列表 → 选择场次进入选座页。选座下单流程选座页展示座位布局通常是8-10排、每排8-12座 → 用户点击可选座位 → 确认选座并提交订单 → 订单状态变为待支付 → 模拟支付成功后状态变为已支付 → 座位同步标记为已售出。管理维护流程管理员登录后台 → 添加电影标题、海报、简介、时长、上映日期 → 为电影配置影厅场次时间、影厅编号、票价 → 查看订单汇总。还有一个容易忽略的用户体验点首页到底展示什么。我做过的最舒服的方案是首页默认展示今日热映影片每个卡片带海报、评分和票价起步价。用户知道今天有什么可看才有点进去的动力。不要一上来就是一堆管理功能那不是用户视角。2.2 数据表设计与字段取舍数据库我选了SQLite原因很简单Android原生支持、零配置、单文件存储适合课程设计交付。如果哪个答辩老师问为什么不用MySQL你可以回答移动端本地存储场景下SQLite足够支撑单机演示数据量且避免了对远程数据库的连接依赖部署时更稳定。这个回答本身就是加分项。核心表我设计了四张第一版的时候是五张后来砍掉了独立的影厅表把影厅信息直接冗余到排片表里减少了表间关联复杂度用户表tb_user字段类型说明idINTEGER 主键自增用户IDusernameVARCHAR(50)登录名唯一passwordVARCHAR(50)密码演示项目存明文即可生产环境必须加密phoneVARCHAR(20)手机号注册时留联系方式create_timeDATETIME注册时间电影表tb_movie字段类型说明idINTEGER 主键自增电影IDtitleVARCHAR(100)电影名称poster_urlVARCHAR(200)海报图片地址descriptionTEXT剧情简介durationINTEGER片长分钟ratingREAL评分用于列表展示release_dateVARCHAR(20)上映日期is_hotINTEGER是否热映标记1热映0已下架排片表tb_session字段类型说明idINTEGER 主键自增场次IDmovie_idINTEGER关联电影IDhall_nameVARCHAR(50)影厅名如1号厅show_timeVARCHAR(30)放映时间priceREAL票价total_seatsINTEGER该厅座位总数booked_seatsTEXT已售座位坐标集合存成JSON字符串这里我特别说下booked_seats字段。座位坐标我按 排-列 的方式编码比如第3排第5座写成3-5。已售座位统一放在一个JSON数组字符串里比如[1-1,1-2,3-5]。选座时把字符串解析成集合做判断下单成功后往集合里追加座位编号再存回去。这个设计简单直接单机演示完全够用也比单独建一张座位表少了大量冗余数据。订单表tb_order字段类型说明idINTEGER 主键自增订单IDorder_noVARCHAR(50)订单编号时间戳随机数拼接user_idINTEGER下单用户IDsession_idINTEGER关联场次IDseat_infoVARCHAR(100)订单选中的座位编号多个座位用逗号分隔total_priceREAL订单总价statusINTEGER状态0待支付 1已支付 2已取消create_timeDATETIME下单时间之所以单独掏出订单表说是想强调order_no订单编号这个字段的价值。很多新手第一版会忽略它直接用自增主键当订单号。但演示时一旦涉及到支付成功凭证查看订单详情等场景一个可读性强的订单号比如 20250613153022 4位随机数会显得专业很多论文里也值得写一笔订单编号采用时间戳与随机序列组合生成保证唯一性。2.3 为什么这样分表三张核心业务表 一张用户表的拆法遵循的是让每个业务流程最多关联2张表的原则。用户在首页看电影列表只查tb_movie进详情页看场次只查tb_session选座页要看哪些座位已经被占只查tb_session的booked_seats下单插入tb_order同时更新tb_session和tb_movie的相关标记。每个操作的数据源都足够简单写SQL语句时就不容易出错对初学者友好。答辩时如果被问到为什么不用外键约束可以这样解释SQLite默认关闭外键约束且本项目数据量小关联逻辑由应用层控制可以简化表结构、减少死锁风险。这个回答既说了事实也展示了你的取舍意识。3. 开发环境与工程搭建把基础版本锁好后面才不会折腾Android开发最怕的就是环境不一致导致的诡异问题。同一个项目在A机器上能跑在B机器上编译报错80%的原因是SDK版本、Gradle版本、依赖库版本不一致。我在动手前第一步就是锁定环境清单后续所有讲解和部署文档都跟这个清单保持一致。3.1 我用的环境配置组件版本备注Android Studio2024.1.x新版即可建议用官方最新稳定版Gradle8.x跟随Android Studio默认版本SDK PlatformAPI 34覆盖绝大多数Android真机minSdk24Android 7.0保证老设备也能装targetSdk34配合新版系统权限规范开发语言Java 17课程设计主流选择稳妥模拟器Pixel 6 API 34调试首选为什么选Java而不是Kotlin不是因为Kotlin不好而是考虑到这个项目的定位是课程设计和毕业论文Java的资源量更大遇到问题时更容易找到参考答辩时也更容易被老师理解。如果你本身Kotlin熟练完全可以用Kotlin重写逻辑层没有任何差异。3.2 工程结构和依赖引入包名我建议用com.example.cinema简单直接。工程内部按功能分包不要把所有Activity堆在一个包下。我的分包方式供参考com.example.cinema ├── activity // Activity层放各个页面 ├── adapter // RecyclerView适配器 ├── bean // 实体类对应用户、电影、场次、订单 ├── db // 数据库帮助类和DAO ├── util // 工具类如网络请求封装 └── fragment // Fragment比如首页的Tabbuild.gradle里核心依赖就四个别贪多dependencies { implementation androidx.appcompat:appcompat:1.7.0 implementation com.google.android.material:material:1.12.0 implementation androidx.recyclerview:recyclerview:1.3.2 implementation com.github.bumptech.glide:glide:4.16.0 }这里我细说下为什么必须引入Glide。电影海报如果是网络图片手动加载需要处理InputStream、Bitmap转换、缓存策略代码量大且容易OOM。Glide一行搞定Glide.with(context).load(url).into(imageView)内部自带内存/磁盘缓存和生命周期绑定省下的时间够你多调两个页面。如果项目里的海报走的是本地资源那Glide可以不加只是我个人不建议——演示时用网络图比本地图看起来真实得多。3.3 网络权限与文件读写权限配置在AndroidManifest.xml里有几项配置是新手特别容易漏掉的uses-permission android:nameandroid.permission.INTERNET / uses-permission android:nameandroid.permission.ACCESS_NETWORK_STATE /只加INTERNET还不够。如果你用HTTP明文协议访问后台接口Android 9API 28之后默认禁止明文流量这时候要么后台接口走HTTPS要么在manifest里开启明文流量豁免。本地开发和演示阶段我建议在application节点加android:usesCleartextTraffictrue这个属性只在application标签下有效加的时机是在Debug阶段到了正式发布再评估收紧。这个细节在部署文档里我会写个醒目提示因为很多人的后台接口就是http://192.168.x.x:8080/xxx不放开明文流量接口永远调不通。4. 核心功能模块的实现思路与关键代码拆解骨架搭好之后就是一步步填肉。我按用户从打开App到下单完成的路径来拆解每个模块给出关键的实现思路和代码不会把所有代码堆上来只讲透核心的那几段。4.1 用户注册登录SharedPreferences会话管理登录注册是系统的入口。注册逻辑没什么玄机校验用户名是否已存在、密码是否为空、两次密码是否一致然后插入用户表。登录成功后最关键的一步是记录会话状态SharedPreferences sp getSharedPreferences(cinema_prefs, MODE_PRIVATE); SharedPreferences.Editor editor sp.edit(); editor.putInt(user_id, user.getId()); editor.putString(username, user.getUsername()); editor.apply();为什么用SharedPreferences而不是自己写一个全局变量因为全局变量在App进程被杀掉后就丢失了而SharedPreferences是持久化存储App重启后仍然能读到登录态。这个设计对在选座过程中App被系统回收恢复后仍然保持登录的场景至关重要。在你的启动Activity里加一个判断如果sp.contains(user_id)直接跳转到主页否则跳转登录页。这段判断我放在onCreate里而不是启动闪屏页逻辑更清晰。Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); SharedPreferences sp getSharedPreferences(cinema_prefs, MODE_PRIVATE); if (sp.contains(user_id)) { startActivity(new Intent(this, MainActivity.class)); } else { startActivity(new Intent(this, LoginActivity.class)); } finish(); }4.2 RecyclerView加载电影列表电影列表是App的门面。用RecyclerView而不是ListView一个很大的理由是性能复用。ListView的ViewHolder需要自己写RecyclerView强制你实现ViewHolder模式语法上更规范。首页电影列表的适配器代码如下注意绑定数据时直接用Glide加载海报public class MovieAdapter extends RecyclerView.AdapterMovieAdapter.ViewHolder { private ListMovie movieList; private OnItemClickListener clickListener; Override public void onBindViewHolder(NonNull ViewHolder holder, int position) { Movie movie movieList.get(position); holder.tvTitle.setText(movie.getTitle()); holder.tvRating.setText(评分 movie.getRating()); holder.tvDuration.setText(movie.getDuration() 分钟); Glide.with(holder.itemView.getContext()) .load(movie.getPosterUrl()) .placeholder(R.drawable.ic_default_poster) .into(holder.ivPoster); holder.itemView.setOnClickListener(v - clickListener.onItemClick(movie)); } }这里有一个实际调试中很常见的问题图片加载失败时页面看起来像破图。Glide的placeholder参数能设置加载中的占位图加载失败时还需要error(R.drawable.ic_default_poster)。我的习惯是占位图和错误图用同一张至少保证列表不会出现灰色空块。4.3 电影详情与场次列表点击电影卡片跳转到详情页这个页面的信息层次是顶部大图海报片名评分 → 影片简介 → 中部选择场次区块。场次列表可能有多个按日期分Tab比如今天/明天/后天每个Tab下方是该日期的场次卡片卡片上显示放映时间、影厅、票价。场次数据的加载按movie_id从tb_session表中查。这里有个小的设计细节同一部电影一天可能有多场但列表不需要显示全部只需要显示未来未开始的场次。SQL里加上时间过滤String sql SELECT * FROM tb_session WHERE movie_id ? AND show_time ?;这个show_time 当前时间的过滤条件能避免演示时出现已经开演了1小时还能买票的尴尬局面。很多第一次做这类系统的人都会漏掉这个判断被答辩老师问到时候就愣住了。4.4 选座页面二维布局与状态管理选座是整个项目里最体现交互细节的模块也是很多学生最头疼的部分。思路其实不复杂用一张GridView或者动态添加的按钮矩阵按排和列生成座位。数据源是一个二维数组或一维数组行列计算每个座位有三种状态可购灰白色、选中橙色、已售灰色不可点。我先说排布方式。影厅通常前端是银幕位置座位从第1排往后排。屏幕上方的银幕用一个深色长条控件表示下方每排座位按行排布。每个座位的宽高计算出来后用一个GridLayout容器动态添加子控件GridLayout gridLayout findViewById(R.id.seat_grid); gridLayout.setColumnCount(seatColumns); // 例如8列 for (int row 0; row seatRows; row) { for (int col 0; col seatColumns; col) { TextView seatView new TextView(this); seatView.setText((row 1) - (col 1)); // 根据状态设置背景色 seatView.setOnClickListener(v - toggleSeat(row, col)); GridLayout.LayoutParams lp new GridLayout.LayoutParams(); // 设置每个座位的宽高比如80dp*80dp间距8dp gridLayout.addView(seatView, lp); } }座位上我不建议直接显示第3排5座字样会让界面显得拥挤。可以只显示列号比如每排第一个座位左侧显示排数3排座位本身显示列号1、2、3……这样视觉干净很多。状态切换逻辑用一个SetString selectedSeats来维护用户当前选中的座位已售座位集合从场次对象里拿到public void toggleSeat(int row, int col) { String seatNo row - col; if (soldSeats.contains(seatNo)) return; // 已售不可点 if (selectedSeats.contains(seatNo)) { selectedSeats.remove(seatNo); // 更新UI为可选状态 } else { if (selectedSeats.size() 5) { Toast.makeText(this, 单场最多选5个座位, Toast.LENGTH_SHORT).show(); return; } selectedSeats.add(seatNo); // 更新UI为选中状态 } // 刷新底部价格栏 updateTotalPrice(); }单场最多选5张是我当时定的业务规则你也可以不设上限但设一个限制在演示时有两个好处一是说明你考虑了真实业务场景影院通常限制单票购票数二是避免了用户疯狂点选后导致的界面和价格混乱。页面上需要一个实时更新的已选座位总价区域这样用户每次点击都有反馈。用户确认后点击立即下单携带场次ID和座位编号集合跳转到确认订单页。4.5 订单创建与模拟支付订单确认页展示的是电影名、影厅、场次时间、座位、单价、总价以及一个模拟支付按钮。为什么要模拟支付因为接真实支付宝/微信SDK需要商户资质毕业设计阶段用模拟支付是通行做法。点击支付按钮后执行以下三步将订单写入tb_order状态设为已支付更新场次表中booked_seats把本次选中的座位编号追加进JSON数组跳转到订单成功页并播放一个支付成功的动画或绿色勾图片。第二步的更新要特别小心。我见过有人把追加逻辑写成了覆盖——用户买了3个座位一提交其他已售座位全没了。正确做法是查出场次原座位集合合并新座位编号后整体写回JSONArray soldArray new JSONArray(session.getBookedSeats()); for (String seat : selectedSeats) { soldArray.put(seat); } String updated soldArray.toString(); // update tb_session set booked_seats ? where id ?订单编号的生成逻辑我当时放了一个工具类里public static String generateOrderNo() { SimpleDateFormat sdf new SimpleDateFormat(yyyyMMddHHmmss, Locale.CHINA); String timeStr sdf.format(new Date()); int random (int) ((Math.random() * 9 1) * 1000); return timeStr random; }4.6 我的订单列表与状态回退我的订单页用RecyclerView展示当前用户的订单每条订单显示电影名、场次时间、座位、金额、状态。这里需要联表查询订单表只存了session_id要拿到电影标题和场次时间需要关联tb_session和tb_movie。重点说说状态回退。演示过程中最常出现的场景是用户下了单但模拟支付环节被手滑返回了订单留在待支付状态。这时候用户应该能取消订单释放座位。所以订单列表里对待支付的订单要提供取消订单按钮点击后将订单状态改为已取消同时把对应场次里该订单的座位从booked_seats中移除。反过来已支付订单的座位就不能取消了——除非你在系统里设计了退票流程否则不要加这个入口避免逻辑复杂度上升。5. 关键难点拆解网络层、图片加载与会话保持界面功能写完后很多人的项目卡在同一个地方后台接口调试。课程设计项目一般有两种形态一种是纯本地SQLite像前面章节讲的另一种是Android端 远程后台JavaWeb/Node/PHP JSON接口。第二种形态在演示时更像一个真正的系统但也更容易踩坑。5.1 本地SQLite vs 远程后台接口怎么选我在前几版的项目里把两种方案都做过给你交个底对比项本地SQLite方案远程后台接口方案开发工作量低数据库操作全在Android端高需要额外开发后台演示效果只能在一台设备上看没有多端同步感可多设备登录查看数据统一稳定性极高无网络依赖依赖网络和服务器状态部署复杂低需要部署后台服务Tomcat等论文可写性中重点是Android端高可写前后端分离的设计我的建议是如果你时间充裕、有部署条件选远程后台方案论文的系统架构章节会好看很多如果时间紧、怕环境麻烦本地SQLite完全可以支撑演示关键是把Android端的功能讲透。5.2 网络请求用Volley还是OkHttp如果选了后台方案网络请求框架二选一Volley或OkHttp。我个人的倾向是Volley原因是它自带请求队列、结果回调、图片加载支持API设计更贴近Android课程设计的调性OkHttp更底层通常要搭配Retrofit使用引入的依赖和概念更多答辩时可能把自己绕晕。Volley的基本用法如下RequestQueue queue Volley.newRequestQueue(context); String url http://192.168.1.100:8080/cinema/api/movies; StringRequest request new StringRequest(Request.Method.GET, url, response - { // 解析JSONArray更新RecyclerView }, error - Toast.makeText(context, 网络请求失败, Toast.LENGTH_SHORT).show() ); queue.add(request);Volley放在主线程之外处理网络回调自动切回UI线程不用担心ANR问题。这一步我在部署文档里写得很详细——很多学生的网络请求崩溃都是忘了在真机上设置URL为电脑的局域网IP而不是localhost或者模拟器上用10.0.2.2代替localhost访问宿主机服务。这两个天然会造成误区的细节建议在论文的测试环境说明里写清楚。5.3 图片资源策略网络图还是本地图演示项目的海报图我建议优先考虑网络图片。用https://example.com/poster1.jpg这类硬编码URL或者直接引用一个在线的图片占位服务效果比mipmap下的本地图片真实太多。但网络图片的坑是如果现场演示时网络环境差海报加载不出来整个应用显得破败不堪。我的稳妥做法是在Assets或drawable目录下放3-5张本地备用图Glide加载失败时回退到本地图。Glide的.error()方法就是这个场景准备的Glide.with(context) .load(movie.getPosterUrl()) .placeholder(R.drawable.default_poster) .error(R.drawable.default_poster) .into(imageView);这样即使断网列表上至少还是有图的状态。5.4 登录态在多Activity间的传递很多新手会把user_id通过Intent在页面间传来传去比如从登录页传到主页再传到订单页。这个做法的问题在于一旦你直接在订单页启动App比如从最近任务恢复拿不到user_id整个页面就崩了。正确做法就是回到第4章说的SharedPreferences方案。所有需要用户身份的页面直接从这个全局Preferences里读int userId getSharedPreferences(cinema_prefs, MODE_PRIVATE) .getInt(user_id, -1); if (userId -1) { // 跳转登录页 }这个模式简洁稳定也是后面写论文用户会话管理一节的素材。6. 完整部署流程从源码到真机演示的全链路记录部署文档是这个项目交付物的重要组成部分很多人忽略了它的价值。部署文档不是给老师看的是给你自己留后路——项目写到一半想换电脑、答辩前几天系统突然炸了、老师要拷一份在他电脑上跑起来这时一份傻瓜式的部署文档能救你命。6.1 环境准备阶段部署文档的第一段永远写清楚环境要求。长度不要长但必须精确Windows 10/11 或 macOS 均可已安装 Android Studio版本见第3章已安装 JDK 17建议使用Android自带模拟器或真机打开USB调试如果是后台方案还需要安装JDK Tomcat或对应后台运行环境并准备MySQL数据库。6.2 导入源码并跑通本地SQLite版本本地SQLite版本不需要装MySQL部署相对简单。操作顺序解压源码压缩包用Android Studio的 Open 直接打开整个工程目录等待Gradle同步完成。如果同步失败优先检查网络Gradle需要下载依赖可以配置国内镜像源加速。连接模拟器或真机点击Run按钮等待编译安装。首次启动后如果没有跳转到登录注册页检查App是否会闪退若闪退查Logcat中的AndroidRuntime日志。6.3 远程后台方案的连调如果你采用Android端 远程后台的方案部署文档还需要额外几步在电脑上启动Tomcat将后台war包部署到webapps目录创建数据库并导入cinema.sql脚本一般源码里会带修改Android端某个Constant.java或ApiConfig.java文件里的BASE_URL// 模拟器访问宿主机用10.0.2.2真机用电脑局域网IP public static final String BASE_URL http://10.0.2.2:8080/cinema/api/;重新编译运行App用手机或模拟器打开首页确认电影列表能加载出来。这一步我实在踩过太多坑了。模拟器上的10.0.2.2是Android模拟器指定的宿主机地址不是localhost——写localhost一定不通。而真机调试时需要把电脑防火墙的8080端口放行否则手机访问不到。部署文档里把这些最坑但最常识的项写清楚你迭代项目的时候就再也不用临时翻帖子了。6.4 打包APK与演示前的自测清单答辩或提交前建议先跑一遍自测清单省得现场丢人[ ] 注册一个新账号用该账号登录 → 验证登录会话正常[ ] 首页电影列表加载正常点击进入详情场次列表数据正确[ ] 选座页面已售座位无法点击选中座位后底部价格实时更新[ ] 下单后模拟支付返回订单首页能看到已支付状态[ ] 退出登录后未登录用户点击下单能跳到登录页[ ] 杀进程重启App登录态仍保持不强制重新登录[ ] 横竖屏切换如果允许的话页面不崩溃数据不丢这个清单我建议跟着项目同步维护每修一个bug就补一条最终版本会成为一个很有说服力的交付物。7. 论文写作要点与讲解视频录制思路交付物里还有论文lw和讲解视频。这两部分看起来是写作文和拍视频但很多学生在这一步翻车——代码写得很好论文却写得像需求文档翻译老师看完不知道你到底做了什么。7.1 论文章节组织把做了什么变成为什么这么做论文的骨架我建议按这个顺序走绪论背景与意义、国内外研究现状。这一段不需要写太多重点是电影院订票系统的互联网化需求。相关技术介绍Android开发框架、SQLite、Volley或OkHttp、Glide。每项技术用1-2页讲清楚它是什么、为什么选它别写教科书级别的长篇大论。系统分析可行性分析技术、经济、操作、需求分析功能性需求、非功能性需求。这里可以画用例图、业务流程图。系统设计总体架构、功能模块划分、数据库设计表结构、E-R图。这一章要有设计感结构细到能看出来你确实想了。系统实现核心模块贴代码并结合文字描述选座逻辑、订单状态流转、数据库操作是重点。每一段代码下面都要写该段主要实现了什么。系统测试测试环境、功能测试用例表、部分测试结果。这章别糊弄填个20条以上的测试用例老师挑不出毛病。很多论文被老师挑工作量不足核心原因不是代码写得太少而是设计部分太单薄。把数据库表设计细化每个字段写清楚含义把API写清楚如果是后台方案把安全性和性能优化设计补上一两段工作量分分钟就上去了。7.2 讲解视频的录制节奏讲解视频一般10-15分钟我建议的节奏是开场0.5分钟说清楚系统名称、开发环境、整体功能。2分钟技术介绍概括性讲Android端的技术栈和整体架构。6-8分钟核心功能演示按登录 → 浏览 → 选座 → 下单 → 订单查看 → 后台管理顺序走一遍注意每个页面停留3-5秒让观看者看清界面。2-3分钟代码讲解打开核心代码讲选座状态管理和订单生成的实现逻辑。1分钟收尾总结项目特点点明可扩展方向比如接入真实支付、座位实时同步。录视频时注意两点分辨率开高一点尽量1080p录屏过程中不要点到通知栏。这俩问题我见过太多次视频提交后导师说看不清或者你手机弹了个微信广告体验瞬间下降。7.3 答辩前要准备的口头问答清单基于我参与评审的经验老师最爱问的五个问题建议提前写好回答稿Q座位状态为什么不用真正的实时同步方案A本系统面向单影院单店场景演示环境和数据量下采用应用层锁与座位状态串行更新即可满足需求如果扩展到多门店实时场次则需要接入服务端消息推送或WebSocket同步方案。这个回答既承认了现状又展示了扩展意识。Q用户密码存明文合理吗A演示阶段为了便于测试实际生产环境应使用MD5加盐或BCrypt加密存储。可以补充说明你了解了这个知识点只是没在课程设计中实现。Q不做支付对接是不是偷懒A真实支付需要企业资质与商户号课程设计不具备接入条件模拟支付完整覆盖了支付逻辑主流程——生成订单、更新状态、库存扣减是可以验证核心业务流程的。Q如果两个人同时买同一个座位怎么办A演示阶段单机应用通过操作顺序串行化避免了冲突真实线上系统需要数据库行级锁或乐观锁机制。这个答案同样要点到你知道怎么做。Q后续如何优化A接入真实支付、增加影片排片管理后台、引入服务端Redis缓存热门电影场次、接入消息推送通知用户取票信息。给出清晰的扩展路径即可。8. 开发过程中最容易踩的五个坑与对策写到最后把这些年的共性坑集中列出来希望你能绕开。第一坑Gradle同步失败。挂上代理或换镜像源工程里的build.gradle仓库配置加上阿里云镜像。这个问题90%都是网络问题不是代码问题。第二坑选座页面的座位大小错乱。动态添加座位时GridLayout.LayoutParams必须显式指定宽高否则可能被压缩成一行或挤成一坨。用dp单位不要直接用像素值。屏幕适配的话简单做法是按屏幕宽度动态计算每个座位的边长。第三坑模拟器键盘挡住输入框。注册页的输入框被软键盘遮挡是新手经常吐槽的问题。在AndroidManifest.xml中对注册页Activity设置android:windowSoftInputModeadjustResize这个属性让窗口在键盘弹出时自动调整尺寸界面就不会被盖住了。第四坑数据库升级导致App闪退。开发过程中你反复改表结构但手机上装的还是旧版本数据库SQL语句执行报错。对策是开发阶段卸载App重装交付前把数据库版本号相应调整并写清onUpgrade逻辑正式演示时就不用担心脏数据。第五坑Activity忘记在manifest注册。新建的Activity如果不加到AndroidManifest.xml里运行时直接闪退且报ClassNotFoundException。这个坑低级但发生率极高自查第一件事就是检查manifest。最后分享一个我一直在用的实操习惯每完成一个模块就截图存档。不只是最终效果图开发过程中的关键界面变化、测试数据、踩坑截图都放进一个截图归档文件夹里。写论文时你会发现这些截图无比珍贵——论文里的系统截图、测试截图、界面说明全都从这里面出。真的到答辩前几天再翻文件夹你只会后悔当初存少了。