We cannot present every good algorithm that might address your needs in this study, but in addition to the general solutions, we present here some low level tips and architecture ideas. We suggest you get in touch with other professionals in your area to trade ideas and develop better applications.
This study divides performance issues broadly into two sections: Mobile front end architecture and Low level performance optimisation. Of the two, architecture and algorithm improvements can give a significant speed boost to your application than low level performance tricks. Think of low level optimisation as a set of habits that are integral to your programming style and which you exercise all the time (not just at the end of a project). Think of front end architecture as not just traditional technical designs, but as a discipline where your experience in a given problem domain (gaming, news, media, and so on) can be extremely valuable knowledge of what actually works in the field and allows you to anticipate the side effects of your technical choices and how users will react to them.
Keep in mind that the phone in front of you has 1/1000 of the processing speed, 1/1000 of the available memory space, as well as power limitations, battery life considerations and a host of other technical and hardware distinctions that make it quite different from the desktop or laptop computer you use. In addition, mobile phone users demand that we rapidly deliver pixels to the screen, arranged meaningfully to inform and entertain them in short bursts of activity, before they put the phone back in their pocket and continue their lifestyle.
You will find a many performance tips on the Internet and in the books. Some information is old and not applicable to current mobile hardware and some is simply misapplied when taken into the rough-and-tumble mobile space where applications start and stop quickly and must contend with data networks that are in many situations slow and unreliable.
When you make a performance mistake or deliver a service that is really responsive, mobile users take it personally. The performance is instantly visible to mobile users. Nokia Series 40 is the most successful and widely used mobile application platform on the planet with over 1.5 billion phones sold and most of those are currently in use. This, and the challenge of doing more in a smaller space, makes Series 40 performance optimisation one of the most rewarding opportunities for using your coding skills to make a real difference to people.
When developing a MIDlet, naturally your MIDlet’s basic functionality is important. But equally important is the User Experience (UX) – how it feels when that functionality is delivered. One of the most critical aspects in UX is the performance of the application. Your graphics artist will provide you with nice artwork and flow diagrams linking the various parts of the application together. It is up to you, the developer, to bring that to life. Achieving a great UX in how you animate and move through an application is the point – this is why we focus on performance.
UX matters for all types of MIDlets. If your application does what is needed, but functions so slowly that you cannot really get any value from the features, the value of the application is quite minimal. For example, if you have a game with very attractive graphics but they crawl slowly across the screen, or it takes forever to get the game started, users will rate you poorly in the store and this hurts your future downloads. Even if your application is for business and contains mostly buttons and lists, it is important to give the end-user a fast response time and allow them to get on to other things they need to do.
Miller’s1 advice regarding UX and response times which can be summarized as follows:
0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users may like to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users do not know what to expect.
Better performance can be achieved with different optimisations. It is good to keep some key points in mind:
Use small scale optimisations as a habit when coding, but do not rely on these to compensate for poor algorithm or structure.
Keep it simple. Less code and less layers of abstraction are usually preferred in mobile applications. Most mobile apps do not have a 10 year lifespan, so be practical about how elegantly over-engineered to make your basic application structure.
Be cautious when taking code from the internet, understand and improve the code as you use it. Use trusted libraries which are optimised and specifically support Nokia Series 40 to ensure you will not spend your time cleaning up or compensating for someone else’s code.
Comment carefully any optimisations which make the code less easy to understand. Use long descriptive variable, method, and class names to keep the code readable as you improve the performance and perhaps fail to update the descriptive comments.
Reserve time at the end of the project for performance testing, profiling and tuning. The problems are likely to be in just a few places, and often not where you were expecting them. Speed measurements on the phone are the only way to see the results of your changes.
Know when to stop, and only optimise parts that clearly harm the performance. You can significantly slow your development by tuning and re-tuning non-critical areas of the program and thereby breaking things which will need to be fixed again.
Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277
Last updated 9 October 2013