一、引言

• 电商下单请求超时，用户反复重试；
• 社交消息发送失败，聊天记录丢失；
• 新闻资讯加载缓慢，用户流失。

二、技术背景

1. 鸿蒙网络请求的底层机制

• ​​ArkUI内置HTTP组件​​：通过@ohos.net.http模块实现，支持HTTP/1.1、HTTP/2；
• ​​第三方库​​：如OkHttp（鸿蒙兼容Java/Kotlin库），提供更灵活的拦截器、超时配置。

• 单次超时即请求失败，无重试机会；
• 未压缩的JSON/图片数据传输量大，加剧网络拥堵。

三、应用使用场景

四、核心优化策略实现

（一）超时重试：避免单次失败导致请求终止

1. 鸿蒙原生HTTP组件的超时重试

// 网络请求工具类：HttpRequest.ets
import http from '@ohos.net.http';

export class HttpRequest {
  // 基础请求方法（带超时+重试）
  static async request(url: string, options: http.HttpRequestOptions, retryCount = 3): Promise<http.HttpResponse> {
    let retry = 0;
    while (retry < retryCount) {
      try {
        const response = await http.request(url, {
          method: options.method || 'GET',
          header: options.header || {},
          extraData: options.extraData || null,
          timeout: {
            connectTimeout: 5000, // 连接超时5秒（弱网下缩短，避免长时间等待）
            readTimeout: 10000    // 读取超时10秒（平衡失败率与用户体验）
          }
        });
        return response;
      } catch (error) {
        retry++;
        if (retry >= retryCount) throw error;
        // 指数退避：第一次等1秒，第二次2秒，第三次4秒
        await new Promise(resolve => setTimeout(resolve, 1000 * Math.pow(2, retry - 1)));
      }
    }
  }
}

2. OkHttp拦截器实现重试（推荐）

// OkHttp拦截器：RetryInterceptor.kt
class RetryInterceptor(private val maxRetries: Int = 3) : Interceptor {
  override fun intercept(chain: Interceptor.Chain): Response {
    val request = chain.request()
    var response: Response? = null
    var retryCount = 0
    var exception: IOException? = null

    while (retryCount < maxRetries) {
      try {
        response = chain.proceed(request)
        // 若响应成功（状态码200-299），直接返回
        if (response.isSuccessful) return response
      } catch (e: IOException) {
        exception = e
      }
      // 指数退避
      Thread.sleep(1000 * Math.pow(2, retryCount).toLong())
      retryCount++
    }

    throw exception ?: IOException("Unknown error")
  }
}

// 鸿蒙中集成OkHttp：在build.gradle中添加依赖
dependencies {
  implementation 'com.squareup.okhttp3:okhttp:4.9.3'
}

• ​​超时时间​​：弱网下连接超时设为5秒（默认10秒），避免长时间等待；
• ​​重试次数​​：3-5次（过多会增加服务器压力）；
• ​​指数退避​​：避免连续重试导致服务器拥堵。

（二）数据压缩：减少传输量，降低延迟

1. 请求压缩：客户端发送Gzip数据

// 使用OkHttp发送压缩请求
val client = OkHttpClient.Builder()
  .addInterceptor(RetryInterceptor())
  .build()

fun sendCompressedRequest(url: String, json: String): Response {
  val requestBody = RequestBody.create(
    MediaType.parse("application/json; charset=utf-8"),
    gzipCompress(json) // 自定义Gzip压缩方法
  )
  val request = Request.Builder()
    .url(url)
    .post(requestBody)
    .header("Content-Encoding", "gzip") // 告知服务器请求体是Gzip压缩
    .build()
  return client.newCall(request).execute()
}

// Gzip压缩工具方法
fun gzipCompress(data: String): ByteArray {
  val outputStream = ByteArrayOutputStream()
  val gzipOutputStream = GZIPOutputStream(outputStream)
  gzipOutputStream.write(data.toByteArray(Charsets.UTF_8))
  gzipOutputStream.close()
  return outputStream.toByteArray()
}

2. 响应压缩：客户端解压Gzip数据

// OkHttp自动处理响应压缩（默认支持）
val client = OkHttpClient.Builder()
  .addInterceptor(RetryInterceptor())
  .build()

// 发送请求并解压响应
val response = client.newCall(request).execute()
val responseBody = response.body?.string() // 自动解压Gzip

3. 鸿蒙原生HTTP组件的压缩配置

export class HttpRequest {
  static async request(url: string, options: http.HttpRequestOptions): Promise<http.HttpResponse> {
    const headers = {
      ...options.header,
      'Accept-Encoding': 'gzip' // 告知服务器支持Gzip压缩
    };
    return await http.request(url, {
      ...options,
      header: headers
    });
  }
}

• ​​压缩格式​​：优先使用Gzip（兼容性好，压缩率高）；
• ​​请求头​​：必须添加Content-Encoding: gzip（发送压缩请求）和Accept-Encoding: gzip（接收压缩响应）；
• ​​服务器配合​​：需后端支持Gzip压缩（如Nginx开启gzip on;）。

五、原理解释与流程图

1. 超时重试原理流程图

sequenceDiagram
    participant Client as 客户端
    participant Server as 服务器
    participant Retry as 重试机制
    
    Client->>Server: 发送请求（超时5秒）
    alt 请求成功
        Server->>Client: 返回200 OK
    else 请求超时/失败
        Retry->>Client: 触发重试（指数退避）
        Client->>Server: 重新发送请求
        alt 重试成功
            Server->>Client: 返回200 OK
        else 重试失败（达到最大次数）
            Client->>Client: 抛出错误
        end
    end

2. 数据压缩原理流程图

sequenceDiagram
    participant Client as 客户端
    participant Server as 服务器
    
    Client->>Server: 发送请求（Header: Accept-Encoding: gzip）
    Server->>Server: 压缩响应数据（Gzip）
    Server->>Client: 返回压缩响应（Header: Content-Encoding: gzip）
    Client->>Client: 解压响应数据
    Client->>Client: 处理解压后的数据

六、环境准备

1. 开发环境

• ​​工具​​：DevEco Studio 4.0+（鸿蒙应用开发官方IDE）；
• ​​SDK​​：HarmonyOS SDK 4.0+（支持ArkUI 3.0+）；
• ​​依赖​​：
  • OkHttp（可选，用于更灵活的拦截器）：implementation 'com.squareup.okhttp3:okhttp:4.9.3'；
  • Gzip工具类（可选，用于自定义压缩）。

2. 后端配合

• 开启Gzip压缩：Nginx配置gzip on; gzip_types text/plain application/json;；
• 支持压缩请求：后端需解析Content-Encoding: gzip的请求体。

七、测试与效果验证

1. 模拟弱网环境

1. 打开DevEco Studio → 运行应用 → 点击顶部菜单栏​​Tools​​ → ​​Device Manager​​；
2. 选择目标设备 → 点击​​Network​​ → 设置​​Bandwidth​​（带宽）为1 Mbps，​​Latency​​（延迟）为500 ms。

2. 测试结果

• 下单请求成功率：65%（弱网3G）；
• 加载时间：8秒（新闻列表）；
• 流量消耗：1.2 MB（新闻列表JSON）。

• 下单请求成功率：98%；
• 加载时间：3秒（新闻列表）；
• 流量消耗：300 KB（新闻列表JSON）。

八、部署场景

九、疑难解答

Q1：重试会导致重复提交订单吗？

Q2：Gzip压缩会增加客户端CPU消耗吗？

Q3：弱网下压缩效果不佳怎么办？

• 调整压缩级别：OkHttp默认压缩级别是6（平衡速度与压缩率），可设为9（更高压缩率，但CPU消耗大）；
• 针对小数据（如<1KB）不压缩：避免压缩开销大于传输收益。

Q4：鸿蒙原生HTTP组件支持重试吗？

十、未来展望与技术趋势

1. 技术趋势

• ​​AI预测网络状态​​：通过机器学习预测弱网环境，动态调整超时时间和重试次数；
• ​​自适应压缩​​：根据网络带宽自动选择压缩算法（如弱网下用Gzip，强网下用Zstandard）；
• ​​HTTP/3支持​​：鸿蒙未来可能支持HTTP/3（QUIC协议），天生具备弱网抗丢包能力。

2. 挑战

• ​​服务器兼容性​​：老旧服务器可能不支持Gzip或HTTP/2；
• ​​数据一致性​​：重试可能导致重复请求，需业务层保证幂等；
• ​​性能平衡​​：压缩和重试会增加客户端和服务器的负载，需找到最优配置。

十一、总结

1. ​​超时重试​​：通过合理的超时时间和指数退避，应对临时网络波动，提升请求成功率；
2. ​​数据压缩​​：减少传输量，降低延迟，缓解弱网带宽压力。

• 所有网络请求都配置超时（5-10秒）和重试（3-5次）；
• 所有JSON响应都开启Gzip压缩；
• 业务层做幂等性处理，避免重试导致重复操作；
• 定期模拟弱网环境测试，确保优化效果。