Http progress listener has serious performance issue on Android

[fireonmac]

Http progress listener has serious performance issue on Android

[jkbz64]

To dampen the issue I would advise you @fireonmac to make sure you are removing the listeners after you have created them and don't need anymore and/or early exit for the specific files - or simply just do not subscribe multiple times, it will double the number of callbacks.

If you happen to use react or other library/framework which re-render children on component state change (where you might store the number of downloaded bytes), make sure the stored progress change doesn't actually do that!

[jkbz64]

Note: I'm not a maintainer but I did write the initial progress implementation.

iOS implementation uses .default NSURLSession which under the hood most likely uses variable "buffer" size depending on your device/network connection, whenever URLSessionDownloadDelegate calls back the
urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64) it returns bytesWritten incremented by the "buffer" length (assuming the buffer gets filled every time) and also might potentially postpone the call to the method so it may feel "better".

Currently the android implementation uses fixed buffer of 1024 bytes which will make roughly 100k calls for 100MB file to the progress listener - again, assuming the buffer gets filled everytime

@thomasvidas

Is there any specific reason buffer size of 1024 bytes was chosen? I think typical size for the network packet will be power of two in the range of 512b -> 32kb.
Raising the buffer size to let's say 8192 bytes would reduce number of listener calls by almost ten times on fast connections (where the problem is very apparent) and probably would alleviate the problem without having to go into much more complicated solutions for reasonable sized files. If you have nothing against I can open the PR, doesn't seem like a big deal considering progress isn't usually used for very small files.

[nurfgun]

am on the same team with @fireonmac. and i can confirm that we make sure that only one listener is attached at all time and the component containing percentage get refreshed only once in a while with a throttle. Not so much difference it makes thou.
We are currently using a fork of this repo with #195 as a temporary workaround and hope this resolves soon!
Thanks for your great work, @jkbz64 btw.