1. 项目缘起与整体设计思路1.1 为什么要在 Android 上做 485 通信这个项目说起来不复杂但真正踩进去才知道水有多深。需求场景很典型一台 Android 工业平板通过 RS485 总线去控制一块 Modbus 从站板卡板卡负责驱动电磁锁、读门磁状态、采集环境传感器数据。整个系统跑在工厂车间里7x24 小时不间断运行对通信可靠性的要求远高于普通消费级 App。Android 设备做 485 通信本质上要解决三个层面的问题。第一层是物理层Android 平板本身没有 485 接口必须通过 USB 转 485 模块或者板载串口芯片来扩展第二层是驱动层Android 是基于 Linux 内核的串口设备在系统里表现为/dev/ttyXXX节点但普通 App 没有权限直接访问第三层是协议层485 只是电气标准真正通信还得靠 Modbus RTU 这样的应用层协议来组织数据帧。我选择android-serialport-api这个库理由很直接它足够轻量核心就是 JNI 调用open()、read()、write()这几个系统调用没有多余的抽象层。市面上有些库封装得很厚反而在排查底层问题时增加了干扰。但这个库也确实老最后一次更新是很多年前的事了用之前我就预感到会有坑只是没想到坑这么深。1.2 整体架构与数据流设计整个系统的数据流是这样的App 层的业务逻辑发起一个 Modbus 请求比如读取从站 1 的线圈状态请求经过 Modbus 协议栈封装成 RTU 帧从站地址 功能码 数据 CRC16 校验然后通过android-serialport-api的SerialPort对象写入串口。485 总线上的从站收到帧后解析如果地址匹配就执行操作并返回响应帧App 层再读取响应、校验 CRC、解析数据。这里有个关键设计决策读写必须分离到不同线程。串口的read()是阻塞调用如果和write()放在同一个线程里写完之后去读一旦从站没响应就会永久阻塞整个业务逻辑卡死。我的做法是开一个独立的读线程用InputStream持续读取读到完整帧后通过回调或者阻塞队列交给业务层处理。另一个决策是超时机制必须自己实现。android-serialport-api的read()没有超时参数它就是个阻塞的read()系统调用。我的方案是在读线程里配合available()方法做轮询或者用select()的思路——虽然这个库没直接暴露select()但可以通过设置串口的VMIN和VTIME参数来间接控制读取超时行为。1.3 为什么选 Modbus RTU 而不是其他协议Modbus RTU 在工业现场的地位不用多说简单、成熟、几乎所有 PLC 和板卡都支持。它的帧结构极其紧凑地址 1 字节、功能码 1 字节、数据 N 字节、CRC 2 字节。对于 485 这种半双工总线来说帧越短越好因为收发切换需要时间帧太长容易和其他从站的响应撞车。Modbus RTU 的 3.5 字符间隔判定帧结束这个机制在 Android 上实现起来要特别注意。理论上 9600 波特率下 3.5 个字符约等于 4ms但 Android 的线程调度不是实时的实际间隔可能远大于这个值。我的做法是不依赖精确的 3.5 字符间隔而是根据功能码预判响应长度读够字节数就认为帧结束配合 CRC 校验兜底。2. android-serialport-api 的两个深坑实录2.1 第一个坑设备节点权限与 SELinux 拦截这个坑是我遇到的第一个也是最让人抓狂的。按照android-serialport-api的文档你只需要传入设备路径和波特率调用SerialPort构造函数就行。但实际跑起来open()直接返回 -1日志里只有一句含糊的Permission denied。问题出在两处。第一处是 Linux 文件权限/dev/ttyS0或者/dev/ttyUSB0这些节点的属主通常是root:dialout权限是660。普通 App 的 UID 不在dialout组里自然打不开。第二处更隐蔽是 SELinux 的neverallow规则。即使你把文件权限改成666SELinux 仍然可能拦截appdomain对tty_device的访问。我试过几种方案。最直接的是 root 设备后chmod 666 /dev/ttyXXX但工业平板通常不给 root而且每次重启权限就恢复了。第二种方案是修改init.rc或者ueventd.rc在系统启动时自动设置权限但这需要系统签名或者 root 权限来 remount 系统分区。最终我采用的方案是在 App 启动时通过su执行 chmod如果设备有 root 的话。如果没有 root那就只能走系统应用的路子把 App 预置到/system/priv-app/下并在AndroidManifest.xml里声明android:sharedUserIdandroid.uid.system。这样 App 就以系统身份运行SELinux 上下文是system_app对串口设备的访问权限就放开了。注意sharedUserId在 Android 10 之后被标记为 deprecated但在工业定制固件上通常仍然可用。如果你的目标设备是 Android 12 以上且厂商没有做特殊适配这条路可能走不通需要联系设备厂商在固件层面开放串口权限。还有一个细节android-serialport-api的 JNI 代码里open()调用的是标准的open(path, O_RDWR | O_NOCTTY)。O_NOCTTY这个标志很重要它防止串口成为进程的控制终端否则某些信号比如 CtrlC会干扰串口通信。这个库默认带了算是省心。2.2 第二个坑JNI 层文件描述符泄漏与线程安全第二个坑更隐蔽是在长时间运行后才暴露的。系统跑了两三天后App 开始频繁崩溃日志显示Too many open files。排查后发现是SerialPort对象没有正确关闭每次重连都新开一个文件描述符旧的没释放。android-serialport-api的SerialPort类里有个close()方法但它只关闭了 Java 层的流JNI 层的fd是否关闭取决于FileDescriptor的close()是否被正确调用。我看了下源码SerialPort的构造函数里通过 JNI 拿到fd后包装成FileInputStream和FileOutputStream。如果你只调用SerialPort.close()它内部会调用mFd.close()但如果你在close()之前发生了异常mFd可能没有被正确初始化导致fd泄漏。我的修复方案是自己管理文件描述符的生命周期。在SerialPort外面包一层SerialPortManager用引用计数跟踪当前打开的串口确保close()一定被调用并且用try-finally保证异常时也能释放。另外read()和write()的并发调用需要加锁因为 JNI 层的fd不是线程安全的两个线程同时操作同一个fd会导致数据错乱甚至崩溃。public class SerialPortManager { private SerialPort mSerialPort; private InputStream mInputStream; private OutputStream mOutputStream; private final Object mLock new Object(); private volatile boolean mIsOpen false; public boolean open(String path, int baudRate) { synchronized (mLock) { if (mIsOpen) return true; try { mSerialPort new SerialPort(new File(path), baudRate, 0); mInputStream mSerialPort.getInputStream(); mOutputStream mSerialPort.getOutputStream(); mIsOpen true; return true; } catch (Exception e) { close(); return false; } } } public void close() { synchronized (mLock) { mIsOpen false; try { if (mInputStream ! null) mInputStream.close(); } catch (Exception ignored) {} try { if (mOutputStream ! null) mOutputStream.close(); } catch (Exception ignored) {} try { if (mSerialPort ! null) mSerialPort.close(); } catch (Exception ignored) {} mInputStream null; mOutputStream null; mSerialPort null; } } }提示SerialPort的构造函数第三个参数flags传 0 即可这个库对 flags 的处理比较粗糙传其他值反而可能引入问题。2.3 两个坑的共性根因分析回过头看这两个坑其实都指向同一个问题这个库太底层了把太多责任推给了调用者。权限问题需要调用者自己搞定 SELinux 和文件权限资源管理需要调用者自己保证fd不泄漏。它只做了最核心的 JNI 桥接剩下的全靠你自己。这在工业场景下其实是好事因为你需要对底层有完全的控制权。但前提是你得知道这些坑的存在否则就会像我一样在权限和泄漏问题上浪费大量时间。我的建议是如果你用这个库一定要在项目初期就把权限方案和资源管理框架搭好不要等到出问题了再补。3. Modbus 锁板可靠通信实战3.1 硬件连接与 485 总线拓扑先说说硬件。我用的是 USB 转 485 模块芯片是 CH340 加 MAX485。Android 平板通过 OTG 线连接模块模块的 A、B 端子接到锁板卡的 485 接口上。这里有个细节A 接 AB 接 B不要搞反了。我见过有人把 A、B 接反结果通信完全没反应排查了半天以为是软件问题。总线拓扑是手拉手的方式平板作为主站锁板卡作为从站。如果总线上有多个从站需要在最远端的从站上接一个 120 欧姆的终端电阻用来消除信号反射。我一开始没接通信距离短的时候没问题但线拉到 50 米以上就开始丢包加上终端电阻后就稳了。485 是半双工总线收发不能同时进行。USB 转 485 模块通常会自动处理收发切换但有些廉价模块切换延迟大导致发送完成后总线还没释放从站的响应就来了造成冲突。我的经验是发送完成后至少延时 10ms 再开始读取给总线足够的释放时间。3.2 Modbus RTU 帧结构与 CRC 校验实现Modbus RTU 的帧结构前面提过这里详细说下 CRC 校验。CRC16 的算法是标准的多项式0xA001初始值0xFFFF。我一开始自己写了个 CRC 计算函数结果发现算出来的值和在线工具对不上排查后发现是字节序的问题。Modbus RTU 的 CRC 是低字节在前高字节在后而很多 CRC 算法的输出是高字节在前。public static int crc16(byte[] data, int offset, int length) { int crc 0xFFFF; for (int i offset; i offset length; i) { crc ^ (data[i] 0xFF); for (int j 0; j 8; j) { if ((crc 0x0001) ! 0) { crc (crc 1) ^ 0xA001; } else { crc 1; } } } return crc; } // 组装帧时CRC 低字节在前 byte[] frame new byte[8]; // ... 填充地址、功能码、数据 ... int crc crc16(frame, 0, 6); frame[6] (byte) (crc 0xFF); // 低字节 frame[7] (byte) ((crc 8) 0xFF); // 高字节注意CRC 计算的范围是从站地址到数据段的最后一个字节不包括 CRC 本身。我见过有人把 CRC 也算进去结果永远校验失败。3.3 锁板控制的功能码选择与寄存器映射锁板卡支持的功能码有 01读线圈、05写单线圈、03读保持寄存器、06写单寄存器。控制电磁锁用 05 功能码最直接写0xFF00表示开锁写0x0000表示关锁。读门磁状态用 01 功能码读回来的位对应该线圈的通断状态。寄存器映射是板卡厂商定义的我拿到的文档里锁 1 对应线圈地址 0x0000锁 2 对应 0x0001以此类推。门磁状态在离散输入寄存器里用 02 功能码读取。这里有个坑不同厂商的地址偏移可能不同有的从 0 开始有的从 1 开始。我一开始按 0 开始写结果控制的是第二把锁排查后发现文档里写的是逻辑地址实际协议里要减 1。3.4 通信可靠性保障重试、超时与状态机工业现场电磁干扰大485 总线又长丢包是常态。我的可靠性保障分三层。第一层是超时重试每个 Modbus 请求发出后等待 200ms没收到响应就重试最多重试 3 次。第二层是CRC 校验收到的帧如果 CRC 不对直接丢弃当作没收到。第三层是状态机管理每个锁板卡维护一个状态机记录当前是空闲、发送中、等待响应还是错误状态避免并发请求打乱节奏。public class ModbusMaster { private static final int TIMEOUT_MS 200; private static final int MAX_RETRY 3; public byte[] sendRequest(byte[] request, int expectedResponseLen) { for (int retry 0; retry MAX_RETRY; retry) { try { synchronized (mLock) { mOutputStream.write(request); mOutputStream.flush(); } Thread.sleep(10); // 等待总线释放 byte[] response readResponse(expectedResponseLen, TIMEOUT_MS); if (response ! null verifyCrc(response)) { return response; } } catch (Exception e) { // 记录日志继续重试 } } return null; } private byte[] readResponse(int expectedLen, int timeoutMs) { long deadline System.currentTimeMillis() timeoutMs; byte[] buffer new byte[expectedLen]; int read 0; while (read expectedLen System.currentTimeMillis() deadline) { try { if (mInputStream.available() 0) { int n mInputStream.read(buffer, read, expectedLen - read); if (n 0) read n; } else { Thread.sleep(5); } } catch (Exception e) { return null; } } return read expectedLen ? buffer : null; } }提示available()在串口上返回的是当前缓冲区里的字节数不是总字节数。所以要用循环加Thread.sleep()的方式轮询不能指望一次available()就能拿到完整帧。3.5 多从站轮询与总线冲突避免如果总线上有多个锁板卡主站需要轮询。我的做法是维护一个从站列表按顺序逐个发送请求每个从站处理完再处理下一个。绝对不要并发发送485 是半双工总线两个请求同时发出去必然冲突。轮询间隔也要注意。从站处理请求需要时间如果主站发得太快从站还没准备好就收到下一个请求会直接丢弃。我的经验是每个从站处理完后至少间隔 50ms 再发下一个请求。如果从站响应慢这个间隔还要加大。4. 常见问题与排查技巧实录4.1 通信完全无响应怎么排查这是最常见的问题排查要按层次来。先确认硬件USB 转 485 模块的指示灯是否闪烁A、B 线是否接反终端电阻是否接上。然后确认设备节点ls -l /dev/tty*看看有没有新增的ttyUSB0或ttyS0。接着确认权限cat /proc/tty/drivers看驱动是否加载dmesg | grep tty看内核日志有没有报错。软件层面先确认波特率、数据位、停止位、校验位是否和从站一致。Modbus RTU 默认是 9600、8、N、1但有些板卡是 19200 或 115200。然后确认从站地址是否正确我见过有人把从站地址设成 0而 0 是广播地址从站不会响应。4.2 数据乱码或 CRC 校验失败数据乱码通常是波特率不匹配或者信号质量差。先确认波特率然后检查线缆是否屏蔽、是否远离变频器等干扰源。如果 CRC 偶尔失败可能是总线冲突或者帧间隔不对。我的做法是在发送和接收之间加延时并且用示波器或者逻辑分析仪抓一下波形看看有没有信号反射或者毛刺。还有一种可能是字节序问题。Modbus 的寄存器是 16 位的高字节在前还是低字节在前不同厂商实现不同。我遇到过读回来的温度值高低温反了排查后发现是字节序问题在解析时交换一下字节就好了。4.3 App 长时间运行后崩溃或卡死这个问题前面提过主要是fd泄漏和线程阻塞。排查方法是ls -l /proc/pid/fd | wc -l看文件描述符数量是否持续增长。如果是检查SerialPort的close()是否被正确调用。另外读线程如果一直阻塞在read()上close()时可能无法唤醒它导致线程泄漏。我的做法是在close()之前先关闭InputStream这样read()会抛异常退出。4.4 常见问题速查表问题现象可能原因排查方法解决方案完全无响应权限不足查看 logcat 是否有 Permission denied修改设备节点权限或使用系统签名完全无响应A/B 线接反交换 A、B 线测试正确接线完全无响应从站地址错误确认从站地址配置修改为正确地址数据乱码波特率不匹配确认双方波特率统一波特率CRC 校验失败帧间隔不对逻辑分析仪抓波形增加发送后延时CRC 校验失败字节序问题对比在线 CRC 工具调整 CRC 高低字节顺序长时间运行崩溃fd 泄漏查看 /proc/pid/fd 数量确保 close() 被调用长时间运行卡死读线程阻塞查看线程堆栈close() 前先关闭流多从站冲突并发发送检查发送逻辑改为轮询加间隔4.5 独家避坑技巧汇总第一个技巧用 Modbus Poll 和 Modbus Slave 先在 PC 上验证协议。PC 上的工具成熟稳定可以快速确认帧结构、寄存器地址、CRC 是否正确。确认无误后再移植到 Android能省掉大量排查时间。第二个技巧日志要打全。每次发送和接收的原始字节都打成十六进制日志出问题时一眼就能看出帧对不对。我习惯用String.format(%02X , b)格式化看起来清晰。第三个技巧串口打开后先发一个无效请求测试。比如发一个不存在的从站地址看是否有超时响应。这样可以确认发送通路是通的问题出在接收或者从站侧。第四个技巧电磁锁这类感性负载要加续流二极管。锁断开瞬间会产生反向电动势干扰 485 总线。我在锁的两端并了一个 1N4007通信稳定性明显提升。第五个技巧Android 的 USB 权限要动态申请。如果用的是 USB 转串口UsbManager需要用户授权才能访问设备。这个授权对话框在工业平板上可能被遮挡最好在代码里处理UsbManager.requestPermission()的回调。5. 性能优化与长期运行稳定性5.1 读线程的优化策略读线程是整个通信的核心它的效率直接影响响应速度。我最初的实现是while(true)循环里不断available()加sleep(5)CPU 占用率虽然不高但响应有最多 5ms 的延迟。后来改成用InputStream.read()阻塞读配合close()时关闭流来唤醒响应延迟降到 1ms 以内。但阻塞读有个问题如果从站一直不响应读线程会永久阻塞。我的解决方案是用available()做超时控制在循环里检查时间戳超时就退出。这样既保证了响应速度又避免了永久阻塞。5.2 内存与 GC 优化Modbus 通信频繁创建字节数组如果每帧都new byte[]GC 压力会很大。我的做法是复用缓冲区在ModbusMaster里维护一个byte[]池每次请求从池里取用完还回去。对于 7x24 运行的系统这个优化能显著减少 GC 次数避免 GC 停顿导致的通信超时。另外日志输出也要注意。如果每帧都打十六进制日志字符串拼接会产生大量临时对象。我的做法是只在调试模式打详细日志生产模式只打错误日志并且用StringBuilder复用。5.3 异常恢复与看门狗机制工业现场什么意外都可能发生USB 模块被拔掉、从站断电、总线短路这些都会导致通信中断。我的做法是加一个看门狗线程每隔 30 秒检查一次通信状态如果连续 10 次请求都失败就触发恢复流程关闭串口、重新打开、重新初始化。恢复流程要幂等多次执行不能出问题。我试过在恢复时没有正确关闭旧的SerialPort结果新的打开失败因为旧的fd还占着设备节点。所以恢复流程的第一步一定是close()并且要确保close()成功。5.4 长期运行的数据统计与监控为了评估通信质量我在 App 里加了一个简单的统计模块记录总请求数、成功数、超时数、CRC 错误数。这些数据通过日志定期输出方便分析通信稳定性。如果发现超时率突然升高可能是总线接触不良或者干扰加剧需要现场排查。这个统计模块用AtomicLong实现避免多线程竞争。每 1000 次请求输出一次统计既能反映趋势又不会刷屏。6. 项目复盘与个人体会这个项目从立项到稳定运行前后花了将近两个月其中大部分时间都花在排查android-serialport-api的坑和调试 Modbus 通信上。回过头看如果一开始就知道权限和fd泄漏这两个问题至少能省下一半时间。我个人在实际操作中的体会是工业场景下的 Android 开发和消费级 App 完全是两回事。消费级 App 可以容忍偶尔的卡顿和崩溃工业设备不行一次通信失败可能导致产线停摆。所以在这个领域可靠性优先于开发效率宁可多花时间做异常处理和测试也不要为了赶进度留下隐患。另外硬件和软件要一起排查。我遇到过好几次以为是软件问题最后发现是接线松动或者模块供电不足。所以手边常备一个 USB 转 485 模块和一根短接线能快速排除硬件问题。最后再分享一个小技巧Modbus 通信的调试逻辑分析仪比示波器好用。逻辑分析仪能直接解码 485 差分信号把 A、B 线的电平变化翻译成字节一眼就能看出发送和接收的帧对不对。我用的是一款几十块钱的入门级逻辑分析仪配合开源软件排查通信问题效率极高。这个项目后续还可以这样扩展把 Modbus 通信层抽象成独立的库支持 TCP 和 RTU 两种模式方便复用到其他项目。另外可以加一个 Web 配置界面让现场工程师不用改代码就能调整从站地址和寄存器映射。这些想法等有空了再慢慢实现。