- contentProvider的初始化是在它自己进程的主线程里面完成,一般发生在有人第一次访问这个contentProvider或者这个contentProvider进程第一次启动,比如这个进程有个service,开机启动,那么随着servier启动的还有contentProvider.
- contentProvider有个android:multiProcess属性,用来配置是否在多个进程里面,有不同的实例。如果为true,那么它就会在每个访问这个contentProvider的进程里面生成一个对象。这个时候调用contentProvider,就是哪个线程调用的,contentProvider就运行在那个线程里面。
- 如果这个值配置为false,那么多个进程之间共享一个contentProvider,通过binder来进行进程之间对象传递。如果多个进程同时访问,会为每个访问请求分配个线程。所以,这些操作,比如查询,不会运行在contentProvider进程的主线程。
- contentProvider查询等操作是否需要等待,需要binder来设置。
- 另外,contentProvider查询的数据传递是通过ashmem来完成的。
总而言之,1. contentProvider的初始化是在主线程里面完成。2. 请求查询等操作的话,应用程序最好自己起一个线程去完成。3. contentProvider实现比较复杂,底层交互甚多。首先感谢你细心的回答,看完你的回答后,我还是存在以下几个不解之处:1、您说的“contentProvider的初始化是在它自己进程的主线程里面完成”,初始化应该未生成对象吧?也就是说ContentProvider并没有在主线程生成对象,而是谁访问它,它才在访问的线程完成实例化并生成对象?2、如果android:multiProcess的值为false,您说“多个进程之间共享一个contentProvider,通过binder来进行进程之间对象传递。”,那么传递的对象是否是在ContentProvider所属的进程完成实例化后才通过binder传递给需要的进程?3、还有“contentProvider查询的数据传递是通过ashmem来完成的。”,是不是说存放查询结果的Cursor之所以能够跨进程返回到访问ContentProvider的进程是因为它是把返回值Cursor通过ashmem机制存放到某块内存,然后访问ContentProvider的进程再去取?
1. 第一点的话,ContentProvider初始化的时候,会把自己初始化之后生成的对象存在Ams里面,ams的话是一个系统进程。嗯,具体你可以百度下,因为内容比较多。然后其他进程去请求获取contentProvider对象时,一般第一次都会来ams里面获取。获取到之后,一般会在自己进程里面进行缓存。以便于下次获取。
2. 是的,它是ContentProvider初始化完成之后存在ams的对象,通过binder传给具体的某个调用contentProvider的进程
3. ashmem机制的话是比较底层的东西,嗯,ContentProvider通信的基础吧。大概意思就是ContentProvider进程里面有一块共享内存,用来存放这次查询的数据。然后通过binder这个内存地址传递给调用ContentProvider的进程,这样,这个调用ContentProvider的进程就能访问ContentProvider进程的共享内存了。至于cursor的话,只是java上层的一个对象,底层ashmem那块,怎么跨进程传地址,怎么读数据已经全部封装好了。。
contentProivder 启动这块,可以参考下这个帖子:http://bbs.51cto.com/thread-1068382-1.html