鸿蒙App弱网适配（超时重试/数据压缩策略）

一、引言与技术背景

1. 提高可用性 (Availability)：在网络异常时，应用不应完全瘫痪，而应能优雅地处理错误，并提供重试机制。
2. 提升响应性 (Responsiveness)：通过减少单次请求的数据量，缩短请求时间，让用户在弱网下也能尽快看到内容。
3. 增强鲁棒性 (Robustness)：应用应能抵御网络抖动、延迟和中断，具备自我恢复和数据完整性校验的能力。

二、核心概念与原理

1. 超时重试 (Timeout & Retry)

• 超时 (Timeout)：
  • 连接超时 (Connect Timeout)：客户端与服务器建立TCP连接的最大等待时间。在弱网下，这个值应设置得相对宽松一些。
  • 读取超时 (Read Timeout)：客户端等待服务器返回数据的最大时间间隔。如果服务器处理请求很慢，这个超时也会触发。
• 重试 (Retry)：
  • 重试条件：并非所有失败都应重试。通常只对幂等性的、因网络问题导致的失败（如超时、连接拒绝）进行重试。对于业务逻辑错误（如 400 Bad Request, 401 Unauthorized）则不应重试。
  • 退避策略 (Backoff Strategy)：为了避免因短时间内大量重试请求压垮本已脆弱的网络或服务，通常采用指数退避 (Exponential Backoff)​ 算法。即每次重试的间隔时间呈指数级增长（如 1s, 2s, 4s, 8s...），并加入一个随机因子（Jitter）防止多个客户端同时重试造成“惊群效应”。
  • 重试次数：设定一个最大重试次数，防止无限重试耗尽资源。

2. 数据压缩 (Data Compression)

• 请求压缩 (Request Compression)：客户端在向服务器发送数据前，先对其进行压缩（如对POST请求的Body使用GZIP），服务器收到后再解压。适用于客户端向服务器上传大量数据的场景。
• 响应压缩 (Response Compression)：服务器在返回数据前，对响应体进行压缩，客户端在收到后进行解压。这是更常见的场景，例如获取列表数据、文章详情等。
• 压缩算法：
  • GZIP：最常用、兼容性最好的压缩算法，对文本数据（JSON, XML, HTML）压缩效果显著。
  • Brotli：比 GZIP 压缩率更高、速度更快的新一代算法，但需要服务端和客户端的共同支持。
  • Protocol Buffers (Protobuf)：一种二进制的、结构化的数据序列化格式。与JSON/XML等文本格式相比，它本身就具有更小的体积和更快的编解码速度，是弱网环境下数据传输的绝佳选择。

3. 原理流程图

[发起网络请求]
      |
      V
{请求成功?}
      |-- Yes --> [处理响应数据]
      |
      |-- No --> {是否为可重试错误? (e.g., Timeout)}
                |-- No --> [结束，抛出业务错误]
                |
                |-- Yes --> {重试次数 < 最大次数?}
                            |-- No --> [结束，抛出网络错误]
                            |
                            |-- Yes --> [计算等待时间: base * 2^retry_count + jitter]
                                        |
                                        V
                                    [等待指定时间]
                                        |
                                        V
                                    [重新发起请求] --> (循环)

[Client Request]
      |
      |-- Header: Accept-Encoding: gzip
      V
[Server Processing]
      |
      |-- Header: Content-Encoding: gzip
      |-- Body: (gzip_compressed_data)
      V
[Client Receives Response]
      |
      |-- Checks Header: Content-Encoding: gzip
      |-- Decompresses Body using GZIP library
      |
      V
[Process Decompressed Data]

三、应用使用场景

• 所有需要网络请求的页面：这是网络优化的通用需求。
• 电商App的商品列表/详情：快速加载商品信息是核心体验。
• 社交App的消息列表/Feed流：保证消息的及时性和连续性。
• 新闻阅读App：快速加载文章内容，节省用户流量。
• 文件上传/下载功能：在网络不稳定时保证任务的可靠性。

四、环境准备

• DevEco Studio：最新版本。
• 真机：用于模拟不同网络环境（可通过系统设置限速）。
• 测试服务器：一个可以自定义响应头和状态码的简单后端服务，用于模拟超时和验证压缩。如果没有，可以简单地在本地搭建一个HTTP服务器或使用在线API测试工具。
• 待优化Demo：一个简单的应用，包含一个按钮触发网络请求，并将结果显示在UI上。

五、不同场景的代码实现

场景一：实现健壮的超时与重试机制

import http from '@ohos.net.http';
import { BusinessError } from '@ohos.base';

// 定义请求配置接口
interface RequestConfig {
  url: string;
  method?: http.RequestMethod;
  extraData?: string | Object | ArrayBuffer;
  header?: Object;
  connectTimeout?: number;
  readTimeout?: number;
  retryTimes?: number; // 最大重试次数
  backoffBase?: number; // 退避基数 (ms)
}

// 定义响应接口
interface HttpResponse {
  responseCode: number;
  result: string | Object;
  header: Object;
}

export class NetworkRequestUtil {
  // 默认配置
  private static readonly DEFAULT_CONFIG = {
    method: http.RequestMethod.GET,
    connectTimeout: 10000, // 10秒连接超时
    readTimeout: 15000,    // 15秒读取超时
    retryTimes: 3,         // 默认重试3次
    backoffBase: 1000      // 退避基数1秒
  };

  /**
   * 发起一个带有超时和重试机制的HTTP GET请求
   * @param config 请求配置
   * @returns Promise<HttpResponse>
   */
  public static async getWithRetry(config: RequestConfig): Promise<HttpResponse> {
    const finalConfig = { ...this.DEFAULT_CONFIG, ...config };
    let lastError: BusinessError | null = null;

    for (let attempt = 0; attempt <= finalConfig.retryTimes; attempt++) {
      try {
        console.log(`Attempt ${attempt + 1} for URL: ${finalConfig.url}`);
        
        let httpRequest = http.createHttp();
        
        // 发起请求
        const promise = httpRequest.request(
          finalConfig.url,
          {
            method: finalConfig.method,
            extraData: finalConfig.extraData,
            header: finalConfig.header,
            connectTimeout: finalConfig.connectTimeout,
            readTimeout: finalConfig.readTimeout,
          }
        );

        // 使用Promise.race实现超时控制 (虽然http模块有自己的timeout，但这里演示自定义控制)
        // 注意：http模块自身的timeout更直接，这里用race是为了展示通用模式
        const response = await promise;
        
        // 清理httpRequest
        httpRequest.destroy();

        // 检查响应码
        if (response.responseCode >= 200 && response.responseCode < 300) {
          console.log(`Request succeeded on attempt ${attempt + 1}`);
          return {
            responseCode: response.responseCode,
            result: response.result,
            header: response.header
          };
        } else {
          // 非2xx的成功响应，认为是业务逻辑错误，不进行重试
          console.error(`Business error, status code: ${response.responseCode}. Not retrying.`);
          throw new Error(`Business error: ${response.responseCode}`);
        }

      } catch (error) {
        lastError = error as BusinessError;
        console.error(`Attempt ${attempt + 1} failed: ${lastError.message}`);

        // 如果是最后一次尝试，或者错误不可重试，则抛出错误
        if (attempt === finalConfig.retryTimes || !this.isRetryable(error)) {
          break;
        }

        // 计算退避时间 (指数退避 + 随机抖动)
        const backoffTime = finalConfig.backoffBase * Math.pow(2, attempt) + Math.random() * 500;
        console.log(`Retrying in ${backoffTime.toFixed(0)} ms...`);
        await this.delay(backoffTime);
      }
    }

    // 所有重试均失败
    console.error('All retry attempts failed.');
    throw lastError || new Error('Request failed after all retries');
  }

  /**
   * 判断一个错误是否值得重试
   * @param error BusinessError
   * @returns boolean
   */
  private static isRetryable(error: BusinessError): boolean {
    // 可以根据error.code或message来判断
    // 例如，连接超时、读取超时、网络不可达等通常是可重试的
    // 这里简单示例，实际项目中需要更精细的判断
    if (error.code) {
        // http模块的错误码，例如 2300008 为连接超时
        // 具体错误码请参考官方文档
        console.log(`Error code: ${error.code}`);
    }
    // 简单起见，我们假设所有错误都可重试，但实际应避免重试4xx错误
    return true; 
  }

  /**
   * 延迟函数
   * @param ms 毫秒
   * @returns Promise<void>
   */
  private static delay(ms: number): Promise<void> {
    return new Promise(resolve => setTimeout(resolve, ms));
  }
}

场景二：实现响应数据压缩 (GZIP)

import util from '@ohos.util';

// 注意：鸿蒙ARKTS环境中，标准gzip解压需要调用native能力或通过worker+第三方wasm库实现。
// 这里我们用一个伪代码/模拟的方式来展示逻辑。
// 真实项目中，请寻找合适的gzip库或确认系统API。
export class GzipUtils {
  /**
   * 模拟GZIP解压
   * @param compressedData ArrayBuffer
   * @returns string
   */
  public static async decompress(compressedData: ArrayBuffer): Promise<string> {
    // 在实际项目中，这里会是类似这样的调用:
    // let inflater = new util.Inflater();
    // inflater.setInput(compressedData);
    // let result = inflater.getOutput();
    // inflater.close();
    // return new TextDecoder().decode(result);

    // 此处仅为演示，假设我们接收到的是一个字符串
    console.log('Decompressing data... (simulation)');
    // 为了模拟，我们直接返回原始数据
    // 真实情况会复杂得多
    return "Decompressed data result.";
  }

  /**
   * 检查响应头是否需要解压
   * @param headers Object
   * @returns boolean
   */
  public static shouldDecompress(headers: Object): boolean {
    const contentType = (headers as Record<string, string>)['content-encoding'];
    return contentType?.toLowerCase().includes('gzip');
  }
}

import { NetworkRequestUtil } from '../utils/NetworkRequestUtil';
import { GzipUtils } from '../utils/GzipUtils';

@Entry
@Component
struct WeakNetDemoPage {
  @State responseText: string = 'Click the button to send request';
  @State isLoading: boolean = false;

  build() {
    Column() {
      Button(this.isLoading ? 'Loading...' : 'Fetch Data')
        .enabled(!this.isLoading)
        .onClick(() => {
          this.sendRequest();
        })
        .margin(20)
        .width(200)

      Scroll() {
        Text(this.responseText)
          .fontSize(16)
          .textAlign(TextAlign.Start)
          .width('90%')
      }
      .layoutWeight(1)
      .width('100%')

    }
    .height('100%')
    .width('100%')
  }

  async sendRequest() {
    this.isLoading = true;
    this.responseText = 'Requesting...';

    try {
      // 假设这个URL会返回gzip压缩的数据，并且在弱网下可能超时
      const config: NetworkRequestUtil.RequestConfig = {
        url: 'https://api.example.com/data', // 替换为你的测试URL
        header: {
          'Accept': 'application/json',
          'Accept-Encoding': 'gzip' // 告诉服务器客户端支持gzip
        },
        connectTimeout: 8000, // 弱网下可以适当放宽超时
        readTimeout: 12000,
        retryTimes: 2
      };

      const response = await NetworkRequestUtil.getWithRetry(config);

      let resultData: string | Object = response.result;

      // 检查并解压GZIP响应
      if (GzipUtils.shouldDecompress(response.header)) {
        console.log('Response is gzipped, decompressing...');
        if (typeof resultData === 'object' && (resultData as ArrayBuffer)) {
            resultData = await GzipUtils.decompress(resultData as ArrayBuffer);
        } else {
            console.warn('Gzip response was not ArrayBuffer, cannot decompress.');
        }
      }
      
      this.responseText = `Success!\nCode: ${response.responseCode}\nData: ${JSON.stringify(resultData)}`;

    } catch (error) {
      console.error('Request failed:', error);
      this.responseText = `Failed: ${(error as Error).message}`;
    } finally {
      this.isLoading = false;
    }
  }
}

1. 寻找社区库：查找是否有开源的、适用于鸿蒙的 GZIP/TAR 解压库。
2. 使用 Native API：通过 N-API 或 Node-API 调用底层 C++ 的解压库。
3. Worker + WASM：在 Worker 线程中加载一个 WASM 格式的压缩库来执行解压，避免阻塞UI线程。

六、运行结果与测试步骤

1. 部署与基础测试：
   • 将代码部署到真机。
   • 在良好的Wi-Fi环境下点击按钮，验证请求是否能正常发出并返回结果。
2. 模拟弱网与超时测试：
   • 进入手机 设置 -> 开发者选项 -> 网络速度模拟​ (不同手机路径可能不同)。
   • 设置一个较低的下行/上行速率和较高的延迟（如 100kbps, 500ms latency）。
   • 再次点击按钮发起请求。观察 Log，你应该能看到重试的日志输出，并最终（在重试次数内）成功或失败。
   • 将超时时间设置得非常短（如 connectTimeout: 1000），然后断网，观察是否会按预期进行重试后报错。
3. 验证压缩效果 (需要服务端配合)：
   • 使用一个已知的、会返回 Content-Encoding: gzip头的API进行测试。
   • 在 sendRequest方法的 header中加入 'Accept-Encoding': 'gzip'。
   • 在收到响应后，检查 response.header中是否包含 'content-encoding': 'gzip'。
   • 如果 GzipUtils实现了真实的解压逻辑，验证 resultData是否被正确解压为人类可读的格式。

• 在弱网下，应用不再因单次请求超时而无响应，而是通过重试提高了请求成功率。
• 通过使用压缩，单次请求从服务器拿到回执的时间显著缩短，提升了用户感知速度。

七、部署场景与疑难解答

部署场景

• 所有网络请求层：应将超时重试和压缩逻辑封装在统一的网络层，供所有业务模块调用。
• 针对不同网络状况的动态调整：在应用中监听网络状态变化（@ohos.net.connection），在检测到网络变差时，可以动态调整重试策略和请求频率。

疑难解答

1. 问题：重试导致了重复提交（例如，支付订单）。
   • 原因：对非幂等的请求进行了重试。
   • 解决：严格区分幂等和非幂等操作。对于支付、创建订单等，应在请求中携带唯一的 requestId，服务器端根据该ID进行去重，客户端在收到特定错误码（如“订单已创建”）时，直接跳转到结果页而非报错。
2. 问题：指数退避导致用户等待时间过长。
   • 原因：最大重试次数或退避基数设置过大。
   • 解决：根据业务场景调整。对于用户主动触发的操作（如刷新），可以设置较小的重试次数和较快的退避策略。对于后台静默同步，可以设置更激进的策略。可以提供UI反馈，告知用户“网络不佳，正在努力重试...”。
3. 问题：找不到合适的GZIP库。
   • 解决：优先考虑与服务端协商，看是否能接受 Protobuf 等本身就很小巧的数据格式。如果必须用GZIP，评估引入 WASM 方案的复杂度和包体积影响。在某些情况下，放弃客户端解压，要求服务端直接返回未压缩数据也是一种权衡。

八、未来展望与技术趋势

• HTTP/3 与 QUIC 协议：这些新一代协议天生为弱网环境设计，解决了TCP的队头阻塞问题，具有更快的连接建立速度（0-RTT）和更好的拥塞控制，将从根本上改善网络体验。
• AI 驱动的网络适配：应用可以集成更智能的网络库，实时分析RTT、丢包率等指标，动态选择最优的服务器节点、数据压缩算法和请求策略。
• 边缘计算 (Edge Computing)：将计算和数据处理能力下沉到离用户更近的边缘节点，可以极大缩短数据传输的物理距离，是应对弱网最根本的解决方案之一。
• 更完善的内置API：期待鸿蒙SDK未来能提供更易用、更强大的内置网络诊断、压缩/解压API，降低开发者的使用门槛。

九、总结