内存限制

 Mobile devices typically have constrained system resources. Android devices can have as little as 16MB of memory available to a single application. The  Android Compatibility Definition Document (CDD),  Section 3.7. Virtual Machine Compatibility gives the required minimum application memory for various screen sizes and densities. Applications should be optimized to perform under this minimum memory limit. However, keep in mind many devices are configured with higher limits.

一个安卓设备至少应该给某个app 16M的内存，CDD，段落3.7：

虚拟机的兼容性提供了最小的应用程序内存，不论屏幕大小和分辨率。应用程序需要优化来满足最小内存限制优化。虽然，很多设备放宽了这个限制。

        Android设备屏幕大小不一，分辨率低至320*240，高至1280*720，对图片的需求也不同。如果在UI中需要加载一副大图片，明智的做法是先获取屏幕的分辨率，然后再决定加载图片的大小。在一款低分辨率的设备上加载高分辨率图片除了增加内存消耗，别无他用。因为设备最大能展示的清晰度为本身的屏幕分辨率。所以，如果一个不需要放大图片的控件需要加载图片，最大只需要加载该控件本身宽高的图片即可。

       Given that you are working with limited memory, ideally you only want to load a lower resolution version in memory. The lower resolution version should match the size of the UI component that displays it. An image with a higher resolution does not provide any visible benefit, but still takes up precious memory and incurs additional performance overhead due to additional on the fly scaling.

通过重载Application的onTrimMemory函数，可以在系统内存紧张时，释放掉所有缓存的图像对象。

    public void onLowMemory() {
        Object[] callbacks = collectComponentCallbacks();
        if (callbacks != null) {
            for (int i=0; i<callbacks.length; i++) {
                ((ComponentCallbacks)callbacks[i]).onLowMemory();
            }
        }
    }

    public void onTrimMemory(int level) {
        Object[] callbacks = collectComponentCallbacks();
        if (callbacks != null) {
            for (int i=0; i<callbacks.length; i++) {
                Object c = callbacks[i];
                if (c instanceof ComponentCallbacks2) {
                    ((ComponentCallbacks2)c).onTrimMemory(level);
                }
            }
        }
    }

一些关于内存的优化

http://www.open-open.com/lib/view/open1392013992317.html

public class LinkedHashMap<K,V>
extends HashMap<K,V>
implements Map<K,V>

Hash table and linked list implementation of the Map interface, with predictable iteration order. This implementation differs from HashMap in that it maintains a doubly-linked list running through all of its entries. This linked list defines the iteration ordering, which is normally the order in which keys were inserted into the map (insertion-order). Note that insertion order is not affected if a key is re-inserted into the map. (A key k is reinserted into a map m if m.put(k, v) is invoked when m.containsKey(k) would return true immediately prior to the invocation.)

This implementation spares its clients from the unspecified, generally chaotic ordering provided by HashMap (and Hashtable), without incurring the increased cost associated with TreeMap. It can be used to produce a copy of a map that has the same order as the original, regardless of the original map's implementation:

     void foo(Map m) {
         Map copy = new LinkedHashMap(m);
         ...
     }
 企业融合通信

This technique is particularly useful if a module takes a map on input, copies it, and later returns results whose order is determined by that of the copy. (Clients generally appreciate having things returned in the same order they were presented.)

A special constructor is provided to create a linked hash map whose order of iteration is the order in which its entries were last accessed, from least-recently accessed to most-recently (access-order). This kind of map is well-suited to building LRU caches. Invoking the put or get method results in an access to the corresponding entry (assuming it exists after the invocation completes). The putAll method generates one entry access for each mapping in the specified map, in the order that key-value mappings are provided by the specified map's entry set iterator. No other methods generate entry accesses. In particular, operations on collection-views do not affect the order of iteration of the backing map.