本文首發於微信公衆號“Android開發之旅”，歡迎關注

前言

本文將帶領大家來看看啓動優化相關方面的介紹以及各種優化的方法。希望你在讀完本章後會有所收穫。

相信很多同學都聽過八秒定律，八秒定律是在互聯網領域存在的一個定律，即指用戶訪問一個網站時，如果等待網頁打開的時間超過了8秒，就有超過70%的用戶放棄等待。足見啓動的時間是多麼的重要。放到移動APP中，那就是應用啓動的時間不能太久，否則就會造成用戶的流失。

谷歌官方曾給出一篇App startup time的文章，這篇文章詳細介紹了關於啓動優化的切入點以及思路。感興趣的同學可以去看下。App Startup Time 這是官方地址。本篇文章也主要是官方思路的一個擴展。

啓動分類

App的啓動主要分爲：冷啓動、熱啓動和溫啓動。

冷啓動：

耗時最多，也是整個應用啓動時間的衡量標準。我們通過一張圖來看下冷啓動經歷的流程：

熱啓動：

啓動最快，應用直接由後臺切換到前臺。

溫啓動：

啓動較快，是介於冷啓動和熱啓動之間的一種啓動方式，溫啓動只會執行Activity相關的生命週期方法，不會執行進程的創建等操作。

我們優化的方向和重點主要是冷啓動。因爲它纔是代表了應用從被用戶點擊到最後的頁面繪製完成所耗費的所有時間。下面我們通過一張流程圖來看下冷啓動相關的任務流程：

看上面的任務的流程圖，讀者朋友們覺得哪些是我們優化的方向呢？其實我們能做的只有Application和Activity的生命週期階段，因爲其他的都是系統創建的我們沒法干預，比如：啓動App，加載空白Window，創建進程等。這裏面加載空白Window我們其實可以做一個假的優化就是使用一張啓動圖來替換空白Window，具體操作我們在下文中介紹。

啓動的測量方式

這裏主要介紹兩種方式：ADB命令和手動打點。下面我們就來看下兩者的使用以及優缺點。

ADB命令：

在Android Studio的Terminal中輸入以下命令

adb shell am start  -W packagename/[packagename].首屏Activity

執行之後控制檯中輸出如下內容：

Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.optimize.performance/.MainActivity }
Status: ok
Activity: com.optimize.performance/.MainActivity
ThisTime: 563
TotalTime: 563
WaitTime: 575
Complete

其中主要有三個字端：ThisTime、TotalTime和WaitTime，分別解釋下這三個字端的含義：

ThisTime：最後一個Activity啓動耗時

TotalTime：所有Activity啓動耗時

WaitTime：AMS啓動Activity的總耗時

ThisTime和TotalTime時間相同是因爲我們的Demo中沒有Splash界面，應用執行完Application後直接就開始了MainActivity了。所以正常情況下的啓動耗時應是這樣的：ThisTime < TotalTime < WaitTime

這就是ADB方式統計的啓動時間，細心的讀者應該能想到了就是這種方式在線下使用很方便，但是卻不能帶到線上，而且這種統計的方式是非嚴謹、精確的時間。

手動打點方式：

手動打點方式就是啓動時埋點，啓動結束埋點，取二者差值即可。

我們首先需要定義一個統計時間的工具類：

class LaunchRecord {

    companion object {

        private var sStart: Long = 0
        
        fun startRecord() {
            sStart = System.currentTimeMillis()
        }

        fun endRecord() {
            endRecord("")
        }

        fun endRecord(postion: String) {
            val cost = System.currentTimeMillis() - sStart
            println("===$postion===$cost")
        }
    }
}

啓動時埋點我們直接在Application的attachBaseContext中進行打點。那麼啓動結束應該在哪裏打點呢？這裏存在一個誤區：網上很多資料建議是在Activity的onWindowFocusChange中進行打點，但是onWindowFocusChange這個回調只是表示首幀開始繪製了，並不能表示用戶已經看到頁面數據了，我們既然做啓動優化，那麼就要切切實實的得出用戶從點擊應用圖標到看到頁面數據之間的時間差值。所以結束埋點建議是在頁面數據展示出來進行埋點。比如頁面是個列表那就是第一條數據顯示出來，或者其他的任何view的展示。


class MyApplication : Application() {
    override fun attachBaseContext(base: Context?) {
        super.attachBaseContext(base)
        //開始打點
        LaunchRecord.startRecord()
    }
}

我們分別監聽頁面view的繪製完成時間和onWindowFocusChanged回調兩個值進行對比。


class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        mTextView.viewTreeObserver.addOnDrawListener {
            LaunchRecord.endRecord("onDraw")
        }

    }

    override fun onWindowFocusChanged(hasFocus: Boolean) {
        super.onWindowFocusChanged(hasFocus)
        LaunchRecord.endRecord("onWindowFocusChanged")
    }
}

打印的數據爲：

===onWindowFocusChanged===322
===onDraw===328

可以很明顯看到onDraw所需要的時長是大於onWindowFocusChanged的時間的。因爲我們這個只是簡單的數據展示沒有進行網絡相關請求和複雜佈局所以差別不大。

這裏需要說明下：addOnDrawListener 需要大於API 16纔可以使用，如果爲了兼顧老版本用戶可以使用addOnPre DrawListener來代替。

手動打點方式統計的啓動時間比較精確而且可以帶到線上使用，推薦這種方式。但在使用的時候要避開一個誤區就是啓動結束的埋點我們要採用Feed第一條數據展示出來來進行統計。同時addOnDrawListener要求API 16，這兩點在使用的時候需要注意的。

優化工具的選擇

在做啓動優化的時候我們可以藉助三方工具來更好的幫助我們理清各個階段的方法或者線程、CPU的執行耗時等情況。主要介紹以下兩個工具，我在這裏就簡單介紹下，讀者朋友們可以線下自己取嘗試下。

TraceView：

TraceView是以圖形的形式展示執行時間、調用棧等信息，信息比較全面，包含所有線程。

使用：

開始：Debug.startMethodTracing("name" )
結束：Debug.stopMethodTracing("" )

最後會生成一個文件在SD卡中，路徑爲：Andrid/data/packagename/files。

因爲traceview收集的信息比較全面，所以會導致運行開銷嚴重，整體APP的運行會變慢，這就有可能會帶偏我們優化的方向，因爲我們無法區分是不是traceview影響了啓動時間。

SysTrace：

Systrace是結合Android內核數據，生成HTML報告，從報告中我們可以看到各個線程的執行時間以及方法耗時和CPU執行時間等。API 18以上使用，推薦使用TraceCompat，因爲這是兼容的API。

使用：

開始：TraceCompat.beginSection("tag ")
結束：TraceCompat.endSection()

然後執行腳本：

python systrace.py -b 32768 -t 10 -a packagename -o outputfile.html sched gfx view wm am app

給大家解釋下各個字端的含義：

-b 收集數據的大小
-t 時間
-a 監聽的應用包名
-o 生成文件的名稱

Systrace開銷較小，屬於輕量級的工具，並且可以直觀反映CPU的利用率。這裏需要說明下在生成的報告中，當你看某個線程執行耗時時會看到兩個字端分別好似walltime和cputime，這兩個字端給大家解釋下就是walltime是代碼執行的時間，cputime是代碼真正消耗cpu的執行時間，cputime纔是我們優化的重點指標。這點很容易被大家忽視。

優雅獲取方法耗時

上文中主要是講解了如何監聽整體的應用啓動耗時，那麼我們如何識別某個方法所執行的耗時呢？

我們常規的做法和上文中一樣也是打點，如：

public class MyApp extends Application {

    @Override
    public void onCreate() {
        super.onCreate();

        initFresco();
        initBugly();
        initWeex();
    }

    private void initWeex(){
        LaunchRecord.Companion.startRecord();
        InitConfig config = new InitConfig.Builder().build();
        WXSDKEngine.initialize(this, config);
        LaunchRecord.Companion.endRecord("initWeex");
    }

    private void initFresco() {
        LaunchRecord.Companion.startRecord();
        Fresco.initialize(this);
        LaunchRecord.Companion.endRecord("initFresco");
    }

    private void initBugly() {
        LaunchRecord.Companion.startRecord();
        CrashReport.initCrashReport(getApplicationContext(), "註冊時申請的APPID", false);
        LaunchRecord.Companion.endRecord("initBugly");
    }
}

控制檯打印：

=====initFresco=====278
=====initBugly=====76
=====initWeex=====83

但是這種方式導致代碼不夠優雅，並且侵入性強而且工作量大，不利於後期維護和擴展。

下面我給大家介紹另外一種方式就是AOP。AOP是面向切面變成，針對同一類問題的統一處理，無侵入添加代碼。

我們主要使用的是AspectJ框架，在使用之前呢給大家簡單介紹下相關的API：

Join Points 切面的地方：函數調用、執行，獲取設置變量，類初始化
PointCut：帶條件的JoinPoints
Advice：Hook 要插入代碼的位置。
Before：PointCut之前執行
After：PointCut之後執行
Around：PointCut之前之後分別執行

具體代碼如下：

@Aspect
public class AOPJava {

    @Around("call(* com.optimize.performance.MyApp.**(..))")
    public void applicationFun(ProceedingJoinPoint joinPoint) {

        Signature signature = joinPoint.getSignature();
        String name = signature.toShortString();
        long time = System.currentTimeMillis();
        try {
            joinPoint.proceed();
        } catch (Throwable throwable) {
            throwable.printStackTrace();
        }

        Log.d("AOPJava", name + " == cost ==" + (System.currentTimeMillis() - time));

    }
}

控制檯打印結果如下：

MyApp.initFresco() == cost ==288
MyApp.initBugly() == cost ==76
MyApp.initWeex() == cost ==85

但是我們沒有在MyApp中做任何改動，所以採用AOP的方式來統計方法耗時更加方便並且代碼無侵入性。具體AspectJ的使用學習後續文章來介紹。

異步優化

上文中我們主要是講解了一些耗時統計的方法策略，下面我們就來具體看下如何進行啓動耗時的優化。

在啓動分類中我們講過應用啓動任務中有一個空白window，這是可以作爲優化的一個小技巧就是Theme的切換，使用一個背景圖設置給Activity，當Activity打開後再將主題設置回來，這樣會讓用戶感覺很快。但其實從技術角度講這種優化並沒有效果，只是感官上的快。

首先現在res/drawable中新建lanucher.xml文件：

<layer-list xmlns:android="http://schemas.android.com/apk/res/android"
    android:opacity="opaque">
    <item android:drawable="@android:color/white"/>
    <item>
        <bitmap
            android:src="@mipmap/你的圖片"
            android:gravity="fill"/>
    </item>
</layer-list>

將其設置給第一個打開的Activity，如MainActivity：

<activity android:name=".MainActivity"
    android:theme="@style/Theme.Splash">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

最後在MainActivity中的onCreate的spuer.onCreate()中將其設置會原來的主題：

override fun onCreate(savedInstanceState: Bundle?) {
        setTheme(R.style.AppTheme)
        super.onCreate(savedInstanceState)
        }

    }

這樣就完成了Theme主題的切換。

下面我們說下異步優化，異步優化顧名思義就是採用異步的方式進行任務的初始化。新建子線程（線程池）分擔主線稱任務併發的時間，充分利用CPU。

如果使用線程池那麼設置多少個線程合適呢？這裏我們參考了AsyncTask源碼中的設計，獲取可用CPU的數量，並且根據這個數量計算一個合理的數值。

    private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
    private static final int CORE_POOL_SIZE = Math.max(2, Math.min(CPU_COUNT - 1, 4));

    @Override
    public void onCreate() {
        super.onCreate();

        ExecutorService pool = Executors.newFixedThreadPool(CORE_POOL_SIZE);

        pool.submit(new Runnable() {
            @Override
            public void run() {
                initFresco(); 
            }
        });

        pool.submit(new Runnable() {
            @Override
            public void run() {
                initBugly();
            }
        });

        pool.submit(new Runnable() {
            @Override
            public void run() {
                initWeex();
            }
        });

    }

這樣我們就將所有的任務進行異步初始化了。我們看下未異步的時間和異步的對比：

未異步時間：======210
異步的時間：======3

可以看出這個時間差還是比較明顯的。這裏還有另外一個問題就是，比如異步初始化Fresco，但是在MainActivity一加載就要使用而Fresco是異步加載的有可能這時候還沒有加載完成，這樣就會拋異常了，怎麼辦呢？這裏教大家一個新的技巧就是使用CountDownLatch，如：

   private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
   private static final int CORE_POOL_SIZE = Math.max(2, Math.min(CPU_COUNT - 1, 4));

    //1表示要被滿足一次countDown
    private CountDownLatch mCountDownLatch = new CountDownLatch(1);

    @Override
    public void onCreate() {
        super.onCreate();

        ExecutorService pool = Executors.newFixedThreadPool(CORE_POOL_SIZE);

        pool.submit(new Runnable() {
            @Override
            public void run() {
                initFresco();
                //調用一次countDown
                mCountDownLatch.countDown();
            }
        });

        pool.submit(new Runnable() {
            @Override
            public void run() {
                initBugly();
            }
        });

        pool.submit(new Runnable() {
            @Override
            public void run() {
                initWeex();
            }
        });

        try {
            //如果await之前沒有調用countDown那麼就會一直阻塞在這裏
            mCountDownLatch.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

    }

這樣就會一直阻塞在await這裏，直到Fresco初始化完成。

以上這種方式大家覺得如何呢？可以解決異步問題，但是我的Demo中只有三個需要初始化的任務，在我們真實的項目中可不止，所以在項目中我們需要書寫很多的子線程代碼，這樣顯然是不夠優雅的。部分代碼需要在初始化的時候就要完成，雖然可以使用countDowmLatch，但是任務較多的話，也是比較麻煩的，另外就是如果任務之間存在依賴關係，這種使用異步就很難處理了。

針對上面這些問題，我給大家介紹一種新的異步方式就是啓動器。核心思想就是充分利用CPU多核，自動梳理任務順序。核心流程：

任務代碼Task化，啓動邏輯抽象爲Task
根據所有任務依賴關係排序生成一個有向無環圖
多線程按照排序後的優先級依次執行

TaskDispatcher.init(PerformanceApp.)TaskDispatcher dispatcher = TaskDispatcher.createInstance()dispatcher.addTask(InitWeexTask())
        .addTask(InitBuglyTask())
        .addTask(InitFrescoTask())
        .start()dispatcher.await()LaunchTimer.endRecord()

最後代碼會變成這樣，具體的實現有向無環圖邏輯因爲代碼量很多，不方便貼出來，大家可以關注公衆號獲取。

使用有向無環圖可以很好的梳理出每個任務的執行邏輯，以及它們之間的依賴關係

延遲初始化

關於延遲初始化方案這裏介紹兩者方式，一種是比較常規的做法，另外一個是利用IdleHandler來實現。

常規做法就是在Feed顯示完第一條數據後進行異步任務的初始化。比如：

override fun onCreate(savedInstanceState: Bundle?) {
        setTheme(R.style.AppTheme)
        super.onCreate(savedInstanceState)
        
        mTextView.viewTreeObserver.addOnDrawListener {
            // initTask()
        }

    }

這裏有個問題就是更新UI是在Main線程執行的，所以做初始化任務等耗時操作時會發生UI的卡頓，這時我們可以使用Handler.postDelay(),但是delay多久呢？這個時間是不好控制的。所以這種常規的延遲初始化方案有可能會導致頁面的卡頓，並且延遲加載的時機不好控制。

IdleHandler方式就是利用其特性，只有CPU空閒的時候纔會執行相關任務，並且我們可以分批進行任務初始化，可以有效緩解界面的卡頓。代碼如下：

public class DelayInitDispatcher {

    private Queue<Task> mDelayTasks = new LinkedList<>();

    private MessageQueue.IdleHandler mIdleHandler = new MessageQueue.IdleHandler() {
        @Override
        public boolean queueIdle() {
            if (mDelayTasks.size() > 0) {
                Task task = mDelayTasks.poll();
                new DispatchRunnable(task).run();
            }
            return !mDelayTasks.isEmpty();
        }
    };

    public DelayInitDispatcher addTask(Task task) {
        mDelayTasks.add(task);
        return this;
    }

    public void start() {
        Looper.myQueue().addIdleHandler(mIdleHandler);
    }

}

我們在界面顯示的後進行調用：

override fun onCreate(savedInstanceState: Bundle?) {
        setTheme(R.style.AppTheme)
        super.onCreate(savedInstanceState)
        
        mTextView.viewTreeObserver.addOnDrawListener {
            val delayInitDispatcher = DelayInitDispatcher()
            delayInitDispatcher.addTask(DelayInitTaskA())
                    .addTask(DelayInitTaskB())
                    .start()
        }
    }

這樣就可以利用系統空閒時間來延遲初始化任務了。

懶加載

懶加載就是有些Task只有在特定的頁面纔會使用，這時候我們就沒必要將這些Task放在Application中初始化了，我們可以將其放在進入頁面後在進行初始化。

其他方案

提前加載SharedPreferences，當我們項目的sp很大的時候初次加載很耗內存和時間的，我們可以將其提前在初始化Multidex（如果使用的話）之前進行初始化，充分利用此階段的CPU。

啓動階段不啓動子進程，子進程會共享CPU資源，導致主CPU資源緊張，另外一點就是在Application生命週期中也不要啓動其他的組件如：service、contentProvider。

異步類加載方式，如何確定哪些類是需要提前異步加載呢？這裏我們可以自定義classload，替換掉系統的classload，在我們的classload中打印日誌，每個類在加載的時候都會觸發的log日誌，然後在項目中運行一遍，這樣就拿到了所有需要加載的類了，這些就是需要我們異步加載的類。

Class.forName()只加載類本身及其靜態變量的引用類
new實例可以額外加載類成員的引用類

總結

本文主要是講解了啓動耗時的檢測，從整體流程的耗時到各個方法的耗時以及線程的耗時，也介紹了工具的選擇和使用，介紹了啓動時間的優化，異步加載、延遲加載、懶加載等等，從常規方法到更優解，講解了很多方式方法，希望能給大家提供一些新的思路和解決問題的方式。也希望大家能在自己的項目中實戰總結。

Android性能優化之啓動優化實戰

前言

啓動分類

冷啓動：

熱啓動：

溫啓動：

啓動的測量方式

ADB命令：

手動打點方式：

優化工具的選擇

TraceView：

SysTrace：

優雅獲取方法耗時

異步優化

延遲初始化

懶加載

其他方案

總結

掃描下方二維碼關注公衆號，及時獲取文章推送。

《Python進階》學習筆記

Leetcode 3161. 物塊放置查詢

leetcode 60 排列序列

一個docker容器暴露多個端口

微服務實踐之使用 Visual Studio 2022 調試Dapr 應用程序

wpf附加屬性理解 WPF附加屬性

kotlin協程在Android中的使用(Jetpack中的協程和Retrofit中的協程)

Flutter混合開發(一)：Android項目集成Flutter模塊詳細指南

Flutter開發必備Dart基礎：Dart快速入門

Android性能優化之啓動優化實戰

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結