简介：这是一份面向Android开发者的Modbus通信项目资源，核心是将开源jamod库移植至Android平台，解决在移动端与PLC、温控器、变频器等工业设备进行串口或以太网通信的问题。压缩包共173个文件，以105个Java源码为主，配合33张界面设计图、14份API与协议说明文档（apt格式），外加XML工程配置、JAR依赖及脚本文件，整体仅869KB，结构清晰，便于按模块阅读与二次开发。内容覆盖Modbus RTU/TCP/UDP三种模式下的主从通信实现，并针对Android的线程模型、串口JNI调用和异常处理做了适配，可帮助开发者避开常见移植陷阱。项目还包含多份How-to文档，能引导读者理解功能码、寄存器映射、数据解析等关键概念，形成从基础通信到设备适配的完整链路。此外，资源中涉及的串口权限配置、设备地址与寄存器规划等内容，对实际工业现场调试也很有参考价值。目前已有276人学习下载，适合具备一定Android和Java基础、需要快速接入Modbus设备的工程开发人员参考。
1. 先拆解：Android端做主站到底难在哪
1.1 Modbus协议基本盘与Master角色的定位
做工业控制的都知道，Modbus这协议糙是糙了点，但胜在简单、开放，现场上到PLC下到传感器，十有八九留了这个口子。Modbus-Master的意思是让Android设备充当主站，也就是主动发起请求的一方；下位机PLC、温控仪表、电表这些是从站，只能被动响应或等待轮询。为什么很多场合要用Android做主站而不是用现成的工业触摸屏？说白了就两个字：灵活。Android设备本身就带屏幕、带触摸、能联网，用一台平板同时承担人机界面和数据采集，成本比专用HMI低不少，而且改界面、加功能都方便，不用重新烧固件。
主站不是想当就能当的。做从站很简单，收到啥回啥，但做主站你得自己管理整个通信时序：什么时候发请求、发哪条请求、超时了怎么办、从站报了异常怎么解析。这些问题看着零碎，串起来就是一个完整的通信调度逻辑。1313如果之前只写过Android业务代码，没碰过串口和协议帧，一开始上手时最容易蒙的不是Android本身，而是Modbus那套字节级的报文格式。
1.2 选RTU还是选TCP，不能拍脑袋
Modbus最常见的两种载体是RTU（串口）和TCP（以太网）。我在实际项目里见过不少人一上来就直接上TCP，结果到了现场傻眼了，设备还是老式的RS485串口，根本没有网口。所以通信模式的选择应该在写代码之前就先定死：你的下位机是走串口还是走网口，决定了整个项目的数据链路层实现。
RTU走串口时，一条报文是从站地址 + 功能码 + 数据区 + CRC16校验，数据紧凑，一帧一般就8个字节左右，适合波特率不高的RS485总线。TCP模式则是把CRC去掉，加了一个MBAP头，包含事务ID、协议ID、长度等信息，走以太网，可靠性和速度都高不少。我的建议是：如果设备支持TCP，优先用TCP，因为不用处理串口权限和驱动问题，开发效率高很多；但如果你做的产品是要接到存量设备的RS485总线上，那就老老实实把RTU吃透。完整的项目大概率两种都要支持，我后文会给出统一设计。
1.3 自主实现还是用现成库
从业余到商用，Modbus主站这条路有两条走法：拿现成库封装，或者自己手写协议层。网上确实有Modbus4Android这样的开源库能用，但用起来有个老毛病——它把很多细节藏得太深，一旦现场出现兼容性问题，你根本不知道是哪一层出的错。反倒是自己写一个精简的帧构造和解析模块，总共就几百行代码，逻辑完全可控，排查问题的时候能直接打开日志看原始字节，比对着第三方库的源码猜要舒服得多。
我自己的习惯是这样的：核心协议帧部分绝对自己写，不依赖第三方；串口访问这种和硬件强相关的东西，用成熟库；TCP直接调Java Socket原生接口。这样分工，既保证了稳定性，也把最容易被卡的坑抓在自己手里。后面的内容我会沿着这个思路，给出一个可以直接落地的设计方案。
2. 开发环境搭建与关键工具选型
2.1 Android Studio与SDK环境要点
开发环境方面没什么特殊要求，Android Studio官方最新稳定版就行。Modbus-master这个项目用到的SDK组件很常规，一般就是Platform和Build-Tools。有一个新手常见的状况是下载Gradle特别慢，这个可以通过配置镜像源或者预先把Gradle发行包下载好放到用户目录下的gradle/wrapper/dists里解决，不用每次新建项目都重新拉。Android SDK路径最好提前确认好，后面配串口库的NDK编译或者集成USB转串口的so库时，需要用SDK里的工具链。
如果设备需要走USB转串口线，建议项目级最低SDK版本设置在Android 8.0左右，太旧的话有些USB Host API行为不一致。工控场景里Android版本碎片化非常严重，很多定制平板还停留在老旧系统，所以代码里凡是涉及USB权限请求和串口打开逻辑的地方，都要做兼容处理。
2.2 串口访问库怎么选
Android访问串口主要有两条路线：一是直接打开设备上的物理串口节点，比如/dev/ttyS3；二是通过USB Host协议连接外置USB转串口模块。物理串口常用Google的android-serialport-api，虽然这个库年久失修，但底层逻辑简单直接，基于JNI打开串口节点并配置参数，很多工控整机方案的厂商都默认适配过它。USB转串口则要看具体芯片，常见的有FT232、CP210x、CH340，其中FT232官方提供了Android使用的D2XX库，CH340在Android下的驱动支持比较弱，选硬件时尽量避开。
实测下来，我建议直接采用android-serialport-api的思路，自己维护一份JNI源码，不要用第三方封装太厚的库。理由很简单：串口打开失败时，原生代码报错信息最直接，而封装库常常把异常吞掉只给你返回一个false，排查起来非常痛苦。自己维护的代码里，打开失败时能把errno打出来，是权限问题还是设备节点不存在一目了然。
2.3 调试硬件与辅助工具清单
搞Modbus开发不能只靠模拟器，必须有真实硬件。最低配置是一台支持OTG的Android手机或平板，加一块USB转RS485模块，再加一个USB转串口模块连接到电脑。电脑端装一个串口调试助手的替代品，或者用Modbus Slave、Modbus Poll这类专业软件来模拟从站设备。Modbus Poll可以自定义从站地址、寄存器数据，还能设置异常响应，调试主站程序的容错逻辑时非常方便。
我在项目中最常用的黄金搭档是：Android设备跑自己的App，USB转RS485接一个真实的温湿度传感器或者自己搭的STM32从站，电脑上同时开一个串口监听工具挂在总线上。这样三方同时在线，既能验证功能，又能看总线上的原始报文，事半功倍。
3. 核心实操：手写一版稳定的Modbus RTU Master
3.1 通信线程模型：先定框架
很多初学者喜欢在Activity里直接开一个线程，循环里又是发送又是接收，最后把UI卡死、数据错乱，苦不堪言。做Modbus主站，第一步不是写协议，而是把线程模型想清楚。稳妥的方案是维护一个单线程的串口读写队列：所有请求都放到一个队列里，由一个专门的发送线程依次取出并发送，同时接收线程在读取响应。收到响应后通过Handler或者回调抛给业务层。
这里有个容易忽略的细节：Android主线程不能做串口读写，否则严格模式会直接崩，但也不能让网络请求和UI刷新混在同一个线程里。我通常把通信模块封装成一个独立的单例，内部维护两个线程，一个是Scheduler负责轮询任务调度，一个是IOThread负责真正的收发包。两个线程之间用BlockingQueue衔接，简单干净，不会出现并发把串口数据写乱的问题。
3.2 帧构造与CRC16：一次算对
RTU报文里最容易写错的就是CRC16校验。CRC16/Modbus的算法是查表法或逐位计算，多项式是0x8005反序后的0xA001，初始值为0xFFFF，计算结果低字节在前。我直接把一个能用的查表实现贴出来，这段代码我在多个项目里验证过，算出来的校验字节和串口调试助手完全一致：
public class ModbusCrc { private static final int[] TABLE = new int[256]; static { for (int i = 0; i < 256; i++) { int crc = i; for (int j = 0; j < 8; j++) { if ((crc & 1) != 0) { crc = (crc >> 1) ^ 0xA001; } else { crc >>= 1; } } TABLE[i] = crc & 0xFFFF; } } public static byte[] addCrc(byte[] data) { int crc = 0xFFFF; for (byte b : data) { crc = (crc >> 8) ^ TABLE[(crc ^ b) & 0xFF]; } byte[] result = new byte[data.length + 2]; System.arraycopy(data, 0, result, 0, data.length); result[data.length] = (byte) (crc & 0xFF); result[data.length + 1] = (byte) ((crc >> 8) & 0xFF); return result; } }读保持寄存器是Modbus里最常用的功能（功能码03），完整请求帧是从站地址 0x03 起始寄存器高字节 起始寄存器低字节 寄存器数量高字节 寄存器数量低字节 CRC低字节 CRC高字节。例如读从站地址1、起始寄存器0x0000、连续读10个寄存器，原始数据部分是01 03 00 00 00 0A，加上CRC后就变成01 03 00 00 00 0A C5 CD。写线圈、写单个寄存器、写多个寄存器等功能码，套路完全一样，按功能码表替换即可。这块的原理搞懂了，Modbus RTU主站就算完成了一半。
3.3 发送请求与超时处理：细节决定成败
报文构造好后，通过串口发送出去，接下来就要进入接收流程。接收时有两个关键参数，一个是帧超时时间，一个是帧间间隔。Modbus RTU标准里规定帧间间隔是3.5个字符时间，也就是波特率为9600时大约4ms，但Android系统不是实时操作系统，线程调度经常抖动，按理论值设超时很容易误判。达实建议至少设置成20ms到50ms，宁可慢一点也不能误判。另一个坑是串口设备读取时没有帧结束标志，你需要通过时间间隔判断一帧是否接收完毕，我实测用50ms的静默间隔来判断比较稳妥。
收到一帧数据后，第一步要校验从站地址是否匹配，第二步检查功能码的最高位，如果被置1说明从站返回了异常码，此时数据区第一个字节就是错误码，需要单独解析。最后再验证CRC，CRC对不上时直接丢弃，记录日志；这帧数据当中，超时重试是一个常见的排查点：我一帧等不到回复，最多重发两次，每次超时时间按从站最慢响应时间再乘以1.5算，避免在慢速设备上频繁重试把总线塞满。
3.4 Modbus TCP：把RTU改成TCP其实不难
RTU熟悉了之后，TCP模式的实现几乎是水到渠成。它和RTU的区别在于：没有CRC校验，多了一个MBAP头，整体帧变成事务标识符(2字节) + 协议标识符(2字节，固定为0x0000) + 长度(2字节) + 单元标识符(1字节) + 功能码 + 数据。其中长度字段的值等于单元标识符1字节 + 功能码1字节 + 数据区字节数，注意TCP模式下发送时不需要计算CRC，但读取响应时字节序一律是大端模式。
Android端走TCP直接用Socket加DataInputStream/DataOutputStream就可以，不用引入任何第三方库。我做TCP时会把每个从站在连接池里维护一个独立的Socket，每个Socket关联一个读写锁，因为Modbus TCP通常是一问一答的模式，同时发多个请求不等待响应，很多从站会直接忽略后续请求。一个连接同时只跑一个事务，是保证稳定性的前提。
4. UI层集成与轮询调度
4.1 数据实时刷新：别把UI线程堵死
工业App和普通App最大的区别在于，数据是一刻不停变化的，UI要跟着实时刷新。实测最舒服的方案是子线程把解析后的数据放到LiveData或者Handler里，让主线程去刷新界面。千万不要在串口收发线程里直接调用TextView.setText，一旦刷新频率一高，轻则丢帧重则ANR。如果有多个寄存器要显示，建议把数据封装成一个Java Bean，通过postValue一次性推送，UI收到后再批量刷新，比一条一条通知高效得多。
每个页面或者数据面板，在界面上要明确显示最后一次数据更新的时间。这个细节特别重要，因为串口通信卡死或者从站掉线时，如果界面没有任何提示，用户根本不知道数据是旧的，容易误判现场状态。我一般会在刷新回调里维护一个时间戳，超过设定时间没有新数据就主动触发重连或弹提示。
4.2 轮询策略与地址规划
Modbus主站最核心的调度逻辑是轮询。一个总线上可能挂着一二十个从站，每个从站要读十几个寄存器，轮询周期只能按顺序逐个发送。轮询周期的计算很简单：单次请求耗时乘以从站数量乘以寄存器组数。比如一个从站单次请求耗时100ms，总线上有10个从站，每个从站一组请求，一轮下来就是1秒，这种频率在大多数工业场景下都能接受。
轮询策略上我建议把请求分成快速区和慢速区：需要快速刷新的数据比如设备启停状态，放到快周期轮询；温度、压力这类变化慢的模拟量，放到慢周期轮询。这种分组调度比傻乎乎地按顺序全部轮询一遍，能省下大量的总线空闲时间，在从站多的时候效果尤其明显。具体实现上可以给每个请求配置一个interval字段，调度线程遍历请求列表，判断当前时间是否达到下个发送时间。
4.3 字节序与数据类型转换：最容易翻车的地方
Modbus寄存器默认是16位，大端字节序，也就是高字节在前。但在真实项目里，很多仪表厂家的寄存器映射表会乱写，比如把32位浮点数拆成两个寄存器，存放顺序有的是低字在前，有的是高字在前，还有的是高字节在前低字在后，五花八门。我吃过一次大亏，一个流量计的管道压力值怎么转换都差很远，最后拿串口抓包加厂家文档逐字节比对，才发现低字在前。后来我封装了几个通用的字节转换工具，支持大小端切换和高低字切换，所有数据解析统一走工具类，避免在业务代码里满天写死。
模拟量处理还有个隐藏问题：有些传感器数据是无符号的，有些是有符号的，不能一律按int处理。比如16位寄存器读出来是0xFFFF，在无符号场景是65535，在有符号场景是-1，用错符号会把量程完全算错。所以配置表里必须显式声明每个寄存器的数据类型，是int16、uint16还是float32，解析时按声明去套。
5. 实战踩坑与问题排查速查
5.1 串口打不开的3个隐藏原因
串口打不开在Android上是最常见的故障，原因一般有3个：第一是权限不足，普通App默认没有访问/dev/tty*节点的权限，工控整机方案一般会通过修改init.rc或者给APK签系统签名来解决，自己有设备的可以直接问厂商要权限方案；第二是设备节点被其他进程占用了，比如厂商的预置App可能偷偷打开了同一个串口，导致你这边打开即失败，这种问题可以用lsof /dev/ttyS3类似命令确认；第三是USB转串口时没有授予USB权限，Android会弹一个“允许访问USB设备”的对话框，点拒绝一次之后程序就很难再弹出来，需要到系统设置里找到对应应用，重置USB权限选项。
5.2 通讯不稳定与偶发失败的处理
通信不稳定，十有八九是这些原因造成的：总线没有接地或没有接终端电阻、波特率设置不一致、Android系统有蓝牙或WiFi扫描抢占线程调度导致帧间隔超时、发送和接收共用一个串口但并发造成数据交错。排查思路很直接，先用电脑端串口调试工具盯着总线，看是否有连续的错误帧，再用串口监听确认Android发出的字节是否和理论帧一致。如果收发正常只是偶尔超时，优先调大帧超时时间窗口，很多从站慢的时候要80ms才能返回一帧，而你只给了20ms的等待，自然会导致偶发失败。我一般先按从站手册里的最坏响应时间设定超时，再在实际跑一段时间后微调。
排障时有一个好用的方法：把每条原始收发帧都打成十六进制日志，并打上时间戳。这样出了问题，翻日志就能还原整个总线通信过程，比盲调强太多。我在所有项目里都会在通信模块里加一个调试开关，正式发布时关闭，开发时打开，日志里既包含收发字节也包含解析结果。
5.3 现场调试的“三板斧”
现场调试时我有一套固定流程，遇到问题基本能快速定位：第一斧先用电脑串口工具直接和从站通信，确认从站本身没问题，寄存器地址和功能码都正确；第二斧把Android设备接到同一总线上，用调试版App只发一条读指令，看返回的原始字节和电脑端是否一模一样；第三斧如果字节一致但业务数据不对，那就是解析层的问题，重点检查字节序、数据类型和寄存器映射表。这三步走完，90%的问题都能落到具体某一个环节上，剩下10%大概率是硬件问题，比如线上有别的设备干扰或者地电位不一致。
最后再分享一个心得：做Modbus-master的过程中，真正花时间的不是协议本身，而是把通信的边界条件都想清楚。串口读写失败、从站超时、数据校验错误、线程并发冲突、UI卡顿，每一个坎儿都值得提前设计好应对机制。建议手写一套精简的协议层，把所有关键日志都留好，后面接到新设备时，你只需对照寄存器映射表加配置，不用改核心代码，这套骨架就能一直复用下去。
本文还有配套的精品资源，点击获取
