公司面试题——Android内存管理

Android的内存回收机制是沿用java的有向图模式：

GC回收——有向图（根节点main——引用变量——对象）可达不回收；

                 有向图不可达回收；

Android的内存溢出是如何发生的?

       Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。因此我们所能利用的内存空间是有限的。如果我们的内存占用超过了一定的水平就会出现OutOfMemory的错误。（通常简称OOM错误）

为什么会出现OOM？原因主要有两个：

              1，长期保持某些资源（如Context）的引用，造成内存泄露，资源造成得不到释放。

      2，保存了多个耗用内存过大的对象（如Bitmap），造成内存超出限制。

情形1：static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context的情况最多），就可能有问题了。

  如何才能有效的避免这种引用的发生呢？

    第一，应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。

    第二、Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。

    第三、使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef;

情形2：线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控。

ex:一个在Activity中的内部类，由于内部类引用了Activity对象，即使Activity销毁了，但其引用仍然存在（如：内部类是一个线程，如若线程的run未执行完毕，那么这种对于Activity的引用仍然保留）；

 这种线程导致的内存泄露问题应该如何解决呢？

    第一、将线程的内部类，改为静态内部类。

    第二、在线程内部采用弱引用保存Context引用。

情形3：可以说出现OutOfMemory问题的绝大多数人，都是因为Bitmap的问题。因为Bitmap占用的内存实在是太多了，它是一个“超级大胖子”，特别是分辨率大的图片，如果要显示多张那问题就更显著了。

 如何解决Bitmap带给我们的内存问题？

    第一、及时的销毁。（例如只保存当前项，前项，后项 这3项的图片, 滑动Gallery的时候再根据当前项动态回收前后不需要的图片和加载需要的图片.）

    虽然，系统能够确认Bitmap分配的内存最终会被销毁，但是由于它占用的内存过多，所以很可能会超过java堆的限制。因此，在用完Bitmap时，要及时的recycle掉。recycle并不能确定立即就会将Bitmap释放掉，但是会给虚拟机一个暗示：“该图片可以释放了”。

    第二、设置一定的采样率。

    有时候，我们要显示的区域很小，没有必要将整个图片都加载出来，而只需要记载一个缩小过的图片，这时候可以设置一定的采样率（缩小长宽大小），那么就可以大大减小占用的内存。

情形X：查询数据库，未释放游标。

程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor 后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。所以在使用完游标以后要cursor.close();