Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Look For and Pay Attention to Performance Warning Signs

You ignore performance problems at your peril. Turning a blind eye and not looking for potential performance problems in your mobile device application's design is a sure way to invite problems down the road. Performance problems are best addressed when they are created, and it is at this point when they are easiest to diagnose. More than on a desktop application, your mobile application consists of a series of interlocking and interdependent systems that need to share the same finite system resources. Because the pool of available memory is smaller and the concept of swapping out infrequently used memory to a disk paging file does not exist for mobile devices, any one wasteful element of your application can cause large-scale performance problems for the whole application. For instance, maintaining large bitmaps in memory will directly take away from memory that may be needed to store a tree of XML data or compiled function code. It is easy to diagnose cases where your application simply runs out of memory. It is far more difficult to diagnose the source of a problem when your application is becoming slowly starved of memory and the garbage collector is forced to run more and more frequently just to keep the application running.

The interdependence of the parts of your application means that both integrated and component-level analysis is required. Each individual component part of your application (the code that deals with loading and saving data, the code the deals with graphics, the code that deals with network I/O, and so on) should be reviewed to understand the state that it demands and the kinds of temporary allocations it makes when it is running; obviously, smaller is better. As soon as possible, these components need to be integrated together into your application to see how the system performs as a whole. The data used to test the application must be of a similar size to the real-world data your mobile application will use.

When performance problems arise, it is important to diagnose and deal with them promptly. The more code that gets written and integrated into your application, the harder it will be to discover and fix the parts of your application that are responsible for performance problems. Some runtimes can give you profiling data such as the number of objects allocated, the number of garbage collections performed, and other useful memory-usage metrics to help you understand the root causes of performance problems in your application. Instrumenting your code with diagnostic measurements is another useful method for pulling out comparative performance data. Finally, isolating portions of your application and looking at the algorithms and memory-usage characteristics of individual parts in detail can prove helpful.

When performance problems exist, it is extremely important to not continue to add features and code to your mobile application in the false belief that performance can be addressed in the future. You should only add code and features to your mobile device application when you have the extra performance capacity to support those features. If you find you are hitting a performance wall, you need to find ways to economize application state and algorithmic object churn before adding additional resource-consuming pieces to your application. Extra performance capacity is the currency you have to spend on new features; if you are in debt, find a way to get out of debt before spending more.