Android簡訊批量插入速度最佳化的思考與嘗試

        在做Android上簡訊的備份還原功能時，簡訊的恢複思路最初考慮的很簡單，迴圈解析檔案，每得到一條簡訊，就調用SMSProvider的insert方法將簡訊插入資料庫，SMSProvider是簡訊資料庫操作的最基本的類，重載了父類ContentProvider的query,insert,delete和update方法，除了insert方法，父類ContentProvider中還有個bulkInsert方法，該方法為批量插入，代碼如下：

    public int bulkInsert(Uri uri, ContentValues[] values) {
        int numValues = values.length;
        for (int i = 0; i < numValues; i++) {
            insert(uri, values[i]);
        }
        return numValues;
    }

可以看出來，該函數只是簡單的迴圈調用了insert方法，而insert是虛方法，所以真正在使用時會調用到SMSProvider的insert方法，並沒有速度上的優勢；

      在實際使用過程中，要恢複的簡訊數量多時，速度有點無法忍受，決定考慮下對速度的最佳化;

      Android資料庫使用精巧的Sqlite3，幸運的是Sqlite3是支援事務的，自然就想到了統一事務對批量插入帶來的好處，這是嘗試速度最佳化的第一個方向，

db.beginTransaction(); 
try {
    //Here資料庫操作
    db.setTransactionSuccessful(); //別忘了這句 
} catch (xxx) {
   //XXXXX
} finaly {
    db.endTransaction(); //Commit
}

帶來了其他風險，對於簡訊這個應用是不被允許的。

……………………………………………………………………………………………………………………………………………………………………

這是很早之前寫的，目前嘗試失敗了，寫出原因：

     上面也提到了bulkInsert這個函數，他裡面並沒有使用統一事務的方法來將簡訊批量插入，而是迴圈調用insert，並沒有什麼速度上的優勢與考慮，我想Android的開發人員們，不可能不知道Sqlite3統一事務的方法，那他們為什麼放著不用呢？？

     原因是如果使用統一事務會帶來另外一個風險--丟失收到的簡訊；事務的開啟是要鎖定DB的，也就是說開啟一個事務之後，其他對資料庫的寫入操作都是無法成功的，這樣的話，如果在一次統一事務裡操作的資料很多，需要消耗一定的時間，那麼簡訊到來時，其是無法被insert到資料庫裡的，也就收不到這條簡訊了，與簡訊恢複這個操作速度慢來比，這更加不能被允許；另外一個風險就是死結，說到底是因為Sqlite3對並發情況支援的不是很好；

     經過我的實際測試，發現當資料庫裡原來的資料不多時，統一事務的方法批量插入消耗的時間還是蠻少的，但隨著資料越來越多，就會越來越慢了~~~更好的實現方法自己再慢慢摸索吧，上面的嘗試也算學習了吧。。。。