用 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.