apk安裝過程，涉及到data/app、data/data等檔案夾的通路與資源的存儲，了解安裝流程，可以幫助業務進行整改，解決線上問題
疑問：
（1）了解APK安裝流程有什麼好處
（2）了解APK安裝流程可以解決什麼問題
安裝就分為下面三個階段，每個階段可以做些什麼工作，可以幫助我們優化安裝流程，解決安裝後的一些問題呢？
（1）安裝前、安裝中：這兩個階段，第三方應用做不了什麼，一般是應用分發APP應用商店、遊戲中心、浏覽器、應用寶這些應用會關注這兩個狀态。
（2）安裝後：這個階段，無論是内置應用還是第三方應用，或多或少的會遇到一些問題，如so檔案找不到，圖檔存儲、緩存資料等出現異常等...
安裝前無非是根據自己的應用情況，選擇一種可以使用的安裝方法。
對于具有系統簽名的廠商應用，具備靜默安裝能力，使用pm指令即可實作。
非系統簽名的應用寶這種應用，隻能使用包安裝管理器進行安裝。
使用session安裝的原因，是因為從Android 8.0開始，pm指令無法實作靜默安裝，否則會直接顯示安裝失敗。但是網上并未發現對靜默方法的适配方案，也許這是因為這個相容隻有廠商關注，第三方應用不關注這個方法的相容。下面給出相容方案：
該方法是從packageManager中抽取出的代碼，可實作應用的靜默安裝。
APK檔案其實是zip格式，一般包含一個或多個dex檔案、resources.arsc、AndroidManifest.xml、res目錄、META-INF目錄及包含so庫的lib目錄：
system/app——内置應用，也就是系統自帶的應用程式，無法删除。
data/app——使用者程式安裝的目錄，有删除權限。安裝時把apk檔案複制到此目錄。
data/data——存放應用程式的資料，比如一些sp緩存資料。
data/dalvik-cache——将APK中的dex檔案安裝到dalvik-cache目錄下(dex檔案是dalvik虛拟機的可執行檔案,其大小約為原始APK檔案大小的四分之一)。
安裝過程概括為：複制APK安裝包到/data/app目錄下，解壓并掃描安裝包，向資料總管注入APK資源，解析AndroidManifest檔案，并在/data/data目錄下建立對應的應用資料目錄，然後針對dalvik/art環境優化dex檔案，儲存到dalvik-cache目錄，将AndroidManifest檔案解析出的元件、權限注冊到PackageManagerService，完成後發送廣播。
安裝中，這個過程看上去沒有什麼可以做的，但是對于廠商應用來說，應用的安裝速度，卻是可以有很大的提升空間的。如應用更新的差分包更新就是一種常見的增量更新方式。
經過一系列測試與驗證，發現應用安裝的速度，本身與一些因素有關，最主要的是CPU的使用頻率。
衆所周知，現在的手機較為高端，為8核，但是在應用安裝過程中，分析trace檔案，可以确認，并不是8核線程全負荷工作去完成一個應用的安裝，而是一部分線程運作在高核，一部分在低核。
cpuinfo_max_freq cpuinfo_min_freq ：分别給出了 CPU 硬體所支援的最高運作頻率及最低運作頻率，
cpuinfo_cur_freq 則會從CPU 硬體寄存器中讀取CPU 目前所處的運作頻率。
Governor 在選擇合适的運作頻率時隻會在scaling_max_freq 和 scaling_min_freq 所确定的頻率範圍内進行選擇。
scaling_cur_freq 傳回的是cpufreq 子產品緩存的CPU目前運作頻率，而不會對CPU 硬體寄存器進行檢查。
scaling_available_governors 會告訴使用者目前有哪些 governors 可供使用者使用。
scaling_driver 則會顯示該 CPU 所使用的變頻驅動程式。
Scaling_governor 則會顯示目前的管理政策，往這個上 echo 其他類型會有相應的轉變。
scaling_setspeed ：需将 governor 類型切換為 userspace ，才會出現，往這個檔案 echo 數值，會切換主頻。
基于此，可以在應用安裝時，提升CPU的工作頻率，即可使CPU運作在合适的頻率。
除了可以直接根據安裝速度判斷安裝速度是否提升外，也可以根據下面日志判斷提頻是否有效：
可以直接看到頻率變化：
微信安裝速度可以由前面CPU低頻時的20s，提升到CPU頻率較高時的10s左右。
注意：頻率不是越高越好，頻率越高，手機耗電會越高，容易發熱。
應用安裝後，會遇到各種各樣的問題，啟動失敗，合規整改（這個其實在應用開發時就要完成），那麼哪些問題又是可能遇到，又可以借助apk的安裝流程去解決的
在《符合 Google Play 的目标 API 級别要求》 一文中，根據google官方要求，需要對隐私權限進行管控，強制執行分區存儲，這就要求，每個應用不得在sd卡進行資源存儲。那麼問題來了，假如你的項目使用了Glide，Glide的存儲路徑之前設定到了sd卡下面，現在又無法使用外部存儲目錄，該怎麼辦？
當了解了apk的安裝流程之後，知道應用的資料會存儲在data/data/packagename下面，這就給Glide的資源存儲提供了一個内部檔案夾，唯一要做的事情，就是為了防止data/data占用過大，把Glide的存儲目錄設定個上限即可。
如果你的應用接了騰訊的mmkv，你可能遇到了這樣的問題：
這個表示應用加載libmmkv.so出現異常。
出現問題的原因是什麼：根據日志可以确認，是找不到應用data/app/檔案夾下面的libmmkv.so檔案。
前面提到，應用的資料會存儲在data/data下面，這個路徑下面也包含了應用解壓之後的so庫，是以可以做一件事情解決上面libmmkv.so的問題，重連結data/data下面的資源到data/app下面，實作資源共享。實踐證明該方案完全可行，有效解決了so庫找不到的問題。
從apk發起安裝，安裝中、一直到安裝結束，應用狀态的變化，CPU的使用，資源的共享，牽涉到一系列知識點，這些知識點是可以串聯起來的，對提升個人的知識體系有幫助。當然，由于文章篇幅有限，本文章隻是作為一個引導，大緻說明安裝過程中存在什麼知識點，PMS、檔案管理、程序拉起等等安全可以另起一章節進行介紹，後續會介紹這些方面的内容。
廠商應用更多的關注安裝前、安裝中遇到的問題，第三方應用關注安裝後遇到的問題。掌握了安裝過程中的每一個環節，通過上面的分析，可以知道，能夠快速幫助定位問題。
作者：vivo網際網路用戶端團隊-Xu Jie
分享 vivo 網際網路技術幹貨與沙龍活動，推薦最新行業動态與熱門會議。