简介一份面向Android开发者的TCP客户端实现资源围绕Socket通信、线程管理与异常处理等关键点演示如何在Android设备上创建TCP客户端并与远程服务器进行双向数据交换。项目包含完整的Eclipse工程源码压缩包共49个文件以java源码、class字节码、xml配置和png图片为主同时附带有可直接安装的apk及dex文件便于对照源码直接运行验证通信效果整体体积仅436KB。已有1057人学习浏览适合初学Android网络编程、正在做毕业设计或需要在应用中快速集成TCP通信模块的开发者。从中可获取TCPClient类完整实现、Socket初始化与数据收发代码、子线程中处理网络耗时操作的方法以及通过Handler或接口回调更新UI的典型写法。项目是一个紧凑实用的入门参考可帮助快速掌握Android端可靠数据传输流程。 做Android的TCP客户端项目很多人一开始都以为很简单——new一个Socket、传个地址端口、write几个字节Demo就跑通了。但真正把它放进一个要长期运行、会被系统回收、还得在弱网环境里保持连接的App里你很快就会发现问题从来不是怎么连上而是连上之后怎么稳定地活着。这篇文章把我在实现Android TCP_Client过程中踩过的坑和最终沉淀下来的方案整理出来核心覆盖协议帧设计、连接管理、线程协作和Android版本差异适配适合刚接触Socket的Android开发者也适合手头有demo级客户端、想改成工程级模块的朋友参考。1. 先搞清楚TCP客户端项目的真实工作边界1.1 它不是能连上而是持续稳定地连上大多数Android TCP_Client项目业务背景都很相似手机连接局域网里的硬件设备比如串口服务器、PLC、智能网关或者对接服务端自定义的二进制协议。这些场景基本都不是发一条消息、收一条回复的HTTP式交互而是要建立一条长期存活的数据通道。这个长期存活四个字才是整个项目的真正工作量所在。一个demo只需要三件事连接、发送、接收。但一个能上线的客户端模块要处理的至少包括连接超时和读超时兜底不能因为一次弱网就永久卡死。服务端随时可能断开客户端要能感知并在几秒内恢复。数据流里出现半包、粘包要能正确拆帧不能把两帧数据混着解析。Activity销毁时不能泄漏Thread或者Handler网络层不能持有UI层引用。App进入后台、系统休眠、Doze模式下连接不能被静默杀掉。这些需求不是附加功能而是TCP客户端的基本盘。如果一开始就把它们放进设计里后面能省掉大量返工时间。1.2 一个可维护的TCP客户端由哪些部分组成我习惯把一个完整的客户端拆成五个部分分工明确互不掺和模块职责关键点连接器建立Socket、设置超时、发起重连超时参数不能写死读循环从InputStream持续读数据并交给解析器阻塞读单独线程帧编解码器处理粘包/半包解析出完整消息帧必须是有状态的累积缓冲心跳与重连维持活跃连接断开后指数退避恢复状态机清晰禁止重连风暴UI回调桥把网络事件安全地抛到主线程不持有Activity强引用每个模块之间通过接口通信。连接器只负责socket生命周期它不知道业务帧长什么样帧编解码器只处理字节流和Frame对象的互相转换不关心这条消息是心跳还是业务数据UI层只实现Listener接口不碰任何网络线程。这样拆开之后测试和排查都非常舒服——哪个环节出问题直接单独看哪个类。1.3 为什么不用现成的网络库会有人问Netty for Android、OkSocket、或者直接用协程加Ktor不是更省事吗我自己的判断是这取决于协议复杂度。如果业务建立在HTTP或者WebSocket上老老实实用OkHttp没必要自己造轮子。但如果服务器协议是私有TCP二进制帧Netty那套pipeline机制在Android上偏重而且很多业务团队对Netty内部状态机并不熟悉出了问题反而更难查。我自己实现一个五六个类的轻量客户端几百行代码所有状态流转都在自己掌控里调试成本低很多。这个取舍不是绝对正确但对于私有TCP协议不需要极致吞吐的业务场景轻量自研的性价比确实更高。接着往下看核心设计你就能理解为什么这些类必须存在。2. 协议帧设计与粘包拆包处理传输层只保证字节流2.1 TCP是流协议消息边界必须自己定义初学者最容易忽略的一件事TCP没有消息的概念它只是把字节按顺序从一端流到另一端。你调用两次send分别发了Hello和World对方可能在一次read里就收到HelloWorld也可能先收到Hel再收到loWorld。这个问题在Android上尤其明显因为Wi-Fi网络下的MTU、TCP窗口、Nagle算法都会影响数据到达的粒度。如果不对数据做帧封装解析端根本不知道一条消息在哪里结束、下一条从哪里开始。常见的解法是固定长度法、分隔符法和长度前缀法。固定长度法适合所有消息等长的极简场景遇到变长数据就是浪费分隔符法比如用\n结尾简单但业务字节流里如果本身包含分隔符需要转义反而容易出bug我最推荐长度前缀法每个包固定格式用头部的长度字段告诉解析端这条消息有多大。2.2 设计一个够用的二进制帧项目里我采用的帧结构如下大端字节序字段偏移长度说明魔数02固定0x5A 0xA5用于快速校验和同步版本21协议版本号当前0x01类型310x01心跳0x02业务0x03登录可自行扩展长度44载荷payload的字节数不含头部载荷8N消息正文魔数的作用是容错和同步。如果网络流里意外混入了脏数据解析端可以通过魔数找回正确的帧边界不至于全盘错乱。版本号是为了以后协议升级留的口子不用一升级就把整个解析逻辑推翻。长度字段占用4字节理论上支持最大2GB的payload——实际使用中根本到不了这么大一般会设一个上限比如64KB防止异常包把内存撑爆。对应的Frame对象也很简单字段就是version、type、payload外加一个encode方法把对象转成字节数组。这里有个容易踩的坑编码的时候一定要用DataOutputStream或者手动做位移不要依赖String.getBytes()后直接System.arraycopy因为不同编码下字符串字节长度不一样容易造成长度字段和实际内容不一致。2.3 半包和粘包的解析代码解析端需要维护一个累积缓冲因为一次read读到的数据可能是半帧、一帧整的、也可能是多帧。核心逻辑是先把新数据追加进缓冲然后循环尝试从缓冲头部解析帧能解析出完整帧就消费掉解析不到完整帧就保留剩余字节等下一次read。public class FrameCodec { private static final int HEADER_LENGTH 8; private static final int MAX_PAYLOAD 64 * 1024; private final ByteArrayOutputStream buffer new ByteArrayOutputStream(); public ListFrame decode(byte[] data) throws IOException { ListFrame frames new ArrayList(); buffer.write(data); byte[] buf buffer.toByteArray(); int offset 0; while (true) { // 剩余字节不够一个头等待下次数据 if (buf.length - offset HEADER_LENGTH) { break; } // 魔数不匹配逐字节向后滑动找同步点 if (buf[offset] ! (byte) 0x5A || buf[offset 1] ! (byte) 0xA5) { offset; continue; } int payloadLength ((buf[offset 4] 0xFF) 24) | ((buf[offset 5] 0xFF) 16) | ((buf[offset 6] 0xFF) 8) | (buf[offset 7] 0xFF); if (payloadLength 0 || payloadLength MAX_PAYLOAD) { throw new IOException(invalid payload length: payloadLength); } int totalLength HEADER_LENGTH payloadLength; // 数据不够一帧等待后半包 if (buf.length - offset totalLength) { break; } byte[] payload Arrays.copyOfRange(buf, offset HEADER_LENGTH, offset totalLength); frames.add(new Frame(buf[offset 2], buf[offset 3], payload)); offset totalLength; } // 把已消费的字节移除保留剩余的半包字节 if (offset 0) { byte[] remaining Arrays.copyOfRange(buf, offset, buf.length); buffer.reset(); buffer.write(remaining); } return frames; } }这段代码有两个细节值得说。第一所有字节组合都要用 0xFF处理因为Java的byte是有符号的直接移位会导致负数和符号扩展解析出的长度完全是错的。第二半包场景下buffer里保留的是上次未消费完的字节如果每次read都触发新的ArrayCopy会有性能开销但Android手机处理这种量级的数据完全够用不必过度优化。3. 连接管理从Connect到断线重连的完整机制3.1 connect超时和读超时必须显式设置Socket默认的connect行为是无限期阻塞的如果目标IP不可达主线程会一直卡住直接导致ANR。所以创建Socket后一定要用Socket.connect(InetSocketAddress, timeout)这种方式而不是默认构造之后调connect不带参数。读超时同样重要。如果不设置setSoTimeout客户端在一条空闲连接上会一直挂在read()方法里这时候服务端悄悄断开、网络层又没触发RST客户端根本感知不到还傻乎乎地以为连接健康。我一般会给读循环设置10秒左右的soTimeout一旦读超时抛出SocketTimeoutException就当作一次异常连接处理主动进入重连流程。3.2 为什么选择长连接而不是每次都新建这个项目的服务器是典型的长连接协议场景每次连接建立时客户端要发登录帧、服务器要下发配置如果每个业务请求都重建TCP连接光握手开销就吃掉一大半时间而且服务器端状态都没法维持。所以必须选择长连接但长连接换来的是更复杂的心跳和保活逻辑。连接建立之后客户端不能只是等在那里要主动证明自己和Server还活着。3.3 应用层心跳比TCP KeepAlive可靠很多人会问Socket不是自带setKeepAlive(true)吗是的但TCP层的KeepAlive默认探测间隔是两小时而且这个参数在Android上没法直接改等它发现连接死了业务早就超时了。所以我必须在应用层做心跳客户端每隔30秒根据服务器要求调整发送一个type0x01的空载荷心跳帧服务端收到后回一个心跳响应。客户端记录最后一次收到任意帧的时间如果超过某个阈值比如90秒没有任何数据进来就主动判定连接死亡关闭Socket并触发重连。心跳间隔的选择有个权衡太短会浪费带宽和电量太长会导致断线发现慢。业内常用30秒心跳、3个周期超时的组合。注意心跳帧也要被业务回调过滤掉不要把它当成业务数据抛给上层。3.4 断线重连必须用指数退避重连逻辑如果写得太粗暴每次断开后立刻重连服务器一旦抖动几十个客户端会同时疯狂重连形成雪崩。我实现的策略是指数退避第一次失败等1秒第二次等2秒第三次等4秒依此类推最大退避间隔60秒封顶。一旦重连成功退避计数器归零。这样既保证了恢复速度又不会给服务器增加过大压力。public class ExponentialBackoff { private static final long BASE_DELAY_MS 1000; private static final long MAX_DELAY_MS 60_000; private int attempt 0; public long nextDelay() { long delay Math.min(BASE_DELAY_MS * (1L attempt), MAX_DELAY_MS); if (attempt 30) attempt; return delay; } public void reset() { attempt 0; } }重连的过程还要考虑一件事重连成功之后很多业务协议要求客户端重新发送登录帧或订阅帧。所以我的连接状态监听器里有一个onConnected回调重连器监听这个回调后在workHandler里重新post一个登录任务。这些状态流转最好用一个枚举记录下来DISCONNECTED、CONNECTING、CONNECTED、RECONNECTING。每个状态的转换都打日志排查问题时一眼就能看出客户端当时在哪个环节卡住了。3.5 关闭连接时别让异常堆栈满天飞主动关闭连接的动作也容易踩坑。正确顺序是先把状态标志位connected置false再在try里关闭InputStream和Socket。因为一旦先关闭Socket正在阻塞的read会抛出SocketException如果你没在finally里做保护很容易在非UI线程打出一堆无意义的异常日志。我的做法是关闭操作单独封装吞掉所有已知的SocketException只在debug模式下打印。这个细节虽然小但能让错误日志干净很多真正的问题一眼就能被找到。4. UI线程与网络线程的协作不ANR、不泄漏、不丢数据4.1 线程模型一个工作线程到底够不够Android的主线程不能做网络I/O这是铁律。我的方案是使用一个HandlerThread作为网络工作线程连接、读循环、心跳、重连都通过它的Handler串行执行。之所以串行是为了避免并发问题——网络层的共享状态比如当前Socket对象、重连状态如果被多个线程同时访问就得加一堆锁说明白状态流转关系而用单线程串行状态自然就是线程安全的逻辑简单很多。读循环在这里有个同步细节read操作是阻塞的它就挂在工作线程上不会阻塞主线程。发送的时候比如UI上用户按了一个按钮要发指令发送方法是调用workHandler.post一个任务把要发送的Frame对象编码后通过当前Socket写出去。这样所有Socket操作都在同一个线程内不会出现两个线程同时写导致字节交错的问题。4.2 回调全部投递到主线程网络层跑在工作线程但UI操作必须回到主线程。这个桥接很关键我设计了一个Listener接口public interface TcpClientListener { void onConnected(); void onDisconnected(); void onFrameReceived(Frame frame); void onError(Throwable t); }网络层内部持有主线程的Handler在工作线程里拿到结果之后通过mainHandler.post(() - listener.onConnected())切回主线程再回调。这样上层实现Listener时可以直接安心更新UI不用自己再切线程。同时这也能避免一个常见错误——在read循环里直接调用业务回调如果业务回调里有耗时操作会阻塞读循环导致后续数据接收延迟。主线程回调之后如果业务层想继续做耗时处理它自己再开线程不关网络层的事。4.3 Activity生命周期绑定和内存泄漏防护网络层生命周期比Activity长如果Activity直接实现Listener接口作为一个内部类传进去Activity销毁后网络层还持有它的引用内存泄漏就发生了。处理方式是在Activity或Fragment的onDestroy或onStop里显式调用client.setListener(null)并且根据业务决定是否client.stop()。还有一点容易被忽视如果Listener是匿名内部类并且直接new给client那么client持有ListenerListener持有Activity同样泄漏。所以我建议用宿主对象模式——把Listener实现在一个不依赖Activity的ViewModel或独立管理类里再通过LiveData或者简单回调把UI事件抛给Activity监听。这样即使Activity重建网络层也不需要跟着重建连接还能保持住数据不丢。4.4 需要后台保活时用前台服务如果业务要求App退到后台TCP连接还得继续活着那网络层就不能只挂在Activity里必须放到一个Service中。Android 8.0以后后台Service很容易被系统限制常规做法是startForegroundService并启动前台通知靠通知常驻来稳定连接。具体通知渠道、通知文案要按业务来但有一点必须注意前台服务不是免死金牌Doze模式下网络照样可能被冻结所以Service里依然要保留心跳和断线重连的能力不能假设系统不会杀进程。5. Android版本差异与实测中值得记住的坑5.1 INTERNET权限与明文流量开关Android TCP客户端首先要加android.permission.INTERNET权限这个老生常谈但很多人会忽略Android 9API 28开始默认禁止明文流量。如果你连接的是局域网IP比如192.168.1.100:8080而且服务器端不是TLS那么targetSdk 28以上的应用会直接抛出Cleartext HTTP traffic to 192.168.1.100 not permitted异常连接建立失败。解决办法有两种一种是在AndroidManifest.xml的application标签上加android:usesCleartextTraffictrue简单粗暴但对整个App放开明文安全上不够严谨更推荐的是用Network Security Config只对特定域名或IP段放开明文。如果你对接的是硬件设备IP往往是动态的那就只能在config里用base-config cleartextTrafficPermittedtrue并配合debug-overrides只在调试包放开。这个配置我记得很清楚因为它曾经让我在写demo阶段浪费了整整一下午去排查为什么真机连不上、模拟器却正常的奇怪问题。5.2 Doze模式让心跳变成了不靠谱的心跳Android 6.0之后引入了Doze模式设备长期静止且未充电时系统会暂停网络访问导致应用层心跳发送失败、连接看似断掉。等用户重新点亮屏幕网络恢复心跳任务又会一次性积压执行。处理这个问题有几个方向心跳任务尽量用AlarmManager或者WorkManager来驱动而不是纯依赖Handler.postDelayed优先级高的场景可以申请忽略电池优化白名单但审核和应用商店政策会有限制不能滥用。更务实的做法是客户端在onResume时主动检查连接状态发现断了立刻重连而不是傻等心跳。5.3 用本地Mock Server复现三类故障TCP客户端的调试不能只靠连真机服务器必须搭一个本地Mock Server来主动控制故障场景。我自己的测试环境是电脑上跑一个Python脚本监听固定端口模拟正常收发、断开、延迟三种行为。需要复现半包时就让服务端分两次发送同一帧数据中间sleep 100毫秒需要复现粘包时就把两帧拼在一次write里发需要复现断线时直接关闭服务端。故障场景模拟方式客户端应表现半包服务端分两次write同一帧解码后正常收到完整帧粘包服务端一次write两帧解码后收到两帧连接被重置服务端直接close30秒内感知进入重连服务器不响应只监听不回复心跳超时触发重连这套Mock Server帮我揪出了两个真实问题一个是FrameCodec的缓冲没有清空残留数据二是重连成功后的登录帧没有被重新发送。如果没有可控的故障注入这两个问题在真机上可能要等一两天才会自然暴露一次排查成本极高。5.4 其他实测中容易忽略的细节模拟器网络模式与真机差异很大。模拟器默认走NAT访问局域网服务器通常没问题但延迟和丢包行为和真实Wi-Fi完全不同所以一定要在真机上跑长时间连接测试。另外Android设备切换Wi-Fi时旧连接的Socket会直接失效但读循环不会立刻报错而是等到soTimeout才暴露。如果业务对网络切换敏感建议监听ConnectivityManager的网络回调在切换时主动断开旧连接立刻走重连流程。IPv6也是一个隐性问题。部分路由器会下发IPv6地址如果你的服务器只监听IPv4而代码里解析域名得到的是IPv6地址connect就会超时。稳妥做法是connect时遍历InetAddress.getAllByName的结果优先尝试IPv4失败再尝试IPv6。最后再提醒一个操作习惯给每个Socket连接打日志时带上本地端口和服务端地址。排查问题时本地端口让你能结合抓包工具快速定位是哪一条连接否则线上日志一多连接对象之间完全分不清谁是谁。我个人体会是TCP客户端这个项目写代码的时间大概只占三分之一剩下三分之二都在反反复复测试各种连接断开后能否正确恢复的场景。把状态机理顺、把重连策略做稳、把粘包半包处理干净这个小模块就真的能让人省心了。本文还有配套的精品资源点击获取 Android TCP客户端从Demo到工程级：帧设计、心跳与断线重连实践
简介一份面向Android开发者的TCP客户端实现资源围绕Socket通信、线程管理与异常处理等关键点演示如何在Android设备上创建TCP客户端并与远程服务器进行双向数据交换。项目包含完整的Eclipse工程源码压缩包共49个文件以java源码、class字节码、xml配置和png图片为主同时附带有可直接安装的apk及dex文件便于对照源码直接运行验证通信效果整体体积仅436KB。已有1057人学习浏览适合初学Android网络编程、正在做毕业设计或需要在应用中快速集成TCP通信模块的开发者。从中可获取TCPClient类完整实现、Socket初始化与数据收发代码、子线程中处理网络耗时操作的方法以及通过Handler或接口回调更新UI的典型写法。项目是一个紧凑实用的入门参考可帮助快速掌握Android端可靠数据传输流程。 做Android的TCP客户端项目很多人一开始都以为很简单——new一个Socket、传个地址端口、write几个字节Demo就跑通了。但真正把它放进一个要长期运行、会被系统回收、还得在弱网环境里保持连接的App里你很快就会发现问题从来不是怎么连上而是连上之后怎么稳定地活着。这篇文章把我在实现Android TCP_Client过程中踩过的坑和最终沉淀下来的方案整理出来核心覆盖协议帧设计、连接管理、线程协作和Android版本差异适配适合刚接触Socket的Android开发者也适合手头有demo级客户端、想改成工程级模块的朋友参考。1. 先搞清楚TCP客户端项目的真实工作边界1.1 它不是能连上而是持续稳定地连上大多数Android TCP_Client项目业务背景都很相似手机连接局域网里的硬件设备比如串口服务器、PLC、智能网关或者对接服务端自定义的二进制协议。这些场景基本都不是发一条消息、收一条回复的HTTP式交互而是要建立一条长期存活的数据通道。这个长期存活四个字才是整个项目的真正工作量所在。一个demo只需要三件事连接、发送、接收。但一个能上线的客户端模块要处理的至少包括连接超时和读超时兜底不能因为一次弱网就永久卡死。服务端随时可能断开客户端要能感知并在几秒内恢复。数据流里出现半包、粘包要能正确拆帧不能把两帧数据混着解析。Activity销毁时不能泄漏Thread或者Handler网络层不能持有UI层引用。App进入后台、系统休眠、Doze模式下连接不能被静默杀掉。这些需求不是附加功能而是TCP客户端的基本盘。如果一开始就把它们放进设计里后面能省掉大量返工时间。1.2 一个可维护的TCP客户端由哪些部分组成我习惯把一个完整的客户端拆成五个部分分工明确互不掺和模块职责关键点连接器建立Socket、设置超时、发起重连超时参数不能写死读循环从InputStream持续读数据并交给解析器阻塞读单独线程帧编解码器处理粘包/半包解析出完整消息帧必须是有状态的累积缓冲心跳与重连维持活跃连接断开后指数退避恢复状态机清晰禁止重连风暴UI回调桥把网络事件安全地抛到主线程不持有Activity强引用每个模块之间通过接口通信。连接器只负责socket生命周期它不知道业务帧长什么样帧编解码器只处理字节流和Frame对象的互相转换不关心这条消息是心跳还是业务数据UI层只实现Listener接口不碰任何网络线程。这样拆开之后测试和排查都非常舒服——哪个环节出问题直接单独看哪个类。1.3 为什么不用现成的网络库会有人问Netty for Android、OkSocket、或者直接用协程加Ktor不是更省事吗我自己的判断是这取决于协议复杂度。如果业务建立在HTTP或者WebSocket上老老实实用OkHttp没必要自己造轮子。但如果服务器协议是私有TCP二进制帧Netty那套pipeline机制在Android上偏重而且很多业务团队对Netty内部状态机并不熟悉出了问题反而更难查。我自己实现一个五六个类的轻量客户端几百行代码所有状态流转都在自己掌控里调试成本低很多。这个取舍不是绝对正确但对于私有TCP协议不需要极致吞吐的业务场景轻量自研的性价比确实更高。接着往下看核心设计你就能理解为什么这些类必须存在。2. 协议帧设计与粘包拆包处理传输层只保证字节流2.1 TCP是流协议消息边界必须自己定义初学者最容易忽略的一件事TCP没有消息的概念它只是把字节按顺序从一端流到另一端。你调用两次send分别发了Hello和World对方可能在一次read里就收到HelloWorld也可能先收到Hel再收到loWorld。这个问题在Android上尤其明显因为Wi-Fi网络下的MTU、TCP窗口、Nagle算法都会影响数据到达的粒度。如果不对数据做帧封装解析端根本不知道一条消息在哪里结束、下一条从哪里开始。常见的解法是固定长度法、分隔符法和长度前缀法。固定长度法适合所有消息等长的极简场景遇到变长数据就是浪费分隔符法比如用\n结尾简单但业务字节流里如果本身包含分隔符需要转义反而容易出bug我最推荐长度前缀法每个包固定格式用头部的长度字段告诉解析端这条消息有多大。2.2 设计一个够用的二进制帧项目里我采用的帧结构如下大端字节序字段偏移长度说明魔数02固定0x5A 0xA5用于快速校验和同步版本21协议版本号当前0x01类型310x01心跳0x02业务0x03登录可自行扩展长度44载荷payload的字节数不含头部载荷8N消息正文魔数的作用是容错和同步。如果网络流里意外混入了脏数据解析端可以通过魔数找回正确的帧边界不至于全盘错乱。版本号是为了以后协议升级留的口子不用一升级就把整个解析逻辑推翻。长度字段占用4字节理论上支持最大2GB的payload——实际使用中根本到不了这么大一般会设一个上限比如64KB防止异常包把内存撑爆。对应的Frame对象也很简单字段就是version、type、payload外加一个encode方法把对象转成字节数组。这里有个容易踩的坑编码的时候一定要用DataOutputStream或者手动做位移不要依赖String.getBytes()后直接System.arraycopy因为不同编码下字符串字节长度不一样容易造成长度字段和实际内容不一致。2.3 半包和粘包的解析代码解析端需要维护一个累积缓冲因为一次read读到的数据可能是半帧、一帧整的、也可能是多帧。核心逻辑是先把新数据追加进缓冲然后循环尝试从缓冲头部解析帧能解析出完整帧就消费掉解析不到完整帧就保留剩余字节等下一次read。public class FrameCodec { private static final int HEADER_LENGTH 8; private static final int MAX_PAYLOAD 64 * 1024; private final ByteArrayOutputStream buffer new ByteArrayOutputStream(); public ListFrame decode(byte[] data) throws IOException { ListFrame frames new ArrayList(); buffer.write(data); byte[] buf buffer.toByteArray(); int offset 0; while (true) { // 剩余字节不够一个头等待下次数据 if (buf.length - offset HEADER_LENGTH) { break; } // 魔数不匹配逐字节向后滑动找同步点 if (buf[offset] ! (byte) 0x5A || buf[offset 1] ! (byte) 0xA5) { offset; continue; } int payloadLength ((buf[offset 4] 0xFF) 24) | ((buf[offset 5] 0xFF) 16) | ((buf[offset 6] 0xFF) 8) | (buf[offset 7] 0xFF); if (payloadLength 0 || payloadLength MAX_PAYLOAD) { throw new IOException(invalid payload length: payloadLength); } int totalLength HEADER_LENGTH payloadLength; // 数据不够一帧等待后半包 if (buf.length - offset totalLength) { break; } byte[] payload Arrays.copyOfRange(buf, offset HEADER_LENGTH, offset totalLength); frames.add(new Frame(buf[offset 2], buf[offset 3], payload)); offset totalLength; } // 把已消费的字节移除保留剩余的半包字节 if (offset 0) { byte[] remaining Arrays.copyOfRange(buf, offset, buf.length); buffer.reset(); buffer.write(remaining); } return frames; } }这段代码有两个细节值得说。第一所有字节组合都要用 0xFF处理因为Java的byte是有符号的直接移位会导致负数和符号扩展解析出的长度完全是错的。第二半包场景下buffer里保留的是上次未消费完的字节如果每次read都触发新的ArrayCopy会有性能开销但Android手机处理这种量级的数据完全够用不必过度优化。3. 连接管理从Connect到断线重连的完整机制3.1 connect超时和读超时必须显式设置Socket默认的connect行为是无限期阻塞的如果目标IP不可达主线程会一直卡住直接导致ANR。所以创建Socket后一定要用Socket.connect(InetSocketAddress, timeout)这种方式而不是默认构造之后调connect不带参数。读超时同样重要。如果不设置setSoTimeout客户端在一条空闲连接上会一直挂在read()方法里这时候服务端悄悄断开、网络层又没触发RST客户端根本感知不到还傻乎乎地以为连接健康。我一般会给读循环设置10秒左右的soTimeout一旦读超时抛出SocketTimeoutException就当作一次异常连接处理主动进入重连流程。3.2 为什么选择长连接而不是每次都新建这个项目的服务器是典型的长连接协议场景每次连接建立时客户端要发登录帧、服务器要下发配置如果每个业务请求都重建TCP连接光握手开销就吃掉一大半时间而且服务器端状态都没法维持。所以必须选择长连接但长连接换来的是更复杂的心跳和保活逻辑。连接建立之后客户端不能只是等在那里要主动证明自己和Server还活着。3.3 应用层心跳比TCP KeepAlive可靠很多人会问Socket不是自带setKeepAlive(true)吗是的但TCP层的KeepAlive默认探测间隔是两小时而且这个参数在Android上没法直接改等它发现连接死了业务早就超时了。所以我必须在应用层做心跳客户端每隔30秒根据服务器要求调整发送一个type0x01的空载荷心跳帧服务端收到后回一个心跳响应。客户端记录最后一次收到任意帧的时间如果超过某个阈值比如90秒没有任何数据进来就主动判定连接死亡关闭Socket并触发重连。心跳间隔的选择有个权衡太短会浪费带宽和电量太长会导致断线发现慢。业内常用30秒心跳、3个周期超时的组合。注意心跳帧也要被业务回调过滤掉不要把它当成业务数据抛给上层。3.4 断线重连必须用指数退避重连逻辑如果写得太粗暴每次断开后立刻重连服务器一旦抖动几十个客户端会同时疯狂重连形成雪崩。我实现的策略是指数退避第一次失败等1秒第二次等2秒第三次等4秒依此类推最大退避间隔60秒封顶。一旦重连成功退避计数器归零。这样既保证了恢复速度又不会给服务器增加过大压力。public class ExponentialBackoff { private static final long BASE_DELAY_MS 1000; private static final long MAX_DELAY_MS 60_000; private int attempt 0; public long nextDelay() { long delay Math.min(BASE_DELAY_MS * (1L attempt), MAX_DELAY_MS); if (attempt 30) attempt; return delay; } public void reset() { attempt 0; } }重连的过程还要考虑一件事重连成功之后很多业务协议要求客户端重新发送登录帧或订阅帧。所以我的连接状态监听器里有一个onConnected回调重连器监听这个回调后在workHandler里重新post一个登录任务。这些状态流转最好用一个枚举记录下来DISCONNECTED、CONNECTING、CONNECTED、RECONNECTING。每个状态的转换都打日志排查问题时一眼就能看出客户端当时在哪个环节卡住了。3.5 关闭连接时别让异常堆栈满天飞主动关闭连接的动作也容易踩坑。正确顺序是先把状态标志位connected置false再在try里关闭InputStream和Socket。因为一旦先关闭Socket正在阻塞的read会抛出SocketException如果你没在finally里做保护很容易在非UI线程打出一堆无意义的异常日志。我的做法是关闭操作单独封装吞掉所有已知的SocketException只在debug模式下打印。这个细节虽然小但能让错误日志干净很多真正的问题一眼就能被找到。4. UI线程与网络线程的协作不ANR、不泄漏、不丢数据4.1 线程模型一个工作线程到底够不够Android的主线程不能做网络I/O这是铁律。我的方案是使用一个HandlerThread作为网络工作线程连接、读循环、心跳、重连都通过它的Handler串行执行。之所以串行是为了避免并发问题——网络层的共享状态比如当前Socket对象、重连状态如果被多个线程同时访问就得加一堆锁说明白状态流转关系而用单线程串行状态自然就是线程安全的逻辑简单很多。读循环在这里有个同步细节read操作是阻塞的它就挂在工作线程上不会阻塞主线程。发送的时候比如UI上用户按了一个按钮要发指令发送方法是调用workHandler.post一个任务把要发送的Frame对象编码后通过当前Socket写出去。这样所有Socket操作都在同一个线程内不会出现两个线程同时写导致字节交错的问题。4.2 回调全部投递到主线程网络层跑在工作线程但UI操作必须回到主线程。这个桥接很关键我设计了一个Listener接口public interface TcpClientListener { void onConnected(); void onDisconnected(); void onFrameReceived(Frame frame); void onError(Throwable t); }网络层内部持有主线程的Handler在工作线程里拿到结果之后通过mainHandler.post(() - listener.onConnected())切回主线程再回调。这样上层实现Listener时可以直接安心更新UI不用自己再切线程。同时这也能避免一个常见错误——在read循环里直接调用业务回调如果业务回调里有耗时操作会阻塞读循环导致后续数据接收延迟。主线程回调之后如果业务层想继续做耗时处理它自己再开线程不关网络层的事。4.3 Activity生命周期绑定和内存泄漏防护网络层生命周期比Activity长如果Activity直接实现Listener接口作为一个内部类传进去Activity销毁后网络层还持有它的引用内存泄漏就发生了。处理方式是在Activity或Fragment的onDestroy或onStop里显式调用client.setListener(null)并且根据业务决定是否client.stop()。还有一点容易被忽视如果Listener是匿名内部类并且直接new给client那么client持有ListenerListener持有Activity同样泄漏。所以我建议用宿主对象模式——把Listener实现在一个不依赖Activity的ViewModel或独立管理类里再通过LiveData或者简单回调把UI事件抛给Activity监听。这样即使Activity重建网络层也不需要跟着重建连接还能保持住数据不丢。4.4 需要后台保活时用前台服务如果业务要求App退到后台TCP连接还得继续活着那网络层就不能只挂在Activity里必须放到一个Service中。Android 8.0以后后台Service很容易被系统限制常规做法是startForegroundService并启动前台通知靠通知常驻来稳定连接。具体通知渠道、通知文案要按业务来但有一点必须注意前台服务不是免死金牌Doze模式下网络照样可能被冻结所以Service里依然要保留心跳和断线重连的能力不能假设系统不会杀进程。5. Android版本差异与实测中值得记住的坑5.1 INTERNET权限与明文流量开关Android TCP客户端首先要加android.permission.INTERNET权限这个老生常谈但很多人会忽略Android 9API 28开始默认禁止明文流量。如果你连接的是局域网IP比如192.168.1.100:8080而且服务器端不是TLS那么targetSdk 28以上的应用会直接抛出Cleartext HTTP traffic to 192.168.1.100 not permitted异常连接建立失败。解决办法有两种一种是在AndroidManifest.xml的application标签上加android:usesCleartextTraffictrue简单粗暴但对整个App放开明文安全上不够严谨更推荐的是用Network Security Config只对特定域名或IP段放开明文。如果你对接的是硬件设备IP往往是动态的那就只能在config里用base-config cleartextTrafficPermittedtrue并配合debug-overrides只在调试包放开。这个配置我记得很清楚因为它曾经让我在写demo阶段浪费了整整一下午去排查为什么真机连不上、模拟器却正常的奇怪问题。5.2 Doze模式让心跳变成了不靠谱的心跳Android 6.0之后引入了Doze模式设备长期静止且未充电时系统会暂停网络访问导致应用层心跳发送失败、连接看似断掉。等用户重新点亮屏幕网络恢复心跳任务又会一次性积压执行。处理这个问题有几个方向心跳任务尽量用AlarmManager或者WorkManager来驱动而不是纯依赖Handler.postDelayed优先级高的场景可以申请忽略电池优化白名单但审核和应用商店政策会有限制不能滥用。更务实的做法是客户端在onResume时主动检查连接状态发现断了立刻重连而不是傻等心跳。5.3 用本地Mock Server复现三类故障TCP客户端的调试不能只靠连真机服务器必须搭一个本地Mock Server来主动控制故障场景。我自己的测试环境是电脑上跑一个Python脚本监听固定端口模拟正常收发、断开、延迟三种行为。需要复现半包时就让服务端分两次发送同一帧数据中间sleep 100毫秒需要复现粘包时就把两帧拼在一次write里发需要复现断线时直接关闭服务端。故障场景模拟方式客户端应表现半包服务端分两次write同一帧解码后正常收到完整帧粘包服务端一次write两帧解码后收到两帧连接被重置服务端直接close30秒内感知进入重连服务器不响应只监听不回复心跳超时触发重连这套Mock Server帮我揪出了两个真实问题一个是FrameCodec的缓冲没有清空残留数据二是重连成功后的登录帧没有被重新发送。如果没有可控的故障注入这两个问题在真机上可能要等一两天才会自然暴露一次排查成本极高。5.4 其他实测中容易忽略的细节模拟器网络模式与真机差异很大。模拟器默认走NAT访问局域网服务器通常没问题但延迟和丢包行为和真实Wi-Fi完全不同所以一定要在真机上跑长时间连接测试。另外Android设备切换Wi-Fi时旧连接的Socket会直接失效但读循环不会立刻报错而是等到soTimeout才暴露。如果业务对网络切换敏感建议监听ConnectivityManager的网络回调在切换时主动断开旧连接立刻走重连流程。IPv6也是一个隐性问题。部分路由器会下发IPv6地址如果你的服务器只监听IPv4而代码里解析域名得到的是IPv6地址connect就会超时。稳妥做法是connect时遍历InetAddress.getAllByName的结果优先尝试IPv4失败再尝试IPv6。最后再提醒一个操作习惯给每个Socket连接打日志时带上本地端口和服务端地址。排查问题时本地端口让你能结合抓包工具快速定位是哪一条连接否则线上日志一多连接对象之间完全分不清谁是谁。我个人体会是TCP客户端这个项目写代码的时间大概只占三分之一剩下三分之二都在反反复复测试各种连接断开后能否正确恢复的场景。把状态机理顺、把重连策略做稳、把粘包半包处理干净这个小模块就真的能让人省心了。本文还有配套的精品资源点击获取