已在子线程运行仍抛出android.os.NetworkOnMainThreadException？TCP连接问题

嘿，我来帮你拆解下这两个Android Socket开发里的典型坑，别慌～

这个异常是Android 3.0+的强制限制——主线程绝对不能碰任何网络操作，但有时候你以为放子线程了，其实悄悄踩了这些坑：

• 不小心把网络操作切回主线程了：比如子线程里用Handler发消息，然后在handleMessage()里做Socket的读写/连接操作？这可是主线程的方法，直接触发异常。
• Socket初始化跑在主线程：比如你在Activity的onCreate()里直接new Socket(host, port)，哪怕后续读写在子线程，初始化阶段的连接操作已经在主线程执行了，照样炸。
• 用了AsyncTask但找错了方法：onPreExecute()和onPostExecute()都是主线程的，只有doInBackground()才是子线程，要是你在前面两个方法里做了网络操作，必出问题。

快速排查+解决： #

• 敲黑板：所有网络相关操作（Socket实例化、connect、read、write）必须100%放在子线程，一点都不能留在主线程。
• 用StrictMode定位问题：在你的Application类的onCreate()里加这段代码，Logcat里会直接给你标红哪个方法在主线程做了网络操作：

StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder()
        .detectAll()
        .penaltyLog()
        .build();
StrictMode.setThreadPolicy(policy);

• 换靠谱的异步方式：比如用普通Thread+Runnable，或者Kotlin的Coroutines、RxJava这类框架，确保网络代码完全脱离主线程。

这个基本和流的处理逻辑脱不了干系，大概率是某一端的发送/读取逻辑有问题：

• 忘了flush输出流：Java的OutputStream.write()会把数据先存在缓冲区，不调用flush()的话，数据可能一直没发出去，导致另一端卡在read()里等消息。不管是客户端还是服务端，发完消息一定要加outputStream.flush()。
• 错误关闭了流：要是你发完消息直接关了OutputStream，那整个Socket都会被关闭，另一端再想发消息就会失败。双向通信时，除非要结束连接，不然别随便关流。
• 读取逻辑有问题：比如用read(byte[])时，直接把整个数组转成字符串，但实际可能只读到了一部分数据，导致后续读取卡住。正确的做法是循环读取，根据返回的长度处理数据：

byte[] buffer = new byte[1024];
int bytesRead;
while ((bytesRead = inputStream.read(buffer)) != -1) {
    String receivedMsg = new String(buffer, 0, bytesRead);
    // 处理收到的消息
}

• 角色互换后代码逻辑不一致：比如你的设备作为客户端时记得flush，但作为服务端时忘了？仔细对比两端的发送代码，确保不管是服务端还是客户端，发送逻辑都是一致的。

排查小技巧： #

在两端的发送/读取代码里加Log，看看消息到底有没有发出去、有没有被接收，很快就能定位到哪一步出问题了。

内容的提问来源于stack exchange，提问作者buzzerbeater27