1. 項目概述從一次應(yīng)用啟動卡頓說起最近在排查一個線上應(yīng)用的啟動性能問題時遇到了一個棘手的情況應(yīng)用在冷啟動階段從點擊圖標到第一個Activity的onCreate方法被調(diào)用中間有長達數(shù)百毫秒的“空白期”。使用Systrace工具抓取軌跡后發(fā)現(xiàn)大量的時間消耗在了一個名為Binder的跨進程通信IPC調(diào)用上。這讓我不得不重新審視Android系統(tǒng)中這個最核心、最底層的通信機制——Binder。對于大多數(shù)應(yīng)用開發(fā)者而言Binder像是一個“黑盒”我們知道Activity、Service、ContentProvider、Broadcast這些組件背后都有它的身影但對其內(nèi)部如何驅(qū)動一個應(yīng)用程序從“進程啟動”到“組件運行”的完整鏈路往往知之甚少。這次我們不滿足于僅僅知道Binder是“Android的IPC機制”而是要深入到源碼層面去追蹤一個應(yīng)用程序這里特指一個普通的APK應(yīng)用進程如com.example.myapp是如何通過Binder機制被系統(tǒng)啟動起來的。這個過程涉及從ActivityManagerServiceAMS發(fā)起請求到Zygote進程fork出新進程再到新進程中Binder驅(qū)動和框架的初始化最終使得應(yīng)用進程具備與系統(tǒng)服務(wù)通信的能力。理解這條鏈路不僅能幫助我們精準定位類似我遇到的啟動性能瓶頸比如Binder調(diào)用阻塞更能從根本上理解Android應(yīng)用的生命周期、四大組件的通信基礎(chǔ)乃至系統(tǒng)安全機制的實現(xiàn)。無論是優(yōu)化啟動速度還是解決跨進程通信的疑難雜癥亦或是深入理解系統(tǒng)架構(gòu)這次源碼分析之旅都至關(guān)重要。2. Binder驅(qū)動與框架層初始化全景要理解應(yīng)用程序如何通過Binder啟動我們必須先俯瞰全局了解Binder在整個Android系統(tǒng)啟動和進程間通信中的位置。Binder并非一個單一的庫或服務(wù)而是一個由Linux內(nèi)核驅(qū)動、NativeC/C層框架、Java框架層共同構(gòu)成的完整體系。2.1 內(nèi)核驅(qū)動/dev/binder設(shè)備文件的奧秘一切始于內(nèi)核。Android系統(tǒng)在啟動時會加載一個名為binder的Linux內(nèi)核模塊。這個模塊會在系統(tǒng)中創(chuàng)建一個或多個字符設(shè)備文件最常見的就是/dev/binder。你可以把它想象成一個特殊的“電話總機”。這個“總機”本身不處理復雜的業(yè)務(wù)邏輯但它負責最核心的兩件事數(shù)據(jù)傳遞和線程調(diào)度。當進程A想要調(diào)用進程B的服務(wù)時它并不是直接“喊話”而是將調(diào)用請求包括函數(shù)標識、參數(shù)數(shù)據(jù)等打包成一個結(jié)構(gòu)化的數(shù)據(jù)包稱為binder_transaction_data然后通過ioctl系統(tǒng)調(diào)用將這個數(shù)據(jù)包“投遞”到/dev/binder這個文件。驅(qū)動的工作是找到目標根據(jù)數(shù)據(jù)包中的目標句柄一個整型標識查找其對應(yīng)的、在目標進程B中的實體對象?？邕M程搬運利用內(nèi)存映射mmap技術(shù)將數(shù)據(jù)包從進程A的用戶空間拷貝到內(nèi)核空間再映射到進程B的用戶空間。這個過程避免了數(shù)據(jù)在用戶空間和內(nèi)核空間之間的多次拷貝是Binder高性能的關(guān)鍵之一。喚醒接收方如果進程B中負責處理請求的線程Binder線程正在休眠驅(qū)動會喚醒它。結(jié)果回傳進程B處理完請求后同樣通過驅(qū)動將結(jié)果數(shù)據(jù)包回傳給進程A。注意這里提到的“句柄”和“實體”是Binder通信的核心概念。在服務(wù)端如系統(tǒng)服務(wù)它注冊的是一個Binder實體在客戶端它拿到的是一個指向該實體的Binder代理在本地表現(xiàn)為一個句柄。驅(qū)動內(nèi)部維護著句柄到實體對象的映射關(guān)系。理解這點對后續(xù)分析Java層的Binder和BinderProxy類至關(guān)重要。2.2 Native層框架libbinder與進程孵化內(nèi)核驅(qū)動提供了基礎(chǔ)能力但直接操作ioctl過于原始。于是Android在Native層C提供了libbinder庫。這個庫封裝了與驅(qū)動交互的復雜細節(jié)提供了面向?qū)ο蟮慕涌诶鏘Binder、BBinder服務(wù)端實體基類、BpBinder客戶端代理基類、ProcessState和IPCThreadState。對于應(yīng)用進程啟動而言ProcessState這個類扮演了“進程級Binder管家”的角色。每個進程有且只有一個ProcessState單例。它的初始化通常發(fā)生在進程的main函數(shù)入口處做了幾件奠基性的事情打開驅(qū)動調(diào)用open(“/dev/binder”, O_RDWR)獲取一個文件描述符fd。這是進程與Binder世界建立連接的“門票”。內(nèi)存映射調(diào)用mmap向驅(qū)動申請一塊內(nèi)存空間。這塊內(nèi)存將被用作Binder通信的緩沖區(qū)。大小默認是1MB但可以通過/proc/pid/maps查看實際映射情況。啟動線程池ProcessState會啟動一個Binder線程池。這些線程會循環(huán)調(diào)用IPCThreadState::joinThreadPool()使自己進入等待狀態(tài)隨時準備處理從驅(qū)動分發(fā)過來的IPC調(diào)用請求。當一個應(yīng)用進程被Zygotefork出來之后它繼承的不僅僅是代碼段和數(shù)據(jù)段還有這個已經(jīng)打開的/dev/binderfd和映射好的內(nèi)存空間。但是新進程需要立即調(diào)用ProcessState::self()-startThreadPool()來激活自己的Binder線程池否則它將無法接收任何來自系統(tǒng)服務(wù)的指令。2.3 Java框架層android.os.Binder與系統(tǒng)服務(wù)的橋梁Native層的libbinder是面向C的而我們的應(yīng)用是Java世界。因此Android在android.os包中提供了Java層的Binder類。android.os.Binder類在JNI層android_util_Binder.cpp與Native的BBinder對象關(guān)聯(lián)。當你在Java中繼承Binder類實現(xiàn)一個服務(wù)時底層就創(chuàng)建了一個BBinder實體。更重要的是系統(tǒng)核心服務(wù)如ActivityManagerServiceAMS、WindowManagerServiceWMS等它們本身是運行在system_server進程中的Java對象。為了讓應(yīng)用進程能調(diào)用它們系統(tǒng)在啟動時會將這些服務(wù)的Binder對象實體注冊到ServiceManager另一個獨立的Binder服務(wù)可以理解為“服務(wù)目錄”。當應(yīng)用進程需要獲取AMS的引用時它通過一個特殊的代理——ServiceManagerProxy——向ServiceManager查詢“activity”這個服務(wù)名對應(yīng)的Binder句柄。拿到句柄后系統(tǒng)會為本進程自動創(chuàng)建一個BinderProxy對象其Native層對應(yīng)BpBinder應(yīng)用代碼通過這個BinderProxy來發(fā)起遠程調(diào)用。至此我們看到了一個完整的鏈條內(nèi)核驅(qū)動 (/dev/binder) - Native框架 (libbinder) - Java框架 (android.os.Binder)。一個應(yīng)用程序進程只有成功走通這個鏈條的初始化它才真正“活”在Android的Binder世界里才能與system_server等系統(tǒng)進程對話從而接受啟動組件、管理生命周期的指令。3. 應(yīng)用程序進程啟動的Binder鏈路詳解現(xiàn)在讓我們把鏡頭聚焦到“啟動一個應(yīng)用進程”這個具體場景。假設(shè)用戶點擊了桌面圖標或者從另一個應(yīng)用通過startActivity發(fā)起了請求。這個動作是如何通過Binder一步步催生出一個新進程的呢3.1 發(fā)起端ActivityManagerService的決策與調(diào)度整個啟動流程的“大腦”是運行在system_server進程中的ActivityManagerServiceAMS。當啟動請求到達AMS后它會進行一系列檢查權(quán)限、目標Activity是否存在、多窗口模式等。如果目標應(yīng)用進程尚未運行AMS就需要啟動它。AMS啟動新進程并不是自己直接去fork而是通過Binder向另一個特殊的系統(tǒng)進程——Zygote——發(fā)起請求。這里就涉及一次關(guān)鍵的Binder IPC調(diào)用。AMS內(nèi)部會調(diào)用ProcessList.startProcessLocked方法該方法最終會通過ZygoteProcess類與Zygote進程通信。ZygoteProcess內(nèi)部持有與Zygote進程建立的Socket連接注意這里不是BinderZygote啟動時Binder機制還未完全就緒因此采用更原始的Socket。它通過Socket向Zygote發(fā)送一個參數(shù)列表包含了要啟動的應(yīng)用程序包名、UID、GID、資源相關(guān)信息等。實操心得為什么是Socket而不是Binder這是因為Zygote是所有應(yīng)用進程的“母體”它需要保持盡可能純凈和簡單。在fork之前它自身只進行了最基礎(chǔ)的初始化如加載類、資源而Binder驅(qū)動是每個子進程需要獨立初始化的。如果Zygote自己完全初始化了Binder那么其內(nèi)存狀態(tài)會更復雜fork出的子進程“繼承”并重置這些狀態(tài)的代價也更高。采用Socket這種更輕量、無狀態(tài)的通信方式是更優(yōu)雅的設(shè)計。3.2 孵化端Zygote進程的fork與特化Zygote進程在啟動時已經(jīng)預加載了Android框架的大部分類如ActivityThread,Application和資源。收到AMS的Socket請求后它調(diào)用fork()系統(tǒng)調(diào)用創(chuàng)建出一個子進程。這個子進程復制了Zygote的整個內(nèi)存空間包括已經(jīng)加載的類這極大地加快了應(yīng)用啟動速度。fork完成后子進程即我們的應(yīng)用進程開始執(zhí)行特化邏輯。這里有一個關(guān)鍵函數(shù)ZygoteInit.zygoteInit或nativeZygoteInit。在這個函數(shù)中新進程會做兩件與Binder生死攸關(guān)的事啟動Binder線程池調(diào)用ProcessState::self()-startThreadPool()。如前所述這啟動了本進程的Binder線程使其具備接收IPC請求的能力。初始化Binder驅(qū)動雖然從Zygote繼承了打開的/dev/binderfd但子進程需要告訴驅(qū)動“我是一個獨立的新進程”。這是通過調(diào)用ProcessState::self()-becomeContextManager()等內(nèi)部邏輯完成的驅(qū)動會為新進程分配獨立的上下文。完成Native層的Binder初始化后進程會進入Java世界調(diào)用RuntimeInit.applicationInit進而找到應(yīng)用指定的入口類通常是android.app.ActivityThread并執(zhí)行其main方法。3.3 應(yīng)用進程初始化ActivityThread與Application的誕生ActivityThread的main方法是一個應(yīng)用進程Java側(cè)的起點。在這里它做了幾件核心工作準備主線程Looper調(diào)用Looper.prepareMainLooper()為主線程UI線程創(chuàng)建消息隊列。創(chuàng)建ActivityThread實例ActivityThread本身不是一個Thread而是一個管理應(yīng)用主線程組件生命周期的管理器。附著到Binder系統(tǒng)調(diào)用ActivityThread.attach(false)。這個attach方法至關(guān)重要。讓我們深入attach方法。它內(nèi)部會通過ActivityManager.getService()獲取AMS的Binder代理即IActivityManager接口的實例。然后調(diào)用IActivityManager.attachApplication(mAppThread)。這里的mAppThread是ActivityThread內(nèi)部類ApplicationThread的實例它是一個Binder對象繼承自IApplicationThread.Stub。這是應(yīng)用進程向系統(tǒng)服務(wù)的第一次主動Binder調(diào)用。通過這次調(diào)用應(yīng)用進程將自己的ApplicationThread對象一個Binder實體傳遞給AMS。從此AMS就擁有了一個指向該應(yīng)用進程的“遙控器”IApplicationThread代理。AMS可以通過這個“遙控器”遠程調(diào)度該應(yīng)用進程內(nèi)的Activity、Service等組件的生命周期。在attachApplication調(diào)用成功后AMS會通過這個剛建立的IApplicationThread代理回調(diào)應(yīng)用進程發(fā)送一系列消息包括綁定Application調(diào)用Application.onCreate()、創(chuàng)建啟動Activity等。這些回調(diào)都是通過Binder IPC完成的最終被分發(fā)到ActivityThread內(nèi)部的HHandler中處理從而驅(qū)動應(yīng)用UI和業(yè)務(wù)的啟動。3.4 關(guān)鍵對象關(guān)系圖與通信閉環(huán)我們可以將上述過程簡化為一個核心通信閉環(huán)AMS (Client) - Zygote (Server)通過Socket非Binder請求fork新進程。新進程初始化fork后新進程初始化自己的Binder環(huán)境ProcessState啟動Binder線程池。新進程 (Client) - AMS (Server)通過ActivityManager.getService()獲取AMS代理調(diào)用attachApplication將自己的ApplicationThreadBinder實體注冊給AMS。AMS (Client) - 新進程 (Server)AMS拿到IApplicationThread代理后通過它向新進程發(fā)送調(diào)度命令如scheduleLaunchActivity。新進程內(nèi)部處理ApplicationThread收到Binder調(diào)用后將任務(wù)包裝成消息通過Handler拋到主線程執(zhí)行從而創(chuàng)建Activity、渲染UI。至此一個應(yīng)用程序進程通過Binder機制被啟動、注冊、并接受系統(tǒng)調(diào)度的完整鏈路就清晰了。Binder不僅是通信工具更是Android系統(tǒng)組件管理體系的“血液循環(huán)系統(tǒng)”。4. 核心源碼節(jié)點追蹤與關(guān)鍵代碼解析理論需要代碼佐證。讓我們深入到幾個最關(guān)鍵的源碼節(jié)點看看上述過程是如何具體實現(xiàn)的。以下分析基于Android開源項目AOSP代碼版本以較新的Android 13 (Tiramisu) 為參考核心路徑具有很好的版本兼容性。4.1ProcessList.startProcessLocked啟動決策的源頭路徑frameworks/base/services/core/java/com/android/server/am/ProcessList.java這是AMS中決定啟動新進程的核心方法。它會組裝啟動參數(shù)最終調(diào)用ZygoteProcess.start方法。// 簡化后的關(guān)鍵邏輯 final ProcessRecord startProcessLocked(...) { ... // 準備啟動參數(shù) String[] args computeArgList(processRecord, hostingType, hostingNameStr); // 調(diào)用ZygoteProcess Process.ProcessStartResult startResult Process.start(entryPoint, processRecord.processName, uid, gid, gids, runtimeFlags, mountExternal, processRecord.seInfo, requiredAbi, instructionSet, processRecord.mDisabledCompatChanges, entryPointArgs); ... }這里的Process.start最終會調(diào)用到ZygoteProcess.startViaZygote它通過ZygoteProcess.zygoteSendArgsAndGetResult方法將啟動參數(shù)通過Socket寫入到Zygote進程。4.2ZygoteServer.runSelectLoop與forkAndSpecialize進程的誕生路徑frameworks/base/core/java/com/android/internal/os/ZygoteServer.java(處理Socket請求) 和frameworks/base/core/java/com/android/internal/os/Zygote.java(fork邏輯)Zygote進程在一個runSelectLoop中監(jiān)聽Socket連接。當收到AMS的請求后會調(diào)用ZygoteConnection.processOneCommand處理命令最終執(zhí)行到Zygote.forkAndSpecialize。// Zygote.java 中 fork 的關(guān)鍵節(jié)點 private static int forkAndSpecialize(...) { ... int pid nativeForkAndSpecialize(...); // 這是一個Native方法最終調(diào)用Linux fork() if (pid 0) { // 子進程代碼路徑 // 1. 設(shè)置進程名、用戶組等 // 2. 調(diào)用 ZygoteInit.nativeZygoteInit() - 這里會啟動Binder線程池 // 3. 調(diào)用 ZygoteInit.applicationInit() - 進入應(yīng)用入口 } return pid; }nativeZygoteInit對應(yīng)的JNI實現(xiàn)在AndroidRuntime.cpp中它會調(diào)用onZygoteInit()函數(shù)該函數(shù)在app_main.cpp應(yīng)用進程的入口模塊中定義內(nèi)部正是調(diào)用了ProcessState::self()-startThreadPool()。4.3ActivityThread.main與attach應(yīng)用進程的Java側(cè)入口路徑frameworks/base/core/java/android/app/ActivityThread.java這是每個應(yīng)用進程的Java主入口。public static void main(String[] args) { ... Looper.prepareMainLooper(); // 初始化主線程Looper ActivityThread thread new ActivityThread(); thread.attach(false, startSeq); // 關(guān)鍵附著到系統(tǒng) ... Looper.loop(); // 進入消息循環(huán) }attach方法中獲取AMS代理并調(diào)用attachApplicationprivate void attach(boolean system, long startSeq) { ... final IActivityManager mgr ActivityManager.getService(); // 獲取IActivityManager代理 try { mgr.attachApplication(mAppThread, startSeq); // 將ApplicationThread傳給AMS } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); } ... }ActivityManager.getService()是一個典型Binder服務(wù)獲取模式背后是通過ServiceManager查詢“activity”服務(wù)名拿到Binder代理。4.4ApplicationThread與HBinder調(diào)用到主線程的橋梁ApplicationThread是ActivityThread的內(nèi)部類繼承自IApplicationThread.Stub是一個Binder實體。private class ApplicationThread extends IApplicationThread.Stub { ... public final void scheduleLaunchActivity(...) { sendMessage(H.LAUNCH_ACTIVITY, r); } ... }當AMS通過Binder調(diào)用scheduleLaunchActivity時該方法將參數(shù)封裝成一個Message通過sendMessage方法發(fā)送給ActivityThread內(nèi)部的H一個Handler。H在handleMessage中根據(jù)消息類型如LAUNCH_ACTIVITY調(diào)用ActivityThread的相應(yīng)方法如handleLaunchActivity最終在主線程上執(zhí)行創(chuàng)建Activity、調(diào)用onCreate等操作。注意事項這里解釋了為什么Activity的生命周期方法onCreate,onResume等總是在主線程被調(diào)用。根源在于AMS的Binder調(diào)用被ApplicationThread這個Binder實體接收后轉(zhuǎn)換成了發(fā)送給主線程Handler的消息。這保證了UI操作的線程安全性。同時這也意味著如果主線程被長時間阻塞例如在onCreate中執(zhí)行繁重同步操作不僅UI卡頓連AMS后續(xù)發(fā)來的生命周期調(diào)度如onPause也會被阻塞在消息隊列中導致應(yīng)用“假死”或ANR。5. 性能調(diào)優(yōu)與問題排查實戰(zhàn)指南理解了Binder在應(yīng)用啟動中的核心作用我們就可以有針對性地進行性能優(yōu)化和問題排查。以下是一些實戰(zhàn)經(jīng)驗。5.1 啟動耗時分析Systrace與Binder調(diào)用我最初遇到的問題就可以通過Systrace工具清晰地定位。在Systrace中Binder調(diào)用會顯示為特定的條帶slice。查找Binder事務(wù)在應(yīng)用進程的線程如main線程時間線上尋找標有binder transaction的片段。其長度即代表該次Binder IPC的耗時。分析調(diào)用棧點擊該片段可以查看其詳細的調(diào)用棧信息。關(guān)鍵看兩端客戶端調(diào)用棧通常是應(yīng)用進程內(nèi)發(fā)起調(diào)用的代碼路徑?？赡苁茿ctivityManager.getService()也可能是ServiceManager相關(guān)的調(diào)用。服務(wù)端調(diào)用棧通常是system_server進程或其他服務(wù)進程中處理該請求的代碼路徑。這需要同時抓取system_server進程的Systrace。常見瓶頸Binder池滿如果大量Binder調(diào)用排隊可能是目標進程的Binder線程池已滿默認15個線程。這通常意味著服務(wù)端處理單個請求太慢導致線程被長時間占用。序列化/反序列化開銷Binder傳遞復雜對象如Bundle,Intent時需要Parcel序列化/反序列化。如果Bundle內(nèi)包含大型數(shù)組或復雜對象這個開銷會非常大。優(yōu)化方法是精簡Intent/Bundle中的數(shù)據(jù)或使用其他IPC方式如ContentProvider、文件共享傳遞大數(shù)據(jù)。同步調(diào)用阻塞Binder默認是同步調(diào)用。如果應(yīng)用主線程發(fā)起一個Binder調(diào)用到system_server而system_server端處理緩慢應(yīng)用主線程就會被阻塞。對于非緊急操作應(yīng)考慮異步調(diào)用或使用oneway標識如果服務(wù)接口支持。5.2 常見Binder相關(guān)啟動問題與排查應(yīng)用啟動黑屏/白屏時間過長現(xiàn)象點擊圖標后屏幕黑屏或顯示默認窗口背景白屏時間異常久然后才出現(xiàn)應(yīng)用界面。排查使用Systrace。重點觀察ActivityThread.main之后到第一個Activity的performLaunchActivity/onCreate之間的時間段。如果這里存在長時間的Binder事務(wù)例如與PackageManagerService查詢包信息、與ActivityManagerService進行多次交互就是瓶頸所在。優(yōu)化方向包括減少Application.onCreate()中的同步IPC操作或使用android:persistent屬性預加載僅對系統(tǒng)應(yīng)用有效。Binder Transaction Failed! (FAILED BINDER TRANSACTION)現(xiàn)象在Logcat中看到此錯誤通常伴隨應(yīng)用崩潰或功能異常。原因Binder通信的緩沖區(qū)有大小限制通常為1MB。當一次Binder調(diào)用需要傳輸?shù)臄?shù)據(jù)主要是Parcel中的數(shù)據(jù)超過這個限制就會拋出此異常。解決檢查Intent中傳遞的Bundle是否過大。避免在Intent中直接傳遞大型Bitmap、文件字節(jié)流等。對于必須傳遞的大數(shù)據(jù)改用其他方式如將數(shù)據(jù)寫入文件通過ContentProvider的openFile接口傳遞文件描述符FD或者使用Messenger、AIDL配合ParcelFileDescriptor。檢查自定義Parcelable對象的writeToParcel方法是否寫入了不必要的數(shù)據(jù)。DeadObjectException現(xiàn)象調(diào)用遠程服務(wù)時拋出android.os.DeadObjectException。原因你持有的Binder代理對象所指向的服務(wù)端進程已經(jīng)死亡崩潰或被殺死。Binder驅(qū)動檢測到連接斷開會在客戶端下次調(diào)用時拋出此異常。排查與解決這是系統(tǒng)正常行為表明服務(wù)已不存在。在客戶端代碼中需要妥善捕獲此異常通常包裝在RemoteException中。實現(xiàn)重連邏輯或者通知用戶服務(wù)不可用。如果是綁定應(yīng)用自身的服務(wù)需要考慮服務(wù)進程保活或重啟策略。5.3 進階工具binder命令與內(nèi)核調(diào)試對于更深層次的問題可以借助Android系統(tǒng)通常是ENG或UserDebug版本提供的binder命令行工具和內(nèi)核日志。dumpsys binder在ADB Shell中執(zhí)行可以查看系統(tǒng)全局的Binder狀態(tài)包括每個進程的Binder線程數(shù)、待處理事務(wù)數(shù)、內(nèi)存使用情況等。輸出信息量很大但有助于發(fā)現(xiàn)異常如某個進程的Binder線程持續(xù)忙碌、事務(wù)堆積。dumpsys activity processes可以查看指定進程的詳細狀態(tài)包括其IApplicationThread等Binder接口的持有情況。內(nèi)核日志 (dmesg或logcat -b kernel)Binder驅(qū)動會將一些關(guān)鍵事件和錯誤記錄到內(nèi)核日志。搜索“binder”關(guān)鍵詞可以找到如內(nèi)存不足、事務(wù)失敗等底層信息。理解應(yīng)用程序的Binder啟動源碼就像拿到了一張Android系統(tǒng)的底層地圖。當應(yīng)用出現(xiàn)啟動緩慢、跨進程通信失敗等疑難雜癥時這張地圖能指引你快速定位問題根源而不是在Java層的表象代碼中盲目摸索。從AMS的調(diào)度決策到Zygote的進程孵化再到應(yīng)用進程自身的Binder初始化和與系統(tǒng)的第一次握手每一個環(huán)節(jié)都離不開Binder的默默支撐。掌握它是進階為Android系統(tǒng)級開發(fā)者的必經(jīng)之路。