【鸿蒙心迹】图像超分在鸿蒙端的落地尝试：从模型选型到推理加速

摘要：本文记录了把图像超分模型从 PC 搬到鸿蒙手机的完整过程。先讲清超分与普通插值放大的本质差异，再拆解端侧推理的模型架构、框架选型（ONNX Runtime / NNAPI / MindSpore Lite）与性能瓶颈分布，最后给出鸿蒙端 2x 超分的五步实战：模型压缩（23→6 残差块、64→32 通道、FP32→INT8，64MB 压到 4MB）、NAPI 集成 ONNX Runtime、NCHW 预处理、128×128 分块加 16 像素 overlap 推理拼接、反归一化输出。同时总结 INT8 量化、NPU 加速、异步流水线三类优化手段，以及算子不支持、OOM、拼接接缝三个典型坑的排查方案。

手机拍出来的照片放大就糊，这是所有人都遇到过的问题。图像超分辨率（Super Resolution）技术能把低分辨率图片放大为高分辨率，同时恢复细节。在PC上这已经不是新鲜事，但在手机端实时跑超分模型，直到最近两年才真正可行。鸿蒙端能不能做？怎么做？性能够不够？这篇就是我把超分模型从PC搬到鸿蒙手机的完整记录。

如果你对AI图像处理感兴趣，想在鸿蒙端实现图像超分功能，但对端侧推理框架和模型优化不熟悉，这篇适合你。读完后你会掌握：超分的基本原理、端侧推理框架的选型、性能优化的关键手段。

本文分三层：第一层建立超分技术的整体认知；第二层拆解端侧推理的原理和瓶颈；第三层是完整的落地实战和性能调优。

入门认知：图像超分到底"超"了什么

一句话定义

图像超分辨率是用算法把低分辨率图片放大为高分辨率图片，同时恢复丢失的纹理细节——不是简单的插值放大，而是"脑补"出原本应该存在的细节。

打个比方：普通放大就像用放大镜看一张模糊的照片——越大越糊，因为信息就那么多。超分就像一个画家看着模糊照片，凭经验"重新画"出清晰版本——他不是在放大原图，而是在创造原图可能包含的细节。

超分 vs 普通放大

对比维度	双线性插值	超分辨率
原理	按比例计算中间像素值	用AI模型预测缺失细节
放大效果	平滑但模糊	清晰有纹理
计算量	极低	高（需神经网络推理）
处理速度	毫秒级	秒级（端侧）
适用场景	快速预览缩略图	照片增强、视频提升

表1：普通插值放大与超分的核心差异

全景图示

图1：图像超分在端侧的完整处理链路

适用边界

超分适合：照片放大增强、老照片修复、低分辨率视频提升。不适合：实时视频流（端侧算力不够）、已经高分辨率的图片（再超分收益极小）、文字/线稿类图片（超分模型主要针对自然图像训练）。

进阶原理：端侧推理的机制与瓶颈

超分模型的基本架构

主流超分模型（ESRGAN、Real-ESRGAN、EDSR等）的核心架构：

输入图 → 特征提取(卷积层) → 残差块 × N → 上采样(像素重组) → 输出图

关键参数：

• 残差块数量：越多效果越好但越慢，端侧通常用4-8个
• 上采样倍数：2x/4x最常用，4x以上端侧很难实时
• 特征通道数：64通道是端侧可接受的极限，PC端常用128-256

端侧推理框架选型

框架	优势	劣势	鸿蒙支持
ONNX Runtime	通用性好，模型格式标准	CPU推理较慢	支持
NNAPI	系统级加速，可调用NPU	模型需转换，兼容性参差	部分支持
MindSpore Lite	华为自研，NPU加速最好	模型需从MindSpore格式转换	原生支持

表2：三种端侧推理框架对比

[提示] 如果你的目标设备是华为自家芯片（麒麟系列），MindSpore Lite + NPU是最优组合——推理速度比ONNX Runtime快3-5倍。如果需要跨厂商兼容，ONNX Runtime更稳妥。

性能瓶颈在哪里？

端侧超分的性能瓶颈分布：

瓶颈环节	占总耗时比例	优化方向
模型推理	60-70%	模型压缩、量化、NPU加速
图像预处理	15-20%	减少裁剪次数、用GPU做归一化
图像后处理	10-15%	减少拼接操作、直接输出目标尺寸
内存拷贝	5-10%	减少数据格式转换、用零拷贝接口

表3：端侧超分性能瓶颈分布

常见误区

误区1：直接把PC端模型丢到手机上跑

PC端ESRGAN模型有23个残差块、64通道，在RTX 3080上推理1张图约0.3秒。同样的模型在手机CPU上推理需要30-60秒——完全不可用。端侧必须做模型压缩。

误区2：模型越小越好

过度压缩模型会导致超分效果严重退化——放大后的图片虽然不糊了，但纹理细节全是"假"的（模型脑补出错误纹理）。要在速度和质量之间找平衡点。

高级应用：在鸿蒙端实现2x超分

实战步骤

第一步：模型准备与压缩

从PC端ESRGAN模型出发，做以下压缩：

1. 减少残差块：23 → 6个
2. 减少特征通道：64 → 32
3. 知识蒸馏：用大模型教小模型
4. 量化：FP32 → INT8

压缩后模型大小从约64MB降到约4MB，推理速度提升10倍以上。

将压缩后的模型导出为ONNX格式：

# PyTorch导出ONNX
dummy_input = torch.randn(1, 3, 64, 64)
torch.onnx.export(
    model, dummy_input, "esrgan_lite.onnx",
    input_names=["input"], output_names=["output"],
    opset_version=11
)

第二步：在鸿蒙中集成ONNX Runtime

通过NAPI集成ONNX Runtime的C++库（参考本系列第5篇文章的NAPI集成方法）：

import ort from 'libonnxruntime.so'

async function superResolve(inputImage: PixelMap): Promise<PixelMap> {
  // 创建推理会话
  const session = await ort.InferenceSession.create({
    modelPath: 'esrgan_lite.onnx',
    executionMode: 'sequential'
  })

  // 预处理：把PixelMap转为模型输入张量
  const inputTensor = await preprocessImage(inputImage)

  // 推理
  const outputs = await session.run({ input: inputTensor })

  // 后处理：把输出张量转回PixelMap
  const outputImage = await postprocessImage(outputs.output)
  return outputImage
}

第三步：图像预处理

超分模型通常只能处理小尺寸输入（如64x64或128x128），大图需要裁剪成小块分别处理：

async function preprocessImage(image: PixelMap): Promise<ort.Tensor> {
  const width = image.width
  const height = image.height
  const tileSize = 128  // 每块128x128

  // 如果图片大于tileSize，需要分块处理
  if (width > tileSize || height > tileSize) {
    // 裁剪为多个128x128小块
    const tiles = splitIntoTiles(image, tileSize)
    // 逐块推理后拼接
    return processTiles(tiles, tileSize)
  }

  // 小图直接处理
  const pixels = await image.readPixels()
  // 归一化到[0,1]，转为NCHW格式
  const floatData = new Float32Array(3 * width * height)
  for (let i = 0; i < width * height; i++) {
    floatData[i] = pixels[i * 4] / 255.0           // R
    floatData[width * height + i] = pixels[i * 4 + 1] / 255.0  // G
    floatData[2 * width * height + i] = pixels[i * 4 + 2] / 255.0  // B
  }

  return new ort.Tensor('float32', floatData, [1, 3, height, width])
}

[注意] NCHW格式（Batch-Channel-Height-Width）是大多数AI模型的标准输入格式。ArkTS的PixelMap是HWC格式（Height-Width-Channel），必须转换。

第四步：分块推理与拼接

大图分块处理时，块与块之间需要重叠（overlap），否则拼接处会有明显接缝：

const tileSize = 128
const overlap = 16  // 重叠16像素

function splitIntoTiles(image: PixelMap, tileSize: number): Tile[] {
  const tiles: Tile[] = []
  for (let y = 0; y < image.height; y += tileSize - overlap) {
    for (let x = 0; x < image.width; x += tileSize - overlap) {
      tiles.push({
        x, y,
        width: Math.min(tileSize, image.width - x),
        height: Math.min(tileSize, image.height - y),
        data: cropRegion(image, x, y, tileSize, tileSize)
      })
    }
  }
  return tiles
}

[坑] overlap太小会导致拼接接缝明显，太大会导致计算量暴增（重叠区域被重复计算）。16像素是2x超分的经验值，4x超分建议32像素。

第五步：后处理与输出

async function postprocessImage(tensor: ort.Tensor): Promise<PixelMap> {
  const data = tensor.data as Float32Array
  const [_, channels, height, width] = tensor.dims

  // 反归一化：[0,1] → [0,255]
  const pixels = new Uint8Array(width * height * 4)
  for (let i = 0; i < width * height; i++) {
    pixels[i * 4] = Math.min(255, Math.max(0, data[i] * 255))           // R
    pixels[i * 4 + 1] = Math.min(255, Math.max(0, data[width * height + i] * 255))  // G
    pixels[i * 4 + 2] = Math.min(255, Math.max(0, data[2 * width * height + i] * 255))  // B
    pixels[i * 4 + 3] = 255  // Alpha
  }

  // 创建输出PixelMap
  const opts: image.PixelMapOpts = {
    width, height, data: pixels.buffer
  }
  return image.createPixelMap(opts)
}

性能优化

优化1：INT8量化

将模型从FP32量化为INT8，推理速度提升2-3倍，精度损失约1-3%：

# 量化脚本
from onnxruntime.quantization import quantize_dynamic, QuantType
quantize_dynamic("esrgan_lite.onnx", "esrgan_lite_int8.onnx",
                 weight_type=QuantType.QUInt8)

优化2：NPU加速（华为设备）

在支持NPU的华为设备上，用MindSpore Lite替代ONNX Runtime：

import mindspore from 'libmindspore_lite.so'

async function superResolveNPU(inputImage: PixelMap): Promise<PixelMap> {
  const context = new mindspore.Context()
  context.target = ['npu', 'cpu']  // 优先NPU，回退CPU
  const session = await mindspore.InferenceSession.create({
    modelPath: 'esrgan_lite.ms',  // MindSpore格式模型
    context: context
  })
  // ...推理流程类似
}

优化3：异步流水线

把预处理、推理、后处理放到流水线中并行执行：

// 第一块在推理时，第二块在做预处理，第三块在做后处理
async function pipelineProcess(tiles: Tile[]) {
  const results: Promise<PixelMap>[] = []
  for (const tile of tiles) {
    results.push(processTile(tile))
  }
  return Promise.all(results)
}

踩坑排错

坑1：ONNX Runtime在鸿蒙上不支持某些算子

现象：创建推理会话时报 “unsupported operator” 错误。

原因：ONNX Runtime的鸿蒙版本算子覆盖不全，部分PC端常用算子（如PixelShuffle）不支持。

解决：用ONNX的算子简化工具把不支持的算子替换为等价的基础算子组合：

import onnxsim
model_simplified, ok = onnxsim.simplify(model)

坑2：内存溢出（OOM）

现象：处理大图时应用崩溃，日志显示内存不足。

原因：分块推理时所有tile数据同时加载到内存。

解决：限制同时处理的tile数量，用队列串行处理：

const MAX_CONCURRENT = 2  // 同时最多2块在处理

坑3：拼接接缝明显

现象：超分后的图片能看到网格状接缝。

原因：overlap区域处理不当，块边缘像素突变。

解决：在拼接时对overlap区域做线性融合（渐变过渡），而非直接替换：

function blendOverlap(tile1: PixelMap, tile2: PixelMap, overlap: number): PixelMap {
  // overlap区域内的像素按距离做线性加权
  // 越靠近tile1中心权重越高，越靠近tile2中心权重越低
}

最佳实践

• 模型先压缩再上端：残差块减到6个，通道减到32，量化为INT8
• 华为设备用MindSpore Lite + NPU：比ONNX Runtime快3-5倍
• 分块处理加overlap：16像素overlap（2x超分），32像素（4x超分）
• 拼接做线性融合：避免硬接缝
• 限制并发tile数量：防止OOM
• 算子兼容性先验证：用onnxsim简化模型再部署

总结

核心要点：

1. 端侧超分必须做模型压缩——减残差块、减通道、量化，从64MB压到4MB
2. 推理框架选型看设备——华为设备用MindSpore Lite+NPU最优，跨厂商用ONNX Runtime
3. 大图必须分块处理——块间加overlap避免接缝，拼接时做线性融合
4. 性能瓶颈在模型推理——量化+NPU加速+异步流水线三管齐下

最佳实践清单：

• 模型压缩：6残差块+32通道+INT8量化
• 华为设备优先MindSpore Lite + NPU
• 分块128x128 + overlap 16像素（2x超分）
• 拼接做线性融合，不做硬替换
• 限制并发tile数量防OOM
• 用onnxsim简化算子确保兼容性

你在端侧AI推理中遇到过什么性能瓶颈？评论区交流，一起把端侧AI跑快跑稳。