简介一套以Java语言编写的安卓端UDP报文发送小程序面向初学网络编程的开发者可用于局域网内的UDP包发送、连通性测试以及WiFi定位相关实验。项目核心包含发送客户端与主界面逻辑使用DatagramSocket和DatagramPacket完成创建套接字、封装目标IP与端口、调用send发送、关闭套接字等关键步骤代码量小便于逐行阅读和二次修改。压缩包共40个文件整体仅有97KB其中以17个XML配置与界面布局文件、4个Java源文件、3个Gradle构建脚本为主另含PNG图标、README说明、ProGuard规则和Gradle Wrapper导入Android Studio即可查看运行。截至目前已有505人学习下载通过完整源码可以查看网络权限声明、发送逻辑、界面布局以及广播接收等设计结合UDP无连接、不可靠的特性能帮助理解实时视频、在线游戏等场景下为何选用UDP。也可以继续扩展回包解析、超时重发和日志记录快速搭建自己的局域网网络调试工具。 前段时间在现场调一台嵌入式设备手头只有手机没有电脑想验证设备的 UDP 服务端口是不是活着、能不能正确解析我发的报文翻了半天应用商店要么是广告满天飞的「网络工具箱」要么是功能大杂烩但关键按钮藏得极深。后来实在受不了在回程高铁上花了半小时写了个安卓小程序取名 UDPSend只做一件事往指定 IP 和端口发送 UDP 数据包。这个小工具我到现在还留着。做嵌入式、工控、机器人通信的人应该都有同感——不是什么时候手边都有一台笔记本但手机几乎不离身。这篇内容就把 UDPSend 从需求到实现的关键细节拆开讲一遍包括 UDP 协议里和安卓开发强相关的几个点、工具的设计取舍、核心代码怎么写、真机上最容易踩的坑以及怎么验证工具本身是不是可靠。适合正在做安卓网络开发、或者是被 UDP 调试折腾过的朋友参考。1. 为什么我会动手写一个安卓端 UDP 发送工具1.1 现场调试设备时我突然意识到手机比电脑更顺手那次调试的对象是一个带 WiFi 模块的传感器盒子业务逻辑是把采集到的数据通过 UDP 主动上报到指定端口。设备端日志只显示「发送失败」但失败在哪一段完全看不出来。当时我最需要的是一个能往任意 IP:端口 发 UDP 包的工具用来区分是设备端问题、网络问题还是服务端问题。这种场景其实很常见开发板上跑着 UDP 服务你想快速验证它能不能收到数据现场没有串口线也没带电脑只能靠手机 WiFi 连设备要和 WSL2 里的 Ubuntu 子系统做 UDP 通讯测试手边只有手机用 LabVIEW 或 C# 做上位机 UDP 通信时需要一个独立的发包端做对照实验用手机发 UDP 包比在电脑上敲命令行更直观。触摸屏点几下就能发而且手机就在口袋里。至于为什么要自己写而不是随便找个工具下面说。1.2 为什么不想用现成的「网络调试助手」应用商店里叫「网络调试助手」的应用一抓一大把但真正好用的不多。我归纳了几类痛点包体臃肿。为了一个 UDP 发包功能附带了一堆根本不用的「TCP 服务端」「WebSocket 测试」「DNS 查询」功能安装包几十上百 MB。广告和权限问题。很多工具类应用内置广告 SDK申请一堆和网络调试毫无关系的权限在一个现场调试工具里这些都属于不可控因素。年久失修。不少老牌工具还是几年前发布的targetSdk 版本低在 Android 13、14 上可能闪退或者受到后台限制导致发包异常。最关键的一点别人写的工具你没法确定它底层怎么处理数据。比如十六进制模式下要不要过滤空格、字符串模式下用的是什么字符集这些细节对方不写文档你根本猜不到出了问题反而更难排查。所以我的结论很直接这种二十几 KB 就能搞定的小工具自己写一个比找一个完全信任的第三方应用成本更低。行为完全可控逻辑简单代码量少出了问题自己就能查。2. 动手前必须吃透的 UDP 关键点2.1 「发送成功」不等于对方收到了这是 UDP 调试里最容易被忽略的一点。TCP 是面向连接的发送前要三次握手对端确认收到了才算完UDP 则是无连接的你调用send()只是把数据报交给了本机操作系统的协议栈协议栈会尽力把它发出去但中途会不会丢、对端有没有收到、对端进程有没有绑定端口在监听全部没有反馈。这就带来一个很重要的调试思维转变用 UDP 工具发包如果对端没反应不要第一步就怀疑工具坏了。send()成功只是说明「本机发送成功」而不是「对端接收成功」。完整的验证链路要配合对端日志或者回显服务来判断这个后面会详细展开。2.2 一次 send 对应一次 recv别和 TCP 搞混UDP 是数据报协议发送端每调用一次send()接收端的recvfrom()就会读到一条完整的数据报。它不像 TCP 那样是字节流不存在粘包问题但存在「包边界」概念。这个特性对工具设计是有影响的UDP 发送工具不需要像 TCP 工具那样提供「分包发送」「流式发送」之类的功能一次点击发送一个数据报简单直接。但要注意 MTU 的限制。以太网标准 MTU 是 1500 字节减去 IP 头和 UDP 头各 20 字节和 8 字节单包数据超过 1472 字节后就会触发 IP 分片。分片报文在跨路由器时容易被丢弃实际调试中建议单包不超过 1400 字节。UDP 理论最大载荷是 65507 字节但我在代码里加了长度校验超过 65507 直接报错避免构造出无法发送的非法包。2.3 广播地址和组播地址是 UDP 的独门招牌TCP 是点对点的而 UDP 天然支持广播和组播。局域网里很多设备发现协议就是靠 UDP 广播实现的比如打印机发现、SSDP、部分工控设备的自动发现机制。所以我在设计 UDPSend 时特意保留了广播地址功能输入框里填255.255.255.255就能向局域网内所有设备广播一条消息填224.0.0.1之类的组播地址也能往组播组里发数据。这个能力在调试设备自动发现逻辑时特别有用。注意Android 设备发送 UDP 广播前确认 WiFi 路由器没有开启 AP 隔离。这个坑后面会专门说。另外补充一个容易被坑的知识点UDP 协议本身没有规定字节序网络上统一的规矩是网络字节序大端Big-Endian。嵌入式设备协议里经常有「帧头 长度 数据」之类的结构如果对方用的是小端模式工具最好能提供字节序切换选项。UDPSend 第一版没做这个后面扩展时再加。3. 只做「发送」一件事UDPSend 的设计取舍3.1 只做发送不做接收最开始我也纠结过要不要把接收功能一起做进去——毕竟「能发能收」听起来才完整。但仔细想了想接收功能会引入一堆额外问题接收需要绑定本地端口Android 上端口绑定和生命周期管理比发送复杂得多接收要常驻监听线程涉及后台运行限制、通知栏服务、省电策略等一系列问题工具被迫申请更多权限违背了「最小权限」原则主界面要加接收日志区交互复杂度翻倍更重要的是我做这个工具的初衷是「验证对端能不能收到」判断依据是对端日志不需要自己接收。如果要做完整的 UDP 调试助手那是另一个量级的项目。第一版只做发送代码量控制在几十行逻辑清晰出问题也容易排查。3.2 选型普通 Socket 加协程就够技术选型上有几个常见选项我的判断是Java 传统DatagramSocket这是最直接的方案几十行就能完成 UDP 发送没有任何学习成本。它的阻塞式模型对「用户点击一次发一个包」这种低频操作完全够用。Kotlin 协程 withContext(Dispatchers.IO)用协程把网络操作放到后台线程避免在主线程做网络操作导致 ANR代码也比Thread写法简洁。NIO 的DatagramChannel适合高并发或者需要非阻塞收发的场景对一个小工具来说是过度设计还让代码更难读懂。第三方网络库Netty 等功能强大但引入依赖后包体积、崩溃风险、学习成本都会上来不值当。最终选型是DatagramSocket Kotlin 协程核心发送类不超过 40 行。搭建界面用原生 XML 布局不引入 Jetpack Compose因为这个小项目完全没必要为一个按钮和两个输入框增加复杂度。3.3 交互流程一组输入框加一个按钮界面设计遵循「单一操作路径」原则打开应用看到的就是目标 IP、目标端口、数据内容、发送按钮外加一个十六进制模式的开关和简单的发送日志。这背后是有讲究的。调试工具在真正的现场使用中有个很核心的需求——操作路径短。打开应用到发出第一个包最好不超过三秒。如果界面有一堆 Tab、设置项、二级菜单虽然在功能上更强大但关键的发送按钮可能被埋得很深。这个取舍在工具类应用里非常重要。4. 核心实现从 DatagramSocket 到十六进制解析4.1 一个 30 行的 UdpSender 核心类先看最核心的发送类import java.net.DatagramPacket import java.net.DatagramSocket import java.net.InetAddress class UdpSender { private var socket: DatagramSocket? null Synchronized fun send(ip: String, port: Int, data: ByteArray) { val address InetAddress.getByName(ip) val packet DatagramPacket(data, data.size, address, port) if (socket null) { socket DatagramSocket() } socket!!.send(packet) } Synchronized fun close() { socket?.close() socket null } }几个容易被忽略的细节DatagramSocket()无参构造器会由系统随机分配一个本地端口发送端不需要关心本地端口是多少。UDP 发送前不需要connect()DatagramPacket构造时把目标地址和端口传进去就行。虽然DatagramSocket.connect()也能调用但那只是一种「过滤模式」不是 TCP 那种真正的连接。send()方法是阻塞的不要在主线程调用。我在调用处用withContext(Dispatchers.IO)包了一层。用Synchronized保证并发场景下 socket 初始化和发送不冲突。如果用户快速连点多次发送没有同步会导致创建多个 socket 实例浪费资源还可能出现异常。4.2 十六进制输入解析的隐藏坑做网络调试工具十六进制模式基本是标配。嵌入式设备的私有协议经常需要用十六进制字节序列来拼报文比如设备 MAC 地址过滤、寄存器地址读写之类。但十六进制字符串转字节数组这个功能看似简单坑不少。我踩过的坑包括用户输入0x01 0x02 0x1F这种带前缀的格式、输入01:02:1F这种带冒号的格式、输入01021F这种连在一起的格式还有0x01,0x02这种带逗号的格式。如果只处理一种格式用户很容易被搞懵。最终解析逻辑是这样处理的private fun parseHexString(input: String): ByteArray? { val cleaned input.trim() .replace(Regex(0[xX]), ) .replace(Regex([\\s:,、]), ) if (cleaned.isEmpty() || cleaned.length % 2 ! 0) { return null } return ByteArray(cleaned.length / 2) { i - cleaned.substring(i * 2, i * 2 2).toInt(16).toByte() } }先统一去掉0x前缀、空格、冒号、逗号、顿号等分隔符再判断剩余字符串长度是不是偶数最后两两一组转成字节。这样0x01 0x02、01:02、0102、0102四种输入都能正确解析。这里有个新手容易踩的雷如果用户输入了奇数长度的十六进制字符串比如0x123必须直接报错而不是猜测补零。很多工具会自作主张在末尾补零这在网络协议里是致命错误因为报文内容完全变了。4.3 校验、异常与线程调度发送逻辑再简单也必须在界面上看到反馈。我对输入做了这些校验IP 地址格式用InetAddress.getByName()解析捕获UnknownHostException提示「IP 地址格式不正确」端口范围0 到 65535但 0 到 1024 之间是系统保留端口通常不会用校验时提醒「端口范围建议在 1024 到 65535 之间」空数据拦截发送内容为空时直接提示「请输入要发送的数据」数据长度上限超过 65507 字节直接拦截提示「数据过长UDP 单包最大 65507 字节」异常捕获SocketException、SecurityException都捕获后转换成用户能看懂的错误消息而不是让应用闪退线程调度上点击发送按钮后代码逻辑是这样的sendButton.setOnClickListener { val ip ipEdit.text.toString() val port portEdit.text.toString().toIntOrNull() val data if (hexMode) parseHexString(dataEdit.text.toString()) else dataEdit.text.toString().toByteArray(Charsets.UTF_8) if (port null || data null) { showError(输入有误); returnsetOnClickListener } lifecycleScope.launch { val result withContext(Dispatchers.IO) { try { sender.send(ip, port, data) 发送成功${data.size} 字节 } catch (e: Exception) { 发送失败${e.message} } } logTextView.append(\n${Date().time} $result) } }这里有个界面体验的细节发送结果要用时间戳加上日志的形式展示出来而不是弹一个 Toast。因为调试时要连续发送多包一个带时间戳的日志列表能让你看到每次发送的间隔这对判断网络抖动、报文频率等非常有帮助。4.4 中文编码不能想当然字符串模式的编码也很关键。UDP 报文本质上是字节数组字符串转字节时用的是什么字符集对端就必须用什么字符集解析。我的实现里默认用 UTF-8因为现代设备和系统基本都是 UTF-8但要注意一些老旧的嵌入式设备可能用的是 GBK 或者 ASCII如果对显示乱码需要手动切编码。这是工具类应用要不要做编码选项的经典取舍。第一版我先固定 UTF-8扩展方向里加上编码切换。5. 真机和模拟器上最容易踩的三个坑5.1 模拟器的 NAT 网络发到宿主机要用 10.0.2.2如果你用的是 Android Studio 模拟器调试有一个最大的网络坑模拟器默认走 NAT 模式模拟器里的「本机」不是宿主机。模拟器访问宿主机要使用特殊地址10.0.2.2而不是127.0.0.1或者localhost。也就是说如果宿主机上开了一个 Python UDP 服务监听127.0.0.1:12345你想从模拟器发 UDP 包过去目标 IP 必须要填10.0.2.2端口填12345。我第一次调试时就栽在这里填了半天127.0.0.1服务端一点反应都没有。另外模拟器 NAT 模式下访问局域网其他设备也是受限的不能直接拿模拟器去测局域网里的嵌入式设备。真机调试时完全没有这个问题这也算是一个「模拟器能跑通不代表真机没问题」的典型例子。5.2 路由器的 AP 隔离WiFi 下「发送成功」也会失败这个坑在真机调试时特别隐蔽。手机连上一个 WiFi 路由器开发板也连同一个 WiFi手机往开发板的 IP 发 UDP 包send()返回成功但开发板就是收不到。排查到最后发现路由器开了 AP 隔离也叫「客户端隔离」或「无线隔离」。这个功能把连接到同一个 WiFi 的设备互相隔离禁止它们之间直接通信通常是为了防止局域网内部攻击但对调试来说就是灾难。遇到这种情况解决办法有三个关掉路由器的 AP 隔离或者把需要通信的设备用网线接到路由器 LAN 口让其中一个走有线上网或者把手机和开发板用自建热点连到一起避开路由器的隔离策略。这个问题的关键在于UDP 发送成功没有任何反馈你只能靠对端日志排除问题。5.3 对方收不到的排查顺序把常见问题归纳成排查顺序按以下顺序走基本能定位九成的问题排查步骤检查内容常见原因1目标 IP 是否正确看错了设备 IP或者设备 DHCP 地址变了2目标端口是否正确对端监听的是 12345你发到了 12343对端进程是否绑定端口在监听对端程序没起来或者绑定失败4防火墙是否放行 UDP 端口Windows 默认防火墙会挡 UDP 入站5路由器是否开了 AP 隔离或组播过滤无线设备间通信被隔离6是否需要广播/组播特殊处理对端不在同一广播域排查到第 4 步时有个经验Windows 宿主机上跑 UDP 服务通常要手动在防火墙里放行对应的 UDP 入站端口。用命令行netsh advfirewall firewall add rule nameUDP12345 dirin actionallow protocolUDP localport12345就能放行省事。这点在做 WSL2 和 Windows 的 UDP 通讯测试时同样适用。6. 用回显脚本验证工具并聊聊还能扩展什么6.1 用 Python 回显脚本做一次端到端验证工具写完不能只测「发送成功」还要验证「对端真的收到了内容」。最方便的做法是写一个 UDP 回显服务——收到什么就原样发回去。import socket s socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.bind((0.0.0.0, 12345)) print(listening on 12345) while True: data, addr s.recvfrom(4096) print(ffrom {addr}: {data.hex()}) s.sendto(data, addr)验证过程是这样的电脑上运行这个脚本监听 12345 端口手机和电脑连同一个局域网查清楚电脑的 IP 地址手机上打开 UDPSendIP 填电脑 IP端口填 12345数据填hello点击发送Python 控制台打印出hex编码后的数据说明手机到电脑的链路通了如果 UDPSend 做了接收功能目前没做回显的内容还能再收回来验证双向链路这种端到端验证非常必要。它能同时验证手机端发送逻辑和电脑端接收监听是排查「谁的问题」最靠谱的方法。6.2 如果要继续做我会加哪些功能当前版本满足 90% 的使用场景就够了但如果要往「更专业的调试工具」方向扩展我的排序是这样的周期发送设置发送间隔自动连续发包。这对验证对端服务稳定性、长时间跑链路很有用相当于一个轻量级打流工具。报文递增字段在数据里嵌入一个自增序号对端根据序号能判断有没有丢包。这是打流测试的进阶需求。广播地址快捷选择把255.255.255.255和常见组播地址做成快捷按钮省得每次手敲。历史记录保存最近发送的 100 条报文方便重复调试同一条指令。字节序切换十六进制模式下提供大端/小端转换开关适配更多嵌入式私有协议。接收模式开关如果用户确实需要「收发一体」做一个独立的监听页面但这时候就要处理后台服务、通知、前台服务类型声明等一系列新问题得单独开一个版本来做。我的看法是工具类应用的核心价值是「聚焦一件事并把它做到极致」。UDPSend 当前版本的定位就是发送 U DP 包它不会去抢 TCP 调试工具的饭碗也不会尝试做成一个完整的网络协议分析器。把你最常做的那件事做好比什么都强。最后分享一个小技巧我在 UDPSend 里加了发送计数显示——累计发出去多少包、成功多少包、失败多少包。这个看似不起眼的功能在实际现场调试时帮了大忙。比如你以为自己在连续发包测试丢包率结果手机上显示已经发了 500 包对端只收到 480 包那问题就定位到链路层而不是应用层了。这类「最基本的数据统计」往往比花哨的功能更实用。本文还有配套的精品资源点击获取
