/tag/华为

我真是受够了厨子，最近手机也坏了，修来修去还是有问题，而且iphone本地化太差了，ai功能鸽了多久了，真是服了。虽然说流畅啥的，但是我感觉现在国产手机流畅度也不差了。 正好了618，干脆想抢点优惠换个手机，网上说同事也说mate90pm提前到9月份发布，有点纠结了，到底是618抢mate80pm优惠入手呢，还是等mate90pm呢 618mate80pm我预期应该6000以内可以吧应该，mate90pm刚出来估计得7999 7 个帖子 - 6 位参与者 阅读完整话题

可以充公交卡 每天1-5 2 个帖子 - 2 位参与者 阅读完整话题

1019730049 QQ 群

那天晚上 11 点，我在火车上 SSH 到服务器查日志。手机浏览器切了个微信回来，tab 被 kill 了，session 断了，查了一半的日志全没了。 我翻了翻手机上所有终端 app——Termius 、Blink Shell 、ServerCat——它们都有同一个问题：你不能真的"保持连接"。系统杀后台、网络切换、锁屏省电，随便哪个都能把你的 SSH 掐断。 那能不能反过来？让 shell 在远程服务器上一直跑，手机只是个"显示器"——断了就断了，重连回来输出还在。 这就是 Corterm （云枢终端）的出发点： session 不是连接，是状态。 先把架子搭起来 思路很直接： Worker — 装在远程机器上的轻量 agent ，管 PTY 生命周期。你断了连，shell 照跑。 Gateway — 中间层，管认证、路由、session 协调。Worker 和 Client 之间不直接通信。 Client — 纯渲染层。断了重连时，Gateway 把 Worker 上的 scrollback buffer 吐给你，无缝衔接。 Client (Browser/iOS/Android/HarmonyOS) ↕ SignalR Gateway (.NET 10) ↕ SignalR Worker (.NET 10 + PTY) Gateway 和 Worker 用 .NET 10 + SignalR ，Client 端浏览器用 React + xterm.js ，iOS/Android 用 MAUI 。浏览器、手机 App 都跑通了，接下来是鸿蒙。 手搓 SignalR：1091 行 ArkTS 的协议实现 鸿蒙端的第一道坎：SignalR 。 Corterm 的 Gateway 是 .NET 写的，实时通信用的 SignalR 。iOS/Android 那边有官方 SDK ，浏览器更不用说。但鸿蒙……我翻了半天文档，没有。连第三方实现都没有。 两条路：要么在 Gateway 加一层 WebSocket 中间层，要么直接在 ArkTS 里实现 SignalR 协议。前者意味着改服务端，所有客户端都得测。后者意味着我要在一个 TypeScript 的严格子集里，手写一个协议栈。 我选了后者。 Negotiate 握手 SignalR 连接的第一步不是 WebSocket ，而是一个 HTTP POST negotiate 请求。服务端返回一个 connectionToken ，后续 WebSocket 连接必须带上这个 token 。 // HttpConnection.ets private async negotiate(accessToken: string): Promise<string> { const negotiateUrl = `${this.url}/negotiate?negotiateVersion=1`; const httpClient = http.createHttp(); const headers: Record<string, string> = { 'Accept': 'application/json', 'Content-Type': 'application/json', }; if (accessToken.length > 0) { headers['Authorization'] = `Bearer ${accessToken}`; } const response = await httpClient.request(negotiateUrl, { method: http.RequestMethod.POST, header: headers, connectTimeout: 15000, readTimeout: 15000, }); const body = response.result as string; const negotiateResponse = JSON.parse(body) as NegotiateResponse; this.connectionId = negotiateResponse.connectionId ?? ''; return negotiateResponse.connectionToken ?? ''; } 鸿蒙的网络 API 是 @kit.NetworkKit 里的 http.createHttp() 和 webSocket.createWebSocket() ，用法跟 Node.js 的差不多，但所有东西都得显式类型声明。 WebSocket 连接 拿到 token 后，拼 URL ，建 WebSocket： // HttpConnection.ets private async connectWebSocket(accessToken: string): Promise<void> { const wsUrl = this.url .replace('https://', 'wss://') .replace('http://', 'ws://'); let fullUrl = wsUrl; const params: string[] = []; if (this.connectionToken.length > 0) { params.push(`id=${encodeURIComponent(this.connectionToken)}`); } if (accessToken.length > 0) { params.push(`access_token=${encodeURIComponent(accessToken)}`); } if (params.length > 0) { fullUrl += '?' + params.join('&'); } this.ws = webSocket.createWebSocket(); const ws = this.ws; const openPromise = new Promise<void>((resolve, reject) => { ws.on('open', () => resolve()); ws.on('error', (err: Error) => { if (!this.stopRequested) reject(new Error(`WebSocket error: ${err.message}`)); }); }); ws.on('message', (_err: Error, data: string | ArrayBuffer) => { let text: string; if (typeof data === 'string') { text = data; } else { text = buffer.from(data).toString('utf-8'); } if (this.onreceive !== null) { this.onreceive(text); } }); await ws.connect(fullUrl, { header: connectHeaders }); await openPromise; } Hub 协议层 SignalR 不是裸 WebSocket 。它有自己的消息格式——我打开 C# 源码看了下，其实就 5 种消息类型： Type 1 — InvocationMessage （双向 RPC 调用） Type 2 — StreamItemMessage （流式结果） Type 3 — CompletionMessage （ RPC 响应） Type 6 — Ping （心跳） Type 7 — Close （关闭） 消息之间用 0x1E （ ASCII record separator ）分隔。 processIncomingData 是整个消息分发管道的入口： // HubConnection.ets private processIncomingData(data: string): void { // 第一条消息是 handshake response if (this.handshakePromise !== null) { this.protocol.decodeHandshakeResponse(data); const promise = this.handshakePromise; this.handshakePromise = null; promise.resolve(); return; } // 常规消息 const messages = this.protocol.decodeMessages(data, this.logger); for (const message of messages) { this.dispatchMessage(message); } } private dispatchMessage(message: HubMessageBase): void { this.resetServerTimeout(); switch (message.type) { case 1: { // Invocation const invocation = message as InvocationMessage; this.invokeHandler(invocation.target, invocation.arguments); break; } case 2: { // StreamItem const pending = this.streamManager.getInvocation(streamItem.invocationId); if (pending !== undefined) pending.resolve(streamItem.item); break; } case 3: { // Completion const pending = this.streamManager.removeInvocation(completion.invocationId); if (pending !== undefined) { if (completion.error.length > 0) pending.reject(new Error(completion.error)); else pending.resolve(completion.result); } break; } case 6: break; // Ping case 7: this.handleCloseMessage(close); break; } } Keepalive 和重连 心跳每 15 秒发一次 Ping ，服务端 30 秒没消息就判定超时： private resetKeepAlive(): void { this.pingTimer = setInterval(() => { const ping = new PingMessage(); const encoded = this.protocol.encodeMessage(ping); this.httpConnection.send(encoded); }, this.keepAliveIntervalInMilliseconds) as number; // 15000ms } private resetServerTimeout(): void { clearTimeout(this.serverTimeoutTimer); this.serverTimeoutTimer = setTimeout(() => { this.httpConnection.stop(new Error('Server timeout')); }, this.serverTimeoutInMilliseconds) as number; // 30000ms } 重连策略是 SignalR 的经典配置 [0, 2000, 5000, 10000, 30000] ——先立即重试，然后 2 秒、5 秒、10 秒、30 秒。但官方 SDK 试完这 5 次就放弃了。我的实现改成了循环重试，延迟数组里的最后一个值（ 30 秒）会一直用下去，最多 15 次之后才真正断开： private scheduleReconnect(): void { if (this.stopRequested) return; const delayIndex = Math.min(this.reconnectAttempt, this.reconnectDelays.length - 1); const delay = this.reconnectDelays[delayIndex]; this.reconnectTimer = setTimeout(() => this.attemptReconnect(), delay) as number; } ArkTS 的那些坑 写 SignalR 客户端最痛的不是协议本身，而是 ArkTS 的限制。它是 TypeScript 的严格子集： 不能用 as const — 只能用 class X { static readonly A = '...' } 不能写无类型对象字面量 — { key: value } 直接报错，必须声明类型 不能用解构赋值 — const [k, v] of Object.entries(obj) 编译不过 throw 只能抛 Error — catch 到的任意值不能直接 throw 每一条都是我在编译报错后才学到的。 在 ArkWeb 里跑 xterm.js 终端渲染的答案很明确：xterm.js 。问题是它跑在浏览器里，而我要在 HarmonyOS 的原生 app 里用它。 HarmonyOS 提供了 ArkWeb （ WebView 组件），有 WebMessagePort 做双向通信。我先试了 javaScriptProxy ，崩溃不断，换成 WebMessagePort 才稳定下来。 核心逻辑：创建一对 MessagePort ，Port 0 发给 HTML 端，Port 1 留在 native 端监听： // XtermWebview.ets private initMessagePort() { this.msgPorts = this.webviewController.createWebMessagePorts(); // Port 1 留在 native 端 this.msgPorts[1].onMessageEvent((result: webview.WebMessage) => { const msg = JSON.parse(result as string) as Record<string, Object>; const type = msg['type'] as string; if (type === 'input') { this.onInput(msg['data'] as string); } else if (type === 'resize') { const cols = msg['cols'] as number; const rows = msg['rows'] as number; this.onResize(cols, rows); } }); // Port 0 发给 HTML 端 this.webviewController.postMessage('__init_port__', [this.msgPorts[0]], '*'); } 输出方向反过来：native 拿到 Worker 的输出，base64 编码后调 runJavaScript 写入 xterm： writeOutput(base64Payload: string) { const escaped = base64Payload.replace(/\\/g, '\\\\').replace(/"/g, '\\"'); this.webviewController.runJavaScript(`writeBase64Output("${escaped}")`); } 为什么用 base64 ？因为终端输出包含二进制数据（ ANSI 转义序列、控制字符），直接当 JSON 字符串传会炸。 整个终端页面的生命周期是一个 9 状态的状态机： Disconnected → Connecting → Replaying → Live → Reconnecting → ... 。重连时 Gateway 先 replay scrollback buffer ，然后切到 Live 模式，用户感觉不到断过。 手机上怎么按 Ctrl+C 终端有了，但我怎么在手机上发 SIGINT ？ 没有键盘的设备用终端，这是所有移动端终端 app 的噩梦。 我的解法是 VirtualKeyBar ——一个水平可滚动的虚拟按键条。关键是 Sticky Modifier ：Ctrl 和 Alt 是 latch 按键，按一下变亮（激活），再按下一个字符键时才发送组合键。 // VirtualKeyBar.ets — LatchButton 组件 @Component struct LatchButton { label: string = '' @Prop latched: boolean = false onToggle: () => void = () => {} build() { Button(this.label) .backgroundColor(this.latched ? $r('app.color.terminal_secondary_container') : $r('app.color.terminal_surface_container_high')) .onClick(() => { clickHaptic(); this.onToggle(); }) } } Ctrl + 字母的映射藏在 handleVirtualKey 里： // TerminalPage.ets private handleVirtualKey(key: string) { if (key.startsWith('Ctrl+')) { const label = key.substring(5); // a-z → 0x01-0x1A const ch = label.toLowerCase().charCodeAt(0); if (ch >= 97 && ch <= 122) { this.sendInput(String.fromCharCode(ch - 96)); } } // Escape sequences const inputMap: Record<string, string> = { 'ArrowUp': '\x1b[A', 'ArrowDown': '\x1b[B', 'ArrowRight': '\x1b[C', 'ArrowLeft': '\x1b[D', }; } 'c'.charCodeAt(0) 是 99 （ 0x63 ），减 96 得 3 ， String.fromCharCode(3) 就是 \x03 ——SIGINT 。一行数学运算解决了所有 Ctrl+字母的映射。 CI/CD 十五连跪 6 月 8 号，我开始写 harmony-release.yml 。 然后接下来的 3 天里，我推了这个文件 15 次。 Pipeline 长这样： Tag push (harmony-v*) → 版本提取 → 签名准备 → hvigor 构建 → AGConnect 认证 → OBS 上传 → 编译轮询 → 提审 踩坑中最惨的几个： AGConnect API 文档是解谜游戏。 /upload-url/for-obs 端点文档只写了入参，没告诉你返回的 header 要原样传给 OBS 的 PUT 请求。我是抓包才搞明白的。 编译状态要轮询。 华为的服务端编译一个 .app 文件要 60 秒以上，API 没有回调，只能 30 秒一次轮询，最多 20 次： - name: Query compile status run: | for i in $(seq 1 20); do SUCCESS_STATUS=$(curl -s ... | jq -r '.pkgStateList[0].successStatus') if [ "$SUCCESS_STATUS" = "0" ]; then echo "Compile successful" exit 0 fi sleep 30 done 自托管 runner 的脏文件。 有一次构建失败，查了半天发现是 /tmp 下残留了上次的 .app 文件，签名步骤拿错了文件。于是加了一行 rm -rf 在 pipeline 开头。 每次看到 GitHub Actions 红叉，我都觉得自己在跟华为的文档玩解谜游戏。 53 天的数字 425 次提交。53 天。1 个人。5 个平台。 其中鸿蒙端： 8645 行 ArkTS 1091 行 手写 SignalR 客户端 9 个 HAR 模块（ 1 entry + 5 feature + 3 common ） 5 月 8 日 第一个鸿蒙 commit → 6 月 11 日 上架华为应用市场 接下来要做的：文件传输、端口转发、多 tab 、命令片段。 如果你也觉得手机上应该有个不中断的终端，来看看： github.com/monster-echo/CortexTerminal2 Docker 一键体验： docker run -d -p 5000:5000 ghcr.io/monster-echo/cortex-terminal:latest

那天晚上 11 点，我在火车上 SSH 到服务器查日志。手机浏览器切了个微信回来，tab 被 kill 了，session 断了，查了一半的日志全没了。 我翻了翻手机上所有终端 app——Termius 、Blink Shell 、ServerCat——它们都有同一个问题：你不能真的"保持连接"。系统杀后台、网络切换、锁屏省电，随便哪个都能把你的 SSH 掐断。 那能不能反过来？让 shell 在远程服务器上一直跑，手机只是个"显示器"——断了就断了，重连回来输出还在。 这就是 Corterm （云枢终端）的出发点： session 不是连接，是状态。 先把架子搭起来 思路很直接： Worker — 装在远程机器上的轻量 agent ，管 PTY 生命周期。你断了连，shell 照跑。 Gateway — 中间层，管认证、路由、session 协调。Worker 和 Client 之间不直接通信。 Client — 纯渲染层。断了重连时，Gateway 把 Worker 上的 scrollback buffer 吐给你，无缝衔接。 Client (Browser/iOS/Android/HarmonyOS) ↕ SignalR Gateway (.NET 10) ↕ SignalR Worker (.NET 10 + PTY) Gateway 和 Worker 用 .NET 10 + SignalR ，Client 端浏览器用 React + xterm.js ，iOS/Android 用 MAUI 。浏览器、手机 App 都跑通了，接下来是鸿蒙。 手搓 SignalR：1091 行 ArkTS 的协议实现 鸿蒙端的第一道坎：SignalR 。 Corterm 的 Gateway 是 .NET 写的，实时通信用的 SignalR 。iOS/Android 那边有官方 SDK ，浏览器更不用说。但鸿蒙……我翻了半天文档，没有。连第三方实现都没有。 两条路：要么在 Gateway 加一层 WebSocket 中间层，要么直接在 ArkTS 里实现 SignalR 协议。前者意味着改服务端，所有客户端都得测。后者意味着我要在一个 TypeScript 的严格子集里，手写一个协议栈。 我选了后者。 Negotiate 握手 SignalR 连接的第一步不是 WebSocket ，而是一个 HTTP POST negotiate 请求。服务端返回一个 connectionToken ，后续 WebSocket 连接必须带上这个 token 。 // HttpConnection.ets private async negotiate(accessToken: string): Promise<string> { const negotiateUrl = `${this.url}/negotiate?negotiateVersion=1`; const httpClient = http.createHttp(); const headers: Record<string, string> = { 'Accept': 'application/json', 'Content-Type': 'application/json', }; if (accessToken.length > 0) { headers['Authorization'] = `Bearer ${accessToken}`; } const response = await httpClient.request(negotiateUrl, { method: http.RequestMethod.POST, header: headers, connectTimeout: 15000, readTimeout: 15000, }); const body = response.result as string; const negotiateResponse = JSON.parse(body) as NegotiateResponse; this.connectionId = negotiateResponse.connectionId ?? ''; return negotiateResponse.connectionToken ?? ''; } 鸿蒙的网络 API 是 @kit.NetworkKit 里的 http.createHttp() 和 webSocket.createWebSocket() ，用法跟 Node.js 的差不多，但所有东西都得显式类型声明。 WebSocket 连接 拿到 token 后，拼 URL ，建 WebSocket： // HttpConnection.ets private async connectWebSocket(accessToken: string): Promise<void> { const wsUrl = this.url .replace('https://', 'wss://') .replace('http://', 'ws://'); let fullUrl = wsUrl; const params: string[] = []; if (this.connectionToken.length > 0) { params.push(`id=${encodeURIComponent(this.connectionToken)}`); } if (accessToken.length > 0) { params.push(`access_token=${encodeURIComponent(accessToken)}`); } if (params.length > 0) { fullUrl += '?' + params.join('&'); } this.ws = webSocket.createWebSocket(); const ws = this.ws; const openPromise = new Promise<void>((resolve, reject) => { ws.on('open', () => resolve()); ws.on('error', (err: Error) => { if (!this.stopRequested) reject(new Error(`WebSocket error: ${err.message}`)); }); }); ws.on('message', (_err: Error, data: string | ArrayBuffer) => { let text: string; if (typeof data === 'string') { text = data; } else { text = buffer.from(data).toString('utf-8'); } if (this.onreceive !== null) { this.onreceive(text); } }); await ws.connect(fullUrl, { header: connectHeaders }); await openPromise; } Hub 协议层 SignalR 不是裸 WebSocket 。它有自己的消息格式——我打开 C# 源码看了下，其实就 5 种消息类型： Type 1 — InvocationMessage （双向 RPC 调用） Type 2 — StreamItemMessage （流式结果） Type 3 — CompletionMessage （ RPC 响应） Type 6 — Ping （心跳） Type 7 — Close （关闭） 消息之间用 0x1E （ ASCII record separator ）分隔。 processIncomingData 是整个消息分发管道的入口： // HubConnection.ets private processIncomingData(data: string): void { // 第一条消息是 handshake response if (this.handshakePromise !== null) { this.protocol.decodeHandshakeResponse(data); const promise = this.handshakePromise; this.handshakePromise = null; promise.resolve(); return; } // 常规消息 const messages = this.protocol.decodeMessages(data, this.logger); for (const message of messages) { this.dispatchMessage(message); } } private dispatchMessage(message: HubMessageBase): void { this.resetServerTimeout(); switch (message.type) { case 1: { // Invocation const invocation = message as InvocationMessage; this.invokeHandler(invocation.target, invocation.arguments); break; } case 2: { // StreamItem const pending = this.streamManager.getInvocation(streamItem.invocationId); if (pending !== undefined) pending.resolve(streamItem.item); break; } case 3: { // Completion const pending = this.streamManager.removeInvocation(completion.invocationId); if (pending !== undefined) { if (completion.error.length > 0) pending.reject(new Error(completion.error)); else pending.resolve(completion.result); } break; } case 6: break; // Ping case 7: this.handleCloseMessage(close); break; } } Keepalive 和重连 心跳每 15 秒发一次 Ping ，服务端 30 秒没消息就判定超时： private resetKeepAlive(): void { this.pingTimer = setInterval(() => { const ping = new PingMessage(); const encoded = this.protocol.encodeMessage(ping); this.httpConnection.send(encoded); }, this.keepAliveIntervalInMilliseconds) as number; // 15000ms } private resetServerTimeout(): void { clearTimeout(this.serverTimeoutTimer); this.serverTimeoutTimer = setTimeout(() => { this.httpConnection.stop(new Error('Server timeout')); }, this.serverTimeoutInMilliseconds) as number; // 30000ms } 重连策略是 SignalR 的经典配置 [0, 2000, 5000, 10000, 30000] ——先立即重试，然后 2 秒、5 秒、10 秒、30 秒。但官方 SDK 试完这 5 次就放弃了。我的实现改成了循环重试，延迟数组里的最后一个值（ 30 秒）会一直用下去，最多 15 次之后才真正断开： private scheduleReconnect(): void { if (this.stopRequested) return; const delayIndex = Math.min(this.reconnectAttempt, this.reconnectDelays.length - 1); const delay = this.reconnectDelays[delayIndex]; this.reconnectTimer = setTimeout(() => this.attemptReconnect(), delay) as number; } ArkTS 的那些坑 写 SignalR 客户端最痛的不是协议本身，而是 ArkTS 的限制。它是 TypeScript 的严格子集： 不能用 as const — 只能用 class X { static readonly A = '...' } 不能写无类型对象字面量 — { key: value } 直接报错，必须声明类型 不能用解构赋值 — const [k, v] of Object.entries(obj) 编译不过 throw 只能抛 Error — catch 到的任意值不能直接 throw 每一条都是我在编译报错后才学到的。 在 ArkWeb 里跑 xterm.js 终端渲染的答案很明确：xterm.js 。问题是它跑在浏览器里，而我要在 HarmonyOS 的原生 app 里用它。 HarmonyOS 提供了 ArkWeb （ WebView 组件），有 WebMessagePort 做双向通信。我先试了 javaScriptProxy ，崩溃不断，换成 WebMessagePort 才稳定下来。 核心逻辑：创建一对 MessagePort ，Port 0 发给 HTML 端，Port 1 留在 native 端监听： // XtermWebview.ets private initMessagePort() { this.msgPorts = this.webviewController.createWebMessagePorts(); // Port 1 留在 native 端 this.msgPorts[1].onMessageEvent((result: webview.WebMessage) => { const msg = JSON.parse(result as string) as Record<string, Object>; const type = msg['type'] as string; if (type === 'input') { this.onInput(msg['data'] as string); } else if (type === 'resize') { const cols = msg['cols'] as number; const rows = msg['rows'] as number; this.onResize(cols, rows); } }); // Port 0 发给 HTML 端 this.webviewController.postMessage('__init_port__', [this.msgPorts[0]], '*'); } 输出方向反过来：native 拿到 Worker 的输出，base64 编码后调 runJavaScript 写入 xterm： writeOutput(base64Payload: string) { const escaped = base64Payload.replace(/\\/g, '\\\\').replace(/"/g, '\\"'); this.webviewController.runJavaScript(`writeBase64Output("${escaped}")`); } 为什么用 base64 ？因为终端输出包含二进制数据（ ANSI 转义序列、控制字符），直接当 JSON 字符串传会炸。 整个终端页面的生命周期是一个 9 状态的状态机： Disconnected → Connecting → Replaying → Live → Reconnecting → ... 。重连时 Gateway 先 replay scrollback buffer ，然后切到 Live 模式，用户感觉不到断过。 手机上怎么按 Ctrl+C 终端有了，但我怎么在手机上发 SIGINT ？ 没有键盘的设备用终端，这是所有移动端终端 app 的噩梦。 我的解法是 VirtualKeyBar ——一个水平可滚动的虚拟按键条。关键是 Sticky Modifier ：Ctrl 和 Alt 是 latch 按键，按一下变亮（激活），再按下一个字符键时才发送组合键。 // VirtualKeyBar.ets — LatchButton 组件 @Component struct LatchButton { label: string = '' @Prop latched: boolean = false onToggle: () => void = () => {} build() { Button(this.label) .backgroundColor(this.latched ? $r('app.color.terminal_secondary_container') : $r('app.color.terminal_surface_container_high')) .onClick(() => { clickHaptic(); this.onToggle(); }) } } Ctrl + 字母的映射藏在 handleVirtualKey 里： // TerminalPage.ets private handleVirtualKey(key: string) { if (key.startsWith('Ctrl+')) { const label = key.substring(5); // a-z → 0x01-0x1A const ch = label.toLowerCase().charCodeAt(0); if (ch >= 97 && ch <= 122) { this.sendInput(String.fromCharCode(ch - 96)); } } // Escape sequences const inputMap: Record<string, string> = { 'ArrowUp': '\x1b[A', 'ArrowDown': '\x1b[B', 'ArrowRight': '\x1b[C', 'ArrowLeft': '\x1b[D', }; } 'c'.charCodeAt(0) 是 99 （ 0x63 ），减 96 得 3 ， String.fromCharCode(3) 就是 \x03 ——SIGINT 。一行数学运算解决了所有 Ctrl+字母的映射。 CI/CD 十五连跪 6 月 8 号，我开始写 harmony-release.yml 。 然后接下来的 3 天里，我推了这个文件 15 次。 Pipeline 长这样： Tag push (harmony-v*) → 版本提取 → 签名准备 → hvigor 构建 → AGConnect 认证 → OBS 上传 → 编译轮询 → 提审 踩坑中最惨的几个： AGConnect API 文档是解谜游戏。 /upload-url/for-obs 端点文档只写了入参，没告诉你返回的 header 要原样传给 OBS 的 PUT 请求。我是抓包才搞明白的。 编译状态要轮询。 华为的服务端编译一个 .app 文件要 60 秒以上，API 没有回调，只能 30 秒一次轮询，最多 20 次： - name: Query compile status run: | for i in $(seq 1 20); do SUCCESS_STATUS=$(curl -s ... | jq -r '.pkgStateList[0].successStatus') if [ "$SUCCESS_STATUS" = "0" ]; then echo "Compile successful" exit 0 fi sleep 30 done 自托管 runner 的脏文件。 有一次构建失败，查了半天发现是 /tmp 下残留了上次的 .app 文件，签名步骤拿错了文件。于是加了一行 rm -rf 在 pipeline 开头。 每次看到 GitHub Actions 红叉，我都觉得自己在跟华为的文档玩解谜游戏。 53 天的数字 425 次提交。53 天。1 个人。5 个平台。 其中鸿蒙端： 8645 行 ArkTS 1091 行 手写 SignalR 客户端 9 个 HAR 模块（ 1 entry + 5 feature + 3 common ） 5 月 8 日 第一个鸿蒙 commit → 6 月 11 日 上架华为应用市场 接下来要做的：文件传输、端口转发、多 tab 、命令片段。 如果你也觉得手机上应该有个不中断的终端，来看看： github.com/monster-echo/CortexTerminal2 Docker 一键体验： docker run -d -p 5000:5000 ghcr.io/monster-echo/cortex-terminal:latest

那天晚上 11 点，我在火车上 SSH 到服务器查日志。手机浏览器切了个微信回来，tab 被 kill 了，session 断了，查了一半的日志全没了。 我翻了翻手机上所有终端 app——Termius 、Blink Shell 、ServerCat——它们都有同一个问题：你不能真的"保持连接"。系统杀后台、网络切换、锁屏省电，随便哪个都能把你的 SSH 掐断。 那能不能反过来？让 shell 在远程服务器上一直跑，手机只是个"显示器"——断了就断了，重连回来输出还在。 这就是 Corterm （云枢终端）的出发点： session 不是连接，是状态。 先把架子搭起来 思路很直接： Worker — 装在远程机器上的轻量 agent ，管 PTY 生命周期。你断了连，shell 照跑。 Gateway — 中间层，管认证、路由、session 协调。Worker 和 Client 之间不直接通信。 Client — 纯渲染层。断了重连时，Gateway 把 Worker 上的 scrollback buffer 吐给你，无缝衔接。 Client (Browser/iOS/Android/HarmonyOS) ↕ SignalR Gateway (.NET 10) ↕ SignalR Worker (.NET 10 + PTY) Gateway 和 Worker 用 .NET 10 + SignalR ，Client 端浏览器用 React + xterm.js ，iOS/Android 用 MAUI 。浏览器、手机 App 都跑通了，接下来是鸿蒙。 手搓 SignalR：1091 行 ArkTS 的协议实现 鸿蒙端的第一道坎：SignalR 。 Corterm 的 Gateway 是 .NET 写的，实时通信用的 SignalR 。iOS/Android 那边有官方 SDK ，浏览器更不用说。但鸿蒙……我翻了半天文档，没有。连第三方实现都没有。 两条路：要么在 Gateway 加一层 WebSocket 中间层，要么直接在 ArkTS 里实现 SignalR 协议。前者意味着改服务端，所有客户端都得测。后者意味着我要在一个 TypeScript 的严格子集里，手写一个协议栈。 我选了后者。 Negotiate 握手 SignalR 连接的第一步不是 WebSocket ，而是一个 HTTP POST negotiate 请求。服务端返回一个 connectionToken ，后续 WebSocket 连接必须带上这个 token 。 // HttpConnection.ets private async negotiate(accessToken: string): Promise<string> { const negotiateUrl = `${this.url}/negotiate?negotiateVersion=1`; const httpClient = http.createHttp(); const headers: Record<string, string> = { 'Accept': 'application/json', 'Content-Type': 'application/json', }; if (accessToken.length > 0) { headers['Authorization'] = `Bearer ${accessToken}`; } const response = await httpClient.request(negotiateUrl, { method: http.RequestMethod.POST, header: headers, connectTimeout: 15000, readTimeout: 15000, }); const body = response.result as string; const negotiateResponse = JSON.parse(body) as NegotiateResponse; this.connectionId = negotiateResponse.connectionId ?? ''; return negotiateResponse.connectionToken ?? ''; } 鸿蒙的网络 API 是 @kit.NetworkKit 里的 http.createHttp() 和 webSocket.createWebSocket() ，用法跟 Node.js 的差不多，但所有东西都得显式类型声明。 WebSocket 连接 拿到 token 后，拼 URL ，建 WebSocket： // HttpConnection.ets private async connectWebSocket(accessToken: string): Promise<void> { const wsUrl = this.url .replace('https://', 'wss://') .replace('http://', 'ws://'); let fullUrl = wsUrl; const params: string[] = []; if (this.connectionToken.length > 0) { params.push(`id=${encodeURIComponent(this.connectionToken)}`); } if (accessToken.length > 0) { params.push(`access_token=${encodeURIComponent(accessToken)}`); } if (params.length > 0) { fullUrl += '?' + params.join('&'); } this.ws = webSocket.createWebSocket(); const ws = this.ws; const openPromise = new Promise<void>((resolve, reject) => { ws.on('open', () => resolve()); ws.on('error', (err: Error) => { if (!this.stopRequested) reject(new Error(`WebSocket error: ${err.message}`)); }); }); ws.on('message', (_err: Error, data: string | ArrayBuffer) => { let text: string; if (typeof data === 'string') { text = data; } else { text = buffer.from(data).toString('utf-8'); } if (this.onreceive !== null) { this.onreceive(text); } }); await ws.connect(fullUrl, { header: connectHeaders }); await openPromise; } Hub 协议层 SignalR 不是裸 WebSocket 。它有自己的消息格式——我打开 C# 源码看了下，其实就 5 种消息类型： Type 1 — InvocationMessage （双向 RPC 调用） Type 2 — StreamItemMessage （流式结果） Type 3 — CompletionMessage （ RPC 响应） Type 6 — Ping （心跳） Type 7 — Close （关闭） 消息之间用 0x1E （ ASCII record separator ）分隔。 processIncomingData 是整个消息分发管道的入口： // HubConnection.ets private processIncomingData(data: string): void { // 第一条消息是 handshake response if (this.handshakePromise !== null) { this.protocol.decodeHandshakeResponse(data); const promise = this.handshakePromise; this.handshakePromise = null; promise.resolve(); return; } // 常规消息 const messages = this.protocol.decodeMessages(data, this.logger); for (const message of messages) { this.dispatchMessage(message); } } private dispatchMessage(message: HubMessageBase): void { this.resetServerTimeout(); switch (message.type) { case 1: { // Invocation const invocation = message as InvocationMessage; this.invokeHandler(invocation.target, invocation.arguments); break; } case 2: { // StreamItem const pending = this.streamManager.getInvocation(streamItem.invocationId); if (pending !== undefined) pending.resolve(streamItem.item); break; } case 3: { // Completion const pending = this.streamManager.removeInvocation(completion.invocationId); if (pending !== undefined) { if (completion.error.length > 0) pending.reject(new Error(completion.error)); else pending.resolve(completion.result); } break; } case 6: break; // Ping case 7: this.handleCloseMessage(close); break; } } Keepalive 和重连 心跳每 15 秒发一次 Ping ，服务端 30 秒没消息就判定超时： private resetKeepAlive(): void { this.pingTimer = setInterval(() => { const ping = new PingMessage(); const encoded = this.protocol.encodeMessage(ping); this.httpConnection.send(encoded); }, this.keepAliveIntervalInMilliseconds) as number; // 15000ms } private resetServerTimeout(): void { clearTimeout(this.serverTimeoutTimer); this.serverTimeoutTimer = setTimeout(() => { this.httpConnection.stop(new Error('Server timeout')); }, this.serverTimeoutInMilliseconds) as number; // 30000ms } 重连策略是 SignalR 的经典配置 [0, 2000, 5000, 10000, 30000] ——先立即重试，然后 2 秒、5 秒、10 秒、30 秒。但官方 SDK 试完这 5 次就放弃了。我的实现改成了循环重试，延迟数组里的最后一个值（ 30 秒）会一直用下去，最多 15 次之后才真正断开： private scheduleReconnect(): void { if (this.stopRequested) return; const delayIndex = Math.min(this.reconnectAttempt, this.reconnectDelays.length - 1); const delay = this.reconnectDelays[delayIndex]; this.reconnectTimer = setTimeout(() => this.attemptReconnect(), delay) as number; } ArkTS 的那些坑 写 SignalR 客户端最痛的不是协议本身，而是 ArkTS 的限制。它是 TypeScript 的严格子集： 不能用 as const — 只能用 class X { static readonly A = '...' } 不能写无类型对象字面量 — { key: value } 直接报错，必须声明类型 不能用解构赋值 — const [k, v] of Object.entries(obj) 编译不过 throw 只能抛 Error — catch 到的任意值不能直接 throw 每一条都是我在编译报错后才学到的。 在 ArkWeb 里跑 xterm.js 终端渲染的答案很明确：xterm.js 。问题是它跑在浏览器里，而我要在 HarmonyOS 的原生 app 里用它。 HarmonyOS 提供了 ArkWeb （ WebView 组件），有 WebMessagePort 做双向通信。我先试了 javaScriptProxy ，崩溃不断，换成 WebMessagePort 才稳定下来。 核心逻辑：创建一对 MessagePort ，Port 0 发给 HTML 端，Port 1 留在 native 端监听： // XtermWebview.ets private initMessagePort() { this.msgPorts = this.webviewController.createWebMessagePorts(); // Port 1 留在 native 端 this.msgPorts[1].onMessageEvent((result: webview.WebMessage) => { const msg = JSON.parse(result as string) as Record<string, Object>; const type = msg['type'] as string; if (type === 'input') { this.onInput(msg['data'] as string); } else if (type === 'resize') { const cols = msg['cols'] as number; const rows = msg['rows'] as number; this.onResize(cols, rows); } }); // Port 0 发给 HTML 端 this.webviewController.postMessage('__init_port__', [this.msgPorts[0]], '*'); } 输出方向反过来：native 拿到 Worker 的输出，base64 编码后调 runJavaScript 写入 xterm： writeOutput(base64Payload: string) { const escaped = base64Payload.replace(/\\/g, '\\\\').replace(/"/g, '\\"'); this.webviewController.runJavaScript(`writeBase64Output("${escaped}")`); } 为什么用 base64 ？因为终端输出包含二进制数据（ ANSI 转义序列、控制字符），直接当 JSON 字符串传会炸。 整个终端页面的生命周期是一个 9 状态的状态机： Disconnected → Connecting → Replaying → Live → Reconnecting → ... 。重连时 Gateway 先 replay scrollback buffer ，然后切到 Live 模式，用户感觉不到断过。 手机上怎么按 Ctrl+C 终端有了，但我怎么在手机上发 SIGINT ？ 没有键盘的设备用终端，这是所有移动端终端 app 的噩梦。 我的解法是 VirtualKeyBar ——一个水平可滚动的虚拟按键条。关键是 Sticky Modifier ：Ctrl 和 Alt 是 latch 按键，按一下变亮（激活），再按下一个字符键时才发送组合键。 // VirtualKeyBar.ets — LatchButton 组件 @Component struct LatchButton { label: string = '' @Prop latched: boolean = false onToggle: () => void = () => {} build() { Button(this.label) .backgroundColor(this.latched ? $r('app.color.terminal_secondary_container') : $r('app.color.terminal_surface_container_high')) .onClick(() => { clickHaptic(); this.onToggle(); }) } } Ctrl + 字母的映射藏在 handleVirtualKey 里： // TerminalPage.ets private handleVirtualKey(key: string) { if (key.startsWith('Ctrl+')) { const label = key.substring(5); // a-z → 0x01-0x1A const ch = label.toLowerCase().charCodeAt(0); if (ch >= 97 && ch <= 122) { this.sendInput(String.fromCharCode(ch - 96)); } } // Escape sequences const inputMap: Record<string, string> = { 'ArrowUp': '\x1b[A', 'ArrowDown': '\x1b[B', 'ArrowRight': '\x1b[C', 'ArrowLeft': '\x1b[D', }; } 'c'.charCodeAt(0) 是 99 （ 0x63 ），减 96 得 3 ， String.fromCharCode(3) 就是 \x03 ——SIGINT 。一行数学运算解决了所有 Ctrl+字母的映射。 CI/CD 十五连跪 6 月 8 号，我开始写 harmony-release.yml 。 然后接下来的 3 天里，我推了这个文件 15 次。 Pipeline 长这样： Tag push (harmony-v*) → 版本提取 → 签名准备 → hvigor 构建 → AGConnect 认证 → OBS 上传 → 编译轮询 → 提审 踩坑中最惨的几个： AGConnect API 文档是解谜游戏。 /upload-url/for-obs 端点文档只写了入参，没告诉你返回的 header 要原样传给 OBS 的 PUT 请求。我是抓包才搞明白的。 编译状态要轮询。 华为的服务端编译一个 .app 文件要 60 秒以上，API 没有回调，只能 30 秒一次轮询，最多 20 次： - name: Query compile status run: | for i in $(seq 1 20); do SUCCESS_STATUS=$(curl -s ... | jq -r '.pkgStateList[0].successStatus') if [ "$SUCCESS_STATUS" = "0" ]; then echo "Compile successful" exit 0 fi sleep 30 done 自托管 runner 的脏文件。 有一次构建失败，查了半天发现是 /tmp 下残留了上次的 .app 文件，签名步骤拿错了文件。于是加了一行 rm -rf 在 pipeline 开头。 每次看到 GitHub Actions 红叉，我都觉得自己在跟华为的文档玩解谜游戏。 53 天的数字 425 次提交。53 天。1 个人。5 个平台。 其中鸿蒙端： 8645 行 ArkTS 1091 行 手写 SignalR 客户端 9 个 HAR 模块（ 1 entry + 5 feature + 3 common ） 5 月 8 日 第一个鸿蒙 commit → 6 月 11 日 上架华为应用市场 接下来要做的：文件传输、端口转发、多 tab 、命令片段。 如果你也觉得手机上应该有个不中断的终端，来看看： github.com/monster-echo/CortexTerminal2 Docker 一键体验： docker run -d -p 5000:5000 ghcr.io/monster-echo/cortex-terminal:latest

那天晚上 11 点，我在火车上 SSH 到服务器查日志。手机浏览器切了个微信回来，tab 被 kill 了，session 断了，查了一半的日志全没了。 我翻了翻手机上所有终端 app——Termius 、Blink Shell 、ServerCat——它们都有同一个问题：你不能真的"保持连接"。系统杀后台、网络切换、锁屏省电，随便哪个都能把你的 SSH 掐断。 那能不能反过来？让 shell 在远程服务器上一直跑，手机只是个"显示器"——断了就断了，重连回来输出还在。 这就是 Corterm （云枢终端）的出发点： session 不是连接，是状态。 先把架子搭起来 思路很直接： Worker — 装在远程机器上的轻量 agent ，管 PTY 生命周期。你断了连，shell 照跑。 Gateway — 中间层，管认证、路由、session 协调。Worker 和 Client 之间不直接通信。 Client — 纯渲染层。断了重连时，Gateway 把 Worker 上的 scrollback buffer 吐给你，无缝衔接。 Client (Browser/iOS/Android/HarmonyOS) ↕ SignalR Gateway (.NET 10) ↕ SignalR Worker (.NET 10 + PTY) Gateway 和 Worker 用 .NET 10 + SignalR ，Client 端浏览器用 React + xterm.js ，iOS/Android 用 MAUI 。浏览器、手机 App 都跑通了，接下来是鸿蒙。 手搓 SignalR：1091 行 ArkTS 的协议实现 鸿蒙端的第一道坎：SignalR 。 Corterm 的 Gateway 是 .NET 写的，实时通信用的 SignalR 。iOS/Android 那边有官方 SDK ，浏览器更不用说。但鸿蒙……我翻了半天文档，没有。连第三方实现都没有。 两条路：要么在 Gateway 加一层 WebSocket 中间层，要么直接在 ArkTS 里实现 SignalR 协议。前者意味着改服务端，所有客户端都得测。后者意味着我要在一个 TypeScript 的严格子集里，手写一个协议栈。 我选了后者。 Negotiate 握手 SignalR 连接的第一步不是 WebSocket ，而是一个 HTTP POST negotiate 请求。服务端返回一个 connectionToken ，后续 WebSocket 连接必须带上这个 token 。 // HttpConnection.ets private async negotiate(accessToken: string): Promise<string> { const negotiateUrl = `${this.url}/negotiate?negotiateVersion=1`; const httpClient = http.createHttp(); const headers: Record<string, string> = { 'Accept': 'application/json', 'Content-Type': 'application/json', }; if (accessToken.length > 0) { headers['Authorization'] = `Bearer ${accessToken}`; } const response = await httpClient.request(negotiateUrl, { method: http.RequestMethod.POST, header: headers, connectTimeout: 15000, readTimeout: 15000, }); const body = response.result as string; const negotiateResponse = JSON.parse(body) as NegotiateResponse; this.connectionId = negotiateResponse.connectionId ?? ''; return negotiateResponse.connectionToken ?? ''; } 鸿蒙的网络 API 是 @kit.NetworkKit 里的 http.createHttp() 和 webSocket.createWebSocket() ，用法跟 Node.js 的差不多，但所有东西都得显式类型声明。 WebSocket 连接 拿到 token 后，拼 URL ，建 WebSocket： // HttpConnection.ets private async connectWebSocket(accessToken: string): Promise<void> { const wsUrl = this.url .replace('https://', 'wss://') .replace('http://', 'ws://'); let fullUrl = wsUrl; const params: string[] = []; if (this.connectionToken.length > 0) { params.push(`id=${encodeURIComponent(this.connectionToken)}`); } if (accessToken.length > 0) { params.push(`access_token=${encodeURIComponent(accessToken)}`); } if (params.length > 0) { fullUrl += '?' + params.join('&'); } this.ws = webSocket.createWebSocket(); const ws = this.ws; const openPromise = new Promise<void>((resolve, reject) => { ws.on('open', () => resolve()); ws.on('error', (err: Error) => { if (!this.stopRequested) reject(new Error(`WebSocket error: ${err.message}`)); }); }); ws.on('message', (_err: Error, data: string | ArrayBuffer) => { let text: string; if (typeof data === 'string') { text = data; } else { text = buffer.from(data).toString('utf-8'); } if (this.onreceive !== null) { this.onreceive(text); } }); await ws.connect(fullUrl, { header: connectHeaders }); await openPromise; } Hub 协议层 SignalR 不是裸 WebSocket 。它有自己的消息格式——我打开 C# 源码看了下，其实就 5 种消息类型： Type 1 — InvocationMessage （双向 RPC 调用） Type 2 — StreamItemMessage （流式结果） Type 3 — CompletionMessage （ RPC 响应） Type 6 — Ping （心跳） Type 7 — Close （关闭） 消息之间用 0x1E （ ASCII record separator ）分隔。 processIncomingData 是整个消息分发管道的入口： // HubConnection.ets private processIncomingData(data: string): void { // 第一条消息是 handshake response if (this.handshakePromise !== null) { this.protocol.decodeHandshakeResponse(data); const promise = this.handshakePromise; this.handshakePromise = null; promise.resolve(); return; } // 常规消息 const messages = this.protocol.decodeMessages(data, this.logger); for (const message of messages) { this.dispatchMessage(message); } } private dispatchMessage(message: HubMessageBase): void { this.resetServerTimeout(); switch (message.type) { case 1: { // Invocation const invocation = message as InvocationMessage; this.invokeHandler(invocation.target, invocation.arguments); break; } case 2: { // StreamItem const pending = this.streamManager.getInvocation(streamItem.invocationId); if (pending !== undefined) pending.resolve(streamItem.item); break; } case 3: { // Completion const pending = this.streamManager.removeInvocation(completion.invocationId); if (pending !== undefined) { if (completion.error.length > 0) pending.reject(new Error(completion.error)); else pending.resolve(completion.result); } break; } case 6: break; // Ping case 7: this.handleCloseMessage(close); break; } } Keepalive 和重连 心跳每 15 秒发一次 Ping ，服务端 30 秒没消息就判定超时： private resetKeepAlive(): void { this.pingTimer = setInterval(() => { const ping = new PingMessage(); const encoded = this.protocol.encodeMessage(ping); this.httpConnection.send(encoded); }, this.keepAliveIntervalInMilliseconds) as number; // 15000ms } private resetServerTimeout(): void { clearTimeout(this.serverTimeoutTimer); this.serverTimeoutTimer = setTimeout(() => { this.httpConnection.stop(new Error('Server timeout')); }, this.serverTimeoutInMilliseconds) as number; // 30000ms } 重连策略是 SignalR 的经典配置 [0, 2000, 5000, 10000, 30000] ——先立即重试，然后 2 秒、5 秒、10 秒、30 秒。但官方 SDK 试完这 5 次就放弃了。我的实现改成了循环重试，延迟数组里的最后一个值（ 30 秒）会一直用下去，最多 15 次之后才真正断开： private scheduleReconnect(): void { if (this.stopRequested) return; const delayIndex = Math.min(this.reconnectAttempt, this.reconnectDelays.length - 1); const delay = this.reconnectDelays[delayIndex]; this.reconnectTimer = setTimeout(() => this.attemptReconnect(), delay) as number; } ArkTS 的那些坑 写 SignalR 客户端最痛的不是协议本身，而是 ArkTS 的限制。它是 TypeScript 的严格子集： 不能用 as const — 只能用 class X { static readonly A = '...' } 不能写无类型对象字面量 — { key: value } 直接报错，必须声明类型 不能用解构赋值 — const [k, v] of Object.entries(obj) 编译不过 throw 只能抛 Error — catch 到的任意值不能直接 throw 每一条都是我在编译报错后才学到的。 在 ArkWeb 里跑 xterm.js 终端渲染的答案很明确：xterm.js 。问题是它跑在浏览器里，而我要在 HarmonyOS 的原生 app 里用它。 HarmonyOS 提供了 ArkWeb （ WebView 组件），有 WebMessagePort 做双向通信。我先试了 javaScriptProxy ，崩溃不断，换成 WebMessagePort 才稳定下来。 核心逻辑：创建一对 MessagePort ，Port 0 发给 HTML 端，Port 1 留在 native 端监听： // XtermWebview.ets private initMessagePort() { this.msgPorts = this.webviewController.createWebMessagePorts(); // Port 1 留在 native 端 this.msgPorts[1].onMessageEvent((result: webview.WebMessage) => { const msg = JSON.parse(result as string) as Record<string, Object>; const type = msg['type'] as string; if (type === 'input') { this.onInput(msg['data'] as string); } else if (type === 'resize') { const cols = msg['cols'] as number; const rows = msg['rows'] as number; this.onResize(cols, rows); } }); // Port 0 发给 HTML 端 this.webviewController.postMessage('__init_port__', [this.msgPorts[0]], '*'); } 输出方向反过来：native 拿到 Worker 的输出，base64 编码后调 runJavaScript 写入 xterm： writeOutput(base64Payload: string) { const escaped = base64Payload.replace(/\\/g, '\\\\').replace(/"/g, '\\"'); this.webviewController.runJavaScript(`writeBase64Output("${escaped}")`); } 为什么用 base64 ？因为终端输出包含二进制数据（ ANSI 转义序列、控制字符），直接当 JSON 字符串传会炸。 整个终端页面的生命周期是一个 9 状态的状态机： Disconnected → Connecting → Replaying → Live → Reconnecting → ... 。重连时 Gateway 先 replay scrollback buffer ，然后切到 Live 模式，用户感觉不到断过。 手机上怎么按 Ctrl+C 终端有了，但我怎么在手机上发 SIGINT ？ 没有键盘的设备用终端，这是所有移动端终端 app 的噩梦。 我的解法是 VirtualKeyBar ——一个水平可滚动的虚拟按键条。关键是 Sticky Modifier ：Ctrl 和 Alt 是 latch 按键，按一下变亮（激活），再按下一个字符键时才发送组合键。 // VirtualKeyBar.ets — LatchButton 组件 @Component struct LatchButton { label: string = '' @Prop latched: boolean = false onToggle: () => void = () => {} build() { Button(this.label) .backgroundColor(this.latched ? $r('app.color.terminal_secondary_container') : $r('app.color.terminal_surface_container_high')) .onClick(() => { clickHaptic(); this.onToggle(); }) } } Ctrl + 字母的映射藏在 handleVirtualKey 里： // TerminalPage.ets private handleVirtualKey(key: string) { if (key.startsWith('Ctrl+')) { const label = key.substring(5); // a-z → 0x01-0x1A const ch = label.toLowerCase().charCodeAt(0); if (ch >= 97 && ch <= 122) { this.sendInput(String.fromCharCode(ch - 96)); } } // Escape sequences const inputMap: Record<string, string> = { 'ArrowUp': '\x1b[A', 'ArrowDown': '\x1b[B', 'ArrowRight': '\x1b[C', 'ArrowLeft': '\x1b[D', }; } 'c'.charCodeAt(0) 是 99 （ 0x63 ），减 96 得 3 ， String.fromCharCode(3) 就是 \x03 ——SIGINT 。一行数学运算解决了所有 Ctrl+字母的映射。 CI/CD 十五连跪 6 月 8 号，我开始写 harmony-release.yml 。 然后接下来的 3 天里，我推了这个文件 15 次。 Pipeline 长这样： Tag push (harmony-v*) → 版本提取 → 签名准备 → hvigor 构建 → AGConnect 认证 → OBS 上传 → 编译轮询 → 提审 踩坑中最惨的几个： AGConnect API 文档是解谜游戏。 /upload-url/for-obs 端点文档只写了入参，没告诉你返回的 header 要原样传给 OBS 的 PUT 请求。我是抓包才搞明白的。 编译状态要轮询。 华为的服务端编译一个 .app 文件要 60 秒以上，API 没有回调，只能 30 秒一次轮询，最多 20 次： - name: Query compile status run: | for i in $(seq 1 20); do SUCCESS_STATUS=$(curl -s ... | jq -r '.pkgStateList[0].successStatus') if [ "$SUCCESS_STATUS" = "0" ]; then echo "Compile successful" exit 0 fi sleep 30 done 自托管 runner 的脏文件。 有一次构建失败，查了半天发现是 /tmp 下残留了上次的 .app 文件，签名步骤拿错了文件。于是加了一行 rm -rf 在 pipeline 开头。 每次看到 GitHub Actions 红叉，我都觉得自己在跟华为的文档玩解谜游戏。 53 天的数字 425 次提交。53 天。1 个人。5 个平台。 其中鸿蒙端： 8645 行 ArkTS 1091 行 手写 SignalR 客户端 9 个 HAR 模块（ 1 entry + 5 feature + 3 common ） 5 月 8 日 第一个鸿蒙 commit → 6 月 11 日 上架华为应用市场 接下来要做的：文件传输、端口转发、多 tab 、命令片段。 如果你也觉得手机上应该有个不中断的终端，来看看： github.com/monster-echo/CortexTerminal2 Docker 一键体验： docker run -d -p 5000:5000 ghcr.io/monster-echo/cortex-terminal:latest

那天晚上 11 点，我在火车上 SSH 到服务器查日志。手机浏览器切了个微信回来，tab 被 kill 了，session 断了，查了一半的日志全没了。 我翻了翻手机上所有终端 app——Termius 、Blink Shell 、ServerCat——它们都有同一个问题：你不能真的"保持连接"。系统杀后台、网络切换、锁屏省电，随便哪个都能把你的 SSH 掐断。 那能不能反过来？让 shell 在远程服务器上一直跑，手机只是个"显示器"——断了就断了，重连回来输出还在。 这就是 Corterm （云枢终端）的出发点： session 不是连接，是状态。 先把架子搭起来 思路很直接： Worker — 装在远程机器上的轻量 agent ，管 PTY 生命周期。你断了连，shell 照跑。 Gateway — 中间层，管认证、路由、session 协调。Worker 和 Client 之间不直接通信。 Client — 纯渲染层。断了重连时，Gateway 把 Worker 上的 scrollback buffer 吐给你，无缝衔接。 Client (Browser/iOS/Android/HarmonyOS) ↕ SignalR Gateway (.NET 10) ↕ SignalR Worker (.NET 10 + PTY) Gateway 和 Worker 用 .NET 10 + SignalR ，Client 端浏览器用 React + xterm.js ，iOS/Android 用 MAUI 。浏览器、手机 App 都跑通了，接下来是鸿蒙。 手搓 SignalR：1091 行 ArkTS 的协议实现 鸿蒙端的第一道坎：SignalR 。 Corterm 的 Gateway 是 .NET 写的，实时通信用的 SignalR 。iOS/Android 那边有官方 SDK ，浏览器更不用说。但鸿蒙……我翻了半天文档，没有。连第三方实现都没有。 两条路：要么在 Gateway 加一层 WebSocket 中间层，要么直接在 ArkTS 里实现 SignalR 协议。前者意味着改服务端，所有客户端都得测。后者意味着我要在一个 TypeScript 的严格子集里，手写一个协议栈。 我选了后者。 Negotiate 握手 SignalR 连接的第一步不是 WebSocket ，而是一个 HTTP POST negotiate 请求。服务端返回一个 connectionToken ，后续 WebSocket 连接必须带上这个 token 。 // HttpConnection.ets private async negotiate(accessToken: string): Promise<string> { const negotiateUrl = `${this.url}/negotiate?negotiateVersion=1`; const httpClient = http.createHttp(); const headers: Record<string, string> = { 'Accept': 'application/json', 'Content-Type': 'application/json', }; if (accessToken.length > 0) { headers['Authorization'] = `Bearer ${accessToken}`; } const response = await httpClient.request(negotiateUrl, { method: http.RequestMethod.POST, header: headers, connectTimeout: 15000, readTimeout: 15000, }); const body = response.result as string; const negotiateResponse = JSON.parse(body) as NegotiateResponse; this.connectionId = negotiateResponse.connectionId ?? ''; return negotiateResponse.connectionToken ?? ''; } 鸿蒙的网络 API 是 @kit.NetworkKit 里的 http.createHttp() 和 webSocket.createWebSocket() ，用法跟 Node.js 的差不多，但所有东西都得显式类型声明。 WebSocket 连接 拿到 token 后，拼 URL ，建 WebSocket： // HttpConnection.ets private async connectWebSocket(accessToken: string): Promise<void> { const wsUrl = this.url .replace('https://', 'wss://') .replace('http://', 'ws://'); let fullUrl = wsUrl; const params: string[] = []; if (this.connectionToken.length > 0) { params.push(`id=${encodeURIComponent(this.connectionToken)}`); } if (accessToken.length > 0) { params.push(`access_token=${encodeURIComponent(accessToken)}`); } if (params.length > 0) { fullUrl += '?' + params.join('&'); } this.ws = webSocket.createWebSocket(); const ws = this.ws; const openPromise = new Promise<void>((resolve, reject) => { ws.on('open', () => resolve()); ws.on('error', (err: Error) => { if (!this.stopRequested) reject(new Error(`WebSocket error: ${err.message}`)); }); }); ws.on('message', (_err: Error, data: string | ArrayBuffer) => { let text: string; if (typeof data === 'string') { text = data; } else { text = buffer.from(data).toString('utf-8'); } if (this.onreceive !== null) { this.onreceive(text); } }); await ws.connect(fullUrl, { header: connectHeaders }); await openPromise; } Hub 协议层 SignalR 不是裸 WebSocket 。它有自己的消息格式——我打开 C# 源码看了下，其实就 5 种消息类型： Type 1 — InvocationMessage （双向 RPC 调用） Type 2 — StreamItemMessage （流式结果） Type 3 — CompletionMessage （ RPC 响应） Type 6 — Ping （心跳） Type 7 — Close （关闭） 消息之间用 0x1E （ ASCII record separator ）分隔。 processIncomingData 是整个消息分发管道的入口： // HubConnection.ets private processIncomingData(data: string): void { // 第一条消息是 handshake response if (this.handshakePromise !== null) { this.protocol.decodeHandshakeResponse(data); const promise = this.handshakePromise; this.handshakePromise = null; promise.resolve(); return; } // 常规消息 const messages = this.protocol.decodeMessages(data, this.logger); for (const message of messages) { this.dispatchMessage(message); } } private dispatchMessage(message: HubMessageBase): void { this.resetServerTimeout(); switch (message.type) { case 1: { // Invocation const invocation = message as InvocationMessage; this.invokeHandler(invocation.target, invocation.arguments); break; } case 2: { // StreamItem const pending = this.streamManager.getInvocation(streamItem.invocationId); if (pending !== undefined) pending.resolve(streamItem.item); break; } case 3: { // Completion const pending = this.streamManager.removeInvocation(completion.invocationId); if (pending !== undefined) { if (completion.error.length > 0) pending.reject(new Error(completion.error)); else pending.resolve(completion.result); } break; } case 6: break; // Ping case 7: this.handleCloseMessage(close); break; } } Keepalive 和重连 心跳每 15 秒发一次 Ping ，服务端 30 秒没消息就判定超时： private resetKeepAlive(): void { this.pingTimer = setInterval(() => { const ping = new PingMessage(); const encoded = this.protocol.encodeMessage(ping); this.httpConnection.send(encoded); }, this.keepAliveIntervalInMilliseconds) as number; // 15000ms } private resetServerTimeout(): void { clearTimeout(this.serverTimeoutTimer); this.serverTimeoutTimer = setTimeout(() => { this.httpConnection.stop(new Error('Server timeout')); }, this.serverTimeoutInMilliseconds) as number; // 30000ms } 重连策略是 SignalR 的经典配置 [0, 2000, 5000, 10000, 30000] ——先立即重试，然后 2 秒、5 秒、10 秒、30 秒。但官方 SDK 试完这 5 次就放弃了。我的实现改成了循环重试，延迟数组里的最后一个值（ 30 秒）会一直用下去，最多 15 次之后才真正断开： private scheduleReconnect(): void { if (this.stopRequested) return; const delayIndex = Math.min(this.reconnectAttempt, this.reconnectDelays.length - 1); const delay = this.reconnectDelays[delayIndex]; this.reconnectTimer = setTimeout(() => this.attemptReconnect(), delay) as number; } ArkTS 的那些坑 写 SignalR 客户端最痛的不是协议本身，而是 ArkTS 的限制。它是 TypeScript 的严格子集： 不能用 as const — 只能用 class X { static readonly A = '...' } 不能写无类型对象字面量 — { key: value } 直接报错，必须声明类型 不能用解构赋值 — const [k, v] of Object.entries(obj) 编译不过 throw 只能抛 Error — catch 到的任意值不能直接 throw 每一条都是我在编译报错后才学到的。 在 ArkWeb 里跑 xterm.js 终端渲染的答案很明确：xterm.js 。问题是它跑在浏览器里，而我要在 HarmonyOS 的原生 app 里用它。 HarmonyOS 提供了 ArkWeb （ WebView 组件），有 WebMessagePort 做双向通信。我先试了 javaScriptProxy ，崩溃不断，换成 WebMessagePort 才稳定下来。 核心逻辑：创建一对 MessagePort ，Port 0 发给 HTML 端，Port 1 留在 native 端监听： // XtermWebview.ets private initMessagePort() { this.msgPorts = this.webviewController.createWebMessagePorts(); // Port 1 留在 native 端 this.msgPorts[1].onMessageEvent((result: webview.WebMessage) => { const msg = JSON.parse(result as string) as Record<string, Object>; const type = msg['type'] as string; if (type === 'input') { this.onInput(msg['data'] as string); } else if (type === 'resize') { const cols = msg['cols'] as number; const rows = msg['rows'] as number; this.onResize(cols, rows); } }); // Port 0 发给 HTML 端 this.webviewController.postMessage('__init_port__', [this.msgPorts[0]], '*'); } 输出方向反过来：native 拿到 Worker 的输出，base64 编码后调 runJavaScript 写入 xterm： writeOutput(base64Payload: string) { const escaped = base64Payload.replace(/\\/g, '\\\\').replace(/"/g, '\\"'); this.webviewController.runJavaScript(`writeBase64Output("${escaped}")`); } 为什么用 base64 ？因为终端输出包含二进制数据（ ANSI 转义序列、控制字符），直接当 JSON 字符串传会炸。 整个终端页面的生命周期是一个 9 状态的状态机： Disconnected → Connecting → Replaying → Live → Reconnecting → ... 。重连时 Gateway 先 replay scrollback buffer ，然后切到 Live 模式，用户感觉不到断过。 手机上怎么按 Ctrl+C 终端有了，但我怎么在手机上发 SIGINT ？ 没有键盘的设备用终端，这是所有移动端终端 app 的噩梦。 我的解法是 VirtualKeyBar ——一个水平可滚动的虚拟按键条。关键是 Sticky Modifier ：Ctrl 和 Alt 是 latch 按键，按一下变亮（激活），再按下一个字符键时才发送组合键。 // VirtualKeyBar.ets — LatchButton 组件 @Component struct LatchButton { label: string = '' @Prop latched: boolean = false onToggle: () => void = () => {} build() { Button(this.label) .backgroundColor(this.latched ? $r('app.color.terminal_secondary_container') : $r('app.color.terminal_surface_container_high')) .onClick(() => { clickHaptic(); this.onToggle(); }) } } Ctrl + 字母的映射藏在 handleVirtualKey 里： // TerminalPage.ets private handleVirtualKey(key: string) { if (key.startsWith('Ctrl+')) { const label = key.substring(5); // a-z → 0x01-0x1A const ch = label.toLowerCase().charCodeAt(0); if (ch >= 97 && ch <= 122) { this.sendInput(String.fromCharCode(ch - 96)); } } // Escape sequences const inputMap: Record<string, string> = { 'ArrowUp': '\x1b[A', 'ArrowDown': '\x1b[B', 'ArrowRight': '\x1b[C', 'ArrowLeft': '\x1b[D', }; } 'c'.charCodeAt(0) 是 99 （ 0x63 ），减 96 得 3 ， String.fromCharCode(3) 就是 \x03 ——SIGINT 。一行数学运算解决了所有 Ctrl+字母的映射。 CI/CD 十五连跪 6 月 8 号，我开始写 harmony-release.yml 。 然后接下来的 3 天里，我推了这个文件 15 次。 Pipeline 长这样： Tag push (harmony-v*) → 版本提取 → 签名准备 → hvigor 构建 → AGConnect 认证 → OBS 上传 → 编译轮询 → 提审 踩坑中最惨的几个： AGConnect API 文档是解谜游戏。 /upload-url/for-obs 端点文档只写了入参，没告诉你返回的 header 要原样传给 OBS 的 PUT 请求。我是抓包才搞明白的。 编译状态要轮询。 华为的服务端编译一个 .app 文件要 60 秒以上，API 没有回调，只能 30 秒一次轮询，最多 20 次： - name: Query compile status run: | for i in $(seq 1 20); do SUCCESS_STATUS=$(curl -s ... | jq -r '.pkgStateList[0].successStatus') if [ "$SUCCESS_STATUS" = "0" ]; then echo "Compile successful" exit 0 fi sleep 30 done 自托管 runner 的脏文件。 有一次构建失败，查了半天发现是 /tmp 下残留了上次的 .app 文件，签名步骤拿错了文件。于是加了一行 rm -rf 在 pipeline 开头。 每次看到 GitHub Actions 红叉，我都觉得自己在跟华为的文档玩解谜游戏。 53 天的数字 425 次提交。53 天。1 个人。5 个平台。 其中鸿蒙端： 8645 行 ArkTS 1091 行 手写 SignalR 客户端 9 个 HAR 模块（ 1 entry + 5 feature + 3 common ） 5 月 8 日 第一个鸿蒙 commit → 6 月 11 日 上架华为应用市场 接下来要做的：文件传输、端口转发、多 tab 、命令片段。 如果你也觉得手机上应该有个不中断的终端，来看看： github.com/monster-echo/CortexTerminal2 Docker 一键体验： docker run -d -p 5000:5000 ghcr.io/monster-echo/cortex-terminal:latest

有佬做过华为手表和codex cc 联动的应用吗。通过智能手表感知codex的当前任务，还可以进行互动，这种可行吗？ 3 个帖子 - 2 位参与者 阅读完整话题

联通的2000兆宽带，光猫是华为星光f50。光猫路由模式下载可以跑到2400m，上传240m。改成桥接路由器拨号下载就只有1700m到1900m的样子，偶尔能够到2000.路由器是华硕tuf gaming 小旋风 Pro WiFi7 4 个帖子 - 3 位参与者 阅读完整话题

最近在华为freeclip2和oppo enco clip2两个做抉择 本人是用oppo手机 这两个耳机哪个佩戴和体验上更好 4 个帖子 - 4 位参与者 阅读完整话题

“IT早报”时间，大家好，现在是 2026 年 6 月 9 日星期二，今天的重要科技资讯有： 1、华为余承东官宣尊界 V800，定位“超高端 MPV” 华为余承东官宣尊界 V800，定位“超高端 MPV”，新车已在工信部完成申报。车身尺寸庞大，轴距达 3430mm，搭载 1.5T 增程器及前后双电机。其设计延续了尊界 S800 的豪华语言，并提供多种配置选择。>> 查看详情 2、苹果 WWDC26 主题演讲一文汇总：iOS 27 等新系统发布、Siri AI 登场，库克迎来生涯“最后一舞” 苹果 WWDC26 主题演讲已结束，库克完成 CEO 任内“最后一舞”。新一代 iOS 27、macOS 27 等系统聚焦三大重点：平台性能与设计优化、儿童安全功能增强，以及由全新 Apple 智能驱动的 Siri 全面重构。>> 查看详情 3、腾讯 QQ 回应为何不显示华为 5A 在线状态，称该标识为鸿蒙系统定制无法获取 腾讯 QQ 官方最近就为什么鸿蒙系统不显示 5A 在线状态这一问题进行了回应，称 5A 标识为鸿蒙系统定制网络状态显示，在线状态无法获取 5A 网络状态，在线状态的显示以真实网络连接为准。>> 查看详情 4、总台曝光小作坊翻新牙刷：化工废桶、拖鞋边角料当原料，江苏扬州开展专项整治 总台《财经调查》栏目 6 月 7 日晚间发布报道，称接到消费者和业内人士的举报，市场上有一些牙刷生产企业，涉嫌违规使用各类废旧、回收塑料的原料，制作一次性牙刷，并大量流入市场。>> 查看详情 5、消息称月之暗面寻求 20 亿美元融资，估值较去年 12 月暴涨 7 倍 月之暗面正寻求新一轮高达 20 亿美元的融资，目标估值达 300 亿美元。若成功，其估值将在半年内暴涨七倍，这已是该公司半年内的第三次融资，旨在应对日益激烈的大模型竞争。>> 查看详情 6、苹果官宣 iPhone 11 也能升级 iOS 27，应用打开速度最高提升 30% 在 6 月 9 日的 WWDC26 主题演讲中，苹果官宣 iPhone 11 也能升级到 iOS 27 系统。>> 查看详情 7、苹果：Siri AI 和其他 Apple 智能新功能在中国大陆暂不提供 在 6 月 9 日的 WWDC26 主题演讲中，苹果发布了 Siri AI 和多项 Apple 智能新功能。在中国大陆，Siri AI 和其他 Apple 智能新功能需要配合监管要求推进相关工作，因此暂不提供。>> 查看详情 8、赛力斯“赛豆科技”全新品牌 AIVA 官宣：车标样式曝光，全系标配豆包大模型智能座舱 赛豆科技品牌发布会定档 6 月 9 日 19:00-20:00 举行。根据官方直播页面，这一新汽车品牌定名 AIVA。>> 查看详情 9、中国 AI 大模型周调用量连续六周超越美国，前四名均为国产模型 OpenRouter 最新数据显示，全球 AI 大模型总调用量连续七周上涨。中国模型周调用量环比增长 27.49% 达 14.19 万亿 Token，连续六周超越美国。DeepSeek-V4-Flash 蝉联榜首，MiniMax 新模型 M3 首周即冲入前三。>> 查看详情 10、微信灰度朋友圈关键词搜索功能：支持按朋友或发布时间筛选，可快速定位需要的信息 据网友分享，微信新版朋友圈主页最近右上角出现了“放大镜”图标，支持搜索历史朋友圈内容。IT之家也就此向腾讯客服进行求证，对方也确认了该功能的存在。>> 查看详情 11、微信 AI 官宣内测：用户一句话，可直接操作小程序页面 微信开放平台为开发者提供了接入微信 AI 生态的能力，提供两种接入模式，开发者可按需选择，满足不同规模团队的开发需求（两种模式不互斥，可同时开启）。>> 查看详情 12、阿里宣布合并通义大模型事业部和未来生活实验室，周靖人将担任首席科学家 此次调整涉及到一批 AI 业务。周靖人将担任阿里巴巴首席科学家，牵头成立阿里巴巴 AI 未来研究院，专注前沿 AI 科技的探索与突破。>> 查看详情 13、追觅 CEO 俞浩实控的逐越鸿智质押嘉美包装 2.47 亿股，用于并购贷款担保 嘉美包装 6 月 8 日一字跌停，收盘股价报 15.11 元 / 股，总市值约 166 亿元。>> 查看详情 14、徐洁云回应雷军增持金山软件：雷总持股比例增加是由于小米增持，并非个人买入 6 月 8 日，@徐洁云 就小米集团增持金山软件一事发文：感谢大家的关注，这是小米在公开市场增持金山软件，并做合规披露；另外，雷总持股比例增加，是由于小米增持，并非个人买入。小米坚定看好金山的长期发展，以及双方的战略协同前景。>> 查看详情 15、小米官方回应 SU7 Ultra 在江西省南昌市英雄大桥起火事件，称初步排除电池自燃引发起火 小米公司发言人官方微博发文，回应了 6 月 7 日 SU7 Ultra 在江西省南昌市英雄大桥起火事件，称经现场调查及后台数据分析，事发前车辆动力电池全程处于正常工作状态，未出现热失控信号，初步排除电池自燃引发起火。>> 查看详情 16、网传乘客用智能眼镜偷拍空姐上传社区，乐奇 Rokid 回应称高度重视并紧急启动专项整改 乐奇 Rokid 6 月 8 日发文，发布关于社区生态治理与隐私保护的声明。>> 查看详情 17、小米公司发言人：多名网络用户就造谣小米公司公开道歉 小米公司发言人 6 月 8 日宣布，多名网络用户就造谣小米公司公开道歉。>> 查看详情 18、科学家首次精确编辑人类胚胎基因，引发“定制婴儿”担忧 哥伦比亚大学团队利用碱基编辑技术，成功修复了胚胎中与心脏病和血液疾病相关的致病基因突变，但近八成胚胎形成“嵌合体”，意味着致病细胞可能残留。该技术相比 CRISPR 更精准，但伦理争议巨大，目前培育基因编辑婴儿在美国等多国属违法。>> 查看详情 19、2999 元起：小米 17T 系列手机发布，天玑 8500-Ultra / 天玑 9500 芯片 该系列包含小米 17T 和 17T Pro 两款机型，均配备大电池与徕卡影像系统，Pro 版搭载天玑 9500，标准版搭载天玑 8500-Ultra。>> 查看详情 20、全球首个：高德发布 3D 原生城市世界模型 ABot-Earth0.5，单图 10 分钟重建 3D 城市 该模型已建成覆盖 190 多个国家的全球最广 3D 地图，输出素材可直接导入主流游戏引擎。其制图成本仅为传统 1%，效率提升约千倍，有望为具身智能、低空经济及应急救援提供基础支撑。>> 查看详情 21、苹果 iPhone 显示最高气温接近 50 度，杭州临安气象局通报称 App 自身系统数据错误 经查证，该异常预报系该品牌手机自带天气预报 App 自身系统数据错误所致。>> 查看详情 22、比亚迪王朝首款 D 级旗舰轿车“大汉”官方伪装照公布 比亚迪王朝网首款 D 级旗舰轿车“大汉”官方伪装照 6 月 8 日公布。此前经过多轮征名筛选，“大汉”在 6 个候选名字中断层领先。新车信息尚待披露，但参考同属 D 级旗舰的 SUV“大唐”将于 6 月中旬上市，其搭载的第二代刀片电池、全域 1000V 高压架构等配置。>> 查看详情 23、整治夸大宣传、只评不测、商测一体等问题，国家网信办、市场监管总局联合印发《网络测评活动规范》 国家网信办、市场监管总局联合印发《网络测评活动规范》，旨在解决网络测评中存在的夸大宣传、只评不测、商测一体等问题。规范要求涉及产品功能性能的测试须委托法定检验检测机构，并明示测试标准。主观感受类评价需显著标明“仅供参考”。>> 查看详情 24、魅族推出“618 屏安计划・售后免费贴膜”活动，所有在保机器均可到店免费享受钢化膜贴膜 魅族售后官方 6 月 8 日宣布推出“618 屏安计划・售后免费贴膜”活动，称所有在保机器均可到店免费享受钢化膜贴膜服务。设备已过保、存在人为损坏故障的机型，不享受本次免费贴膜权益。>> 查看详情 25、消息称理想公关一号位杨继斌将离职，入职仅半年 6 月 8 日，多个爆料账号爆出理想汽车公关一号位杨继斌从理想离职。>> 查看详情 26、王腾回应塑料中框言论“回旋镖”：我说的可是 2025 年，毕竟 26 年各种元器件都在涨价 今日宜休科技公司创始人 @王腾Thomas 6 月 8 日发布了自己此前关于塑料中框言论的回旋镖，称自己说的可是 2025 年，毕竟 26 年各种元器件都在涨价。>> 查看详情 27、消息称比亚迪大唐 EV 将于 6 月 17 日上市，预售价 25-32 万元 该车是王朝网首款 D 级旗舰 SUV，拥有第二代刀片电池、全域 1000V 高压架构等配置，提供单电机、双电机四驱等动力选择，预售价 25-32 万元。>> 查看详情 28、奇瑞就与印度塔塔集团商谈合作衍生的失实报道发声，称没有在该市场直接投资和技术转让等安排 奇瑞集团 6 月 8 日就与印度塔塔集团的相关合作发布《关于奇瑞合作事宜失实报道的澄清声明》，称奇瑞没有在印度市场直接投资和技术转让等安排，部分媒体和账号所称的“平台转让”、“平台授权”等表述与事实不符。>> 查看详情 29、小米机器人亮相小米 17T 系列发布会，能自己拿着手机拍照 在发布会上，小米机器人惊喜亮相，拿着小米 17T Pro 进行拍照，通过音量键变焦拍照方式，演示了该手机的长焦能力。>> 查看详情 30、张雪：凯越没有找过我，支持凯越维护自身权益 张雪 6 月 8 日发布视频，就相关传言进行澄清，他表示“凯越没有找过我，据我所知凯越目前的经营状态没有问题”。>> 查看详情 31、余承东科普为何有些手机越用越卡：运存负责给 App 提供运行空间，是卡顿与否的重要原因 余承东科普手机卡顿的真正原因在于运行内存不足，而非存储空间满。他解释了 16GB 运行内存与 512GB 存储的区别，并介绍了华为的“超空间内存技术”如何通过压缩 App 来提升多任务能力。>> 查看详情 32、未来十年“打飞的”或成出行可能：我国飞行汽车进入商业化探索期，有望拉动 10 万亿级市场 专家表示，当前飞行汽车应用主要体现在高价值、高时效性的场景，比如争分夺秒的急救转运、特种消防救援、点对点的高端接驳。在未来十年的成长期，随着飞行汽车技术不断成熟和价格普惠，将使通过叫车软件“打飞的”出行成为可能。>> 查看详情 33、新能源车“变胖”让老司机都犯愁，数据显示常见家用车 10 年变宽 20 厘米 如今家用热门新能源车中的大型 SUV、MPV 车型普遍接近甚至超过 2 米，车重也是动辄在 2 吨以上。日益变胖的新能源车，也给车主停车带来了困扰。>> 查看详情 34、京东发言人：京东外卖、京东创始人等遭受大量恶意抹黑和造谣攻击，小笨文化等部分造谣抹黑者已受到法律惩处 京东发言人官方微博 6 月 8 日转发了一篇来自“四川公安”的推文，表示一段时间以来，京东外卖、京东金融等业务以及京东创始人遭受了大量有组织、有预谋的恶意抹黑和造谣攻击。>> 查看详情 35、英伟达与 SK 海力士宣布多年期技术合作，共同开发下一代 AI 内存 双方宣布建立多年期技术合作，将围绕下一代 AI 内存展开联合研发，并应用于半导体制造。SK 海力士将为英伟达 Vera Rubin AI 超级计算机、RTX Spark PC 等平台开发专用内存。同时，英伟达的 CUDA-X、PhysicsNeMo 等技术将用于加速芯片设计和晶圆厂数字孪生。>> 查看详情 36、用 AI 猜胜负：Kimi 官宣将公开预测 104 场世界杯赛事，德国队或爆冷夺冠 2026 年美加墨世界杯即将揭幕。月之暗面 Kimi 6 月 8 日宣布，将通过「Agent 集群」同时调度 300 个子 Agent，从战术、球员、伤病、赛程、历史、舆情、天气、心理、赔率变动、专家观点等维度，并行研究 104 场世界杯赛事，并在每轮赛前公开预测与赛后复盘。>> 查看详情 今天就先聊到这里，IT早报，咱们明天见。

IT之家 6 月 8 日消息，博主 @熠熠玩数码 刚刚发文透露， 华为鸿蒙 HarmonyOS 7 系统已开启对内部保密 Beta 用户推送 。 博主表示，按照惯例，在 HDC 发布后， 预计 HarmonyOS 7 马上会开启 Developer Beta 招募 ，正式版则会在新旗舰手机上首发搭载。 据IT之家此前报道，华为开发者大会 HDC 2026 官宣定档 6 月 12 日 ~14 日举行， 早鸟票已于 4 月 29 日开售 。本届 HDC 2026 将发布 HarmonyOS 全新版本、鸿蒙 AI 核心能力，以及生态全新成果等。

IT之家 6 月 8 日消息，阿维塔科技董事长王辉刚刚分享了阿维塔 07L 中大型 SUV 的设计手稿。他透露， 更多原创设计，会陆续解锁 。 据介绍，阿维塔 07L 是一款中大型 SUV 全新车型，由阿维塔和华为乾崑联合设计， 预计今年三季度上市 。该车车身尺寸全面加大，车长达到 4910mm、车高为 1650mm、轴距达 2990mm。根据此前宣传，新车主打卖点之一就是储物容量，前后备厢累计可装 12 件行李箱（行李箱具体容量未公布，预计大小在 20 寸 ~24 寸之间）。 据IT之家此前报道，阿维塔 07L 已现身工信部第 407 批《道路机动车辆生产企业及产品公告》。 该车延续双动力路线，提供纯电与增程两种选择 。其中，增程版车型搭载了 1.5T 增程器 + 231kW 电机，并提供 39.05 或 52.01 千瓦时的磷酸铁锂电池，WLTC 工况下纯电续航为 197 公里、270 公里。 阿维塔官方确认， 阿维塔 07L 将首批搭载华为乾崑智驾 ADS 5 系统 。

IT之家 6 月 8 日消息，一条华为乾崑智驾车型百公里时速进隧道，并触发避障提前切换车道的视频最近在互联网平台曝光，引发了网友和博主讨论。 事实上，隧道内部环境与开放道路不同，空间封闭、车道较窄、视野受限，驾驶者观察周边情况的能力下降，同时光线从明亮的室外进入隧道会产生视觉适应延迟，因此很容易导致反应不及时或操作失误而发生事故。 此次曝光的视频画面显示，该车在进入隧道后立刻就遇到了桩桶。而在人眼尚未看清路况之时，车辆已经提前发起变道操作，并在遇到锥桶前切换好了车道。 将视频调慢至 0.5X 进行回放可以看到，这台车执行躲避非常坚决，且在进隧道前就开启了转向灯。由此可以看出， 车辆在还没进隧道时，其感知系统就已经发现了障碍 。 值得一提的是，还有博主分享了其他华为乾崑智驾的避障表现视频。另一条视频显示，该车在高速遭遇了废弃栏杆，但车辆却提前从 110+ 公里时速减速至约 90+，并成功识别出了两侧栏杆中间的可通行空间。 在今年 5 月的鸿蒙智行问界 M9 系列新品发布会上，华为常务董事、产品投资评审委员会主任、终端 BG 董事长余承东曾谈及为何华为乾崑智驾会选择多传感器融合感知的路线。他表示， 纯视觉目标是接近人眼，而华为的目标是超越人眼 。 虽然目前国内的智能辅助驾驶功能已愈发成熟，但IT之家仍要提醒： 辅助驾驶≠自动驾驶 ，即使开启相关功能，驾驶员也绝不能放松警惕，驾驶人才是最终的责任主体。启用相关功能前，一定要了解功能局限和具体能力范围，并时刻观察路况，随时准备接管，避免悲剧发生。 根据汽车驾驶自动化分级的国家标准，驾驶自动化等级分为 0-5 级（目前在售车辆均为 L2 级组合驾驶辅助）： L0 为应急辅助 L1 为部分驾驶辅助 L2 为组合驾驶辅助 L3 为有条件自动驾驶 L4 为高度自动驾驶 L5 才是完全自动驾驶

IT之家 6 月 8 日消息，在去年 11 月 25 日的华为 Mate 80 系列 | Mate X7 及全场景新品线上发布会上，华为常务董事、产品投资委员会主任、终端 BG 董事长余承东正式宣布 Mate 80 系列手机支持 5A 速度 。 ▲ IT之家视频：华为 Mate 80 系列首发开箱 根据华为官方介绍，5A 只代表华为终端先进的通信技术，而非网络制式，既不等同于 5G-A（5GA），也不等同于 5.5G。 5A 技术没有单独的开关 ，无需用户额外付费或手动设置，支持机型将在系统状态栏默认显示 5A 标识。 IT之家注意到，腾讯 QQ 官方最近就为什么鸿蒙系统不显示 5A 在线状态这一问题进行了回应： 5A 标识为鸿蒙系统定制的网络状态显示，在线状态无法获取 5A 网络状态，在线状态的显示以真实网络连接为准。

各位佬， 剧透 ，想着买个降噪耳机，去看了华为、小米、科大讯飞最后也体验了苹果的air pods4降噪版 还是感觉苹果最强，想问问各位佬这块耳机怎么样，多少钱入的，值得入手不，有没有什么缺点？ 目前线下店1400多， 1100多， 今天最低930 有点纠结了~ 13 个帖子 - 11 位参与者 阅读完整话题

IT之家 6 月 8 日消息，华为智选车产品总监（享界系列）彭磊今日发文， 称享界 SUV 上周也完成了公告提报，也是享界的一场“高考”，即将面世 。 据IT之家此前报道，鸿蒙智行享界方盒子 SUV 谍照已曝光。 新车采用方正硬朗的外观设计，并拥有全新造型的大灯，摆脱家族化设计风格 。另外，车顶处可见轻微隆起。由此来看，新车有望搭载华为乾崑 896 线双光路图像级激光雷达。 另外，根据鸿蒙智行目前的产品出新节奏和规划来看，享界方盒子 SUV 新车预计还将搭载全新一代鸿蒙智行 HarmonyOS 专属座舱以及华为乾崑智驾 ADS 5。 在去年 12 月的鸿蒙智行年度直播中，华为常务董事、产品投资委员会主任、终端 BG 董事长余承东 透露了享界新车部分信息 。据介绍，新车外观内饰都有创新，中央广播电视总台节目主持人撒贝宁形容该车的形象“够飒”。 北汽集团随后发布文章， 确认这将是一款硬派“方盒子”车型 ，还确认今年会有 SUV、MPV 等原创新品亮相。 张建勇自信地表示：“我们享界也不会客气，明年会有 SUV、MPV 等原创新品亮相，绝对不一样！”当主持人撒贝宁和尼格买提在现场用手势比划出“方盒子”形状时，一款硬派车型的亮相已呼之欲出。这预示着享界品牌将迅速从豪华轿车、旅行车市场，拓展至风格更鲜明、个性化的全新细分领域。

IT之家 6 月 8 日消息，据龙泉驿发布官方消息，由东风与华为深度联创的旗舰 SUV 奕境 X9 在成都经开区（龙泉驿区） 完成试制下线 。 IT之家获悉， 奕境 X9 将于今年 9 月在成都车展亮相并同步开启全国交付 ，奕境品牌未来三年还将投放 5 款全新产品。 ▲ 奕境 X9 工信部申报图 官方表示，为承载奕境 X9 高端智造需求，东风汽车集团有限公司成都分公司完成了自动化、数字化、柔性化产线全面升级，植入 AI 视觉检测系统、工业机器人集群，融合东风制造工艺与华为质量管理体系，实现零部件验收、整车装配、品质检测全流程双重标准验证。 奕境 X9 长 5301mm、宽 2015mm、高 1820mm，轴距为 3120mm；全系搭载华为乾崑车载光“三件套”，包括 HUAWEI XPIXEL 百万像素智慧投影大灯、HUAWEI XSCENE 车载激光投影和 HUAWEI XHUD 增强现实抬头显示。

我的华为云的Flexus L 实例IP被 墙了, 上面部署了一个hiddify, 现在没办法使用了. 谁能救救我. 2 个帖子 - 2 位参与者 阅读完整话题