當(dāng)前位置：首頁(yè) > 运维知识 > Android >内容正文

Android

Android开机速度优化（第三篇）

發(fā)布時(shí)間：2023/12/14 Android 42 豆豆

生活随笔收集整理的這篇文章主要介紹了 Android开机速度优化（第三篇）小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

參考地址：https://www.jianshu.com/p/6dba42c022a9

問題描述

開機(jī)時(shí)間相對(duì)參考機(jī)過慢，大約慢15s左右。Android 系統(tǒng)7.0。

問題分析

開機(jī)問題涉及的層次較多，大致有bootloader-->kernel-->Zygote-->PMS-->AMS-->Launcher
可以借助bootchart來分析，也可以直接通過log分析。不幸的是本項(xiàng)目機(jī)器因未知原因?qū)е聼o(wú)法抓取到bootchart。
幸好在我瀏覽源碼時(shí)發(fā)現(xiàn)了一個(gè)神器perfboot工具。具體在system/core/init/perfboot.py。
運(yùn)行該命令需要在源碼編譯環(huán)境下。詳細(xì)請(qǐng)參考源碼文件，此處不做過多介紹。
使用命令：
./perfboot.py --iterations=5 --interval=30 -v --output=/data/My_Doc/Performance/Bugs/bootup_op_4200151/J5D_UE.tsv
獲取問題機(jī)與參考機(jī)的開機(jī)數(shù)據(jù)。生成下圖

參考機(jī)vs問題機(jī)

上圖X軸是開機(jī)啟動(dòng)過程中的一些重要節(jié)點(diǎn)。Y軸是開機(jī)時(shí)間。
詳細(xì)說明下X軸上各個(gè)節(jié)點(diǎn)表征的含義。

bootloader 優(yōu)化

這一塊沒有接觸過，交給底層同事優(yōu)化。大概說下抓取log的方式.

adb shell cat /proc/bootmsg > bootmsg.txt.

從log里底層同事發(fā)現(xiàn)是bootimg簽名有問題，更詳細(xì)的分析，自己對(duì)這塊真心不懂，總結(jié)不出幫助性的意見。

kernel層優(yōu)化

kernel的優(yōu)化先check一遍config的配置，kernel中config的配置種類繁多，就算是工作幾年的kernel工程師也不一定能清楚每一個(gè)config值的作用。Android提供了一個(gè)基礎(chǔ)配置表。
可以用腳本：kernel/scripts/kconfig/merge_config.sh來生成一份config文件。具體用法戳這
拿生成的config文件和當(dāng)前項(xiàng)目中的config做對(duì)比，同時(shí)也對(duì)比參考機(jī)的config文件。對(duì)比的時(shí)候可以用一個(gè)現(xiàn)成的工具kernel/scripts/diffconfig來比較。
綜合比較后的結(jié)果，本地一點(diǎn)點(diǎn)調(diào)試，查找資料。最終去掉了如下config：

CONFIG_MTD_TESTS=m ----> m改為n CONFIG_SERIAL_MSM_HSL=y ----> y改為n CONFIG_SERIAL_MSM_HSL_CONSOLE=y ----> y改為n CONFIG_MMC_BLOCK_TEST=m ---->注釋掉 CONFIG_MMC_TEST=m ---->注釋掉 CONFIG_SERIAL_MSM_HSL=y ----> y改為n CONFIG_SERIAL_MSM_HSL_CONSOLE=y ----> y改為n CONFIG_MSM_SMD_DEBUG=y ---->注釋掉 CONFIG_CGROUP_DEBUG=y ---->注釋掉 CONFIG_RELAY=y ---->注釋掉 CONFIG_RMNET_DATA_DEBUG_PKT=y ---->注釋掉 CONFIG_DEBUG_GPIO=y ---->注釋掉 CONFIG_CORESIGHT=y ---->注釋掉 CONFIG_CORESIGHT_EVENT=y ---->注釋掉 CONFIG_CORESIGHT_FUSE=y ---->注釋掉 CONFIG_CORESIGHT_CTI=y ---->注釋掉 CONFIG_CORESIGHT_TMC=y ---->注釋掉 CONFIG_CORESIGHT_TPIU=y ---->注釋掉 CONFIG_CORESIGHT_FUNNEL=y ---->注釋掉 CONFIG_CORESIGHT_REPLICATOR=y ---->注釋掉 CONFIG_CORESIGHT_STM=y ---->注釋掉 CONFIG_CORESIGHT_HWEVENT=y ---->注釋掉 CONFIG_DEBUG_MEMORY_INIT=y ---->注釋掉 CONFIG_DYNAMIC_DEBUG=y ---->注釋掉 //以下也全部注釋掉 CONFIG_SCHED_DEBUG CONFIG_DEBUG_KMEMLEAK CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400 CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF CONFIG_DEBUG_SPINLOCK CONFIG_DEBUG_MUTEXES CONFIG_DEBUG_ATOMIC_SLEEP CONFIG_DEBUG_STACK_USAGE CONFIG_DEBUG_LIST CONFIG_FAULT_INJECTION_DEBUG_FS CONFIG_LOCKUP_DETECTOR CONFIG_DEBUG_PAGEALLOC CONFIG_PAGE_POISONING CONFIG_RMNET_DATA_DEBUG_PKT CONFIG_MMC_PERF_PROFILING CONFIG_DEBUG_BUS_VOTER CONFIG_SLUB_DEBUG CONFIG_DEBUG_BUGVERBOSE CONFIG_ALLOC_BUFFERS_IN_4K_CHUNK CONFIG_SERIAL_CORE CONFIG_SERIAL_CORE_CONSOLE CONFIG_SERIAL_MSM_HSL CONFIG_SERIAL_MSM_HSL_CONSOLE CONFIG_MSM_TZ_LOG CONFIG_DYNAMIC_DEBUG

這里說下config的配置有y,n,m，m表示編譯成模塊，不編譯進(jìn)內(nèi)核。不配置的話相當(dāng)于n。
CONFIG_DEBUG_INFO 不能去掉，會(huì)引起CTS不過。由于config的的各項(xiàng)值可能散落在kernel的不同文件中，我們可以單獨(dú)編譯下kernel，然后去out目錄下查看obj/KERNEL_OBJ/.config 文件，這里面的配置項(xiàng)是完全的。

kernel關(guān)閉掉一些debug開關(guān)后。在新版本上復(fù)測(cè)結(jié)果如下：

優(yōu)化lk和kernel后

這里提下如何看kernel的log，
開機(jī)后用命令：adb shell dmesg > dmesg.txt抓取Log
log里面搜關(guān)鍵字"Bootloader start count"-->LK 啟動(dòng)
“Bootloader end count”-->LK 結(jié)束
"Kernel MPM timestamp"-->bootloader運(yùn)行完成

通過對(duì)bootloader和kernel的優(yōu)化，直接減少了14s左右的開機(jī)時(shí)間，可以看到優(yōu)化的效果還是比較明顯的。

frameworks層優(yōu)化

用命令: adb logcat -b events|grep boot我們過濾出啟動(dòng)階段的主要事件。

01-01 13:38:52.139 391 391 I boot_progress_start: 15452 01-01 13:38:53.329 391 391 I boot_progress_preload_start: 16641 01-01 13:38:56.675 391 391 I boot_progress_preload_end: 19989 01-01 13:38:57.020 1729 1729 I boot_progress_system_run: 20333 01-01 13:38:57.824 1729 1729 I boot_progress_pms_start: 21137 01-01 13:38:58.865 1729 1729 I boot_progress_pms_system_scan_start: 22179 01-01 13:39:08.852 1729 1729 I boot_progress_pms_data_scan_start: 32166 01-01 13:39:08.907 1729 1729 I boot_progress_pms_scan_end: 32221 01-01 13:39:10.109 1729 1729 I boot_progress_pms_ready: 33422 01-01 13:39:12.557 1729 1729 I boot_progress_ams_ready: 35871 01-01 13:39:15.189 1729 1782 I boot_progress_enable_screen: 38503 01-01 13:39:17.973 290 321 I sf_stop_bootanim: 41287 01-01 13:39:18.887 1729 1961 I wm_boot_animation_done: 42201

結(jié)合對(duì)比圖看，boot_progress_enable_screen之前問題機(jī)跟對(duì)比機(jī)各個(gè)節(jié)點(diǎn)耗時(shí)相差不大。在這里說明下，Android M上啟動(dòng)階段到boot_progress_enable_screen就結(jié)束了，而Android N上還多了sf_stop_bootanim和wm_boot_animation_done兩個(gè)事件。這也就是圖-優(yōu)化kernel后棕紅色的線條到boot_progress_enable_screen就沒有延生的原因，因?yàn)樗硎镜膮⒖紮C(jī)，而參考機(jī)正好是Android M系統(tǒng)。
從log的時(shí)間戳可以看出:
boot_progress_enable_screen--->花費(fèi)2s左右的時(shí)間到達(dá)sf_stop_bootanim--->花費(fèi)1s多時(shí)間到達(dá)wm_boot_animation_done。多出來的兩個(gè)過程總共多花接近4s的時(shí)間。
我們要重點(diǎn)看下這個(gè)過程發(fā)生了什么，為什么會(huì)多出來這近4s時(shí)間。

1.先看下boot_progress_enable_screen出現(xiàn)的位置。
它在frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

void enableScreenAfterBoot() {EventLog.writeEvent(EventLogTags.BOOT_PROGRESS_ENABLE_SCREEN,SystemClock.uptimeMillis());mWindowManager.enableScreenAfterBoot();synchronized (this) {updateEventDispatchingLocked();} }

2.sf_stop_bootanim出現(xiàn)的位置。
它在frameworks/native/services/surfaceflinger/SurfaceFlinger_hwc1.cpp。
這里特別說明下SurfaceFlinger_hwc1.cpp是SurfaceFlinger.cpp的升級(jí)版，它支持HWC 2.0，使用的是SurfaceFlinger.cpp還是SurfaceFlinger_hwc1.cpp跟平臺(tái)選擇相關(guān)。

void SurfaceFlinger::bootFinished() {...// stop boot animation// formerly we would just kill the process, but we now ask it to exit so it// can choose where to stop the animation.property_set("service.bootanim.exit", "1");const int LOGTAG_SF_STOP_BOOTANIM = 60110;LOG_EVENT_LONG(LOGTAG_SF_STOP_BOOTANIM,ns2ms(systemTime(SYSTEM_TIME_MONOTONIC))); }

3.wm_boot_animation_done出現(xiàn)的位置。
frameworks/base/services/core/java/com/android/server/wm/WindowManagerService.java

public void performEnableScreen() {...// Don't enable the screen until all existing windows have been drawn.if (!mForceDisplayEnabled && checkWaitingForWindowsLocked()) {return;}if (!mBootAnimationStopped) {// Do this one time.Trace.asyncTraceBegin(Trace.TRACE_TAG_WINDOW_MANAGER, "Stop bootanim", 0);try {IBinder surfaceFlinger = ServiceManager.getService("SurfaceFlinger");if (surfaceFlinger != null) {//Slog.i(TAG_WM, "******* TELLING SURFACE FLINGER WE ARE BOOTED!");Parcel data = Parcel.obtain();data.writeInterfaceToken("android.ui.ISurfaceComposer");surfaceFlinger.transact(IBinder.FIRST_CALL_TRANSACTION, // BOOT_FINISHEDdata, null, 0);data.recycle();}} catch (RemoteException ex) {Slog.e(TAG_WM, "Boot completed: SurfaceFlinger is dead!");}mBootAnimationStopped = true;}if (!mForceDisplayEnabled && !checkBootAnimationCompleteLocked()) {if (DEBUG_BOOT) Slog.i(TAG_WM, "performEnableScreen: Waiting for anim complete");return;}...EventLog.writeEvent(EventLogTags.WM_BOOT_ANIMATION_DONE, SystemClock.uptimeMillis());... }

找到了3個(gè)節(jié)點(diǎn)出現(xiàn)的位置，現(xiàn)在再來分析如何將這3個(gè)節(jié)點(diǎn)串聯(lián)起來。
1-->2過程： AMS的enableScreenAfterBoot調(diào)用WMS的enableScreenAfterBoot方法，在WMS中的enableScreenAfterBoot會(huì)繼續(xù)調(diào)用內(nèi)部方法performEnableScreen，該方法內(nèi)部判斷開機(jī)動(dòng)畫如果沒有停止，就調(diào)用SurfaceFlinger去停止開機(jī)動(dòng)畫

surfaceFlinger.transact(IBinder.FIRST_CALL_TRANSACTION, // BOOT_FINISHEDdata, null, 0);

這里的FIRST_CALL_TRANSACTION實(shí)際上就是BOOT_FINISHED。
frameworks/native/include/gui/ISurfaceComposer.h

class BnSurfaceComposer: public BnInterface<ISurfaceComposer> { public:enum {// Note: BOOT_FINISHED must remain this value, it is called from// Java by ActivityManagerService.BOOT_FINISHED = IBinder::FIRST_CALL_TRANSACTION,

surfaceFlinger.transact發(fā)出的調(diào)用請(qǐng)求會(huì)被ISurfaceComposer處理。
frameworks/native/libs/gui/ISurfaceComposer.cpp

status_t BnSurfaceComposer::onTransact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags) {...switch(code) {case BOOT_FINISHED: {CHECK_INTERFACE(ISurfaceComposer, data, reply);bootFinished();return NO_ERROR;}}... }

這里的bootFinished就是SurfaceFlinger_hwc1.cpp定義的bootFinished()方法，最終來到了第2個(gè)節(jié)點(diǎn)sf_stop_bootanim。
為了驗(yàn)證上述調(diào)用過程，我們添加上打印調(diào)用棧的log看看輸出。

void SurfaceFlinger::bootFinished() {const nsecs_t now = systemTime();const nsecs_t duration = now - mBootTime;ALOGI("Boot is finished (%ld ms)", long(ns2ms(duration)) );mBootFinished = true;android::CallStack stack;stack.update();stack.log("azhengye", ANDROID_LOG_DEBUG, " ");String8 strtemp = stack.toString("");ALOGD("Sunny\t%s", strtemp.string()); } --------------------------------------------------------------------------------- 04-28 12:41:15.978 308 2956 D azhengye: #00 pc 0002b761 /system/lib/libsurfaceflinger.so 04-28 12:41:15.978 308 2956 D azhengye: #01 pc 00045c9f /system/lib/libgui.so 04-28 12:41:15.978 308 2956 D azhengye: #02 pc 000310cf /system/lib/libsurfaceflinger.so 04-28 12:41:15.978 308 2956 D azhengye: #03 pc 000359b3 /system/lib/libbinder.so 04-28 12:41:15.979 308 2956 D azhengye: #04 pc 0003d159 /system/lib/libbinder.so 04-28 12:41:15.979 308 2956 D azhengye: #05 pc 0003cdb7 /system/lib/libbinder.so 04-28 12:41:15.979 308 2956 D azhengye: #06 pc 0003d2bb /system/lib/libbinder.so 04-28 12:41:15.979 308 2956 D azhengye: #07 pc 0004f5f5 /system/lib/libbinder.so 04-28 12:41:15.979 308 2956 D azhengye: #08 pc 0000e349 /system/lib/libutils.so 04-28 12:41:15.979 308 2956 D azhengye: #09 pc 000473d3 /system/lib/libc.so 04-28 12:41:15.979 308 2956 D azhengye: #10 pc 0001a0c9 /system/lib/libc.so --------------------------------------------------------------------------------- SurfaceFlinger_hwc1.cpp:312 android::SurfaceFlinger::bootFinished() ISurfaceComposer.cpp:371 android::BnSurfaceComposer::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int) SurfaceFlinger_hwc1.cpp:3103 android::SurfaceFlinger::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int) Binder.cpp:126 android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int) IPCThreadState.cpp:1111 android::IPCThreadState::executeCommand(int) IPCThreadState.cpp:445 android::IPCThreadState::getAndExecuteCommand() IPCThreadState.cpp:513 android::IPCThreadState::joinThreadPool(bool) ProcessState.cpp:63 (discriminator 1)android::PoolThread::threadLoop() Threads.cpp:751 android::Thread::_threadLoop(void*) pthread_create.cpp:198 (discriminator 1)__pthread_start(void*) clone.cpp:41 (discriminator 1)__start_thread

上述log也印證了之前的分析，至此1-->2的過程算是通了。在來看2-->3過程，在3節(jié)點(diǎn)出現(xiàn)之前還有一次判斷：

if (!mForceDisplayEnabled && !checkBootAnimationCompleteLocked()) {if (DEBUG_BOOT) Slog.i(TAG_WM, "performEnableScreen: Waiting for anim complete");return; }

這里系統(tǒng)需要去檢測(cè)開機(jī)動(dòng)畫是否還在播放，

private boolean checkBootAnimationCompleteLocked() {if (SystemService.isRunning(BOOT_ANIMATION_SERVICE)) {mH.removeMessages(H.CHECK_IF_BOOT_ANIMATION_FINISHED);mH.sendEmptyMessageDelayed(H.CHECK_IF_BOOT_ANIMATION_FINISHED,BOOT_ANIMATION_POLL_INTERVAL);return false;}return true; }

BOOT_ANIMATION_SERVICE是在初始化SurfaceFlinger時(shí)啟動(dòng)的。
frameworks/native/services/surfaceflinger/SurfaceFlinger_hwc1.cpp

void SurfaceFlinger::init() {...// start boot animationstartBootAnim(); }

順藤摸瓜來到了BootAnimation，前面分析過在SurfaceFlinger的bootFinished方法中將"service.bootanim.exit"置為了1，這個(gè)設(shè)置在BootAnimation就被讀取了。
frameworks/base/cmds/bootanimation/BootAnimation.cpp

... #define EXIT_PROP_NAME "service.bootanim.exit" ... void BootAnimation::checkExit() {// Allow surface flinger to gracefully request shutdownchar value[PROPERTY_VALUE_MAX];property_get(EXIT_PROP_NAME, value, "0");int exitnow = atoi(value);if (exitnow) {requestExit();if (mAudioPlayer != NULL) {mAudioPlayer->requestExit();}} }

跟蹤到這2-->3過程也就通暢了。在理清了該過程的調(diào)用邏輯后，問題也浮出了水面。原來之前的同事在解決一個(gè)開機(jī)進(jìn)桌面出現(xiàn)黑屏問題時(shí)，在checkExit內(nèi)部人為delay了幾秒的時(shí)間...

在排查log時(shí)還發(fā)現(xiàn)下面的錯(cuò)誤：

01-01 15:55:23.506 1865 1865 E BitmapFactory: Unable to decode stream: java.io.FileNotFoundException: /data/system/users/0/wallpaper_orig (No such file or directory)

adb shell 進(jìn)入手機(jī)發(fā)現(xiàn)確實(shí)沒有/data/system/users/0/wallpaper_orig文件。
會(huì)不會(huì)是是wallpaper異常導(dǎo)致消耗時(shí)間多余呢?
為了清晰debug在過濾下log

adb logcat -b all|grep -E "Wallpaper may change|haveWall|sf_stop_bootanim|boot_progress_enable_screen"

輸出如下log：

01-02 12:13:03.814 1851 2082 V WindowManager: Wallpaper may change! Adjusting 01-02 12:13:04.865 1851 2082 V WindowManager: Wallpaper may change! Adjusting 01-02 12:13:06.986 1851 2006 I boot_progress_enable_screen: 40388 01-02 12:13:06.988 1851 2082 V WindowManager: Wallpaper may change! Adjusting 01-02 12:13:07.052 1851 2006 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=false wallEnabled=true haveKeyguard=true 01-02 12:13:07.056 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=false wallEnabled=true haveKeyguard=true 01-02 12:13:07.184 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=false wallEnabled=true haveKeyguard=true 01-02 12:13:08.049 1851 2082 V WindowManager: Wallpaper may change! Adjusting 01-02 12:13:08.066 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=false wallEnabled=true haveKeyguard=true 01-02 12:13:08.067 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=false wallEnabled=true haveKeyguard=true 01-02 12:13:08.071 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=false wallEnabled=true haveKeyguard=true 01-02 12:13:08.072 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=false wallEnabled=true haveKeyguard=true 01-02 12:13:08.076 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=false wallEnabled=true haveKeyguard=true 01-02 12:13:09.894 1851 2082 V WindowManager: Wallpaper may change! Adjusting 01-02 12:13:09.908 1851 3413 V WindowManager: Wallpaper may change! Adjusting 01-02 12:13:10.178 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=true wallEnabled=true haveKeyguard=true 01-02 12:13:10.186 292 3736 I sf_stop_bootanim: 43587 01-02 12:13:10.191 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=true wallEnabled=true haveKeyguard=true 01-02 12:13:10.196 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=true wallEnabled=true haveKeyguard=true 01-02 12:13:10.397 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=true wallEnabled=true haveKeyguard=true

然后在做實(shí)驗(yàn)push一個(gè)wallpaper_orig到指定目錄，BitmapFactory的錯(cuò)誤雖然不見了。然而對(duì)于縮短時(shí)間并沒有什么卵用。
看來不是這個(gè)異常沒有拖慢開機(jī)速度。但我注意到

01-02 12:13:10.178 1851 2082 I WindowManager: ******** booted=true msg=false haveBoot=false haveApp=false haveWall=true wallEnabled=true haveKeyguard=true 01-02 12:13:10.186 292 3736 I sf_stop_bootanim: 43587

這段log中haveWall=true之前一直都是haveWall=false,haveWall表示系統(tǒng)Window已經(jīng)成功加載好了Wallpaper。Log中不斷的輸出
WindowManager: Wallpaper may change! Adjusting
這里究竟為什么Wallpaper會(huì)不斷的Adjusting呢?看起來一旦Wallpaper調(diào)整好就會(huì)將haveWall置true。
追蹤了下該句log在代碼中的位置：
frameworks/base/services/core/java/com/android/server/wm/WindowManagerService.java

private boolean checkWaitingForWindowsLocked() {//省略無(wú)關(guān)代碼if (DEBUG_SCREEN_ON || DEBUG_BOOT) {Slog.i(TAG_WM, "******** booted=" + mSystemBooted + " msg=" + mShowingBootMessages+ " haveBoot=" + haveBootMsg + " haveApp=" + haveApp+ " haveWall=" + haveWallpaper + " wallEnabled=" + wallpaperEnabled+ " haveKeyguard=" + haveKeyguard);}// If we are turning on the screen to show the boot message,// don't do it until the boot message is actually displayed.if (!mSystemBooted && !haveBootMsg) {return true;}// If we are turning on the screen after the boot is completed// normally, don't do so until we have the application and// wallpaper.if (mSystemBooted && ((!haveApp && !haveKeyguard) ||(wallpaperEnabled && !haveWallpaper))) {return true;}return false;}

這個(gè)checkWaitingForWindowsLocked表示是否需要等待系統(tǒng)Windows就緒。被同在WindowManagerService類中的performEnableScreen方法調(diào)用

public void performEnableScreen() {// Don't enable the screen until all existing windows have been drawn.if (!mForceDisplayEnabled && checkWaitingForWindowsLocked()) {return;} }

從注釋看performEnableScreen執(zhí)行的是激活屏幕動(dòng)作，然而在此之前需要等待系統(tǒng)必要的windows已經(jīng)被畫好了，也就是說我屏幕一旦激活了，繪制好的windows就能馬上顯示出來。否則performEnableScreen直接就退出了。
而performEnableScreen又是被同在WindowManagerService類中enableScreenAfterBoot方法調(diào)用。大致的調(diào)用過程如下：
AMS打印出boot_progress_enable_screen---->調(diào)用WMS的enableScreenAfterBoot--->調(diào)用WMS的performEnableScreen--->調(diào)用WMS的checkWaitingForWindowsLocked檢查是否可以Enable Screen，因?yàn)閃allpaper沒有準(zhǔn)備好，因此checkWaitingForWindowsLocked返回了true，進(jìn)而導(dǎo)致performEnableScreen直接返回，沒有去執(zhí)行本來要做的Enable Screen動(dòng)作。

WindowManager: Wallpaper may change! Adjusting
是在下面的code打印出來的。
frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java

// "Something has changed! Let's make it correct now." private void performSurfacePlacementInner(boolean recoveringMemory) {//省略無(wú)關(guān)代碼if (mWallpaperMayChange) {if (DEBUG_WALLPAPER_LIGHT)Slog.v(TAG, "Wallpaper may change! Adjusting");defaultDisplay.pendingLayoutChanges |= FINISH_LAYOUT_REDO_WALLPAPER;if (DEBUG_LAYOUT_REPEATS) debugLayoutRepeats("WallpaperMayChange",defaultDisplay.pendingLayoutChanges);}//省略無(wú)關(guān)代碼 }

debug調(diào)用棧如下：

1-01 21:18:30.572 2912 2962 W System.err: java.lang.Exception: print stack 01-01 21:18:30.573 2912 2962 W System.err: at com.android.server.wm.WindowManagerService.checkWaitingForWindowsLocked(WindowManagerService.java:5841) 01-01 21:18:30.574 2912 2962 W System.err: at com.android.server.wm.WindowManagerService.performEnableScreen(WindowManagerService.java:5905) 01-01 21:18:30.575 2912 2962 W System.err: at com.android.server.wm.WindowManagerService$H.handleMessage(WindowManagerService.java:8390) 01-01 21:18:30.576 2912 2962 W System.err: at android.os.Handler.dispatchMessage(Handler.java:102) 01-01 21:18:30.577 2912 2962 W System.err: at android.os.Looper.loop(Looper.java:154) 01-01 21:18:30.578 2912 2962 W System.err: at android.os.HandlerThread.run(HandlerThread.java:61) 01-01 21:18:30.578 2912 2962 W System.err: at com.android.server.ServiceThread.run(ServiceThread.java:46)

這塊沒有檢查出多余的操作，沒繼續(xù)check了。
經(jīng)過以上分析后修改代碼，最終問題機(jī)的開機(jī)速度達(dá)到了參考機(jī)的標(biāo)準(zhǔn)。性能問題是一個(gè)持續(xù)挖掘改善的過程，開機(jī)過程中還能優(yōu)化的地方肯定還有。

debug 技術(shù)說明

匯總下分析該問題時(shí)，匯集的一些debug技術(shù)。

java代碼中打印堆棧 Slog.d("azhengye", "Stack=="+new RuntimeException("azhengye debug").fillInStackTrace());
或者new Exception("print stack").printStackTrace(); 然后log中搜索"System.err:"
c++ debug: 為了在native查看函數(shù)調(diào)用棧可以在需要的地方添加如下代碼。
#include <utils/CallStack.h>
android::CallStack stack;
stack.update();
String8 strtemp = stack.toString("");
ALOGD("\t%s", strtemp.string());
過濾出的log還需要用arm-linux-androideabi-addr2line轉(zhuǎn)行下，好在有現(xiàn)成的腳本幫我們做這件事，這里一并貼出來。

#!/usr/bin/python # stack symbol parser import os import string import sys ANDROID_TARGET_OUT = os.getcwd()+"/" # addr2line tool path and symbol path addr2line_tool = 'arm-linux-androideabi-addr2line' symbol_dir = ANDROID_TARGET_OUT + '/symbols' symbol_bin = symbol_dir + '/system/bin/' symbol_lib = symbol_dir + '/system/lib/' class ReadLog: def __init__(self,filename): self.logname = filename def parse(self): f = file(self.logname,'r') lines = f.readlines() if lines != []: print 'read file ok' else: print 'read file failed' result =[] for line in lines: if line.find('stack') != -1: print 'stop search' break elif line.find('system') != -1: #print 'find one item' + line result.append(line) return result class ParseContent: def __init__(self,addr,lib): self.address = addr # pc address self.exename = lib # executable or shared library def addr2line(self): cmd = addr2line_tool + " -C -f -s -e " + symbol_dir + self.exename + " " + self.address #print cmd stream = os.popen(cmd) lines = stream.readlines(); list = map(string.strip,lines) return list inputarg = sys.argv if len(inputarg) < 2: print 'Please input panic log' exit() filename = inputarg[1] readlog = ReadLog(filename) inputlist = readlog.parse() for item in inputlist: itemsplit = item.split() test = ParseContent(itemsplit[-2],itemsplit[-1]) list = test.addr2line() print "%-30s%s" % (list[1],list[0])

在源碼編譯的imge文件夾下執(zhí)行上面的腳本，調(diào)試 SF 的bootFinished就用的該腳本，下面是個(gè)輸出例子。

01-02 01:38:13.305 477 3072 D azhengye : #00 pc 000059b9 /system/bin/bootanimation 01-02 01:38:13.305 477 3072 D azhengye : #01 pc 00006515 /system/bin/bootanimation 01-02 01:38:13.305 477 3072 D azhengye : #02 pc 0000591f /system/bin/bootanimation 01-02 01:38:13.305 477 3072 D azhengye : #03 pc 000054f1 /system/bin/bootanimation 01-02 01:38:13.305 477 3072 D azhengye : #04 pc 0000e349 /system/lib/libutils.so 01-02 01:38:13.305 477 3072 D azhengye : #05 pc 000473d3 /system/lib/libc.so 01-02 01:38:13.305 477 3072 D azhengye : #06 pc 0001a0c9 /system/lib/libc.so ------------------------------------------------------------------------------------ python panic.py /data/My_Doc/Performance/boot_c_log read file ok BootAnimation.cpp:534 android::BootAnimation::checkExit() BootAnimation.cpp:972 android::BootAnimation::playAnimation(android::BootAnimation::Animation const&) BootAnimation.cpp:870 android::BootAnimation::movie() BootAnimation.cpp:452 android::BootAnimation::threadLoop() Threads.cpp:751 android::Thread::_threadLoop(void*) pthread_create.cpp:198 (discriminator 1)__pthread_start(void*) clone.cpp:41 (discriminator 1)__start_thread

堆棧dump
adb shell kill -3 <pid>

輸出的trace會(huì)保存在 /data/anr/traces.txt文件中。這個(gè)需要注意，如果沒有 /data/anr/這個(gè)目錄或/data/anr/traces.txt這個(gè)文件，需要手工創(chuàng)建一下，并設(shè)置好讀寫權(quán)限。如果是native thread的堆棧打印，可能需要修改dalvik/vm/Thread.cpp的dumpNativeThread方法。

debuggerd coredump 這個(gè)是開始分析問題查資料找到的debug方法，不過自己沒有實(shí)踐，僅作記錄參考。
debuggerd是android的一個(gè)daemon進(jìn)程，負(fù)責(zé)在進(jìn)程異常出錯(cuò)時(shí)，將進(jìn)程的運(yùn)行時(shí)信息dump出來供分析。debuggerd生成的coredump數(shù)據(jù)是以文本形式呈現(xiàn)，被保存在 /data/tombstone/ 目錄下，它可以在不中斷進(jìn)程執(zhí)行的情況下打印當(dāng)前進(jìn)程的native堆棧。使用方法是:

debuggerd -b <pid>

這可以協(xié)助我們分析進(jìn)程執(zhí)行行為，也可以用來定位native進(jìn)程中鎖死或錯(cuò)誤邏輯引起的死循環(huán)的代碼位置。

總結(jié)

各家廠商都會(huì)定制不同的開機(jī)行為，因此沒有一個(gè)固定的方法能fix所有的開機(jī)問題，但通過本文我們總結(jié)分析該類問題的套路，那就是關(guān)注boot階段的各個(gè)event事件，先量化出開機(jī)慢在哪里，然后在去針對(duì)性的優(yōu)化。
源碼真的是個(gè)寶庫(kù)，多讀吧。

作者：小草凡
鏈接：https://www.jianshu.com/p/6dba42c022a9
來源：簡(jiǎn)書
簡(jiǎn)書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請(qǐng)聯(lián)系作者獲得授權(quán)并注明出處。

總結(jié)

以上是生活随笔為你收集整理的Android开机速度优化（第三篇）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇： [转帖]从 2G 到 5G，手机上网话语
下一篇： android 键盘自动消失,Andr

日韩av黄I国产麻豆传媒I国产91av视频在线观看I日韩一区二区三区在线看I美女国产在线I麻豆视频国产在线观看I成人黄色短片

Android

Android开机速度优化（第三篇）

參考地址：https://www.jianshu.com/p/6dba42c022a9

問題描述

問題分析

bootloader 優(yōu)化

kernel層優(yōu)化

frameworks層優(yōu)化

debug 技術(shù)說明

總結(jié)

總結(jié)