在做Android上短信的备份还原功能时，短信的恢复思路最初考虑的很简单，循环解析文件，每得到一条短信，就调用SMSProvider的insert方法将短信插入数据库，SMSProvider是短信数据库操作的最基本的类，重载了父类ContentProvider的query,insert,delete和update方法，除了insert方法，父类ContentProvider中还有个bulkInsert方法，该方法为批量插入，代码如下：
<span style="font-size:14px;">public int bulkInsert(Uri uri, ContentValues[] values) {
int numValues = values.length;
for (int i = 0; i < numValues; i++) {
insert(uri, values[i]);
}
return numValues;
}</span>
可以看出来，该函数只是简单的循环调用了insert方法，而insert是虚方法，所以真正在使用时会调用到SMSProvider的insert方法，并没有速度上的优势；
在实际使用过程中，要恢复的短信数量多时，速度有点无法忍受，决定考虑下对速度的优化;
Android数据库使用精巧的Sqlite3，幸运的是Sqlite3是支持事务的，自然就想到了统一事务对批量插入带来的好处，这是尝试速度优化的第一个方向，
<span style="font-size:14px;">db.beginTransaction();
try {
//Here数据库操作
db.setTransactionSuccessful(); //别忘了这句
} catch (xxx) {
//XXXXX
} finaly {
db.endTransaction(); //Commit
}</span>
带来了其他风险，对于短信这个应用是不被允许的。
……………………………………………………………………………………………………………………………………………………………………
这是很早之前写的，目前尝试失败了，写出原因：
上面也提到了bulkInsert这个函数，他里面并没有使用统一事务的方法来将短信批量插入，而是循环调用insert，并没有什么速度上的优势与考虑，我想Android的开发人员们，不可能不知道Sqlite3统一事务的方法，那他们为什么放着不用呢？？
原因是如果使用统一事务会带来另外一个风险--丢失收到的短信；事务的开启是要锁定DB的，也就是说开启一个事务之后，其他对数据库的写入操作都是无法成功的，这样的话，如果在一次统一事务里操作的数据很多，需要消耗一定的时间，那么短信到来时，其是无法被insert到数据库里的，也就收不到这条短信了，与短信恢复这个操作速度慢来比，这更加不能被允许；另外一个风险就是死锁，说到底是因为Sqlite3对并发情况支持的不是很好；
经过我的实际测试，发现当数据库里原来的数据不多时，统一事务的方法批量插入消耗的时间还是蛮少的，但随着数据越来越多，就会越来越慢了~~~更好的实现方法自己再慢慢摸索吧，上面的尝试也算学习了吧。。。。