蓝牙Socket连接未关闭致重连失败，求正确关闭时机建议

嘿，你猜得没错，问题根源就是没及时释放Socket资源！当你把应用从后台抽屉移除时，系统大概率会直接终止应用进程，但如果Socket没被正确关闭，设备端可能还会认为旧连接“活着”，等你重启应用尝试重连时，就会因为设备端的连接残留（比如TCP超时未释放、连接数限制）导致失败。下面给你梳理清楚该在什么时候关，以及怎么优化多Activity共享Socket的逻辑：

要覆盖应用生命周期的关键节点，确保无论正常退出还是被系统杀死，都能稳妥关闭Socket：

• 别依赖Application的onTerminate()：这个方法只有在应用正常退出时才会被调用，系统强制杀死进程时根本不会触发，只能当补充手段。
• 用全局Activity生命周期监听：这是最靠谱的方式——在自定义Application里注册ActivityLifecycleCallbacks，维护一个活跃Activity的计数：
  • 每启动一个Activity，计数+1；每销毁一个Activity，计数-1
  • 当计数降到0（意味着所有Activity都销毁，应用要退到后台或被杀死），就调用Socket的关闭逻辑
• 避免在单个Activity的onDestroy()重复关闭：如果多个Activity都持有Socket引用，直接在每个onDestroy()关会导致重复关闭报错。必须让Socket由单例类统一管理，只有全局无活跃页面时才关闭。

既然要跨页面用Socket，别让每个Activity直接持有Socket实例，搞个单例管理类更省心：

• 创建单例SocketManager：封装连接、断开、发送数据、重连的所有逻辑，确保整个应用只有一个Socket实例
• 内置重连机制：当Socket因为异常断开（比如IOException、网络波动），自动触发重连；同时对外提供手动重连的方法，方便重启应用时调用
• 绑定全局生命周期：把SocketManager和Application的生命周期绑定，用上面说的Activity计数来控制Socket的存活

关闭时要按顺序来，避免资源泄漏：

// 先关输出流
if (outputStream != null) {
    try {
        outputStream.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}
// 再关输入流
if (inputStream != null) {
    try {
        inputStream.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}
// 最后关闭Socket
if (socket != null && !socket.isClosed()) {
    try {
        socket.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

设备端一般会维护TCP连接列表，当应用被杀死但Socket没正常关闭时，设备端需要等待TCP的超时时间（通常几分钟）才会释放这个连接。在这段时间内，如果你用同一个本地端口，或者设备端的连接数已经满了，新的连接请求就会被拒绝。及时关闭Socket能让设备端立刻知道连接断开，从根源解决重连问题。

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