RCP 预建链为何没提速？先查同一 Session、目标域名和预热时机

首屏要加载图片时，很容易以为提前发一个 connectOnly 请求就能缩短等待。排查时，先别只看“预热调用成功”这一条日志：预建链只负责提前建连接，不负责提前下载图片。真正的图片请求是否复用了连接，才是要验证的事。

本文围绕 HarmonyOS Remote Communication Kit（RCP）的冷启预建链。它适合能提前知道目标服务器、且首屏确实会访问的资源；对随机生成的地址、很晚才访问的资源，不应该无差别预热。下文的时序图是机制示意，并非实测耗时。

先弄清楚三件事

request.connectOnly = true 表示只建立连接，不发送正常的 HTTP 请求体，也不获取图片数据。随后正常请求仍要发起。预建链和正常请求应使用同一 RCP Session，目标服务器要对应；预热若比正常请求还晚，就无法把建链等待从首屏路径上挪走。即使这些条件满足，连接仍可能因网络切换、连接池或服务器行为无法复用，因此“同一 Session”是必要检查项，不是提速保证书。

华为的冷启网络预建链最佳实践在 2026-09-09 更新，示例以 rcp.Request、connectOnly、同一预建链 Session 的 fetch 和 tracing 时序进行说明。这里讨论的是 HarmonyOS 7 方向的首屏性能排查；我当前本地 SDK 为 API 24，未完成 API 26 编译与真机抓包，不能把下面的示意代码说成已在 HarmonyOS 7 实测通过。

两个容易踩的场景

场景一：预热 CDN A，首屏实际走了 CDN B。 应用启动时知道首页配置服务器，却不知道图片最终落在哪个图片域名，于是把配置域名预热了，随后首屏图片仍要重新解析、建连。排查时分别记录预热 URL 和真实首屏 URL 的 origin，不要只比较“都是 HTTPS”。修复是只对可预测的高频目标域名预热；不要为了碰运气把所有候选 CDN 都开一遍连接。

场景二：域名一致，但两次请求走了不同 Session。 预热在 sessionA.fetch(preRequest)，列表组件自己又创建了 sessionB 发真实请求。预热日志会显示成功，图片请求却未必复用这条连接。把 Session 的所有权收口到一个网络模块，在预热和真正取图时从同一个入口获取会话。另一个变体是预热任务排在首页图片请求之后，即便 Session 相同，也已经错过首屏时机。

最小接入骨架与验证

下面只展示官方文档中的关键调用关系，省略 Session 创建、释放、网络权限、错误类型和图片解码。getPreConnectSession() 是你项目里的同一会话获取函数，不是 RCP 内置 API；不要把这段直接复制成完整工程。

import { rcp } from '@kit.RemoteCommunicationKit';

// 应用准备阶段：只对已知且会在首屏使用的 HTTPS 目标预建链。
const session = getPreConnectSession();
const warmRequest = new rcp.Request(imageUrl, 'GET');
warmRequest.connectOnly = true;
await session.fetch(warmRequest);

// 首屏确实需要图片时：从同一入口获取同一 Session 发正常请求。
const dataRequest = new rcp.Request(imageUrl, 'GET');
const response = await getPreConnectSession().fetch(dataRequest);
if (response.statusCode !== 200 || !response.body) {
  throw new Error('Image response unavailable');
}

想知道是否真有收益，需要把“直接请求”设为对照组，在相同设备、网络和冷启动条件下多次比较首屏可见时间，并记录 RCP tracing 的 DNS、TCP、TLS 阶段。别拿一次快慢下结论；HTTP 缓存命中、图片本地缓存和预热连接失效都会干扰结果。关闭预建链时首屏不能失效，正常请求必须仍能完成。

下面的纯逻辑测试可保存为 preconnect-check.mjs，运行 node preconnect-check.mjs。第一个断言验证同域名不会因两张图重复预热；后面四个断言分别覆盖满足条件、不同 Session、不同目标域名和预热过晚。true 只代表值得进一步检查连接是否复用，不代表系统已经复用了连接。

import assert from 'node:assert/strict';

function targets(resources) {
  return [...new Set(resources.filter(x => x.firstScreen && x.predictable)
    .map(x => new URL(x.url).origin))].slice(0, 2);
}
function meetsPreconditions(warm, actual) {
  return warm.session === actual.session &&
    new URL(warm.url).origin === new URL(actual.url).origin &&
    warm.finishedAt <= actual.startedAt;
}

assert.deepEqual(targets([
  { url: 'https://cdn.example.com/a', firstScreen: true, predictable: true },
  { url: 'https://cdn.example.com/b', firstScreen: true, predictable: true },
  { url: 'https://api.example.com/config', firstScreen: true, predictable: true }
]), ['https://cdn.example.com', 'https://api.example.com']);
const warm = { session: 's1', url: 'https://cdn.example.com/a', finishedAt: 10 };
assert.equal(meetsPreconditions(warm, { session: 's1', url: 'https://cdn.example.com/b', startedAt: 20 }), true);
assert.equal(meetsPreconditions(warm, { session: 's2', url: 'https://cdn.example.com/b', startedAt: 20 }), false);
assert.equal(meetsPreconditions(warm, { session: 's1', url: 'https://other.example.com/b', startedAt: 20 }), false);
assert.equal(meetsPreconditions(warm, { session: 's1', url: 'https://cdn.example.com/b', startedAt: 5 }), false);
console.log('5 checks passed; no RCP connection was measured');

这只验证选择与排查规则，不会模拟 TCP/TLS，也不证明 RCP 真实连接复用。 真机验证仍要补齐 API 26 工具链和抓包/Tracing 证据。

怎么取舍

首屏只有一个固定配置域名、请求足够早：先测不预热的基线，再试少量预建链。列表图片经过多个动态 CDN：先定位最终 URL 和缓存策略，预热可能不是第一优先级。正常请求已复用长连接或命中缓存：额外预建链可能只增加连接资源开销。我的做法是把预热目标限制到少数高频服务器，保留无需预热也能加载的退路，并用 tracing 而不是“感觉变快了”决定是否保留。

参考：华为冷启网络预建链最佳实践，2026-09-09 更新。