学徒浅析Android——Android原生下载机制针对0K大小文件下载异常的分析

本篇文章已授权微信公众号 guolin_blog（郭霖）独家发布
 
最近在进行一次测试用例中，发现测试手机在利用本地下载功能下载0K大小的文件时，进度条一直处于进度模糊状态中，虽然查看本地存储路径，发现文件已经存在，但是页面上并没有提示下载成功，此时只能对下载执行暂停或删除操作。最初只是怀疑是自身应用的问题，但是在试了自己的华为畅享5s(Android5.1)、联想S560(Android.4.2)（暴露贫穷了）及朋友的ZTE小鲜(Android6.0)、华为P9(Android7.0)等三款不同厂商的设备后，发现都有相同的现象，所以怀疑这是android自身的一个待优化点（说bug有点严重了，毕竟0K大小的文件谁会经常遇到呢）。在此基础上，对AOSP的DownloadProvider进行了一番研究，源码资源大家可以访问http://androidxref.com/，最新的Android
Oreo源码也可以在上面查阅。
 
下面的调查以Android7.0和Android8.0的DownloadProvider源码为基础展开。将探讨两个问题：
（1）进度条样式为什么是进度模糊样式？
（2）0K文件是否真正意义上下载成功了？
 
Android的本地下载分为三部分：
1、frameworks/base/core/java/android/app/下的DownloadManager.java和frameworks/base/core/java/android/provider/下的Downloads.java
2、packages/apps/providers/下的DownloadProvider
3、frameworks/base/packages/下的DocumentsUI
其中，DocumentsUI就是我们常见的下载列表。而DownloadManager.java就是开放给开发者调用的下载器，也是系统自身使用的下载器，Downloads.java负责表路径和下载状态标记的管理，DownloadProvider负责下载过程中数据的处理和展示。鉴于ANDROID下载机制中，默认下载进度是以通知的形式展示的，所以我通过检索Notification，发现只在DownloadProvider中出现了调用，那么问题的根源可能就存在在DownloadProvider中。
 
DownloadProvider类目录结构如下：



可以发现一个很明显的DownloadNotifier.java，分析其代码，DownloadNotifier在构造函数中创建了一个NotificationManager对象，代码详情如下：

DownloadNotifier的构造函数（Android8.0）
public DownloadNotifier(Context context) {
mContext = context;
mNotifManager = context.getSystemService(NotificationManager.class);

// Ensure that all our channels are ready to use
mNotifManager.createNotificationChannel(new NotificationChannel(CHANNEL_ACTIVE,
context.getText(R.string.download_running),
NotificationManager.IMPORTANCE_LOW));
mNotifManager.createNotificationChannel(new NotificationChannel(CHANNEL_WAITING,
context.getText(R.string.download_queued),
NotificationManager.IMPORTANCE_DEFAULT));
mNotifManager.createNotificationChannel(new NotificationChannel(CHANNEL_COMPLETE,
context.getText(com.android.internal.R.string.done_label),
NotificationManager.IMPORTANCE_DEFAULT));
}

DownloadNotifier的构造函数（Android8.0以下）
public DownloadNotifier(Context context) {
mContext = context;
mNotifManager = (NotificationManager) context.getSystemService(
Context.NOTIFICATION_SERVICE);
}

更新下载通知的操作由update()（低版本中叫updateWith()）来实现，该方法将被具体的下载线程进行调用，而通知样式围绕下载状态标记的具体实现则是updateWithLocked()内部的一个私有方法updateWithLocked(Cursor
cursor)（这个方法名一直没有变），代码详情如下：

Android7.0及以上
public void update() {
try (Cursor cursor = mContext.getContentResolver().query(
Downloads.Impl.ALL_DOWNLOADS_CONTENT_URI, UpdateQuery.PROJECTION,
Downloads.Impl.COLUMN_DELETED + " == '0'", null, null)) {
synchronized (mActiveNotifs) {
updateWithLocked(cursor);
}
}
}
Android7.0以下
public void updateWith(Collection<DownloadInfo> downloads) {
synchronized (mActiveNotifs) {
updateWithLocked(downloads);
}
}

在解析updateWithLocked()方法前，先介绍下DownloadProvider是如何调用DownloadNotifier.update()方法的。DownloadProvider下载运行图如下：



下载记录是统一保存在Downloads.Impl.ALL_DOWNLOADS_CONTENT_URI指向的表中，当用户执行下载操作时，系统通过URI调起DownloadProvider.java，该类负责统一管理DownloadProvider下各类的使用，首先初始化待访问的数据集合DownloadInfo，启动DownloadJobService管理本次下载，DownloadJobService会把DownloadProvider提供的DownloadInfo交给DownloadThread完成更新和操作，同时具体的数据读写也在DownloadThread中完成。DownloadJobService会先注册一个数据监听器：

public void onCreate() {
super.onCreate();
getContentResolver().registerContentObserver(ALL_DOWNLOADS_CONTENT_URI, true, mObserver);
}

private ContentObserver mObserver = new ContentObserver(Helpers.getAsyncHandler()) {
@Override
public void onChange(boolean selfChange) {
Helpers.getDownloadNotifier(DownloadJobService.this).update();
}
};

监听下载过程中数据库的变化，及时调用DownloadNotifier.update()更新进度条。等到下载结束时，DownloadThread会再一次调用DownloadNotifier.update()。这便是下载中通知变化的流程。

下面来分析下updateWithLocked()中对通知更新的实现流程，总体上可以分成三步走：
1、不管入参是Cursor还是ArrayList<DoenloadInfo>，都是通过访问Downloads.Impl.ALL_DOWNLOADS_CONTENT_URI(content://downloads/all_downloads)获得当前下载记录。针对每条数据，根据status和visibility字段生成一个标记，作为key,一并保存到ArrayMap<String,
IntArray> clustered中。
   标记整体分为两部分：下载状态；当前调用下载的应用包名/下载记录的ID
    标记生成方法如下：buildNotificationTag(Cursor cursor)

private static String buildNotificationTag(Cursor cursor) {
final long id = cursor.getLong(UpdateQuery._ID);
final int status = cursor.getInt(UpdateQuery.STATUS);
final int visibility = cursor.getInt(UpdateQuery.VISIBILITY);
final String notifPackage = cursor.getString(UpdateQuery.NOTIFICATION_PACKAGE);

if (isQueuedAndVisible(status, visibility)) {
return TYPE_WAITING + ":" + notifPackage;
} else if (isActiveAndVisible(status, visibility)) {
return TYPE_ACTIVE + ":" + notifPackage;
} else if (isCompleteAndVisible(status, visibility)) {
// Complete downloads always have unique notifs
return TYPE_COMPLETE + ":" + id;
} else {
return null;
}
}

2、对clustered中每一条下载记录创建一条对应的通知对象。此时用到了一个全局变量mActiveNotifs,存放当前活跃的通知。
    private final ArrayMap<String, Long> mActiveNotifs = new ArrayMap<>();
根据clustered中提供的标记通过getNotificationTagType方法提取中下载类型type，实际上通过getNotificationTagType的实现代码，type就是步骤1中提到的下载状态，getNotificationTagType实现代码如下：

private static int getNotificationTagType(String tag) {
return Integer.parseInt(tag.substring(0, tag.indexOf(':')));
}

根据type的不同，通知将配置不同的文字、图片等样式，
3、删除未更新的过期通知。即只展示当前正在下载的通知。

关键看步骤2中当前进度的计算这段逻辑，代码如下：

// Calculate and show progress
String remainingText = null;
String percentText = null;
if (type == TYPE_ACTIVE) {
long current = 0;
long total = 0;
long speed = 0;
synchronized (mDownloadSpeed) {
for (int j = 0; j < cluster.size(); j++) {
cursor.moveToPosition(cluster.get(j));

final long id = cursor.getLong(UpdateQuery._ID);
final long currentBytes = cursor.getLong(UpdateQuery.CURRENT_BYTES);
final long totalBytes = cursor.getLong(UpdateQuery.TOTAL_BYTES);

if (totalBytes != -1) {
current += currentBytes;
total += totalBytes;
speed += mDownloadSpeed.get(id);
}
}
}
if (total > 0) {
percentText =
NumberFormat.getPercentInstance().format((double) current / total);

if (speed > 0) {
final long remainingMillis = ((total - current) * 1000) / speed;
remainingText = res.getString(R.string.download_remaining,
DateUtils.formatDuration(remainingMillis));
}

final int percent = (int) ((current * 100) / total);
builder.setProgress(100, percent, false);
} else {
builder.setProgress(100, 0, true);
}
}

mNotifManager.notify(tag, 0, notif);

进度值的计算是在状态标记为TYPE_ACTIVE时才会触发。那么什么时候进入TYPE_ACTIVE状态呢，Downloads提供了详细的下载状态，但是DownloadManager可以更清晰的告诉我们。DownloadManager在Downloads基础上转化成五种下载状态：
  DownloadManager.STATUS_PENDING
  DownloadManager.STATUS_RUNNING
  DownloadManager.STATUS_PAUSED
  DownloadManager.STATUS_SUCCESSFUL
  DownloadManager.STATUS_FAILED
任何一次下载都要经过 STATUS_PENDING->STATUS_RUNNING->STATUS_SUCCESSFUL/STATUS_FAILED 这样一个过程。重看buildNotificationTag()，你会发现TYPE_ACTIVE是通过isActiveAndVisible()生成的，代码如下：

private static boolean isActiveAndVisible(int status, int visibility) {
return status == STATUS_RUNNING &&
(visibility == VISIBILITY_VISIBLE
|| visibility == VISIBILITY_VISIBLE_NOTIFY_COMPLETED);
}

STATUS_RUNNING表示当前下载链接已经建立成功，开始获取文件大小，并执行下载。换句话说，STATUS_RUNNING阶段不会因为文件大小是0K，就直接从STATUS_PENDING执行到STATUS_SUCCESSFUL/STATUS_FAILED，这是一个必要的过程。所以0K大小的文件下载时也会执行进度值计算。进度百分比percent分别通过字段total_bytes和current_bytes提供，total_bytes默认值为-1，只有当成功获取到文件大小时才会被赋值。正常下载过程中，进度条设置为builder.setProgress(100,
percent, false);当下载状态为TYPE_ACTIVE且下载文件大小为0时，进度条设置为builder.setProgress(100, 0, true);这个true表示当前进度条为非明确样式，即表示进度的加载条充满进度槽并持续滚动，这样就导致了下载0K文件时进度条样式的不统一。
进度条样式的问题到这里就可以告一段落了，关于0K文件是否下载成功，我们可以回看DownloadThread。DownloadThread中读写操作是有transferData(InputStream
in, OutputStream out, FileDescriptor outFd)来实现。这里有一个入参FileDescriptor。顾名思义它会先创建一个待写入的目标文件。transferData()中的读写操作如下：

private void transferData(InputStream in, OutputStream out, FileDescriptor outFd)throws StopRequestException {
final byte buffer[] = new byte[Constants.BUFFER_SIZE];
while (true) {
if (mPolicyDirty) checkConnectivity();

if (mShutdownRequested) {
throw new StopRequestException(STATUS_HTTP_DATA_ERROR,
"Local halt requested; job probably timed out");
}

int len = -1;
try {
len = in.read(buffer);
} catch (IOException e) {
throw new StopRequestException(
STATUS_HTTP_DATA_ERROR, "Failed reading response: " + e, e);
}

if (len == -1) {
break;
}
try {
// When streaming, ensure space before each write
if (mInfoDelta.mTotalBytes == -1) {
final long curSize = Os.fstat(outFd).st_size;
final long newBytes = (mInfoDelta.mCurrentBytes + len) - curSize;

StorageUtils.ensureAvailableSpace(mContext, outFd, newBytes);
}

out.write(buffer, 0, len);

mMadeProgress = true;
mInfoDelta.mCurrentBytes += len;

updateProgress(outFd);

} catch (ErrnoException e) {
throw new StopRequestException(STATUS_FILE_ERROR, e);
} catch (IOException e) {
throw new StopRequestException(STATUS_FILE_ERROR, e);
}
}
...
}

由于是一个0K文件，in.read(buffer)实际上是读不到数据的，所以len依然是-1，这就导致while循环不能完整执行，后续的写入操作、标志更新操作等都没有被执行，由于又没有异常产生，通知页面便始终处于下载中状态，直到超时。所以我在本地存储路径下看到的文件，实际上是没有执行写入操作的，严格意义上并没有下载成功。
这就是关于0K大小文件的下载异常分析，虽然在平时的文件下载需求中不大会出现0K这种现象，但不代表着永远不会遇到，也许你下载的文件的是破损压缩文件、上传失败的压缩文件或者是标记文件，这种场景下还是要考虑进来的，毕竟存在即为合理。对于0K文件直接本地创建即可，无需执行读写操作。