企业官网建设流程全解析

简介：面向Android毕业设计的签到系统学生端项目，主要服务高校课堂签到与出勤管理场景，适合计算机相关专业毕业生或Android入门开发者作为课题参考和实操训练。资源共246个文件，压缩包约89.86MB，包括97个Java文件实现核心业务逻辑、77个XML文件构建界面布局与资源配置、47张PNG图片素材、多个Jar依赖库以及一个可直接安装的APK文件，结构完整便于学习。目前已有180人学习浏览。项目覆盖从开发环境搭建到测试发布的完整链路，涉及Activity与Intent界面跳转、SQLite数据库存储、OkHttp网络通信与JSON解析、动态权限管理、通知提醒及高德地图SDK接入等毕业设计常见技术点，可帮助快速掌握学生签到系统的需求分析、模块划分与实现方法，也适合以此为基础扩展教师端或管理后台，提升毕设项目的完整度与答辩说服力。

1. 签到课题怎么选，学生端是哪一半

一个典型的“基于 Android 的签到系统”课题，通常被拆成教师端和学生端两个 App。教师端负责建课程、发签到码、看统计，学生端负责登录、选课、扫码或点按钮完成签到。网上能搜到的源码包里，学生端往往是最先被打开的那一半，因为它功能边界清晰、页面流程短、还容易演示——打开 App、登录、进教室、签到、看到“签到成功”的绿色提示，整个过程两分钟能走完，非常适合毕业答辩演示。

但“能演示”和“能通过”是两件事。指导老师最常问的三个问题是：怎么防止学生代签？怎么证明签到位置真实？数据存哪、掉了怎么办？这三个问题分别指向时间策略、定位策略和数据同步策略。学生端作为数据的产生端，承担了所有原始信息的采集和合法性证明，它的代码质量直接决定答辩时你拿什么回答这些追问。

这篇文章适合两类人：一是拿这个课题做毕业设计、想把学生端做成一个能跑通全流程而不是只摆 UI 的同学；二是想快速给内部培训或小团队做个轻量签到工具的 Android 工程师。下面按“环境 → 核心功能 → 数据层 → 防作弊 → 打包验证”这五条线把学生端的完整做法拆开。

2. Android Studio 项目重建：从 zip 到能跑的工程

2.1 先别急着打开 zip，先检查这套工程是哪一年的

你拿到手的“签到系统-学生端.zip”通常是一个完整的 Android Studio 工程目录，里面有app、gradle、build.gradle、settings.gradle这些文件。但很多毕业设计源码是三五年前的，打开之后会遇到一堆版本问题，最常见的两个：Gradle 版本和 Android Gradle Plugin（AGP）版本对不上 SDK 版本，以及compileSdkVersion比本机已安装的 SDK 低而报错。

第一步不是双击打开，而是先解压，用文本编辑器看build.gradle（顶层）和app/build.gradle里的关键版本号：

// 顶层 build.gradle 示例 buildscript { dependencies { classpath "com.android.tools.build:gradle:4.2.2" // AGP 版本 } } // app/build.gradle 里 android { compileSdk 31 // 编译用的 SDK 版本 defaultConfig { applicationId "com.example.checkin_student" minSdk 21 // 最低支持 Android 5.0 targetSdk 31 } }

逻辑说明：compileSdk决定你用什么版本的 API 来编译代码，minSdk决定最低支持到什么系统。如果 AGP 版本 4.2.2 对应 Gradle 必须是 6.7.1 以上，而工程里gradle/wrapper/gradle-wrapper.properties写的还是 6.5，就会在 Sync 阶段直接失败。参数调整优先级是：不要一上来就升 AGP，而是先对齐 Gradle wrapper 与 AGP 的兼容表。AGP 4.2.2 对应 Gradle 6.7.1，AGP 7.0 对应 Gradle 7.0，AGP 7.4 对应 Gradle 7.5。

2.2 本机 SDK 和 adb 的准备

下载 Android Studio 是绕不开的一步。装完后打开 SDK Manager（Tools → SDK Manager），重点看两个东西：

• “Android SDK Platform” 列表里是否有工程需要的compileSdk版本
• “SDK Tools” 里是否勾选了 “Android SDK Platform-Tools”，里面装着adb和sqlite3等调试工具

emulator 如果跑不动，可直接用真机。手机开启“开发者选项”和“USB 调试”，然后用adb devices检查连接状态：

adb devices -l

逻辑说明：这条命令会列出设备序列号和状态，正常情况是device而不是unauthorized。如果显示 unauthorized，说明手机上的授权弹窗没点允许。在后续调adb shell看数据库、拷贝崩溃日志，都依赖这一步先连通。

2.3 处理 Android 11 及以上的包可见性问题

如果你拿到手的学生端源码里用了PackageManager.queryIntentActivities()去检测是否安装微信或 QQ（有些方案会在签到时调起微信小程序），在 targetSdk 30+ 上会面临包可见性限制。解决办法是在AndroidManifest.xml里加<queries>声明，常见的写法是：

<queries> <package android:name="com.tencent.wework" /> <package android:name="com.tencent.mm" /> </queries>

注意，这行不是写在<application>里，而是与<application>平级放在<manifest>下。不加这段代码，运行时queryIntentActivities返回空列表，你会误判成“学生没装企业微信”，签到按钮直接置灰。这是一个隐蔽坑，报错不会崩，但功能失效。

3. 学生端核心流程：登录、课程列表、定位签到

3.1 HttpURLConnection 还是 OkHttp：怎么选

学生端最常见的网络交互就是登录请求和提交签到记录。毕业设计工程里两种写法都存在：老项目用HttpURLConnection，新一点的用OkHttp。我的建议是：如果原工程已经用了 OkHttp 就不用改，如果没引第三方库也别强行引，HttpURLConnection在 API 28 之后内部就是 OkHttp 内核，功能完全够用。

登录接口的常见写法是 POST 一个 JSON 到服务端，伪代码如下：

private String login(String studentId, String password) { HttpURLConnection conn = null; try { URL url = new URL(BASE_URL + "/api/login"); conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod("POST"); conn.setRequestProperty("Content-Type", "application/json"); conn.setConnectTimeout(5000); conn.setReadTimeout(5000); conn.setDoOutput(true); JSONObject body = new JSONObject(); body.put("studentId", studentId); body.put("password", password); OutputStream os = conn.getOutputStream(); os.write(body.toString().getBytes("UTF-8")); os.flush(); int code = conn.getResponseCode(); if (code == 200) { BufferedReader br = new BufferedReader( new InputStreamReader(conn.getInputStream(), "UTF-8")); return br.readLine(); } return null; } catch (Exception e) { e.printStackTrace(); return null; } finally { if (conn != null) conn.disconnect(); } }

逻辑说明：setConnectTimeout控制 TCP 连接建立的超时时间，setReadTimeout控制服务器返回数据的等待时间，毕业设计现场网络不稳定，建议分别设 5 秒不设太长。调用disconnect()是必须的，安卓 APP 的连接数有限，不释放会导致后续请求全部超时。注意这个函数是同步阻塞的，在 Android 里不能在主线程直接调，需要放进new Thread(...).start()或者用AsyncTask包一层，这是面试必问的基础。

3.2 课程列表和签到状态的 UI 联动

学生端的主界面通常是 RecyclerView 展示当天课程，每门课右边有一个“签到”按钮。这里有两个状态需要区分：这门课当前是否可以签到，以及你在这门课上是否已经签到过。

常见的做法是在列表数据模型里加两个字段：

public class CourseItem { private int courseId; private String courseName; private String teacherName; private String signStartTime; // 教师端设定的开始时间，如 "14:00" private String signEndTime; // 教师端设定的截止时间，如 "14:10" private boolean signed; // 本地是否已签到 }

按钮的点击处理要做一个时间判断：

private boolean isWithinSignWindow(CourseItem item) { SimpleDateFormat sdf = new SimpleDateFormat("HH:mm", Locale.CHINA); try { Date now = new Date(); Date start = sdf.parse(item.getSignStartTime()); Date end = sdf.parse(item.getSignEndTime()); return now.after(start) && now.before(end); } catch (ParseException e) { return false; } }

逻辑说明：判断用的是本地时间，这里会有一个真实问题：学生改手机系统时间能不能绕过签到窗口？答案是能的，因为Date()拿的是系统时间。这也是为什么正规签到系统一定要求服务端在校验时再判断一次时间，学生端的时间判断只是 UI 层面的提示。如果你在答辩中说“已经防止了改时间签到”，但工程里没有服务端时间接口，那么这个说法就站不住。稳妥的做法是在登录接口返回一个服务端时间戳存到内存里，签到判断时用这个时间戳而不是系统时间。

3.3 定位签到：GPS 还是网络定位

“定位”是签到系统里写得最乱的功能。很多学生直接拿LocationManager.getLastKnownLocation()的返回值当定位结果，拿到的往往是几分钟前的缓存位置，在教室里根本不准。我常用的方案是混合定位，先要求网络定位（MNC），再用 GPS 修正：

private void requestLocation() { LocationManager lm = (LocationManager) getSystemService(LOCATION_SERVICE); if (ActivityCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED) { requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, 100); return; } Criteria criteria = new Criteria(); criteria.setAccuracy(Criteria.ACCURACY_FINE); criteria.setPowerRequirement(Criteria.POWER_MEDIUM); String provider = lm.getBestProvider(criteria, true); lm.requestLocationUpdates(provider, 3000L, 5.0f, locationListener); }

逻辑说明：requestLocationUpdates的第一个参数minTimeMs是 3000 毫秒，表示最短时间间隔；第二个参数minDistanceM是 5 米，表示最短移动距离。效果是：时间超过 3 秒或者位移超过 5 米才触发一次回调。学生端如果在签到页停留，回调会持续更新经纬度，最后提交时用getLastKnownLocation反而可能拿的是旧值，所以要维护一个currentLocation变量，在回调里实时更新。Manifest 里需要声明ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION两个权限。到 Android 6.0 以后，ACEESS_FINE_LOCATION属于危险权限，必须在运行时动态申请，光在 AndroidManifest 里写是不够的。

下面是一份常用的签到请求参数表，前后端要约定好，否则教师端没办法判断这次签到是否合法：

4. 学生端的本地数据层：用 SQLite 存什么、怎么升级

4.1 为什么学生端也要本地数据库

很多签到系统的学生端是不做本地存储的，所有数据都从服务器拉。但实际场景里有两种痛：教学楼的 4G 信号差，签到页一直转圈；还有教师端写好后端接口没写好，答辩演示时拿不到数据。所以一个成熟的学生端应该把“课程列表”和“签到记录”各存一份到本地，界面优先加载本地缓存，再异步请求服务端刷新。

不建议用原生的SQLiteOpenHelper手写建表和增删改查，直接用 Room 的比较多。Room 自带编译期 SQL 校验，写错表名列名会直接报编译错误而不是运行期才崩溃，这对毕设工程的稳定性很重要。

4.2 Room 实体和 DAO 的定义方式

app/build.gradle里需要加三个依赖：

implementation "androidx.room:room-runtime:2.4.2" annotationProcessor "androidx.room:room-compiler:2.4.2"

实体类定义如下：

@Entity(tableName = "sign_record") public class SignRecord { @PrimaryKey(autoGenerate = true) private int id; @ColumnInfo(name = "course_id") private int courseId; @ColumnInfo(name = "student_id") private String studentId; @ColumnInfo(name = "sign_time") private long signTime; @ColumnInfo(name = "lat") private double lat; @ColumnInfo(name = "lng") private double lng; @ColumnInfo(name = "status") private int status; // 0=待上传 1=已上传 2=上传失败 }

DAO 接口：

@Dao public interface SignRecordDao { @Insert void insert(SignRecord record); @Query("SELECT * FROM sign_record WHERE status = 0") List<SignRecord> getPendingUploadRecords(); @Update void update(SignRecord record); }

逻辑说明：status字段是关键。签到时先写入本地数据库，status=0表示待上传，然后后台线程再去请求服务端。如果网络失败，就把status=2标记为失败，并且启动一个定时任务 10 秒后重试。这样即使用户在签到成功后立刻锁屏断网，本地数据也不会丢。Room 升级时需要在Room.databaseBuilder()里加fallbackToDestructiveMigration()，这个方法的副作用是升级会清空原有表，所以只适合毕设这种对数据留存要求不高的场景，不能带到生产环境。

4.3 数据库文件查看姿势

调试时最常遇到的问题是“我明明存了数据，但界面上不显示”。不要靠 Log 打印猜，直接用 adb 把数据库拉出来用 DB Browser 打开看。先把 App 跑起来，签一次到，然后执行：

adb shell "run-as com.example.checkin_student ls /data/data/com.example.checkin_student/databases/" adb exec-out run-as com.example.checkin_student cat /data/data/com.example.checkin_student/databases/sign_db.db > /tmp/sign_db.db

逻辑说明：第一行查看数据库文件名，第二行把数据库导出到本地/tmp目录。run-as只有 debuggable 的应用才能用，如果工程里把buildTypes的debug关掉或者 release 打包，这条命令会报run-as: package not debuggable。所以建议调试时统一用 debug 包名，最后发布才切 release。

5. 防作弊和边界处理：时间、地点、重复

5.1 重复签到的双重判断

学生端最容易出现的 bug 是连点两次“签到”按钮，本地生成了两条 sign_record。防止办法有两个层面：UI 层面在点击后立刻设置button.setEnabled(false)，业务层面在点击时先查一次本地库，查是否已有该课程当天的记录。

@Query("SELECT COUNT(*) FROM sign_record WHERE course_id = :courseId AND sign_time BETWEEN :startOfDay AND :endOfDay") int getSignCountByCourseAndDay(int courseId, long startOfDay, long endOfDay);

在点击回调里：

long now = System.currentTimeMillis(); long startOfDay = now - (now % 86400000L) - TimeZone.getDefault().getOffset(now); long endOfDay = startOfDay + 86400000L; int count = db.signRecordDao() .getSignCountByCourseAndDay(courseId, startOfDay, endOfDay); if (count > 0) { toast("今天已经签到过了"); return; }

逻辑说明：startOfDay的计算方式是用当前时间戳减去当天已经过去的毫秒数，再补偿时区偏移。这里不能直接now - now % 86400000就完事，因为那得到的是 UTC 0 点的毫秒数，在东八区等于当天早上 8 点而不是 0 点，会导致跨日判断错位。这个计算很容易被忽略，改时间测试时往往发现“今天签过”的判断会提前或延后几个小时。

5.2 位置偏差怎么容错

学生站在教室门口一米的走廊上定位，经纬度会和教师端设定的教室中心点差十几米。如果教师端把签到半径设成 100 米，这个问题通常不会暴露；但如果答辩时老师把“允许范围”调到 20 米来刁难，学生端的定位精度就要硬扛。计算距离用球面余弦定理或Location.distanceBetween：

float[] results = new float[1]; Location.distanceBetween( myLat, myLng, teacherLat, teacherLng, results); if (results[0] > limitMeters) { toast("不在签到范围内，距离" + Math.round(results[0]) + "米"); return; }

逻辑说明：results[0]拿到的是两点间的大地距离，单位是米。这里的坑在于myLat可能为 0.0，也就是定位还没成功就点了签到，此时 distance 结果达到一万多公里，必然在范围外。所以提交前要判断lat != 0 && lng != 0，并且最好判断一下Location.getAccuracy()的结果，误差大于 50 米的定位结果应当弹窗提示但允许用户强制提交，并把精度值一起传给服务端留作参考。

5.3 学生端的“防作弊”极限在哪

必须明确一件事：学生端单方面做不了真正的防作弊。学生拿到 root 权限后可以用 Frida 拦截 OkHttp 的请求体，直接伪造 lat/lng 字段。真正防伪造的唯一途径是服务端签名验证，或者使用高德/百度地图的 SDK 服务端 API 做地理围栏校验。但学生端能做的是把这些旁路尽量堵住：不上传模拟定位时isFromMockProvider()的结果；不上传Timestamp与服务端时间差异超过 10 分钟的请求；每次签名增加一个随机 nonce，防止重放攻击。

private boolean isMockLocation(Location location) { if (android.os.Build.VERSION.SDK_INT >= 18) { return location.isFromMockProvider(); } return false; }

如果返回值是 true，直接弹出一个“检测到模拟定位，签到失败”的对话框。这是一个很轻的防御，但对答辩现场的演示意义很大——你可以在老师面前开启“模拟位置”App 演示一次，然后展示这次签到被拦截了，这比任何口头解释都有说服力。

6. 打包验证和答辩前必须做的事

6.1 用 adb 模拟一次完整的签到链路

答辩前不要光靠手动点来验证，写一个固定流程比较靠谱。建议按这个顺序过一遍：

# 1. 安装 debug 包并拉起主界面 adb install -r app/build/outputs/apk/debug/app-debug.apk adb shell am start -n com.example.checkin_student/.ui.LoginActivity # 2. 模拟定位到教室坐标（用 fake location App 或 adb 命令） # 3. 登录测试账号，进入课程列表，点击签到 # 4. 从崩溃日志和数据库查看结果 adb logcat -c # 清空日志 adb logcat *:E # 只打印错误级别 adb exec-out run-as com.example.checkin_student cat /data/data/com.example.checkin_student/databases/sign_db.db > /tmp/after.db

逻辑说明：adb install -r是覆盖安装保留数据；am start是用组件名直接拉起 Activity，可以跳过一个层级。如果这条命令报Activity class does not exist，说明包名写错或者该界面是MainActivity。数据库导出后重点看sign_record表里有没有一条sign_time和当前时间匹配的记录，有就说明链路通了。

6.2 混淆和签名打包

release 包要签名才能装到真机上，Android Studio 的 Build → Generate Signed APK 走一遍即可。这里一个容易被卡住的点是：minifyEnabled true开启混淆之后，如果工程里有用反射调用的地方，代码会运行时报ClassNotFoundException。签到工程里最容易中招的是 JSON 解析库（如 Gson），它用反射读写字段，需要在proguard-rules.pro里加：

-keep class com.example.checkin_student.model.** { *; } -keep class com.google.gson.** { *; }

6.3 一句话讲清你的设计，留给答辩问答

老师问到“学生端核心设计亮点”，你只需要把下面这条思路说完整：签到时先本地落地，再从本地异步上传，配合时间窗口和地理围栏做合法性判断；教师端的统计依据不是你的 UI 状态，而是服务端记录的原始签到日志。如果现场断网，你还能当着老师的面模拟一次“飞行模式签到成功”，然后恢复网络，退出应用重新进来，看到那条记录变成了已上传状态。这一个演示就能证明你的学生端不是玩具，而是一个有状态机、有容错、有数据一致性的客户端。

本文还有配套的精品资源，点击获取