android内存优化详解.docxVIP

Android内存优化详解 An droid内存泄露 刖言 不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄露。 其实如果我们一个程序中， 已经不再使用某个对象， 但是因为仍然有引用指向它， 垃圾回收 器就无法回收它，当然该对象占用的内存就无法被使用， 这就造成了内存泄露。 如果我们的 java运行很久,而这种内存泄露不断的发生，最后就没内存可用了。当然 java的，内存泄漏 和C/C++是不一样的。如果java程序完全结束后，它所有的对象就都不可达了，系统就可 以对他们进行垃圾回收，它的内存泄露仅仅限于它本身，而不会影响整个系统的。 C/C++ 的内存泄露就比较糟糕了，它的内存泄露是系统级，即使该 C/C++程序退出，它的泄露的 内存也无法被系统回收，永远不可用了，除非重启机器。 An droid的一个应用程序的内存泄露对别的应用程序影响不大。 为了能够使得An droid应用 程序安全且快速的运行，An droid的每个应用程序都会使用一个专有的 Dalvik虚拟机实例来 运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程 中运行的。An droid为不同类型的进程分配了不同的 内存使用上限，如果程序在运行过程中 出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会 被系统视为内存泄漏， 从而被kill掉，这使得仅仅自己的进程被 kill掉，而不会影响其他进程 （如果是 system_process等系统进程出问题的话，则会引起系统重启）。 1,引用没释放造成的内存泄露 1.1注册没取消造成的内存泄露 这种An droid的内存泄露比纯java的内存泄露还要严重，因为其他一些An droid程序可能 引用我们的An roid程序的对象（比如注册机制）。即使我们的 An droid程序已经结束了， 但是别的引用程序仍然还有对我们的 An droid程序的某个对象的引用， 泄露的内存依然不能 被垃圾回收。 比如示例1: 假设我们希望在锁屏界面（LockScreen）中，监听系统中的电话服务以获取一些信息 （如信 号强度等），则可以在LockScreen中定义一个PhoneStateListener 的对象，同时将它注册 到TelephonyManager 服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创 建一个LockScreen对象，而当锁屏界面消失的时候 LockScreen对象就会被释放掉。 但是如果在释放LockScreen对象的时候忘记取消我们之前注册的 PhoneStateListener 对象，则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终 会由于大量的LockScreen对象没有办法被回收而引起 OutOfMemory,使得 system_process 进程挂掉。 虽然有些系统程序， 它本身好像是可以自动取消注册的(当然不及时)， 但是我们还是应该 在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉 。 1.2集合中对象没清理造成的内存泄露 我们通常把一些对象的引用加入到了集合中， 当我们不需要该对象时， 并没有把它的引用从 集合中清理掉，这样这个集合就会越来越大。如果这个集合是 static的话，那情况就更严重 了。 2，资源对象没关闭造成的内存泄露 资源性对象比如(Cursor，File文件等)往往都用了一些缓冲，我们在不使用的时候，应该 及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还 存在于java虚拟机外。如果我们仅仅是把它的引用设置为 null,而不关闭它们，往往会造成 内存泄露。因为有些资源性对象，比如 SQLiteCursor (在析构函数finalize ()，如果我们没 有关闭它，它自己会调 close()关闭)，如果我们没有关闭它，系统在回收它时也会关闭它， 但是这样的效率太低了。因此 对于资源性对象在不使用的时候，应该调用它的 close()函数， 将其关闭掉，然后才置为 null.在我们的程序退出时一定要确保我们的资源性对象已经关闭 。 程序中经常会进行查询数据库的操作，但是经常会有 使用完毕Cursor后没有关闭的情况。 如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况 下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。 3，一些不良代码成内存压力 有些代码并不造成内存泄露， 但是它们，或是对没使用的内存没进行有效及时的释放， 或是 没有有效的利用已有的对象而是频繁的申请新内存，对内存的回收和分配造成很大影响的， 容易迫使虚拟机不得不给该应用进程分配更多的内存，造成不必要的内存开