Android内容服务ContentService原理浅析

作者:看书的小蜗牛 https://www.jianshu.com/p/d6af600e4c20 本文由 看书的小蜗牛 原创,已获授权原创首发

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.getCallingPid()获取的进程是上一个notify时候的系统进程,那么自然也就没有权限。如果将ContentProvider放到A进程之外的进程,就不会有问题,当然,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端配置

原文发布于微信公众号 - 刘望舒(liuwangshuAndroid)

原文发表时间:2018-08-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏老码农专栏

原 荐 用 ActFramework 写一个

64390
来自专栏battcn

一起来学SpringBoot | 第二十五篇:打造属于你的聊天室(WebSocket)

WebSocket 是 HTML5 新增的一种在单个 TCP 连接上进行全双工通讯的协议,与 HTTP 协议没有太大关系....

25120
来自专栏CodingBlock

Android查缺补漏(IPC篇)-- 进程间通讯基础知识热身

本文作者:CodingBlock 文章链接:http://www.cnblogs.com/codingblock/p/8479282.html

11540
来自专栏Ryan Miao

gradle中使用嵌入式(embedded) tomcat, debug 启动

在gradle项目中使用embedded tomcat。 最开始部署项目需要手动将web项目打成war包,然后手动上传到tomcat的webapp下,然后启动t...

56090
来自专栏向治洪

Android NDk环境配置

概论 NDK全称是Native Development Kit,NDK提供了一系列的工具,帮助开发者快速开发C(或C++)的动态库,并能自动将so和java应...

218100
来自专栏北京马哥教育

Python大法之告别脚本小子---信息资产收集类脚本编写

在采集到URL之后,要做的就是对目标进行信息资产收集了,收集的越好,你挖到洞也就越多了............当然这一切的前提,就是要有耐心了!!!由于要写工具...

22400
来自专栏安富莱嵌入式技术分享

【RL-TCPnet网络教程】第9章 RL-TCPnet网络协议栈移植(uCOS-III)

本章教程为大家讲解RL-TCPnet网络协议栈的uCOS-III操作系统移植方式,学习了第6章讲解的底层驱动接口函数之后,移植就比较容易了,主要是添加库文件、配...

12130
来自专栏Kubernetes

containerd源码分析

本文是对containerd v0.2.4的源码分析。 ##Containerd源码流程图 ? 源码接口调用详情 从ctr调用containerd-api #...

82770
来自专栏沃趣科技

ASM 翻译系列第四十弹:理解ASM中 REQUIRED_MIRROR_FREE_MB和USABLE_FILE_MB的含义

原作者:Harald van Breederode 译者: 魏兴华 审核: 魏兴华 DBGeeK社区联合出品 原文链接:https://prutse...

427120
来自专栏CodingBlock

Android查缺补漏(IPC篇)-- 进程间通讯基础知识热身

本文作者:CodingBlock 文章链接:http://www.cnblogs.com/codingblock/p/8479282.html 在Android...

30360

扫码关注云+社区

领取腾讯云代金券