Contentprovider类图
Provider进程不存在: 当provider进程不存在时,先创建进程并publish相关的provider,
AT为ActivityThread，cpr为ContentProviderRecord
图解:
client进程：通过binder(调用AMS.getContentProviderImpl)向system_server进程请求相应的provider；
system进程：如果目标provider所对应的进程尚未启动，system_server会调用startProcessLocked来启动provider进程； 当进程启动完成，此时cpr.provider ==null，则system_server便会进入wait()状态，等待目标provider发布；
provider进程：进程启动后执行完attch到system_server，紧接着执行bindApplication；在这个过程会installProvider以及 publishContentProviders；再binder call到system_server进程；
system进程：再回到system_server，发布provider信息，并且通过notify机制，唤醒前面处于wait状态的binder线程；并将 getContentProvider的结果返回给client进程；
client进程：接着执行installProvider操作，安装provider的(包含对象记录,引用计数维护等工作)；
另外，关于CONTENT_PROVIDER_PUBLISH_TIMEOUT超时机制所统计的时机区间是指在startProcessLocked之后会调用AMS.attachApplicationLocked为起点，一直到AMS.publishContentProviders的过程。
进程存在，provider未发布: 请求provider时,provider进程存在但provide的记录对象cpr ==null,AT为ActivityThread，cpr为ContentProviderRecord，这时的流程如下:
Client进程在获取provider的过程,发现cpr为空,则调用scheduleInstallProvider来向provider所在进程发出一个oneway的binder请求,并进入wait()状态.
provider进程安装完provider信息,则notifyAll()处于等待状态的进程/线程;
如果provider在publish完成之后, 这时再次请求该provider,那就便没有的最右侧的这个过程,直接在AMS.getContentProviderImpl之后便进入AT.installProvider的过程,而不会再次进入wait()过程.
最后, 关于provider分为stable provider和unstable provider, 在于引用计数 的不同，一句话来说就是stable provider建立的是强连接, 客户端进程的与provider进程是存在依赖关系, 即provider进程死亡则会导致客户端进程被杀.