android流程

Ⅰ Android 打包流程

打包後的apk是一個壓縮包,解壓之後,內容如下:

詳細可參考 apk簽名原理

無論我們怎麼配置gradle文件去自定義打包，但是都是要走上圖所畫的七個流程。七個深綠色的橢圓代表了七個不可或缺的打包步驟，並且每一個步驟都一個打包工具

所用到的工具:

zipalign 位元組對齊：

為什麼要以4位元組整數倍為起始偏移?

在文件對齊後, 就可以使用mmap來直接讀寫apk文件

mmap映射

上面涉及到的Android打包流程是以gradle task鏈的形式串聯起來的。
下面看一下常見的task

件

我可以想到的:

Transform API

https://www.jianshu.com/p/a134d00e81ab

https://www.jianshu.com/p/fffb81688dc5

Ⅱ Android的編譯打包流程詳解

下圖的是官網對於Android編譯打包流程的介紹。

官方的介紹非常籠統，簡而言之，其大致流程就是：
編譯-->DEX-->打包-->簽名和對齊

（好像什麼都沒Get到，有一種意猶未盡的感覺……）

來一張外國大神的圖片(註：這張圖少了簽名的步驟)

用文字解釋一下上圖的流程：

首先，我們整理一下編譯的輸入部分是什麼(圖中黃色部分)：

接下來的步驟：

好了，編譯打包的詳細流程說完了，接下來我們看看是否能回答開篇的那些問題。

答：aapt工具對於每個資源文件生成了唯一的ID，這些ID保存在R.java文件中。如下是R.java文件的內容：

資源ID是一個4位元組的無符號整數，在R.java文件中用16進製表示。其中，最高的1位元組表示Package ID，次高1個位元組表示Type ID，最低2位元組表示Entry ID。

只有一個ID如何能引用到實際資源呢？實際上aapt工具還生成了一個文件resources.arsc，相當於一個資源索引表，或者你理解成一個map也行，map的key是資源ID，value是資源在apk文件中的路徑。resources.arsc裡面還有其他信息，這個就不多說了。

通過R.java文件和resources.arsc配合，就能引用到實際的資源文件。

答：第7步已經闡述了對齊所做的工作，為什麼要進行對齊，這是為了加快資源的訪問速度。如果每個資源的開始位置都是上一個資源之後的 4*n位元組，那麼訪問下一個資源就不用遍歷，直接跳到4*n位元組處判斷是不是一個新的資源即可。

如果舉例子，那麼對齊有點類似於資源數組化，數組的訪問速度當然比鏈錶快。

答：xml裡面都是各種字元，不利於快速遍歷。編譯成二進制文件，用數字替換各種符號，一方面能快速訪問，另一方面也能減少大小。

https://developer.android.com/studio/build/index.html
http://www.alittlemadness.com/2010/06/07/understanding-the-android-build-process/
http://blog.csdn.net/luoshengyang/article/details/8744683
https://stackoverflow.com/questions/6517151/how-does-the-mapping-between-android-resources-and-resources-id-work
http://www.jianshu.com/p/eaaddfe34d11

Ⅲ Android App安裝以及啟動流程

Android App的安裝可以分為有界面的安裝和無界面的安裝。

有界面的安裝其實就是調用系統App（PackageInstaller）去安裝apk，打開安裝apk應用之後，點擊安裝按鈕執行startInstall方法，然後就進入安裝中界面開始安裝，安裝成功或者失敗都會有對應的回調。內部其實也是使用PackageManager的installExistingPackage方法，通過binder機制，調用到PackageManagerService的installExistingPackage方法，最終調用到installExistingPackageAsUser方法安裝，而 安裝的核心原理其實就是將apk文件拷貝到系統可識別的重要的文件目錄 ：

無界面安裝是調用adb命令，執行到一個c寫的commandline腳本，調用 install_app 方法，然後再調用 pm_command ，然後執行到pm腳本，執行 run 方法，調用 runinstall ，然後調用 installPackageAsUser 通過AMS執行安裝。

說到App的啟動，就需要從開機開始說起，Android開機會先把所有應用安裝一遍就是把apk拷貝到對應的目錄（這也是Android開機慢的原因）。

整個流程如下：

其實App的啟動，除了剛開機是不一樣之外，正常時候基本與Activity的啟動非常接近。

Ⅳ Android 啟動流程

makeApplication創建application中會執行attachBaseContext(context);

installContentProviders第一個參數context，是從上面傳遞下來的app，也就是application。
遍歷providers列表，初始化每一個provider，都是用application的context。構造出ContentProvider然後執行attachInfo() 方法，attachInfo()執行完畢會執行onCreate()。

最後再mInstrumentation.callApplicationOnCreate(app);執行Application的OnCreate方法。

總結
從流程上來看，符合日誌列印的流程Application#attachBaseContext() → ContentProvider#attachInfo() → ContentProvider#onCreate() → Application#onCreate()
ContentProvider持有的Context也是application，具備給SDK初始化使用。

這時候第一進程是zygote。zygote英文是受精卵的意思。android系統的所有進程都是由zygote進程fork而來。zygote最先啟動的第一個進程是鼎鼎大名的SystemServer進程。這個進程包含了我們常說的三個大神級系統服務，分別是ActivityManagerService，WindowManagerService以及PackegeManagerService。

http://androidxref.com/6.0.0_r1/xref/frameworks/base/core/java/android/app/ActivityThread.java

進程入口在ActivityThread這個類的main（）方法，這個main方法類似C語言的mian方法，是一個程序入口。

這個方法會接著調用ActivityManagerNatvie（一個單例類，可以獲取ActivityManagerService的實例）的getDeafault()返回ActivityManagerService實例。

ApplicationThread是ActivityThread的內部類，他是App和系統跨進程交互的入口，它的實現類在客戶端進程。

獲得了正在Binder通信的客戶端的當前線程的id，然後和ApplicationThread對象作為參數傳入到AMS的attachApplicationLocked。

thread是ApplicationThreadProxy的對象引用，它是代理對象，先調用ApplicationThreadProxy的bindApplication方法，接著在這個方法中又調用ApplicationThreadNative的函數onTransact，然後函數onTransact中根據code找到對應的case，最終會調用ApplicationThread的bindApplication方法。

在這里，bindApplication方法通過向ActivityThread的消息隊列發送BIND_APPLICATION消息

消息的處理調用handleBindApplication方法，handleBindApplication方法比較重要的是會調用如下方法

在執行完bindApplication()之後進入ActivityStackSupervisor.attachApplicationLocked()，這樣我們整個應用進程已經啟動起來了。開始activity的啟動邏輯了。

這個類是一個AMS的一個棧管理類，裡面存儲著ActivityStack的集合。在這個方法，會遍歷各個ActivityStack，找到前台棧，找到裡面的TopActivity。然後比較 傳進來的ProcessRecord.processName和UID是否個和opActivity對用的ActivityRecord裡面的一致。如果一致，就調用ActivityStackSupervisor.realStartAcvitiyLocked（ProcessRecord，ActivityRecord）方法。

這個方法會調用傳過來的ApplicationThread實例的ScheelLaunchActivity（包括ActivityRecord）方法，所以真正執行的是ActivityThread中的scheleLaunchActivity

這個方法是跨進程的，會把ActivityRecord同步到App進程的ActivityRecordClient數據結構，用來後面構造Application和Activity等。

ActivityThread接收到SystemServer進程的消息之後會通過其內部的Handler對象分發消息，經過一系列的分發之後調用了ActivityThread的handleLaunchActivity方法：

接著調用PerformLaunchActivity方法和HandleLaunchActivtiy（）方法。performLauncherActivity，看名字應該就是執行Activity的啟動操作了

1.這個方法主要是構造Application和通過mInstrumention.newActivity()構造Activity。

這個方法會初始化一個Window，以後詳細講，人格視圖都是附在一個window的docorView上，然後由WMS.addView顯示。

這個方法會調用Actiity的resume（）方法，並且在makrVisible（）裡面調用WMS.addView(window),這個windows裡面的docorView的contentView就是onCreate（）裡面setContentView（int layout）設置的contentView。

注意關於WMS.addView(window),這個系統服務，我們下次再講，裡面有一個類RootViewImpl，這個類負責管理我們contentView視圖樹的逐級繪制。

原文鏈接
https://www.cnblogs.com/mingfeng002/p/10330414.html
https://blog.csdn.net/ZZB_Bin/article/details/125209192

Ⅳ 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機制。

Ⅵ Android開機流程

最近回顧的一些知識，補充了一下。

源碼標准：API : 29「Android 10.0」

android手機是怎麼開機的？

android 的底層是 linux kernel「 內核 」，由 BootLoader「系統啟動載入器」 負責載入（類似於計算機的BIOS系統）。

首先啟動 init「父進程，第一個進程」進程，接著運行init.rc腳本，腳本文件有個命令啟動了Zygote進程，初始化時會啟動虛擬機。

Zygote進程fork出 SystemServer 進程，然後會調用SystemServer.main()方法。

run方法中，主要是在進程中啟動系統的各項服務，比如ActivityManagerService，PackageManagerService，WindowManagerService服務等。

下面是一些 主要 的初始化方法。

真正啟動是在ActivityManagerService的中systemReady方法，調用resumeTopActivityLocked打開 鎖屏界面 。

到這里，android的開機流程結束。

Ⅶ Android app開發流程有哪些環節

android app開發流程具體步驟如下：
一 應用開發規劃：
※確定app軟體功能。
※必須的app應用界面及界面跳轉的流程。
※開發app需要的數據及數據的來源及格式。
※是否需要服務端支持。
※是否需要本地資料庫支持。
※是否需要特殊許可權。
※是否需要後台服務。

二 架構設計：
※分層。
※網路連接。
※數據處理-xml、domain。
※封裝Activity。
三 界面設計：
※主界面確定。
※模塊界面、列表、查看、編輯界面。
※菜單、按鈕、對話框、提示信息。
※界面總體顏色。

四 數據操作和存儲：
※數據來源。
※數據類型。
※存儲方式。

五 業務實現：
※客戶端業務解析。

六 頁面跳轉：
※每個頁面間的跳轉。
※菜單、按鈕、事件等。
二、Android APP開發過程中需要注意的問題：
（1）Android APP開發有自己規范的一套標准，在開發中必須無條件遵守。
（2）在Android APP開發過程中，需要根據不同特性來進行優化。
（3）需要針對特定屏幕密度使用特定的圖標和點陣圖。
（4）避免利用那些智能手機可能不支持的硬體功能。
（5）還要針對網頁的布局來調整字體的大小和觸控按鈕。

Ⅷ Android：一個完整app開發流程

可選MVP，MVVM

本app基於mvp架構。除了mvp架構的文件。
還包含下面的文件夾：
ui （下面根據Activity劃分）
widget （自定義dialog等）
base （BaseActivity，BaseFragment）

有側滑欄，tab的一般用fragment

設置sw-360dp,sw-480dp等不同的dimension目錄，根據百分比計算dp值。

bindview使用butterknife，不同組件通信使用EventBus，定時使用RxJava，崩潰收集bugly

按鈕樣式：
使用selector

按鈕背景色，包括顏色和圓角

使用ConstraintLayout，直接使用標注的值來做，最簡單，不要用百分比。使用layout_constraint，layout_margin完成所有布局。

在AndroidStudio直接肉眼布局，Android可以選擇不同的解析度機器，水平或者垂直進行預覽

配置sdk版本
配置abi

使用藍湖進行圖片的協助。提供m,h,x,xx等不同解析度的圖片

Ⅸ Android開機流程

當電源鍵按下系統載入引導程序 BootLoader 到RAM中，開始執行

Android操作系統運行前通過 BootLoader 小程序拉起系統OS

當內核啟動時，首先進行系統設置，比如：設置緩存、載入驅動等，設置完成則在系統中尋找init.rc文件並啟動第一個進程： init

zygote虛擬機啟動一個子進程system_server，同時定義了一個Socket用來處理AMS啟動應用的請求

ZygoteInit.java裡面通過startSystemServer() fork出了SystemServer進程，SystemServer和Zygote進程是Android框架中兩個重要的進程，系統里重要的進程都在SystemServer里開啟，如AMS、WMS、PMS等。

SystemServer啟動後會初始化ActivityManagerService，同時載入本地系統服務庫，調用createSystemContext()創建系統上下文，創建ActivityThread及各種服務

AMS開啟後會調用finishRooting()完成系統引導過程，同時發送開機廣播，ActivityManagerService會與zygote的Socket通信，請求啟動Home。zygote收到AMS的連接請求後，zygote處理請求會通過fork啟動新的應用進程，並最終啟動Home。完成系統界面的載入與顯示。

Ⅹ Android打包流程

官方詳細： https://ionicframework.com/docs/intro/deploying/
ps：打包前做好config.xml配置如包名

一、添加android平台
添加之後，在項目目錄的platforms下會生成一個android文件夾。

二、cordova編譯應用
使用build命令編譯應用的發布版本，這個過程需要你的android sdk和環境變數、java jdk和環境變數、android的gradle配置沒有錯誤。

編譯成功之後，在項目路徑platforms/android/build/outputs/apk/android-release-unsigned.apk未簽名文件，這個時候的apk還不能被安裝到手機上。

三、生成簽名文件

輸入的密碼要記住，其他姓名地區等信息隨便填吧，最好還是記住，成功之後在主目錄下就生成了 jhy-release-key.keystore 文件，命令中jhy-release-key.keystore是生成文件的名字， alias_jhy 是別名，隨便起但是要記住，一會簽名要用到，其他信息如加密、有效日期等就不說了，無需改動。

生成後會提示:
JKS 密鑰庫使用專用格式。建議使用 "keytool -importkeystore -srckeystore jhy-release-key.jks -destkeystore jhy-release-key.jks -deststoretype pkcs12" 遷移到行業標准格式 PKCS12。
執行命令：

執行結果： Warning: 已將 "jhy-release-key.jks" 遷移到 Non JKS/JCEKS。將 JKS 密鑰庫作為 "jhy-release-key.jks.old" 進行了備份。

四、簽名應用文件

把在第二步生成的android-release-unsigned.apk拷貝到與生成的jhy-release-key.jks同一目錄下，也就是項目的主目錄下，執行命令：

輸入簽名文件的密碼，成功之後主目錄下的android-release-unsigned.apk就被簽名成功了，會比原來未被簽名的apk文件大一點，能夠安裝到手機或android虛擬機上了。

簽名完成後會提示沒有時間戳，忽略即可

檢測是否簽名成功：

也可用以下命令簽名並生成新apk文件