在即时通讯App的RecyclerView中嵌套列表展示多类型附件的最优方案

问题背景 #

正在开发一款类即时通讯App，已通过RecyclerView实现消息列表的基础绘制。现需在每条消息内展示图片、音频、文件等不同类型的附件，消息数据结构如下：

{
    "id": 2,
    "text": "Test",
    "sendTime": "21:31 12.10.22",
    "userId": 1,
    "user": {
        "id": 1,
        "login": "geckon01",
        "email": "geckon01@example.com",
        "role": "host",
        "lastOnline": "2022-10-23T11:03:57.6349417",
        "avatarFileId": 0,
        "avatarBase64": null
    },
    "attachments": [{
        "id": 1,
        "type": "Image",
        "data": null,
        "user": {
            "id": 1,
            "login": "geckon01",
            "email": "geckon01@example.com",
            "role": "host",
            "lastOnline": "2022-10-23T11:03:57.6349417",
            "avatarFileId": 0,
            "avatarBase64": null
        },
        "file": {
            "id": 1,
            "directory": "graphics",
            "fileName": "1c08af89-41f2-4f85-bb5a-3336a37e51bf.jpg",
            "type": "Graphics",
            "fileOwner": {
                "id": 1,
                "login": "geckon01",
                "email": "geckon01@example.com",
                "role": "host",
                "lastOnline": "2022-10-23T11:03:57.6349417",
                "avatarFileId": 0,
                "avatarBase64": null
            }
        },
        "messageId": 2
    }]
}

需要根据附件类型渲染不同视图，曾考虑用Fragment但担心性能问题，目标是实现包含多种类型附件的完整消息布局，询问RecyclerView嵌套列表的最优实现方式。

最优实现方案：避免嵌套RecyclerView，采用两种高效替代方式 #

方案一：主消息Item内部用自定义ViewGroup承载附件 #

• 为每种附件类型（Image/Audio/File）单独创建布局文件，比如item_attachment_image.xml（展示图片缩略图+文件名）、item_attachment_audio.xml（展示音频波形+播放按钮+时长）、item_attachment_file.xml（展示文件图标+文件名+大小）
• 在主消息的Item布局中，添加一个容器（推荐用自定义FlowLayout实现自动换行，或用LinearLayout做横向/纵向排列），用于动态挂载附件View
• 在主RecyclerView的Adapter的onBindViewHolder方法中，遍历当前消息的attachments列表：
  • 根据attachment.type创建对应的附件View实例
  • 绑定附件的文件信息、交互事件（比如图片点击预览、音频点击播放）
  • 将创建好的附件View添加到容器中
• 优化点：维护一个附件View的回收池，当Item被回收时，将容器内的附件View放入回收池，下次绑定直接复用，减少View创建销毁的开销

方案二：将消息与附件拆分为单一RecyclerView的多类型Item #

• 把每条消息的结构拆分为多个独立的Item类型：
  • TYPE_MESSAGE_HEADER：展示头像、用户名、发送时间
  • TYPE_MESSAGE_TEXT：展示消息文本内容
  • TYPE_ATTACHMENT_IMAGE：单张图片附件
  • TYPE_ATTACHMENT_AUDIO：单个音频附件
  • TYPE_ATTACHMENT_FILE：单个文件附件
• 构建数据源时，将一条完整消息拆解为上述多个Item数据，比如一条带2张图片的消息，会生成HEADER→TEXT→IMAGE1→IMAGE2四个Item
• 在RecyclerView的Adapter中：
  • 重写getItemViewType方法，根据当前位置的Item数据返回对应的类型
  • 重写onCreateViewHolder，根据不同类型创建对应的ViewHolder
  • 重写onBindViewHolder，绑定对应类型的数据和交互事件
• 优势：完全复用RecyclerView的原生回收复用机制，性能最优，尤其适合附件数量较多的场景，滑动流畅度有保障

为什么不推荐嵌套RecyclerView？ #

• 布局层级过深：嵌套会增加View树的层级，导致Measure、Layout阶段的耗时增加，直接影响滑动流畅度
• 回收复用冲突：内层RecyclerView的回收池会和外层相互干扰，容易出现视图错乱、卡顿等问题
• 滚动事件复杂：需要额外处理内外层RecyclerView的滚动事件拦截，逻辑繁琐且容易出现滑动冲突

关于Fragment的顾虑 #

完全没必要用Fragment承载附件视图，Fragment的创建、初始化、生命周期管理开销远大于普通View，会严重拖慢列表的滚动性能，直接使用自定义View即可满足需求。

内容的提问来源于stack exchange，提问作者Geckon01