Jetpack Compose如何为LazyColumn懒加载音乐文件及元数据并解决异常

问题1：专辑封面加载慢、列表渲染延迟解决方案 #

• 第一步：修改数据结构，移除MusicCardModel中的Bitmap字段，新增albumId: Long?字段，扫描阶段仅从MediaStore查询基础元数据，不同步加载封面，将扫描逻辑的耗时压缩到和不加封面的水平。
• 第二步：废弃全局同步加载封面的getAlbumArt调用，改用Compose生态的异步图片加载框架（Coil/Glide Compose）在列表项渲染时懒加载封面：
  1. 优先通过albumId拼接系统专辑封面Uri加载，比读取音频文件内嵌封面效率高10倍以上：ContentUris.withAppendedId(Uri.parse("content://media/external/audio/albumart"), albumId)
  2. 图片加载框架自动处理异步、缓存、占位图逻辑，仅当卡片进入可视区域时才触发加载，不会一次性加载所有封面占用资源。
     示例代码（Coil Compose）：

// MusicCard中替换原Image组件
AsyncImage(
    model = ContentUris.withAppendedId(Uri.parse("content://media/external/audio/albumart"), albumId),
    modifier = Modifier.size(70.dp),
    contentDescription = "专辑封面",
    placeholder = painterResource(R.drawable.note),
    error = painterResource(R.drawable.note)
)

• 第三步：调整扫描逻辑，去掉循环内的封面加载步骤，扫描完成后立刻返回列表，页面可实现秒开，封面异步加载不阻塞主线程。

问题2：切换应用触发TransactionTooLargeException解决方案 #

该异常的根因是Android Bundle的传输上限约为1MB，你将全量音乐列表（尤其是携带Bitmap的大对象）存入了可保存状态（rememberSaveable、ViewModel SavedStateHandle等），切后台时系统序列化状态数据超过上限触发崩溃。

• 全量音乐列表仅存在ViewModel的普通成员变量中，不要存入可持久化的状态容器，切后台不需要保存全量列表数据，进程被回收后重新从MediaStore扫描即可，MediaStore的音乐数据是系统持久化的，无需自行存储。
• 移除MusicCardModel中的Bitmap字段后，单条数据的内存占用可降低90%以上，即使有临时序列化场景也不会轻易超过Bundle大小上限。
• 额外优化：如果设备内音乐超过1000首，可改为分页查询MediaStore，每次仅加载20-30条数据，滚动到列表底部再加载下一页，进一步降低内存占用，也能避免全量加载带来的其他性能问题。

内容的提问来源于stack exchange，提问作者Ahmet Saraç