安卓互联手写实现：解决版本升级API失效痛点
版本升级后 API 全变了，旧代码直接报错，这种崩溃感谁懂？别再找那些过时的教程了，直接上手手写实现一套稳定的安卓互联方案，才能从根子上解决问题。
项目目标
咱们做技术博客，最怕的就是“水土不服”。很多读者反馈，照着网上 2021 年的代码跑，到 2024 年 Android 14 上直接崩，原因就是系统权限收紧、API 废弃。我们的目标很明确：不依赖第三方臃肿 SDK，从零手写一个轻量级、跨版本兼容的安卓互联模块。
这个模块主要解决三个场景：
- 设备发现：局域网内快速发现其他安卓设备。
- 数据同步：大文件（如视频、文档）的高效传输。
- 状态心跳：保持连接活跃，自动重连，避免“假死”。
为什么非要手写？因为第三方库往往封装得太深，出了 bug 你只能干瞪眼。手写实现，每一行代码都在你手里，哪里断了你知道，怎么修你也清楚。这就是安卓互联实战的核心价值——可控、可维护、可复现。
目录结构
为了保持工程化整洁，我们采用标准的 Gradle 模块结构。不要把所有逻辑堆在一个 Activity 里，那是新手才会犯的错。
com.example.androidconnect/
├── app/
│ ├── java/
│ │ └── com/example/androidconnect/
│ │ ├── MainActivity.kt // 入口，UI 展示
│ │ ├── model/
│ │ │ ├── DeviceInfo.kt // 设备数据模型
│ │ │ └── TransferState.kt // 传输状态枚举
│ │ ├── service/
│ │ │ ├── DiscoveryService.kt // 核心：设备发现服务
| | ├── TransferManager.kt // 核心：文件传输管理
│ │ └── util/
│ │ ├── SocketUtils.kt // 底层 Socket 封装
│ │ └── PermissionHelper.kt // 权限申请工具
│ ├── res/
│ └── AndroidManifest.xml // 权限声明重点
└── build.gradle.kts
注意 service 包下的两个核心类，这是整个安卓互联逻辑的大脑。DiscoveryService 负责“找人”，TransferManager 负责“传东西”。这种职责分离的设计，是为了方便后续单元测试和模块化扩展。
核心代码实现
这里是重头戏。我们不贴满屏代码，只讲最关键的手写实现逻辑，并逐行拆解为什么这么写。
1. 设备发现：UDP 广播的坑与解法
很多教程教你用 Wi-Fi Direct，但配置复杂且兼容性差。在局域网内，UDP 广播是最稳的。但 Android 7.0+ 对后台网络访问限制极严，直接 sendto 会静默失败。
// DiscoveryService.kt 片段
class DiscoveryService : Service() {private var socket: DatagramSocket? = nullprivate val handler = Handler(Looper.getMainLooper())private val discoveredDevices = mutableListOf<DeviceInfo>()override fun onCreate() {super.onCreate()// 关键：必须获取运行时权限，否则广播包发不出去if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_NETWORK_STATE) != PackageManager.PERMISSION_GRANTED) {// 启动 Activity 请求权限return}initSocket()}private fun initSocket() {try {socket = DatagramSocket(0) // 系统自动分配端口socket!!.setReuseAddress(true) // 允许多实例绑定socket!!.setSoTimeout(5000) // 设置超时，避免无限阻塞// 启动监听线程，接收其他设备的广播包Thread {val buffer = ByteArray(1024)while (isRunning) {try {val packet = DatagramPacket(buffer, buffer.size)socket!!.receive(packet)val data = String(packet.data).trim()// 解析 JSON 格式的广播包，包含 IP, 端口, 设备名val device = parseDeviceInfo(data)if (device.ip != getLocalIp()) { // 排除自己addOrUpdateDevice(device)}} catch (e: SocketTimeoutException) {// 超时正常，继续循环} catch (e: Exception) {e.printStackTrace()}}}.start()// 定时发送广播，告诉其他设备“我在这”handler.postDelayed(sendBroadcastRunnable, 3000)} catch (e: IOException) {e.printStackTrace()}}private val sendBroadcastRunnable = Runnable {try {val localIp = getLocalIp()// 构造广播包：IP:Port:DeviceNameval msg = "$localIp:$port:$deviceName"val bytes = msg.toByteArray()val broadcastIp = InetAddress.getByName("255.255.255.255")val packet = DatagramPacket(bytes, bytes.size, broadcastIp, BROADCAST_PORT)socket!!.send(packet)} catch (e: Exception) {e.printStackTrace()}// 3秒后再次发送，保持活跃handler.postDelayed(this, 3000)}
}
逐行讲解重点：
DatagramSocket(0)：传 0 表示让系统分配随机端口，避免端口冲突。setSoTimeout(5000)：这是很多新手忽略的。不设超时，线程会永久阻塞在receive()，导致无法退出或响应停止指令。- 广播地址：使用
255.255.255.255是最通用的局域网广播地址，比计算子网掩码更简单可靠，适合 C 类网络（大多数家庭/办公网）。
2. 文件传输：TCP 粘包处理
UDP 适合发现，TCP 适合传输。但 TCP 是流式协议，存在“粘包”问题。如果不处理，接收端可能一次收到多个文件头，或者把一个文件拆成多段。
// TransferManager.kt 片段
fun sendFile(file: File, socket: Socket) {val outputStream = socket.getOutputStream()val randomAccessFile = RandomAccessFile(file, "r")// 1. 先发送文件元数据：长度(8字节) + 文件名长度(4字节) + 文件名outputStream.write(Long.valueOf(randomAccessFile.length()).toByteArray())val fileNameBytes = file.name.toByteArray()outputStream.write(Int.toByte(fileNameBytes.size))outputStream.write(fileNameBytes)// 2. 分块发送文件内容，每块 1024 字节val buffer = ByteArray(1024)var bytesRead: Intwhile ((bytesRead = randomAccessFile.read(buffer)) != -1) {outputStream.write(buffer, 0, bytesRead)}outputStream.flush()randomAccessFile.close()
}fun receiveFile(socket: Socket, saveDir: File) {val inputStream = socket.getInputStream()// 1. 读取元数据val lenBytes = ByteArray(8)inputStream.read(lenBytes)val fileSize = ByteBuffer.wrap(lenBytes).longval nameLenByte = inputStream.read()val nameBytes = ByteArray(nameLenByte)inputStream.read(nameBytes)val fileName = String(nameBytes)val destFile = File(saveDir, fileName)val fileOutputStream = FileOutputStream(destFile)// 2. 按文件大小读取内容val buffer = ByteArray(1024)var totalRead = 0Lwhile (totalRead < fileSize) {val bytesRead = inputStream.read(buffer)if (bytesRead == -1) breakfileOutputStream.write(buffer, 0, bytesRead)totalRead += bytesRead}fileOutputStream.close()
}
避坑指南：
- 字节序问题：
Long.toByte()和ByteBuffer默认是大端序（Big-Endian）。如果发送端和接收端架构不同（虽然 Android 都是小端，但 Java 网络流通常用大端），务必显式指定order(ByteOrder.BIG_ENDIAN)，否则文件大小会解析成天文数字。 - 缓冲区分块：不要一次性
read()整个文件，内存会爆。1024 或 4096 字节是经验值，兼顾性能与内存占用。
运行与测试
代码写完了，怎么验证？别光看 Logcat 没报错就以为成功了。
模拟多设备环境： 由于测试手机可能只有一台，建议在 Android Studio 中启动两个 Emulator（虚拟机），分别配置不同的 Wi-Fi 网络（同一网段）。或者使用两台真机，连接同一个 Wi-Fi。
抓包验证： 使用 Wireshark 或 Android Studio 自带的 Network Profiler。观察 UDP 广播包是否真的发出去了，以及 TCP 连接建立后的数据流是否符合预期。重点看是否有
RST包，如果有，说明连接被重置，检查防火墙设置。弱网测试： 在 Network Profiler 中设置 "Slow 3G" 或 "Offline"。观察
DiscoveryService是否能自动重连，TransferManager是否能断点续传（当前代码未实现断点续传，这是进阶方向，但在弱网下必须考虑）。
常见报错排查：
java.net.SocketException: Permission denied：检查AndroidManifest.xml是否声明了INTERNET和ACCESS_NETWORK_STATE权限，且运行时权限已获取。Connection refused：目标设备的端口未开放，或目标设备TransferManager服务未启动。确保在接收端先启动监听线程。
优化扩展
基础功能跑通后，如何让它更“工程化”？
引入 OkHttp 替代原生 Socket？ 不建议。OkHttp 是 HTTP 协议，不适合这种自定义二进制协议。手写实现的优势就在于协议层的绝对控制。但可以用
AsyncTask或Coroutine替代原生Thread，避免阻塞主线程，提升代码可读性。加密传输： 公网环境下，明文传输是危险的。可以在 TCP 握手阶段增加 RSA 密钥交换，后续数据用 AES 加密。参考 OpenSSL 官方文档中的
TLS握手流程，理解非对称加密与对称加密的结合使用。状态管理： 使用
ViewModel+LiveData或StateFlow管理设备列表和传输进度。避免在 Activity 销毁时丢失传输状态。将TransferManager封装为单例，通过EventBus或Flow向 UI 层推送进度更新。断点续传： 在文件元数据中增加
Last-Modified时间戳和File-ID。接收端如果检测到相同File-ID且已存在部分文件，则从上次中断位置继续发送。这需要修改协议头，增加偏移量字段。
小结
通过手写实现这套安卓互联方案，我们绕过了第三方 SDK 的黑盒，彻底解决了版本升级后 API 失效的痛点。从 UDP 广播发现设备，到 TCP 流式传输文件，每一步都基于底层原理，而非堆砌 API。
技术不是背出来的，是踩坑踩出来的。你在这个项目中遇到过什么奇奇怪怪的 Bug？或者在权限申请上有什么独门技巧？
还有什么不懂的?评论区留言挨个回
