本文基于Android 4.2源码

Android工程师对settings.db一定不会陌生。settings.db里保存了许多在系统中共享的，甚至是关键的属性。无论是Framework，还是App都在使用。
对于settings.db的相关操作，Android使用了ContentProvider进行封装，并作为一个组件添加到system用户组当中。所有的对settings.db的操作，最终都会由SettingsProvider来完成。
Android提供了两种操作途径来使用settings.db，一个是通过编译在Framework中的Settings API；另一个则是在adb shell下使用的Settings command。无论是哪一个途径，对他们来说，SettingsProvider都是透明的，他们使用的都是SettingsProvider的Binder IPC接口。这里再次体现了Android设计架构的厉害，对涉及修改settings.db本身的操作实现、缓存持久化等操作只需要碰SettingsProvider；但如果想要修改暴露在外界的功能API，基本上只需要修改Settings API/command即可，两个功能模块之间不会相互干扰，可以独立运行和维护。

SettingsProvider的操作框架简图：

具体的CRUD操作解析参见下一篇：重要的几个API方法

• query: Settings API的query每次都会从settings.db中读取；Settings command为了获得更快的访问速度则总是从Cache中读取。
• insert: Cache中没有相同的Key/Value时才往settings.db中写入。
• delete: SettingsProvider的delete会先删除掉settings.db中的记录，然后删除对应Cache中的所有相关记录然后重新从settings.db中读取。
• update: 同delete一样，先更新，删除相关的所有Cache，然后重新读取。
• 可以看出，当然SettingsCache存在的意义是加快Settings command的访问速度。
• SettingsCache使用的是LruCache LruCache解析。