Android应用程序内部启动Activity过程（startActivity）的源代码分析

文章转载至CSDN社区罗升阳的安卓之旅，原文地址：http://blog.csdn.net/luoshengyang/article/details/6703247

上文介绍了Android应用程序的启动过程，即应用程序默认Activity的启动过程，一般来说，这种默认 Activity是在新的进程和任务中启动的；本文将继续分析在应用程序内部启动非默认Activity的过程的源代码，这种非默认Activity一般 是在原来的进程和任务中启动的。

这里，我们像上一篇文章Android应用程序启动过程源代码分析一样，采用再上一篇文章Android应用程序的Activity启动过程简要介绍和学习计划所举的例子来分析在应用程序内部启动非默认Activity的过程。

在应用程序内部启动非默认Activity的过程与在应用程序启动器Launcher中启动另外一个应用程序的默认Activity的过程大体上一致的，因此，这里不会像上文Android应用程序启动过程源代码分析一样详细分析每一个步骤，我们着重关注有差别的地方。

回忆一下Android应用程序的Activity启动过程简要介绍和学习计划一 文所用的应用程序Activity，它包含两个Activity，分别是MainActivity和SubActivity，前者是应用程序的默认 Activity，后者是非默认Activity。MainActivity启动起来，通过点击它界面上的按钮，便可以在应用程序内部启动 SubActivity。

我们先来看一下应用程序的配置文件AndroidManifest.xml，看看这两个Activity是如何配置的：

[html] view plaincopy

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <manifest xmlns:android="http://schemas.android.com/apk/res/android"
  3. package="shy.luo.activity"
  4. android:versionCode="1"
  5. android:versionName="1.0">
  6. <application android:icon="@drawable/icon" android:label="@string/app_name">
  7. <activity android:name=".MainActivity"
  8. android:label="@string/app_name">
  9. <intent-filter>
  10. <action android:name="android.intent.action.MAIN" />
  11. <category android:name="android.intent.category.LAUNCHER" />
  12. </intent-filter>
  13. </activity>
  14. <activity android:name=".SubActivity"
  15. android:label="@string/sub_activity">
  16. <intent-filter>
  17. <action android:name="shy.luo.activity.subactivity"/>
  18. <category android:name="android.intent.category.DEFAULT"/>
  19. </intent-filter>
  20. </activity>
  21. </application>
  22. </manifest>

这里可以很清楚地看到，MainActivity被配置成了应用程序的默认Activity，而SubActivity可以通过名称 “shy.luo.activity.subactivity”隐式地启动，我们来看一下src/shy/luo/activity /MainActivity.java文件的内容，可以清楚地看到SubActivity是如何隐式地启动的：

[java] view plaincopy

  1. public class MainActivity extends Activity  implements OnClickListener {
  2. ......
  3. @Override
  4. public void onClick(View v) {
  5. if(v.equals(startButton)) {
  6. Intent intent = new Intent("shy.luo.activity.subactivity");
  7. startActivity(intent);
  8. }
  9. }
  10. }

这里，首先创建一个名称为“shy.luo.activity.subactivity”的Intent，然后以这个Intent为参数，通过调用startActivity函数来实现隐式地启动SubActivity。

有了这些背景知识后，我们就来看一下SubActivity启动过程的序列图：

点击查看大图

与前面介绍的MainActivity启动过程相比，这里少了中间创建新的进程的步骤；接下来，我们就详细分析一下SubActivity与MainActivity启动过程中有差别的地方，相同的地方请参考Android应用程序启动过程源代码分析一文。

Step 1. Activity.startActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step

2大体一致，通过指定名称“shy.luo.activity.subactivity”来告诉应用程序框架层，它要隐式地启动SubActivity。
所不同的是传入的参数intent没有Intent.FLAG_ACTIVITY_NEW_TASK标志，表示这个SubActivity和启动它的
MainActivity运行在同一个Task中。

Step 2. Activity.startActivityForResult

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 3一致。

Step 3. Instrumentation.execStartActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 4一致。

Step 4. ActivityManagerProxy.startActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 5一致。

Step 5. ActivityManagerService.startActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 6一致。

Step 6. ActivityStack.startActivityMayWait

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 7一致。

Step 7. ActivityStack.startActivityLocked

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 8一致。

Step 8. ActivityStack.startActivityUncheckedLocked

这一步与上一篇文章Android应用程序启动过程源代码分析的Step

9有所不同，主要是当前要启动的Activity与启动它的Activity是在同一个Task中运行的，我们来详细看一下。这个函数定义在
frameworks/base/services/java/com/android/server/am/ActivityStack.java文件
中：

[java] view plaincopy

  1. public class ActivityStack {
  2. ......
  3. final int startActivityUncheckedLocked(ActivityRecord r,
  4. ActivityRecord sourceRecord, Uri[] grantedUriPermissions,
  5. int grantedMode, boolean onlyIfNeeded, boolean doResume) {
  6. final Intent intent = r.intent;
  7. final int callingUid = r.launchedFromUid;
  8. int launchFlags = intent.getFlags();
  9. ......
  10. if (sourceRecord == null) {
  11. ......
  12. } else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
  13. ......
  14. } else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE
  15. ......
  16. }
  17. if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
  18. ......
  19. }
  20. boolean addingToTask = false;
  21. if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
  22. (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
  23. || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
  24. || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
  25. ......
  26. }
  27. if (r.packageName != null) {
  28. // If the activity being launched is the same as the one currently
  29. // at the top, then we need to check if it should only be launched
  30. // once.
  31. ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
  32. if (top != null && r.resultTo == null) {
  33. if (top.realActivity.equals(r.realActivity)) {
  34. ......
  35. }
  36. }
  37. } else {
  38. ......
  39. }
  40. boolean newTask = false;
  41. // Should this be considered a new task?
  42. if (r.resultTo == null && !addingToTask
  43. && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
  44. ......
  45. } else if (sourceRecord != null) {
  46. ......
  47. // An existing activity is starting this new activity, so we want
  48. // to keep the new one in the same task as the one that is starting
  49. // it.
  50. r.task = sourceRecord.task;
  51. ......
  52. } else {
  53. ......
  54. }
  55. ......
  56. startActivityLocked(r, newTask, doResume);
  57. return START_SUCCESS;
  58. }
  59. ......
  60. }

这里，参数intent的标志位Intent.FLAG_ACTIVITY_NEW_TASK没有设置，在配置文件
AndriodManifest.xml中，SubActivity也没有配置启动模式launchMode，于是它就默认标准模式，即
ActivityInfo.LAUNCH_MULTIPLE，因此，下面if语句不会执行：

[java] view plaincopy

  1. if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
  2. (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
  3. || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
  4. || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
  5. ......
  6. }

于是，变量addingToTask为false。

继续往下看：

[java] view plaincopy

  1. if (r.packageName != null) {
  2. // If the activity being launched is the same as the one currently
  3. // at the top, then we need to check if it should only be launched
  4. // once.
  5. ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
  6. if (top != null && r.resultTo == null) {
  7. if (top.realActivity.equals(r.realActivity)) {
  8. ......
  9. }
  10. }
  11. }

这里看一下当前要启动的Activity是否就是当前堆栈顶端的Activity，如果是的话，在某些情况下，就不用再重新启动了。函数topRunningNonDelayedActivityLocked返回当前
堆栈顶端的Activity，这里即为MainActivity，而当前要启动的Activity为SubActivity，因此，这二者不相等，于是跳过里面的if语句。

接着往下执行：

[java] view plaincopy

  1. // Should this be considered a new task?
  2. if (r.resultTo == null && !addingToTask
  3. && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
  4. ......
  5. } else if (sourceRecord != null) {
  6. ......
  7. // An existing activity is starting this new activity, so we want
  8. // to keep the new one in the same task as the one that is starting
  9. // it.
  10. r.task = sourceRecord.task;
  11. ......
  12. } else {
  13. ......
  14. }

前面说过参数intent的标志位Intent.FLAG_ACTIVITY_NEW_TASK没有设置，而这里的sourceRecord即为当前执
行启动Activity操作的Activity，这里即为MainActivity，因此，它不为null，于是于MainActivity所属的
Task设置到r.task中去，这里的r即为SubActivity。看到这里，我们就知道SubActivity要和MainActivity运行在
同一个Task中了，同时，变量newTask的值为false。

最后，函数进 入startActivityLocked(r, newTask,
doResume)进一步处理了。这个函数同样是定义在frameworks/base/services/java/com/android
/server/am/ActivityStack.java文件中：

[java] view plaincopy

  1. public class ActivityStack {
  2. ......
  3. private final void startActivityLocked(ActivityRecord r, boolean newTask,
  4. boolean doResume) {
  5. final int NH = mHistory.size();
  6. int addPos = -1;
  7. if (!newTask) {
  8. // If starting in an existing task, find where that is...
  9. boolean startIt = true;
  10. for (int i = NH-1; i >= 0; i--) {
  11. ActivityRecord p = (ActivityRecord)mHistory.get(i);
  12. if (p.finishing) {
  13. continue;
  14. }
  15. if (p.task == r.task) {
  16. // Here it is!  Now, if this is not yet visible to the
  17. // user, then just add it without starting; it will
  18. // get started when the user navigates back to it.
  19. addPos = i+1;
  20. if (!startIt) {
  21. mHistory.add(addPos, r);
  22. r.inHistory = true;
  23. r.task.numActivities++;
  24. mService.mWindowManager.addAppToken(addPos, r, r.task.taskId,
  25. r.info.screenOrientation, r.fullscreen);
  26. if (VALIDATE_TOKENS) {
  27. mService.mWindowManager.validateAppTokens(mHistory);
  28. }
  29. return;
  30. }
  31. break;
  32. }
  33. if (p.fullscreen) {
  34. startIt = false;
  35. }
  36. }
  37. }
  38. ......
  39. // Slot the activity into the history stack and proceed
  40. mHistory.add(addPos, r);
  41. r.inHistory = true;
  42. r.frontOfTask = newTask;
  43. r.task.numActivities++;
  44. ......
  45. if (doResume) {
  46. resumeTopActivityLocked(null);
  47. }
  48. }
  49. ......
  50. }

这里传进来的参数newTask为false，doResume为true。当newTask为false，表示即将要启动的Activity是在原有
的Task运行时，如果这个原有的Task当前对用户不可见时，这时候就不需要继续执行下去了，因为即使把这个Activity启动起来，用户也看不到，
还不如先把它保存起来，等到下次这个Task对用户可见的时候，再启动不迟。这里，这个原有的Task，即运行MainActivity的Task当前对
用户是可见的，因此，会继续往下执行。

接下去执行就会把这个SubActivity通过mHistroy.add(addPos, r)添加到堆栈顶端去，然后调用resumeTopActivityLocked进一步操作。

Step 9. ActivityStack.resumeTopActivityLocked

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 10一致。

但是要注意的是，执行到这个函数的时候，当前处于堆栈顶端的Activity为SubActivity，ActivityStack的成员变量mResumedActivity指向MainActivity。
        Step 10. ActivityStack.startPausingLocked
        这一步与上一篇文章Android应用程序启动过程源代码分析的Step 11一致。

从这里开始，ActivityManagerService通知MainActivity进入Paused状态。

Step 11. ApplicationThreadProxy.schedulePauseActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 12一致。

Step 12. ApplicationThread.schedulePauseActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 13一致。

Step 13. ActivityThread.queueOrSendMessage
        这一步与上一篇文章Android应用程序启动过程源代码分析的Step 14一致。

Step 14. H.handleMessage

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 15一致。

Step 15. ActivityThread.handlePauseActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 16一致。

Step 16. ActivityManagerProxy.activityPaused

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 17一致。

Step 17. ActivityManagerService.activityPaused

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 18一致。

Step 18. ActivityStack.activityPaused

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 19一致。

Step 19. ActivityStack.completePauseLocked

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 20一致。

执行到这里的时候，MainActivity就进入Paused状态了，下面就开始要启动SubActivity了。

Step 20. ActivityStack.resumeTopActivityLokced

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 21一致。

Step 21. ActivityStack.startSpecificActivityLocked

这一步与上一篇文章Android应用程序启动过程源代码分析的Step

22就有所不同了，这里，它不会调用mService.startProcessLocked来创建一个新的进程来启动新的Activity，我们来看一
下这个函数的实现，这个函数定义在frameworks/base/services/java/com/android/server/am
/ActivityStack.java文件中：

[java] view plaincopy

  1. public class ActivityStack {
  2. ......
  3. private final void startSpecificActivityLocked(ActivityRecord r,
  4. boolean andResume, boolean checkConfig) {
  5. // Is this activity‘s application already running?
  6. ProcessRecord app = mService.getProcessRecordLocked(r.processName,
  7. r.info.applicationInfo.uid);
  8. ......
  9. if (app != null && app.thread != null) {
  10. try {
  11. realStartActivityLocked(r, app, andResume, checkConfig);
  12. return;
  13. } catch (RemoteException e) {
  14. ......
  15. }
  16. }
  17. ......
  18. }
  19. ......
  20. }

这里由于不是第一次启动应用程序的Activity（MainActivity是这个应用程序第一个启动的Activity），所以下面语句：

[java] view plaincopy

  1. ProcessRecord app = mService.getProcessRecordLocked(r.processName,
  2. nfo.applicationInfo.uid);

取回来的app不为null。在上一篇文章Android应用程序启动过程源代码分析中，
我们介绍过，在Activity应用程序中的AndroidManifest.xml配置文件中，我们没有指定application标签的
process属性，于是系统就会默认使用package的名称，这里就是"shy.luo.activity"了。每一个应用程序都有自己的uid，因
此，这里uid +
process的组合就可以创建一个全局唯一的ProcessRecord。这个ProcessRecord是在前面启动MainActivity时创建
的，因此，这里将它取回来，并保存在变量app中。注意，我们也可以在AndroidManifest.xml配置文件中指定SubActivity的
process属性值，这样SubActivity就可以在另外一个进程中启动，不过很少有应用程序会这样做，我们不考虑这种情况。

这个app的thread也是在前面启动MainActivity时创建好的，于是，这里就直接调用realStartActivityLocked函数来启动新的Activity了，新的Activity的相关信息都保存在参数r中了。

Step 22. ActivityStack.realStartActivityLocked

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 28一致。
        Step 23. ApplicationThreadProxy.scheduleLaunchActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 29一致。

Step 24. ApplicationThread.scheduleLaunchActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 30一致。

Step 25. ActivityThread.queueOrSendMessage

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 31一致。

Step 26. H.handleMessage

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 32一致。

Step 27. ActivityThread.handleLaunchActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 33一致。

Step 28. ActivityThread.performLaunchActivity

这一步与上一篇文章Android应用程序启动过程源代码分析的Step 34一致，不过，这里要从ClassLoader里面加载的类就是shy.luo.activity.SubActivity了。

Step 29. SubAcitiviy.onCreate

这个函数定义在packages/experimental/Activity/src/shy/luo/activity/SubActivity.java文件中，这是我们自定义的app工程文件：

[java] view plaincopy

  1. public class SubActivity extends Activity implements OnClickListener {
  2. ......
  3. @Override
  4. public void onCreate(Bundle savedInstanceState) {
  5. ......
  6. Log.i(LOG_TAG, "Sub Activity Created.");
  7. }
  8. ......
  9. }

这样，SubActivity就在应用程序Activity内部启动起来了。
       在应用程序内部启动新的Activity的过程要执行很多步骤，但是整体来看，主要分为以下四个阶段：

一. Step 1 - Step 10：应用程序的MainActivity通过Binder进程间通信机制通知ActivityManagerService，它要启动一个新的Activity；
       二. Step 11 - Step 15：ActivityManagerService通过Binder进程间通信机制通知MainActivity进入Paused状态；
  
    三. Step 16 - Step
22：MainActivity通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状
态，于是ActivityManagerService就准备要在MainActivity所在的进程和任务中启动新的Activity了；
       四. Step 23 - Step 29：ActivityManagerService通过Binder进程间通信机制通知MainActivity所在的ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。

和上一篇文章Android应用程序启动过程源代码分析中启动应用程序的默认Activity相比，这里在应用程序内部启动新的Activity的过程少了中间创建新的进程这一步，这是因为新的Activity是在已有的进程和任务中执行的，无须创建新的进程和任务。

这里同样不少地方涉及到了Binder进程间通信机制，相关资料请参考Android进程间通信（IPC）机制Binder简要介绍和学习计划一文。

这里希望读者能够把本文和上文Android应用程序启动过程源代码分析仔细比较一下应用程序的默认Activity和非默认Activity启动过程的不同之处，以加深对Activity的理解。

最后，在本文和上文中，我们多次提到了Android应用程序中任务（Task）的概念，它既不是我们在Linux系统中所理解的进程
（Process），也不是线程（Thread），它是用户为了完成某个目标而需要执行的一系列操作的过程的一种抽象。这是一个非常重要的概念，它从用户
体验的角度出发，界定了应用程序的边界，极大地方便了开发者利用现成的组件（Activity）来搭建自己的应用程序，就像搭积木一样，而且，它还为应用
程序屏蔽了底层的进程，即一个任务中的Activity可以都是运行在同一个进程中，也中可以运行在不同的进程中。Android应用程序中的任务的概
念，具体可以参考官方文档http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html，上面已经介绍的非常清楚了。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

时间： 2024-10-06 11:39:46

Android应用程序内部启动Activity过程（startActivity）的源代码分析的相关文章

Android应用程序消息处理机制（Looper、Handler）分析

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6817933 Android应用程序是通过消息来驱动的,系统为每一个应用程序维护一个消息队例,应用程序的主线程不断地从这个消息 队例中获取消息(Looper),然后对这些消息进行处理(Handler),这样就实现了通过消息来驱动应用程序的执行,本文将详细分析Android 应用程序的消息处理机制. 前面我们学习Android应用程序中的Activ

Android应用程序进程启动过程的源代码分析

文章转载至CSDN社区罗升阳的安卓之旅,原文地址: http://blog.csdn.net/luoshengyang/article/details/6747696 Android 应用程序框架层创建的应用程序进程具有两个特点,一是进程的入口函数是ActivityThread.main,二是进程天然支持Binder进程间通信 机制:这两个特点都是在进程的初始化过程中实现的,本文将详细分析Android应用程序进程创建过程中是如何实现这两个特点的. Android应用程序框架层创建的应用程序进程

Android应用程序窗口（Activity）的窗口对象（Window）的创建过程分析

http://blog.csdn.net/luoshengyang/article/details/8223770 在前文中,我们分析了Android应用程序窗口的运行上下文环境的创建过程.由此可知,每一个Activity组件都有一个关联的ContextImpl对象,同时,它还关联有一个Window对象,用来描述一个具体的应用程序窗口.由此又可知,Activity只不过是一个高度抽象的UI组件,它的具体UI实现其实是由其它的一系列对象来实现的.在本文中,我们就将详细分析Android应用程序窗口

Android应用程序窗口（Activity）与WindowManagerService服务的连接过程分析

在前两文中,我们分析了Activity组件的窗口对象和视图对象的创建过程.Activity组件在其窗口对象和视图对象创建完成之后,就会请求与WindowManagerService建立一个连接,即请求WindowManagerService为其增加一个WindowState对象,用来描述它的窗口状态.在本文中,我们就详细分析Activity组件与WindowManagerService的连接过程. 我们从两方面来看Activity组件与WindowManagerService服务之间的连接.一方

Android应用程序窗口（Activity）的视图对象（View）的创建过程分析

从前文可知道,每一个Activity组件都有一个关联的Window对象,用来描述一个应用程序窗口.每一个应用程序窗口内部又包含有一个View对象,用来描述应用程序窗口的视图.应用程序窗口视图是真正用来实现UI内容和布局的,也就是说,每一个Activity组件的UI内容和布局都是通过与其所关联的一个Window对象的内部的一个View对象来实现的.在本文中,我们就详细分析应用程序窗口视图的创建过程. 在前面Android应用程序窗口(Activity)实现框架简要介绍和学习计划一文中提到,应用程序

Android应用程序窗口（Activity）的测量（Measure）、布局（Layout）和绘制（Draw）过程分析

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/8372924 在前面一篇文章中,我们分析了Android应用程序窗口的绘图表面的创建过程.Android应用程序窗口的绘图表面在创建完成之后,我们就可以从上到下地绘制它里面的各个视图了,即各个UI元素了.不过在绘制这些UI元素之前,我们还需要从上到下地测量它们实际所需要的大小,以及对它们的位置进行合适的安排,即对它们进行合适的布局.在本文中,我们

Android应用程序窗口（Activity）实现框架简要介绍和学习计划

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/8170307 前面我们学习了SurfaceFlinger服务的实现原理.有了这个基础之后,从本文开始,我们就可以分析Android系统在Java层的UI实现了.我们知道,在Android应用程序的四大组件中,只有Activity组件与UI相关,它描述的是应用程序窗口,因此,我们就通过它的UI实现来分析Android系统在Java层的UI实现.本文

Android应用程序窗口（Activity）的运行上下文环境（Context）的创建过程分析

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/8201936 在前文中,我们简要介绍了Android应用程序窗口的框架.Android应用程序窗口在运行的过程中,需要访问一些特定的资源或者类.这些特定的资源或者类构成了Android应用程序的运行上下文环境,Android应用程序窗口可以通过一个Context接口来访问它,这个Context接口也是我们在开发应用程序时经常碰到的.在本文中,我们

Android应用程序窗口（Activity）的绘图表面（Surface）的创建过程分析

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/8303098 在前文中,我们分析了应用程序窗口连接到WindowManagerService服务的过程.在这个过程中,WindowManagerService服务会为应用程序窗口创建过一个到SurfaceFlinger服务的连接.有了这个连接之后,WindowManagerService服务就可以为应用程序窗口创建绘图表面了,以便可以用来渲染窗口