PERFORMANCEOPTIMIZATION

Cao PhongDeveloper Tech Support ManagerAug 07, 2013

WHY OPTIMIZEMost of the development tasks for the typical mobile application can be done in many different ways.

Different implementation techniques lead to different application performance and essentially different responsiveness of user interface.

Responsiveness of UI is one of the important factors for application success.

• 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 will want 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 will then not know what to expect.

Miller, R. B. (1968)Response time in man-computer conversational transactions.

Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277

CHOOSING GUI STRATEGYLCDUI FormsCanvasGameCanvasLWUIT

LCDUI FORMSFast, simple and standard way of making UI.

On full touch Asha very attractive looking and have huge UX improvements.

Not as fast as Canvas. Animation on a Form is much slower than on a Canvas, and there is no way to influence the vertical scroll position, animate transitions between screen, or shift to a full screen view. You can, however, slightly increase the performance when changing screens by using just one Form and re-populating it with new Items.

CANVASHighly customizable way of making UI.

You have to take care of render timing yourself, or you can use Nokia’s FrameAnimatorclass to quickly create effects such as kinetic scrolling.

Any part of your code can call Canvas.repaint() to signal that painting should occur soon. The most important performance tip for navigating through a Canvas-based UI is to implement your own View class to represent each screen, and paint all Views on one Canvas rather than switching from one Canvas to another, which can be slow and does not give you the possibility of animating the transition for smooth effect.

GAMECANVASGameCanvas is double buffered with more control over the painting cycle and threading.

Unlike Canvas, you should create your own Thread, which calls GameCanvas.paint()directly to fill the graphics buffer, and then GameCanvas.flushGraphics() to instantly blit the graphics buffer onto the screen.

LWUITLWUIT (Lightweight User Interface Toolkit) is a toolkit for creating Java SWING-like applications without some of the complexity of SWING.

Like Form, it offers basic components, but it adds to this better layouts, styles and theming, bundling own fonts into your application, and animated screen transitions.Canvas, but it is a large and complex library written to be a general purpose replacement for the default UI on many different phones.

LWUIT and the associated themes and any fonts you include quickly make your JAR file grow quite large. http://projects.developer.nokia.com/LWUIT_for_Series_40

JAVA HEAP MEMORYOn Series 40 (well, FT) only from 2 to 4 MB – use it wisely

Instances of classes (objects) and primitive types are created in the heap.

Total number of methods in classes loaded by JVM has a direct impact on how much heap space is left for other data. These memory allocations are permanent for the runtime of the application and are not dynamically unloaded by the JVM once a class is no longer in use.

RECURSIVE ALGORITHMS AND STACK MEMORY

Variables passed as arguments to a method are passed on the current thread’s stack. Method variables of primitive types are also allocated on the stack. Recursive algorithms are algorithms where a method calls itself in a loop to complete a task. As a result, they create multiple stack frames.

– They use a lot of stack memory. The same method is called repeatedly, and only as the application completes does it unwind the queued stack frames. This extra stack memory is often not useful, and stack memory per thread is limited and such heavy stack use may well cause an OutOfMemoryException well before you are actually out of heap memory.

– Recursive algorithms can be slow. Each method call includes a certain amount of overhead, which is not really necessary since a recursive algorithm can be unwound into a non-recursive equivalent loop that does not include the relatively heavy method call.

ARCHITECTURE CHANGESCarefully consider architecture of your drawing loop and user input loops and decouple them whenever possible.

Explore WeakReference introduced in CLDC 1.1 for memory management.

WEAKREFERENCE OBJECT CACHINGBest pattern for using all available heap memory, but never running into the dreaded OutOfMemoryError.

CLDC 1.1 WeakReference

When an object is referenced by a WeakReference, and not using traditional Objectpointers, this is a signal to the garbage collector that is has permission to collect the object if memory is running low.You have to maintain own HashTable of Objects

To understand this pattern better look at Tantalum Mobile: http://projects.developer.nokia.com/Tantalum

public void remove(final Object key) {if (key != null) {

hash.remove(key);}

}

public boolean containsKey(final Object key) {if (key != null) {

return hash.containsKey(key);}

return false;}

public int size() {return hash.size();

}

public void clear() {hash.clear();

}}

public class WeakHashCache {

protected final Hashtable hash = new Hashtable();

public Object get(final Object key) {final WeakReference reference = (WeakReference) hash.get(key);

if (reference != null) {return reference.get();

}return null;

}

public void put(final Object key, final Object value) {synchronized (hash) {

if (key == null) {return;

}if (value == null) {

hash.remove(key);return;

}hash.put(key, new WeakReference(value));

}}

RENDER CACHINGOne of the common performance needs is to make your application paint, in particular scroll, smoothly and quickly.

You can paint items each into their own Image, keeping that pre-painted Image in a cache, and reusing it as the object moves around the screen. Essentially, WeakReference cach of pre-painted Images.

To understand this pattern better look at Tantalum Mobile: http://projects.developer.nokia.com/Tantalum

BAG OF TRICKSUse final – class, method, variables

Avoid enumerations

Don’t make it static if it’s commonly called from instances

Final int n = vector.size() before a classic for() loop

Minimize how much external RAM you use. Example: copy from one array back into the same array is faster than copy from one array into a second- more primary cache hits in RAM.

FILE SYSTEM (FLASH MEMORY) CACHINGFlash memory is slow, but faster then Web.

Cache downloaded data from previous session. Improve startup time of app, by loading from disk cache instead of new Web requests.

RMS and File System (JSR-75) same speed, but with RMS no security prompts.

Underwater stones: still remember, Flash memory is slow.

Architect your application to use asynchronous loading /saving of data from / to disk cache.

HASH ACCELERATIONSome iterative algorithms are slow. Proper usage of collections types of data structures can increase performance.

Vector.contains() is very slow, but Hashtable.containsKey() is very fast. Reconsider your algorithms to use Hashtables.

Usage can be found in very surprising places. For example, Font.stringWidth() is slow, but necessary for drawing multiline text on Canvas. Creating a Hashtable with the width in each character you have used in the Font can transform this into a fast operation and increase Canvas.paint() speed.

STRING CONCATENATIONIf you are going to concatenate a large number of small Strings, use:

StringBuffer.append()

instead of the

String +=

operator. String is much slower because every time you concatenate a string to another with += operator, a new StringBuffer is created under the hood. Depending on the number of concatenations, a single explicit StringBuffer can be many times faster than multiple implicit StringBuffers created by String addition.

PERFORMANCE SUMMARY

Compare Algorithms– Talk to colleagues and pick the best algorithm; having the best possible algorithm

is the most effective way to optimize performance.

Simple Architecture– Keep your architecture simple and to the point without extra layers of method

calls or objects for artificial abstraction. Mobile front end code does not last for ever, so over-engineering and excessive abstraction into multiple classes will slow you down compared to simple use of variables.

PERFORMANCE SUMMARY

Manage Memory with WeakReferenceCaching

– Avoid memory problems by always accessing image data in memory using a WeakReference Cache.

– Create a type of virtual memory by duplicating the WeakReference cache contents in Flash memory (Record Management System) so that you can quickly recover items which are no longer available in RAM.

PERFORMANCE SUMMARY

Profile your app towards the end of project

– Profile your application in an emulator.– Also test the actual run-time of critical code sections on the phone using

System.currentTimeMillis() to see and carefully measure the effects of your code changes.

SPECIAL THANKSPaul Houghton

Michael Samarin

THANK YOUQUESTIONS?