PAYATHON 2026

部分 Samsung 设备的媒体通知和锁屏封面出现像素化，如何排查？

数据小许

现有信息还不足以确定像素化的具体原因。代码会将图片从 1024×1024 缩小到 512×512，但你已经测试过不缩放的版本。接下来需要检查实际获取的图片数据，以及封面交给媒体组件后的处理过程。仅凭现有现象，不能认定是 Samsung 系统缺陷。

先确认代码实际传入了什么图片

示例中，imageRepository.getImage(url) 获取图片数据，经 scaleArtworkForNotification(raw) 处理后，由 setArtworkData(...) 写入 MediaMetadata。只有 artworkByteArray 为 null 时，代码才会执行 setArtworkUri(...)。

比较 ByteArray 和 Uri 两种方式时，要确认每次测试实际进入了哪个分支，以及两者是否指向同一份图片。仅修改图片地址，不代表代码已改为通过 Uri 加载。

源文件约 8 KB，单凭大小无法判断画质。PNG 文件大小与画面内容有关，纯色、图标等图片可以很小。低分辨率图片即使放大后保存为 1024×1024，也不会增加原本缺失的细节。需要检查实际获取的文件和视觉内容。

可以先记录图片在处理前后的尺寸：

import android.graphics.BitmapFactory
import android.util.Log

private fun logArtwork(label: String, data: ByteArray) {
    val options = BitmapFactory.Options().apply {
        inJustDecodeBounds = true
    }
    BitmapFactory.decodeByteArray(data, 0, data.size, options)

    Log.d(
        "Artwork",
        "$label: bytes=${data.size}, " +
            "size=${options.outWidth}×${options.outHeight}, " +
            "mime=${options.outMimeType}"
    )
}

在现有图片获取代码中调用：

imageRepository.getImage(url)?.let { raw ->
    logArtwork("downloaded", raw)
    val output = scaleArtworkForNotification(raw)
    logArtwork("metadata", output)
    output
}

这能确认返回的数据能否被识别、尺寸是否符合预期，但不能证明图片本身清晰。还应在应用内显示同一份 raw 数据，检查其中的小字、边缘或纹理。

用原始数据做一次可追踪的对照

暂时跳过缩放，将获取到的原始数据直接交给现有的 setArtworkData(...) 路径：

val artworkByteArray = artworkUrl?.let { url ->
    imageRepository.getImage(url)?.also { raw ->
        logArtwork("original", raw)
    }
}

对照时要确认媒体组件已经收到新的 MediaItem 或 metadata，并使用外观明显不同的测试封面，避免把旧封面误认为新结果。具体更新方式取决于播放器和会话的接入代码，当前材料没有提供这部分实现。

建议比较以下位置：

检查位置结果及排查方向
应用内显示获取到的原始数据如果已经模糊，优先检查图片内容、下载结果和仓库缓存
应用内显示缩放后的数据如果只有缩放后变差，重点检查缩放过程
媒体通知如果应用内清晰而通知模糊，继续检查媒体组件加载和通知显示过程
锁屏如果与通知效果不同，应分别记录，不能假设它们使用相同的显示尺寸和处理方式

如果原图在应用内清晰，传入 metadata 的数据也确认无误，而问题只出现在特定设备的系统界面，才有依据进一步怀疑后续图片处理或设备端显示行为。

缩放代码有哪些需要注意的地方

对于这张 1024×1024 的图片，scaleArtworkForNotification() 会输出 512×512 的图片。缩小会减少可用细节，如果后续放大显示，模糊可能会更明显。

不过，这不能说明 512 是错误尺寸，换成更大的固定值也不能保证解决问题。应在同一设备上对照原始数据和缩放数据的实际效果。

还需要检查两点：

  • 材料中没有给出 original.scale(...) 的 import 和具体实现，需要确认它使用的缩放方式，以及是否启用了适合图片缩放的过滤。
  • 当前函数始终把大图缩放成正方形。本题的源图是正方形，比例不会变化；如果以后传入非正方形封面，则会被拉伸，应按需要等比缩放或裁剪。

scaled.compress(Bitmap.CompressFormat.PNG, 100, out) 中的 100 不能修复清晰度。PNG 是无损格式，这个 quality 参数无法补回缩小时丢失的细节。

ByteArray 和 Uri 都模糊，能说明什么

这说明问题未必只由其中一种数据入口引起，但仍无法定位根因。两次测试可能取得相同的低细节图片、命中缓存，或在后续处理过程中产生相似结果。

使用 Uri 时，还需要确认它实际返回的图片是否与 ByteArray 测试一致，以及是否加载成功。如果封面通过异步流程加载，还应观察加载完成后显示结果是否更新。

如果原始数据、缩放结果和 metadata 更新均检查正常，下一步应补充以下信息：

  • 出问题的 Samsung 型号、Android 与 One UI 版本，以及正常设备的对照结果。
  • MediaItem、播放器、MediaSession 和通知组件的具体来源与依赖版本。
  • 是否自定义了图片加载器、Bitmap 解码或缓存逻辑。
  • 像素化出现在通知折叠态、展开态、锁屏中的哪些位置。

目前最需要确认的是图片从哪个环节开始变模糊。如果只在特定系统界面复现，可以用最小播放示例继续验证；如果缩放后的图片在应用内已经明显变差，先调整应用内处理，有助于缩小问题范围。

备注：内容仅供参考。