android應用啟動優化

❶ 安卓手機有時開機就提示「android正在啟動 正在優化第N個應用（共N個）。」

安卓手機顯示正在優化的處理方法：顯示正在優化通常是在手機更新完系統後第一次開機進入桌面時，此為正常現象，等待優化完成後會自動進入桌面，如遇特殊情況優化一直無法完成，多為更新故障，可以進入rec重新安裝更新包，雙清重啟手機後再試。

❷ 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.延時載入

❸ Android性能優化第（八）篇---App啟動速度優化之耗時檢測處理

應用的啟動速度緩慢這是很多開發者都遇到的一個問題，比如啟動緩慢導致的黑屏，白屏問題，大部分的答案都是做一個透明的主題，或者是做一個Splash界面，但是這並沒有從根本上解決這個問題。那麼如何從根本上解決這個問題或者做到一定程度的緩解？

1、冷啟動：當啟動應用時，後台沒有該應用的進程，這時系統會首先會創建一個新的進程分配給該應用，這種啟動方式就是冷啟動。

2、熱啟動：當啟動應用時，後台已有該應用的進程，比如按下home鍵，這種在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這種啟動方式叫熱啟動。

3、溫啟動 ：當啟動應用時，後台已有該應用的進程，但是啟動的入口Activity被幹掉了，比如按了back鍵，應用雖然退出了，但是該應用的進程是依然會保留在後台，這種啟動方式叫溫啟動。

adb shell am start -W [PackageName]/[PackageName.MainActivity]

執行成功後將返回三個測量到的時間：

這裡面涉及到三個時間，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 這個方法的調用耗時，ThisTime 是指調用過程中最後一個 Activity 啟動時間到這個 Activity 的 startActivityAndWait 調用結束。TotalTime 是指調用過程中第一個 Activity 的啟動時間到最後一個 Activity 的 startActivityAndWait 結束。如果過程中只有一個 Activity ，則 TotalTime 等於 ThisTime。

總結:如果只關心某個應用自身啟動耗時，參考TotalTime；如果關心系統啟動應用耗時，參考WaitTime；如果關心應用有界面Activity啟動耗時，參考ThisTime。

從我們Application開始到首頁顯示出來，這個過程，我們應該注意一些什麼，將這個過程細分一下，會有下面的時間點需要注意。

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

因為上面這些階段全部都是在主線程中執行的，任何不經意的操作都可能拖慢應用的啟動速度。所以我們不應在Application以及Activity的生命周期回調中做任何費時操作，具體指標大概是你在onCreate，onResume，onStart等回調中所花費的總時間最好不要超過400ms，否則用戶在桌面點擊你的應用圖標後，將感覺到明顯的卡頓。但是有些 不得以的任務 又必須在UI顯示之前執行。所以我們要將 任務 劃分優先順序。

對於首頁渲染完成後，開始載入，或者延遲載入，延遲載入的目的就是界面先顯示出來，然後載入，但是你覺得要延遲多久呢？在 Android 的高端機型上,應用的啟動是非常快的 , 這時候只需要 Delay 很短的時間就可以了, 但是在低端機型上,應用的啟動就沒有那麼快了,而且現在應用為了兼容舊的機型,往往需要 Delay 較長的時間,這樣帶來體驗上的差異是很明顯的。延遲載入有一種方式。

極力推薦用第二種，在窗口完成以後進行載入，這裡面的run方法是在onResume之後運行的。關於這種懶載入機制，參考 Android應用啟動優化:一種DelayLoad的實現和原理(上篇) ，給出了詳細的解釋。

通過上面我們知道一種懶載入機制，所以我們可以將Application中和首頁的onCreate中的有些耗時任務，放到首頁渲染完畢後載入。如何找出這些耗時任務，TraceView就派上用場了，TraceView的用法，移步我的前面的博客 Android性能優化第（六）篇---TraceView 分析圖怎麼看？

比如在首頁的onCreate中我們進行了用戶啟動上報，這個進行懶載入是不是分分鍾減少139毫秒呢？

在比如在Application裡面用到了GSON，將String轉化成json,我將這個移動到懶載入裡面，是不是又減少了100毫秒呢？

在比如，有些Application中做了支付SDK的初始化，用戶又不會一打開App就要支付，放在Application中載入幹嘛？

此處我們這里舉得例子是優化了139毫秒和100毫秒的，其實真正耗時的任務有的有1秒多，都被我優化完了，所以trace圖中看不到了，就舉個了這兩個例子，還有SharedPreferences也是耗時大戶，經過檢測保存一個boolean變數耗時120+毫秒以上。

利用TraceView可以清楚我們每一個方法的耗時時間，極大的幫助了我們做優化工作。

五、優化思路總結
1、UI渲染優化，去除重復繪制，減少UI重復繪制時間，打開設置中的GPU過度繪制開關，各界面過度繪制不應超過2.5x；也就是打開此調試開關後，界面整體呈現淺色，特別復雜的界面，紅色區域也不應該超過全屏幕的四分之一；
2、根據優先順序的劃分，KoMobileApplication的一些初始化工作能否將任務優先順序劃分成3,在首頁渲染完成後進行載入，比如：PaySDKManager。
3、主線程中的所有SharedPreference能否在非UI線程中進行，SharedPreferences的apply函數需要注意，因為Commit函數會阻塞IO，這個函數雖然執行很快，但是系統會有另外一個線程來負責寫操作，當apply頻率高的時候，該線程就會比較佔用CPU資源。類似的還有統計埋點等，在主線程埋點但非同步線程提交，頻率高的情況也會出現這樣的問題。
4、檢查BaseActivity,不恰當的操作會影響所有子Activity的啟動。
5、對於首次啟動的黑屏問題，對於「黑屏」是否可以設計一個.9圖片替換掉，間接減少用戶等待時間。
6、對於網路錯誤界面，友好提示界面，使用ViewStub的方式，減少UI一次性繪制的壓力。
7、任務優先順序為2，3的，通過下面這種方式進行懶載入的方式

8、Multidex的使用，也是拖慢啟動速度的元兇，必須要做優化。後面有空專門寫一篇Multidex。

相關鏈接：

Android應用啟動優化:一種DelayLoad的實現和原理(上篇)http://androidperformance.com/2015/11/18/Android-app-lunch-optimize-delay-load.html

Android性能優化之加快應用啟動速度http://www.open-open.com/lib/view/open1452821612355.html

手機淘寶性能優化全記錄http://www.open-open.com/lib/view/open1452488209370.html

Android客戶端性能優化（魅族資深工程師毫無保留奉獻）http://blog.tingyun.com/web/article/detail/155#rd

Please accept mybest wishes for your happiness and success !

❹ 華為手機開機重啟後顯示安卓正在啟動優化應用的原因是什麼

華為手機出現這握虧穗種現象一般是由於andriod系統的匹配功能。目前4.4以上的系統都是這段卜樣的。如果每次都是如此你可以嘗試拔掉SD卡試試，看看還會不會出現這種情況，這種情況也很可能是SD卡質量不佳導致的。空拿

或者您可以去咨詢華為官方售後中心：網頁鏈接

❺ 華為手機開機重啟後老是顯示安卓正在啟動優化應用是怎麼回事

建議進入Recovery模式執行雙清wipe操作。Recovery模式指的是一種可以對安卓機內部的數據或系統進行修改的模式（類吵罩搏似於windowsPE或DOS）。悶運在這個模式下可以刷入新的安卓系統，或者對已有的系統進行備份或升級，也可以在此恢復出廠設置。進入recovery的方法：1、將手機完全關機後，按住音量鍵下+電源鍵，進入bootloader界面（部分手機可能不同，多數是音量上或下+電源鍵）；2、按音量鍵將游標移動到recovery那一行；3、按電源鍵，之後手機會自動重啟進入recovery模式。其中音量鍵為游標選擇鍵，可以用來移動游標，電源鍵則是確認鍵。雙wipe步驟如下：1.在recovery模式下,用音量下鍵選擇wipedata/factoryreset這項。2.按HOME鍵執行wipedata/factoryreset命令後再用音量下鍵選擇Yes--deletealluserdata並按HOME鍵執行命令。3.執行Yes--deletealluserdata命令後，表示開始執行。4.按音量下鍵選擇wipecachepartition命令並按HOME鍵執行。5.執行wipecachepartition命令後，音量下鍵選擇Yes--WipeCache並按HOME鍵執行命令。6.執行Yes--WipeCache命令後升祥，表示wipecachepartition也執行成功了。7.wipedata/factoryreset和wipecachepartition執行成功後選擇rebootsystemnow重啟系統即可。

❻ 如何優化 android 系統應用的啟動速度

一、應用的啟動

啟動方式

通常來說，在安卓中應用的啟動方式分為兩種：冷啟動和熱啟動。

• 1、冷啟動：當啟動應用時，後台沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用，這個啟動方式就是冷啟動。

• 2、熱啟動：當啟動應用時，後台已有該應用的進程（例：按back鍵、home鍵，應用雖然會退出，但是該應用的進程是依然會保留在後台，可進入任務列表查看），所以在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這個方式叫熱啟動。

特點

1、冷啟動：冷啟動因為系統會重新創建一個新的進程分配給它，所以會先創建和初始化Application類，再創建和初始化MainActivity類（包括一系列的測量、布局、繪制），最後顯示在界面上。

2、熱啟動：熱啟動因為會從已有的進程中來啟動，所以熱啟動就不會走Application這步了，而是直接走MainActivity（包括一系列的測量、布局、繪制），所以熱啟動的過程只需要創建和初始化一個MainActivity就行了，而不必創建和初始化Application，因為一個應用從新進程的創建到進程的銷毀，Application只會初始化一次。

上面說的啟動是點擊app的啟動圖標來啟動的，而另外一種方式是進入最近使用的列表界面來啟動應用，這種不應該叫啟動，應該叫恢復。

二、應用啟動的流程

在安卓系統上，應用在沒有進程的情況下，應用的啟動都是這樣一個流程：當點擊app的啟動圖標時，安卓系統會從Zygote進程中fork創建出一個新的進程分配給該應用，之後會依次創建和初始化Application類、創建MainActivity類、載入主題樣式Theme中的windowBackground等屬性設置給MainActivity以及配置Activity層級上的一些屬性、再inflate布局、當onCreate/onStart/onResume方法都走完了後最後才進行contentView的measure/layout/draw顯示在界面上，所以直到這里，應用的第一次啟動才算完成，這時候我們看到的界面也就是所說的第一幀。

所以，總結一下，應用的啟動流程如下：

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

三、測量應用啟動的時間

在上面這個啟動流程中，任何一個地方有耗時操作都會拖慢我們應用的啟動速度，而應用啟動時間是用毫秒度量的，對於毫秒級別的快慢度量我們還是需要去精確的測量到到底應用啟動花了多少時間，而根據這個時間來做衡量。

什麼才是應用的啟動時間

從點擊應用的啟動圖標開始創建出一個新的進程直到我們看到了界面的第一幀，這段時間就是應用的啟動時間。

我們要測量的也就是這段時間，測量這段時間可以通過adb shell命令的方式進行測量，這種方法測量的最為精確，命令為：

• adb shell am start -W [packageName]/[packageName.MainActivity]



執行成功後將返回三個測量到的時間：
1、ThisTime:一般和TotalTime時間一樣，除非在應用啟動時開了一個透明的Activity預先處理一些事再顯示出主Activity，這樣將比TotalTime小。
2、TotalTime:應用的啟動時間，包括創建進程+Application初始化+Activity初始化到界面顯示。
3、WaitTime:一般比TotalTime大點，包括系統影響的耗時。

下面是測量一個應用冷啟動和熱啟動的時間：
冷啟動：


熱啟動：




以上就是本文的全部內容，希望對大家學習Android軟體編程有所幫助。

❼ Android開機速度優化初探

Android的開機速度，基本上沒人說快的，通常移植完系統後，馬上要看的事情就是優化開機時間，以下是簡單回憶以下以前做優化的那些事。

優化開機時間，通常做的首先是那有有沒有BUG，明顯不合理的先解決，由於開發階段穩定性臘擾帶問題，一些地方可能延時加的大，或者頻率設的低，先記下來，後面定期還會再看。這些先不看的話，一般拿到機器，我們統計開機時間，主要看如下幾個時間段分布：

開機按鍵時間、亮屏時間(基本固定，除非弄錯了，基本檢查一遍確定)

uboot啟動時間

內核啟動後到bootanim退出時間

可以通過添加列印mole init的李汪log，來check每個mole初始化時的時間。從而找到花費時間比較多的mole:

--- a/init/main.c

+++ b/init/main.c

@@-785,7+785,7@@int__init_or_mole

do_one_initcall(initcall_tfn)

if(initcall_blacklisted(fn))

return

-EPERM;

-if(initcall_debug)

+if(1)

                ret =

do_one_initcall_debug(fn);

-3 優化建議：

preloadClasses()與preloadResources()可以放到兩個線程裡面跑。

修改zygote的nice值，及thread priority。

http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java#590

中增加如下的修改：

在  EventLog . writeEvent ( LOG_BOOT_PROGRESS_PRELOAD_START , 592 SystemClock . uptimeMillis ()); 593 preload (); 594 EventLog . writeEvent ( LOG_BOOT_PROGRESS_PRELOAD_END , 595 SystemClock . uptimeMillis ()); 前增加修改

/* 20151013 optimize android boot begin */

//get the default priority.

int defaultPriority = Process.getThreadPriority(Process.myPid()) ;

//increase the priority .

Process.setThreadPriority(Process.THREAD_PRIORITY_AUDIO) ;

在 gcAndFinalize (); 增加

Process.setThreadPriority(defaultPriority) ;

/*  20151013 optimize android boot end */

-2 系統剪裁也有助於提高系統輪蘆的開機速度

提升CPU頻率 - 將所有CPU切換至性能模式

adb shell stop perf-hal-1-0

adb shell "echo 1 > /sys/devices/system/cpu/cpu0/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu1/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu2/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu3/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu4/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu5/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu6/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu7/online"

adb shell "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu7/cpufreq/scaling_governor"

adb shell "echo performance > /sys/class/devfreq/soc:qcom,cpubw/governor"

adb shell "echo performance > /sys/class/devfreq/soc:qcom,mincpubw/governor"

adb shell "echo performance > /sys/class/devfreq/soc:qcom,memlat-cpu0/governor"

adb shell "echo performance > /sys/class/devfreq/soc:qcom, memlat-cpu6/governor"

提升GPU頻率

adb shell "echo 0 > /sys/class/kgsl/kgsl-3d0/min_pwrlevel"

adb shell "echo 1 > /sys/class/kgsl/kgsl-3d0/force_clk_on"

adb shell "echo performance > /sys/class/kgsl/kgsl-3d0/devfreq/governor"

-1 電源優化

on init

    # Disable UFS powersaving

    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 0

    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 0

    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 0

    write /sys/mole/lpm_levels/parameters/sleep_disabled Y

on property:sys.boot_completed=1

    # Enable UFS powersaving

    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1

    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1

    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1

    write /sys/mole/lpm_levels/parameters/sleep_disabled N

on charger

    # Enable UFS powersaving

    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1

    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1

    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1

    write /sys/class/typec/port0/port_type sink

    write /sys/mole/lpm_levels/parameters/sleep_disabled N

0 bootgraph 用來分析內核功能， 在kernel cmdline 增加 initcall_debug ,然後dmesg > boot.log  bootgraph.pl boot.log >  boot.svg

1通過一個比gzip更快的方式去解壓內核鏡像；

2 去掉系統中一些不必要的log列印；

3 去掉一些系統中不需要的驅動模塊；

4 啟動時即以最大頻率（cpu/DDR）且多核一起跑；

5 將一些耗時大，對啟動順序沒有要求的驅動通過非同步方式進行載入（如下所示）

這里我們主要關注的是第三個，也是優化的重點。這部分時間，具體都在幹啥，瓶頸是哪，可以通過bootchart很清楚的看到。以下結合以前抓的圖，簡要說一下（圖是很久之前抓的，比較懶，沒有再跑一遍過程）

上圖中bootanim的退出時間沒有截出來，實際圖是有的，大約是33s的時候結束。

這里分析時，我們是分了幾個時間段：

1 內核開始啟動，到init進程開始執行。這個可以通過log看到。

2 init進程執行，主要是處理init.rc中的命令，到core和mainl類服務開始啟動的時間，上圖中可以看到，服務大體都在一個時間點起來的，約7.5S時，這之前的一大段空窗期，也是要重點看的

3 zygote啟動時間

4 systemserver中各個服務啟動時間

5 應用啟動(systemui/launcher/keyguard..)

以上，具體分析看每段時間：

第一點另外處理，具體分析列印看是否有異常，這個值一般是很小的，不合理要和BSP同事一起查一下原因。

第二個主要是init.rc執行各種命令，這個可以通過在execute_one_command函數中統計測量 ，比如大於100ms的命令列印出來，再分析定位原因，這里命令執行時間長基本算BUG，要和BSP工程師一起解決。

第三點主要zygote啟動問題，主要慢的原因，是載入資源和類庫，這個要讀nand，一般卡的時間比較長，圖中可以看到，zygote進程一溜的小粉紅，說明IO較多。這個preload過程消耗的時間，在logcat的log中，也會列印的，一般來說，都是在近10S左右。

第四個，zygote初始化完後，會fork system_server。 system_server進程啟動，耗時也是較長的。根據以前統計分析的結果，這里的服務啟動，基本上都是花在packageManagerService的PackageScan中，這又是一個讀文件，卡在文件讀取中，時間長短，和預制app及安裝的app數量有關

第五個時間，是基本都准備ready後，啟動launcher等應用了，啟動完成後，systemServer請求SurfaceFlinger殺了bootanimation，就啟動完成了。

以上時間中，主要要優化的，還是第三步和第四步的IO慢問題，其他可優化的不多。比如CPU，常開四核performance模式啟動，也並沒提升多少，一般我們就不管了這個了。

咋優化？

確定優化方向後主要看怎麼優化這兩段耗時的地方：

1. Zygote的preload 資源和class

2. PackageManagerService的包掃描

這里的第一個，最早之前有人直接是去掉preload或刪減，雖然可以加快一點開機速度，但是撿了芝麻丟了西瓜，根本不能這樣干~

我們最早做的實現方式，

2.1 是將preload做並行處理，畢竟現在都是多核處理器了，而且是preload是載入後還要解析處理的，並行會有一定幅度提升。

對於包掃描，這個不好拆成並行任務，不像preload那麼簡單干凈。考慮過將PackageManager的信息序列化後存起來，下次開機就不掃了，不過看起來改動有點大，不太好搞，也放棄了。

PackageManagerService掃描、檢查APK安裝包信息

2.2 PMS對/system/framework，/system/app，/data/app，/data/app-private目錄中的APK掃描耗費了大量的時間，如果預置的三方應用很多，這樣啟動的時間就會越長。

優化建議：

2.3 /system/app下的應用，如果是預置應用，在Android.mk建議加上LOCAL_DEX_PREOPT := true控制，在/system/vendor下的預置應用，如果此應用編譯時間比較長的，也使用上LOCAL_DEX_PREOPT := true

2.4 盡量減少data區內置app的數量，這個會嚴重影響開機速度，特別是第一次的開機速度。放在system的app 盡量生成odex 這樣會加快開機速度。

最後我們的實現的方式，就是linux上用的較多的readahead機制。具體實現細節就不展開說了，原理就是：

1. 統計開機過程中，讀取的塊數據信息，記錄下來保存

2.再次開機，通過記錄下來的塊數據讀取信息，直接起一個服務，預先開始讀，zygote或packagemanagerservice要讀文件的時候，文件數據已經在cache中了。

實際用下來，這一招特別好，優化非常明顯。以下是實現了一個readahead後的bootchart圖：

可以看到：

1. zygote和system_server都提速了

2. zygote和system_server的IO時間，都降低非常大

3. 主要IO時間，跑到readahead進程中去了。

不過，以上實現，還是有可優化的地方：

1. readahead進程可以再提前，在system分區掛載後立刻啟動，這樣zygote中的IO應該可以再減小

2. 對system_server的IO，此時readahead已經結束了，按理不應該有了，這里還是有IO，這一般是後裝apk導致，這個可以把readahead做的更健壯一些，不要只學習開始的一兩次。

其他NB的優化

另外還有一個很NB的技術，就是STD。這個我們也搞過，花費了大量的人力物力。STD開機時間，不算上uboot時間的話，基本都是在10S內，5~8S之間。不過這么NB的技術，目前基本上也是廢棄了，用起來問題也挺多的：

1. 開機時間少了，關機時間拉長。

由於是STD(Suspend to Disk)，關機時需要將內存數據寫入nand，這塊也是挺麻煩的事情

2. 穩定性

本身STD弄起來就比較復雜，BUG挺多的，另外使用STD，就相當於永不關機了，這也太考驗系統軟體的穩定性了...

3. 沒毛用

   一開始還能忽悠客戶，不過後來也沒人怎麼關心這個feature了，平白給自己找活干，大家都不樂意使能它了。

❽ 華為手機開機重啟後顯示安卓正在啟動優化應用的原因是什麼

造成 Android開機就顯示升級應用的錯誤，是自己刷機後沒有wipe，雙清。

2、手機在線ota升級後沒有自動雙清，導致系統緩存混亂。

3、你的手機的安裝包裡面有自動安裝的程序。

解決方法：

嘗試在關機狀態下，按住「音量+」鍵再按住「開機鍵」直到顯示語言，選擇進入系統，然後按重啟手機，它會顯示重啟進入系統一和重啟進入系統二，選擇進入系統二，之後重啟。

其他原因及方法：

1、可能是軟體兼容性導致的，若多次出現自動關機狀況，建議將近期安裝的第三方軟體刪除，排除是否和下載的軟體有關。

2、請備份手機重要數據，恢復出廠設置。

3、建議執行wipe（雙清）操作。

4、若問題既然存在，請送檢。

1、造成 Android開機就顯示升級應用的錯誤，是自己刷機後沒有wipe，雙清。

2、手機在線ota升級後沒有自動雙清，導致系統緩存混亂。

3、手機的安裝包裡面有自動安裝的程序。

4、手機的自身優化系統和機子不兼容。

解決方法： 嘗試在關機狀態下，按住「音量+」鍵再按住「開機鍵」直到顯示語言，選擇進入系統，然後按重啟手機，它會顯示重啟進入系統一和重啟進入系統二，選擇進入系統二，之後重啟。

拓展：

Android是由Google公司和開放手機聯盟領導並開發的一種基於Linux的自由且開放源代碼的操作系統，主要使用於移動設備。

❾ Android啟動優化概述

Android啟動應用, 按 官方說法 分為冷啟動, 溫啟動和熱啟動.
具體的定義可以看官方文檔, 簡單地說

一般我們只需要關注冷啟動即可.

要想啟動快, 硬體性能必然有影響, 在硬體一定的前提下, 我們要盡量 降低啟動應用時CPU的負載 , 讓CPU有更多的算力投入到啟動流程中:

在做好一些基本原則後, 接著看具體的流程優化點

在應用進程創建後, 首先必然是載入類, 此時一些靜態變數就會初始化了, 因此我們應該

類載入完畢後就是創建 Application 實例了, 因此我們應該

之後會先創建 ContentProvider 和執行 ContentProvider.onCreate() , 因此我們應該

跟接著就會執行 Application.onCreate() 等方法, 因此我們應該

接著就進入 Activity 環節.
同樣第一步會是創建實例, 因此我們應該

在 Activity 進程生命周期後, 第一步就是渲染(inflate)布局, 我們應該

在應用啟動的瞬間, 系統服納虧務會先展示一個空白窗口哪茄殲, 等待應用第一幀繪制完畢後, 再從該窗口切換到應用, 如果啟動耗時較長, 就會明顯看到白屏, 對於這一點, 常見的操作有

可以使用IdleHandler, 在主線程空閑時再執行某些不重要的操作

實際上非同步初始化只是不阻塞主線程, 但是子線程一樣會佔用CPU資源, 讓主線程的執行時間變少, 所以不應該盲目地將所有工作放到子線程.

優化做到最後, 就是在系統流程上做文章了

原理是將啟動時載入的類放到主dex，提升了這些類的內聚，讓更多的類滿足pre-verify的條件，在安裝時就做了校驗和優化，以減少首次載入的耗時，從而優化冷啟動耗時。
Redex 初探與 Interdex：Andorid 冷啟動優化

應用啟動過程中會從apk壓縮包中讀取文件, 該優化的原理是利用Linux中的Pagecache機制, 讓啟動過程會用到的文件盡可能進入緩存中, 減少磁碟IO次數
支付寶 App 構建優化解析：通過安裝包重排布優化 Android 端啟動性能

在Dalvik VM(Android5.0以前)載入類的時候會有一個類校驗過程, 它需要校驗方李沖法的每一個指令, 是一個比較耗時的過程, 可以通過Hook去掉類載入過程中的類驗證過程. 不過對於ART(Android5.0之後)來說, 這個過程在安裝時已經做了, 所以用處不大.

不進入冷啟動, 就不用優化了~

這個Android Studio自帶的工具, 可以看到啟動過程中詳細的方法執行流程, 但是採集數據本身會影響方法執行, 所以不能准確判斷每個方法的耗時, 但是仍可以判斷哪個方法相對來說耗時.

這個工具的好處是可以自定義事件, 可以指定需要採集的數據集, 可以看到線程間的狀態等.

啟動優化的一個關鍵點在於定義啟動結束的點, 以及如何測量啟動時間.

在Android4.4以上, 系統進程會提供一個類似 ActivityManager: Displayed ***: +3s534ms 的日誌, 表示從啟動進程到首次繪制完畢所用的時間.

應用可以在任何時候調用該方法, 觸發系統列印類似 system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms 的日誌

應用可以通過 ViewTreeObserver 來監聽繪制前回調來判斷第一幀的繪制時機, 或者直接在控制項樹的末尾加一個簡單的View, 它 onDraw 調用時即表示頁面(差不多)繪制完畢.

應用啟動過程可以參考 Android Vitals Series' Articles 系列文章

❿ Android 性能優化 05---App啟動優化

其實啟動框架就是一個任務調度系統，是手淘啟動的「大管家」。
管家要做的事情就是把它們的關系梳理得明明白白，有條不紊，合理安排位置、調度時間，襲嘩同時提升硬體資源的利用率。

總結下來無非就是兩點：

有向無環圖[拓撲排序]

可用方案
APT，位元組碼插樁，利用ContentProvider
面試題LeakCanary 為什麼不需要在Application中手動初始化？

①點擊桌面App圖標，Launcher進程採用Binder IPC向system_server進程發起 startActivity請求；
②system_server進程接收到請求後，向zygote進程發送創建進程的請求；
③Zygote進程fork出新的子進程，即App進程；
④App進程，通過Binder IPC向sytem_server進程發起attachApplication請求；
⑤system_server進程在收到請求後，進皮禪頃行一系列准備工作後，再通過binder IPC 向App進程發送scheleLaunchActivity請求；
⑥App進程的binder線程（ApplicationThread）在收到請求後，通過handler向主 線程發送LAUNCH_ACTIVITY消息；
⑦主線程在收到Message後，通過反射機制創建目標Activity，並回調 Activity.onCreate()等方法。
⑧到此，App便正式啟動，開始進入Activity生命周期，執行完 onCreate/onStart/onResume方法，UI渲染結束後便可以看到App的主界面。

應用有三種啟動狀態，每種狀態都會影響應用向用戶顯示所需的時間：冷啟動、溫啟動與熱啟動。

adb命令啟動應用，一般會輸入三個值：ThisTime、TotalTime與WaitTime。
1.WaitTime：包括前一個應用Activitypause的時間和新應用啟動的時間；
2.ThisTime：表示一連串啟動Activity的最後一個Activity的啟動耗時；
3.TotalTime：表示新應用啟動的耗時，包括新進程的啟動和Activity的啟動，但不包括前一個應用Activitypause
的耗時。

StrictMode是一個開發人員工具，它可以檢測出我們可能無意中做的事情，並將它們提請我們注意，以便我 們能夠修復它們。 StrictMode最常用於捕獲應用程序主線程上的意外磁碟或網路訪問。幫助我們讓磁碟和網路操作遠離主線程， 可以使應用程序更加平滑、響應更快

當系統載入並啟動 App 時，需要耗費相應的時間，這樣會造成用戶會感覺到當點擊 App 圖標時會有 「延遲」 現象，
為了解決這一問題，Google 的做法是燃陸在 App 創建的過程中，先展示一個空白頁面，讓用戶體會到點擊圖標之後立
馬就有響應。
如果你的application或activity啟動的過程太慢，導致系統的BackgroundWindow沒有及時被替換，就會出現啟動
時白屏或黑屏的情況（取決於Theme主題是Dark還是Light）。

消除啟動時的黑/白屏問題，大部分App都採用自己在Theme中設置背景圖的方式來解決。

然後在Activity的onCreate方法，把Activity設置回原來的主題。

這么做，只是提高啟動的用戶體驗。並不能做到真正的加快啟動速度。