Android单次点击批量下载100+文件时应用冻结，咨询同步更新UI的最优实现方案

现有DownloadManager触发应用冻结的常见原因 #

• 短时间在主线程提交100+下载请求，触发系统下载服务的跨进程通信阻塞
• 在主线程轮询查询每个任务的实时下载进度、状态，触发主线程阻塞导致ANR
• 未做并发数限制，瞬间发起的过量下载请求撑满系统下载服务的任务队列，触发系统侧降载

可选技术路径的适配性对比 #

• 前台自定义下载Service
  • 独立于页面生命周期运行，不会因页面切换、后台切出被系统随意终止
  • 可自主管控下载任务队列，灵活配置并发下载数，避免系统服务过载
  • 支持细粒度回调每个任务的实时进度、成功/失败状态，可直接推送到UI层，同步更新加载动画、整体/单个文件的下载进度、按钮可用状态
  • 可自主实现断点续传、失败重试、文件类型分类调度逻辑，比系统DownloadManager的可控性更强
• JobScheduler
  • 适配无即时响应要求的延迟类后台任务，无法满足用户点击后即时启动下载、实时展示进度的需求
  • 系统会根据设备电量、网络状态自动调整任务执行时机，无法保证用户操作后的即时下载启动，也难以实现流畅的进度UI同步
  • 调度粒度较粗，对100+不同大小文件的批量下载场景，自定义控制的开发成本远高于收益
• 原生DownloadManager
  • 可作为兜底下载通道使用，但不适合作为100+文件批量下载的核心逻辑，其跨进程状态查询的广播解耦成本高、并发控制能力弱，容易触发系统侧的阻塞问题

场景最优实现方案 #

适配当前需求的最优路径为前台Service + 基于轻量网络库的自定义下载引擎，核心实现要点：

• 用户点击下载按钮后，主线程第一时间将按钮置为不可点击的加载态，避免重复触发请求
• 启动符合安卓8.0+规范的前台Service，在Service的工作线程内初始化固定并发数的任务调度队列（建议并发值设为3-5，可根据实时网络带宽动态调整），将100余个待下载文件按文件大小排序加入队列
• 队列调度时优先安排体积较小的gif、普通图片，大体积视频排在队列靠后位置，降低用户的等待感知
• 每个下载任务的进度、状态变更，通过应用内可观察的数据对象（如Flow、LiveData）同步到UI层，实时更新加载器动画、整体下载进度条、单个文件的下载状态标识
• 所有下载、队列调度逻辑全部运行在工作线程，完全不占用主线程资源，从根源上解决应用冻结问题
• 前台Service需展示对应通知栏条目，明确告知用户当前整体下载进度，符合系统后台运行的权限要求

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