forkandroid

1. Android 性能優化之啟動加速

當點擊app的啟動圖標時，安卓系統會從Zygote進程中fork創建出一個新的進程分配給該應用，之後會依次創建和初始化Application類、創建MainActivity類、載入主題樣式Theme中的

windowBackground等屬性設置給MainActivity以及配置Activity層級上的一些屬性、再inflate布局、當onCreate/onStart/onResume方法都走完了後最後才進行contentView的measure/layout/draw顯示在界面上，所以直到這里，

應用的第一次啟動才算完成，這時候我們看到的界面也就是所說的第一幀。所以，總結一下，應用的啟動流程如下：

Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量布局繪制顯示在界面上。

1、冷啟動：當啟動應用時，後台沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用，這個啟動方式就是冷啟動。
2、熱啟動：當啟動應用時，後台已有該應用的進程（例：按back鍵、在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這個方式叫熱啟動

1、冷啟動：冷啟動因為系統會重新創建一個新的進程分配給它，所以會先創建和初始化Application類，再創建和初始化MainActivity類（包括一系列的測量、布局、繪制），最後顯示在界面上。
2、熱啟動：熱啟動因為會從已有的進程中來啟動，所以熱啟動就不會走Application這步了，而是直接走MainActivity（包括一系列的測量、布局、繪制），所以熱啟動的過程只需要創建和初始化一個MainActivity就行了，而不必創建和初始化Application

黑白屏產生原因：當我們在啟動一個應用時，系統會去檢查是否已經存在這樣一個進程，如果不存在，系統的服務會先檢查startActivity 中的intent 的信息，然後在去創建進程，最後啟動Acitivy，即冷啟動。

而啟動出現白黑屏的問題，就是在這段時間內產生的。系統在繪制頁面載入布局之前，首先會初始化窗口（Window），而在進行這一步操作時，系統會根據我們設

置的Theme 來指定它的Theme 主題顏色，我們在Style 中的設置就決定了顯示的是白屏還是黑屏。

1.Application 優化(懶載入,延時載入)

2.UI效果，背景圖

3.fragment的懶載入

4.延時載入

2. Android 四大組件 - 進程的 fork 創建過程

相關文章鏈接：

1.AndroidFramework-學習啟動篇

2.Android系統服務-AMS的啟動過程

3.Android系統服務-PMS的啟動過程

4.AndroidFramework-開機啟動Zygote進程

相關源碼文件：

無論是點擊桌面圖標調用startActivitySafely還是直接調用startActivity在源碼中都是調用的startActivityForResult方法。由於Activity的啟動流程有些復雜，因此本文先從進程的fork創建過程來入手分析。

activity的啟動過程中會賀粗掉用startSpecificActivityLocked方法，首先會根據processName和uid來判斷進程是否有創建，如果沒有創禪睜鎮建進程則需要先創早高建進程，processName默認情況是包名，uid是由PMS在啟動的過程中解析計算好的，其具體的計算賦值過程可以參考《Android系統服務-PMS的啟動過程》

如果當前進程沒有創建，則調用Process的startViaZygote方法去創建進程，就是向Zygote進程發起創建進程的請求，這里跨進程通信採用的是Socket套接字的方式。注意，其中有一個重要的參數entryPoint是android.app.ActivityThread。

Zygote啟動後會循環處理客戶端發過來的請求，當接收到請求後會調用ZygoteConnection的runOnce方法，解析到客戶端的參數後會調用native底層的fork的方法，至此進程才真正創建完畢。進程fork完畢後，Zygote進程會將信息返回給AMS，新創建的進程會調用commonInit、nativeZygoteInit和applicationInit三個核心方法：

進程fork後會執行ActivityThread的main方法，該方法又會向AMS發起綁定IApplicationThread請求，這里IApplicationThread是一個可以跨進程通信的Binder對象，然後AMS又會調用IApplicationThread的bindApplication方法去創建應用的Application，等應用的Application創建完畢後，才會真正的開始創建啟動Activity。

視頻地址：https://pan..com/s/1tB9hDc_6Aw_L0pgtbAU8Sw

視頻密碼：6fzw

3. android開發中跨進程通信有幾種方式

Android進程間通信的幾種方式 定義多進程
第一：Android應用中使用多進程只有一個辦法（用NDK的fork來做除外），就是在AndroidManifest.xml中聲明組件時，用android:process屬性來指定。
不知定process屬性，則默認運行在主進程中，主進程名字為包名。
android:process = package:remote，將運行在package:remote進程中，屬於全局進程，其他具有相同shareUID與簽名的APP可以跑在這個進程中。
android:process = :remote ，將運行在默認包名:remote進程中，而且是APP的私有進程，不允許其他APP的組件來訪問。
第二：多進程引發的問題
靜態成員和單例失效：每個進程保持各自的靜態成員和單例，相互獨立。
線程同步機制失效：每個進程有自己的線程鎖。
SharedPreferences可靠性下降：不支持並發寫，會出現臟數據。
Application多次創建：不同進程跑在不同虛擬機，每個虛擬機啟動會創建自己的Application，自定義Application時生命周期會混亂。
綜上，不同進程擁有各自獨立的虛擬機，Application，內存空間，由此引發一系列問題。
第三： 進程間通信
Bundle/Intent傳遞數據：
可傳遞基本類型，String，實現了Serializable或Parcellable介面的數據結構。Serializable是java的序列化方法，Parcellable是Android的序列化方法，前者代碼量少（僅一句），但I/O開銷較大，一般用於輸出到磁碟或網卡；後者實現代碼多，效率高，一般用戶內存間序列化和反序列化傳輸。
文件共享：
對同一個文件先後寫讀，從而實現傳輸，Linux機制下，可以對文件並發寫，所以要注意同步。順便一提，Windows下不支持並發讀或寫。
Messenger：
Messenger是基於AIDL實現的，服務端（被動方）提供一個Service來處理客戶端（主動方）連接，維護一個Handler來創建Messenger，在onBind時返回Messenger的binder。
雙方用Messenger來發送數據，用Handler來處理數據。Messenger處理數據依靠Handler，所以是串列的，也就是說，Handler接到多個message時，就要排隊依次處理。
AIDL：
AIDL通過定義服務端暴露的介面，以提供給客戶端來調用，AIDL使伺服器可以並行處理，而Messenger封裝了AIDL之後只能串列運行，所以Messenger一般用作消息傳遞。
通過編寫aidl文件來設計想要暴露的介面，編譯後會自動生成響應的java文件，伺服器將介面的具體實現寫在Stub中，用iBinder對象傳遞給客戶端，客戶端bindService的時候，用asInterface的形式將iBinder還原成介面，再調用其中的方法。
ContentProvider：
系統四大組件之一，底層也是Binder實現，主要用來為其他APP提供數據，可以說天生就是為進程通信而生的。自己實現一個ContentProvider需要實現6個方法，其中onCreate是主線程中回調的，其他方法是運行在Binder之中的。自定義的ContentProvider注冊時要提供authorities屬性，應用需要訪問的時候將屬性包裝成Uri.parse("content://authorities")。還可以設置permission，readPermission，writePermission來設置許可權。 ContentProvider有query，delete，insert等方法，看起來貌似是一個資料庫管理類，但其實可以用文件，內存數據等等一切來充當數據源，query返回的是一個Cursor，可以自定義繼承AbstractCursor的類來實現。
Socket：
學過計算機網路的對Socket不陌生，所以不需要詳細講述。只需要注意，Android不允許在主線程中請求網路，而且請求網路必須要注意聲明相應的permission。然後，在伺服器中定義ServerSocket來監聽埠，客戶端使用Socket來請求埠，連通後就可以進行通信。

4. Android後台進程保活方案

思想： 使用 Linux 中的 fork 機制創建 Native 進程，在 Native 進程中監控主進程的存活，當主進程掛掉後，在 Native 進程中立即對主進程進行拉活。

原理： 在 Android 中所有進程和系統組件的生命周期受 ActivityManagerService 的統一管理。Android5.0以下通過 Linux 的 fork 機制創建的進程為純 Linux 進程，其生命周期不受 Android 的管理。

該方案主要適用於 Android5.0 以下版本手機。

該方案不受 forceclose 影響，被強制停止的應用依然可以被拉活，在 Android5.0 以下版本拉活效果非常好。
詳情

對於 Android5.0 以上手機，系統雖然會將native進程內的所有進程都殺死，這里其實就是系統「依次」殺死進程時間與拉活邏輯執行時間賽跑的問題，如果可以跑的比系統邏輯快，依然可以有效拉起。在 某些 Android 5.0 以上機型有效。
詳情

https://github.com/Marswin/MarsDaemon

作者5.0以下系統用一個java進程和一個fork出來的純native進程雙管道互鎖監聽對方的狀態，無論哪個被殺後都拉起第三個進程，第三個進程來拉活常駐進程，實現拉活。
5.0以上同一進程組的進程會被同時殺死，所以5.0以上使用雙java進程在native層互鎖文件實現監聽，但任務管理器會在短時間內殺死所有進程，只能用反射提前初始化pacel，在進程被殺的時候和系統搶那幾十毫秒的時間發送一個拉活的廣播。用4個文件來讓兩個進程實現互鎖來做監聽，但實際效果很一般，測試了幾個5.0以上的國產機型都不行，效果是根本監聽不到進程被殺，目測原因是當任務管理器查殺進程的時候將所有的進程都掛起了，隨後全部殺掉，並在一段時間內禁止進程啟動。

PersistedJobService.java

BootReceiver.java靜態注冊BroadcastReceiver

注冊，開機，網路切換、拍照、拍視頻時候，利用系統產生的廣播也能喚醒app，不過Android N已經將這三種廣播取消了

常用的拉活許可權

BackgroundService.java
WakeLock

作為前台應用運行，提高應用存活幾率

service被關掉後自動啟動

START_STICKY
如果系統在onStartCommand返回後被銷毀，系統將會重新創建服務並依次調用onCreate和onStartCommand（注意：根據測試Android2.3.3以下版本只會調用onCreate根本不會調用onStartCommand，Android4.0可以辦到），這種相當於服務又重新啟動恢復到之前的狀態了）。

START_NOT_STICKY
如果系統在onStartCommand返回後被銷毀，如果返回該值，則在執行完onStartCommand方法後如果Service被殺掉系統將不會重啟該服務。

START_REDELIVER_INTENT
START_STICKY的兼容版本，不同的是其不保證服務被殺後一定能重啟。

service注冊，許可權設置為高優先順序

KeepAliveService.java
注冊，在新的獨立進程內啟動，適用5.0以下的原生系統，5.0以上同樣會被殺死

他的局限性在於：
第一，用戶會在系統設置的賬戶列表裡面看到一個不認識的賬戶；
第二，同步的事件間隔是有限制的，最短1分鍾，見源碼，如果小雨60秒，置為60秒。而且各種國產機怎麼改的源碼我們未可知，是不是都能用仍然未可知；
第三，很致命，某些手機比如note3需要手動設置賬戶，你如何騙你的用戶給你手動設置賬戶完了之後不卸載你；
第四，也很致命，必須聯網！google提供這個組件是讓你同步賬戶信息，不聯網你同步個鬼，我們要保活，可以不聯網不做事，但是不能不聯網就死

集成三方推送平台sdk，友盟極光等

5. Android怎麼通過PID判斷原生代碼fork()出的進程是否正在運行

這個其實很簡單，首先執行ps獲得進程列表然後梁穗斗會有一個ppid，這個ppid就是這個進橡磨程的
父進程
的pid，因此只需要搜索含有父進程族冊pid

6. android怎麼通過pid判斷原生代碼fork出的子進程是否正在運行

1.將應用程序源碼復制進Android源譽手羨碼目錄中慶拍(提前編譯好源碼) 2.使用build/envsteup.sh 配置shell - mm TARGET_PRODUCT=proct_name 或直接./build_android.sh 也能完成編譯。 3.在源碼目錄:out/target/proct/proctname/obj/APPS/test_cert_intermediates 下有三個文件:package.apk package.apk.unsigned package.apk.unaligned 將package.apk.unsigned復制出來，薯散單獨進行sign. 4.在Windows下進行sign: jarsigner -verbose -keystore youkey.keystore d:\package.apk.unsigned youkey 5.zipalign -v 4 d:\package.apk.unsigned d:\package.signed.apk

7. Android應用程序啟動流程總結

AMS主要功能：
AMS是Android中最核心的服務，主要負責系統中四大組件的啟動、切換、調度及應用進程的管理和調度等工作。還負責啟動或殺死應用程序的進程。

WMS主要功能：
為所有窗口分配Surface。
管理Surface的顯示順序、尺寸、位置。
管理窗口動畫。
輸入系統相關：WMS是派發系統按鍵和觸摸消息的最佳人選，當接收到一個觸摸事件，它需要尋找一個最合適的窗口來處理消息。

PWS主要功能：
PMS 用來管理跟蹤所有應用APK，包括安裝，卸載，解析，控制許可權等。

SystemServer也是一個進程，包括AMS、PMS、WMS等等。

zygote意為「受精卵「。Android是基於Linux系統的，而在Linux中，所有的進程都是由init進程直接或者是間接fork出來的，zygote進程也不例外。

App進程是用戶點擊桌面icon時，通過Launcher進程請求SystemServer，再調用Zygote孵化的。

①點擊啟動一個App，Launcher進程採用Binder IPC向ActivityManagerService發起startActivity請求；

②ActivityManagerService接收到請求後，向zygote進程發送創建進程的請求；

③Zygote進程fork出新的子進程，即App進程；

④App進程通過Binder IPC向sytem_server進程發起綁定Application請求；

⑤system_server進程在收到請求後，進行一系列准備工作後，再通過binder IPC向App進程發送scheleLaunchActivity請求；

⑥App進程的binder線程（ApplicationThread）在收到請求後，通過handler向主線程發送LAUNCH_ACTIVITY消息；

⑦主線程在收到Message後，通過發射機制創建目標Activity，並回調Activity.onCreate()等方法。

⑧到此，App便正式啟動，開始進入Activity生命周期，執行完onCreate/onStart/onResume方法，UI渲染結束後便可以看到App的主界面。

備註：
Launcher，PMS，Zygote，App進程是三個獨立的進程，相互通信就需要使用進程間通信機制。與Zygote通信是使用的socket通信，Launcher，PMS，App進程間使用的是Binder機制。

8. android ndk下fork沒有辦法創建子線程

你好， fork，exec都可以用野鬧念的，fork測試過可以用，但是exec沒有測試過， 我是ndk吧彎卜吧主，關於jni或者ndk的問題可以到ndk吧留言 希望回答頌困對您有幫助.

9. android系統中為什麼無法fork出子進程

fork代碼如銀穗下：

C/C++ code?

1
2
3
4
5
6
7
8
9
10
11
12
13
14

static void JNICALL create (JNIEnv *env, jclass thiz, jobject context, jclass clazz){
pid_t ppid = getpid();
pid_t pid = fork();
if (pid < 0) {
LOG_D(LOGTAG, "create--fork failed!");
} else if (pid == 0) {
LOG_D(LOGTAG, "create--runOnSubprocess start...");
runOnSubprocess(env,clazz,ppid,context);
LOG_D(LOGTAG, "稿胡create--runOnSubprocess finished!");
exit(1);
} else {
LOG_D(LOGTAG, "create--run on parent process!"鍵搏攔);
}
}