原文出处——>[Android应用程序与SurfaceFlinger服务之间的共享UI元数据(SharedClient)的创建过程分析](http://blog.csdn.net/luoshengyang/article/details/7867340)
在前面一篇文章中,我们分析了Android应用程序与SurfaceFlinger服务的连接过程。Android应用程序成功连接上SurfaceFlinger服务之后,还需要一块匿名共享内存来和SurfaceFlinger服务共享它的UI元数据,以便使得SurfaceFlinger服务可以正确地为它创建以及渲染Surface。在本文中,我们将详细地分析这块用来保存UI元数据的匿名共享内存的创建过程。
在Android应用程序与SurfaceFlinger服务的关系概述和学习计划一文中提到,用来保存Android应用程序的UI元数据的匿名共享内存最终是被结构化为一个SharedClient对象来访问的。每一个与UI有关的Android应用程序进程有且仅有一个SharedClient对象,而且这些SharedClient对象是由Android应用程序请求SurfaceFlinger服务创建的:Android应用程序首先获得SurfaceFlinger服务的一个Binder代理接口,然后再通过这个代理接口得到另外一个类型为UserClient的Binder代理接口,最后就可以通过后一个Binder代理接口来获得一个SharedClient对象。
由于每一个与UI有关的Android应用程序进程有且仅有一个SharedClient对象,因此,Android系统就通过一个单例模式的类来专负责创建和管理这个SharedClient对象。这个类的名称为SurfaceClient,定义在frameworks/base/libs/surfaceflinger_client/Surface.cpp文件中,如下所示:
~~~
class SurfaceClient : public Singleton<SurfaceClient>
{
// all these attributes are constants
sp<ISurfaceComposer> mComposerService;
sp<ISurfaceComposerClient> mClient;
status_t mStatus;
SharedClient* mControl;
sp<IMemoryHeap> mControlMemory;
SurfaceClient()
: Singleton<SurfaceClient>(), mStatus(NO_INIT)
{
sp<ISurfaceComposer> sf(ComposerService::getComposerService());
mComposerService = sf;
mClient = sf->createClientConnection();
if (mClient != NULL) {
mControlMemory = mClient->getControlBlock();
if (mControlMemory != NULL) {
mControl = static_cast<SharedClient *>(
mControlMemory->getBase());
if (mControl) {
mStatus = NO_ERROR;
}
}
}
}
friend class Singleton<SurfaceClient>;
public:
status_t initCheck() const {
return mStatus;
}
SharedClient* getSharedClient() const {
return mControl;
}
ssize_t getTokenForSurface(const sp<ISurface>& sur) const {
// TODO: we could cache a few tokens here to avoid an IPC
return mClient->getTokenForSurface(sur);
}
void signalServer() const {
mComposerService->signal();
}
};
~~~
当SurfaceClient类的静态成员函数getInstance第一次被调用的时候,系统就会在对应的应用程序进程中创建一个SurfaceClient对象,即会调用SurfaceClient类的构造函数。SurfaceClient类的构造函数首先会调用ComposerService类的静态成员函数getComposerService来获得一个SurfaceFlinger服务的代理接口,并且保存在SurfaceClient类的成员变量mComposerService中,以便以后可以使用。ComposerService类的静态成员函数getComposerService在前面Android应用程序与SurfaceFlinger服务的连接过程分析一文中已经分析过了,这里不再详述。有了SurfaceFlinger服务的代理接口sf之后,SurfaceClient类的构造函数接着就可以调用它的成员函数createClientConnection来获得一个类型为UserClient的Binder代理接口,这个Binder代理接口实现了ISurfaceComposerClient接口,因此,我们可以将它保存在SurfaceClient类的成员变量mClient中。最后,SurfaceClient类的构造函数就调用前面获得的类型为ISurfaceComposerClient的Binder代理接口mClient的成员函数getControlBlock来获得一块用来描述应用程序UI元数据的匿名共享内存mControlMemory ,并且将这些匿名共享内存强制转化为一个SharedClient对象mControl,以便后面可以方便地访问UI元数据。
以上就是Android应用程序与SurfaceFlinger服务之间的共享UI元数据(SharedClient)的创建过程的总体描述,接下来我们再详细分析每一步的实现。现在,我们继续分析一下SurfaceClient类的其余成员函数的实现:
1. 成员函数initCheck用来检查一个Android应用程序进程是否已经成功地请求SurfaceFlinger服务创建了一块用来描述UI元数据的SharedClient对象了。
2. 成员函数getSharedClient用来返回用来描述UI元数据的SharedClient对象mControl。
3. 成员函数getTokenForSurface用来返回由参数sur所描述的一个Surface的Token值。这个Token值由SurfaceFlinger服务来创建和管理,并且可以通过前面所获得的类型为UserClient的Binder代理接口mClient的成员函数getTokenSurface来获得。
4. 成员函数signalServer用来通知SurfaceFlinger服务更新Android应用程序UI,这是通过调用SurfaceFlinger服务的代理接口mComposerService的成员函数signal来实现的,实际上就是向SurfaceFlinger服务发送一个信号,以便可以将它唤醒起来更新UI。
介绍完成SurfaceClient类的实现之后,我们还需要了解一下两个类的实现,即UserClient类和SharedClient类的实现,以便可以帮助我们了解用来保存Android应用程序的UI元数据的匿名共享内存的创建过程,以及帮助后面两篇文章对Surface的创建和渲染过程的分析。
接下来,我们就首先分析UserClient类的实现,接着再分析SharedClient类的实现。
在Android应用程序与SurfaceFlinger服务的连接过程分析一文的图2中,我们介绍了用来连接Android应用程序和SurfaceFlinger服务的Client类,而UserClient类和Client类是类似的,它们都实现了相同的接口,只不过是侧重点有所不同。Android应用程序与SurfaceFlinger服务的连接过程分析一文的图2中的Client类替换成UserClient类,就可以得到UserClient类的实现结构图,如图1所示:
![](https://box.kancloud.cn/c1f1f5df9582fee3cfb83362fec9a913_687x492.jpg)
图1 UserClient类的实现结构图
UserClient类与Client类最重要的区别是,前者实现了ISurfaceComposerClient接口的成员函数getControlBlock,而后者实现了ISurfaceComposerClient接口的成员函数createSurface。后面我们就会分析UserClient类是如何实现ISurfaceComposerClient接口的成员函数getControlBlock的。
UserClient类的实现暂时就介绍到这里,接下来我们来看SharedClient类的实现。为了方便描述,我们把Android应用程序与SurfaceFlinger服务的关系概述和学习计划一文的图4和图5贴出来,如以下图2和图3所示:
![](https://box.kancloud.cn/8bf549fcb8720f263b9595724490c92f_540x347.jpg)
图2 用来描述Android应用程序的UI元数据的SharedClient
![](https://box.kancloud.cn/3bb7bdaf74bd82c0f9c2b8cb05f977d5_659x412.jpg)
图3 SharedBufferStack的结构示意图
每一个SharedClient对象包含了至多31个SharedBufferStack,而每一个SharedBufferStack都对应一个Android应用程序进程中的一个Surface。
SharedClient类定义在文件frameworks/base/include/private/surfaceflinger/SharedBufferStack.h 文件中,如下所示:
~~~
class SharedClient
{
public:
SharedClient();
~SharedClient();
......
private:
......
SharedBufferStack surfaces[ SharedBufferStack::NUM_LAYERS_MAX ];
};
~~~
它有一个大小为SharedBufferStack::NUM_LAYERS_MAX的SharedBufferStack数组。SharedBufferStack::NUM_LAYERS_MAX的值等于31,定义在SharedBufferStack类中。
SharedBufferStack类同样是定义在文件frameworks/base/include/private/surfaceflinger/SharedBufferStack.h 文件中,如下所示:
~~~
class SharedBufferStack
{
......
public:
// When changing these values, the COMPILE_TIME_ASSERT at the end of this
// file need to be updated.
static const unsigned int NUM_LAYERS_MAX = 31;
static const unsigned int NUM_BUFFER_MAX = 16;
static const unsigned int NUM_BUFFER_MIN = 2;
static const unsigned int NUM_DISPLAY_MAX = 4;
......
struct SmallRect {
uint16_t l, t, r, b;
};
struct FlatRegion {
static const unsigned int NUM_RECT_MAX = 5;
uint32_t count;
SmallRect rects[NUM_RECT_MAX];
};
struct BufferData {
FlatRegion dirtyRegion;
SmallRect crop;
uint8_t transform;
uint8_t reserved[3];
};
SharedBufferStack();
......
status_t setDirtyRegion(int buffer, const Region& reg);
status_t setCrop(int buffer, const Rect& reg);
status_t setTransform(int buffer, uint8_t transform);
Region getDirtyRegion(int buffer) const;
Rect getCrop(int buffer) const;
uint32_t getTransform(int buffer) const;
// these attributes are part of the conditions/updates
volatile int32_t head; // server's current front buffer
volatile int32_t available; // number of dequeue-able buffers
volatile int32_t queued; // number of buffers waiting for post
......
// not part of the conditions
......
volatile int8_t index[NUM_BUFFER_MAX];
......
int8_t headBuf; // last retired buffer
......
BufferData buffers[NUM_BUFFER_MAX];
};
~~~
下面我们简要地对SharedBufferStack类进行分析。
首先,SharedBufferStack类在内部定义了四个常量:
* NUM_LAYERS_MAX -- 表示一个Android应用程序最多可以有NUM_LAYERS_MAX个Layer,可以将一个Layer理解为一个Surface。
* NUM_BUFFER_MAX -- 表示一个SharedBufferStack至多可以有NUM_BUFFER_MAX个UI元数据缓冲区。
* NUM_BUFFER_MIN -- 表示一个SharedBufferStack至少要有UM_BUFFER_MIN个UI元数据缓冲区。
* NUM_DISPLAY_MAX -- 表示Android系统至多可以支持NUM_DISPLAY_MAX个显示屏。
从这些常量就可以看出:
1. Android系统至多支持4个显示屏。
2. 一个Android应用程序至多可以同时创建31个Surface。
3. 一个Surface可以有2~16个UI元数据缓冲区,即可以使用2~16缓冲区技术来渲染Surface。
其次,SharedBufferStack类在内部定义了三个结构体:
* SmallRect -- 用来描述一个矩形区域,其中,成员变量l、t,、r和b分别表示左上和右下两个角的位置。
* FlatRegion -- 用来描述一个SmallRect数组rects ,数组的大小为NUM_RECT_MAX,但是实际个数为count。
* BufferData -- 用来描述一个UI元数据缓冲区,它有四个成员变量dirtyRegion、crop、transform和reserved,其中,dirtyRegion用来描述一个Surface需要更新的区域,即裁剪区域,crop用来描述一个Surface的纹理坐标,transform用来描述一个Surface的旋转方向,例如,旋转90度或者上下翻转等等,而reserved是保留给以后使用的。通过这个UI元数据缓冲区,SurfaceFlinger服务就可以正确地把一个Surface的图形缓冲区所描述的图形渲染到屏幕来。
SharedBufferStack类有一个BufferData数组buffers,它的大小为NUM_BUFFER_MAX,即16,就是用来一组UI元数据缓冲区的,这些UI元数据缓冲区的内容可以分别通过setDirtyRegion、setCrop、setTransform、getDirtyRegion、getCrop和getTransform这六个成员函数来访问。这六个成员函数的第一个参数均为一个int值,用来描述要访问的是哪一个BufferData的数据。
SharedBufferStack类还有另外一个类型为int8_t的数组index,它的大小也为NUM_BUFFER_MAX。这个index数组才是一个真正的Stack,它按照一定的规则来访问。index数组的每一个元素的值均是一个索引值,用来映射到数组buffers中去的。例如,假设index[0]的值等于2,那么它就对应数组buffers中的第2个元素,即buffers[2]。
SharedBufferStack类的其余重要成员变量的含义如下所示:
* head -- 用来描述一个SharedBufferStack的头部,它是一个索引值,是映射到数组index中去的。
* available -- 用来描述一个SharedBufferStack中的空闲UI元数据缓冲区的个数。
* queued -- 用来描述一个SharedBufferStack中的已经补使用了的UI元数据缓冲区的个数,即那些在排队等待SurfaceFlinger服务使用的UI元数据缓冲区。
* headBuf -- 用来描述一个SharedBufferStack的头部所对应的UI元数据缓冲区的编号,这个编号是映射到数组buffers中去。
关于SharedBufferStack类的实现,我们就暂时介绍到这里,在下一篇文章分析Android应用程序的Surface创建过程时,我们再通过SharedBufferServer类和SharedBufferClient类的实现来进一步理解SharedBufferStack类的实现。
现在,我们就开始详细分析Android应用程序与SurfaceFlinger服务之间的共享UI元数据的创建过程,如图4所示:
![](https://box.kancloud.cn/02e412ab67878f42292bd129a6493338_519x530.jpg)
图 4 Android应用程序的共享UI元数据的创建过程
接下来我们就详细分析每一个步骤。
Step 1. SurfaceFlinger::createClientConnection
~~~
sp<ISurfaceComposerClient> SurfaceFlinger::createClientConnection()
{
sp<ISurfaceComposerClient> bclient;
sp<UserClient> client(new UserClient(this));
status_t err = client->initCheck();
if (err == NO_ERROR) {
bclient = client;
}
return bclient;
}
~~~
SurfaceFlinger类的成员函数createClientConnection实现在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中,它的实现很简单,只是创建了一个类型为UserClient的Binder对象client,并且获得它的一个ISurfaceComposerClient接口,最后将这个ISurfaceComposerClient接口,即一个UserClient代理对象,返回给Android应用程序进程。
接下来,我们再继续分析UserClient对象的创建过程,,即UserClient类的构造函数的实现。
Step 2. new UserClient
~~~
UserClient::UserClient(const sp<SurfaceFlinger>& flinger)
: ctrlblk(0), mBitmap(0), mFlinger(flinger)
{
const int pgsize = getpagesize();
const int cblksize = ((sizeof(SharedClient)+(pgsize-1))&~(pgsize-1));
mCblkHeap = new MemoryHeapBase(cblksize, 0,
"SurfaceFlinger Client control-block");
ctrlblk = static_cast<SharedClient *>(mCblkHeap->getBase());
if (ctrlblk) { // construct the shared structure in-place.
new(ctrlblk) SharedClient;
}
}
~~~
UserClient类的成员变量mFlinger是一个类型为SurfaceFlinger的强指针,它指向了SurfaceFlinger服务, UserClient类的另外一个成员变量mBitmap是一个int32_t值,它是用来为Android应用程序的Surface分配Token值的,即如果它的第n位等于1,那么就表示值等于n的Token已经被分配出去使用了。
UserClient类的构造函数首先得到一个SharedClient对象的大小,接着再将这个大小对齐到页面边界,于是就得到了接下来要创建的匿名共享块的大小cblksize。这块匿名共享内存是一个MemoryHeapBase对象描述的,并且保存在UserClient类的成员变量mCblkHeap。MemoryHeapBase类是用来创建匿名共享内存的一个C++接口,它的实现原理可以参考Android系统匿名共享内存(Anonymous Shared Memory)C++调用接口分析一文。
UserClient类的构造函数得到了一块匿名共享内存之后,紧接着就在这块匿名共享内存上创建了一个SharedClient对象,并且保存在UserClient类的成员变量ctrlblk中,以便后面可以通过它来访问Android应用程序的UI元数据。
回到SurfaceFlinger类的成员函数createClientConnection中,它将一个指向了一个UserClient对象的ISurfaceComposerClient接口返回到Android应用程序进程之后,Android应用程序进程就可以将它封装成一个类型为BpSurfaceComposerClient的Binder代理对象。
Step 3. return BpSurfaceComposerClient
将一个Binder代理对象封装成一个BpSurfaceComposerClient的过程可以参考前面Android应用程序与SurfaceFlinger服务的连接过程分析一文中的Step 4。
Step 4. UserClient::getControlBlock
~~~
sp<IMemoryHeap> UserClient::getControlBlock() const {
return mCblkHeap;
}
~~~
从前面的Step 2可以知道,UserClient类的成员变量mCblkHeap指向了一块匿名共享内存,UserClient类将这块匿名共享内存返回给Android应用程序之后,Android应用程序就会将它结构化成一个SharedClient对象来访问,并且保存在SurfaceClient类的成员变量mControl中,这个结构化过程就可以参考前面所描述的SurfaceClient类的构造函数了。
至此,用来描述Android应用程序的UI元数据的一个SharedClient对象的创建过程就分析完了。以后当Android应用程序请求SurfaceFlinger服务创建一个Surface的时候,SurfaceFlinger服务就会从这个SharedClient对象中取出一个SharedBufferStack出来,以便可以用作这个Surface的UI元数据缓冲区。在接下来的一篇文章中,我们将详细描述Android应用程序请求SurfaceFlinger服务创建Surface的过程,敬请期待!
- 前言
- Android组件设计思想
- Android源代码开发和调试环境搭建
- Android源代码下载和编译
- Android源代码情景分析法
- Android源代码调试分析法
- 手把手教你为手机编译ROM
- 在Ubuntu上下载、编译和安装Android最新源代码
- 在Ubuntu上下载、编译和安装Android最新内核源代码(Linux Kernel)
- 如何单独编译Android源代码中的模块
- 在Ubuntu上为Android系统编写Linux内核驱动程序
- 在Ubuntu上为Android系统内置C可执行程序测试Linux内核驱动程序
- 在Ubuntu上为Android增加硬件抽象层(HAL)模块访问Linux内核驱动程序
- 在Ubuntu为Android硬件抽象层(HAL)模块编写JNI方法提供Java访问硬件服务接口
- 在Ubuntu上为Android系统的Application Frameworks层增加硬件访问服务
- 在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务
- Android源代码仓库及其管理工具Repo分析
- Android编译系统简要介绍和学习计划
- Android编译系统环境初始化过程分析
- Android源代码编译命令m/mm/mmm/make分析
- Android系统镜像文件的打包过程分析
- 从CM刷机过程和原理分析Android系统结构
- Android系统架构概述
- Android系统整体架构
- android专用驱动
- Android硬件抽象层HAL
- Android应用程序组件
- Android应用程序框架
- Android用户界面架构
- Android虚拟机之Dalvik虚拟机
- Android硬件抽象层
- Android硬件抽象层(HAL)概要介绍和学习计划
- Android专用驱动
- Android Logger驱动系统
- Android日志系统驱动程序Logger源代码分析
- Android应用程序框架层和系统运行库层日志系统源代码分析
- Android日志系统Logcat源代码简要分析
- Android Binder驱动系统
- Android进程间通信(IPC)机制Binder简要介绍和学习计划
- 浅谈Service Manager成为Android进程间通信(IPC)机制Binder守护进程之路
- 浅谈Android系统进程间通信(IPC)机制Binder中的Server和Client获得Service Manager接口之路
- Android系统进程间通信(IPC)机制Binder中的Server启动过程源代码分析
- Android系统进程间通信(IPC)机制Binder中的Client获得Server远程接口过程源代码分析
- Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析
- Android Ashmem驱动系统
- Android系统匿名共享内存Ashmem(Anonymous Shared Memory)简要介绍和学习计划
- Android系统匿名共享内存Ashmem(Anonymous Shared Memory)驱动程序源代码分析
- Android系统匿名共享内存Ashmem(Anonymous Shared Memory)在进程间共享的原理分析
- Android系统匿名共享内存(Anonymous Shared Memory)C++调用接口分析
- Android应用程序进程管理
- Android应用程序进程启动过程的源代码分析
- Android系统进程Zygote启动过程的源代码分析
- Android系统默认Home应用程序(Launcher)的启动过程源代码分析
- Android应用程序消息机制
- Android应用程序消息处理机制(Looper、Handler)分析
- Android应用程序线程消息循环模型分析
- Android应用程序输入事件分发和处理机制
- Android应用程序键盘(Keyboard)消息处理机制分析
- Android应用程序UI架构
- Android系统的开机画面显示过程分析
- Android帧缓冲区(Frame Buffer)硬件抽象层(HAL)模块Gralloc的实现原理分析
- SurfaceFlinger
- Android系统Surface机制的SurfaceFlinger服务
- SurfaceFlinger服务简要介绍和学习计划
- 启动过程分析
- 对帧缓冲区(Frame Buffer)的管理分析
- 线程模型分析
- 渲染应用程序UI的过程分析
- Android应用程序与SurfaceFlinger服务的关系
- 概述和学习计划
- 连接过程分析
- 共享UI元数据(SharedClient)的创建过程分析
- 创建Surface的过程分析
- 渲染Surface的过程分析
- Android应用程序窗口(Activity)
- 实现框架简要介绍和学习计划
- 运行上下文环境(Context)的创建过程分析
- 窗口对象(Window)的创建过程分析
- 视图对象(View)的创建过程分析
- 与WindowManagerService服务的连接过程分析
- 绘图表面(Surface)的创建过程分析
- 测量(Measure)、布局(Layout)和绘制(Draw)过程分析
- WindowManagerService
- WindowManagerService的简要介绍和学习计划
- 计算Activity窗口大小的过程分析
- 对窗口的组织方式分析
- 对输入法窗口(Input Method Window)的管理分析
- 对壁纸窗口(Wallpaper Window)的管理分析
- 计算窗口Z轴位置的过程分析
- 显示Activity组件的启动窗口(Starting Window)的过程分析
- 切换Activity窗口(App Transition)的过程分析
- 显示窗口动画的原理分析
- Android控件TextView的实现原理分析
- Android视图SurfaceView的实现原理分析
- Android应用程序UI硬件加速渲染
- 简要介绍和学习计划
- 环境初始化过程分析
- 预加载资源地图集服务(Asset Atlas Service)分析
- Display List构建过程分析
- Display List渲染过程分析
- 动画执行过程分析
- Android应用程序资源管理框架
- Android资源管理框架(Asset Manager)
- Asset Manager 简要介绍和学习计划
- 编译和打包过程分析
- Asset Manager的创建过程分析
- 查找过程分析
- Dalvik虚拟机和ART虚拟机
- Dalvik虚拟机
- Dalvik虚拟机简要介绍和学习计划
- Dalvik虚拟机的启动过程分析
- Dalvik虚拟机的运行过程分析
- Dalvik虚拟机JNI方法的注册过程分析
- Dalvik虚拟机进程和线程的创建过程分析
- Dalvik虚拟机垃圾收集机制简要介绍和学习计划
- Dalvik虚拟机Java堆创建过程分析
- Dalvik虚拟机为新创建对象分配内存的过程分析
- Dalvik虚拟机垃圾收集(GC)过程分析
- ART虚拟机
- Android ART运行时无缝替换Dalvik虚拟机的过程分析
- Android运行时ART简要介绍和学习计划
- Android运行时ART加载OAT文件的过程分析
- Android运行时ART加载类和方法的过程分析
- Android运行时ART执行类方法的过程分析
- ART运行时垃圾收集机制简要介绍和学习计划
- ART运行时Java堆创建过程分析
- ART运行时为新创建对象分配内存的过程分析
- ART运行时垃圾收集(GC)过程分析
- ART运行时Compacting GC简要介绍和学习计划
- ART运行时Compacting GC堆创建过程分析
- ART运行时Compacting GC为新创建对象分配内存的过程分析
- ART运行时Semi-Space(SS)和Generational Semi-Space(GSS)GC执行过程分析
- ART运行时Mark-Compact( MC)GC执行过程分析
- ART运行时Foreground GC和Background GC切换过程分析
- Android安全机制
- SEAndroid安全机制简要介绍和学习计划
- SEAndroid安全机制框架分析
- SEAndroid安全机制中的文件安全上下文关联分析
- SEAndroid安全机制中的进程安全上下文关联分析
- SEAndroid安全机制对Android属性访问的保护分析
- SEAndroid安全机制对Binder IPC的保护分析
- 从NDK在非Root手机上的调试原理探讨Android的安全机制
- APK防反编译
- Android视频硬解稳定性问题探讨和处理
- Android系统的智能指针(轻量级指针、强指针和弱指针)的实现原理分析
- Android应用程序安装过程源代码分析
- Android应用程序启动过程源代码分析
- 四大组件源代码分析
- Activity
- Android应用程序的Activity启动过程简要介绍和学习计划
- Android应用程序内部启动Activity过程(startActivity)的源代码分析
- 解开Android应用程序组件Activity的"singleTask"之谜
- Android应用程序在新的进程中启动新的Activity的方法和过程分析
- Service
- Android应用程序绑定服务(bindService)的过程源代码分析
- ContentProvider
- Android应用程序组件Content Provider简要介绍和学习计划
- Android应用程序组件Content Provider应用实例
- Android应用程序组件Content Provider的启动过程源代码分析
- Android应用程序组件Content Provider在应用程序之间共享数据的原理分析
- Android应用程序组件Content Provider的共享数据更新通知机制分析
- BroadcastReceiver
- Android系统中的广播(Broadcast)机制简要介绍和学习计划
- Android应用程序注册广播接收器(registerReceiver)的过程分析
- Android应用程序发送广播(sendBroadcast)的过程分析