- 浏览: 22522 次
- 性别:
- 来自: 北京
最新评论
page1
在Android系统中, 显示系统在底层是通过SurfaceFlinger服务来完成的, 因此从今天开始, 我们从SurfaceFlinger服务作为入口来分析一下Android显示系统.
SurfaceFlinger服务是在System进程中, 而System进程是由Zygote进程启动的, 并且是以Java层的SystemServer类的静态成员函数main为入口函数的。
因此,接下来我们就从SystemServer类(定义在SystemServer.java文件中)的静态成员函数main开始,分析SurfaceFlinger服务的启动过程:
1 public static void main(String[] args) {
2 if (System.currentTimeMillis() < EARLIEST_SUPPORTED_TIME) {
3 // If a device's clock is before 1970 (before 0), a lot of
4 // APIs crash dealing with negative numbers, notably
5 // java.io.File#setLastModified, so instead we fake it and
6 // hope that time from cell towers or NTP fixes it
7 // shortly.
8 Slog.w(TAG, "System clock is before 1970; setting to 1970.");
9 SystemClock.setCurrentTimeMillis(EARLIEST_SUPPORTED_TIME);
10 }
11 if (SamplingProfilerIntegration.isEnabled()) {
12 SamplingProfilerIntegration.start();
13 timer = new Timer();
14 timer.schedule(new TimerTask() {
15 @Override
16 public void run() {
17 SamplingProfilerIntegration.writeSnapshot("system_server", null);
18 }
19 }, SNAPSHOT_INTERVAL, SNAPSHOT_INTERVAL);
20 }
// Mmmmmm... more memory!
21 dalvik.system.VMRuntime.getRuntime().clearGrowthLimit();
// The system server has to run all of the time, so it needs to be
// as efficient as possible with its memory usage.
22 VMRuntime.getRuntime().setTargetHeapUtilization(0.8f);
23 System.loadLibrary("android_servers");
24 init1(args);
25 }
第24行(SystemServer.main)会调用init1函数来进行初始化操作, init1函数是个native函数来初始化C++层的服务, 会导致com_android_server_SystemServer.cpp的android_server_SystemServer_init1函数的调用, 关于com_android_server_SystemServer.cpp的android_server_SystemServer_init1函数的详细分析可以参考page2文件.
page2
1static void android_server_SystemServer_init1(JNIEnv* env, jobject clazz)
2{
3 system_init();
4}
第3行(com_android_server_SystemServer->android_server_SystemServer_init1)会调用system_init函数, system_init函数是在system_init.cpp文件中定义的, system_init函数的定义如下:
1extern "C" status_t system_init()
2{
3 ALOGI("Entered system_init()");
4 sp<ProcessState> proc(ProcessState::self());
5 sp<IServiceManager> sm = defaultServiceManager();
6 ALOGI("ServiceManager: %p\n", sm.get());
7 sp<GrimReaper> grim = new GrimReaper();
8 sm->asBinder()->linkToDeath(grim, grim.get(), 0);
9 char propBuf[PROPERTY_VALUE_MAX];
10 property_get("system_init.startsurfaceflinger", propBuf, "1");
11 if (strcmp(propBuf, "1") == 0) {
12 // Start the SurfaceFlinger
13 SurfaceFlinger::instantiate();
14 }
15 property_get("system_init.startsensorservice", propBuf, "1");
16 if (strcmp(propBuf, "1") == 0) {
17 // Start the sensor service
18 SensorService::instantiate();
19 }
// And now start the Android runtime. We have to do this bit
// of nastiness because the Android runtime initialization requires
// some of the core system services to already be started.
// All other servers should just start the Android runtime at
// the beginning of their processes's main(), before calling
// the init function.
20 ALOGI("System server: starting Android runtime.\n");
21 AndroidRuntime* runtime = AndroidRuntime::getRuntime();
22 ALOGI("System server: starting Android services.\n");
23 JNIEnv* env = runtime->getJNIEnv();
24 if (env == NULL) {
25 return UNKNOWN_ERROR;
26 }
27 jclass clazz = env->FindClass("com/android/server/SystemServer");
28 if (clazz == NULL) {
29 return UNKNOWN_ERROR;
30 }
31 jmethodID methodId = env->GetStaticMethodID(clazz, "init2", "()V");
32 if (methodId == NULL) {
33 return UNKNOWN_ERROR;
34 }
35 env->CallStaticVoidMethod(clazz, methodId);
36 ALOGI("System server: entering thread pool.\n");
37 ProcessState::self()->startThreadPool();
38 IPCThreadState::self()->joinThreadPool();
39 ALOGI("System server: exiting thread pool.\n");
40 return NO_ERROR;
41 }
第9-14行(system_init->system_init)如果发现系统属性中设置了启动SurfaceFlinger服务, 第13行(system_init->system_init)会调用SurfaceFlinger的instantiate函数来启动SurfaceFlinger服务, 关于SurfaceFlinger的instantiate的详细分析可以参考page3文件.
第37-38行(system_init->system_init)是启动Binder的线程池, 从此开始, SystemServer进程就可以接受Binder的进程间通信了.
page3
我们从SurfaceFlinger的instantiate函数作为入口来分析SurfaceFinger服务的启动.
我们先来看一下SurfaceFlinger类的继承体系:
class SurfaceFlinger : public BinderService<SurfaceFlinger>,
public BnSurfaceComposer,
private IBinder::DeathRecipient,
private Thread,
private HWComposer::EventHandler
我靠!SurfaceFlinger继承了5个父类.
不管了, 先分析instantiate函数, instantiate函数是从BinderService继承而来的, 我们先来看一下BinderService类的声明:
template<typename SERVICE> class BinderService
BinderService接受一个模板参数.
BinderService的instantiate函数定义如下:
static void instantiate() {
publish();
}
instantiate函数只是调用了publish函数, publish函数的定义如下:
1 static status_t publish(bool allowIsolated = false) {
2 sp<IServiceManager> sm(defaultServiceManager());
3 return sm->addService(String16(SERVICE::getServiceName()), new SERVICE(), allowIsolated);
4 }
第2行(BinderService->publish)获得ServiceManager.
第3行(BinderService->publish)会new一个SERVICE实例, 并调用ServiceManager的addService函数来交给ServiceManager管理, 这是Binder机制的基础.
因此这里会new一个SurfaceFlinger对象, 关于SurfaceFlinger的构造函数的分析可以参考page4文件.
因为ServiceManager的addService函数的参数是个SP类型的, 因此这里会导致SurfaceFlinger的onFirstRef函数的调用, onFirstRef函数的定义如下:
1void SurfaceFlinger::onFirstRef()
2{
3 mEventQueue.init(this);
4
5 run("SurfaceFlinger", PRIORITY_URGENT_DISPLAY);
6
7 // Wait for the main thread to be done with its initialization
8 mReadyToRunBarrier.wait();
9}
第3行(SurfaceFlinger->onFirstRef)成员变量mEventQueue是一个MessageQueue类型的, 因此这里会调用MessageQueue的init函数. 关于MessageQueue的init函数的实现可以参考page5文件.
第5行(SurfaceFlinger->onFirstRef)会调用run函数, run函数是从Thread类继承下来的. 关于Thread的run函数的详细分析可以参考page6文件.
page4
我们分析一下SurfaceFlinger的构造函数的实现:
1 SurfaceFlinger::SurfaceFlinger()
2 : BnSurfaceComposer(), Thread(false),
3 mTransactionFlags(0),
4 mTransactionPending(false),
5 mAnimTransactionPending(false),
6 mLayersRemoved(false),
7 mRepaintEverything(0),
8 mBootTime(systemTime()),
9 mVisibleRegionsDirty(false),
10 mHwWorkListDirty(false),
11 mDebugRegion(0),
12 mDebugDDMS(0),
13 mDebugDisableHWC(0),
14 mDebugDisableTransformHint(0),
15 mDebugInSwapBuffers(0),
16 mLastSwapBufferTime(0),
17 mDebugInTransaction(0),
18 mLastTransactionTime(0),
19 mBootFinished(false)
20 {
21 ALOGI("SurfaceFlinger is starting");
22
23 // debugging stuff...
24 char value[PROPERTY_VALUE_MAX];
25
26 property_get("debug.sf.showupdates", value, "0");
27 mDebugRegion = atoi(value);
28
29 property_get("debug.sf.ddms", value, "0");
30 mDebugDDMS = atoi(value);
31 if (mDebugDDMS) {
32 if (!startDdmConnection()) {
33 // start failed, and DDMS debugging not enabled
34 mDebugDDMS = 0;
35 }
36 }
37 ALOGI_IF(mDebugRegion, "showupdates enabled");
38 ALOGI_IF(mDebugDDMS, "DDMS debugging enabled");
39 }
可以看到, SurfaceFlinger的构造函数除了初始化成员变量之外, 没有什么额外的逻辑.
page5
我们分析一下MessageQueue的init函数的实现, 如下所示:
1void MessageQueue::init(const sp<SurfaceFlinger>& flinger)
2{
3 mFlinger = flinger;
4 mLooper = new Looper(true);
5 mHandler = new Handler(*this);
6}
第3行(MessageQueue->init)会将SurfaceFlinger对象保存到MessageQueue里.
第4行(MessageQueue->init)会new一个Looper对象, 用于分发消息.
第5行(MessageQueue->init)会用本MessageQueue去初始化一个Handler对象, 注意, Handler是在MessageQueue类里定义的一个内部类, 定义如下:
class Handler : public MessageHandler {
enum {
eventMaskInvalidate = 0x1,
eventMaskRefresh = 0x2
};
MessageQueue& mQueue;
int32_t mEventMask;
public:
Handler(MessageQueue& queue) : mQueue(queue), mEventMask(0) { }
virtual void handleMessage(const Message& message);
void dispatchRefresh();
void dispatchInvalidate();
};
在Android系统中, 显示系统在底层是通过SurfaceFlinger服务来完成的, 因此从今天开始, 我们从SurfaceFlinger服务作为入口来分析一下Android显示系统.
SurfaceFlinger服务是在System进程中, 而System进程是由Zygote进程启动的, 并且是以Java层的SystemServer类的静态成员函数main为入口函数的。
因此,接下来我们就从SystemServer类(定义在SystemServer.java文件中)的静态成员函数main开始,分析SurfaceFlinger服务的启动过程:
1 public static void main(String[] args) {
2 if (System.currentTimeMillis() < EARLIEST_SUPPORTED_TIME) {
3 // If a device's clock is before 1970 (before 0), a lot of
4 // APIs crash dealing with negative numbers, notably
5 // java.io.File#setLastModified, so instead we fake it and
6 // hope that time from cell towers or NTP fixes it
7 // shortly.
8 Slog.w(TAG, "System clock is before 1970; setting to 1970.");
9 SystemClock.setCurrentTimeMillis(EARLIEST_SUPPORTED_TIME);
10 }
11 if (SamplingProfilerIntegration.isEnabled()) {
12 SamplingProfilerIntegration.start();
13 timer = new Timer();
14 timer.schedule(new TimerTask() {
15 @Override
16 public void run() {
17 SamplingProfilerIntegration.writeSnapshot("system_server", null);
18 }
19 }, SNAPSHOT_INTERVAL, SNAPSHOT_INTERVAL);
20 }
// Mmmmmm... more memory!
21 dalvik.system.VMRuntime.getRuntime().clearGrowthLimit();
// The system server has to run all of the time, so it needs to be
// as efficient as possible with its memory usage.
22 VMRuntime.getRuntime().setTargetHeapUtilization(0.8f);
23 System.loadLibrary("android_servers");
24 init1(args);
25 }
第24行(SystemServer.main)会调用init1函数来进行初始化操作, init1函数是个native函数来初始化C++层的服务, 会导致com_android_server_SystemServer.cpp的android_server_SystemServer_init1函数的调用, 关于com_android_server_SystemServer.cpp的android_server_SystemServer_init1函数的详细分析可以参考page2文件.
page2
1static void android_server_SystemServer_init1(JNIEnv* env, jobject clazz)
2{
3 system_init();
4}
第3行(com_android_server_SystemServer->android_server_SystemServer_init1)会调用system_init函数, system_init函数是在system_init.cpp文件中定义的, system_init函数的定义如下:
1extern "C" status_t system_init()
2{
3 ALOGI("Entered system_init()");
4 sp<ProcessState> proc(ProcessState::self());
5 sp<IServiceManager> sm = defaultServiceManager();
6 ALOGI("ServiceManager: %p\n", sm.get());
7 sp<GrimReaper> grim = new GrimReaper();
8 sm->asBinder()->linkToDeath(grim, grim.get(), 0);
9 char propBuf[PROPERTY_VALUE_MAX];
10 property_get("system_init.startsurfaceflinger", propBuf, "1");
11 if (strcmp(propBuf, "1") == 0) {
12 // Start the SurfaceFlinger
13 SurfaceFlinger::instantiate();
14 }
15 property_get("system_init.startsensorservice", propBuf, "1");
16 if (strcmp(propBuf, "1") == 0) {
17 // Start the sensor service
18 SensorService::instantiate();
19 }
// And now start the Android runtime. We have to do this bit
// of nastiness because the Android runtime initialization requires
// some of the core system services to already be started.
// All other servers should just start the Android runtime at
// the beginning of their processes's main(), before calling
// the init function.
20 ALOGI("System server: starting Android runtime.\n");
21 AndroidRuntime* runtime = AndroidRuntime::getRuntime();
22 ALOGI("System server: starting Android services.\n");
23 JNIEnv* env = runtime->getJNIEnv();
24 if (env == NULL) {
25 return UNKNOWN_ERROR;
26 }
27 jclass clazz = env->FindClass("com/android/server/SystemServer");
28 if (clazz == NULL) {
29 return UNKNOWN_ERROR;
30 }
31 jmethodID methodId = env->GetStaticMethodID(clazz, "init2", "()V");
32 if (methodId == NULL) {
33 return UNKNOWN_ERROR;
34 }
35 env->CallStaticVoidMethod(clazz, methodId);
36 ALOGI("System server: entering thread pool.\n");
37 ProcessState::self()->startThreadPool();
38 IPCThreadState::self()->joinThreadPool();
39 ALOGI("System server: exiting thread pool.\n");
40 return NO_ERROR;
41 }
第9-14行(system_init->system_init)如果发现系统属性中设置了启动SurfaceFlinger服务, 第13行(system_init->system_init)会调用SurfaceFlinger的instantiate函数来启动SurfaceFlinger服务, 关于SurfaceFlinger的instantiate的详细分析可以参考page3文件.
第37-38行(system_init->system_init)是启动Binder的线程池, 从此开始, SystemServer进程就可以接受Binder的进程间通信了.
page3
我们从SurfaceFlinger的instantiate函数作为入口来分析SurfaceFinger服务的启动.
我们先来看一下SurfaceFlinger类的继承体系:
class SurfaceFlinger : public BinderService<SurfaceFlinger>,
public BnSurfaceComposer,
private IBinder::DeathRecipient,
private Thread,
private HWComposer::EventHandler
我靠!SurfaceFlinger继承了5个父类.
不管了, 先分析instantiate函数, instantiate函数是从BinderService继承而来的, 我们先来看一下BinderService类的声明:
template<typename SERVICE> class BinderService
BinderService接受一个模板参数.
BinderService的instantiate函数定义如下:
static void instantiate() {
publish();
}
instantiate函数只是调用了publish函数, publish函数的定义如下:
1 static status_t publish(bool allowIsolated = false) {
2 sp<IServiceManager> sm(defaultServiceManager());
3 return sm->addService(String16(SERVICE::getServiceName()), new SERVICE(), allowIsolated);
4 }
第2行(BinderService->publish)获得ServiceManager.
第3行(BinderService->publish)会new一个SERVICE实例, 并调用ServiceManager的addService函数来交给ServiceManager管理, 这是Binder机制的基础.
因此这里会new一个SurfaceFlinger对象, 关于SurfaceFlinger的构造函数的分析可以参考page4文件.
因为ServiceManager的addService函数的参数是个SP类型的, 因此这里会导致SurfaceFlinger的onFirstRef函数的调用, onFirstRef函数的定义如下:
1void SurfaceFlinger::onFirstRef()
2{
3 mEventQueue.init(this);
4
5 run("SurfaceFlinger", PRIORITY_URGENT_DISPLAY);
6
7 // Wait for the main thread to be done with its initialization
8 mReadyToRunBarrier.wait();
9}
第3行(SurfaceFlinger->onFirstRef)成员变量mEventQueue是一个MessageQueue类型的, 因此这里会调用MessageQueue的init函数. 关于MessageQueue的init函数的实现可以参考page5文件.
第5行(SurfaceFlinger->onFirstRef)会调用run函数, run函数是从Thread类继承下来的. 关于Thread的run函数的详细分析可以参考page6文件.
page4
我们分析一下SurfaceFlinger的构造函数的实现:
1 SurfaceFlinger::SurfaceFlinger()
2 : BnSurfaceComposer(), Thread(false),
3 mTransactionFlags(0),
4 mTransactionPending(false),
5 mAnimTransactionPending(false),
6 mLayersRemoved(false),
7 mRepaintEverything(0),
8 mBootTime(systemTime()),
9 mVisibleRegionsDirty(false),
10 mHwWorkListDirty(false),
11 mDebugRegion(0),
12 mDebugDDMS(0),
13 mDebugDisableHWC(0),
14 mDebugDisableTransformHint(0),
15 mDebugInSwapBuffers(0),
16 mLastSwapBufferTime(0),
17 mDebugInTransaction(0),
18 mLastTransactionTime(0),
19 mBootFinished(false)
20 {
21 ALOGI("SurfaceFlinger is starting");
22
23 // debugging stuff...
24 char value[PROPERTY_VALUE_MAX];
25
26 property_get("debug.sf.showupdates", value, "0");
27 mDebugRegion = atoi(value);
28
29 property_get("debug.sf.ddms", value, "0");
30 mDebugDDMS = atoi(value);
31 if (mDebugDDMS) {
32 if (!startDdmConnection()) {
33 // start failed, and DDMS debugging not enabled
34 mDebugDDMS = 0;
35 }
36 }
37 ALOGI_IF(mDebugRegion, "showupdates enabled");
38 ALOGI_IF(mDebugDDMS, "DDMS debugging enabled");
39 }
可以看到, SurfaceFlinger的构造函数除了初始化成员变量之外, 没有什么额外的逻辑.
page5
我们分析一下MessageQueue的init函数的实现, 如下所示:
1void MessageQueue::init(const sp<SurfaceFlinger>& flinger)
2{
3 mFlinger = flinger;
4 mLooper = new Looper(true);
5 mHandler = new Handler(*this);
6}
第3行(MessageQueue->init)会将SurfaceFlinger对象保存到MessageQueue里.
第4行(MessageQueue->init)会new一个Looper对象, 用于分发消息.
第5行(MessageQueue->init)会用本MessageQueue去初始化一个Handler对象, 注意, Handler是在MessageQueue类里定义的一个内部类, 定义如下:
class Handler : public MessageHandler {
enum {
eventMaskInvalidate = 0x1,
eventMaskRefresh = 0x2
};
MessageQueue& mQueue;
int32_t mEventMask;
public:
Handler(MessageQueue& queue) : mQueue(queue), mEventMask(0) { }
virtual void handleMessage(const Message& message);
void dispatchRefresh();
void dispatchInvalidate();
};
发表评论
-
Activity与WindowManagerService连接的过程(三)
2018-04-16 16:27 584page11 WindowManagerService ... -
Activity与WindowManagerService连接的过程(二)
2018-04-16 16:36 706page6 WindowManagerGlobal的getW ... -
Activity与WindowManagerService连接的过程(一)
2018-04-16 16:21 955page1 Activity组件在 ... -
Activity的ViewRoot的创建过程(三)
2017-11-06 14:25 707page7 在这篇文章里, 我们分析一下W类的构造过程. W ... -
Activity的ViewRoot的创建过程(二)
2017-11-06 14:29 869page4 我们看一下ViewRootImpl对象的创 ... -
Activity的ViewRoot的创建过程(一)
2017-11-06 14:27 1026page1 当一个Activity第一次激活的时候会为该Ac ... -
Activity的Window和WindowManager的创建过程(三)
2017-07-05 11:49 1299page9 在这里我们分析一下DisplayManager的 ... -
Activity的Window和WindowManager的创建过程(二)
2017-07-05 11:31 499page5 在这篇文章中, 我们分析一下ContextImp ... -
Activity的Window和WindowManager的创建过程(一)
2017-07-05 11:27 575page1 我们开始分析一下Activity的Window和 ... -
Acitivy创建Context的过程(二)
2017-06-21 14:11 452page4 在这里我们分析一下ContextImpl的ini ... -
Acitivy创建Context的过程(一)
2017-06-21 14:15 586page1 从本篇文章开始,我们分析一下Activity创建 ... -
应用程序进程与SurfaceFlinger的连接过程
2017-06-21 11:49 1025我们从SurfaceComposerClient对象的创建开始 ... -
Android源码之SurfaceFlinger的启动(三)
2017-04-20 11:09 1003page11 我们来看一下SurfaceFlinger ... -
Android源码之SurfaceFlinger的启动(二)
2017-04-18 15:15 813page6 我们看一下Thread的run函数的实现: ... -
Android源码之Zygote
2015-12-15 11:45 481当ActivityManagerService启动一个应用程序 ... -
Android源码之Binder(五)
2015-12-04 09:19 1415Service组件在启动时,需要将自己注册到Service M ... -
Android源码之Binder(四)
2015-12-04 09:18 1803case BINDER_SET_MAX_THREADS: ... -
Android源码之Binder(三)
2015-12-04 09:17 881{ int ret; struct binder_pr ... -
Android源码之Binder(二)
2015-12-04 09:15 502分析完Binder驱动程序的打开和内存分配的过程之后,我们看一 ... -
Android源码之Binder(一)
2015-12-04 09:12 962在Android系统中,进程间通信使用的是Binder机制。B ...
相关推荐
第2章通过Android源码中的一处实例深入地介绍了JNI技术。 第3章围绕init进程,介绍了如何解析init.rc以启动Zygote和属性服务(property service)的工作原理。 第4章剖析了zygote和system_server进程的工作...
全书共10章,第1章介绍了阅读本书所需要做的准备工作,主要包括对Android系统架构和源码阅读方法的介绍;第2章通过对Android系统中的MediaScanner进行分析,详细讲解了Android中十分重要的JNI技术;第3章分析了init...
共10章,第1章介绍了阅读本书所需要做的准备工作,主要包括对Android系统架构和源码阅读方法的介绍;第2章通过对Android系统中的MediaScanner进行分析,详细讲解了Android中十分重要的JNI技术;第3章分析了init进程...
全书共10章,第1章介绍了阅读本书所需要做的准备工作,主要包括对Android系统架构和源码阅读方法的介绍;第2章通过对Android系统中的MediaScanner进行分析,详细讲解了Android中十分重要的JNI技术;第3章分析了init...
《深入理解Android(卷1)》共10章,第1章介绍了阅读本书所需要做的准备工作,主要包括对Android系统架构和源码阅读方法的介绍;第2章通过对Android系统中的MediaScanner进行分析,详细讲解了Android中十分重要的JNI...
全书共10章,第1章介绍了阅读本书所需要做的准备工作,主要包括对Android系统架构和源码阅读方法的介绍;第2章通过对Android系统中的MediaScanner进行分析,详细讲解了Android中十分重要的JNI技术;第3章分析了init...
全书共10章,第1章介绍了阅读本书所需要做的准备工作,主要包括对android系统架构和源码阅读方法的介绍;第2章通过对android系统中的mediascanner进行分析,详细讲解了android中十分重要的jni技术;第3章分析了...
全书共10章,第1章介绍了阅读本书所需要做的准备工作,主要包括对Android系统架构和源码阅读方法的介绍;第2章通过对Android系统中的MediaScanner进行分析,详细讲解了Android中十分重要的JNI技术;第3章分析了init...