3个坑搞不定安卓4.0下载?看这份实战项目源码拆解
学会语法却不知怎么搭项目，这是很多开发者卡在入门到进阶之间的最大痛点。特别是面对像安卓4.0下载这种涉及旧版本兼容、网络请求与文件落盘的实战项目，光看书本理论根本跑不通。很多新人对着Android SDK的文档发呆，觉得API调用很简单，但真到手里，内存泄漏、线程崩溃、UI卡顿这些问题接踵而至。
今天不聊虚的，直接上硬菜。我们拆解一个典型的Android 4.0（API Level 14）环境下的文件下载模块。为什么选4.0？因为虽然它是2011年的系统，但在大量存量工业设备、车载终端和老旧IoT设备上依然存活。理解这个时代的代码架构，能帮你看清Android异步处理演变的脉络。
1. 入口定位：从Activity到DownloadManager的调用链
在Android 4.0时代，处理下载最“正统”的方式不是自己写Socket，而是使用系统提供的DownloadManager。这不仅仅是一个API，它是系统级服务。
很多新手习惯在onCreate里直接发起下载，这是大忌。正确的入口逻辑应该是：用户触发UI事件 - 检查权限 - 构造Request对象 - 提交给DownloadManager - 获取Uri监听状态。
这里有一个关键的架构决策：解耦。下载任务不应该阻塞UI线程，也不应该直接耦合在Activity的生命周期中。在4.0的架构下，DownloadManager运行在独立的进程（com.android.providers.downloads）中。这意味着，即使你的App闪退，下载任务在系统层面可能还在继续（取决于具体配置），但你的App无法收到回调。
这就是为什么我们需要建立自己的监听机制。在4.0中，BroadcastReceiver是监听下载状态变化的核心手段。你需要注册一个接收ACTION_DOWNLOAD_COMPLETE广播的接收器。
常见违规问题：
很多教程教你直接在Activity里registerReceiver。这在4.0中会导致一个隐蔽的Bug：当Activity暂停（如切换到后台或打开新页面）后，如果下载完成，由于Activity处于PAUSED或STOPPED状态，某些UI更新操作会抛出异常，或者更糟糕的是，因为接收器未正确注销导致内存泄漏。
2. 核心片段：DownloadRequest的构建与状态监听
让我们看一段典型的、符合Android 4.0规范的源码。这段代码展示了如何安全地构建下载请求，并处理状态回调。
public class Downloader {
private DownloadManager mDownloadManager;
private Context mContext;
private Uri mDownloadUri;
private BroadcastReceiver mCompleteReceiver;
public Downloader(Context context) {
mContext = context;
// 获取系统服务，注意：必须使用ApplicationContext避免内存泄漏
mDownloadManager = (DownloadManager) context.getSystemService(Context.DOWNLOAD_SERVICE);
// 定义广播接收器，监听下载完成事件
mCompleteReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
// 只有当动作是下载完成时才处理，忽略暂停、取消等其他状态
if (DownloadManager.ACTION_DOWNLOAD_COMPLETE.equals(action)) {
long downloadId = intent.getLongExtra(
DownloadManager.EXTRA_DOWNLOAD_ID, -1);
// 检查ID是否匹配当前任务
if (downloadId == mDownloadUri.hashCode()) {
handleDownloadComplete(downloadId);
}
}
}
};
}
public void startDownload(String url, String fileName) {
// 1. 构建请求对象
DownloadManager.Request request = new DownloadManager.Request(Uri.parse(url));
// 2. 设置通知可见性（4.0特性，下载过程中会在通知栏显示进度）
request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED);
// 3. 设置下载目标路径：外部存储目录
// 注意：4.0默认写入外部存储，无需运行时权限检查（这是4.0与后续版本的最大区别之一）
request.setDestinationInExternalPublicDir(
Environment.DIRECTORY_DOWNLOADS, fileName);
// 4. 设置HTTP头，某些服务器需要User-Agent才能放行
request.addRequestHeader(User-Agent, Mozilla/5.0);
// 5. 设置网络类型限制：仅Wi-Fi下载，防止流量消耗
request.setAllowedNetworkTypes(DownloadManager.Request.NETWORK_WIFI);
// 6. 提交任务
mDownloadUri = mDownloadManager.enqueue(request);
// 7. 注册广播监听器
// 使用IntentFilter精确匹配
IntentFilter filter = new IntentFilter(
DownloadManager.ACTION_DOWNLOAD_COMPLETE);
mContext.registerReceiver(mCompleteReceiver, filter);
}
private void handleDownloadComplete(long downloadId) {
// 查询下载详情
DownloadManager.Query query = new DownloadManager.Query();
query.setFilterById(downloadId);
Cursor cursor = mDownloadManager.query(query);
if (cursor.moveToFirst()) {
int columnIndex = cursor.getColumnIndex(DownloadManager.COLUMN_LOCAL_URI);
if (columnIndex != -1) {
String localUri = cursor.getString(columnIndex);
// 这里可以触发后续逻辑，如安装APK或打开文件
// 注意：在4.0中，localUri通常是content://形式
// 需要将其转换为文件路径才能操作
}
}
cursor.close();
// 关键步骤：注销接收器，防止内存泄漏
mContext.unregisterReceiver(mCompleteReceiver);
}
}
逐行解析关键设计：
mContext的使用：构造函数中接收Context，但在内部操作时，如果涉及全局监听，建议传入ApplicationContext。在registerReceiver时，如果传入的是Activity的Context，当Activity销毁时，接收器如果没注销，就会造成泄漏。
setDestinationInExternalPublicDir：这是4.0特有的API。它直接告诉系统把文件放到公共的Download目录。不需要手动创建文件，不需要管理文件句柄。这是系统级管理的优势。
setAllowedNetworkTypes：在4.0时代，流量费昂贵，且4G网络不稳定。限制仅Wi-Fi下载是标配。如果用户在移动数据下操作，这个请求会静默失败或等待Wi-Fi。
广播监听的时机：registerReceiver放在startDownload内部，unregisterReceiver放在handleDownloadComplete内部。这是一种“任务级”的生命周期管理。如果下载中途取消，你需要额外处理ACTION_DOWNLOAD_REMOVED广播来注销接收器，否则接收器会一直驻留内存。
3. 设计思想：为什么不用AsyncTask？
很多老教程教人用AsyncTask配合HttpURLConnection手动下载。在4.0的实战项目中，这种方案存在巨大缺陷。
核心差异对比：
特性
DownloadManager (系统服务)
AsyncTask + HTTP (应用层)
断点续传
系统自动支持
需手动实现，逻辑复杂
内存占用
几乎为0（独立进程）
占用主进程堆内存
App杀死
下载继续（可选）
下载立即终止
进度更新
通过广播/Cursor查询
通过Handler消息传递
权限管理
系统级，自动处理
需手动检查存储权限
设计思想的核心：
Android 4.0的架构哲学是**“能力下沉”**。能由系统服务做的，就不应该在应用层做。DownloadManager不仅处理网络I/O，还处理文件写入、进度持久化、通知栏UI更新。应用层只需要关心“我要下载什么”和“下载完了我要干什么”。
这种分离带来了极高的稳定性。你不需要处理网络波动导致的流中断，不需要处理磁盘写满异常，不需要处理用户中途锁屏导致的进程回收。这些都是系统服务的职责。
避坑指南：
Content URI vs File Path：4.0的DownloadManager返回的COLUMN_LOCAL_URI通常是content://media/...格式。如果你试图用new File(uri.getPath())直接操作，会报错。必须通过ContentResolver获取真实的文件路径，或者使用FileUtils工具类转换。
权限混淆：虽然4.0不需要运行时权限，但你需要在AndroidManifest.xml中声明uses-permission android:name=android.permission.WRITE_EXTERNAL_STORAGE /和uses-permission android:name=android.permission.INTERNET /。漏掉任何一个，下载都会静默失败。
4. 手写简化版：自定义下载服务
如果业务要求更精细的控制（如自定义文件名、进度条精度、加密存储），DownloadManager就不够用了。这时候需要手写下载逻辑。
在4.0中，推荐架构是：Service + AsyncTask + Handler。
public class CustomDownloadService extends Service {
private static final int PROGRESS = 1;
private static final int SUCCESS = 2;
private static final int FAILED = 3;
private Handler mHandler;
private String mUrl;
private String mFileName;
@Override
public IBinder onBind(Intent intent) { return null; }
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
if (intent != null) {
mUrl = intent.getStringExtra(URL);
mFileName = intent.getStringExtra(FILENAME);
startDownload();
}
return START_NOT_STICKY;
}
private void startDownload() {
// 创建Handler，必须在主线程中创建，以便更新UI（如果需要）
// 这里我们假设Service仅负责下载，通过广播或Binder回调通知UI
new Thread(() - {
try {
// 1. 打开连接
URL url = new URL(mUrl);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod(GET);
conn.setConnectTimeout(10000);
conn.setReadTimeout(10000);
// 2. 获取输入流
InputStream inputStream = conn.getInputStream();
int totalLength = conn.getContentLength();
// 3. 创建输出流，写入外部存储
// 在4.0中，确保SD卡已挂载
File dir = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS);
if (!dir.exists()) dir.mkdirs();
File file = new File(dir, mFileName);
FileOutputStream fos = new FileOutputStream(file);
byte[] buffer = new byte[1024];
int count = 0;
int currentLength = 0;
while ((count = inputStream.read(buffer)) != -1) {
fos.write(buffer, 0, count);
currentLength += count;
// 4. 计算进度并发送消息
if (totalLength 0) {
int progress = (currentLength * 100) / totalLength;
sendProgress(progress);
}
}
fos.flush();
fos.close();
inputStream.close();
conn.disconnect();
sendResult(true, Download Completed);
} catch (Exception e) {
e.printStackTrace();
sendResult(false, Download Failed: + e.getMessage());
}
}).start();
}
private void sendProgress(int progress) {
// 实际项目中，这里应该通过LocalBroadcastManager发送广播
// 或者通过Binder回调给Activity
// 避免直接持有Activity引用
}
private void sendResult(boolean success, String message) {
// 通知结束，停止Service
stopSelf();
}
}
关键细节解析：
Service的作用：将下载任务放在Service中，可以延长任务生命周期。即使Activity销毁，只要Service未被杀死，下载就不会中断。这是DownloadManager的替代品，但灵活性更高。
线程管理：使用匿名Thread而非AsyncTask。AsyncTask在4.0中有严格的线程池限制（默认串行），且容易因配置变更（如屏幕旋转）导致取消逻辑复杂化。裸线程更透明，更可控。
异常处理：必须捕获IOException。网络波动是常态，代码必须能优雅地处理连接中断。
进度通知：不要直接在Service中更新UI。Service运行在主线程（默认）或工作线程。如果是工作线程，不能直接操作UI。必须通过Handler切换到主线程，或通过LocalBroadcastManager发送广播。
5. 应用场景与避坑总结
在实战项目中，选择哪种方案取决于业务场景：
场景一：APK安装更新。推荐使用DownloadManager。因为APK安装需要系统签名验证，且用户期望在通知栏看到进度。DownloadManager天然支持setDestinationInExternalPublicDir，下载完成后直接调用Intent.ACTION_VIEW安装，流程最顺畅。
场景二：大文件下载（100MB）。推荐使用自定义Service。DownloadManager的进度更新粒度较粗，且不支持断点续传的精细控制（如自定义Resume-Range头）。自定义Service可以实现断点续传，节省流量。
场景三：图片/小文件预加载。不要使用下载模块。使用HttpUrlConnection或Volley（4.0时代流行的库）直接在内存中处理，写入缓存目录。
培训机构选择与避坑：
很多新手在自学时，会被各种“速成班”误导。在Android 4.0这种旧版本的技术栈上，最大的坑是**“过时代码的现代化包装”**。
避坑一：忽略API Level差异。很多教程直接复制4.4（KitKat）或5.0（Lollipop）的代码，却声称适用于4.0。例如，4.0不支持FileObserver的某些回调，不支持StorageManager。如果你的代码在4.0上运行，必须严格遵循API Level 14的文档。查阅Android官方文档中的ICE_CREAM_SANDWICH标记，确认API可用性。
避坑二：硬编码路径。4.0时代，SD卡挂载点不稳定。/sdcard路径在某些设备上不可用。必须使用Environment.getExternalStorageDirectory()动态获取。
避坑三：线程安全问题。4.0的Handler机制与后续版本不同。在AsyncTask中，onPostExecute始终在主线程运行，但onProgressUpdate如果在doInBackground中被频繁调用，会导致消息队列阻塞。自定义Service时，务必注意Handler的消息去重。
现场常见违规问题：
未注销广播接收器：这是内存泄漏的头号杀手。在onDestroy或下载完成时，必须调用unregisterReceiver。
主线程网络请求：4.0引入了NetworkOnMainThreadException。如果在UI线程直接发起HTTP请求，App会直接崩溃。务必确保所有I/O操作都在子线程。
忽略权限检查：虽然4.0是静态权限，但WRITE_EXTERNAL_STORAGE必须在Manifest中声明，且用户必须授予权限（通过系统设置或首次启动弹窗）。如果权限未授予，openFileOutput会抛出SecurityException。
结尾互动：
在安卓4.0下载这个看似简单的实战项目中，你遇到过最诡异的Bug是什么？是广播收不到，还是文件路径找不到？或者你公司项目里是怎么处理老旧设备兼容性的？是维护一套4.0代码，还是强制用户升级？欢迎在评论区分享你的踩坑经验，我们一起拆解。 
长河君 · 2026/9/22 15:05:17 · 阅读 1.2k 3个坑搞不定安卓4.0下载?看这份实战项目源码拆解
3个坑搞不定安卓4.0下载?看这份实战项目源码拆解
学会语法却不知怎么搭项目，这是很多开发者卡在入门到进阶之间的最大痛点。特别是面对像安卓4.0下载这种涉及旧版本兼容、网络请求与文件落盘的实战项目，光看书本理论根本跑不通。很多新人对着Android SDK的文档发呆，觉得API调用很简单，但真到手里，内存泄漏、线程崩溃、UI卡顿这些问题接踵而至。
今天不聊虚的，直接上硬菜。我们拆解一个典型的Android 4.0（API Level 14）环境下的文件下载模块。为什么选4.0？因为虽然它是2011年的系统，但在大量存量工业设备、车载终端和老旧IoT设备上依然存活。理解这个时代的代码架构，能帮你看清Android异步处理演变的脉络。
1. 入口定位：从Activity到DownloadManager的调用链
在Android 4.0时代，处理下载最“正统”的方式不是自己写Socket，而是使用系统提供的DownloadManager。这不仅仅是一个API，它是系统级服务。
很多新手习惯在onCreate里直接发起下载，这是大忌。正确的入口逻辑应该是：用户触发UI事件 - 检查权限 - 构造Request对象 - 提交给DownloadManager - 获取Uri监听状态。
这里有一个关键的架构决策：解耦。下载任务不应该阻塞UI线程，也不应该直接耦合在Activity的生命周期中。在4.0的架构下，DownloadManager运行在独立的进程（com.android.providers.downloads）中。这意味着，即使你的App闪退，下载任务在系统层面可能还在继续（取决于具体配置），但你的App无法收到回调。
这就是为什么我们需要建立自己的监听机制。在4.0中，BroadcastReceiver是监听下载状态变化的核心手段。你需要注册一个接收ACTION_DOWNLOAD_COMPLETE广播的接收器。
常见违规问题：
很多教程教你直接在Activity里registerReceiver。这在4.0中会导致一个隐蔽的Bug：当Activity暂停（如切换到后台或打开新页面）后，如果下载完成，由于Activity处于PAUSED或STOPPED状态，某些UI更新操作会抛出异常，或者更糟糕的是，因为接收器未正确注销导致内存泄漏。
2. 核心片段：DownloadRequest的构建与状态监听
让我们看一段典型的、符合Android 4.0规范的源码。这段代码展示了如何安全地构建下载请求，并处理状态回调。
public class Downloader {
private DownloadManager mDownloadManager;
private Context mContext;
private Uri mDownloadUri;
private BroadcastReceiver mCompleteReceiver;
public Downloader(Context context) {
mContext = context;
// 获取系统服务，注意：必须使用ApplicationContext避免内存泄漏
mDownloadManager = (DownloadManager) context.getSystemService(Context.DOWNLOAD_SERVICE);
// 定义广播接收器，监听下载完成事件
mCompleteReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
// 只有当动作是下载完成时才处理，忽略暂停、取消等其他状态
if (DownloadManager.ACTION_DOWNLOAD_COMPLETE.equals(action)) {
long downloadId = intent.getLongExtra(
DownloadManager.EXTRA_DOWNLOAD_ID, -1);
// 检查ID是否匹配当前任务
if (downloadId == mDownloadUri.hashCode()) {
handleDownloadComplete(downloadId);
}
}
}
};
}
public void startDownload(String url, String fileName) {
// 1. 构建请求对象
DownloadManager.Request request = new DownloadManager.Request(Uri.parse(url));
// 2. 设置通知可见性（4.0特性，下载过程中会在通知栏显示进度）
request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED);
// 3. 设置下载目标路径：外部存储目录
// 注意：4.0默认写入外部存储，无需运行时权限检查（这是4.0与后续版本的最大区别之一）
request.setDestinationInExternalPublicDir(
Environment.DIRECTORY_DOWNLOADS, fileName);
// 4. 设置HTTP头，某些服务器需要User-Agent才能放行
request.addRequestHeader(User-Agent, Mozilla/5.0);
// 5. 设置网络类型限制：仅Wi-Fi下载，防止流量消耗
request.setAllowedNetworkTypes(DownloadManager.Request.NETWORK_WIFI);
// 6. 提交任务
mDownloadUri = mDownloadManager.enqueue(request);
// 7. 注册广播监听器
// 使用IntentFilter精确匹配
IntentFilter filter = new IntentFilter(
DownloadManager.ACTION_DOWNLOAD_COMPLETE);
mContext.registerReceiver(mCompleteReceiver, filter);
}
private void handleDownloadComplete(long downloadId) {
// 查询下载详情
DownloadManager.Query query = new DownloadManager.Query();
query.setFilterById(downloadId);
Cursor cursor = mDownloadManager.query(query);
if (cursor.moveToFirst()) {
int columnIndex = cursor.getColumnIndex(DownloadManager.COLUMN_LOCAL_URI);
if (columnIndex != -1) {
String localUri = cursor.getString(columnIndex);
// 这里可以触发后续逻辑，如安装APK或打开文件
// 注意：在4.0中，localUri通常是content://形式
// 需要将其转换为文件路径才能操作
}
}
cursor.close();
// 关键步骤：注销接收器，防止内存泄漏
mContext.unregisterReceiver(mCompleteReceiver);
}
}
逐行解析关键设计：
mContext的使用：构造函数中接收Context，但在内部操作时，如果涉及全局监听，建议传入ApplicationContext。在registerReceiver时，如果传入的是Activity的Context，当Activity销毁时，接收器如果没注销，就会造成泄漏。
setDestinationInExternalPublicDir：这是4.0特有的API。它直接告诉系统把文件放到公共的Download目录。不需要手动创建文件，不需要管理文件句柄。这是系统级管理的优势。
setAllowedNetworkTypes：在4.0时代，流量费昂贵，且4G网络不稳定。限制仅Wi-Fi下载是标配。如果用户在移动数据下操作，这个请求会静默失败或等待Wi-Fi。
广播监听的时机：registerReceiver放在startDownload内部，unregisterReceiver放在handleDownloadComplete内部。这是一种“任务级”的生命周期管理。如果下载中途取消，你需要额外处理ACTION_DOWNLOAD_REMOVED广播来注销接收器，否则接收器会一直驻留内存。
3. 设计思想：为什么不用AsyncTask？
很多老教程教人用AsyncTask配合HttpURLConnection手动下载。在4.0的实战项目中，这种方案存在巨大缺陷。
核心差异对比：
特性
DownloadManager (系统服务)
AsyncTask + HTTP (应用层)
断点续传
系统自动支持
需手动实现，逻辑复杂
内存占用
几乎为0（独立进程）
占用主进程堆内存
App杀死
下载继续（可选）
下载立即终止
进度更新
通过广播/Cursor查询
通过Handler消息传递
权限管理
系统级，自动处理
需手动检查存储权限
设计思想的核心：
Android 4.0的架构哲学是**“能力下沉”**。能由系统服务做的，就不应该在应用层做。DownloadManager不仅处理网络I/O，还处理文件写入、进度持久化、通知栏UI更新。应用层只需要关心“我要下载什么”和“下载完了我要干什么”。
这种分离带来了极高的稳定性。你不需要处理网络波动导致的流中断，不需要处理磁盘写满异常，不需要处理用户中途锁屏导致的进程回收。这些都是系统服务的职责。
避坑指南：
Content URI vs File Path：4.0的DownloadManager返回的COLUMN_LOCAL_URI通常是content://media/...格式。如果你试图用new File(uri.getPath())直接操作，会报错。必须通过ContentResolver获取真实的文件路径，或者使用FileUtils工具类转换。
权限混淆：虽然4.0不需要运行时权限，但你需要在AndroidManifest.xml中声明uses-permission android:name=android.permission.WRITE_EXTERNAL_STORAGE /和uses-permission android:name=android.permission.INTERNET /。漏掉任何一个，下载都会静默失败。
4. 手写简化版：自定义下载服务
如果业务要求更精细的控制（如自定义文件名、进度条精度、加密存储），DownloadManager就不够用了。这时候需要手写下载逻辑。
在4.0中，推荐架构是：Service + AsyncTask + Handler。
public class CustomDownloadService extends Service {
private static final int PROGRESS = 1;
private static final int SUCCESS = 2;
private static final int FAILED = 3;
private Handler mHandler;
private String mUrl;
private String mFileName;
@Override
public IBinder onBind(Intent intent) { return null; }
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
if (intent != null) {
mUrl = intent.getStringExtra(URL);
mFileName = intent.getStringExtra(FILENAME);
startDownload();
}
return START_NOT_STICKY;
}
private void startDownload() {
// 创建Handler，必须在主线程中创建，以便更新UI（如果需要）
// 这里我们假设Service仅负责下载，通过广播或Binder回调通知UI
new Thread(() - {
try {
// 1. 打开连接
URL url = new URL(mUrl);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod(GET);
conn.setConnectTimeout(10000);
conn.setReadTimeout(10000);
// 2. 获取输入流
InputStream inputStream = conn.getInputStream();
int totalLength = conn.getContentLength();
// 3. 创建输出流，写入外部存储
// 在4.0中，确保SD卡已挂载
File dir = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS);
if (!dir.exists()) dir.mkdirs();
File file = new File(dir, mFileName);
FileOutputStream fos = new FileOutputStream(file);
byte[] buffer = new byte[1024];
int count = 0;
int currentLength = 0;
while ((count = inputStream.read(buffer)) != -1) {
fos.write(buffer, 0, count);
currentLength += count;
// 4. 计算进度并发送消息
if (totalLength 0) {
int progress = (currentLength * 100) / totalLength;
sendProgress(progress);
}
}
fos.flush();
fos.close();
inputStream.close();
conn.disconnect();
sendResult(true, Download Completed);
} catch (Exception e) {
e.printStackTrace();
sendResult(false, Download Failed: + e.getMessage());
}
}).start();
}
private void sendProgress(int progress) {
// 实际项目中，这里应该通过LocalBroadcastManager发送广播
// 或者通过Binder回调给Activity
// 避免直接持有Activity引用
}
private void sendResult(boolean success, String message) {
// 通知结束，停止Service
stopSelf();
}
}
关键细节解析：
Service的作用：将下载任务放在Service中，可以延长任务生命周期。即使Activity销毁，只要Service未被杀死，下载就不会中断。这是DownloadManager的替代品，但灵活性更高。
线程管理：使用匿名Thread而非AsyncTask。AsyncTask在4.0中有严格的线程池限制（默认串行），且容易因配置变更（如屏幕旋转）导致取消逻辑复杂化。裸线程更透明，更可控。
异常处理：必须捕获IOException。网络波动是常态，代码必须能优雅地处理连接中断。
进度通知：不要直接在Service中更新UI。Service运行在主线程（默认）或工作线程。如果是工作线程，不能直接操作UI。必须通过Handler切换到主线程，或通过LocalBroadcastManager发送广播。
5. 应用场景与避坑总结
在实战项目中，选择哪种方案取决于业务场景：
场景一：APK安装更新。推荐使用DownloadManager。因为APK安装需要系统签名验证，且用户期望在通知栏看到进度。DownloadManager天然支持setDestinationInExternalPublicDir，下载完成后直接调用Intent.ACTION_VIEW安装，流程最顺畅。
场景二：大文件下载（100MB）。推荐使用自定义Service。DownloadManager的进度更新粒度较粗，且不支持断点续传的精细控制（如自定义Resume-Range头）。自定义Service可以实现断点续传，节省流量。
场景三：图片/小文件预加载。不要使用下载模块。使用HttpUrlConnection或Volley（4.0时代流行的库）直接在内存中处理，写入缓存目录。
培训机构选择与避坑：
很多新手在自学时，会被各种“速成班”误导。在Android 4.0这种旧版本的技术栈上，最大的坑是**“过时代码的现代化包装”**。
避坑一：忽略API Level差异。很多教程直接复制4.4（KitKat）或5.0（Lollipop）的代码，却声称适用于4.0。例如，4.0不支持FileObserver的某些回调，不支持StorageManager。如果你的代码在4.0上运行，必须严格遵循API Level 14的文档。查阅Android官方文档中的ICE_CREAM_SANDWICH标记，确认API可用性。
避坑二：硬编码路径。4.0时代，SD卡挂载点不稳定。/sdcard路径在某些设备上不可用。必须使用Environment.getExternalStorageDirectory()动态获取。
避坑三：线程安全问题。4.0的Handler机制与后续版本不同。在AsyncTask中，onPostExecute始终在主线程运行，但onProgressUpdate如果在doInBackground中被频繁调用，会导致消息队列阻塞。自定义Service时，务必注意Handler的消息去重。
现场常见违规问题：
未注销广播接收器：这是内存泄漏的头号杀手。在onDestroy或下载完成时，必须调用unregisterReceiver。
主线程网络请求：4.0引入了NetworkOnMainThreadException。如果在UI线程直接发起HTTP请求，App会直接崩溃。务必确保所有I/O操作都在子线程。
忽略权限检查：虽然4.0是静态权限，但WRITE_EXTERNAL_STORAGE必须在Manifest中声明，且用户必须授予权限（通过系统设置或首次启动弹窗）。如果权限未授予，openFileOutput会抛出SecurityException。
结尾互动：
在安卓4.0下载这个看似简单的实战项目中，你遇到过最诡异的Bug是什么？是广播收不到，还是文件路径找不到？或者你公司项目里是怎么处理老旧设备兼容性的？是维护一套4.0代码，还是强制用户升级？欢迎在评论区分享你的踩坑经验，我们一起拆解。