android sdk 未开放原生 websocket api，应用层必须使用 okhttp 或 java-websocket 等第三方库；okhttp 集成度高、省电稳定，java-websocket 在后台保活更可控；需注意 cleartexttraffic 配置、网络切换延迟及二进制帧缓冲复用问题。
Android 原生 WebSocket API（即 android.net.http.WebSocket）在 Android 9（API 28）才正式引入，且仅限系统 WebView 内部使用；**Android SDK 并未向应用层开放原生 WebSocket 类**。所谓“原生实现”，实际是开发者误用术语，真正可用的仍是第三方库封装——OkHttp、Java-WebSocket 或 AndroidAsync。
为什么不能直接 new WebSocket()？
你找不到 android.net.http.WebSocket 的 public 构造函数，它被标记为 @SystemApi 和 @hide，仅供系统进程（如 WebViewService）调用。尝试反射或强制访问会导致 IllegalAccessError 或运行时崩溃，尤其在 Android 10+ 上受 SELinux 严格限制。
- Android Studio 中输入
WebSocket不会提示自动补全应用层类 -
adb shell cmd package resolve-activity -a android.intent.action.VIEW ws://也查不到对应组件 - 官方文档中
android.net.http包下无公开 API 列表
OkHttp 是当前最稳妥的“伪原生”方案
OkHttp 的 WebSocket 实现深度集成进其连接池与事件循环，复用 DNS、TLS、连接复用等能力，比独立 WebSocket 库更省电、更稳定。它不是“额外依赖”，而是多数 Android 项目已有的网络栈一部分。
远程控制 Android 设备，支持截图、自动化操作手机 App 等功能。本应用使用 uiautomator2 作为底层框架，通过 ADB 连接设备，用户无需 Root（1）查看手机屏幕；（2）自动化操作手机 App；（3）远程安装/卸载应用……
-
OkHttpClient.Builder().pingInterval(45, TimeUnit.SECONDS)可控心跳，避免运营商 NAT 超时断连 -
WebSocketListener的onFailure()回调中能拿到Response，可区分是握手失败（HTTP 401/403）还是网络中断 - 不依赖
android.permission.ACCESS_NETWORK_STATE即可感知连接状态变化
Java-WebSocket 在后台保活场景更可控
当你的 App 需要在 Android 8+ 后台持续维持连接（如语音通话后台服务），OkHttp 的线程模型可能被系统休眠策略干扰；而 Java-WebSocket 使用 Thread + Selector 自主轮询，配合 startForegroundService() 和前台通知，存活率更高。
- 必须显式调用
connectBlocking()或connect()，不依赖 OkHttp 的 Dispatcher - 所有回调（
onOpen、onMessage）都在你指定的线程执行，UI 更新需手动切回主线程 - 断连后重连需自行管理重试次数和退避间隔，
Draft_6455是唯一推荐协议版本，其他草案（如Draft_17）在 Android 上握手失败率超 30%
容易被忽略的三个硬伤
无论选哪个库，以下三点不处理，上线后必出问题：
- Android 12+ 强制要求
cleartextTraffic显式设为true才允许ws://（非加密），但生产环境必须用wss://，否则会被 Google Play 拒绝 - WiFi 切 4G 时，
onClose()可能延迟 8–12 秒才触发，需结合ConnectivityManager.NetworkCallback监听网络切换提前降级 - 收到二进制帧（
onMessage(WebSocket, byte[])）后，若未及时clone()或拷贝数据，OkHttp 可能复用该byte[]缓冲区，导致后续读取错乱
