HarmonyOS鸿蒙Next中为什么APP使用curl下载会比Android APP使用curl下载的速度慢?

HarmonyOS鸿蒙Next中为什么APP使用curl下载会比Android APP使用curl下载的速度慢? 写了两个相同的APP,一个鸿蒙版本、一个Android版本。

功能都是使用curl.so去执行FTP下载,下载的链接也是同一个。

在同样的华为手机上,鸿蒙APP下载速度比Android APP(通过卓易通安装)的下载速度低了200mbps左右。

有大佬知道这个原因么?

9 回复

尊敬的开发者,您好,您使用curl三方库下载文件,性能会与官网@ohos.request (上传下载)方法有所差异,您可以参考官方示例:应用文件上传下载-上传下载-Basic Services Kit(基础服务)-基础功能-系统 - 华为HarmonyOS开发者实现下载文件功能。如果还是不能解决您的问题,麻烦您提供如下信息吧:

  1. 麻烦您提供下最小可复现demo;
  2. 版本信息(如:模拟器版本信息、手机系统版本信息);
  3. 麻烦您提供下日志信息吧;

更多关于HarmonyOS鸿蒙Next中为什么APP使用curl下载会比Android APP使用curl下载的速度慢?的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


您好,附件是Curl Log,下载的是同一个文件:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/15.1/FreeBSD-15.1-RC2-amd64-dvd1.iso.xz

麻烦帮忙看下,如果需要提交工单,请告诉我

尊敬的开发者,您好,

当前日志文件仅能观察两者之前的下载速度差异,无法判断原因。需要您这边确认以下几点:

1)使用的curl.so是如何编译的? 2)编译产物是否是release包,是否开启了编译优化?

下载大文件的场景,建议开发者您使用@hadss/super_fast_file_trans ,可对比不同方案下的下载速度选择最优方案。

同一 curl 代码在 HarmonyOS/Android 速度不同,建议先排除变量:curl/libssl 版本、编译参数、CPU ABI、线程数、buffer、FTP 主被动模式、网络权限与后台限速。HarmonyOS NDK 下也建议用 Profiler/抓包对比耗时点,确认慢在 DNS、握手、读写还是磁盘落盘,不能只看最终速率下结论。

这个原因多方面的,而且你用的是三方库curl.so

Android:直接dlopen,共享库内存空间、线程调度优先级高。

鸿蒙:必须用NDK/ohos.toolchain编译,否则存在指令翻译 、兼容性层开销。

三方.so 线程默认优先级低于 ArkUI 主线程 / 系统服务,大文件下载时 CPU / 网络资源被抢占。

鸿蒙对非系统 APP 的 FD(文件描述符)数量、缓冲区大小有限制,curl 的大缓冲区 / 多连接策略被压制。

系统省电和流量管理策略也可能不同的

鸿蒙默认开启智能省流量 ,后台网络限制,即使前台,对非系统 APP 的长连接,大流量任务也会动态降速

安卓通常默认关闭 / 限制更松,不主动节流。

明白了,谢谢

curl毕竟是第三方库封装的第三方框架。性能不可控是必然的。

优先推荐鸿蒙的官方api网络框架:

Network Kit(网络服务)

https://developer.huawei.com/consumer/cn/doc/harmonyos-references/network-api

Remote Communication Kit(远场通信服务)https://developer.huawei.com/consumer/cn/doc/harmonyos-references/remote-communication-api

HarmonyOS Next 的 curl 实现可能未完全适配 ArkTS 原生网络栈,导致数据拷贝或线程调度开销较大。此外,鸿蒙的网络权限管理更严格,SSL/TLS 握手过程可能额外消耗时间。建议直接使用 HarmonyOS 的 HTTP 请求 API(如 http.request)以获得优化性能。

鸿蒙Next与Android的网络协议栈实现不同,鸿蒙Next自研的软总线及协议栈对FTP这类长连接传输的优化可能尚未达到Android Linux内核的成熟度,尤其TCP拥塞控制算法、窗口缩放及缓冲区大小可能更保守,直接影响大流量下载吞吐。

同时,鸿蒙Next应用网络访问可能经过系统级策略代理或额外的安全审查层,引入处理时延和握手开销,而Android APK(通过卓易通运行)仍复用了底层原生Linux网络栈,无此类中间损耗。

另外,两个环境使用的curl.so编译配置、TLS/SSL版本或内部I/O模式(如是否启用大缓冲、多线程解析)可能存在差异,也会造成速度差距。

回到顶部