今天要分析下fwk中activity的啟動流程，之前看別人畫的流程圖，總是很快就忘記了，而且總是摸不著重點，遇到具體問題時還是不知道從何入手，又得從頭看起。後來我想通了一件事，我們在分析這種原始碼時不應該過渡糾結於流程圖與某個具體函式，而應該從巨集觀角度想想：要實現這個功能，他應該要包含哪些步驟？
新的activity是何時被建立的？程序內啟動activity與啟動乙個新程序過程有什麼區別？
啟動activity時，當前的activity應該是要進到後台的，那這個時間順序是怎樣的？這幾個activity的順序由誰來管理？
目錄
具體流程
相關類簡介
整個流程可以分為兩大步驟：啟動前準備與真正啟動。
啟動前準備：在activitystarter和activitystacksupervisor 類中完成當前activity的暫停，並通知新的activity的啟動；（涉及intent解析，activity在棧中的進出。舊activity.onpause--新activity.oncreate-onstart-resume--舊activity.onstop。）
具體流程如下：
activity的startactivity
instrumentation#execstartactivity
activitystarter.startactivitymaywait 中呼叫startactivitylocked；
解析intent得到更多資訊；
呼叫startactivitylocked；
startactivity方法；
startactivityunchecked；
activitystarter.startactivityunchecked（實質會根據資訊中launchmode,flag等來計算排程activitystack中的task，activityrecord等，）;
activitystack.startactivitylocked(原始碼為mtargetstack.startactivitylocked。將activity新增到棧頂，初始化windowmanager,回到stacksupervisor，呼叫stacksupervisor.resumetopactivitieslocked，再調回activitystack.resumetopactivityinnerlocked);
next.setvisibility 去使得動畫可見
activitystacksupervisor.startspecificactivitylocked:（如果是新程序就呼叫startprocesslocked；如果不是就呼叫realstartactivitylocked）
activitythread.handlelaunchactivity;
handlelaunchactivity：
解析前面傳過來的activityclientrecord，來收集activity的相關資訊（是前面生成的）；
用minstrumentation.newactivity去例項activity；
建立configuration;
設定應用theme主題；
通過呼叫minstrumentation.callactivityoncreate去呼叫activity.performcreate,裡面可以呼叫oncreate;
呼叫minstrumentation.callactivityonrestoreinstancestate
handleresumeactivity:
performresumeactivity;
activity.performresume:
performrestart:
onresume:
decor.setvisibility(view.invisible);此時檢視才可見。
切換activity視窗時window變化的過程可參考：
（參考：
activitymanagerservices，簡稱ams，服務端物件，負責系統中所有activity的生命週期
instrumentation，每乙個應用程式只有乙個instrumentation物件，每個activity內都有乙個對該物件的引用。instrumentation可以理解為應用程序的管家，activitythread要建立或暫停某個activity時，都需要通過instrumentation來進行具體的操作。
activitystack：這個並不是我們平時所說的任務棧，activity在ams的棧管理，用來記錄已經啟動的activity的先後關係，狀態資訊等。通過activitystack決定是否需要啟動新的程序。activitystack管理了一系列的taskrecord，通過mstackid來唯一標識，持有activitystacksupervisor的引用。
activitystacksupervisor，這是高版本才有的類，它用來管理多個activitystack，早期的版本只有乙個activitystack對應著手機螢幕，後來高版本支援多屏以後，就
有了多個activitystack，於是就引入了activitystacksupervisor用來管理多個activitystack。
activityrecord，activitystack的管理物件，每個activity在ams對應乙個activityrecord，來記錄activity的狀態以及其他的管理資訊。其實就是伺服器端的activity物件的映像。
taskrecord：這個才是我們平時所說的任務棧，ams抽象出來的乙個「任務」的概念，是記錄activityrecord的棧，乙個「task」包含若干個activityrecord。ams用taskrecord確保activity啟動和退出的順序。
activitystarter:啟動activity相關邏輯；
另外強烈推薦看下：
這篇文章詳細介紹了activityrecord、 taskrecord，activitystack。
Activity啟動流程
0x01 public void startactivity intent intent 最終走到 public void startactivityforresult requirespermission intent intent,int requestcode,nullable bundle ...
Activity啟動流程
activity啟動流程很多文章都已經說過了，這裡說一下自己的理解。activity啟動流程分兩種 後邊啟動activity的流程是一樣的，區別是前邊判斷程序是否存在的那部分。activity啟動的前提是已經開機，各項程序和ams等服務已經初始化完成，在這裡也提一下那些內容。ipc 跨程序通訊，an...
activity啟動流程
所有程序都是由init程序直接或間接fork出來的 android系統啟動時，init程序會fork出zygote，意為 受精卵 後面的所有程序都是zygote 出來的 在zygote程序初始化時會啟動systemserver程序，平時所用到的ams pms wms 網路等服務都是在systemse...