Android面试之SQLite数据库
鹭岛厦门是个很美丽的海滨城市，给我的感觉很舒适和悠闲，据说政府对到那工作的高新技术人才第一年有10万元的奖励，因为这个原因我很有兴趣的参加了一个厦门公司的面试。他们主要是研发VOIP方面的技术，对手机应用的性能优化和音频算法有较高的要求。
他们招人的薪资半年内涨了30万元，都一直都没有招到合适的人。为什么呢?因为他们要求技术好的同时，英语也要好。什么才叫好呢?就是可以用流利的英语和国外的团队无障碍交流。
这就为难很多程序员了。这里就不再讲英语的励志故事了，我们回到技术面试上。厦门这家公司对技术的要求还是比较高，问了很多对Android机制的理解问题，为什么面试官很在意对机制的理解呢?因为实际的项目中很多性能问题都是由于缺乏对Android运行机制的正确理解的程序员引发的。除了机制问题，现在印象比较深的就是关于SQLite数据库操作的性能优化问题。 面试题：如何对SQLite数据库中进行大量的数据插入?
Android系统内置了SQLite数据库，并且提供了一整套的API用于对数据库进行增删改查操作。SQLite是一个轻量的、跨平台的、开源的数据库引擎。SQLite每个数据库都是以单个文件(.db)的形式存在，这些数据都是以B-Tree的数据结构形式存储在磁盘上。
使用SQLiteDatabase的insert，delete等方法或者execSQL方法默认都开启了事务，如果操作的顺利完成才会更新.db数据库。事务的实现是依赖于名为rollback journal文件，借助这个临时文件来完成原子操作和回滚功能。 大家可以在/data/data//databases/目录下看到一个和数据库同名的.db-journal文件。
SQLite想要执行操作，需要将程序中的SQL语句编译成对应的
SQLiteStatement，比如\，每执行一次都需要将这个String类型的SQL语句转换成SQLiteStatement。如下insert的操作最终都是将ContentValues转成SQLiteStatementi：
public long insertWithOnConflict(String table, String nullColumnHack,
ContentValues initialValues, int conflictAlgorithm) { // 省略部份代码
SQLiteStatement statement = new SQLiteStatement(this, sql.toString(), bindArgs); try {
return statement.executeInsert(); } finally { statement.close(); }
} finally {
releaseReference(); } }
对于批量处理插入或者更新的操作，我们可以重用SQLiteStatement，使用SQLiteDatabase的beginTransaction()方法开启一个事务，样例如下： try {
sqLiteDatabase.beginTransaction();
SQLiteStatement stat = sqLiteDatabase.compileStatement(insertSQL); // 插入10000次
for (int i = 0; i < 10000; i++) {
stat.bindLong(1, 123456); stat.bindString(2, \ stat.executeInsert(); }
sqLiteDatabase.setTransactionSuccessful(); }
catch (SQLException e) {
e.printStackTrace(); } finally { // 结束
sqLiteDatabase.endTransaction(); sqLiteDatabase.close(); }
我在华为Nexus 6P上对常见的几种做法做了一下测试。 直接使用SQL语句进行插入 直接使用SQL语句插入，添加事务 使用ContentValues方式，添加事务 使用SQLiteStatement方式，添加事务 结果如下图：
从数据上看，第四种方式使用SQLiteStatement最快，不过只要添加了事务(或者说只需要一个事务，不是每条插入都使用事务)，后三种方式的差别并不大。所以针过这个题目的插入的优化可以通过“SQLiteStatement+事务”的方式显著提高效率。
查询方面的优化一般可以通过建立索引。建立索引会对插入和更新的操作性能产生影响，使用索引需要考虑实际情况进行利弊权衡，对于查询操作量级较大，业务对要求查询要求较高的，还是推荐使用索引。所以这会有一个取舍问题，看你的项目是查询频繁还是插入和修改频繁。当然还有一些小的优化细节，如果面试官问到也可以说几点(如limit)。 线程问题
SQLite的同步锁精确到数据库级，粒度比较大，不像别的数据库有表锁，行锁。同一个时间只允许一个连接进行写入操作。
如果有大量的数据处理，那么肯定不合适于在UI线程去操作，这时就要考虑多线程的问题了。我们如果开一个工作线程去操作SQLite数据库，如批量地插入可能需要30秒钟，而这个时间UI线程也要从数据库读取一下数据展示给用户，那么这个时候UI线程能读取到这个数据库吗?大家可以思考一下这个问题。 我们常常在多线程中只使用一个SQLiteDatabase引用，在用
SQLiteDataBase.close()的时需要注意调是否还有别的线程在使用这个实例。如果一个线程操作完成后就直接close了，别一个正在使用这个数据库的线程就会异常。所以有些人会直接把SQLiteDatabase的实例放在Application中，让它
们的生命周期一致。也有的做法是写一个计数器，当计数器为0时才真正关闭数据库。
使用ORM的问题
目前网上有很多开源的ORM(对象关系数据映射)框架，如greenDAO、ormlite等等。在使用这些框架有必要很了解一下它们的利弊，特别是一些使用反射的框架，对性能的影响会比较大。有些框架在多线程同步方面也会产生一些问题，所以使用时要有所顾虑。
Realm 是最近兴起的一个专注于移动设备数据库的库，其核心是使用C++编写，号称很多时候数据的存取速度比SQLite要快很多。不过在我的一些项目中，发现它读取并不比SQLite快。 小结
在实践中我们总结出一条守则：“不要用Helloworld来测试自己的框架(或代码)，要测就要用真实的数据和环境。”
特别是针对数据库方面，如果只用几条简单的数据进行测式，那么你会很容易傲娇和满足，而忽视了很多问题。没有经过真实数据(或大量数据)测试之前，不要对自己的代码太过自信。