Skip to main content
A
AllanPadgett
Participating Frequently
June 18, 2013
Question

File.copyTo (and copyToAsync) extremely slow on Android. e.g. 1/2 second per tiny XML file. Help?

  • June 18, 2013
  • 2 replies
  • 6516 views

On first launch, my app copies about 100 tiny XML files from application dir to storage dir. It takes about 35 seconds. That is clearly an issue. It takes about 1/100th of a second on any other platform. I've switched to copyToAsync() so that the user doesn't bail, but still this is like using a dial-up modem! Anyone have any thoughts?

This topic has been closed for replies.

2 replies

Abhinav_Dhandh
Adobe Employee
Abhinav_Dhandh
Adobe Employee
June 20, 2013

Hi Allan

I tried to reproduce this issue in which I have copied 100 XML's from application directory to applicationStorage directory in Android AIR app. The issue is not reproducible as the files were copied almost instantaneously within 1-2 seconds.

I have shared my sample project here :  https://dl.dropboxusercontent.com/u/184715790/Shared/FileCopyToTest.zip

Additionally, I have also attached the .apk : https://dl.dropboxusercontent.com/u/184715790/Shared/FileCopyToTest.apk

You could try it out and confirm if the issue is still visible.

Also could you inform about your device, OS version & AIR version which you are using ?

Regards,

Abhinav

A
AllanPadgettAuthor
Participating Frequently
June 21, 2013

Hi Abhinav -

I notice that my test is Flex. Your test is pure AS3. You are also using the beta 3.8 release, not an official public release?

I will get the 3.8 beta. Could you also build a 3.7.1 Flex test? Or test the one I sent via Gen?

Thanks,

Allan

A
AllanPadgettAuthor
Participating Frequently
August 8, 2013

Allan,

Crazy good results to report with the idea of simply adding a .zip of the files as a resource into the .apk, then just doing a copyTo of the single zip file, and externally unzipping the contents within the File.applicationStorageDirectory

I took the exact same help/ folder of 170 files totalling 6 MB+, Zipped it into a single 5MB+ help.zip

Added that help.zip as a single bundled resource for the .apk

Then doing a single file copy

var source:File = File.applicationDirectory.resolvePath("help.zip");

var destination:File = File.applicationStorageDirectory.resolvePath("help.zip");

source.copyTo(destination, true);

followed by a very basic and efficient Java expand zip function using builtin Java File IO classes

and simply placing the extract(sourceZipPath, targetFolder) functionality into an Android ANE for the app.

What originally took 20sec+ on a first gen Kindle Fire and Google Nexus 7

now takes less than 3 seconds on the Kindle File and only less than half a second on a Google Nexus 7!

So huge win in my case.

There must definitely be an expensive issue of doing a mass copyTo with nested files that are from the source zipped .apk  Would be great if Adobe could speed this up, or maybe as a fallback they should add builtin Zip decompression in the AIR API so developers can make easier use of zipped resource file sets.

I see that Adobe staff replied with a sample project where they were not able to duplicate the slowdown.

I was using an 'Export Release Build... ' packaged .apk, so maybe extra compression or slowness results from different packaging modes, who knows, but it is something I am definitely seeing on the latest AIR 3.8 SDK and on multiple Android device types.


Thanks for the great update. Would you be willing to share / sell me your ANE and sample code? Never built an ANE and with 3 races left this year, don't plan on having the time to learn. Very nice work!

Allan

Allan Padgett, CEO

Tour Tracker LLC

email: tourtracker@gmail.com

web: http://thetourtracker.com

twitter: @tourtracker

facebook: http://facebook.com/thetourtracker

D
Adobe Employee
Damanjit Singh
Adobe Employee
June 19, 2013

One reason could be that the Android package is a zipped format, thus copying a folder, with multiple files, from app directory, requires extracting the zipped bytes for each file in the folder, unzipping it, and then copying it to the destination.

Though it would be great if you could file a bug with a sample application (with code) do that we could reproduce and analyze at our end.

Thanks,

Daman

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices