I use four different file managers on my Android devices (because each has features that I use that aren’t included in the others). I use CX File Explorer for the bulk of my everyday management because it has the most user-friendly UI. Recently I’ve been transferring tens of gigabytes of files from my phone to a flash drive with a USB OTG adapter. File transfers have been extremely slow. A couple of hundred MB of 50+ MB/s transfer that is probably just filling a memory buffer followed by a drop to around a 2 MB/s transfer rate that slowly degrades from there to as low as 1 MB/s. I had chalked it up to the consequences of buying a cheap flash drive and just let the files trickle down a few GB at a time before unplugging and doing more later. But today I decided to try one of my other file managers, FX File Explorer. And FX, it turns out, copies over the files at a pretty consistent 18 MB/s. Which obviously still isn’t great, but seems like lightning compared to 1 to 2 MB/sec.
So now I’m wondering, any guesses why? The same files going from the same phone to the same USB drive but up to 18x difference in speed?
Android apps have to use the Google-provided Application Programming Interface to do pretty much anything; what’s likely to be happening here is that the API offers sufficiently diverse options to offer a choice of how an application might move files around.
Without knowing the actual details (I am not an Android developer) it may be, for example that there is just a ‘FileMove’ method that just hands the entire task off to the OS (and I would normally expect that way to be the most efficient), but there might also be other methods to create a new file, then copy over the data contents, then delete the original - essentially the same operations that an all-in-one method is doing behind the scenes, but less efficient if you have to ask for it piecemeal.
So developers of one app might not have done things the same way as for other apps - possibly just because they didn’t know, or maybe the app was developed a long time ago, before the full range of current API methods existed.
Or it might be that the really slow app just has a shoddy implementation of something, because incompetence - for example you mentioned that the transfer rate slows to a crawl progressively - it might be that the app is copying the file over in chunks, then verifying what was copied before copying the next chunk, but the verify operation might be comparing the whole amount copied - so as that grows, each verification cycle takes longer.
(all of the above is speculation, but the details are likely to be somewhat consistent with this)