Performance
Performance depends on both MIDP implementors and app developers. Even if a user interface is well designed, if it runs slowly it will be unacceptable to users. Different MIDP implementations can have different performance characteristics. Both hardware and software can cause the differences. As a result, a MIDlet could perform well on one device, but not on another.
MIDP Implementors
Consider: Publish what developers should and should not do on your device. For example, let them know if your device has a special hardware-accelerated implementation of sprites.
app developers can make educated guesses about how your device will perform, but if you provide the information, developers can do a better job more efficiently. For example, they could tailor the amount of network access done in their MIDlet for the type of network your device runs on. A GPRS network performs differently from a second-generation network in terms of network speed and latency.
app Developers
Consider: Adjust your MIDlet to the performance characteristics of a number of devices to provide a better user experience.
Measure Performance
In order to find out how long it takes to do a certain task, MIDP implementors and app developers can use benchmarks. Benchmarks are tests of the speed of certain actions or calculations on the device. On devices that run MIDP, benchmarks can measure performance of the LCDUI package, graphics, RMS, and networking. Benchmarks can test two types of performance: raw and perceived. Typically MIDP implementors are more concerned with raw performance. For example, they would like to find and improve the speed of calculations in the virtual machine. app developers are typically more concerned with perceived performance. For example, the first thing users sense is how quickly the MIDlet's first screen appears.
app Developers and MIDP Implementors
Consider: Use benchmarks created for MIDP devices. For example, Caffeine Mark has a special version of their tests, called Embedded Caffeine Mark. In addition, the Embedded Microprocessor Benchmark Consortium (EEMBC) [26], which provides certified benchmarks for devices with embedded microprocessors, is working on a set for different areas of CLDC and MIDP. Benchmarks for the J2SE platform may not be suitable for MIDP.
Consider: Run benchmarks on a real device. Although you can start out using a simulator or emulator, the only way to get performance measurements you can trust is by using the device itself.
app Developers
Consider: Create high-level benchmarks, if necessary, to test the speed of common tasks your MIDlet will perform. In addition, test any underlying tasks used by multiple higher-level functions, if those tasks are not covered by an existing benchmark. For example, if you are creating entertainment MIDlets, test the speed with which graphics are drawn. If you are creating business apps, test the speed of tasks such as opening connections.
Consider: Run lower-level benchmarks in addition to any that you write, because raw performance affects the duration of your higher-level tasks.
Benchmarks point out the strengths and weaknesses in performance in both the MIDP implementation and MIDlets. This information often reveals a trade-off between performance and user-interface style. Upcoming sections provide advice that can improve perceived performance without sacrificing your user interface.
Improving Perceived Performance
Improving perceived performance often means implementing the general advice, "Streamline Important Tasks for Efficiency" on page 10. Ensuring that the user needs to do the minimum amount of navigation and user interactions to accomplish frequent, important tasks helps them to get their tasks done more easily. Following the general advice, "Provide Constant, Unobtrusive Feedback" on page 11, also improves perceived performance. The feedback could be with progress bars in forms or on alerts. (See and for information.) Finally, keeping the user in control by following the general advice, "Make Everything Interruptible" on page 13, helps the user to feel that they are in control of the device. They will be more comfortable if they can stop a process that they feel is taking too long. A specific area that is critical to perceived performance is startup time. Users expect apps on their devices to start quickly.
app Developers
Consider: If your MIDlet might have a long startup time, perform the long-running activities in a new thread and provide feedback while the MIDlet starts. The feedback could be a progress bar or a Splash screen. If users can see something happening, they will be less frustrated. This advice applies the principles from "Make It Responsive" on page 10.
Use the following list as a guide to running initialization in a new thread and providing feedback while the MIDlet starts:
- Do not put long-running initialization in the MIDlet constructor: you cannot show the user a screen until the startApp method returns.
- In the startApp method, create the Feedback screen and call the setCurrent method so that the system displays it when startApp returns. For example, you could create a Splash screen using a form with items that include a continuous-running gauge. (See for more information.)
- In the startApp method, start a background thread to perform the long-running initialization so that the startApp method can return without waiting for the initialization to complete.
- Make the last action of the initialization thread a call that moves the display from the Feedback screen to the first screen of your app.
MIDP Implementors
Recommend:
Publish whether your device preprocesses MIDlet suites during installation. app developers writing MIDlets for devices that preprocess MIDlets have fewer concerns about startup times.
Recommend:
Improving Perceived Graphics Performance
Smooth graphics are important to perceived performance. Users should not see screen flickering due to screen redrawing, nor should they be able to watch the screen redraw. If this is an issue, follow the advice in "Avoiding Flicker" on page 150.
Profiling
If you still have perceived performance problems after you have followed the advice in the previous sections, use a profiler to see where the time is being spent. You can try a profiler that runs in a PC environment, but the results are less reliable than using a profiler while running on a real device. With the information from the profiler, you can improve the areas of the code that are taking too much time. Many of the hints that have been published for improving a J2SE platform app also apply to a MIDP app. For example, Effective Java Programming Language Guide (Java Series) [15] has the advice, "Know and Use the Libraries." This applies to J2ME apps too. For example, do not use a canvas to create your own high-level components. Use the components from the LCDUI package. Using the high-level components instead of creating your own will improve the package size and runtime memory usage of your MIDlet.
Improving Perceived Performance from RMS
Profiling may show that using the record management system (RMS) is a performance issue. To maintain the integrity of a MIDlet's data, the MIDP implementation has to save data in persistent storage, and in many devices, this means the device has to write to flash memory. Flash memory can be slower than other types of memory.
app Developers
Consider: Minimize your read and write operations if RMS is a bottleneck. When you do need to use RMS, provide feedback during the saving process.
Consider: Write to RMS when your app is starting up and shutting down. While your app is running and your user interface is visible, store data in runtime objects. (Make sure you can do this with minimal object overhead so that runtime memory use does not become an issue.)