One of the best patterns for using all the available heap memory, but never running into the dreaded OutOfMemoryError, is to maintain pointers to your memory-intensive objects using the CLDC 1.1 WeakReference. This class is often overlooked, but it is specifically designed for caching. When an object is referenced by a WeakReference, and not using traditional object pointers, this is a signal to the garbage collector that it has permission to collect the object if memory is running low. Architecturally this is very useful, because it means you can allocate as much memory as you like, and let the garbage collector and total heap size on the phone determine how many of those objects to keep.
WeakReference caching works quite well to simplify your design vs. explicit memory management of large objects that are held by hard links. The pattern is: get the object from the hashtable, if it is null (has been garbage collected), then re-create it (load from flash memory or re-draw it) and put the new object into the Hashtable. Note that if the object is definitely needed in the near future, such as an image which is currently visible or nearly visible at the edge of the screen or next likely action is to change to a new view, you prevent it from being garbage collected by also keeping a normal hard object reference. For example, your code is simpler if you always get images from a Hashtable of WeakReferences, but also keep a hard link to the images which are visible. This allows you to get maximum use from the available memory since if the object becomes visible again and it is still in memory, you won’t have to (slowly) re-create or re-load it.
To understand this pattern better, first let’s look at the implementation in the Tantalum 3 library. This and similar utilities are available in open source form to make it faster for you to utilise high performance design patterns.
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));
}
}
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();
}
}
As we can see by examining the code, we can put() as many objects as we like, but when memory gets low, we may get() a null because the phone has to collect some of the objects. We do not have any control over which objects will be collected before others, so the trick is to always get object from the WeakHashCache, but if there is something which should not be garbage collected at this time (for example an image which is currently visible on the screen), then you should separately maintain a traditional object reference to indicate that the object cannot be garbage collected.
The key question for a WeakHashCache is, what does my application do when I get back a null instead of the object I requested? You may be able to re-generate the object from other available data, but another solution is to also store the objects in flash memory on the phone and thereby create a sort of virtual memory extension of the heap. For a complete implementation of this, see the Tantalum 3 StaticWebCache that takes care of all the load, store, and fetch details associated with caching web service data on your phone.
One of the common performance needs is to make your application paint, in particular scroll, smoothly and quickly. This occurs on all platforms, and for example Windows Phone will automatically store items as images and re-render them for you. We can do the same on Series 40 phones by painting items each into their own Image, keeping that pre-painted Image in a cache, and reusing it as the object moves around the screen.
This is essentially just a WeakReference cache of pre-painted Images. Using this technique, the frame rate of a scrolling list of news items increased from 3 fps to 12 fps on a Nokia Asha 305 on Nokia Asha software platform after changing the application to re-use the rendered list items by implementing WeakReference caching of the rendered list items as images. See the difference for yourself in this video.
The source code to this solution can be found in VerticalListView in the Tantalum 3 Series 40 Example. To enable it, replace the default IconListView with a VerticalListView.
Although flash memory is very slow, accessing it is much faster than downloading data from the web (see Flash memory for more information about flash). It also costs less in places where data bundles are relatively expensive.
One of the nicest places to use flash memory caching is on the main screen of your application. Users prefer not to wait while you load data from the web at each application start-up, but rather display existing items from the flash cache. After the start-up you can update the data asynchronously, but an end-user gets a feeling that the application starts fast. You can also pre-fetch data and images needed for other pages and store that in the flash cache so that performance will appear instantaneous as you navigate between screens.
Case example: The start-up time of a news reader application reduced from 10 seconds to 2 seconds after changing the application to load the XML containing news from flash cache, not from the web (Nokia Asha 305 on Nokia Asha software platform). This makes it much more rewarding to start the application, and therefore people use it more often. See this video.
Some algorithms are relatively slow. Typically these are scaling by “order n”, meaning that as the number of items in a data structure increases, the code slows down by a linear amount since each item in the data structure must be touched. Vector.contains() is a frequent example of where this can start to get slow.
When profiling your application, if you discover that this is a performance bottleneck for your application, consider storing the data in a Hashtable in addition to the Vector or existing code. Hashtable.containsKey() is extremely fast and can speed up your program at these critical points.
Note that this technique can also apply to surprising places which will only be visible when you profile. For example, Font.stringWidth() is surprisingly slow, but may be necessary for you to lay out multi-line text on your 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. This is of course not needed, if you already use render caching.