在做Android上短信的备份还原功能时，短信的恢复思路最初斟酌的很简单，循环解析文件，每得到1条短信，就调用SMSProvider的insert方法将短信插入数据库，SMSProvider是短信数据库操作的最基本的类，重载了父类ContentProvider的query,insert,delete和update方法，除insert方法，父类ContentProvider中还有个bulkInsert方法，该方法为批量插入，代码以下：
可以看出来，该函数只是简单的循环调用了insert方法，而insert是虚方法，所以真正在使用时会调用到SMSProvider的insert方法，并没有速度上的优势；
在实际使用进程中，要恢复的短信数量多时，速度有点没法忍耐，决定斟酌下对速度的优化;
Android数据库使用精致的Sqlite3，荣幸的是Sqlite3是支持事务的，自然就想到了统1事务对批量插入带来的好处，这是尝试速度优化的第1个方向，
带来了其他风险，对短信这个利用是不被允许的。
……………………………………………………………………………………………………………………………………………………………………
这是很早之前写的，目前尝试失败了，写出缘由：
上面也提到了bulkInsert这个函数，他里面并没有使用统1事务的方法来将短信批量插入，而是循环调用insert，并没有甚么速度上的优势与斟酌，我想Android的开发人员们，不可能不知道Sqlite3统1事务的方法，那他们为何放着不用呢？？
缘由是如果使用统1事务会带来另外1个风险--丢失收到的短信；事务的开启是要锁定DB的，也就是说开启1个事务以后，其他对数据库的写入操作都是没法成功的，这样的话，如果在1次统1事务里操作的数据很多，需要消耗1定的时间，那末短信到来时，其是没法被insert到数据库里的，也就收不到这条短信了，与短信恢复这个操作速度慢来比，这更加不能被允许；另外1个风险就是死锁，说究竟是由于Sqlite3对并发情况支持的不是很好；
经过我的实际测试，发现当数据库里原来的数据不多时，统1事务的方法批量插入消耗的时间还是蛮少的，但随着数据愈来愈多，就会愈来愈慢了~~~更好的实现方法自己再渐渐摸索吧，上面的尝试也算学习了吧。。。。