总体设计类图
以下会分拆成两个部分进行说明：
1、总体机制部分
2、Sql操作细节部分
总体机制
可以看到，有几个重要的类：
- AbstractDaoMaster ： 总入口类，每个db有相应的AbstractDaoMaster去管理，一般情况下用于创建AbstractDaoSession，并且创建xxxDao的DaoConfig，然后交给AbstractSession进行xxxDao的实例创建。
- Database ：db抽象接口，有标准的sql实例及sqlcipher加密后的两者实例
- AbstractSession ：db会话，一个AbstractDaoMaster可以创建多个会话，每个会话拥有该该db下的所有AbstractDao实例，并且决定AbstractDao实例是否使用缓存机制。很难想象多个会话是用在什么场景，一般情况下只会有一个会话。
- AbstractDao ：数据库table的实体类，用于访问该table的所有操作。AbstractDao有两个泛型，第一个是主键类型，第二个是Entity的类型。AbstractDao提供了增删改查的所有操作，由于对象是Entity，因此修改的value全部以Entity给予的值为准，也就是说每次进行修改的时候，对应的行数据都会以Entity的值进行覆盖。
- DaoConfig ：数据库table的配置定义，是greenDao的一个重要类。DaoConfig会在AbstractDaoMaster中通过registerDaoClass进行注册。在创建DaoConfig时候，通过反射机制读取xxxDAO的属性，从而生成xxxDao的配置（如column、主键、表名、增删改的语句等信息），用于数据库的增删改查曾操作。
- Property ：数据库的column定义
- IdentityScope ：很多人看到这个比较难于理解，按官方的解释：Identity scopes let greenDAO re-use Java objects. 说白了，就是一个缓存类。有两个缓存的类型：
- IdentityScopeLong
- IdentityScopeObject
主要是根据AbstractDao的主键类型选择的，如果主键是Integer、Long，可以IdentityScopeLong，其他使用IdentityScopeObject。可以IdentityScopeLong内部使用自己编写的经过优化过的LongHashMap作为存储对象，效率会更高。
操作细节设计
前面提到DaoConfig是table的配置，其中的配置包括增删改语句的生成。AbstractDao作为table的入口，增删改的操作全部依赖于DaoConfig里的TableStatements。TableStatements包含了几条语句模板：
- insertStatement
- insertOrReplaceStatement
- updateStatement
- deleteStatement
- countStatement
用于语句的快速获取。每条语句都是已经生成好的一条sql语句模板，AbstractDao使用时，只需要拿到该模板，然后进行数据的绑定就可以生成最终的sql语句。例子如下：
public DatabaseStatement getInsertOrReplaceStatement() {
if (insertOrReplaceStatement == null) {
String sql = SqlUtils.createSqlInsert("INSERT OR REPLACE INTO ", tablename, allColumns);
DatabaseStatement newInsertOrReplaceStatement = db.compileStatement(sql);
synchronized (this) {
if (insertOrReplaceStatement == null) {
insertOrReplaceStatement = newInsertOrReplaceStatement;
}
}
if (insertOrReplaceStatement != newInsertOrReplaceStatement) {
newInsertOrReplaceStatement.close();
}
}
return insertOrReplaceStatement;
}因此，可以看到，插入、更新的时候，虽然可以获取模板生成语句，但也比较笨拙，不支持灵活的根据属性进行更新的操作：假设我们想只更新AbstractDao的某个property，那就只能老老实实的写sql语句的，这点实在是坑！
而最最复杂的查询语句，则是通过QueryBuilder强大的功能进行查询。greenDao查询、更新的操作都是必须每次针对所有column进行操作，不支持部分column的查询和更新。从查询上确实应该如此，因此，在查询的时候，只需要提供灵活的where条件及order等条件供用户输入即可。
QueryBuilder主要包括两部分：
- 语句参数
- 生成语句并进行查询
语句参数
语句参数包含如下部分
private final WhereCollector<T> whereCollector; //where语句
private StringBuilder orderBuilder; //order标识
private final List<Object> values; //具体where值
private final List<Join<T, ?>> joins; //join值
private final AbstractDao<T, ?> dao;
private final String tablePrefix;
private Integer limit; //limit
private Integer offset; //offert
private boolean distinct;
其中WhereCollector是一个WhereCondition集合，WhereCondition包含两个接口：appendTo及appendValuesTo，用于生成最终的where语句。举个例子，And ProprotyCondition是这样生成的：
@Override
public void appendTo(StringBuilder builder, String tableAlias) {
SqlUtils.appendProperty(builder, tableAlias, property).append(op);
}
public static StringBuilder appendProperty(StringBuilder builder, String tablePrefix, Property property) {
if (tablePrefix != null) {
builder.append(tablePrefix).append('.');
}
builder.append('"').append(property.columnName).append('"');
return builder;
}QueryBuilder会根据查询的类型生成不同的AbstractQuery，通过AbstractQuery的查询，最终得到查询结果。这里有个很重要的一个类AbstractQueryData。很容易造成误解成AbstractQuery查询得到的数据，其实不是，AbstractQueryData是AbstractQuery的多线程缓存，用于缓存不同的线程下的查询语句。用于查询语句的复用，这也是greenDao高效的原因。
总结
总的来说，
- greenDao相比其他ORMLite高效，比原生sql效率低，基于2个原因：
- 初始化时采用一次反射，一次性构建好DaoConfig，最小化反射带来的负面效果。而其他ORM有些则生成sql语句时每次都使用反射，效率低也是难免的。
- 缓存使用： Entity缓存、语句缓存复用
- greenDao的查询能够比较强大，但反之Update的操作则比较粗糙，有点不友好。
- 数据库的创建和更新也未涉及，既然用到了对象，那么就可以根据对象的属性进行数据库的创建及更新。（该点会在以后介绍我的方案）
