Low Memory?

We covered all low memory cases follow Processes and Threads, just feel free to use the FileDownloader, it will be following yours expect.

I. UI PROCESS

FileDownloader has very little data in this process, it just some running tasks objects.

UI Process is killed when it is Foreground process by the system

This case is almost impossible.

UI Process is killed when it is Background process by the system

This is a normal case. If your application is back to the background, the process is a background process, the system can kill them at any time to reclaim memory for a foreground, visible, or service process, so FileDownloader has been handled this case split to two situations:

1. When there are tasks running on Serial-Queue

When the UI process has been killed, the FileDownloadService Process(which is a service process) will continue to download some tasks have been posted to the FileDownloadService( you have received pending status for it ) and some tasks have not been posted to the FileDownloadService will be interrupted.

Rescue Experience: You can feel free to start the whole Serial-Queue again like before when your application is launched after that, FileDownloader will continue to download.

2. When there are tasks running in parallel

When the UI process has been killed, the FileDownloadService will continue to download all tasks( because of they are all downloading in parallel and the action of posting task to FileDownloadService is very short ), but because of the UI process is missing, so you can't receive any callback now.

Rescue Experience: You can feel free to start all tasks like before when your application is launched after that, and now you can receive all callbacks from now on normally.

II. DOWNLOAD PROCESS:

There is also very little memory is occupied on the Download process.

The Download process is always a service process unless you invoke FileDownloader#unBindServiceor FileDownloader#unBindServiceIfIdle to let it become an empty process(the system kill this kind of process very often), or you invoke FileDownloader#startForeground() to let it become a foreground process(the system will keep this kind of process alive as far as possible).

If the Download process is killed when there are some tasks is downloading, because the FileDownloadService is START_STICKY service, so the service will be restarted immediately, and in this time, if your UI process is alive, we have stored all interrupted tasks in the UI process, so we will try to continue to download all interrupted tasks.

---

FOLLOWING IS IN CHINESE.

低内存情况

非下载进程(一般是UI进程):

这边的数据并不多，只是一些队列数据，用不了多少内存。

前台进程数据被回收:

如果在前台的时候这个数据都被回收了, 你的应用应该也挂了。极低概率事件。

后台进程数据被回收:

一般事件, 如果是你的下载是UI进程启动的，如果你的UI进程处于后台进程(可以理解为应用被退到后台)状态，在内存不足的情况下会被回收(回收优先级高于服务进程)，此时分两种情况:

1. 是串行队列任务，在回收掉UI进程内存以后，下载进程会继续下载完已经pending到下载进程的那个任务，而还未pending到下载进程的任务会中断下载(由于任务驱动线性执行的是在UI进程); 有损体验: 下次进入应用重启启动整个队列，会继续上次的下载。

2. 是并行队列任务，在回收掉UI进程内存以后，下载进程会继续下载所有任务(所有已经pending到下载进程的任务，由于这里的pending速度是很快的，因此几乎是点击并行下载，所有任务在很短的时间内都已经pending到下载进程了)，而UI进程由于被回收，将不会收到所有的监听; 有损体验: 下次进入应用重新启动整个队列，就会和正常的下载启动一致，收到所有情况的监听。

下载进程:

对内存有一定的占用，但是并不多，每次启动进程会根据数据的有效性进行清理冗余数据，被回收是低概率事件

由于下载不断有不同的buffer占用内存，但是由于在下载时，是活跃的服务进程，因此被回收是低概率事件(会先回收完所有空进程、后台进程(后台应用)以后，如果内存还不够，才会回收该进程)。

即使被回收，也不会有任何问题。由于我们使用的是START_STICKY(如果不希望被重启可主动调用FileDownloader#unBindService/FileDownloader#unBindServiceIfIdle)，因此在内存足够的时候，下载进程会尝试重启(系统调度)，非下载进程(一般是UI进程) 接收到下载进程的连接，会继续下载与继续接收回调，下载进程也会断点续传没有下载完的所有任务(无论并行与串行)，不会影响体验。