因Async Task过多导致应用崩溃问题求助

这个问题我之前处理过类似的场景，AsyncTask的默认THREAD_POOL_EXECUTOR确实有严格的容量限制（默认队列大小128，核心线程数3），当你一次性提交400个下载任务时，队列很快就会被填满，触发RejectedExecutionException。下面是几个实用的解决方案：

1. 自定义线程池替代AsyncTask默认池 #

你可以创建一个自定义的ThreadPoolExecutor，调整线程数量和队列容量，适配你的批量下载需求：

// 自定义线程池配置
int corePoolSize = Runtime.getRuntime().availableProcessors(); // 核心线程数设为CPU核心数
int maxPoolSize = corePoolSize * 2;
long keepAliveTime = 60L;
BlockingQueue<Runnable> workQueue = new LinkedBlockingQueue<>(500); // 队列容量设为500，足够容纳400个任务

ThreadPoolExecutor customExecutor = new ThreadPoolExecutor(
    corePoolSize,
    maxPoolSize,
    keepAliveTime,
    TimeUnit.SECONDS,
    workQueue,
    Executors.defaultThreadFactory(),
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略：如果队列满了，让调用线程执行任务，避免直接报错
);

// 提交下载任务时使用自定义线程池
new AsyncTask<Void, Void, Void>() {
    @Override
    protected Void doInBackground(Void... voids) {
        // 这里写你的Firebase文件下载逻辑
        return null;
    }
}.executeOnExecutor(customExecutor);

这样配置后，队列容量足够容纳所有下载任务，拒绝策略也能避免任务被直接拒绝。

2. 改用现代并发API替代AsyncTask #

AsyncTask已经在Android 11被标记为弃用，推荐使用更灵活、可控的并发方案：

• Kotlin Coroutines：用CoroutineScope配合Dispatchers.IO处理后台下载，自带线程池管理，代码更简洁：

  CoroutineScope(Dispatchers.IO).launch {
      // 遍历所有下载任务
      downloadTaskList.forEach { task ->
          // 执行单个文件下载逻辑
          downloadFileFromFirebase(task)
      }
  }
  

• ExecutorService + Future：如果用Java开发，直接用ExecutorService提交Callable任务，比AsyncTask更灵活。
• WorkManager：如果下载任务需要持久化（比如App退出后继续下载），WorkManager是最佳选择，它会自动管理后台线程和任务队列，还能处理系统重启后的任务恢复。

3. 批量任务限流处理 #

不要一次性提交所有400个任务，分批次提交，比如每次提交20个，等一批完成一定数量后再提交下一批：

// 假设downloadUrls是所有需要下载的文件URL列表
int batchSize = 20;
int totalTasks = downloadUrls.size();

for (int i = 0; i < totalTasks; i += batchSize) {
    int end = Math.min(i + batchSize, totalTasks);
    List<String> batchUrls = downloadUrls.subList(i, end);
    
    // 提交当前批次的任务
    for (String url : batchUrls) {
        new DownloadAsyncTask().executeOnExecutor(customExecutor, url);
    }
    
    // 可选：等待当前批次部分完成再继续，降低系统瞬时压力
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
}

这种方式能避免瞬间填满线程池队列，减少系统资源占用。

4. Firebase Storage下载优化 #

• 下载前先检查本地是否已经存在该文件，避免重复下载，减少任务数量。
• 启用Firebase Storage的重试机制，FirebaseStorage.getInstance().setMaximumDownloadRetryTimeMillis(30000)，提高不稳定网络下的下载成功率。

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