日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢(xún)
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷(xiāo)解決方案
Android系統(tǒng)中的進(jìn)程管理：進(jìn)程的創(chuàng)建

對(duì)于操作系統(tǒng)來(lái)說(shuō)，進(jìn)程管理是其最重要的職責(zé)之一。

創(chuàng)新互聯(lián)建站秉承專(zhuān)業(yè)、誠(chéng)信、服務(wù)、進(jìn)取的價(jià)值觀，堅(jiān)持以客戶(hù)為中心、客戶(hù)至上的服務(wù)理念，以“關(guān)注企業(yè)需求，實(shí)現(xiàn)企業(yè)價(jià)值”為導(dǎo)向，努力為企業(yè)提供全面優(yōu)質(zhì)的互聯(lián)網(wǎng)應(yīng)用服務(wù)。服務(wù)包括空間域名、雅安服務(wù)器托管、企業(yè)郵箱、網(wǎng)站建設(shè)、網(wǎng)站優(yōu)化、網(wǎng)絡(luò)營(yíng)銷(xiāo)解決方案和咨詢(xún)服務(wù)，以幫助企業(yè)客戶(hù)應(yīng)用互聯(lián)網(wǎng)。

考慮到這部分的內(nèi)容較多，因此會(huì)拆分成幾篇文章來(lái)講解。

本文是進(jìn)程管理系統(tǒng)文章的***篇，會(huì)講解Android系統(tǒng)中的進(jìn)程創(chuàng)建。

本文適合Android平臺(tái)的應(yīng)用程序開(kāi)發(fā)者，也適合對(duì)于Android系統(tǒng)內(nèi)部實(shí)現(xiàn)感興趣的讀者。

概述

Android系統(tǒng)以Linux內(nèi)核為基礎(chǔ)，所以對(duì)于進(jìn)程的管理自然離不開(kāi)Linux本身提供的機(jī)制。例如：

  • 通過(guò)fork來(lái)創(chuàng)建進(jìn)行
  • 通過(guò)信號(hào)量來(lái)管理進(jìn)程
  • 通過(guò)proc文件系統(tǒng)來(lái)查詢(xún)和調(diào)整進(jìn)程狀態(tài)等

對(duì)于Android來(lái)說(shuō)，進(jìn)程管理的主要內(nèi)容包括以下幾個(gè)部分內(nèi)容：

  • 進(jìn)程的創(chuàng)建
  • 進(jìn)程的優(yōu)先級(jí)管理
  • 進(jìn)程的內(nèi)存管理
  • 進(jìn)程的回收和死亡處理

本文會(huì)專(zhuān)門(mén)講解進(jìn)程的創(chuàng)建，其余部分將在后面的文章中講解。

主要模塊

為了便于下文的講解，這里先介紹一下Android系統(tǒng)中牽涉到進(jìn)程創(chuàng)建的幾個(gè)主要模塊。

同時(shí)為了便于讀者更詳細(xì)的了解這些模塊，這里也同時(shí)提供了這些模塊的代碼路徑。

這里提到的代碼路徑是指AOSP的源碼數(shù)中的路徑。

關(guān)于如何獲取AOSP源碼請(qǐng)參見(jiàn)這里：Downloading the Source。

本文以Android N版本的代碼為示例，所用到的Source Code Tags是：android-7.0.0_r1。

相關(guān)模塊：

  • app_process

代碼路徑：frameworks/base/cmds/app_process

說(shuō)明：app_process是一個(gè)可執(zhí)行程序，該程序的主要作用是啟動(dòng)zygote和system_server進(jìn)程。

  • Zygote

代碼路徑：frameworks/base/core/Java/com/android/internal/os/ZygoteInit.java

說(shuō)明：zygote進(jìn)程是所有應(yīng)用進(jìn)程的父進(jìn)程，這是系統(tǒng)中一個(gè)非常重要的進(jìn)程，下文我們會(huì)詳細(xì)講解。

  • ActivityManager

代碼路徑：frameworks/base/services/core/java/com/android/server/am/

說(shuō)明：am是ActivityManager的縮寫(xiě)。

這個(gè)目錄下的代碼負(fù)責(zé)了Android全部四大組件(Activity，Service，ContentProvider，BroadcastReceiver)的管理，并且還掌控了所有應(yīng)用程序進(jìn)程的創(chuàng)建和進(jìn)程的優(yōu)先級(jí)管理。

因此，這個(gè)部分的內(nèi)容將是本系列文章講解的重點(diǎn)。

進(jìn)程與線程

Android官方開(kāi)發(fā)網(wǎng)站的這篇文章：Processes and Threads 非常好的介紹了Android系統(tǒng)中進(jìn)程相關(guān)的一些基本概念和重要知識(shí)。

在閱讀下文之前，請(qǐng)務(wù)必將這篇文章瀏覽一遍。

關(guān)于進(jìn)程

在Android系統(tǒng)中，進(jìn)程可以大致分為系統(tǒng)進(jìn)程和應(yīng)用進(jìn)程兩大類(lèi)。

系統(tǒng)進(jìn)程是系統(tǒng)內(nèi)置的(例如：init，zygote，system_server進(jìn)程)，屬于操作系統(tǒng)必不可少的一部分。系統(tǒng)進(jìn)程的作用在于：

  • 管理硬件設(shè)備
  • 提供訪問(wèn)設(shè)備的基本能力
  • 管理應(yīng)用進(jìn)程

應(yīng)用進(jìn)程是指應(yīng)用程序運(yùn)行的進(jìn)程。這些應(yīng)用程序可能是系統(tǒng)出廠自帶的(例如Launcher，電話，短信等應(yīng)用)，也可能是用戶(hù)自己安裝的(例如：微信，支付寶等)。

系統(tǒng)進(jìn)程的數(shù)量通常是固定的(出廠或者系統(tǒng)升級(jí)之后就確定了)，并且系統(tǒng)進(jìn)程通常是一直存活，常駐內(nèi)存的。系統(tǒng)進(jìn)程的異常退出將可能導(dǎo)致設(shè)備無(wú)法正常使用。

而應(yīng)用程序和應(yīng)用進(jìn)程在每個(gè)人使用的設(shè)備上通常是各不一樣的。如何管理好這些不確定的應(yīng)用進(jìn)程，就是操作系統(tǒng)本身要仔細(xì)考慮的內(nèi)容。也是衡量一個(gè)操作系統(tǒng)好壞的標(biāo)準(zhǔn)之一。

在本文中，我們會(huì)介紹init，zygote和system_server三個(gè)系統(tǒng)進(jìn)程。

除此之外，本系列文章將會(huì)把主要精力集中在講解Android系統(tǒng)如何管理應(yīng)用進(jìn)程上。

init進(jìn)程

init進(jìn)程是一切的開(kāi)始，在Android系統(tǒng)中，所有進(jìn)程的進(jìn)程號(hào)都是不確定的，唯獨(dú)init進(jìn)程的進(jìn)程號(hào)一定是1。

因?yàn)檫@個(gè)進(jìn)程一定是系統(tǒng)起來(lái)的***個(gè)進(jìn)程。并且，init進(jìn)程掌控了整個(gè)系統(tǒng)的啟動(dòng)邏輯。

我們知道，Android可能運(yùn)行在各種不同的平臺(tái)，不同的設(shè)備上。因此，啟動(dòng)的邏輯是不盡相同的。

為了適應(yīng)各種平臺(tái)和設(shè)備的需求，init進(jìn)程的初始化工作通過(guò)init.rc配置文件來(lái)管理。

你可以在AOSP源碼的system/core/rootdir/路徑找到這些配置文件。

配置文件的主入口文件是init.rc，這個(gè)文件會(huì)通過(guò)import引入其他幾個(gè)文件。

在本文中，我們統(tǒng)稱(chēng)這些文件為init.rc。

init.rc通過(guò)Android Init Language來(lái)進(jìn)行配置。

建議讀者大致閱讀一下其 語(yǔ)法說(shuō)明 。

init.rc中配置了系統(tǒng)啟動(dòng)的時(shí)候該做哪些事情，以及啟動(dòng)哪些系統(tǒng)進(jìn)程。

這其中有兩個(gè)特別重要的進(jìn)程就是：zygote和system_server進(jìn)程。

  • zygote的中文意思是“受精卵“。這是一個(gè)很有寓意的名稱(chēng)：所有的應(yīng)用進(jìn)程都是由zygote fork出來(lái)的子進(jìn)程，因此zygote進(jìn)程是所有應(yīng)用進(jìn)程的父進(jìn)程。
  • system_server 這個(gè)進(jìn)程正如其名稱(chēng)一樣，這是一個(gè)系統(tǒng)服務(wù)器。Framework層的幾乎所有服務(wù)都位于這個(gè)進(jìn)程中。這其中就包括管理四大組件的ActivityManagerService。

Zygote進(jìn)程

init.rc文件會(huì)根據(jù)平臺(tái)不一樣，選擇下面幾個(gè)文件中的一個(gè)來(lái)啟動(dòng)zygote進(jìn)程：

  • init.zygote32.rc
  • init.zygote32_64.rc
  • init.zygote64.rc
  • init.zygote64_32.rc

這幾個(gè)文件的內(nèi)容是大致一致的，僅僅是為了不同平臺(tái)服務(wù)的。這里我們以init.zygote32.rc的文件為例，來(lái)看看其中的內(nèi)容：

 
 
 
    
  
  
  
  1. service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
    2. 
  
  
  
  2. 
  
  
  
  3. class main
    4. 
  
  
  
  4. 
  
  
  
  5. socket zygote stream 660 root system
    6. 
  
  
  
  6. 
  
  
  
  7. onrestart write /sys/android_power/request_state wake
    8. 
  
  
  
  8. 
  
  
  
  9. onrestart write /sys/power/state on
    10. 
  
  
  
  10. 
  
  
  
  11. onrestart restart audioserver
    12. 
  
  
  
  12. 
  
  
  
  13. onrestart restart cameraserver
    14. 
  
  
  
  14. 
  
  
  
  15. onrestart restart media
    16. 
  
  
  
  16. 
  
  
  
  17. onrestart restart netd
    18. 
  
  
  
  18. 
  
  
  
  19. writepid /dev/cpuset/foreground/tasks /dev/stune/foreground/tasks 
    20.

在這段配置文件中(如果你不明白這段配置的含義，請(qǐng)閱讀一下文檔：Android Init Language)，啟動(dòng)了一個(gè)名稱(chēng)叫做zygote的服務(wù)進(jìn)程。這個(gè)進(jìn)程是通過(guò)/system/bin/app_process 這個(gè)可執(zhí)行程序創(chuàng)建的。

并且在啟動(dòng)這個(gè)可執(zhí)行程序的時(shí)候，傳遞了`-Xzygote /system/bin --zygote --start-system-server

class main` 這些參數(shù)。

要知道這里到底做了什么，我們需要看一下app_process的源碼。

app_process的源碼在這個(gè)路徑：frameworks/base/cmds/app_process/app_main.cpp。

這個(gè)文件的main函數(shù)的有如下代碼：

 
 
 
    
  
  
  
  1. int main(int argc, char* const argv[])
    2. 
  
  
  
  2. {
    3. 
  
  
  
  3. ...
    4. 
  
  
  
  4.     while (i < argc) {
    5. 
  
  
  
  5.         const char* arg = argv[i++];
    6. 
  
  
  
  6.         if (strcmp(arg, "--zygote") == 0) {
    7. 
  
  
  
  7.             zygote = true;
    8. 
  
  
  
  8.             niceName = ZYGOTE_NICE_NAME;
    9. 
  
  
  
  9.         } else if (strcmp(arg, "--start-system-server") == 0) {
    10. 
  
  
  
  10.             startSystemServer = true;
    11. 
  
  
  
  11.         ...
    12. 
  
  
  
  12.     }
    13. 
  
  
  
  13.     ...
    14. 
  
  
  
  14.    if (!className.isEmpty()) {
    15. 
  
  
  
  15.         ...
    16. 
  
  
  
  16.     } else {
    17. 
  
  
  
  17.        ...
    18. 
  
  
  
  18.     
    19. 
  
  
  
  19.        if (startSystemServer) {
    20. 
  
  
  
  20.            args.add(String8("start-system-server"));
    21. 
  
  
  
  21.        }
    22. 
  
  
  
  22.     }
    23. 
  
  
  
  23. ...
    24. 
  
  
  
  24.     if (zygote) {
    25. 
  
  
  
  25.         runtime.start("com.android.internal.os.ZygoteInit", args, zygote);
    26. 
  
  
  
  26.     } else if (className) {
    27. 
  
  
  
  27.         runtime.start("com.android.internal.os.RuntimeInit", args, zygote);
    28. 
  
  
  
  28.     } else {
    29. 
  
  
  
  29.         fprintf(stderr, "Error: no class name or --zygote supplied.\n");
    30. 
  
  
  
  30.         app_usage();
    31. 
  
  
  
  31.         LOG_ALWAYS_FATAL("app_process: no class name or --zygote supplied.");
    32. 
  
  
  
  32.         return 10;
    33. 
  
  
  
  33.     }
    34. 
  
  
  
  34. } 
    35.

這里會(huì)判斷，

  • 如果執(zhí)行這個(gè)命令時(shí)帶了--zygote參數(shù)，就會(huì)通過(guò)runtime.start啟動(dòng)com.android.internal.os.ZygoteInit。
  • 如果參數(shù)中帶有--start-system-server參數(shù)，就會(huì)將start-system-server添加到args中。

這段代碼是C++實(shí)現(xiàn)的。在執(zhí)行這段代碼的時(shí)候還沒(méi)有任何Java的環(huán)境。而runtime.start就是啟動(dòng)Java虛擬機(jī)，并在虛擬機(jī)中啟動(dòng)指定的類(lèi)。于是接下來(lái)的邏輯就在ZygoteInit.java中了。

這個(gè)文件的main函數(shù)主要代碼如下：

 
 
 
    
  
  
  
  1. public static void main(String argv[]) {
    2. 
  
  
  
  2.    ...
    3. 
  
  
  
  3. 
  
  
  
  4.    try {
    5. 
  
  
  
  5.        ...
    6. 
  
  
  
  6. 
  
  
  
  7.        boolean startSystemServer = false;
    8. 
  
  
  
  8.        String socketName = "zygote";
    9. 
  
  
  
  9.        String abiList = null;
    10. 
  
  
  
  10.        for (int i = 1; i < argv.length; i++) {
    11. 
  
  
  
  11.            if ("start-system-server".equals(argv[i])) {
    12. 
  
  
  
  12.                startSystemServer = true;
    13. 
  
  
  
  13.            } else if (argv[i].startsWith(ABI_LIST_ARG)) {
    14. 
  
  
  
  14.                ...
    15. 
  
  
  
  15.            }
    16. 
  
  
  
  16.        }
    17. 
  
  
  
  17.        ...
    18. 
  
  
  
  18.        registerZygoteSocket(socketName);
    19. 
  
  
  
  19.        ...
    20. 
  
  
  
  20.        preload();
    21. 
  
  
  
  21.        ...
    22. 
  
  
  
  22.        Zygote.nativeUnmountStorageOnInit();
    23. 
  
  
  
  23. 
  
  
  
  24.        ZygoteHooks.stopZygoteNoThreadCreation();
    25. 
  
  
  
  25. 
  
  
  
  26.        if (startSystemServer) {
    27. 
  
  
  
  27.            startSystemServer(abiList, socketName);
    28. 
  
  
  
  28.        }
    29. 
  
  
  
  29. 
  
  
  
  30.        Log.i(TAG, "Accepting command socket connections");
    31. 
  
  
  
  31.        runSelectLoop(abiList);
    32. 
  
  
  
  32. 
  
  
  
  33.        closeServerSocket();
    34. 
  
  
  
  34.    } catch (MethodAndArgsCaller caller) {
    35. 
  
  
  
  35.        caller.run();
    36. 
  
  
  
  36.    } catch (RuntimeException ex) {
    37. 
  
  
  
  37.        Log.e(TAG, "Zygote died with exception", ex);
    38. 
  
  
  
  38.        closeServerSocket();
    39. 
  
  
  
  39.        throw ex;
    40. 
  
  
  
  40.    }
    41. 
  
  
  
  41. } 
    42.

在這段代碼中，我們主要關(guān)注如下幾行：

  1. 通過(guò) registerZygoteSocket(socketName); 注冊(cè)Zygote Socket
  2. 通過(guò) preload(); 預(yù)先加載所有應(yīng)用都需要的公共資源
  3. 通過(guò) startSystemServer(abiList, socketName); 啟動(dòng)system_server
  4. 通過(guò) runSelectLoop(abiList); 在Looper上等待連接

這里需要說(shuō)明的是：zygote進(jìn)程啟動(dòng)之后，會(huì)啟動(dòng)一個(gè)socket套接字，并通過(guò)Looper一直在這個(gè)套接字上等待連接。

所有應(yīng)用進(jìn)程都是通過(guò)發(fā)送數(shù)據(jù)到這個(gè)套接字上，然后由zygote進(jìn)程創(chuàng)建的。

這里還有一點(diǎn)說(shuō)明的是：

在Zygote進(jìn)程中，會(huì)通過(guò)preload函數(shù)加載需要應(yīng)用程序都需要的公共資源。

預(yù)先加載這些公共資源有如下兩個(gè)好處：

  • 加快應(yīng)用的啟動(dòng)速度 因?yàn)檫@些資源已經(jīng)在zygote進(jìn)程啟動(dòng)的時(shí)候加載好了
  • 通過(guò)共享的方式節(jié)省內(nèi)存 這是Linux本身提供的機(jī)制：父進(jìn)程已經(jīng)加載的內(nèi)容可以在子進(jìn)程中進(jìn)行共享，而不用多份數(shù)據(jù)拷貝(除非子進(jìn)程對(duì)這些數(shù)據(jù)進(jìn)行了修改。)

preload的資源主要是Framework相關(guān)的一些基礎(chǔ)類(lèi)和Resource資源，而這些資源正是所有應(yīng)用都需要的：

開(kāi)發(fā)者通過(guò)Android SDK開(kāi)發(fā)應(yīng)用所調(diào)用的API實(shí)現(xiàn)都在Framework中。

 
 
 
    
  
  
  
  1. static void preload() {
    2. 
  
  
  
  2.    Log.d(TAG, "begin preload");
    3. 
  
  
  
  3.    Trace.traceBegin(Trace.TRACE_TAG_DALVIK, "BeginIcuCachePinning");
    4. 
  
  
  
  4.    beginIcuCachePinning();
    5. 
  
  
  
  5.    Trace.traceEnd(Trace.TRACE_TAG_DALVIK);
    6. 
  
  
  
  6.    Trace.traceBegin(Trace.TRACE_TAG_DALVIK, "PreloadClasses");
    7. 
  
  
  
  7.    preloadClasses();
    8. 
  
  
  
  8.    Trace.traceEnd(Trace.TRACE_TAG_DALVIK);
    9. 
  
  
  
  9.    Trace.traceBegin(Trace.TRACE_TAG_DALVIK, "PreloadResources");
    10. 
  
  
  
  10.    preloadResources();
    11. 
  
  
  
  11.    Trace.traceEnd(Trace.TRACE_TAG_DALVIK);
    12. 
  
  
  
  12.    Trace.traceBegin(Trace.TRACE_TAG_DALVIK, "PreloadOpenGL");
    13. 
  
  
  
  13.    preloadOpenGL();
    14. 
  
  
  
  14.    Trace.traceEnd(Trace.TRACE_TAG_DALVIK);
    15. 
  
  
  
  15.    preloadSharedLibraries();
    16. 
  
  
  
  16.    preloadTextResources();
    17. 
  
  
  
  17. 
  
  
  
  18.    WebViewFactory.prepareWebViewInZygote();
    19. 
  
  
  
  19.    endIcuCachePinning();
    20. 
  
  
  
  20.    warmUpJcaProviders();
    21. 
  
  
  
  21.    Log.d(TAG, "end preload");
    22. 
  
  
  
  22. } 
    23.

system_server進(jìn)程

上文已經(jīng)提到，zygote進(jìn)程起來(lái)之后會(huì)根據(jù)需要啟動(dòng)system_server進(jìn)程。

system_server進(jìn)程中包含了大量的系統(tǒng)服務(wù)。例如：

  • 負(fù)責(zé)網(wǎng)絡(luò)管理的NetworkManagementService
  • 負(fù)責(zé)窗口管理的WindowManagerService
  • 負(fù)責(zé)震動(dòng)管理的VibratorService
  • 負(fù)責(zé)輸入管理的InputManagerService

等等。關(guān)于system_server，我們今后會(huì)其他的文章中專(zhuān)門(mén)講解，這里不做過(guò)多說(shuō)明。

在本文中，我們只關(guān)注system_server中的ActivityManagerService這個(gè)系統(tǒng)服務(wù)。

ActivityManagerService

上文中提到：zygote進(jìn)程在啟動(dòng)之后會(huì)啟動(dòng)一個(gè)socket，然后一直在這個(gè)socket等待連接。

而會(huì)連接它的就是ActivityManagerService。因?yàn)锳ctivityManagerService掌控了所有應(yīng)用進(jìn)程的創(chuàng)建。

所有應(yīng)用程序的進(jìn)程都是由ActivityManagerService通過(guò)socket發(fā)送請(qǐng)求給Zygote進(jìn)程，然后由zygote fork創(chuàng)建的。

ActivityManagerService通過(guò)Process.start方法來(lái)請(qǐng)求zygote創(chuàng)建進(jìn)程：

 
 
 
    
  
  
  
  1. public static final ProcessStartResult start(final String processClass,
    2. 
  
  
  
  2.                              final String niceName,
    3. 
  
  
  
  3.                              int uid, int gid, int[] gids,
    4. 
  
  
  
  4.                              int debugFlags, int mountExternal,
    5. 
  
  
  
  5.                              int targetSdkVersion,
    6. 
  
  
  
  6.                              String seInfo,
    7. 
  
  
  
  7.                              String abi,
    8. 
  
  
  
  8.                              String instructionSet,
    9. 
  
  
  
  9.                              String appDataDir,
    10. 
  
  
  
  10.                              String[] zygoteArgs) {
    11. 
  
  
  
  11.    try {
    12. 
  
  
  
  12.        return startViaZygote(processClass, niceName, uid, gid, gids,
    13. 
  
  
  
  13.                debugFlags, mountExternal, targetSdkVersion, seInfo,
    14. 
  
  
  
  14.                abi, instructionSet, appDataDir, zygoteArgs);
    15. 
  
  
  
  15.    } catch (ZygoteStartFailedEx ex) {
    16. 
  
  
  
  16.        Log.e(LOG_TAG,
    17. 
  
  
  
  17.                "Starting VM process through Zygote failed");
    18. 
  
  
  
  18.        throw new RuntimeException(
    19. 
  
  
  
  19.                "Starting VM process through Zygote failed", ex);
    20. 
  
  
  
  20.    }
    21. 
  
  
  
  21. } 
    22.

這個(gè)函數(shù)會(huì)將啟動(dòng)進(jìn)程所需要的參數(shù)組裝好，并通過(guò)socket發(fā)送給zygote進(jìn)程。然后zygote進(jìn)程根據(jù)發(fā)送過(guò)來(lái)的參數(shù)將進(jìn)程fork出來(lái)。

在ActivityManagerService中，調(diào)用Process.start的地方是下面這個(gè)方法：

 
 
 
    
  
  
  
  1. private final void startProcessLocked(ProcessRecord app, String hostingType,
    2. 
  
  
  
  2.        String hostingNameStr, String abiOverride, String entryPoint, String[] entryPointArgs) {
    3. 
  
  
  
  3.        
    4. 
  
  
  
  4. ...
    5. 
  
  
  
  5.   Process.ProcessStartResult startResult = Process.start(entryPoint,
    6. 
  
  
  
  6.           app.processName, uid, uid, gids, debugFlags, mountExternal,
    7. 
  
  
  
  7.           app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet,
    8. 
  
  
  
  8.           app.info.dataDir, entryPointArgs);
    9. 
  
  
  
  9. ...
    10. 
  
  
  
  10. } 
    11.

下文中我們會(huì)看到，所有四大組件進(jìn)程的創(chuàng)建，都是調(diào)用這里的startProcessLocked這個(gè)方法而創(chuàng)建的。

對(duì)于每一個(gè)應(yīng)用進(jìn)程，在ActivityManagerService中，都有一個(gè)ProcessRecord與之對(duì)應(yīng)。這個(gè)對(duì)象記錄了應(yīng)用進(jìn)程的所有詳細(xì)狀態(tài)。

PS：對(duì)于ProcessRecord的內(nèi)部結(jié)構(gòu)，在下一篇文章中，我們會(huì)講解。

為了查找方便，對(duì)于每個(gè)ProcessRecord會(huì)存在下面兩個(gè)集合中。

  • 按名稱(chēng)和uid組織的集合：
 
 
 
    
  
  
  
  1. /**
    2. 
  
  
  
  2. * All of the applications we currently have running organized by name.
    3. 
  
  
  
  3. * The keys are strings of the application package name (as
    4. 
  
  
  
  4. * returned by the package manager), and the keys are ApplicationRecord
    5. 
  
  
  
  5. * objects.
    6. 
  
  
  
  6. */
    7. 
  
  
  
  7. final ProcessMap mProcessNames = new ProcessMap(); 
    8.
  • 按pid組織的集合：
 
 
 
    
  
  
  
  1. /**
    2. 
  
  
  
  2. * All of the processes we currently have running organized by pid.
    3. 
  
  
  
  3. * The keys are the pid running the application.
    4. 
  
  
  
  4. *
    5. 
  
  
  
  5. * 
    NOTE: This object is protected by its own lock, NOT the global
    6. 
  
  
  
  6. * activity manager lock!
    7. 
  
  
  
  7. */
    8. 
  
  
  
  8. final SparseArray mPidsSelfLocked = new SparseArray(); 
    9.

下面這幅圖小節(jié)了上文的這些內(nèi)容：

 
 
 
    
  
  
  
    2.

關(guān)于應(yīng)用組件

Processes and Threads 提到：

“當(dāng)某個(gè)應(yīng)用組件啟動(dòng)且該應(yīng)用沒(méi)有運(yùn)行其他任何組件時(shí)，Android 系統(tǒng)會(huì)使用單個(gè)執(zhí)行線程為應(yīng)用啟動(dòng)新的 Linux 進(jìn)程?！?/p>

因此，四大組件中的任何一個(gè)先起來(lái)都會(huì)導(dǎo)致應(yīng)用進(jìn)程的創(chuàng)建。下文我們就詳細(xì)看一下，它們啟動(dòng)時(shí)，各自是如何導(dǎo)致應(yīng)用進(jìn)程的創(chuàng)建的。

PS：四大組件的管理本身又是一個(gè)比較大的話題，限于篇幅關(guān)系，這里不會(huì)非常深入的講解，這里主要是講解四大組件與進(jìn)程創(chuàng)建的關(guān)系。

在應(yīng)用程序中，開(kāi)發(fā)者通過(guò)：

  • startActivity(Intent intent) 來(lái)啟動(dòng)Activity
  • startService(Intent service) 來(lái)啟動(dòng)Service
  • sendBroadcast(Intent intent) 來(lái)發(fā)送廣播
  • ContentResolver 中的接口來(lái)使用ContentProvider

這其中，startActivity，startService和sendBroadcast還有一些重載方法。

其實(shí)這里提到的所有這些方法，最終都是通過(guò)Binder調(diào)用到ActivityManagerService中，由其進(jìn)行處理的。

這里特別說(shuō)明一下：應(yīng)用進(jìn)程和ActivityManagerService所在進(jìn)程(即system_server進(jìn)程)是相互獨(dú)立的，兩個(gè)進(jìn)程之間的方法通常是不能直接互相調(diào)用的。

而Android系統(tǒng)中，專(zhuān)門(mén)提供了Binder框架來(lái)提供進(jìn)程間通訊和方法調(diào)用的能力。

調(diào)用關(guān)系如下圖所示：

Activity與進(jìn)程創(chuàng)建

在ActivityManagerService中，對(duì)每一個(gè)運(yùn)行中的Activity都有一個(gè)ActivityRecord對(duì)象與之對(duì)應(yīng)，這個(gè)對(duì)象記錄Activity的詳細(xì)狀態(tài)。

ActivityManagerService中的startActivity方法接受Context.startActivity的請(qǐng)求，該方法代碼如下：

 
 
 
    
  
  
  
  1. @Override
    2. 
  
  
  
  2. public final int startActivity(IApplicationThread caller, String callingPackage,
    3. 
  
  
  
  3.        Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
    4. 
  
  
  
  4.        int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) {
    5. 
  
  
  
  5.    return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
    6. 
  
  
  
  6.            resultWho, requestCode, startFlags, profilerInfo, bOptions,
    7. 
  
  
  
  7.            UserHandle.getCallingUserId());
    8. 
  
  
  
  8. } 
    9.

Activity的啟動(dòng)是一個(gè)非常復(fù)雜的過(guò)程。這里我們簡(jiǎn)單介紹一下背景知識(shí)：

  • ActivityManagerService中通過(guò)Stack和Task來(lái)管理Activity
  • 每一個(gè)Activity都屬于一個(gè)Task，一個(gè)Task可能包含多個(gè)Activity。一個(gè)Stack包含多個(gè)Task
  • ActivityStackSupervisor類(lèi)負(fù)責(zé)管理所有的Stack
  • Activity的啟動(dòng)過(guò)程會(huì)牽涉到：
    • Intent的解析
    • Stack，Task的查詢(xún)或創(chuàng)建
    • Activity進(jìn)程的創(chuàng)建
    • Activity窗口的創(chuàng)建
    • Activity的生命周期調(diào)度

Activity的管理結(jié)構(gòu)如下圖所示：

在Activity啟動(dòng)的***，會(huì)將前一個(gè)Activity pause，將新啟動(dòng)的Activity resume以便被用戶(hù)看到。

在這個(gè)時(shí)候，如果發(fā)現(xiàn)新啟動(dòng)的Activity進(jìn)程還沒(méi)有啟動(dòng)，則會(huì)通過(guò)startSpecificActivityLocked將其啟動(dòng)。整個(gè)調(diào)用流程如下：

  • ActivityManagerService.activityPaused =>
  • ActivityStack.activityPausedLocked =>
  • ActivityStack.completePauseLocked =>
  • ActivityStackSupervisor.ensureActivitiesVisibleLocked =>
  • ActivityStack.makeVisibleAndRestartIfNeeded =>
  • ActivityStackSupervisor.startSpecificActivityLocked =>
  • ActivityManagerService.startProcessLocked
  • ActivityStackSupervisor.startSpecificActivityLocked 關(guān)鍵代碼如下：
 
 
 
    
  
  
  
  1. void startSpecificActivityLocked(ActivityRecord r,
    2. 
  
  
  
  2.        boolean andResume, boolean checkConfig) {
    3. 
  
  
  
  3.    // Is this activity's application already running?
    4. 
  
  
  
  4.    ProcessRecord app = mService.getProcessRecordLocked(r.processName,
    5. 
  
  
  
  5.            r.info.applicationInfo.uid, true);
    6. 
  
  
  
  6. 
  
  
  
  7.    r.task.stack.setLaunchTime(r);
    8. 
  
  
  
  8. 
  
  
  
  9.    if (app != null && app.thread != null) {
    10. 
  
  
  
  10.        ...
    11. 
  
  
  
  11.    }
    12. 
  
  
  
  12. 
  
  
  
  13.    mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
    14. 
  
  
  
  14.            "activity", r.intent.getComponent(), false, false, true);
    15. 
  
  
  
  15. } 
    16.

這里的ProcessRecord app 描述了Activity所在進(jìn)程。

Service與進(jìn)程創(chuàng)建

Service的啟動(dòng)相對(duì)于Activity來(lái)說(shuō)要簡(jiǎn)單一些。

在ActivityManagerService中，對(duì)每一個(gè)運(yùn)行中的Service都有一個(gè)ServiceRecord對(duì)象與之對(duì)應(yīng)，這個(gè)對(duì)象記錄Service的詳細(xì)狀態(tài)。

ActivityManagerService中的startService方法處理Context.startServiceAPI的請(qǐng)求，相關(guān)代碼：

 
 
 
    
  
  
  
  1. @Override
    2. 
  
  
  
  2. public ComponentName startService(IApplicationThread caller, Intent service,
    3. 
  
  
  
  3.        String resolvedType, String callingPackage, int userId)
    4. 
  
  
  
  4.        throws TransactionTooLargeException {
    5. 
  
  
  
  5.    ...
    6. 
  
  
  
  6.    synchronized(this) {
    7. 
  
  
  
  7.        final int callingPid = Binder.getCallingPid();
    8. 
  
  
  
  8.        final int callingUid = Binder.getCallingUid();
    9. 
  
  
  
  9.        final long origId = Binder.clearCallingIdentity();
    10. 
  
  
  
  10.        ComponentName res = mServices.startServiceLocked(caller, service,
    11. 
  
  
  
  11.                resolvedType, callingPid, callingUid, callingPackage, userId);
    12. 
  
  
  
  12.        Binder.restoreCallingIdentity(origId);
    13. 
  
  
  
  13.        return res;
    14. 
  
  
  
  14.    }
    15. 
  
  
  
  15. } 
    16.

這段代碼中的mServices對(duì)象是ActiveServices類(lèi)型的，這個(gè)類(lèi)專(zhuān)門(mén)負(fù)責(zé)管理活動(dòng)的Service。

啟動(dòng)Service的調(diào)用流程如下：

  • ActivityManagerService.startService =>
  • ActiveServices.startServiceLocked =>
  • ActiveServices.startServiceInnerLocked =>
  • ActiveServices.bringUpServiceLocked =>
  • ActivityManagerService.startProcessLocked

ActiveServices.bringUpServiceLocked會(huì)判斷如果Service所在進(jìn)程還沒(méi)有啟動(dòng)，

則通過(guò)ActivityManagerService.startProcessLocked將其啟動(dòng)。相關(guān)代碼如下：

 
 
 
    
  
  
  
  1. // Not running -- get it started, and enqueue this service record
    2. 
  
  
  
  2. // to be executed when the app comes up.
    3. 
  
  
  
  3. if (app == null && !permissionsReviewRequired) {
    4. 
  
  
  
  4.   if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
    5. 
  
  
  
  5.           "service", r.name, false, isolated, false)) == null) {
    6. 
  
  
  
  6.       String msg = "Unable to launch app "
    7. 
  
  
  
  7.               + r.appInfo.packageName + "/"
    8. 
  
  
  
  8.               + r.appInfo.uid + " for service "
    9. 
  
  
  
  9.               + r.intent.getIntent() + ": process is bad";
    10. 
  
  
  
  10.       Slog.w(TAG, msg);
    11. 
  
  
  
  11.       bringDownServiceLocked(r);
    12. 
  
  
  
  12.       return msg;
    13. 
  
  
  
  13.   }
    14. 
  
  
  
  14.   if (isolated) {
    15. 
  
  
  
  15.       r.isolatedProc = app;
    16. 
  
  
  
  16.   }
    17. 
  
  
  
  17. }
    18.

這里的mAm 就是ActivityManagerService。

Provider與進(jìn)程創(chuàng)建

在ActivityManagerService中，對(duì)每一個(gè)運(yùn)行中的ContentProvider都有一個(gè)ContentProviderRecord對(duì)象與之對(duì)應(yīng)，這個(gè)對(duì)象記錄ContentProvider的詳細(xì)狀態(tài)。

開(kāi)發(fā)者通過(guò)ContentResolver中的insert, delete, update, query這些API來(lái)使用ContentProvider。在ContentResolver的實(shí)現(xiàn)中，無(wú)論使用這里的哪個(gè)接口，ContentResolver都會(huì)先通過(guò)acquireProvider 這個(gè)方法來(lái)獲取到一個(gè)類(lèi)型為IContentProvider的遠(yuǎn)程接口。這個(gè)遠(yuǎn)程接口對(duì)接了ContentProvider的實(shí)現(xiàn)提供方。

同一個(gè)ContentProvider可能同時(shí)被多個(gè)模塊使用，而調(diào)用ContentResolver接口的進(jìn)程只是ContentProvider的一個(gè)客戶(hù)端而已，真正的ContentProvider提供方是運(yùn)行自身的進(jìn)程中的，兩個(gè)進(jìn)程的通訊需要通過(guò)Binder的遠(yuǎn)程接口形式來(lái)調(diào)用。如下圖所示：

ContentResolver.acquireProvider 最終會(huì)調(diào)用到ActivityManagerService.getContentProvider中，該方法代碼如下：

 
 
 
    
  
  
  
  1. @Override
    2. 
  
  
  
  2. public final ContentProviderHolder getContentProvider(
    3. 
  
  
  
  3.        IApplicationThread caller, String name, int userId, boolean stable) {
    4. 
  
  
  
  4.    enforceNotIsolatedCaller("getContentProvider");
    5. 
  
  
  
  5.    if (caller == null) {
    6. 
  
  
  
  6.        String msg = "null IApplicationThread when getting content provider "
    7. 
  
  
  
  7.                + name;
    8. 
  
  
  
  8.        Slog.w(TAG, msg);
    9. 
  
  
  
  9.        throw new SecurityException(msg);
    10. 
  
  
  
  10.    }
    11. 
  
  
  
  11.    // The incoming user check is now handled in checkContentProviderPermissionLocked() to deal
    12. 
  
  
  
  12.    // with cross-user grant.
    13. 
  
  
  
  13.    return getContentProviderImpl(caller, name, null, stable, userId);
    14. 
  
  
  
  14. } 
    15.

而在getContentProviderImpl這個(gè)方法中，會(huì)判斷對(duì)應(yīng)的ContentProvider進(jìn)程有沒(méi)有啟動(dòng)，

如果沒(méi)有，則通過(guò)startProcessLocked方法將其啟動(dòng)。

Receiver與進(jìn)程創(chuàng)建

開(kāi)發(fā)者通過(guò)Context.sendBroadcast接口來(lái)發(fā)送廣播。ActivityManagerService.broadcastIntent 方法了對(duì)應(yīng)廣播發(fā)送的處理。

廣播是一種一對(duì)多的消息形式，廣播接受者的數(shù)量是不確定的。因此發(fā)送廣播本身可能是一個(gè)很耗時(shí)的過(guò)程(因?yàn)橐饌€(gè)通知)。

在ActivityManagerService內(nèi)部，是通過(guò)隊(duì)列的形式來(lái)管理廣播的：

  • BroadcastQueue 描述了一個(gè)廣播隊(duì)列
  • BroadcastRecord 描述了一個(gè)廣播事件

在ActivityManagerService中，如果收到了一個(gè)發(fā)送廣播的請(qǐng)求，會(huì)先創(chuàng)建一個(gè)BroadcastRecord接著將其放入BroadcastQueue中。

然后通知隊(duì)列自己去處理這個(gè)廣播。然后ActivityManagerService自己就可以繼續(xù)處理其他請(qǐng)求了。

廣播隊(duì)列本身是在另外一個(gè)線程處理廣播的發(fā)送的，這樣保證的ActivityManagerService主線程的負(fù)載不會(huì)太重。

在BroadcastQueue.processNextBroadcast(boolean fromMsg) 方法中真正實(shí)現(xiàn)了通知廣播事件到接受者的邏輯。在這個(gè)方法，如果發(fā)現(xiàn)接受者(即BrodcastReceiver)還沒(méi)有啟動(dòng)，便會(huì)通過(guò)ActivityManagerService.startProcessLocked 方法將其啟動(dòng)。相關(guān)如下所示：

 
 
 
    
  
  
  
  1. final void processNextBroadcast(boolean fromMsg) {
    2. 
  
  
  
  2.     ...
    3. 
  
  
  
  3.        // Hard case: need to instantiate the receiver, possibly
    4. 
  
  
  
  4.        // starting its application process to host it.
    5. 
  
  
  
  5. 
  
  
  
  6.        ResolveInfo info =
    7. 
  
  
  
  7.            (ResolveInfo)nextReceiver;
    8. 
  
  
  
  8.        ComponentName component = new ComponentName(
    9. 
  
  
  
  9.                info.activityInfo.applicationInfo.packageName,
    10. 
  
  
  
  10.                info.activityInfo.name);
    11. 
  
  
  
  11.     ...
    12. 
  
  
  
  12.        // Not running -- get it started, to be executed when the app comes up.
    13. 
  
  
  
  13.        if (DEBUG_BROADCAST)  Slog.v(TAG_BROADCAST,
    14. 
  
  
  
  14.                "Need to start app ["
    15. 
  
  
  
  15.                + mQueueName + "] " + targetProcess + " for broadcast " + r);
    16. 
  
  
  
  16.        if ((r.curApp=mService.startProcessLocked(targetProcess,
    17. 
  
  
  
  17.                info.activityInfo.applicationInfo, true,
    18. 
  
  
  
  18.                r.intent.getFlags() | Intent.FLAG_FROM_BACKGROUND,
    19. 
  
  
  
  19.                "broadcast", r.curComponent,
    20. 
  
  
  
  20.                (r.intent.getFlags()&Intent.FLAG_RECEIVER_BOOT_UPGRADE) != 0, false, false))
    21. 
  
  
  
  21.                        == null) {
    22. 
  
  
  
  22.            // Ah, this recipient is unavailable.  Finish it if necessary,
    23. 
  
  
  
  23.            // and mark the broadcast record as ready for the next.
    24. 
  
  
  
  24.            Slog.w(TAG, "Unable to launch app "
    25. 
  
  
  
  25.                    + info.activityInfo.applicationInfo.packageName + "/"
    26. 
  
  
  
  26.                    + info.activityInfo.applicationInfo.uid + " for broadcast "
    27. 
  
  
  
  27.                    + r.intent + ": process is bad");
    28. 
  
  
  
  28.            logBroadcastReceiverDiscardLocked(r);
    29. 
  
  
  
  29.            finishReceiverLocked(r, r.resultCode, r.resultData,
    30. 
  
  
  
  30.                    r.resultExtras, r.resultAbort, false);
    31. 
  
  
  
  31.            scheduleBroadcastsLocked();
    32. 
  
  
  
  32.            r.state = BroadcastRecord.IDLE;
    33. 
  
  
  
  33.            return;
    34. 
  
  
  
  34.        }
    35. 
  
  
  
  35. 
  
  
  
  36.        mPendingBroadcast = r;
    37. 
  
  
  
  37.        mPendingBroadcastRecvIndex = recIdx;
    38. 
  
  
  
  38.    }
    39. 
  
  
  
  39. } 
    40.

至此，四大組件的啟動(dòng)就已經(jīng)分析完了。

結(jié)束語(yǔ)

進(jìn)程管理本身是一個(gè)非常大的話題，本文講解了Android系統(tǒng)中進(jìn)程創(chuàng)建的相關(guān)內(nèi)容。進(jìn)程啟動(dòng)之后該如何管理就是下一篇文章要講解的內(nèi)容了。

敬請(qǐng)期待。


本文題目：Android系統(tǒng)中的進(jìn)程管理：進(jìn)程的創(chuàng)建
鏈接URL：http://m.5511xx.com/article/djgosoh.html