AI 助理
文档备案控制台
开发者社区 开发与运维 文章 正文

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

2017-11-06 1368
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：

         上文介绍了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是如何配置的：


  
  
    

   
   
  1. <?xml version="1.0" encoding="utf-8"?>     
    2. 

   
   
  2. <manifest xmlns:android="http://schemas.android.com/apk/res/android"     
    3. 

   
   
  3.     package="shy.luo.activity"     
    4. 

   
   
  4.     android:versionCode="1"     
    5. 

   
   
  5.     android:versionName="1.0">     
    6. 

   
   
  6.     <application android:icon="@drawable/icon" android:label="@string/app_name">     
    7. 

   
   
  7.         <activity android:name=".MainActivity"     
    8. 

   
   
  8.                   android:label="@string/app_name">     
    9. 

   
   
  9.             <intent-filter>     
    10. 

   
   
  10.                 <action android:name="android.intent.action.MAIN" />     
    11. 

   
   
  11.                 <category android:name="android.intent.category.LAUNCHER" />     
    12. 

   
   
  12.             </intent-filter>     
    13. 

   
   
  13.         </activity>     
    14. 

   
   
  14.         <activity android:name=".SubActivity"     
    15. 

   
   
  15.                   android:label="@string/sub_activity">     
    16. 

   
   
  16.             <intent-filter>     
    17. 

   
   
  17.                 <action android:name="shy.luo.activity.subactivity"/>     
    18. 

   
   
  18.                 <category android:name="android.intent.category.DEFAULT"/>     
    19. 

   
   
  19.             </intent-filter>     
    20. 

   
   
  20.         </activity>     
    21. 

   
   
  21.     </application>     
    22. 

   
   
  22. </manifest>     
    23.

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


  
  
    

   
   
  1. public class MainActivity extends Activity  implements OnClickListener {     
    2. 

   
   
  2.     ......     
    3. 

   
   
  3.      
    4. 

   
   
  4.     @Override     
    5. 

   
   
  5.     public void onClick(View v) {     
    6. 

   
   
  6.         if(v.equals(startButton)) {     
    7. 

   
   
  7.             Intent intent = new Intent("shy.luo.activity.subactivity");     
    8. 

   
   
  8.             startActivity(intent);     
    9. 

   
   
  9.         }     
    10. 

   
   
  10.     }     
    11. 

   
   
  11. }     
    12.

       这里，首先创建一个名称为“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文件中：


  
  
    

   
   
  1. public class ActivityStack {   
    2. 

   
   
  2.    
    3. 

   
   
  3.     ......   
    4. 

   
   
  4.    
    5. 

   
   
  5.     final int startActivityUncheckedLocked(ActivityRecord r,   
    6. 

   
   
  6.            ActivityRecord sourceRecord, Uri[] grantedUriPermissions,   
    7. 

   
   
  7.            int grantedMode, boolean onlyIfNeeded, boolean doResume) {   
    8. 

   
   
  8.         final Intent intent = r.intent;   
    9. 

   
   
  9.         final int callingUid = r.launchedFromUid;   
    10. 

   
   
  10.    
    11. 

   
   
  11.         int launchFlags = intent.getFlags();   
    12. 

   
   
  12.    
    13. 

   
   
  13.         ......   
    14. 

   
   
  14.    
    15. 

   
   
  15.         if (sourceRecord == null) {   
    16. 

   
   
  16.            ......   
    17. 

   
   
  17.         } else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {   
    18. 

   
   
  18.            ......   
    19. 

   
   
  19.         } else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE   
    20. 

   
   
  20.            ......   
    21. 

   
   
  21.         }   
    22. 

   
   
  22.    
    23. 

   
   
  23.         if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {   
    24. 

   
   
  24.            ......   
    25. 

   
   
  25.         }   
    26. 

   
   
  26.    
    27. 

   
   
  27.         boolean addingToTask = false;   
    28. 

   
   
  28.         if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&   
    29. 

   
   
  29.            (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)   
    30. 

   
   
  30.            || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK   
    31. 

   
   
  31.            || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {   
    32. 

   
   
  32.             ......   
    33. 

   
   
  33.         }   
    34. 

   
   
  34.    
    35. 

   
   
  35.         if (r.packageName != null) {   
    36. 

   
   
  36.            // If the activity being launched is the same as the one currently   
    37. 

   
   
  37.            // at the top, then we need to check if it should only be launched   
    38. 

   
   
  38.            // once.   
    39. 

   
   
  39.            ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);   
    40. 

   
   
  40.            if (top != null && r.resultTo == null) {   
    41. 

   
   
  41.                if (top.realActivity.equals(r.realActivity)) {   
    42. 

   
   
  42.                    ......   
    43. 

   
   
  43.                }   
    44. 

   
   
  44.            }   
    45. 

   
   
  45.    
    46. 

   
   
  46.         } else {   
    47. 

   
   
  47.            ......   
    48. 

   
   
  48.         }   
    49. 

   
   
  49.    
    50. 

   
   
  50.         boolean newTask = false;   
    51. 

   
   
  51.    
    52. 

   
   
  52.         // Should this be considered a new task?   
    53. 

   
   
  53.         if (r.resultTo == null && !addingToTask   
    54. 

   
   
  54.            && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {   
    55. 

   
   
  55.             ......   
    56. 

   
   
  56.    
    57. 

   
   
  57.         } else if (sourceRecord != null) {   
    58. 

   
   
  58.             ......   
    59. 

   
   
  59.             // An existing activity is starting this new activity, so we want   
    60. 

   
   
  60.             // to keep the new one in the same task as the one that is starting   
    61. 

   
   
  61.             // it.   
    62. 

   
   
  62.             r.task = sourceRecord.task;   
    63. 

   
   
  63.             ......   
    64. 

   
   
  64.    
    65. 

   
   
  65.         } else {   
    66. 

   
   
  66.            ......   
    67. 

   
   
  67.         }   
    68. 

   
   
  68.    
    69. 

   
   
  69.         ......   
    70. 

   
   
  70.    
    71. 

   
   
  71.         startActivityLocked(r, newTask, doResume);   
    72. 

   
   
  72.         return START_SUCCESS;   
    73. 

   
   
  73.     }   
    74. 

   
   
  74.    
    75. 

   
   
  75.     ......   
    76. 

   
   
  76.    
    77. 

   
   
  77. }   
    78.

 

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


  
  
    

   
   
  1.    if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&   
    2. 

   
   
  2.        (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)   
    3. 

   
   
  3.        || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK   
    4. 

   
   
  4. || r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {   
    5. 

   
   
  5. ......   
    6. 

   
   
  6.    }   
    7.

        于是，变量addingToTask为false。

 

         继续往下看：


  
  
    

   
   
  1.    if (r.packageName != null) {   
    2. 

   
   
  2. // If the activity being launched is the same as the one currently   
    3. 

   
   
  3. // at the top, then we need to check if it should only be launched   
    4. 

   
   
  4. // once.   
    5. 

   
   
  5.        ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);   
    6. 

   
   
  6. if (top != null && r.resultTo == null) {   
    7. 

   
   
  7.      if (top.realActivity.equals(r.realActivity)) {   
    8. 

   
   
  8.     ......   
    9. 

   
   
  9.      }   
    10. 

   
   
  10. }   
    11. 

   
   
  11.    
    12. 

   
   
  12.    }    
    13.

 

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

 

        接着往下执行：


  
  
    

   
   
  1.    // Should this be considered a new task?   
    2. 

   
   
  2.    if (r.resultTo == null && !addingToTask   
    3. 

   
   
  3. && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {   
    4. 

   
   
  4. ......   
    5. 

   
   
  5.    
    6. 

   
   
  6.    } else if (sourceRecord != null) {   
    7. 

   
   
  7. ......   
    8. 

   
   
  8. // An existing activity is starting this new activity, so we want   
    9. 

   
   
  9. // to keep the new one in the same task as the one that is starting   
    10. 

   
   
  10. // it.   
    11. 

   
   
  11. r.task = sourceRecord.task;   
    12. 

   
   
  12. ......   
    13. 

   
   
  13.    
    14. 

   
   
  14.    } else {   
    15. 

   
   
  15. ......   
    16. 

   
   
  16.    }   
    17.

 

        前面说过参数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文件中：


  
  
    

   
   
  1. public class ActivityStack {   
    2. 

   
   
  2.    
    3. 

   
   
  3.     ......   
    4. 

   
   
  4.    
    5. 

   
   
  5.     private final void startActivityLocked(ActivityRecord r, boolean newTask,   
    6. 

   
   
  6.             boolean doResume) {   
    7. 

   
   
  7.         final int NH = mHistory.size();   
    8. 

   
   
  8.    
    9. 

   
   
  9.         int addPos = -1;   
    10. 

   
   
  10.    
    11. 

   
   
  11.         if (!newTask) {   
    12. 

   
   
  12.             // If starting in an existing task, find where that is...   
    13. 

   
   
  13.             boolean startIt = true;   
    14. 

   
   
  14.             for (int i = NH-1; i >= 0; i--) {   
    15. 

   
   
  15.                 ActivityRecord p = (ActivityRecord)mHistory.get(i);   
    16. 

   
   
  16.                 if (p.finishing) {   
    17. 

   
   
  17.                     continue;   
    18. 

   
   
  18.                 }   
    19. 

   
   
  19.                 if (p.task == r.task) {   
    20. 

   
   
  20.                     // Here it is!  Now, if this is not yet visible to the   
    21. 

   
   
  21.                     // user, then just add it without starting; it will   
    22. 

   
   
  22.                     // get started when the user navigates back to it.   
    23. 

   
   
  23.                     addPos = i+1;   
    24. 

   
   
  24.                     if (!startIt) {   
    25. 

   
   
  25.                         mHistory.add(addPos, r);   
    26. 

   
   
  26.                         r.inHistory = true;   
    27. 

   
   
  27.                         r.task.numActivities++;   
    28. 

   
   
  28.                         mService.mWindowManager.addAppToken(addPos, r, r.task.taskId,   
    29. 

   
   
  29.                             r.info.screenOrientation, r.fullscreen);   
    30. 

   
   
  30.                         if (VALIDATE_TOKENS) {   
    31. 

   
   
  31.                             mService.mWindowManager.validateAppTokens(mHistory);   
    32. 

   
   
  32.                         }   
    33. 

   
   
  33.                         return;   
    34. 

   
   
  34.                     }   
    35. 

   
   
  35.                     break;   
    36. 

   
   
  36.                 }   
    37. 

   
   
  37.                 if (p.fullscreen) {   
    38. 

   
   
  38.                     startIt = false;   
    39. 

   
   
  39.                 }   
    40. 

   
   
  40.             }   
    41. 

   
   
  41.         }   
    42. 

   
   
  42.    
    43. 

   
   
  43.         ......   
    44. 

   
   
  44.    
    45. 

   
   
  45.         // Slot the activity into the history stack and proceed   
    46. 

   
   
  46.         mHistory.add(addPos, r);   
    47. 

   
   
  47.         r.inHistory = true;   
    48. 

   
   
  48.         r.frontOfTask = newTask;   
    49. 

   
   
  49.         r.task.numActivities++;   
    50. 

   
   
  50.    
    51. 

   
   
  51.         ......   
    52. 

   
   
  52.    
    53. 

   
   
  53.         if (doResume) {   
    54. 

   
   
  54.             resumeTopActivityLocked(null);   
    55. 

   
   
  55.         }   
    56. 

   
   
  56.     }   
    57. 

   
   
  57.    
    58. 

   
   
  58.     ......   
    59. 

   
   
  59.    
    60. 

   
   
  60. }   
    61.

 

        这里传进来的参数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文件中：


  
  
    

   
   
  1. public class ActivityStack {   
    2. 

   
   
  2.    
    3. 

   
   
  3.     ......   
    4. 

   
   
  4.    
    5. 

   
   
  5.     private final void startSpecificActivityLocked(ActivityRecord r,     
    6. 

   
   
  6.             boolean andResume, boolean checkConfig) {     
    7. 

   
   
  7.         // Is this activity's application already running?     
    8. 

   
   
  8.         ProcessRecord app = mService.getProcessRecordLocked(r.processName,     
    9. 

   
   
  9.                 r.info.applicationInfo.uid);     
    10. 

   
   
  10.    
    11. 

   
   
  11.         ......     
    12. 

   
   
  12.    
    13. 

   
   
  13.         if (app != null && app.thread != null) {     
    14. 

   
   
  14.             try {     
    15. 

   
   
  15.                 realStartActivityLocked(r, app, andResume, checkConfig);     
    16. 

   
   
  16.                 return;     
    17. 

   
   
  17.             } catch (RemoteException e) {     
    18. 

   
   
  18.                 ......     
    19. 

   
   
  19.             }     
    20. 

   
   
  20.         }     
    21. 

   
   
  21.    
    22. 

   
   
  22.         ......   
    23. 

   
   
  23.    
    24. 

   
   
  24.     }     
    25. 

   
   
  25.    
    26. 

   
   
  26.     ......   
    27. 

   
   
  27.    
    28. 

   
   
  28. }   
    29.

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


  
  
    

   
   
  1. ProcessRecord app = mService.getProcessRecordLocked(r.processName,     
    2. 

   
   
  2. nfo.applicationInfo.uid);     
    3.

        取回来的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工程文件：


  
  
    

   
   
  1. public class SubActivity extends Activity implements OnClickListener {   
    2. 

   
   
  2.    
    3. 

   
   
  3.     ......   
    4. 

   
   
  4.    
    5. 

   
   
  5.     @Override   
    6. 

   
   
  6.     public void onCreate(Bundle savedInstanceState) {   
    7. 

   
   
  7.         ......   
    8. 

   
   
  8.    
    9. 

   
   
  9.         Log.i(LOG_TAG, "Sub Activity Created.");   
    10. 

   
   
  10.     }   
    11. 

   
   
  11.    
    12. 

   
   
  12.     ......   
    13. 

   
   
  13.    
    14. 

   
   
  14. }   
    15.

 

 

      这样，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，上面已经介绍的非常清楚了。







本文转自 Luoshengyang 51CTO博客，原文链接：http://blog.51cto.com/shyluo/966000，如需转载请自行联系原作者

文章标签：
Android开发
Java
UED
Linux
开发者
关键词：
Android应用程序
Android应用
Android Activity
Android分析
Android源代码
余二五
目录
相关文章
土木林森
|
开发框架 前端开发 Android开发
Flutter 与原生模块（Android 和 iOS）之间的通信机制，包括方法调用、事件传递等，分析了通信的必要性、主要方式、数据传递、性能优化及错误处理，并通过实际案例展示了其应用效果，展望了未来的发展趋势
本文深入探讨了 Flutter 与原生模块（Android 和 iOS）之间的通信机制，包括方法调用、事件传递等，分析了通信的必要性、主要方式、数据传递、性能优化及错误处理，并通过实际案例展示了其应用效果，展望了未来的发展趋势。这对于实现高效的跨平台移动应用开发具有重要指导意义。
土木林森
1320 4
luanpanfei
|
9月前
|
存储 Android开发
如何查看Flutter应用在Android设备上已被撤销的权限？
如何查看Flutter应用在Android设备上已被撤销的权限？
luanpanfei
402 64
aliyun0641063962-48771
|
安全 Android开发 数据安全/隐私保护
深入探讨iOS与Android系统安全性对比分析
在移动操作系统领域，iOS和Android无疑是两大巨头。本文从技术角度出发，对这两个系统的架构、安全机制以及用户隐私保护等方面进行了详细的比较分析。通过深入探讨，我们旨在揭示两个系统在安全性方面的差异，并为用户提供一些实用的安全建议。
aliyun0641063962-48771
1213 3
卓伊凡
|
11月前
|
前端开发 Java Shell
【08】flutter完成屏幕适配-重建Android,增加GetX路由,屏幕适配,基础导航栏-多版本SDK以及gradle造成的关于fvm的使用（flutter version manage）-卓伊凡换人优雅草Alex-开发完整的社交APP-前端客户端开发+数据联调|以优雅草商业项目为例做开发-flutter开发-全流程-商业应用级实战开发-优雅草Alex
【08】flutter完成屏幕适配-重建Android,增加GetX路由,屏幕适配,基础导航栏-多版本SDK以及gradle造成的关于fvm的使用（flutter version manage）-卓伊凡换人优雅草Alex-开发完整的社交APP-前端客户端开发+数据联调|以优雅草商业项目为例做开发-flutter开发-全流程-商业应用级实战开发-优雅草Alex
卓伊凡
764 20
【08】flutter完成屏幕适配-重建Android,增加GetX路由,屏幕适配,基础导航栏-多版本SDK以及gradle造成的关于fvm的使用（flutter version manage）-卓伊凡换人优雅草Alex-开发完整的社交APP-前端客户端开发+数据联调|以优雅草商业项目为例做开发-flutter开发-全流程-商业应用级实战开发-优雅草Alex
卓伊凡
|
11月前
|
Dart 前端开发 Android开发
【09】flutter首页进行了完善-采用android studio 进行真机调试开发-增加了直播间列表和短视频人物列表-增加了用户中心-卓伊凡换人优雅草Alex-开发完整的社交APP-前端客户端开发+数据联调|以优雅草商业项目为例做开发-flutter开发-全流程-商业应用级实战开发-优雅草Alex
【09】flutter首页进行了完善-采用android studio 进行真机调试开发-增加了直播间列表和短视频人物列表-增加了用户中心-卓伊凡换人优雅草Alex-开发完整的社交APP-前端客户端开发+数据联调|以优雅草商业项目为例做开发-flutter开发-全流程-商业应用级实战开发-优雅草Alex
卓伊凡
364 4
【09】flutter首页进行了完善-采用android studio 进行真机调试开发-增加了直播间列表和短视频人物列表-增加了用户中心-卓伊凡换人优雅草Alex-开发完整的社交APP-前端客户端开发+数据联调|以优雅草商业项目为例做开发-flutter开发-全流程-商业应用级实战开发-优雅草Alex
CamilleKing
|
算法 Java 数据库
Android 应用的主线程在什么情况下会被阻塞？
【10月更文挑战第20天】为了避免主线程阻塞，我们需要合理地设计和优化应用的代码。将耗时操作移到后台线程执行，使用异步任务、线程池等技术来提高应用的并发处理能力。同时，要注意避免出现死循环、不合理的锁使用等问题。通过这些措施，可以确保主线程能够高效地运行，提供流畅的用户体验。
CamilleKing
687 58
mzlogin
|
缓存 Java Shell
Android 系统缓存扫描与清理方法分析
Android 系统缓存从原理探索到实现。
mzlogin
557 15
Android 系统缓存扫描与清理方法分析
xibeijing
|
安全 Android开发 数据安全/隐私保护
深入探索Android与iOS系统安全性的对比分析
在当今数字化时代，移动操作系统的安全已成为用户和开发者共同关注的重点。本文旨在通过比较Android与iOS两大主流操作系统在安全性方面的差异，揭示两者在设计理念、权限管理、应用审核机制等方面的不同之处。我们将探讨这些差异如何影响用户的安全体验以及可能带来的风险。
xibeijing
832 21
请看我回答~
|
JSON Java API
探索安卓开发：打造你的首个天气应用
在这篇技术指南中，我们将一起潜入安卓开发的海洋，学习如何从零开始构建一个简单的天气应用。通过这个实践项目，你将掌握安卓开发的核心概念、界面设计、网络编程以及数据解析等技能。无论你是初学者还是有一定基础的开发者，这篇文章都将为你提供一个清晰的路线图和实用的代码示例，帮助你在安卓开发的道路上迈出坚实的一步。让我们一起开始这段旅程，打造属于你自己的第一个安卓应用吧！
请看我回答~
336 14
肥猪肥猪-17824
|
Java Linux 数据库
探索安卓开发：打造你的第一款应用
在数字时代的浪潮中，每个人都有机会成为创意的实现者。本文将带你走进安卓开发的奇妙世界，通过浅显易懂的语言和实际代码示例，引导你从零开始构建自己的第一款安卓应用。无论你是编程新手还是希望拓展技术的开发者，这篇文章都将为你打开一扇门，让你的创意和技术一起飞扬。
肥猪肥猪-17824
241 13

热门文章

最新文章

  • 1
    Android 汉字转拼音之工具篇
  • 2
    [Android]ListView的Adapter.getView()方法中延迟加载图片的优化
  • 3
    我的Android进阶之旅------&gt;Android ListView 应用解析(使用ArrayAdapter，SimpleAdapter和SimpleCursorAdapter适配器)
  • 4
    Java、Android 新建类自动添加头部注释以及如何添加函数注释模板和快捷键
  • 5
    Android系统进程Zygote启动过程的源代码分析（3）
  • 6
    Sencha touch实践（1）在ios,android上变web app为native app
  • 7
    Android v4、v7、v13 的区别
  • 8
    Android——android studio 安装完成之后导入项目的乱码问题
  • 9
    【android基础】之Android返回键处理(事件)
  • 10
    八款开源 Android 游戏引擎 (巨好的资源)【留用】
  • 1
    批量发送短信的平台，安卓群发短信工具插件脚本，批量群发短信软件【autojs版】
    589
  • 2
    Thanox安卓系统增加工具下载，管理、阻止、限制后台每个APP运行情况
    676
  • 3
    qq虚拟视频插件下载安装手机版， 安卓虚拟视频插件，替换摄像头工具
    653
  • 4
    微信虚拟摄像头模块，微信虚拟视频聊天，安卓虚拟摄像头插件
    210
  • 5
    安卓ck提取工具，可提取手机cookie插件，AUTOJS即可实现
    1218
  • 6
    手机型号修改器， 安卓修改手机型号软件， 一键修改手机型号
    405
  • 7
    安卓手机硬改工具， 设备型号修改神器， 安卓硬改一键新机
    847
  • 8
    安卓硬改一键新机工具，一键修改手机型号，串号网卡Imei、sn码【仅供学习参考】
    1733
  • 9
    安卓硬改一键新机，一键新机改串软件，免ROOT网卡串号Imei/sn码
    888
  • 10
    安卓改机工具免root,一键过设备检测,串号SN码【jar即可实现】
    1123

    • 相关课程

    更多
  • 开源Android容器化框架Atlas开发者指南

    • 相关电子书

    更多
  • 58同城Android客户端Walle框架演进与实践之路
  • Android组件化实现
  • 蚂蚁聚宝Android秒级编译——Freeline
    • 下一篇
    【DataEase】零代码数据可视化分析工具的安装部署保姆级教程