最后一部分是关于native heap，.dex，/dev/other的优化。
Native Heap分析和优化
android的DDMS可以帮助查看c++ native heap的使用，但需要一定的配置，而且必须是root的手机。
- 在~/.android/ddms.cfg增加"native=true"。这样子ddms才会有native heap的tab。
- 指向下面adb命令打开malloc的debug模式
adb root
adb shell setprop libc.debug.malloc 1
adb shell stop
adb shell start - 打开standalone的DDMS（不是eclipse中那个，是独立的应用程序，sdk目录下有），然后在native heap这个tab下，可以查看native heap的分配情况。
在很多手机上，即使执行了这些命令，还是看不到结果。原因是很多手机上并没有安装debug版本的malloc库（包括libc_malloc_debug_leak.so 和 libc_malloc_debug_qemu.so）。这篇经常被引用的文章介绍了一种方法。是从供大家刷机用的CyanogenMod image中提取这两个文件，然后拷贝到自己的机器上。可以参考那片文章的具体步骤。
下面的问题是只能看到地址而不知道文件名和行号。至少有下面一些办法
- 使用ndk中的arm-linux-androideabi-gdb（android ndk的gdb）来打开.so文件。这里的.so不能使apk中使用的，因为那个已经把symbol给strip了。而应该使用 ***objlocalarmeabi***.so，这个是带着symbol的。
然后可以在gdb中使用info symbol 0x000xxxxx来定位到地址对应的函数名。这里的0x000xxxxx是ddms中地址把前三位变成0。因为gdb .so中使用.so的静态地址，而ddms中的地址经过动态链接，是内存的虚拟地址。但动态链接并不改变地址的后五位，所以这里后五位保持不变，前三位变成0，从而转换为so的静态地址。
然后用info line xxx.cpp:xxx来定位具体行。
这个方法比较繁琐，因为当时自己没找到好办法，就这么用的。 - 用ndk的arm-linux-androideabi-addr2line。后面跟so和0x000xxxxx。跟gdb差不多，会简单一些。
- 有人说设置PATH加上包含addr2line的目录，然后再设置ANDROID_PRODUCT_OUT可以在ddms中直接显示函数名和行号，但没有试过。
/other/dev分析和优化
自己用的是4.2版本的android。每次打开preference setting，/other/dev的private dirty都会增加很多（10M作用），并且不会释放。通过查看smaps，发现是/dev/pvrsrvkm导致的（4.3后设备名改为kgsl-3d0）。这个是显示相关的设备，按我的理解，大概是显存（如果没有独立显存，那是用于显示的内存）。通过网上查询，并不是只有我遇到这个问题。例如chrome也有这个问题。但还是不知道为何这个会增加。在一通乱试后，发现如果对activity设置android:hardwareAccelerated=false，就能解决。此时只增加shared dirty，并且关掉activity，内存会被释放。后来再查，看到stackoverflow上这篇文章，才知道这是4.2的一个bug。4.3和4.1都没有问题。
.Dex mmaps优化
这个是java代码编译只会的.dex文件的大小。
开始自己使用eclipse编译出来的apk作性能分析，发现这个也有几M。但release版本的却不到1M。转念一想，原来是proguard的作用。proguard是android自带的混淆器，会对java的类名，函数名，变量名等重新命名，给一个非常短的名字。有两个作用，一个是使得反编译的代码不容易理解，另一个就是减少了dex文件的大小。经过这次内存分析，才发现其效果还是非常明显的。
因为proguard无法对res下的layout，xml文件做混淆，所以他们引用到的java类（例如一些view类）的名字是不能被改变的。所以一个小经验是让xml文件尽量少的引用java类，从而提高混淆的比例。
总结
关于android内存优化，自己就先做了这些。整体思路就是从宏观到微观，利用各种工具和网络资料，从内存占用量最多的模块下手，一步步的分析原因，解决问题。再细化下去，还有很多代码级别的优化，例如perf tips里介绍了很多经验，memory ｅｆｆｉｃｉｅｎｔ ｊａｖａ也很值得参考。有时间再在这个级别做更多的优化。