When someone says an application needs to be optimized, you probably think that it must need to be faster. Though speed is a big part of the optimization needed to develop a mobile applications, or any application for that matter, it is hardly the only type of optimization you will face. Here are some others categories of optimization that will influence the final outcome of any mobile application project.
Heap usage is my personal favorite part of optimization. Not only do you have to worry about how much memory your application uses at its peak, you have to be aware of how it loads that memory, and how often it loads it. Heap fragmentation can be a much more serious issue than running out of memory, depending on your platform. If you are running out of memory you can just cut something, problem fixed. Heap frags a different animal.
Heap frag is when the application loads memory in a way that breaks the heap up into small, non-continuous chunks. Since all memory has to be loaded in one continuous block, you run the risk of not being able to allocate a larger object. What makes this issue so difficult and fun in a language like Java is that you have little control of how and where a block of memory is loading in the heap, or how the garbage collector goes through and cleans up unused objects (which you can be sure will differ from one manufacturer to another). It’s quite a tricky problem to battle, but I love tinkering with it.
Also, memory allocation is slow. How often and when you allocate objects will have a direct affect not only on the state of the heap, but also on the application performance from a speed and battery consumption standpoint.
Finally, the memory profiler is your best friend. It lets you take a look at exactly how your memory is loaded, how and when it’s cleaned up, and which part of the application is doing the most damage. Become familiar with the one available for your development language, it’s your best bet when optimizing heap usage.
When I started working in the mobile industry it wasn’t uncommon to have to keep the app size under 64K. Actually, as of February 2008 many game developers I spoke to at the GDC reported that they still needed to target 64K devices in Europe. Though generally it is not this constrained anymore, application size is still much more of a variable with mobile applications then it is with other platforms. The amount of storage space a device has is greatly dwarfed compared to a PC or a server. In a high-end smart phone you may have a gig of device memory with an SD card slot that can support between 8 and 16 gigs. That’s the high-end phones. That’s not what your average customer is going to be carrying.
On top of that, how long and how much it costs to download your application has to be taken into consideration. If your app is too large, this might be a barrier that potential customers can not get past. All-you-can-eat data plans and 3G networks should help with this issues, but for now I think it is still a valid optimization worth its costs.
There are two types of speed, actual speed and perceived speed. The overall speed of the application is important, but no where near as important as how fast the user perceives an application to be, especially within the mobile environment. Lots of things lag by nature in the mobile space, things completely out of your control. Connectivity for one. Your app could sit for several minutes while communication occurs with the server. How you handle these types of situations will be key to keeping your users happy. If they are left sitting there with no notification that some kind of processing is happening, they are going to think the app either crashed or is incredibly slow. It is an important subject matter, one that is constantly being researched and constantly needs to be taken into consideration when developing mobile apps. The general rule of thumb…if the processing time is going to take more than 2-3 seconds, you better notify the user.
But, overall application speed is important too. If the application lags, if user input doesn’t feel “snappy”, doesn’t supply immediate feedback based on their action, the user is going to feel frustrated. The profiler is again your best friend as there is no better way to get an understanding of what is going on under the hood. Whether it’s a slow implementation of an algorithm, how memory is being allocated and used, how data is being passed around, the profiler will be able to show you a good place to start investigating.
Battery life is a tricky one. Just ask the manufacturers. They are constantly getting hammered in reviews for this very issue. And, as mobile applications become a bigger part of the wireless industry, the affect on the battery is going to be more in the hands of third party developers creating the applications. Let me tell you right now, if you have an app that is chewing through the battery of a device, the manufacturers and the carriers are going to be pissed. User’s are going to be pissed. No one is going to buy your application, no one is going to be willing to sell your application. Battery life is the most important issue in the mobile industry. If your use of the battery is unacceptable, nothing else matters.
Finally, mobile devices have very limited input capabilities for their users. Even with a full QWERTY pad, it is no comparison to sitting at a desktop machine with a mouse and a keyboard in which you can use all ten fingers instead of two clumsy thumbs. So, optimizing the user experience is a very important part of the process. And with so many different input methods available now, the previously mentioned QWERTY pad, SureType, touchscreen and the classic numeric pad, several different approaches will need to be taken to provide the best experience for all of your customer.
All of these subjects are important, some more than others, some are actually getting less important as the industry matures, but all are still important and worth talking about. My next Mobile Development post will tackle a more specific topic related to optimizing mobile apps.
