Android7.0中关于ContentProvider组件详解
作为android的四大组件之一,contentprovider作为进程之间静态数据传递的重要手段,其在系统级别的应用中起了重大的作用。毫无疑问,contentprovider核心机制之一也是binder,但是和其它3大组件又有区别。因为contentprovider涉及数据的增删查改,当数据量比较大的时候,继续用parcel做容器效率会比较低,因此它还使用了匿名共享内存的方式。
但是有一个问题是,contentprovider的提供者进程不再存活时,其他进程通过provider读一个非常简单的数据时,都需要先把提供者进程启动起来(除非指定multiprocess=true),这对用户是相当不友好的。又因为其是间接通过db进行数据操作,所以效率也远不如直接操作db。因此在用户app中,不是很建议经常使用contentprovider。不过对于系统级的app,它统一了数据操作的规范,利是远大于弊的。
contentprovider发布
当进程第一次启动时候会调用handlebindapplication
if (!data.restrictedbackupmode) { if (!arrayutils.isempty(data.providers)) { installcontentproviders(app, data.providers); } }
当xml中有provider时,进行provider的发布
final arraylist<iactivitymanager.contentproviderholder> results = new arraylist<iactivitymanager.contentproviderholder>(); for (providerinfo cpi : providers) { iactivitymanager.contentproviderholder cph = installprovider(context, null, cpi, false /*noisy*/, true /*noreleaseneeded*/, true /*stable*/); if (cph != null) { cph.noreleaseneeded = true; results.add(cph); } } try { activitymanagernative.getdefault().publishcontentproviders( getapplicationthread(), results); } catch (remoteexception ex) { }
@installprovider(这个方法先简单过一下,后面会继续说)
final java.lang.classloader cl = c.getclassloader(); localprovider = (contentprovider)cl. loadclass(info.name).newinstance(); provider = localprovider.geticontentprovider();
@installproviderauthoritieslocked
for (string auth : auths) { final providerkey key = new providerkey(auth, userid); final providerclientrecord existing = mprovidermap.get(key); if (existing != null) { } else { mprovidermap.put(key, pcr); } }
这里两步把providerinfo通过installprovider转换成contentprovider的binder对象icontentprovider,并放于contentproviderholder中。并根据auth的不同,把发布进程的providerclientrecord保存在一个叫mprovidermap的成员变量中,方便第二次调用同一个contentprovider时,无需重新到ams中去查询。
ams @publishcontentproviders
final int n = providers.size(); for (int i = 0; i < n; i++) { contentproviderholder src = providers.get(i); ... contentproviderrecord dst = r.pubproviders.get(src.info.name); if (dst != null) { componentname comp = new componentname(dst.info.packagename, dst.info.name); mprovidermap.putproviderbyclass(comp, dst); string names[] = dst.info.authority.split(";"); for (int j = 0; j < names.length; j++) { mprovidermap.putproviderbyname(names[j], dst); } int launchingcount = mlaunchingproviders.size(); int j; boolean wasinlaunchingproviders = false; for (j = 0; j < launchingcount; j++) { if (mlaunchingproviders.get(j) == dst) { mlaunchingproviders.remove(j); wasinlaunchingproviders = true; j--; launchingcount--; } } if (wasinlaunchingproviders) { mhandler.removemessages(content_provider_publish_timeout_msg, r); } ... } }
可以看到,ams会遍历所有的contentproviderholder,然后调用mprovidermap把信息保存起来,这块接下来说。保存好之后,先去看看之前是不是已经有launch过的,如果已经有launch过的,不再重复launch。再说说这个mprovidermap,这个和activitythread中的mprovidermap不太一样,这个是一个成员实例,非真正的map。看看putproviderbyclass和putproviderbyname。
providermap@putproviderbyclass
if (record.singleton) { msingletonbyclass.put(name, record); } else { final int userid = userhandle.getuserid(record.appinfo.uid); getprovidersbyclass(userid).put(name, record); }
providermap@putproviderbyname
if (record.singleton) { msingletonbyname.put(name, record); } else { final int userid = userhandle.getuserid(record.appinfo.uid); getprovidersbyname(userid).put(name, record); }
可以看到,发布的provider实际会根据class或authority存在不同的map中。如果是单例,则分别存到相应的msingleton map中,否则就根据userid存到相应的map中。这样发布的过程就完成了,其他进程需要使用的时候将会在ams按需读取。
contentreslover跨进程数据操作
当我们跨进程调用数据时候,会先调用获取用户进程的contentresolver
context.getcontentresolver().query(uri, ...); public contentresolver getcontentresolver() { return mcontentresolver; }
而这个contentresolver在每个进程中都存在有且唯一的实例,其在contextimpl构造函数中就已经初始化了,其初始化的实际对象是applicationcontentresolver。
mcontentresolver = new applicationcontentresolver(this, mainthread, user);
这个contentresolver是活在调用者进程中的,它是作为一个类似桥梁的作用。以插入为例:
contentresolver@insert
icontentprovider provider = acquireprovider(url); if (provider == null) { throw new illegalargumentexception("unknown url " + url); } try { long starttime = systemclock.uptimemillis(); uri createdrow = provider.insert(mpackagename, url, values); ... return createdrow; } catch (remoteexception e) { return null; } finally { releaseprovider(provider); }
问题就转化成了,拿到其他进程的contentprovider的binder对象,有了binder对象就可以跨进程调用其方法了。
contentresolver@acquireprovider
if (!scheme_content.equals(uri.getscheme())) { return null; } final string auth = uri.getauthority(); if (auth != null) { return acquireprovider(mcontext, auth); }
校验其uri,其scheme必须为content。
applicationcontentresolver@acquireprovider
protected icontentprovider acquireprovider(context context, string auth) { return mmainthread.acquireprovider(context, contentprovider.getauthoritywithoutuserid(auth), resolveuseridfromauthority(auth), true); }
这里面有个特别的函数会传递一个true的参数给activitythread,这意味本次连接是stable的。那stable和非stable的区别是什么呢?这么说吧:
stable provider:若使用过程中,provider要是挂了,你的进程也必挂。
unstable provider:若使用过程中,provider要是挂了,你的进程不会挂。但你会收到一个deadobjectexception的异常,可进行容错处理。
继续往下。
activitythread@acquireprovider
final icontentprovider provider = acquireexistingprovider(c, auth, userid, stable); if (provider != null) { return provider; } iactivitymanager.contentproviderholder holder = null; try { holder = activitymanagernative.getdefault().getcontentprovider( getapplicationthread(), auth, userid, stable); } catch (remoteexception ex) { } if (holder == null) { return null; } holder = installprovider(c, holder, holder.info, true /*noisy*/, holder.noreleaseneeded, stable); return holder.provider;
这里面分了三步,1、寻找自身进程的缓存,有直接返回。 2、缓存没有的话,寻找ams中的provider。3、installprovider,又到了这个方法。怎么个install法?还是一会儿再说。
@acquireexistingprovider (寻找自身缓存)
synchronized (mprovidermap) { final providerkey key = new providerkey(auth, userid); final providerclientrecord pr = mprovidermap.get(key); if (pr == null) { return null; } icontentprovider provider = pr.mprovider; ibinder jbinder = provider.asbinder(); ... providerrefcount prc = mproviderrefcountmap.get(jbinder); if (prc != null) { incproviderreflocked(prc, stable); } return provider;
这一步就是读取我们发布时提到的mprovidermap中的缓存。当provider记录存在,且进程存活的情况下,则在provider引用计数不为空时则继续增加引用计数。
缓存不存在,则去ams中找
ams@getcontentproviderimpl
contentproviderrecord cpr; cpr = mprovidermap.getproviderbyname(name, userid); if (providerrunning){ if (r != null && cpr.canrunhere(r)) { contentproviderholder holder = cpr.newholder(null); holder.provider = null; return holder; } }
public boolean canrunhere(processrecord app) { return (info.multiprocess || info.processname.equals(app.processname)) && uid == app.info.uid; }
provider是提供保护数据的接入访问的。一般情况下,不同进程的访问只能通过ipc来进行,但那是有些情况是可以允许访问者在自己的进程中创建本地provider来进行访问的。
这种情况是在uid必须相同的前提下,要么同一进程,要么provider设定了multiprocess为true。
if (!providerrunning) { cpi = appglobals.getpackagemanager().resolvecontentprovider(name, stock_pm_flags | packagemanager.get_uri_permission_patterns, userid); ... componentname comp = new componentname(cpi.packagename, cpi.name); cpr = mprovidermap.getproviderbyclass(comp, userid); if (r != null && cpr.canrunhere(r)) { return cpr.newholder(null); } processrecord proc = getprocessrecordlocked( cpi.processname, cpr.appinfo.uid, false); if (proc != null && proc.thread != null) { if (!proc.pubproviders.containskey(cpi.name)) { proc.pubproviders.put(cpi.name, cpr); proc.thread.scheduleinstallprovider(cpi); } } else { proc = startprocesslocked(cpi.processname, cpr.appinfo, false, 0, "content provider", new componentname(cpi.applicationinfo.packagename, cpi.name), false, false, false); } } } mprovidermap.putproviderbyname(name, cpr); }
这块步骤比较多,挑重点就是,先从ams的providermap对象中获取ams缓存。获得后如果provider没有launch,则ams通知其进程install其provider。如果进程不存在,则新孵化一个进程。
@installprovider
回到第三步中的installprovider
private iactivitymanager.contentproviderholder installprovider(context context, iactivitymanager.contentproviderholder holder, providerinfo info, boolean noisy, boolean noreleaseneeded, boolean stable)
可以看到,这个方法里面有6个参数,其中包含contentproviderholder、providerinfo、noreleaseneeded,这几个很重要的参数。
contentproviderholder:当参数为空的时候,说明缓存为空,也就意味着是进程启动的时候调用发布provider。当缓存不为空的时候,还得做一些处理。
providerinfo:包含provider的一些信息,不能为空。
noreleaseneeded:为true的时候provider对于自身进程来说或系统的provider,是永久install的,也就是不会被destory的。
contentprovider localprovider = null; icontentprovider provider; if (holder == null || holder.provider == null) { try { final java.lang.classloader cl = c.getclassloader(); localprovider = (contentprovider)cl. loadclass(info.name).newinstance(); provider = localprovider.geticontentprovider(); if (provider == null) { return null; } localprovider.attachinfo(c, info); } catch (java.lang.exception e) { } } else { provider = holder.provider; }
这部分在发布的时候已经说了,缓存holder为null的时候,new一个实例。
iactivitymanager.contentproviderholder retholder; synchronized (mprovidermap) { ibinder jbinder = provider.asbinder(); if (localprovider != null) { componentname cname = new componentname(info.packagename, info.name); providerclientrecord pr = mlocalprovidersbyname.get(cname); if (pr != null) { provider = pr.mprovider; } else { holder = new iactivitymanager.contentproviderholder(info); holder.provider = provider; holder.noreleaseneeded = true; pr = installproviderauthoritieslocked(provider, localprovider, holder); mlocalproviders.put(jbinder, pr); mlocalprovidersbyname.put(cname, pr); } retholder = pr.mholder; } else { ... }
如果localprovider不等于null,则意味着是new一个实例的情况,这时候还是先去获取缓存,没有的话再真正地new一个contentproviderholder实例,并把通过installproviderauthoritieslocked方法把相关信息存入mprovidermap中,这个就是对应发布provider提的那个方法。
iactivitymanager.contentproviderholder retholder; synchronized (mprovidermap) { ... } else { providerrefcount prc = mproviderrefcountmap.get(jbinder); if (prc != null) { if (!noreleaseneeded) { incproviderreflocked(prc, stable); try { activitymanagernative.getdefault().removecontentprovider( holder.connection, stable); } } } else { providerclientrecord client = installproviderauthoritieslocked( provider, localprovider, holder); if (noreleaseneeded) { prc = new providerrefcount(holder, client, 1000, 1000); } else { prc = stable ? new providerrefcount(holder, client, 1, 0) : new providerrefcount(holder, client, 0, 1); } mproviderrefcountmap.put(jbinder, prc); } retholder = prc.holder; }
如果localprovider等于空,也就意味着有holder缓存或者new时候出现的异常。那先从计数map中取缓存,如果缓存不为空(之前有过计数了),这时候如果设置了noreleaseneeded,那就说明不需要计数。如果noreleaseneeded为false,则把计数器数据转移到一个新引用上,同时销毁旧的。
如果缓存为空,说明之前没有计数过。那还是先通过installproviderauthoritieslocked把信息保存到mprovidermap中。这时候如果noreleaseneeded为true,把stable和非stable的数据都瞎设置了一个1000,反正用不到。。。否则就相应的+1,并把计数器放入相应的缓存中。最后再把holder返回。
再回到contentresolver方法中,我们拿到了provider的binder引用,就可以执行相应的方法了。
上一篇: 白斩鸡调料如何调制
下一篇: 免费产品虽好,但并不适合创业者