网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多开发者第一次做鸿蒙 App 时，对图片加载都有一个共同认知：

Image(url)

不就完了吗？看起来确实如此，因为项目初期：

图片少
用户少
页面简单

一切都很流畅。

但当项目逐渐发展后，很快就会出现各种问题：

首页打开变慢
列表滑动掉帧
内存持续上涨
页面频繁OOM

尤其是：

• 电商 App
• 社交 App
• 内容社区
• 短视频 App

图片往往占据：

60%~90%

以上的流量和内存开销。很多团队最后发现：

性能瓶颈不是业务逻辑，而是图片。

甚至可以说：

图片系统决定了鸿蒙 App 的性能上限。

一、为什么图片会成为性能杀手

很多开发者以为：

图片 = 一个文件

实际上用户看到一张图片时，系统已经经历了：

网络下载
 ↓
磁盘缓存
 ↓
内存缓存
 ↓
图片解码
 ↓
Bitmap创建
 ↓
GPU上传
 ↓
屏幕渲染

整个流程非常重。例如，一张图片：

1080 × 1920

看起来只有：

300KB

但是解码后：

1080 × 1920 × 4
≈ 8MB

因为：

RGBA
每像素4字节

计算过程，1080\times1920\times4\approx8.29\text{MB}，也就是说：

压缩后300KB
解码后8MB

如果首页同时显示：

20张图片

理论占用：

160MB+

内存压力瞬间上来。

二、图片加载链路分析

在大型鸿蒙项目里，图片加载通常会设计成：

ImageView
    ↓
ImageLoader
    ↓
MemoryCache
    ↓
DiskCache
    ↓
Network

完整流程：

请求图片
    ↓
查内存缓存
    ↓
查磁盘缓存
    ↓
网络下载
    ↓
解码
    ↓
写缓存
    ↓
渲染

这样才能保证：

最快速度显示图片

三、最常见问题：重复下载

很多项目最初这样写：

Image(item.imageUrl)

页面进入：

请求一次

退出页面：

释放

再次进入：

再请求一次

结果：

流量浪费
加载变慢
用户体验差

Demo：内存缓存实现

先实现一个简单缓存。

class ImageMemoryCache {

  private cache = new Map<string, PixelMap>()

  get(url: string): PixelMap | undefined {
    return this.cache.get(url)
  }

  put(url: string, pixelMap: PixelMap) {
    this.cache.set(url, pixelMap)
  }
}

使用：

const image = cache.get(url)

if (image) {
  return image
}

缓存命中：

0ms加载

效果非常明显。

四、图片缓存架构设计

真正的线上项目不会只用一级缓存，通常采用：

L1 Memory Cache
       ↓
L2 Disk Cache
       ↓
L3 Network

一级缓存

内存缓存，特点：

速度最快
占用内存

读取：

微秒级

适用于：

当前页面
最近访问页面

二级缓存

磁盘缓存，特点：

速度较快
容量大

适用于：

历史浏览图片

例如：

100MB
200MB
500MB

缓存空间。

三级缓存

网络请求最慢，通常：

50ms
~
500ms

甚至更久。因此：

优秀图片系统会尽量避免触发三级缓存。

五、图片预加载机制

很多 App 会提前加载图片，例如：

用户正在浏览第10条

系统已经开始加载：

11
12
13
14
15

对应图片。

Demo实现

class ImagePreloader {

  preload(urls: string[]) {

    urls.forEach(url => {

      imageLoader.load(url)

    })

  }

}

列表滑动时：

onScrollIndex(index:number){

  preload(
    products.slice(index,index+10)
  )

}

这样用户滑动时：

图片已经在缓存中

几乎秒开。

六、图片尺寸优化

这是最容易被忽略的问题，很多服务端返回：

4000 × 3000

原图，但是客户端显示：

200 × 150

实际上只用了不到 1% 的像素。

错误方案

Image(bigImageUrl)

直接显示。结果：

网络浪费
解码浪费
GPU浪费

正确方案

服务端生成：

thumbnail_200.jpg
thumbnail_400.jpg
thumbnail_800.jpg

客户端根据场景请求：

function getImageUrl(width:number){

   if(width < 300){
      return thumbnail200
   }

   if(width < 600){
      return thumbnail400
   }

   return thumbnail800
}

效果非常明显。

七、列表图片优化

这是性能事故高发区。例如：

商品列表
1000条

很多人直接：

ForEach(products)

然后每个Item：

Image(url)

结果：

同时创建大量Image组件

正确方案

使用：

LazyForEach

List() {

  LazyForEach(
    dataSource,
    (item) => {

      ListItem() {

        ProductCard(item)

      }

    }
  )

}

优势：

只创建可见区域组件

例如：

1000条商品

实际只创建：

10~20个Item

性能差距巨大。

八、图片解码优化

很多开发者忽略了：

下载不是最耗时

真正耗时的是：

图片解码

例如：

JPEG
PNG
WebP

都需要转换成：

Bitmap

才能渲染。

Demo：异步解码

错误：

const bitmap = decode(imageData)

直接在主线程。

正确：

worker.postMessage(imageData)

Worker：

onMessage(data){

   const bitmap = decode(data)

   postMessage(bitmap)

}

主线程：

只负责渲染

不会出现：滑动掉帧的问题。

九、图片懒加载实现

很多页面：

用户根本没看到图片

但图片已经下载，这是巨大的浪费。

Demo实现

if(itemVisible){

   imageLoader.load(url)

}

不可见：

不加载

进入可视区域：

再加载

实现：

按需下载
按需解码
按需渲染

十、图片加载监控系统

大型项目一定要监控，推荐指标：

图片请求次数
缓存命中率
平均下载耗时
平均解码耗时
图片大小
失败率

例如：

Memory Hit
=
85%

说明：

缓存效果很好

如果：

Hit
=
20%

说明：

缓存设计有问题

十一、AI时代的图片系统升级

未来鸿蒙 App 会越来越多接入 AI。例如：

AI生成头像
AI生成海报
AI生成商品图

图片数量会指数增长。

传统：

用户上传
用户浏览

模式变成：

AI实时生成
AI实时缓存
AI实时分发

因此未来图片系统会演化为：

Image Service
      ↓
Cache Center
      ↓
AI Image Pipeline
      ↓
Render Engine

图片不再只是一个资源。而是：

一种实时数据流

十二、本质

如果用一句话总结鸿蒙 App 图片优化：

图片优化不是减少图片，而是减少无效图片处理。

真正优秀的图片架构都会做到：

多级缓存
尺寸适配
懒加载
预加载
异步解码
Worker计算
监控体系

最终形成：

Image Request
      ↓
Memory Cache
      ↓
Disk Cache
      ↓
Network
      ↓
Decode Worker
      ↓
Render

而不是：

Image
 ↓
直接下载
 ↓
直接显示

总结

很多团队优化鸿蒙 App 时，总把精力放在：

接口优化
状态优化
架构优化

但线上项目里最容易被忽略的性能黑洞往往是：

图片系统

记住一句话：

一个不卡的鸿蒙 App，背后一定有一个优秀的图片加载架构。

当你真正建立：

• Memory Cache
• Disk Cache
• Lazy Load
• Preload
• Decode Worker
• Performance Monitor

你会发现：

启动更快
滑动更顺
内存更稳
用户体验提升明显

而这，才是大型鸿蒙 App 图片优化真正的核心。