-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Optimize Tutorial
Since the new architecture support multi-connection I test on my home, it can use all resources on my network (the broadband on my home is 100Mb/s):
36MB file can be finished on about 3.082s:
Through set process.non-separate=true
in filedownloader.properties to let the FileDownloader service runs in the main process.
Improve download speed.
- Reduce CPU consume for IPC and the separate process maintain.
- Reduce I/O consume for IPC.
The FileDownloader service runs in the main process.
If your need your download works in the background what means you want the FileDownloader service isolated in the background which lifecycle is decoupling with the main process, in this case, you need to be very careful to consider whether this optimization is necessary.
2. BaseDownloadTask#setCallbackProgressIgnored(void)
or FileDownloadQueueSet#ignoreEachTaskInternalProgress(void)
Ignore all callbacks of FileDownloadListener#progress
during the entire process of downloading.
Improve download performance.
- Reduce CPU and I/O consume for transfer the
progress
callbacks.
You will not receive any FileDownloadListener#progress
method callback during the entire process of downloading.
If you indeed care about the downloading progress
during the downloading process, maybe you need alternative BaseDownloadTask#setCallbackProgressTimes
and BaseDownloadTask#setCallbackProgressMinInterval
.
NOT RECOMMEND ANYMORE, because FileDownloadBufferedOutputStream
can't support seek, what means FileDownloader can't download file on the multi-connections(the multi-connections feature is supported since v1.5.0
).
Through initializes the FileDownloader with:
FileDownloader.init(getApplicationContext(),
new DownloadMgrInitialParams.InitCustomMaker().
outputStreamCreator(new FileDownloadBufferedOutputStream.Creator()));
and set file.non-pre-allocation=true
in filedownloader.properties to let FileDownloader doesn't pre-allocate the entire length file in the very beginning of download, because FileDownloadBufferedOutputStream
can't support the seek
function.
Improve download speed.
- The I/O rule in the
BufferedOutputStream
is better than the rule in the default output stream componentRandomAccessFile
for FileDownloader(More statistic ref here).
Since the FileDownloadBufferedOutputStream
uses BufferedOutputStream
as the output stream component which doesn't support the seek
function, if FileDownloader pre-allocates file size at the beginning of the download, it will can not be resumed from the breakpoint. If you need FileDownloader can pre-allocates the entire length file in the very beginning of download for preventing occur FileDownloadOutOfSpaceException
during the downloading process, you have to give up this optimization to use the default output stream component, or implement you own output stream component.
More detail please move to here.
FileDownloader#disableAvoidDropFrame()
-
BaseDownloadTask#addFinishListener(FinishListener)
instead ofBaseDownloadTask#setListener(FileDownloadListener)
BaseDownloadTask#setSyncCallback(true)
-
download.min-progress-step
、download.min-progress-time
infiledownloader.properties
- Initialization
- Start downloading
- Pause or Stop
- Get the internal stored data
- Customizable Component
- Interface