uni-app图片加载慢主因是安卓webview下未走原生渲染路径，应启用nvue+原生渲染、预加载关键图、用intersectionobserver替代lazy-load、优化格式尺寸并设固定宽高。
uni-app 图片加载慢是因为 img 标签没走原生渲染路径
安卓 WebView 下，uni-app 的 <image></image> 组件默认用的是 WebView 渲染（非原生），尤其在低端机或旧版系统上，解码、缩放、绘制全靠 JS + Canvas 模拟，卡顿明显。这不是网络问题，是渲染链路太长。
实操建议：
- 优先用
<image></image>而不是<img>，uni-app 会尝试调用原生 image 控件（仅限 nvue 页面或启用了原生渲染的页面） - 在 manifest.json 中开启「启用原生渲染」：设置
"nvueStyle": true，并确保页面是 .nvue 后缀（.vue 页面无法触发原生 image） - 避免在
<image></image>上大量使用mode="aspectFill"或mode="scaleToFill"，这些模式需 CPU 裁剪，安卓下无硬件加速支持 - 慎用
lazy-load属性——uni-app 的 lazy-load 是 JS 滚动监听实现的，非原生，反而增加主线程负担；不如自己用IntersectionObserver控制显隐
预加载图片必须用 uni.preloadImage，别用 new Image()
new Image() 在安卓 WebView 里不会真正预解码，只是下载完就扔进缓存队列，首次渲染仍要解码；而 uni.preloadImage 会触发原生层预解码（iOS/Android 均有效）。
常见错误现象：预加载后首屏图片依然闪白、延迟出现。
实操建议：
- 在 onLaunch 或页面 created 阶段集中调用：
uni.preloadImage({ sources: ['https://a.png', 'https://b.jpg'] }) - 只预加载关键资源（如首页 banner、头像占位图），数量控制在 5 张以内，过多会阻塞主线程
- 不支持动态 URL 拼接（如
'/img/' + id + '.png'），必须传完整静态地址；否则预加载失败且无报错 - 预加载结果不可监听成功/失败，只能靠后续
<image></image>渲染是否流畅反推
懒加载要用 IntersectionObserver + data-src 手动切换
uni-app 内置的 lazy-load 在安卓上兼容性差（尤其 Android 6–8）、触发不准、无法控制阈值。真实场景中，滚动快时大量图片同时触发解码，直接卡死。
使用场景：列表页图片、瀑布流、长图文
实操建议：
- 模板中用
<image :src="item.loaded ? item.realSrc : placeholder"></image> - 在页面中创建
IntersectionObserver实例（注意：H5 和小程序 API 一致，但 App 端需确认基础库 ≥ 2.6.10） - 观察区域设为
{ thresholds: [0.1] }，避免过早触发；进入视口 10% 就开始加载，比默认 0 更稳 - 加载后立即赋值
item.loaded = true，并移除 observer 实例（避免重复触发）
图片格式和尺寸不优化，再好的加载逻辑也白搭
很多“加载慢”本质是单张图太大（>500KB）、分辨率远超屏幕（如 4K 图在 720p 屏上渲染）、格式未适配（全用 PNG 显示照片）。
性能影响：安卓 WebView 解码 JPEG 比 PNG 快 3–5 倍；WebP 在支持机型上体积减少 40%，但 Android 4.3 以下不支持。
实操建议：
- 服务端按设备 dpr 返回不同尺寸图（如
@2x、@3x），前端通过uni.getSystemInfoSync().pixelRatio区分 - 安卓 App 优先用 JPEG（照片类）或 WebP（支持机型），禁用 GIF 动图——uni-app 不做帧解码优化，全靠 WebView，极易 OOM
- 本地资源用
static/目录，避免走网络请求；但注意：热更新时 static 不参与 diff，大图更新需发版 - 对用户上传图做客户端压缩：用
uni.compressImage，质量设为 80，宽高压缩到 1200px 以内
最易被忽略的一点：nvue 页面中 <image></image> 的 width/height 必须写具体数值（如 400rpx），不能只写 auto 或依赖父容器——否则安卓原生层无法预分配纹理内存，导致反复重绘。
