I have an AIR app that is quiet big, and compile time is around 40-50 sec.
Good thing is that app is quiet modular, I could easily break it down to modules, and compile them as swc and then recompile only those modules in which I'm working on, like i could do with normal desktop apps. Is it possible to have the same approach on mobile? Is there any way to do that on IOS? As far as I know It would not be possible to load swc on IOS at runtime.
Any other ideas to bring compile time down?
AIR compiler for iOS compiles everything into a normal swf then compiles that swf again into iOS code, and that's where it takes ages!
But you can do a test build which takes some seconds though it runs slower but enough for testing especially if you're using a high end iOS device.
Related
My SpriteKit playground book averaged 15 FPS on my MacBook Pro.
Do playgrounds run slower than iOS device simulations? If I run the same playground book on my iPad Pro, will the FPS limitation be similar? Will other apps opened on my computer limit the speed of playgrounds?
EDIT:
Moving code such as subclasses and extensions to auxiliary code in the "Sources" folder of the playground book allow the simulation to run quicker because the code only compiles once.
On the Mac, Xcode's "Playgrounds" are super useful for quick experiments but, due to their nature, terribly slow for "real" tasks.
If your code is more than a few pages long, and/or involves working with the UI, as you do with SpriteKit, the Playground may become really slow, sometimes even unresponsive.
"Playgrounds" are part of Xcode and run on top of the iOS simulator - that's how they display graphics and UI in the "Assitant Editor". The iOS simulator is not really known to be fast either.
On the other hand, "Swift Playgrounds" on iOS is a completely different app, even if it shares a lot with its Mac cousin.
Most importantly, it runs in iOS on the real device, with the real hardware processing, not emulation, which makes it ideal to use for SpriteKit, as Apple themselves often shows in their demos.
I would therefore say that your code should indeed run faster/better/properly on the iPad version.
Even if of course, I can't really know, since I don't know your code - you will probably be the one telling us later if using the iPad version made a difference.
I'm working on an app that processes large float arrays, and I was extremely disappointed to find that Swift is apparently a good 10x slower than Python when running on my iPhone 5. I guess that can't be true, but I would have thought it true had I not tested the app in the Time Profiler and realized that it's probably not my algorithm or Swift's implementation causing the issues.
When the app is built for the profiler, it performs nicely: It does the processing in an imperceptibly small amount of time, as it should. But normally, if I hit the run button (play symbol) in Xcode to build and run, even with the compiler set to be Fastest, it takes almost 20 seconds to complete. (Code remains unchanged between builds.) It's ridiculously slow.
It's reasonably fast when I build and run in a simulator on my MacBook Pro, but even then it's slower than it is when built and run through the Time Profiler on my little iPhone 5.
The performance difference between builds is also present when I place the following test code in the application() function in AppDelegate, so I don't think it's a GUI/threading issue or anything. And the same test code runs quickly when implemented in Objective-C (in a separate app on my device) and Python on my Mac.
var nums: [Float] = []
for var i = 0; i < 250000; i++ {
nums.append(Float(i) * 0.001)
}
(This takes around 20 seconds unless run through the Time Profiler.)
Have any of you experienced anything like this before? I'd be immensely happy if you could help me figure this out.
You were building the app in Debug mode instead of Release mode. Debug mode is much easier to debug, but release mode generates faster code.
When building for Debug mode, the compiler inserts special debug symbols that help the debugger. I once tried to debug an app in Release mode and the debugger couldn't even find my variables. Release mode not only doesn't include those symbols, but it also optimizes your app, generating a binary that is much smaller and faster.
Here's how to switch between Debug and Release mode:
Click on your scheme in the top-left corner of Xcode.
Select "Edit Scheme..."
Click on the "Build Configuration" dropdown.
Change the build configuration to Release.
Rebuild your project.
(I am not providing an image here because I assume you know how to rebuild your project.)
I'm developing a reasonably simple app using Xamarin iOS and the smallest size I've gotten for the .app file is 13.5 MB.
I've performed all the recommended optimizations - no debug symbols, LVVM code generation, thumb-2, link all assemblies, single architecture only (ARMV7).
The first question is, does my 13.5 MB sound like something to be expected from Xamarin iOS, or am I likely doing something wrong?
The second question is, how much extra size overhead does Xamarin iOS add to an equivalent native implementation (roughly)?
The third question is, roughly how small can a Hello World app get compiled down to using Xamarin iOS?
The fourth question is, roughly how small can a native Hello World app get compiled down to?
The .dSYM is a directory that includes debugging symbols. This is not something you're shipping as part of your application (to your end users). Note that this is produced even in non-debugging builds since it allows you to symbolicate crash reports (that comes from end users running the release binary).
For the real application size you need to look at the .app directory.
You can learn quite a few tricks to reduce your application size (and build time) by watching this year Evolve video Advanced iOS Build mechanics. That will also answer the other questions you had.
Xamarin apps are a bit larger in release mode, as one would expect. As an example, looking at my binaries from two shipping apps, the binary + dlls are around 12m and 18m (I think I need to look into why the 18m one is so much bigger...). I would guess if I had done these in objective-c they would have been around half that size, from past experience building native apps.
If you're running debug hardware builds, they are enormous. the 12m example above jumps up to 96M (?!) for binary + dlls. Before I checked this, I had in my head that they doubled in size to deal with software debugger, but I guess there's a whole lot of other crap going in that I wasn't aware of.
We are building a large-scale app with AIR for iOS.
One constraint of an AIR app with the iOS packager is that there are no modules. It is possible to load SWF files, but any embedded actionscript code is ignored.
We are wondering what happens to an AIR app for iPad when the code size gets very large. Are you aware of any technique for dividing code up into logical load groups, or do app developers just rely on virtual memory to swap in only a subset (hopefully) of the entire binary image?
No, AIR does not allow package more than one primary SWF.
We have a quite large project and wanted to use modules as well.
Solution we ended up with was removing all embedded sources. That includes graphics and sounds libraries created by Flash IDE or [Embed] classes.
All resources are loaded at runtime using
Sound.load() for mp3/sounds
Loader.load() with asynchronous image decoding policy for png/jpeg/images
FileStream.openAsync() for other/binary data.
We had 36 MB SWF file, now it is only 1.4 MB plus all the external assets.
I've developed an iOS 5 application with a rather large cache stored in /Library/Caches. I've noticed that running the app on an actual ipad is getting very slow. As in 5 minutes or so just to launch the application. Without Xcode, the application launches quickly. There seems to be a correlation between the size of the cache and the amount of time it takes to run the application, as the application starts quickly with a minimal cache.
I'm assuming that Xcode is making a backup or something silly like this. Has anyone else experienced this, and if so is there a workaround?
EDIT: (for clarity)
The structure of /Library/Caches/ is:
./big_ass_image1.png
./big_ass_image2.png
...
./big_ass_imageN.png
I simply read them in with coregraphics at a later time. The issue is the speed at which Xcode actually runs my app on the ipad. It's upwards of 4 minutes, which makes on device development very difficult. I would use the simulator, but it's precisely these big data sets that need to be tested on device.
EDIT: (how the files get there)
The files get into the cache via downloading. And sadly, there's no way to limit the cache size (at least not at the 2 gigabyte level).