HarmonyOS —— Remote Communication Kit 定制数据传输（TransferConfiguration）实战笔记

HarmonyOS ------ Remote Communication Kit 定制数据传输（TransferConfiguration）实战笔记

还是老规矩：这篇就当是我自己啃官方文档后记的"人话版"笔记，顺带给以后考试 / 面试 / 项目踩坑用。

一、TransferConfiguration 是干嘛的？

鸿蒙开发者第四期活动

在 HarmonyOS 的远场通信框架里（Remote Communication Kit），
TransferConfiguration 管的是：HTTP 请求"传输阶段"的行为，比如：

这次请求连服务器 最多等多久？
连上之后，整个传输过程 最多跑多久？
要不要做 自动重定向（文档里有提到策略配置）？
超时了要不要重试？怎么重试？

一句话总结：

TransferConfiguration = "这次 HTTP 请求在 时间和重试层面 到底怎么玩"。

二、支持设备 & 版本限制（又是送分点）

这段和 DnsConfiguration 一样，是"必出选择题"的那种：

支持设备 ：
- Phone
- 2in1
- Tablet
- Wearable
从 5.1.1(19) 开始新增支持：
- TV

可以直接背成一句：

定制数据传输（TransferConfiguration）支持 Phone / 2in1 / Tablet / Wearable，自 5.1.1(19) 起新增 TV 支持。

三、TransferConfiguration 在哪儿配？

官方示例的核心配置是这个：

复制代码

const sessionConfig: rcp.SessionConfiguration = {
  requestConfiguration: {
    transfer: {
      timeout: {
        connectMs: 3000,
        transferMs: 6000
      }
    }
  }
};

从外往里看一层层剥：

rcp.SessionConfiguration
- requestConfiguration：跟请求默认配置相关的统筹设置
  - transfer：传输相关配置
    - timeout：超时设置
      - connectMs：连接超时时间 （单位 ms）
        
        比如 3000 → 最多等 3 秒去"连上服务器"（TCP 建连 / TLS 握手等）。
      - transferMs：传输超时时间 （单位 ms）
        
        比如 6000 → 从开始传输到结束，最多给你 6 秒。

简单脑补流程：

"3 秒内连不上就算超时；连上之后，如果 6 秒内还没把数据收完，也算超时。"

这俩值怎么调，就看你业务是：

实时敏感（金融、IM） → 时间要短一点；
或者对延迟不敏感，但数据大（大文件下载） → transferMs 可以拉长。

四、官方示例：超时重试场景拆解

这一段官方是想说明：

"配好超时，再加上自己的重试逻辑，就能做一个比较稳的请求流程。"

1. 引入模块 & 日志函数

复制代码

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

// 简单的日志封装
const logI = console.info;
const logE = console.error;

没啥难度，就是语法糖。

2. 创建带 TransferConfiguration 的会话

复制代码

const sessionConfig: rcp.SessionConfiguration = {
  requestConfiguration: {
    transfer: {
      timeout: {
        connectMs: 3000,
        transferMs: 6000
      }
    }
  }
};

const session = rcp.createSession(sessionConfig);

理解要点：

这个 sessionConfig 是整场会话的默认配置；
后面你通过这个 session 发的请求，都会默认用这个超时策略（除非某次请求单独覆盖配置）。

3. 超时重试逻辑：retryRequest

官方给了一个递归 + Promise 的写法：

复制代码

async function retryRequest(
  url: string,
  retryCount: number,
  attempt: number
): Promise<rcp.Response | undefined> {
  return new Promise((resolve, reject) => {
    // 在最后一次重试时，等待一段时间后再发送请求
    const delay = attempt === retryCount - 1 ? 3000 : 0; // 如果是最后一次重试，延迟3秒，否则不延迟
    setTimeout(() => {
      session.get(url)
        .then(response => {
          if (response.statusCode === 200) { 
            logI(`Request successful on attempt ${attempt}.`);
            resolve(response);
          } else {
            logE(`Request failed on attempt ${attempt}, statusCode: ${response.statusCode}`);
            if (attempt < retryCount) {
              // 下一次重试（注意：这里官方示例是递归调用）
              retryRequest(url, retryCount, attempt + 1);
            } else {
              logE(`All retries failed.`);
              reject(new Error('All retries failed'));
            }
          }
        })
        .catch((err: BusinessError) => {
          logE(`Request error on attempt ${attempt}, error: ${JSON.stringify(err)}`);
          if (attempt < retryCount) {
            retryRequest(url, retryCount, attempt + 1);
          } else {
            logE(`All retries failed.`);
            reject(new Error('All retries failed'));
          }
        });
    }, delay);
  });
}

这个示例主要体现三个点：

超时行为交给 TransferConfiguration：
- 超时发生时，session.get(url) 会报错 / 返回失败；
- 然后进入 catch 或 statusCode != 200 分支。
按重试次数递归：
- 参数里 attempt 表示"第几次尝试"；
- retryCount 表示最多尝试几次（包括第一次）。
最后一次重试前增加延时：
- attempt === retryCount - 1 时，delay = 3000；
- 相当于说：
  - 第 1、2 次立刻重试；
  - 最后一次（比如第 3 次）前，先"多等 3 秒再试一下"。

⚠ 代码小提醒（偏工程思维）：

官方示例里递归调用 retryRequest 时，没有把 resolve / reject 继续"串"下去（没有 return retryRequest(...).then(resolve, reject)），在真实项目里建议用 async/await 或把 Promise 串联好。

但从文档学习 / 考试角度 ，你记住"它用递归 + 超时时间配置做了一个重试机制"就够了。

4. 调用 retryRequest：真正发请求

复制代码

const URL = 'https://www.example.com';
const retryCount = 3; // 最多尝试 3 次
const attempt = 1;    // 从第 1 次开始

const response = retryRequest(URL, retryCount, attempt);

response.then((res) => {
  if (res?.statusCode != 200) {
    logI(`Timeout retry failed`);
    return;
  }
  logI(`Timeout retry succeeded, print result: ${res}`);
}).catch((err: BusinessError) => {
  logE(`Response error, the error message is: ${JSON.stringify(err)}`);
});

可以理解为：

第一次请求：
- 连接超时 > 3000ms 或传输超时 > 6000ms → 触发失败；
在最大重试次数内，继续尝试；
都失败 → 打出 "All retries failed"。

五、从"文档内容"到"脑子里的知识点"

帮你压缩成一页小抄，方便你写博客/记笔记：

1. TransferConfiguration 作用

针对 HTTP 请求的传输行为 做配置：
- 连接超时时间 connectMs
- 传输超时时间 transferMs
- 自动重定向策略（文档提到）
可以配在 rcp.SessionConfiguration.requestConfiguration.transfer 上。

2. 超时字段

复制代码

transfer: {
  timeout: {
    connectMs: number;  // 建连超时（ms）
    transferMs: number; // 整体传输超时（ms）
  }
}

connectMs ：
连接阶段最多等待时间（TCP/TLS）。
transferMs ：
数据传输阶段最大耗时。

3. 超时重试常见套路

利用 TransferConfiguration 配好：
- "多快放弃这次请求？"
在代码层加：
- 重试次数 retryCount
- 当前尝试次数 attempt
- 最后一跳延迟（比如多等 3 秒）

核心伪代码思路：

复制代码

for (attempt from 1 to retryCount) {
  等待必要的 delay;
  发起 HTTP 请求;
  if (成功 && statusCode == 200) break;
}
如果全部失败 → 记录日志 + 返回错误;

4. 设备 & 版本（再强调一次）

支持 Phone / 2in1 / Tablet / Wearable，自 5.1.1(19) 起新增 TV 支持。