使用FileDownloader提升下载速度办法

FileDownLoader框架在下载稍微大一点的文件时，下载速度不理想，经过实践发现，出现问题的原因主要体现在两点：
1、本身的bug。
2、下载策略的问题。

先说第一点：

1、本身的bug：

bug源自于框架本身的分块策略：

   // 1 connection: [0, 1MB)
    private static final long ONE_CONNECTION_UPPER_LIMIT = 1024 * 1024; // 1MB
    // 2 connection: [1MB, 5MB)
    private static final long TWO_CONNECTION_UPPER_LIMIT = 5 * 1024 * 1024; // 5MB
    // 3 connection: [5MB, 50MB)
    private static final long THREE_CONNECTION_UPPER_LIMIT = 50 * 1024 * 1024; // 50MB
    // 4 connection: [50MB, 100MB)
    private static final long FOUR_CONNECTION_UPPER_LIMIT = 100 * 1024 * 1024; // 100MB

    @Override
    public int determineConnectionCount(int downloadId, String url, String path, long totalLength) {
        if (totalLength < ONE_CONNECTION_UPPER_LIMIT) {
            return 1;
        }

        if (totalLength < TWO_CONNECTION_UPPER_LIMIT) {
            return 2;
        }

        if (totalLength < THREE_CONNECTION_UPPER_LIMIT) {
            return 3;
        }

        if (totalLength < FOUR_CONNECTION_UPPER_LIMIT) {
            return 4;
        }

        return 5;
}

默认逻辑是根据不同的文件大小，创建的下载连接数也不一样，文件总量越大，创建的块也越多，最大是5。在多个块的下载时候，框架内部可能对下载任务没有协调好，导致会偶现下载任务停住的问题，这样就给人一种下载很慢的感觉。

解决方案：
在Application中进行设置，将块的数量固定为1,这样可以解决偶现卡死的问题。

 private void initFileDownload() {
        FileDownloader.setupOnApplicationOnCreate(this)
                .connectionCreator(new FileDownloadUrlConnection
                        .Creator(new FileDownloadUrlConnection.Configuration()
                        .connectTimeout(15_000) // set connection timeout.
                        .readTimeout(15_000) // set read timeout.
                ))
                .connectionCountAdapter((downloadId, url, path, totalLength) -> {
                    return 1;//下载文件块数是1,解决偶现的下载任务停止问题。
                })
                .commit();
    }

作者的初衷可能也为了让下载速度有一个平衡才做了这样一个分块策略。
虽然我们规避了bug，但强行将块设置为1的话，下载速度肯定是不如多个块下载的，为了弥补这些损失，同时为了让本身的下载速度有进一步提升，我们做了第二点—下载策略的修改。

2、下载策略的问题。

所谓的策略，其实就是为了寻求某个平衡。
每一条小的策略肯定都有它的优点和缺点，为什么要这么做都有它的理由，如何定制一个最完美平衡的策略，需要我们开发者根据自己的需求去达成。

先看本身的下载策略有助于我们对 “为什么这样下载不是很快，改完就很快”这个问题的理解。
默认策略一：

process.non-separate=true // 开启子进程

为什么要这样：
默认开启子进程，根据作者的说法是，为了兼容老版本，保持行为的一致性。

带来的问题：

子进程和主进程频繁IPC，对CPU资源有着大量的消耗。
IPC过程中产生大量的I/O事件，数据传输成本高

解决这些不必要的通信事件，设置为

process.non-separate=false // 直接在主进程中下，可以有效减少IPC产生的I/O

默认策略二：

BaseDownloadTask#setCallbackProgressIgnored(void)
或者
FileDownloadQueueSet#ignoreEachTaskInternalProgress(void)
//忽略掉下载过程中的大量的进度值回调，减少计算进度而带来CPU的I/O消耗。

在我们的实际场景中，进度值是根据下载任务数/总任务数来计算的，而不是每一个下载小任务的进度回调。
所以我们根本用不上进度回调，直接加上这两条策略之一即可。

默认策略三：

download.max-network-thread-count=3
//默认开启3个线程下载，进程数区间在[1,12]。

下载线程越多当然更快，我们开启8-10个，提升效果明显。

默认策略四：

download.min-progress-step = 65536
最小缓冲大小，用于判定是否是时候将缓冲区中进度同步到数据库，以及是否是时候要确保下缓存区的数据都已经写文件。值越小，更新会越频繁，下载速度会越慢，但是应对进程被无法预料的情况杀死时会更加安全

这个改不改影响不大，正常情况不会下载那么长时间，如果有较大的问题可以酌情设置。

默认策略五：

ddownload.min-progress-time=2000
最小缓冲时间，用于判定是否是时候将缓冲区中进度同步到数据库，以及是否是时候要确保下缓存区的数据都已经写文件。值越小，更新会越频繁，下载速度会越慢，但是应对进程被无法预料的情况杀死时会更加安全

设置为5000秒，意外杀死的情况较少，并且较小的进度损失可以接受。

在assets文件夹底下创建一个filedownloader.properties文件，将上述配置引入即可。