android 内存相关

case1:如何查看 Native 内存？

使用Debug的getNativeHeapSize ()，getNativeHeapAllocatedSize ()，getNativeHeapFreeSize ()方法。

该方式只能得到Native堆的内存大概情况，数据单位为字节。

static long getNativeHeapAllocatedSize()

Returns the amount of allocated memory in the native heap.

返回的是当前进程navtive堆中已使用的内存大小
static long getNativeHeapFreeSize()

Returns the amount of free memory in the native heap.

返回的是当前进程navtive堆中已经剩余的内存大小

static long getNativeHeapSize()

Returns the size of the native heap.

返回的是当前进程navtive堆本身总的内存大小

示例代码：

          Log.i(tag,"NativeHeapSizeTotal:"+(Debug.getNativeHeapSize()>>10));

          Log.i(tag,"NativeAllocatedHeapSize:"+(Debug.getNativeHeapAllocatedSize()>>10));

          Log.i(tag,"NativeAllocatedFree:"+(Debug.getNativeHeapFreeSize()>>10));

注意：DEBUG中居然没有与上面相对应的关于dalvik的函数。

case2:cursor泄漏后，如何查找泄漏源？

一.[表现形式]

cursor造成的fd泄漏一般表现形式为：

main.log

12-08 18:18:59.611  5701  5708 W CursorWrapperInner: Cursor finalized without prior close()
12-08 18:18:59.611  5701  5708 W CursorWrapperInner: Cursor finalized without prior close()

如果有以上log，那就是代表有cursor泄漏了

二.[原因排查]

1.cursor没有关闭，最简单就是converity排查了，最快也最有效，其次是可以通过在相关代码中查找Cursor关键字，从而确认Cursor最终有没有close,也可以达到排查的效果，就是比较费事，工作量比较大。

2.adapter没有关闭，这个就要查看代码逻辑了，查看使用完毕后，相应的adapter有没有changeCursor(null)。

3.还有一种隐藏的稍深一点，其实也是changeCursor的原因，代码类似如下：

            if (token != MSG_BOX_INBOX_UNREAD) {
                mListAdapter.changeCursor(cursor);
            }
也就是说只对if做了处理，没有对else做操作，这样就会有问题了。

case3:谨慎使用java反射技术

java反射技术主要用到如下函数：

Class.getField

Class.getDeclaredField

Class.getConstructors()

 

使用java反射技术，主要有如下问题，请谨慎使用：

1.  破坏类的原有逻辑

    使用反射技术获得类的非public的field，破坏类的封装性。

    对用反射技术获得的field再进行复制操作，容易破坏类的原来流程、逻辑。 这样使程序不容易理解，难于维护。

 

2. 导致user版本抛出异常，应用退出

   user版本中，一般情况，代码都是混淆的。

   代码混淆后，java的反射机制再也找不到它想找的类、方法、属性了。因为代码混淆的原因，原本的类名、方法名、属性名都改变了，而反射它还是按照原来的名字去反射。

  user版本中使用反射，容易报类似如下的异常，导致应用退出。

   java.lang.NoSuchFieldException: time_0
   at java.lang.ClassCache.findFieldByName(ClassCache.java:446)
   at java.lang.Class.getField(Class.java:864)