用 managedQuery() 時需要注意的一個陷阱

Activity 裡面提供了一個 managedQuery() 方法，按照 Android SDK 裡面的說明，“the activity will manage its lifecycle for you.” 聽起來很好，Activity 可以替你管理 Cursor 的生命週期了，就不用記著去 close() 了，代碼可以更簡潔。

但是 Activity 是怎麼去管理 Cursor 的生命週期的呢？SDK 文檔沒說。最近遇到一個 bug，在一個 Activity 中，用 managedQuery() 查詢資料庫，將查詢得到的 Cursor 用 CursorAdapter 與 ListView 綁定。然後在 Activity 裡面執行大量刪除資料表記錄操作，因為耗時比較長，所以用了多執行緒。測試團隊發現的 bug 是，在刪除操作進行過程中，如果按下 Home 鍵，應用就崩潰了。崩潰原因是 Cursor 被釋放了，導致背景工作執行緒的刪除操作異常。

看了 Activity.java 的源碼之後就明白為什麼會崩潰了。managedQuery() 其實無非就是把查詢得到的 Cursor 放到了 Activity 類的一個數群組成員變數中，然後當 Activity stop 的時候，將這個數組裡的每個 cursor 都關掉，以及在 resume 的時候，將數組裡的每個 cursor 都重新查詢一次。所以在按下 Home 鍵之後，Activity 被 stop 了，cursor 也就被關閉了，如果有個線程還在繼續使用這個 cursor，就會拋異常了。

因此，在用 managedQuery() 的時候，需要清楚 cursor 什麼時候會被釋放，並考慮好自己的代碼在 cursor 被釋放後不再需要使用這個 cursor.