Flash Lite 2: Low RAM, Optimizing via Degraded Ego

Can’t sleep, so here are a couple trends I keep noticing I do in my Flash Lite 2 development.

First off, I keep running out of RAM. The forms I had the designer create from my wireframes won’t work because the wireframes were flawed. In designing them, I had no idea that some of the designs simply wouldn’t work based on the fact that there were too many GUI controls on the screen at one time. The negative is that I am forced to create more classes that represent forms… which actually use RAM by their very existence. Classes in ActionScript 2 are actual prototype objects vs. blueprints like in other languages, and thus physically exist as objects. In effect, I’m merely delaying the inevitable, and making it harder for others to play later. The positive is, my GUI’s are forced to be extremely simple. Simple is good, right? Screen 7 of the wizard? *sigh*…

Related to the above, some controls I’ve been creating hit limits mainly with regards to CPU before RAM. When I fix the CPU problems, which usually are stack overflows or script timeout limits (which on my phone feel like 2 seconds, not 15), I then start to run out of RAM again. Thus, I have to start optimizing my code before it’s even written.

How do you optimize ActionScript 2? Same way you optimize ActionScript 1, with the addition that you have to “drop the ego” as Branden Hall said to me in the past. I’m not sure he meant it in this context, but it fits. This hurts more in AS2 than in AS1. Ego meaning, “loyalty to good programming practices”.

For example, using vector vs. bitmap graphics because vectors use less RAM doesn’t make me hurt. But, these do:

Less Inheritance

Prototype chain lookups are slow. Therefore, the more inheritance I use, the more I hurt myself. Huh!?!?!

For example, I wrote a Calendar component. Getting that S.O.B. to run on a variety of phones out there and NOT CRASH was a feat unto itself. While neato, it still didn’t play nice with others… since it used about 1200k of RAM; that’s a meg and 200k. My Nokia 6680 only has 2 megs. So, putting a design + a button and some labels wouldn’t fly if a developer wanted to do so. That’s just uncool. A component set should make the developer feel happy to use various controls together, not scared. I must crush all fear.

Solution? Reduce the OOP’ness of CalendarDay. What’s CalendarDay? A Calendar is typically a control that draws a bunch of weeks in rows, and each row has a bunch of days, like Sunday, Monday, Tuesday, etc. These 7 days are put in 6 rows. That way, you can safely show most months with last month’s week at the top, and next month’s week at the bottom. These day’s are effectively a bunch of MovieClip’s, 42 to be precise, drawn in a grid. The CPU required to draw 30 of anything in Flash is insane pre-Flash Player 9, let alone 42. …and this is on an ARM processor.

So, it takes me 5 passes to draw things. Create data, attach mc’s, position mc’s, set mc’s data, and finally color mc’s. That equates to 14 seconds in total on my phone (you see it draw at 9), and 8 seconds total on faster N90’s and E70 models.

These mc’s are an instance of CalendarDay. He originally was all cool, had public setters for his data and colors, which all would invalidate at the proper time, and were extremely flexible; ripe for use in a Calendar. Problem? They were cool. I ripped it all out, extended MovieClip instead of my (custom) base UIComponent class, and provided simple methods with no invalidation. I refused to change the package name, though. That, plus some other minor modifications & optimizations netted me:

342k total used RAM.

w00t! In my drunken stupor of celebrating, I notice the code was… well, it sucked. But it works. I’ve always been the biggest proponent that the metric for cool code is code that works vs. code that looks great, but doesn’t do anything. Why, then, do I have such a problem not smiling when I dive into that “class” now?

EventDispatcher is Slow

Almost a second or more dispatching events; remember, I only have about 2 seconds per stack process per frame, so I’ve been trying to use callbacks where possible which equate to only 1 object capable of listening for the event vs. multiple like EventDispatcher supports. Thankfully, this is a rare use case, but… more code for me to write, and still have 2 extra variables + method call to make. EventDispatcher via it’s decoration of objects actually adds enough stuff to equate to this, but at least I don’t have to see it, hehe.

I haven’t succumbed to having children calling known methods on parents yet via _parent.onSomeEvent. I don’t think interfaces could even justify that move… but… it’d save writing 2 properties and a method. That’s 3 slots, per instance used… ugh.

There was a reason EventDispatcher was ported to native C code in Flash Player 9; it’s the main workhorse for GUI coders and was the main bottleneck in pre-Flash Player 9 large projects.

Shorter Method and Property Names

Since Flash Lite 2 runs in the interpreted AVM, the length of the string name used to find the method / property name directly affects the speed in which it takes to run. Shorter method names? Faster to run. Less RAM, and more compact bytecode which equals faster code.

Problem? When I started programming, I read in books, blogs, and websites that encourage short, concise method names that used abbreviations and said those were good to do. Now, I think all the people who wrote the books, blogs, and websites are crackheads and I pray to God I never have to maintain their code in a future project. My methods and properties are about as verbose as can be without being audacious. If you ever question what a property is, or what a method does, I consider that a failure on the programmer’s part in naming.

…yet, here I am thinking of changing setCurrentFromDate to setCurFrD, or even scfd. Properties are even worse; __currentDate to cd. The only thing left to make sense of the cryptic hieroglyphics I’ll write will be the strong typing, but that merely helps confirm suspicions, not convey facts. Horrible… but hey, it’s compact, low RAM, and runs well right? Did anyone get a post-processor for ActionScript 1 / 2 bytecode for Christmas they don’t want? I could use one. Flasm doesn’t count.

What the 3 main issues above effectively make me do is constantly have to re-work my UI. For example, Google Calendar has these text fields for choosing a date. It shows something like “11/5/2006” in the field. If you click it, a Calendar component drops down below it so you can choose a value for the field to hold. I can do that in Flash. I can do that in Flex.

Flash Lite 2? Hah, you’re smokin’ dope, dude. Well, sure, I could do it… if those were the ONLY 2 components on stage. Bleh.

…thus, I have to beg the designer to discuss “solutions”. It’s rough, I’ve already ravaged the design enough, and will have to devote at least a week (last week in February) to make sure the design is up to the designer’s standards before I submit to the Flash Lite contest.

I swear, I’m this close to making a branch in SVN, and creating a “AS2 coder friendly” branch and a “AS1, fugly but optimized” branch for the component framework. This stuff is hard, yo. Purely masochistic at this point. I wanted a challenge and I sure got one. It’d be easier if I could just drop the ego like Branden said, and code lightweight AS1. So… hard… to let… go…

8 Replies to “Flash Lite 2: Low RAM, Optimizing via Degraded Ego”

  1. What device are you using? I have created some pretty complex applications without memory issues. A calendar component is tough but I think it can be done. Did you run out of memory or get actionscript stuck? You have to be careful of loops. If you can create a static layout.

  2. Ciao Jesse,

    in my experience I run out of memory even though I was sure to have enough free. One question that I looking an answer for is about memory allocation and fragmentation on mobile phones by the Flash Lite player. It would be interesting to have some information on this topic from Adobe.


  3. How are you coding Greg? I’m using ActionScript 2, mirroring the UIComponent setup of Flash MX 2004 somewhat, with the invalidation mechinism of Flex 2. Are you just extending MovieClip, and not using sophisticated controls, or do you just have really higher end phones?

  4. Old school Flash game developers will tell you that OOP is not the way to go when you need to squeeze maximum performance out of Flash. Procedural code, terse naming conventions, and negative while loops that result in less byte code being written are key.

    What I recommend if you need to use method names like scfd and also maintain code easily is use something like gModeler to write docs for you. This keeps comments from mucking up your code.

    I’ve got some compact AS1 procedural calendar code if you want it. Hit me up on AIM.

  5. I did some testing of fragmentation about a year and a half ago on flashlite and it turns out there is barely any! The one problem to be aware of though is if the memory hits its upper limit the memory manager will not try to GC before reporting an error. This means if you have a ton of variables dereferened and ready to go it won’t matter. So be careful about that (it is a tricky one)

    Jesse – I can’t talk too much about what I work on but I will tell you it was complex and comparable to Flex 2, FP9 code/components.

  6. Hm. You mention ‘Flash Lite’, ‘Calendar component’, ‘CalendarDay’, and ‘Google Calendar’. You’ve peaked my curiousity. Might you be building something like my Flash Lite 1.1 Mobile Google Calendar? I can’t wait to see your finished product.

    And, I totally agree with you that Flash Lite 2 is a Presentation Layer. My Flash Lite calendar relies on a server layer, too. But then, Google doesn’t have crossdomain files to hit GData so any mobile Google Flash calendar would need one.

    Good luck. Excited to see the finished product.


  7. Ali, when I started this project, I was like… geez, almost a week into it, and I saw your blog entry on it. I was floored with what you had done in Flash Lite 1.1, so I think I almost lost a week of steam… I was like, ‘Holy crap! That’s the bar!!!!???!?!?!’

    However, in the end, my app is merely to showcase what you can build with the Flash Lite 2 component set I’m building, so even if your’s p@wns, hopefully you’ll think about upgrading it to Flash Lite 2 using my set, hehe.

    Well, actually, you don’t need a crossdomain xml for Flash Player playing in projectors on your phone. The problem was parsing all that XML on the phone just didn’t really fly, and it was a lot of data to be pushing to people when all I really needed was tincy chunks of it so even if I do have to port to a web app, the service layer will help there.

  8. :) If I port, I’d love to use your components. I sure at hells don’t want to write another set of my own. I want to start shipping things! I’ll be looking for set. I look forward to ’em!

    You’re totally right about the crossdomain. You definitely don’t need one for the stand alone Flash Lite player. I’ve got a couple side projects that I get confused with one another, and one of my *other* projects got a little shafted by Google’s lack of crossdomain. My fault for the confusion…



Comments are closed.