I kind of ranted about it couple years ago
but the general idea is still true
During the last Flash Online Conference, the RobotBlastPlanet caught my attention on this
It probably still gonna come as a rant but I gonna try to make it a bit nicer and cleaner
I don't care where you are coming from as a developer, as soon as you publish on mobile you gonna have to take care of the performances seriously
all the following are lame excuses
- "oh the tool is not performant my code is perfect"
no, your code is not perfect
- "it's AS3 / AIR / the AVM2 etc. that is slow"
no, you are carelessly using them
- "it should work like on the desktop"
no, you are on mobile, you have basically 10% of the resources of a desktop
It's simple you can try the blaming game, blaming anything else, and expect to be spoon fed a magic solution, or you can try to take responsibility.
As a developer, it is your responsibility to know in great details
- the language, here AS3
- the tools: compilers
- the runtime: Flash, AIR, etc.
- the environment: mobile
It's OK to came to mobile development and not know everything, but you gonna have to learn if your goal is to produce apps with the performance that the users are expecting.
First step is to avoid the stupid mistakes for lack of knowledge
Here inlining is just an example among others, again nothing gonna magically make your code faster.
The difference is to know that it exists and to know when to use it (or not) and why.
And sometimes I encounter developers that complain a lot about how things are slow but refuse to do the basic homework, like learning their compiler.
Some dev think they just have to click "compile" and that's it the job is done.
No, you have to know how your compiler is working to be able to extract the most of it.
And to know that you need to understand that all this happen on the command-line
go into your Flex or AIR SDK bin folder and list the options that are available
./mxmlc -help list
./mxmlc -help advanced
and to use a particular command
./mxmlc -help details optimize
a bit more
./mxmlc -help details advanced compiler
"advanced" is kind of important as by default some options are not shown
./mxmlc -help details inline
no keywords matched.
./mxmlc -help details advanced inline
turn on the inlining of functions (advanced)
But wait, that's only with the AIR SDK that contains ASC 2.0
mxmlc found in the Flex SDK, there it still uses ASC 1.0
there is no such options as
Morality: know your tools, know your compilers.
Now if you want to know more about inlining
- ByteArray - Introducing ASC 2.0
- Using the New Inline Metadata in ASC2
- GotoAndLearn - Inlining Functions with ASC 2.0 (video)
and, not to bash another forum, but dismissing the problem with "it's full of bug don't use it" is the kind of attitude I pointed above "can not be my code, must be the tool that is wrong and buggy", does not help one bit.
The thing is, if you really want to use inlining, you gonna have to read also the backward compatibility issues of ASC 2.0, know damn well your compiler and know exactly what you are doing.
And that's the whole problem with performances related to memory, it is a complex subject and you have to know a lot to be able to follow what's going on.
Second step is to avoid to waste other people time and better yourself, for that you really have to know how to debug.
Repeat after me:
there is no silver bullet, no magic things that suddenly gonna solve all your problems.
You owe to yourself to be precise and know exactly how to pinpoint the problem, and this is related to debugging and only you can do that.
The posts on stack overflow or other forums "it does not work, please help me", that's not gonna cut it.
This is the wrong approach, if at the first sign of trouble your reflex is to go on a forum and ask for help, you're not even trying to do your job.
On this wiki page ActionScript 3 / Debug, I started to list many different ways to debug AS3 code.
With any non-trivial code you will always gonna have bugs, the program with no bugs does not exists, in fact if you are experienced enough, by now you already have shipped programs where you know there are bugs.
Some bugs are "acceptable", maybe it just something cosmetics, a little glitch that happen only on very rare occasions, etc.
Other bugs are "unacceptable", because they simply crash the whole app or it makes it unusable, or when they happen everything goes to a crawl and it's usable but only few minutes, etc.
What is "acceptable" or "unacceptable" can be different for a lot of dev or team, here we are focusing on the nasty ones about memory and performances.
The memory leak bug, the more you use the app the more the app use memory.
The performances bug, the thing that froze the app for fe milliseconds and/or make it unresponsive.
Not only you need to know a lot of different way to debug your app (see the wiki page above), but when you encounter such bug the very first thing you need to do is to isolate it.
That's also what I'm pointing out in Adobe take a lot of shit in their bug reports.
Just knowing something does not work as it should is not enough, you have to know exactly how, exactly where.
Blaming Flash/AIR, asking Adobe "hey fix your shit", complaining on a forum, all those things are a pure waste of time.
The worst one being the forum post half explaining your bug with no context whatsoever, no example, no versioning of what tool/runtime you are using, and hope that some kind of saviour will be able to read your mind and point at the little option you forgot to click in an IDE that magically solve all your problems.
Even worst than that is applying some of the advices given in such forum and not even bothering coming back to say "bug solved" and giving the details of what you changed to make it work.
Learn to debug if you don't know how, absolutely isolate the bug, you should be able to show a sample of code of few lines that create the bug 100% of the time.
And from there all become so much simpler
- there is a bug in your code or your approach to the problem
fix it, problem solved
- you found a bug outside of your code
it could be an external AS3 library, an ANE, the Flash Player / AIR API, etc.
you have a sample you can include in a bug report so the people
responsible for it can replicate the bug and fix it
- 90% of the time you will not even have to go ask a question in a forum
Which lead me to the final stuff.
Step Three is learn, learn and learn some more, before you even need it.
If your problem is memory and performances for mobile devices, spending the time to make a list of devices, organised by Max memory allocation / max device memory is what I call doing your homework as a developer.
You will not see that kind of stuff in the basic documentation of AS3 or Flash or AIR, it is something you have to search and document for yourself.
Let's see what a 10mn search on google bring in term of learning material
There are plenty of documentations out there, if you don't read those you really can not complain about "why things are slow".
Memory and performances are not a new problem that affect only Adobe AIR app on mobile, those problems exists for decades in different kind of environment.
Above you can see specific to AS3 / Flash / AIR, but you can also find general stuff.
Also don't assume that a blog post is the end all and be all of content, go to the source find the original and you will probably find less diluted information.
My point is all that require work, do the actual work (yeah it's not fun that's why I call it work) and you will see the results.
You don't have to do it all in one run, just add bit by bit and in the long run those small things that are not very impressive by itself will add up.