android4.3 framework之zygote深入

zygote本身是一個Native應用程序，在Android.mk中指定的名字是app_process，源碼位置：

framework/base/cmds/app_process/App_main.cpp

該代碼重要功能是由AppRuntime的start完成的，而這個函數使用的是基類AndroidRuntime的start，分析AndroidRuntime：

1、創建虛擬機，調用Jni創建。JNI_CreateJavaVM

2、給虛擬機注冊JNI函數，startReg

在zygoteinit.java中進入java世界，不再返回Native，

1、建立IPC通信服務端-registerZygoteSocket，創建一個服務端的socket

2、preloadClass和preloadresources,預加載類和資源，這裡預加載類有很多，加載preloaded-classes文件的內容，是導致android系統啟動慢的原因之一。preloadResources主要加載framework-res.apk中的資源

3、啟動system_server，創建了一個子進程處理java

4、runSelectLoopMode，這裡補充下socket的知識，socket中有兩種方式觸發讀數據，第一種：使用listen（）去監聽某個端口，再read從該端口讀數據，這種方式稱為阻塞式讀操作，因為當端口沒有數據時，read函數將一直等待，直到有數據才返回；第二種：使用select函數將需要監聽的文件描述符作為select函數的參數，當文件描述符中出現新的數據，自動觸發一個中斷，然後在中斷處理中去讀制定文件描述符的數據，這種方式為非阻塞式操作。而這裡使用的是第二種。而客戶端用ZygoteConnection來表示，在runOnce中處理。

對SystemServer進行分析：

通過Zygote.forkSystemServer函數fork出一個新的進程，setSignalHandler設置信號處理函數，使子進程SystemServer和Zygote一同開啟，一同結束。創建完進程後，執行handleSystemServerProcess，與Binder通信建立聯系。然後調用systemserver的main函數。fork的返回值大於0時，代表父進程，返回值等於0時，代表復制的子進程。調用invokeStaticMain函數拋出異常，在ZygoteInit的main中捕獲，調用systemserver的main函數。

總結：Zygote fork出進程SystemServer主要是為了調用main函數，加載libandroid_server.so 庫，init1是native函數，將調用線程加入Bindle通信中，init2單獨創建一個線程，啟動系統的各項服務

以一個Activity的啟動為例，zygote是怎麼處理的：

ActivityManagerService是由SystemServer創建的，假如通過startActivity啟動一個新的Activity，會先調用ActivityManagerService的startProcessLocked，最終調用zygoteSendArgsAndGeiPid打開和zygote通信的socket，並向該socket發送數據請求，此時，ZygoteInit中runSelectLoopMode正在用非阻塞的方式等待數據，有數據來時，調用runOnce處理，在runOnce中fork出一個新的進程，然後調用invokeStaticMain函數拋出異常，調用systemserver的main函數繼續等待請求下一次分裂。

注意：

創建虛擬機時，heapsize的限制，一般為最大值16MB或者32MB

開機速度優化：

1、ZygoteInit中加載了preloadclasses有1000多個類，耗費時間太多；

2、preloadresources對所有apk文件進行加載；

3、SystemServer創建的Service有很多，像AMS等等。

wait和notify：

synchronized(obj) {
		while(!condition) {
		obj.wait();
		}
	    obj.doSomething();
	}

當線程A獲得了obj鎖後，發現條件condition不滿足，無法繼續下一處理，於是線程A就wait()。當另一線程獲取到obj鎖後，改變條件，可以喚醒A

synchronized(obj) {

		condition = true;
		obj.notify();
	}