ContentService可以看做Android中一个系统级别的消息中心，可以说搭建了一个系统级的观察者模型，APP可以向消息中心注册观察者，选择订阅自己关心的消息，也可以通过消息中心发送信息，通知其他进程，简单模型如下：
ContentService服务伴随系统启动，本身是一个Binder系统服务，运行在SystemServer进程。作为系统服务，最好能保持高效运行，因此ContentService通知APP都是异步的，被限制 oneway，仅仅插入目标进程（线程）的Queue队列，不必等待执行。下面简单分析一下整体的架构，主要从一下几个方面了解下运行流程：
- ContentService启动跟实质
- 注册观察者
- 管理观察者
- 消息分发
ContentService启动跟实质
ContentService服务伴随系统启动，更准确的说是伴随SystemServer进程启动，其入口函数如下：
public static ContentService main(Context context, boolean factoryTest) { <!--新建Binder服务实体--> ContentService service = new ContentService(context, factoryTest); <!--添加到ServiceManager中--> ServiceManager.addService(ContentResolver.CONTENT_SERVICE_NAME, service); return service; }
同AMS、WMS等系统服务类似，ContentService也是一个Binder服务实体，而且受ServiceManager管理，需要注册ServiceManager中，方便APP将来获取该服务的代理。ContentService是一个Binder服务实体，具体实现如下：
<!--关键点1--> public final class ContentService extends IContentService.Stub { private static final String TAG = "ContentService"; private Context mContext; private boolean mFactoryTest; private final ObserverNode mRootNode = new ObserverNode(""); private SyncManager mSyncManager = null; private final Object mSyncManagerLock = new Object(); 。。。
IContentService.Stub由IContentService.aidl文件生成，IContentService.aidl文件中定义了ContentService能提供的基本服务，比如注册/注销观察者、通知观察者等，如下：
interface IContentService { <!--注销一个观察者--> void unregisterContentObserver(IContentObserver observer); <!--注册一个观察者--> void registerContentObserver(in Uri uri, boolean notifyForDescendants, IContentObserver observer, int userHandle); <!--通知观察者--> void notifyChange(in Uri uri, IContentObserver observer, boolean observerWantsSelfNotifications, boolean syncToNetwork, int userHandle); ... }
虽然从使用上来说，ContentService跟ContentProvider关系紧密，但是理论上讲，这是完全独立的两套东西，ContentService是一个独立的消息分发模型，可以完全独立于ContentProvider使用（总觉的这种设计是不是有些问题），看一下基本用法：
1、注册一个观察者：
public static void registerObserver(Context context,ContentObserver contentObserver) { ContentResolver contentResolver = context.getContentResolver(); contentResolver.registerContentObserver(Uri.parse("content://"+"test"), true, contentObserver); }
2、通知观察者
public static void notity(Context context) { ContentResolver contentResolver = context.getContentResolver(); contentResolver.notifyChange(Uri.parse("content://"+"test"),null); }
可以看到，期间只是借用了ContentResolver，但是并没有牵扯到任何ContentProvider，也就是说，ContentService其实主要是为了提供了一个系统级的消息中心，下面简单看一下注册跟通知流程
注册观察者流程
App一般都是借助ContentResolver来注册Content观察者，ContextResoler其实是Context的一个成员变量，本身是一个ApplicationContentResolver对象，它是ContentResolver的子类，
private ContextImpl(ContextImpl container, ActivityThread mainThread, LoadedApk packageInfo, IBinder activityToken, UserHandle user, boolean restricted, Display display, Configuration overrideConfiguration, int createDisplayWithId) { ... mContentResolver = new ApplicationContentResolver(this, mainThread, user); ...
通过ContentResolver注册ContentObserver代码如下：
public final void registerContentObserver(Uri uri, boolean notifyForDescendents, ContentObserver observer, int userHandle) { try { <!--获取ContentService，并注册--> getContentService().registerContentObserver(uri, notifyForDescendents, observer.getContentObserver(), userHandle); } catch (RemoteException e) { } }
可以看到，注册的过程首先是获取ContentService服务代理，然后通过这个代理像ContentService注册观察者，典型的Binder服务通信模型，获取服务的实现如下，
/** @hide */ public static final String CONTENT_SERVICE_NAME = "content"; /** @hide */ public static IContentService getContentService() { if (sContentService != null) { return sContentService; } IBinder b = ServiceManager.getService(CONTENT_SERVICE_NAME); sContentService = IContentService.Stub.asInterface(b); return sContentService; }
其实就是通过系统服务的名称，向ServiceManager查询并获取服务代理，请求成功后，便可以通过代理发送请求，这里请求的任务是注册，这里有一点要注意，那就是在注册的时候，要同时打通ContentService向APP发送消息的链路，这个链路其实就是另一个Binder通信路线，具体做法就是将ContentObserver封装成一个Binder服务实体注册到ContentService中，注册成功后，ContentService就会握有ContentObserver的代理，将来需要通知APP端的时候，就可以通过该代理发送通知，双C/S模型在Android框架中非常常见。具体代码是，通过ContentObserver获取一个IContentObserver对象，APP端将该对象通过binder传递到ContentService服务，如此ContentService便能通过Binder向APP端发送通知
public IContentObserver getContentObserver() { synchronized (mLock) { if (mTransport == null) { mTransport = new Transport(this); } return mTransport; } }
mTransport本质是一个Binder服务实体，同时握有ContentObserver的强引用，将来通知到达的时候，便能通过ContentObserver分发通知
private static final class Transport extends IContentObserver.Stub { private ContentObserver mContentObserver; public Transport(ContentObserver contentObserver) { mContentObserver = contentObserver; } @Override public void onChange(boolean selfChange, Uri uri, int userId) { ContentObserver contentObserver = mContentObserver; if (contentObserver != null) { <!--通过 contentObserver发送回调通知--> contentObserver.dispatchChange(selfChange, uri, userId); } } public void releaseContentObserver() { mContentObserver = null; } }
Transport本身是一个Binder实体对象，被注册到ContentService中，ContentService会维护一个Transport代理的集合，通过代理，可以通知不同的进程，继续看register流程，registerContentObserver通过binder通信最终会调用都ContentService的registerContentObserver函数：
@Override public void registerContentObserver(Uri uri, boolean notifyForDescendants, IContentObserver observer, int userHandle) { <!--权限检查--> if (callingUserHandle != userHandle && mContext.checkUriPermission(uri, pid, uid, Intent.FLAG_GRANT_READ_URI_PERMISSION) != PackageManager.PERMISSION_GRANTED) { enforceCrossUserPermission(userHandle, "no permission to observe other users' provider view"); } ... <!--2 添加到监听队列--> synchronized (mRootNode) { mRootNode.addObserverLocked(uri, observer, notifyForDescendants, mRootNode, uid, pid, userHandle); } }
这里主要看下点2：监听对象的添加，ContentService对象内部维护了一个树，用于管理监听对象，主要是根据Uri的路径进行分组，既方便管理，同时又提高查找及插入效率，每个Uri路径对象对应一个节点，也就是一个ObserverNode对象，每个节点中维护一个监听List，而ContentService持有RootNode根对象，
private final ObserverNode mRootNode = new ObserverNode("");
每个ObserverNode维护了一个ObserverEntry队列，ObserverEntry与ContentObserver一一对应，一个Uri对应一个ObserverNode，一个ObserverNode下可以有多个ContentObserver，也就是会多个ObserverEntry，每个ObserverEntry还有一些其他辅助信息，比如要跟Uri形成键值对，ObserverEntry还将自己设置成了Binder讣告的接受者，一旦APP端进程结束，可以通过Binder讣告机制让ContentService端收到通知，并做一些清理工作，具体实现如下：
public static final class ObserverNode { private class ObserverEntry implements IBinder.DeathRecipient { public final IContentObserver observer; public final int uid; public final int pid; public final boolean notifyForDescendants; private final int userHandle; private final Object observersLock; public ObserverEntry(IContentObserver o, boolean n, Object observersLock, int _uid, int _pid, int _userHandle) { this.observersLock = observersLock; observer = o; uid = _uid; pid = _pid; userHandle = _userHandle; notifyForDescendants = n; try { observer.asBinder().linkToDeath(this, 0); } catch (RemoteException e) { binderDied(); } } <!--做一些清理工作，删除observer--> public void binderDied() { synchronized (observersLock) { removeObserverLocked(observer); } } 。。。 } public static final int INSERT_TYPE = 0; public static final int UPDATE_TYPE = 1; public static final int DELETE_TYPE = 2; private String mName; private ArrayList<ObserverNode> mChildren = new ArrayList<ObserverNode>(); <!--维护自己node的回调队列--> private ArrayList<ObserverEntry> mObservers = new ArrayList<ObserverEntry>(); . ..
继续看看下Observer的add流程，ObserverNode 的addObserverLocked函数被外部调用（被rootnode）的时候，一般传递的index是0，自己递归调用的时候，才不是0，其实添加Observer的过程是一个递归的过程，首先通过Uri路径，递归找到对应的ObserverNode，然后像ObserverNode的监听队列中添加Observer。
private void addObserverLocked(Uri uri, int index, IContentObserver observer, boolean notifyForDescendants, Object observersLock, int uid, int pid, int userHandle) { // If this is the leaf node add the observer <!--已经找到叶子节点，那么可以直接在node中插入ObserverEntry-> if (index == countUriSegments(uri)) { mObservers.add(new ObserverEntry(observer, notifyForDescendants, observersLock, uid, pid, userHandle)); return; } // Look to see if the proper child already exists <!--一层层往下剥离--> String segment = getUriSegment(uri, index); ... int N = mChildren.size(); <!--递归查找--> for (int i = 0; i < N; i++) { ObserverNode node = mChildren.get(i); if (node.mName.equals(segment)) { node.addObserverLocked(uri, index + 1, observer, notifyForDescendants, observersLock, uid, pid, userHandle); return; } } // No child found, create one <!--找不到，就新建，并插入--> ObserverNode node = new ObserverNode(segment); mChildren.add(node); node.addObserverLocked(uri, index + 1, observer, notifyForDescendants, observersLock, uid, pid, userHandle); }
比如：要查询content://A/B/C对应的ObserverNode，首先会找到Authority，找到A对应的ObserverNode，之后在A的children中查找Path=B的Node，然后在B的Children中查找Path=C的Node，找到该Node之后，往这个node的ObserverEntry列表中添加一个对象，到这里就注册就完成了。
通知流程
前文已经说过，ContentService可以看做是通知的中转站，进程A想要通知其他注册了某个Uri的进程，必须首先向ContentService分发中心发送消息，再由ContentService通知其他进程中的观察者，简化模型如下图：
简单跟踪下通知流程，入口函数如下
public static void notity(Context context) { ContentResolver contentResolver = context.getContentResolver(); contentResolver.notifyChange(Uri.parse("content://"+"test"),null); }
ContentResolver的notifyChange会进一步通过Binder，请求ContentService发送通知，
public void notifyChange(Uri uri, ContentObserver observer, boolean syncToNetwork, int userHandle) { try { getContentService().notifyChange( uri, observer == null ? null : observer.getContentObserver(), observer != null && observer.deliverSelfNotifications(), syncToNetwork, userHandle); } catch (RemoteException e) { } }
ContentService收到请求进一步处理，无非就是搜索之前的树，找到对应的节点，将节点上注册回调List通知一遍，具体逻辑如下：
@Override public void notifyChange(Uri uri, IContentObserver observer, boolean observerWantsSelfNotifications, boolean syncToNetwork, int userHandle) { <!--权限检测--> // This makes it so that future permission checks will be in the context of this // process rather than the caller's process. We will restore this before returning. <!--找回调，处理回调--> long identityToken = clearCallingIdentity(); try { ArrayList<ObserverCall> calls = new ArrayList<ObserverCall>(); synchronized (mRootNode) { <!--1 从根节点开始查找binder回调代理--> mRootNode.collectObserversLocked(uri, 0, observer, observerWantsSelfNotifications, userHandle, calls); } final int numCalls = calls.size(); for (int i=0; i<numCalls; i++) { ObserverCall oc = calls.get(i); try { <!--2 通知--> oc.mObserver.onChange(oc.mSelfChange, uri, userHandle); } ...
从上面代码可以看出，其实就是两步，先搜集所有的Binder回调，之后通过回调通知APP端，搜集过程也是个递归的过程，也会存在父子粘连的一些回调逻辑（子Uri是否有必要通知路径中的父Uri回调），理解很简单，不再详述。这步之后，消息就通过Binder被传送给App端，在APP端，Binder实体的onTransact被回调，并处理相应的事务：
private static final class Transport extends IContentObserver.Stub { private ContentObserver mContentObserver; public Transport(ContentObserver contentObserver) { mContentObserver = contentObserver; } @Override public void onChange(boolean selfChange, Uri uri, int userId) { ContentObserver contentObserver = mContentObserver; if (contentObserver != null) { <!--通过 contentObserver发送回调通知--> contentObserver.dispatchChange(selfChange, uri, userId); } } public void releaseContentObserver() { mContentObserver = null; } }
这里有一点需要注意，那就是IContentObserver中onChange是一个oneway请求，可以说，总是异步的，ContentService将消息塞入到APP端Binder线程的执行队列后就返回，不会等待处理结果才返回。
interface IContentObserver { /** * This method is called when an update occurs to the cursor that is being * observed. selfUpdate is true if the update was caused by a call to * commit on the cursor that is being observed. */ contentService 用的是oneway oneway void onChange(boolean selfUpdate, in Uri uri, int userId); }
之后其实就是调用ContentObserver的dispatchChange，dispatchChange可能是在Binder线程中同步执行，也可能是发送到一个与Handler绑定的线程中执行，如下，
private void dispatchChange(boolean selfChange, Uri uri, int userId) { if (mHandler == null) { onChange(selfChange, uri, userId); } else { mHandler.post(new NotificationRunnable(selfChange, uri, userId)); } }
但是整体上来看，由于Binder oneway的存在，ContentService的通知是个异步的过程。
一个奇葩问题的注意事项 Binder循环调用
假设有这样一个场景：
- A进程notify，
- A进程再收到通知
- A进程请求获取ContentProvider的数据，并且ContentProvider位于A进程
这个时候，如果，采用的是同步，也就是ContentObserver没有设置Handler，那就会遇到一个问题，系统会提示你没有权限访问ContentProvider，
java.lang.SecurityException: Permission Denial: reading XXX uri content://MyContentProvider from pid=0, uid=1000 requires the provider be exported, or grantUriPermission()
为什么，明明是当前App中声明的ContentProvider，为什么不能访问，并且pid=0, uid=1000 是怎么来的，其实这个时候是因为Binder机制中的一个小"BUG"，需要用户自己避免,ContentProvider在使用的时候会校验权限，
/** {@hide} */ protected int enforceReadPermissionInner(Uri uri, String callingPkg, IBinder callerToken) throws SecurityException { final Context context = getContext(); // Binder.getCallingPid获取的可能不是我们想要的进程PID final int pid = Binder.getCallingPid(); final int uid = Binder.getCallingUid(); String missingPerm = null; int strongestMode = MODE_ALLOWED; ... final String failReason = mExported ? " requires " + missingPerm + ", or grantUriPermission()" : " requires the provider be exported, or grantUriPermission()"; throw new SecurityException("Permission Denial: reading " + ContentProvider.this.getClass().getName() + " uri " + uri + " from pid=" + pid + ", uid=" + uid + failReason); }
Binder.getCallingPid()获取的可能并不是我们想要的进程PID，因为之前同步访问的时候 Binder.getCallingPid()被赋值为系统进程PID(请求进程)，在同步访问的时候，由于ContentProvider本身在A进程中，会直接调用ContentProvider的相应服务函数，但是Binder.getCallingPid()返回值并没有被更新，也就是说 Binder.getCallingPid()获取的进程是上一个Binder请求的进程，自然也就没有权限访问当前ContentProvider的权限。也就是说，在一个Binder调用中，如果再次触发了binder调用，Binder.getCallingPid()获取的是之前的进程PID。为什么一开始是正确的呢？因为一开始通过clearCaller()重置过：
IPCThreadState::IPCThreadState() : mProcess(ProcessState::self()), mStrictModePolicy(0), mLastTransactionBinderFlags(0) { pthread_setspecific(gTLS, this); clearCaller(); mIn.setDataCapacity(256); mOut.setDataCapacity(256); }
当然，Android提供了解决方案，那就是
<!--将Binder.getCallingPid()的值设定为当前进程--> final long identity = Binder.clearCallingIdentity(); ... <!--恢复之前保存的值--> Binder.restoreCallingIdentity(identity);
以上两个函数配合使用，就可以避免之前的问题。这个问题Google不能从Binder上在底层解决吗？总觉是Binder通信的BUG。
总结
- ContentService是一个系统级别的消息中心，提供系统级别的观察者模型
- ContentService的通信模型 其实是典型的Android 双C/S模型
- ContentService内部是通过树+list的方式管理ContentObserver回调
- ContentService在分发消息的时候，整体上是异步的，在APP端可以在Binder线程中同步处理，也可以发送到Handler绑定的线程中异步处理，具体看APP端配置
