Android学习系列(32)--App调试内存泄露之Cursor篇

十度 Android 2015年12月01日 收藏

    最近在工作中处理了一些内存泄露的问题,在这个过程中我尤其发现了一些基本的问题反而忽略导致内存泄露,比如静态变量,cursor关闭,流关闭,线程,定时器,反注册,bitmap等等,我稍微统计并总结了一下,当然了,这些问题这么说起来比较笼统,接下来我会根据问题,把一些实例代码贴出来,一步一步分析,在具体的场景下,用行之有效的方法,找出泄露的根本原因,并给出解决方案。
    现在,就从cursor关闭的问题开始把,谁都知道cursor要关闭,但是往往相反,人们却常常忘记关闭,因为真正的应用场景可能并非理想化的简单。
1. 理想化的cursor关闭

  1. // Sample Code
  2. Cursor cursor = db.query();
  3. List<String> list = convertToList(cursor);
  4. cursor.close();

    这是最简单的cursor使用场景,如果这里的cursor没有关闭,我想可能会引起万千口水,一片骂声。
    但是实际场景可能并非如此,这里的cursor可能不会关闭,至少有以下两种可能。

2. Cursor未关闭的可能
     (1). cursor.close()之前发生异常。
     (2). cursor需要继续使用,不能马上关闭,后面忘记关闭了。

3. Cursor.close()之前发生异常
     这个很容易理解,应该也是初学者最开始碰到的常见问题,举例如下:

  1. try {
  2. Cursor c = queryCursor();
  3. int a = c.getInt(1);
  4. ......
  5. // 如果出错,后面的cursor.close()将不会执行
  6. ......
  7. c.close();
  8. } catch (Exception e) {
  9. }

  正确写法应该是:

  1. Cursor c;
  2. try {
  3. c = queryCursor();
  4. int a = c.getInt(1);
  5. ......
  6. // 如果出错,后面的cursor.close()将不会执行
  7. //c.close();
  8. } catch (Exception e) {
  9. } finally{
  10. if (c != null) {
  11. c.close();
  12. }
  13. } 

    很简单,但是需要时刻谨记。

4. Cursor需要继续使用,不能马上关闭
    有没有这种情况?怎么办?
    答案是有,CursorAdapter就是一个典型的例子。
    CursorAdapter示例如下:

  1. mCursor = getContentResolver().query(CONTENT_URI, PROJECTION,
  2. null, null, null);
  3. mAdapter = new MyCursorAdapter(this, R.layout.list_item, mCursor);
  4. setListAdapter(mAdapter);
  5. // 这里就不能关闭执行mCursor.close(),
  6. // 否则list中将会无数据

5. 这样的Cursor应该什么时候关闭呢?
    这是个可以说好回答也可以说不好回答的问题,那就是在Cursor不再使用的时候关闭掉。
    比如说,
    上面的查询,如果每次进入或者resume的时候会重新查询执行。
    一般来说,也只是这种需求,很少需要看不到界面的时候还在不停地显示查询结果,如果真的有,不予讨论,记得最终关掉就OK了。
    这个时候,我们一般可以在onStop()方法里面把cursor关掉(同时意味着你可能需要在onResume()或者onStart()重新查询一下)。

  1. @Override
  2. protected void onStop() {
  3. super.onStop();
  4. // mCursorAdapter会释放之前的cursor,相当于关闭了cursor
  5. mCursorAdapter.changeCursor(null);
  6. }

  我专门附上CursorAdapter的changeCursor()方法源码,让大家看的更清楚,免得不放心changeCursor(null)方法:

  1. /**
  2. * Change the underlying cursor to a new cursor. If there is an existing cursor it will be
  3. * closed.
  4. *
  5. * @param cursor The new cursor to be used
  6. */
  7. public void changeCursor(Cursor cursor) {
  8. Cursor old = swapCursor(cursor);
  9. if (old != null) {
  10. old.close();
  11. }
  12. }
  13.  
  14. /**
  15. * Swap in a new Cursor, returning the old Cursor. Unlike
  16. * {@link #changeCursor(Cursor)}, the returned old Cursor is <em>not</em>
  17. * closed.
  18. *
  19. * @param newCursor The new cursor to be used.
  20. * @return Returns the previously set Cursor, or null if there wasa not one.
  21. * If the given new Cursor is the same instance is the previously set
  22. * Cursor, null is also returned.
  23. */
  24. public Cursor swapCursor(Cursor newCursor) {
  25. if (newCursor == mCursor) {
  26. return null;
  27. }
  28. Cursor oldCursor = mCursor;
  29. if (oldCursor != null) {
  30. if (mChangeObserver != null) oldCursor.unregisterContentObserver(mChangeObserver);
  31. if (mDataSetObserver != null) oldCursor.unregisterDataSetObserver(mDataSetObserver);
  32. }
  33. mCursor = newCursor;
  34. if (newCursor != null) {
  35. if (mChangeObserver != null) newCursor.registerContentObserver(mChangeObserver);
  36. if (mDataSetObserver != null) newCursor.registerDataSetObserver(mDataSetObserver);
  37. mRowIDColumn = newCursor.getColumnIndexOrThrow("_id");
  38. mDataValid = true;
  39. // notify the observers about the new cursor
  40. notifyDataSetChanged();
  41. } else {
  42. mRowIDColumn = -1;
  43. mDataValid = false;
  44. // notify the observers about the lack of a data set
  45. notifyDataSetInvalidated();
  46. }
  47. return oldCursor;
  48. }

6. 实战AsyncQueryHandler中Cursor的关闭问题
    AsyncQueryHandler是一个很经典很典型的分析Cursor的例子,不仅一阵见血,能举一反三,而且非常常见,为以后避免。
    AsyncQueryHandler文档参考地址:
    http://developer.android.com/reference/android/content/AsyncQueryHandler.html
    下面这段代码是Android2.3系统中Mms信息主页面ConversationList源码的一部分,大家看看Cursor正确关闭了吗?

  1. private final class ThreadListQueryHandler extends AsyncQueryHandler {
  2. public ThreadListQueryHandler(ContentResolver contentResolver) {
  3. super(contentResolver);
  4. }
  5.  
  6. @Override
  7. protected void onQueryComplete(int token, Object cookie, Cursor cursor) {
  8. switch (token) {
  9. case THREAD_LIST_QUERY_TOKEN:
  10. mListAdapter.changeCursor(cursor);
  11. setTitle(mTitle);
  12. ... ...
  13. break;
  14.  
  15. case HAVE_LOCKED_MESSAGES_TOKEN:
  16. long threadId = (Long)cookie;
  17. confirmDeleteThreadDialog(new DeleteThreadListener(threadId, mQueryHandler,
  18. ConversationList.this), threadId == -1,
  19. cursor != null && cursor.getCount() > 0,
  20. ConversationList.this);
  21. break;
  22.  
  23. default:
  24. Log.e(TAG, "onQueryComplete called with unknown token " + token);
  25. }
  26. }
  27. }
  28.  
  29. @Override
  30. protected void onStop() {
  31. super.onStop();
  32.  
  33. mListAdapter.changeCursor(null);
  34. }

    大家觉得有问题吗?
    主要是两点:
    (1). THREAD_LIST_QUERY_TOKEN分支的Cursor正确关闭了吗?
    (2). HAVE_LOCKED_MESSAGES_TOKEN分支的Cursor正确关闭了吗?
    根据前面的一条条分析,答案是:
    (1). THREAD_LIST_QUERY_TOKEN分支的Cursor被传递到了mListAdapter了,而mListAdapter在onStop里面使用changeCursor(null),当用户离开当前Activity,这个Cursor被正确关闭了,不会泄露。
    (2). HAVE_LOCKED_MESSAGES_TOKEN分支的Cursor(就是参数cursor),只是作为一个判断的一个条件,被使用后不再使用,但是也没有关掉,所以cursor泄露,在StrictMode监视下只要跑到这个地方都会抛出这个错误:

  1. E/StrictMode(639): A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
  2. E/StrictMode(639): java.lang.Throwable: Explicit termination method 'close' not called
  3. E/StrictMode(639): at dalvik.system.CloseGuard.open(CloseGuard.java:184)
  4. ... ...

  在Android4.0 JellyBean中谷歌修正了这个泄露问题,相关代码如下:

  1. private final class ThreadListQueryHandler extends ConversationQueryHandler {
  2. public ThreadListQueryHandler(ContentResolver contentResolver) {
  3. super(contentResolver);
  4. }
  5.  
  6. @Override
  7. protected void onQueryComplete(int token, Object cookie, Cursor cursor) {
  8. switch (token) {
  9. case THREAD_LIST_QUERY_TOKEN:
  10. mListAdapter.changeCursor(cursor);
  11.  
  12. ... ...
  13.  
  14. break;
  15.  
  16. case UNREAD_THREADS_QUERY_TOKEN:
  17. // 新增的UNREAD_THREADS_QUERY_TOKEN分子和HAVE_LOCKED_MESSAGES_TOKEN分支也是类似的情况,cursor在jellybean中被及时关闭了
  18. int count = 0;
  19. if (cursor != null) {
  20. count = cursor.getCount();
  21. cursor.close();
  22. }
  23. mUnreadConvCount.setText(count > 0 ? Integer.toString(count) : null);
  24. break;
  25.  
  26. case HAVE_LOCKED_MESSAGES_TOKEN:
  27. @SuppressWarnings("unchecked")
  28. Collection<Long> threadIds = (Collection<Long>)cookie;
  29. confirmDeleteThreadDialog(new DeleteThreadListener(threadIds, mQueryHandler,
  30. ConversationList.this), threadIds,
  31. cursor != null && cursor.getCount() > 0,
  32. ConversationList.this);
  33. // HAVE_LOCKED_MESSAGES_TOKEN分支中的cursor在jellybean中被及时关闭了
  34. if (cursor != null) {
  35. cursor.close();
  36. }
  37. break;
  38.  
  39. default:
  40. Log.e(TAG, "onQueryComplete called with unknown token " + token);
  41. }
  42. }
  43. }
  44.  
  45.  
  46. @Override
  47. protected void onStop() {
  48. super.onStop();
  49. mListAdapter.changeCursor(null);
  50. }

  是不是小看了AsyncQueryHandler,谷歌在早期的版本里面都有一些这样的代码,更何况不注意的我们呢,实际上网上很多使用AsyncQueryHandler举例中都犯了这个错误,看完这篇文章后,以后再也不怕AsyncQueryHandler的cursor泄露了,还说不定能解决很多你现在应用的后台strictmode的cursor not close异常问题。

7. 小结
    虽然我觉得还有很多cursor未关闭的情况没有说到,但是根本问题都是及时正确的关闭cursor。
    内存泄露cursor篇是我工作经验上的一个总结,专门捋清楚后对我自己对大家觉得都很有帮助,让复杂的问题本质化,简单化!