当前位置: 首页>移动开发>正文

androidstudio android butterknife zelezny失效 android:initorder

安卓架构图

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_android,第1张

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_Server_02,第2张

loader>kernel>native>framework>app

作为安卓的第一个进程init(pid =1),init将通过解析init.rc来陆续启动其他关键服务进程(ServiceManager,Zygote和SystemServer

如果你本地看不了源码的话,可以通过在线查看源码(https://www.androidos.net.cn/android/5.1.0_r3/xref/system/core/rootdir/init.rc)

/system/core/rootdir/init.rc

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_Server_03,第3张

healthd  电池服务进程

zygote   卵进程

media    多媒体进程

surfaceflinger  suface进程

drm  Digital Rights Managemen,也就是数字版权加密保护技术。

servicemanager 是一个Linux 程序。它在设备中的存储路径是 /system/bin/servicemanager/  所属的class 为core 根据该特性,这些进程会同时被启动或停止。cirtical 表示的是系统的关键进程-意味着如果进程不幸在4分钟内异常退出超出4次,这设备将重启并进入还原模式。当servicemanager 每次重启时,其他关键进程如Zygote,media,surfaceflinger等也会被restart。

zygote   卵进程

卵进程干什么用的?

其实Android中大部分的进程和系统进程都是通过Zygote 来生成的

接下来分析一下Zygote是如何启动的

其实跟servicemanager一样也是通过init进程解析init.rc脚本启动的。早期版本android中的Zygote的启动命令是在init.rc中,但是随着硬件的不断升级换代,Android系统不得不面对32位和64位机器同时存在的情况,因而对Zygote的启动也需要根据不同的情况区分对待。

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_Server_04,第4张

一般会有不同的Zygote的脚本,比如

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_加载_05,第5张

现以init.zygote64.rc为例查看一下相关代码

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_Server_06,第6张

从上面可以看出

servicename 为zygote

path:/system/bin/app_process64

属性-Xzygote /system/bin --zygote --start-system-server

Zygote 所属于的class 为main 而不是core 

从路径上来看他所在的进程名叫app_process64 而不像servicemanager 一样在一个独立的进程中。通过指定的--zygote参数,app_process可以识别用户是否需要启动zygote,接下来看一下这个app_process到底是什么?

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_加载_07,第7张

先看一下Android.mk文件

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_加载_08,第8张

上述是构建32位和64位系统的一个编译脚本。其中LOCAL_MULTILTB 表示同时编译32位和64位

接下来分析一下app_process的主函数就知道其内部逻辑

int main(int argc, char* const argv[])
 {
        ...
     AppRuntime runtime(argv[0], computeArgBlockSize(argc, argv));
       ...
     bool zygote = false;
     bool startSystemServer = false;
     bool application = false;
     String8 niceName;
     String8 className;    ++i;  // Skip unused "parent dir" argument.
     while (i < argc) {
         const char* arg = argv[i++];
         if (strcmp(arg, "--zygote") == 0) {    //判断当前进程是否用于承载zygote
             zygote = true;
             niceName = ZYGOTE_NICE_NAME;
         } else if (strcmp(arg, "--start-system-server") == 0) {  //是否需要启动system server
             startSystemServer = true;
         } else if (strcmp(arg, "--application") == 0) {
             application = true;
         } else if (strncmp(arg, "--nice-name=", 12) == 0) {
             niceName.setTo(arg + 12);
         } else if (strncmp(arg, "--", 2) != 0) {
             className.setTo(arg);
             break;
         } else {
             --i;
             break;
         }
     }
      ...
     if (zygote) {
         runtime.start("com.android.internal.os.ZygoteInit", args);
     } else if (className) {
         runtime.start("com.android.internal.os.RuntimeInit", args);
     } else {
         fprintf(stderr, "Error: no class name or --zygote supplied.\n");
         app_usage();
         LOG_ALWAYS_FATAL("app_process: no class name or --zygote supplied.");
         return 10;
     }
 }

这个函数用于解析app_process 时传入的参数,具体如下

--zygote: 表示当前进程用于承载zygote

--start-system-server:是否需要启动system server

--application: 启动进入独立的程序模式

--nice-name: 此进程的“别名”

对于非zygote的情况下,在上述参数的末尾会跟上main class 的名称,而后的其他参数则属于这个class 的主函数入参;对于zygote的情况,所有参数则会作为它的主函数入参使用。

init.rc指定了--zygote选项,因而app_process 接下来将启动"ZygoteInit“”并传入“start-system-server”,之后ZygoteInit会运行与java虚拟机上,为什么?

原因就是runtime这个变量实际是一个AndroidRuntime对象,其start函数源码如下

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_Server_09,第9张

void AndroidRuntime::start(const char* className, const Vector<String8>& options)
 {
  if (startVm(&mJavaVM, &env) != 0) { //启动虚拟机
         return;
     }
     onVmCreated(env);  //虚拟机启动后的回调
     ...
 }

当虚拟机成功启动,并进入ZygoteInit的执行中:

/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
  public static void main(String argv[]) {
         try {
             // Start profiling the zygote initialization.
             SamplingProfilerIntegration.start();            boolean startSystemServer = false;
             String socketName = "zygote";
             String abiList = null;
             for (int i = 1; i < argv.length; i++) {
                 if ("start-system-server".equals(argv[i])) {
                     startSystemServer = true;  //需要启动Sytem server
                 } else if (argv[i].startsWith(ABI_LIST_ARG)) {
                     abiList = argv[i].substring(ABI_LIST_ARG.length());
                 } else if (argv[i].startsWith(SOCKET_NAME_ARG)) {
                     socketName = argv[i].substring(SOCKET_NAME_ARG.length());
                 } else {
                     throw new RuntimeException("Unknown command line argument: " + argv[i]);
                 }
             }            if (abiList == null) {
                 throw new RuntimeException("No ABI list supplied.");
             }registerZygoteSocket(socketName);   //注册一个Socket
             EventLog.writeEvent(LOG_BOOT_PROGRESS_PRELOAD_START,
                 SystemClock.uptimeMillis());
             preload();  //预加载各类资源
             EventLog.writeEvent(LOG_BOOT_PROGRESS_PRELOAD_END,
                 SystemClock.uptimeMillis());            // Finish profiling the zygote initialization.
             SamplingProfilerIntegration.writeZygoteSnapshot();            // Do an initial gc to clean up after startup
             gc(); //执行gc操作            // Disable tracing so that forked processes do not inherit stale tracing tags from
             // Zygote.
             Trace.setTracingEnabled(false);            if (startSystemServer) {
                 startSystemServer(abiList, socketName);
             }            Log.i(TAG, "Accepting command socket connections");
             runSelectLoop(abiList);            closeServerSocket();
         } catch (MethodAndArgsCaller caller) {
             caller.run();
         } catch (RuntimeException ex) {
             Log.e(TAG, "Zygote died with exception", ex);
             closeServerSocket();
             throw ex;
         }
     }

Zygote主要完成两项工作

注册一个Socket

Zygote是”孵化器”,一旦有新程序需要运行时,系统会通过这个Socket(完整的名称为ANDROID_SOCKET_zygote)在第一时间通知“总管家”,并由它负责实际的进程孵化过程。

预加载各类资源

函数preload用于加载虚拟机运行时所需的各类资源,包括:

preloadClassed();  //负责加载和初始化常用的一些classed

preloadResources();//负责加载和初始化常用的一些资源文件

preloadOpenGL();//负责加载和初始化OpenGL

preloadSharedLibraries();//负责加载和初始化共享库

启动System Server

如果app_process的调用参数中带有“--start-system-server”,那么此时就会通过startSystemServer来启动System Server.

Zygote前期主要担任启动系统服务的工作,后期则又担当"程序孵化”的重任。但是Zygote只在init.rc中被启动一次,它是如何协调好这两项工作的关系呢?我们可以推断一下,上述的startSystemServer应该会新建一个专门的进程来承载系统服务的运行,而后app_process 所在的进程则转变为Zygote的“孵化器”守护进程。那么是不是这样子呢?

/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java

 private static boolean startSystemServer(String abiList, String socketName)
            throws MethodAndArgsCaller, RuntimeException {
        /* Hardcoded command line to start the system server */
        String args[] = {
            "--setuid=1000",
            "--setgid=1000",
            "--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,1032,3001,3002,3003,3006,3007",
            "--capabilities=" + capabilities + "," + capabilities,
            "--runtime-init",
            "--nice-name=system_server",
            "com.android.server.SystemServer",
        };
        ZygoteConnection.Arguments parsedArgs = null;
        int pid;
        try {
            parsedArgs = new ZygoteConnection.Arguments(args);
            ZygoteConnection.applyDebuggerSystemProperty(parsedArgs);
            ZygoteConnection.applyInvokeWithSystemProperty(parsedArgs);

            /* Request to fork the system server process */
            pid = Zygote.forkSystemServer(
                    parsedArgs.uid, parsedArgs.gid,
                    parsedArgs.gids,
                    parsedArgs.debugFlags,
                    null,
                    parsedArgs.permittedCapabilities,
                    parsedArgs.effectiveCapabilities);
        } catch (IllegalArgumentException ex) {
            throw new RuntimeException(ex);
        }

        /* For child process */
        if (pid == 0) {
            if (hasSecondZygote(abiList)) {
                waitForSecondaryZygote(socketName);
            }

            handleSystemServerProcess(parsedArgs);
        }

        return true;
    }

上述代码段出现了我们熟悉的fork流程-forkSystemServer 在内部利用UNIX的fork机制创建了一个新的进程;而这个“新生儿”(即 pid ==0 分支)会在随后的执行过程中通过handleSystemServerProcess来启动各个支撑系统运行的System Server

在跟踪System Server 的具体启动过程之前,我们先来为Zygote接下来的工作做一个分析,startSystemServer中并没有为父进程专门开辟一个代码分支。因而这个函数最后会通过return ture 而返回到Zygoteinit 的主函数中。紧随其后的语就是

runSelectLoop(abiList);

查看源码:

static final int GC_LOOP_COUNT = 10;

 private static void runSelectLoop(String abiList) throws MethodAndArgsCaller {
        ArrayList<FileDescriptor> fds = new ArrayList<FileDescriptor>();
        ArrayList<ZygoteConnection> peers = new ArrayList<ZygoteConnection>();
        FileDescriptor[] fdArray = new FileDescriptor[4];

sServerSocket.getFileDescriptor());
        peers.add(null);  //添加null是为了保持fds 和peers的一致性

        int loopCount = GC_LOOP_COUNT; 设定多少次循环才调用垃圾回收函数gc(),
        while (true) {  //确实是死循环
            int index; 
            if (loopCount <= 0) {
                gc();  //gc操作
                loopCount = GC_LOOP_COUNT;
            } else {
                loopCount--;
            }

            try {
                fdArray = fds.toArray(fdArray);
                index = selectReadable(fdArray);
            } catch (IOException ex) {
                throw new RuntimeException("Error in select()", ex);
            }

            if (index < 0) { //出错的情况
                throw new RuntimeException("Error in select()");
            } else if (index == 0) { //有新的连接请求
                ZygoteConnection newPeer = acceptCommandPeer(abiList);
                peers.add(newPeer);
                fds.add(newPeer.getFileDescriptor());
            } else {  //已建立的连接中有客户端发过来的数据需要处理
                boolean done;
                done = peers.get(index).runOnce();

                if (done) {
                    peers.remove(index);
                    fds.remove(index);
                }
            }
        }
    }

从程序中可以看到,runSelectLoop的主体的确是一个while死循环,它将作为zygote的守护体存在,因为zygote此时运行在虚拟机环境中,所以它需要考虑垃圾回收的问题。不过这是一项非常耗时的操作,如果操作频繁,每次收回的垃圾并不会很多,那么就得不偿失。所以上述函数中设定了GC_LOOP_COUNT 为10,意味着while每循环十次才会调用一次gc()。那么while执行一轮都完成了那些工作呢?

我们从sServerSocket.getFileDescriptor() 获取到的是前面通过registerZygoteSocket 创建的Server Socket的文件描述符,它会被添加到一个ArrayList<FileDescriptor> 类型的fds变量中。这同时也意味着zygote中不光只有一个socket产生。具体而言,while循环中会先通过如下两个语句来判断当前哪个fd处于可读状态

fdArray = fds.toArray(fdArray);
index = selectReadable(fdArray);

当fds这个ArrayList指示的某个文件有可读数据时,返回的index值就代表此文件对应的file descriptor在队列中的序列。另外,这个函数还有一个特殊的返回值:0.。因为fds中的第一个元素为Zygote的Server Socket,所以index为0代表了有新的连接请求。这和网络连接中的Socket概念是一致的。

index = 0

此时我们需要通过acceptCommandPeer 来接受来自客户端的连接,产生一个新的ZygoteConnection,然后分别更新peers 和fds.为了保证这两个列表中的对象序列号保持一致,可以看到peers在初始化时专门添加了一个null,对应的是Zygote Server Socket这个“监听者”

index > 0

此时说明已经建立的Socket连接中有来自客户端的数据需要处理,完成具体的工作的是runOnce,下面我们详细分析一下这个函数:

/frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java

 boolean runOnce() throws ZygoteInit.MethodAndArgsCaller {

        String args[];
        Arguments parsedArgs = null;
        FileDescriptor[] descriptors;
        ...
        try {                 
            checkTime(startTime, "zygoteConnection.runOnce: preForkAndSpecialize");
            pid = Zygote.forkAndSpecialize(parsedArgs.uid, parsedArgs.gid, parsedArgs.gids,
                    parsedArgs.debugFlags, rlimits, parsedArgs.mountExternal, parsedArgs.seInfo,
                    parsedArgs.niceName, fdsToClose, parsedArgs.instructionSet,
                    parsedArgs.appDataDir);
            checkTime(startTime, "zygoteConnection.runOnce: postForkAndSpecialize");
        } catch (IOException ex) {
            logAndPrintError(newStderr, "Exception creating pipe", ex);
        } catch (ErrnoException ex) {
            logAndPrintError(newStderr, "Exception creating pipe", ex);
        } catch (IllegalArgumentException ex) {
            logAndPrintError(newStderr, "Invalid zygote arguments", ex);
        } catch (ZygoteSecurityException ex) {
            logAndPrintError(newStderr,
                    "Zygote security policy prevents request: ", ex);
        }

        try {
            if (pid == 0) {
                // in child
                IoUtils.closeQuietly(serQverPipeFd);
                serverPipeFd = null;
                handleChildProc(parsedArgs, descriptors, childPipeFd, newStderr);

                // should never get here, the child is expected to either
                // throw ZygoteInit.MethodAndArgsCaller or exec().
                return true;
            } else {
                // in parent...pid of < 0 means failure
                IoUtils.closeQuietly(childPipeFd);
                childPipeFd = null;
                return handleParentProc(pid, descriptors, serverPipeFd, parsedArgs);
            }
        } finally {
            IoUtils.closeQuietly(childPipeFd);
            IoUtils.closeQuietly(serverPipeFd);
        }
    }

有两点需要重点注意:

创建承载应用程序的新进程

这是在意料之中的,zygote需要为每个新启动的应用程序生成自己独立的进程。不过runOnce中并没有直接使用fork来完成这一工作,而是调用了forkAndSpecialize,稍后会分析这个函数的实现。另外,新的创建的进程中一定需要运行应用程序本身的代码,这一部分工作是在handlerChildProc中展开的。

父进程的“扫尾”工作

执行完上述的任务之后,父进程还需要做一些清尾的工作才算“大功告成”。包括:将子进程加入进程组;正确关闭文件;调用返回结果值等。

Specialize的字面意思是“专门化”,表达了forkAndSpecialize在“孵化”的同时也把它转变为Android应用程序的目标。函数forkAndSpecialize的处理分为3个阶段,即preFork,nativeForkAndSpecialize 以及postForkCommon.

/frameworks/base/core/java/com/android/internal/os/Zygote.java 
 public static int forkAndSpecialize(int uid, int gid, int[] gids, int debugFlags,
          int[][] rlimits, int mountExternal, String seInfo, String niceName, int[] fdsToClose,
          String instructionSet, String appDataDir) {
        long startTime = SystemClock.elapsedRealtime();
        VM_HOOKS.preFork();
        checkTime(startTime, "Zygote.preFork");
        int pid = nativeForkAndSpecialize(
                  uid, gid, gids, debugFlags, rlimits, mountExternal, seInfo, niceName, fdsToClose,
                  instructionSet, appDataDir);
        checkTime(startTime, "Zygote.nativeForkAndSpecialize");
        VM_HOOKS.postForkCommon();
        checkTime(startTime, "Zygote.postForkCommon");
        return pid;
    }

接下来直接分析preForkZygote中对应的实现

/art/runtime/native/dalvik_system_ZygoteHooks.cc
static jlong ZygoteHooks_nativePreFork(JNIEnv* env, jclass) {
  Runtime* runtime = Runtime::Current();
  CHECK(runtime->IsZygote()) << "runtime instance not started with -Xzygote";

  runtime->PreZygoteFork();

  // Grab thread before fork potentially makes Thread::pthread_key_self_ unusable.
  Thread* self = Thread::Current();
  return reinterpret_cast<jlong>(self);
}

这里的Runtime实例具体而言指的是Zygote进程中的运行环境,  runtime->PreZygoteFork()又会间接的调用Headp::PreZygoteFork,从而完全堆空间的初始操作。

函数nativeForkAndSpecialize 是一个native方法,具体对应的实现是com_android_internal_os_Zygote_nativeForkAndSpecialize ,后者则又进一步调用了ForkAndSpecializeCommon

/frameworks/base/core/jni/com_android_internal_os_Zygote.cpp
// Utility routine to fork zygote and specialize the child process.
static pid_t ForkAndSpecializeCommon(JNIEnv* env, uid_t uid, gid_t gid, jintArray javaGids,
                                     jint debug_flags, jobjectArray javaRlimits,
                                     jlong permittedCapabilities, jlong effectiveCapabilities,
                                     jint mount_external,
                                     jstring java_se_info, jstring java_se_name,
                                     bool is_system_server, jintArray fdsToClose,
                                     jstring instructionSet, jstring dataDir) {
  uint64_t start = MsTime();
  SetSigChldHandler();
  ckTime(start, "ForkAndSpecializeCommon:SetSigChldHandler");

  pid_t pid = fork();   //这里才是真正孵化出一个新进程

  if (pid == 0) {//子进程中
    ...
    env->CallStaticVoidMethod(gZygoteClass, gCallPostForkChildHooks, debug_flags,
                              is_system_server ? NULL : instructionSet);
    ckTime(start, "ForkAndSpecializeCommon:PostForkChildHooks returns");
    ...
  } else if (pid > 0) {
    // the parent process 这里什么也不做因为父进程有处理
  }
  return pid;
}
}  

这个函数首先会fork一个新进程,并在pid == 0这一分支中为孵化的进程完成一系列初始化操作,而后执行CallStaticVoidMethod.其中gZygoteClass对应的是“com/android/internal/os/Zygote”,而gPostForkChildHooks则是Zygote这个类中的成员变量函数callPostForkChildHooks --从名称可以看出用于执行孵化后的一些处理工作。ForkAndSpecializeCommon也还没有设计与应用程序相关的具体业务,这部分工作会由runOnce中的handleChildProc 来完成,核心代码如下:

/frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java
 private void handleChildProc(Arguments parsedArgs,
            FileDescriptor[] descriptors, FileDescriptor pipeFd, PrintStream newStderr)
            throws ZygoteInit.MethodAndArgsCaller {
        ...
        if (parsedArgs.niceName != null) {//子进程的别名
            Process.setArgV0(parsedArgs.niceName);
        }

        if (parsedArgs.runtimeInit) {
           ...
        } else {//应用程序的ActivityThread将在这里执行
            String className;
            try {
                className = parsedArgs.remainingArgs[0];
            } catch (ArrayIndexOutOfBoundsException ex) {
                logAndPrintError(newStderr,
                        "Missing required class name argument", null);
                return;
            }

            String[] mainArgs = new String[parsedArgs.remainingArgs.length - 1];
            System.arraycopy(parsedArgs.remainingArgs, 1,
                    mainArgs, 0, mainArgs.length);  //className 主函数参数

            if (parsedArgs.invokeWith != null) {      //invokeWith的情况
                WrapperInit.execStandalone(parsedArgs.invokeWith,
                        parsedArgs.classpath, className, mainArgs);
            } else {
                ClassLoader cloader;
                if (parsedArgs.classpath != null) {
                    cloader = new PathClassLoader(parsedArgs.classpath,
                            ClassLoader.getSystemClassLoader());
                } else {
                    cloader = ClassLoader.getSystemClassLoader();
                }

                try { //执行main函数
                    ZygoteInit.invokeStaticMain(cloader, className, mainArgs);
                } catch (RuntimeException ex) {
                    logAndPrintError(newStderr, "Error starting.", ex);
                }
            }
        }
    }

这个函数的任务用一句话来概括,就是找到并执行目标进程的入口函数。Android系统中所有的应用程序理论上都是由Zygote启动的;而且我们不难发现Zygote会为新启动的应用fork一个进程。不过和传统的内核中的fork+exec的做法不同的地方是,Zygote中并不会执行exec().。这在某些情况下就会造成一些障碍,比如无法使用valgrind来检测程序的内存泄漏情况。为了响应开发人员的类似需求,Android系统特别提供了一种Wrapper实现,并通过parsedArgs.invokeWith来加以控制

handleChildProc这个函数中,最重要的参数之一是className。可以看到,handleChildProc会把className对应的类加载到内存中,然后执行其中的main函数。那么这个className具体指的是什么呢?

其实是后续ActivityManagerServer,它会向Zygote发起的一个创建新进程的请求,代码如下

/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
  private final void startProcessLocked(ProcessRecord app, String hostingType,
            String hostingNameStr, String abiOverride, String entryPoint, String[] entryPointArgs) {
  Process.ProcessStartResult startResult = Process.start(entryPoint,
                    app.processName, uid, uid, gids, debugFlags, mountExternal,
                    app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet,
                    app.info.dataDir, entryPointArgs);//这些参数将被转化为Arguments中的成员变量
                    ...
}

Process的字面意思虽然是进程,但其实它属于“进程类”,或者成为“进程管家”会贴切些。Process.jar显然是去启动一个新的进程来继承业务,而函数的第一个参数entryPoint,即我们在handleChildProc中看到的className。这是因为ActivityManagerService传递过来的字符串形式列表会被Arguments.paseArgs解析成Arguments中的各个成员变量,

各成员变量

  参数格式    

对应的成员变量

“--setuid=”

uid

"--setgid="

gid

"--target--sdk-version="

targetSdkVersion

"--runtime-init"

runtimeInit

"-classpath"

classPath

"--nice-name="

nicename

剩余的参数

remainingArgs

 

现在问题转化为,ActivityManagerService 中的entryPoint是如何得来的呢?它的来源简单来讲就是下面的这个语句。

if (entryPoint == null) entryPoint = "android.app.ActivityThread";

换句话说,Zygote中主动执行的类是ActivityThread,这同时也是我们熟知的Acitivity应用程序的“主线程”:

  /frameworks/base/core/java/android/app/ActivityThread.java
  public static void main(String[] args) {
        ...
        Looper.prepareMainLooper();

        ActivityThread thread = new ActivityThread();
        thread.attach(false);

        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        ...
        Looper.loop();
        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

到目前为止,我们已经分析了Zygote作为守护进程时,如何为Android应用程序的启动而服务的。接下来要了解引导系统各个重要服务的启动过程。

从前面可以知道,System Server的启动是在startSystemServer中完成的。Zygote首先会利用Zygote.forkSystemServer来孵化处一个子进程,然后在pid==0的分支中调用handleSystemServerProcess,后者在函数的末尾又会进一步调用RuntimeInit.zygoteInit:

/frameworks/base/core/java/com/android/internal/os/RuntimeInit.java
  public static final void zygoteInit(int targetSdkVersion, String[] argv, ClassLoader classLoader)
            throws ZygoteInit.MethodAndArgsCaller {
        ...
        commonInit();
        nativeZygoteInit();

        applicationInit(targetSdkVersion, argv, classLoader);
    }

函数zygoteInit通过3个方面来完成初始化,分别是:

commonInit

通用部分的初始化,包括设置默认的uncaught exeception handler;为HttpURLConnection准备好默认的Http User_Agent;开启trace模式(只在emulator下才有必要)等。

nativeZygoteInit

这是一个本地初始化函数,也是zygoteInit中的重点,我们稍后会做重点分析。

applicationInit

这个函数的声明为:private static void applicationInit(int targetSdkVersion, String[] argv, ClassLoader classLoader);从中可以看出它是程序运行的“起点”。在我们这个场景中,程序指的是SystemServers,而"入口"是什么呢?这就和第二个参数argv有关系.。这个Sting[]实际上包含了两个重要的成员变量,即startClass 和startArgs。而这两个变量的赋值可以追溯到startSystemServer中,具体代码如下:
String args[] = {
            "--setuid=1000",
            "--setgid=1000",
            "--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,1032,3001,3002,3003,3006,3007",
            "--capabilities=" + capabilities + "," + capabilities,
            "--runtime-init",
            "--nice-name=system_server",
            "com.android.server.SystemServer",
        };

换句话说,startClass 对应的就是com.android.server.SystemServer。因而applicationInit最终将调用main@SystemServer:

public static void main(String[] args){

       new SystemServer().run();

}

经过上面的初始化后,程序现在会有两个分支,其一是nativeZygoteInit 主导的本地系统服务的启动:另一个则是applicationInit负责的java层系统服务的启动。

(1)本地系统服务的启动

在JNI机制中,Native函数在java层会有一个声明,然后在本地层得到真正的实现。那么当我们调用了java层的函数后,系统是如何找到Native中与之对应的函数的呢?通常情况下,Native中的C++文件名称是以java层的package为基础的,如java层的包名为com.android.internal.XX,那么其对应的JNI层文件则是com_android_internal_XX。不过这种对应关系并不是绝对不变的,可以根据开发人员的需求进行调整。譬如我们上面讲的ZygoteInit所在的java包是com.android.initernal,而实际上JNI的实现则为AndroidRuntime.cpp。

AndroidRuntime 表明这个class的任务是“负责Android的运行时环境”。当我们调用了nativeZygoteInit后,实际上是执行了 com_android_internal_os_RuntimeInit_nativeZygoteInit@AndroidRuntime.cpp,代码如下:

/frameworks/base/core/jni/AndroidRuntime.cpp
static void com_android_internal_os_ZygoteInit_nativeZygoteInit(JNIEnv* env, jobject clazz)
{
    gCurRuntime->onZygoteInit();
}

全局变量gCurRuntime是一个AndroidRuntime的对象,结合之前能想象到AndroidRuntime是一个父类,真正的实现则在App_main.cpp中的AppRuntime。当我们新建AppRuntime对象时,它的父类的构造函数会被调用,并为gCurRuntime赋值。上述的onZygoteInit也在这个App_main.cpp文件中,如下所示:

 /frameworks/base/cmds/app_process/app_main.cpp
 virtual void onZygoteInit()
    {
        sp<ProcessState> proc = ProcessState::self();
        ALOGV("App process: starting thread pool.\n");
        proc->startThreadPool();
    }

上面这段代码是Binder机制中的重要组成部分,其中startThreadPool将开启Binder线程池以保证其他进程可以正确访问到Zygote所提供的服务。Zyogte通过JNI和回调的方式非常巧妙地把本地层和java层,SystemServer和App process关联起来了。

(2)java层系统服务的启动

java层的系统服务比较多,它们各司其职,缺一不可。我们知道,Zygote会为System Server的运行启动和初始化虚拟机,并通过入口main@System.java 开启 “系统服务之旅”。不过main函数只起到“门”的作用,它又会直接调用SystemServer().run(),后者才是真正实现服务的地方:

private void run() {
        try {            
            SystemProperties.set("persist.sys.dalvik.vm.lib.2", VMRuntime.getRuntime().vmLibrary());
            ...
            // Mmmmmm... more memory!
            VMRuntime.getRuntime().clearGrowthLimit();       

            // Prepare the main looper thread (this thread).
            android.os.Process.setThreadPriority(
                android.os.Process.THREAD_PRIORITY_FOREGROUND);
            android.os.Process.setCanSelfBackground(false);
            Looper.prepareMainLooper();  //准备主循环体
            Looper.getMainLooper().setSlowLogThresholdMs(
                    SLOW_DISPATCH_THRESHOLD_MS, SLOW_DELIVERY_THRESHOLD_MS);

            // Initialize native services.
            System.loadLibrary("android_servers");  //加载本地服务库        
            ...
            // Initialize the system context.
            createSystemContext();

            // Create the system service manager.
            mSystemServiceManager = new SystemServiceManager(mSystemContext);
            mSystemServiceManager.setStartInfo(mRuntimeRestart,
                    mRuntimeStartElapsedTime, mRuntimeStartUptime);
            LocalServices.addService(SystemServiceManager.class, mSystemServiceManager);
            // Prepare the thread pool for init tasks that can be parallelized
            SystemServerInitThreadPool.get();
        } finally {
            traceEnd();  // InitBeforeStartServices
        }

        // Start services.
        try {
            traceBeginAndSlog("StartServices");
            startBootstrapServices();
            startCoreServices();
            startOtherServices();
            SystemServerInitThreadPool.shutdown();
        } catch (Throwable ex) {
            Slog.e("System", "******************************************");
            Slog.e("System", "************ Failure starting system services", ex);
            throw ex;
        } finally {
            traceEnd();
        }

        StrictMode.initVmDefaults(null);
        // Loop forever.
        Looper.loop();  //进入死循环,直到设备关机
        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

System Server 在启动前首先需要做很多初始化设置,包括将VM的版本记录到系统变量中,设置线程优先级,设置堆的使用率等。我们知道,Android系统服务会被分为两类,其一就是java层的,其二就是本地层的。后者具体事由System.loadLibrary("android_servers")实现的

通过以上我们可以看到app_process就是系统服务的“根据地”。它在init进程的帮助下,通过Zygote逐步建立起各SystemServer的运行环境,继而为上层的“繁殖壮大”提供“土壤环境”。

androidstudio android butterknife zelezny失效 android:initorder,androidstudio android butterknife zelezny失效 android:initorder_加载_10,第10张

流程图转自:()

全文借鉴《Android内核设计思想》

后续分析SystemServer以及ActivityManagerService

 

 


https://www.xamrdz.com/mobile/4hw1937293.html

相关文章: