本文首發于微信公衆号「Android開發之旅」，歡迎關注

Jetpack版Wan-Android項目位址：Android Jetpack架構開發元件化應用實戰歡迎star

Flutter版Wan-Android項目位址：Flutter版Wan-Android 歡迎star

前言

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

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

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

啟動分類

App的啟動主要分為：冷啟動、熱啟動和溫啟動。

冷啟動：

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

Android性能優化之啟動優化實戰前言啟動分類啟動的測量方式優化工具的選擇優雅擷取方法耗時異步優化延遲初始化懶加載其他方案總結

熱啟動：

啟動最快，應用直接由背景切換到前台。

溫啟動：

啟動較快，是介于冷啟動和熱啟動之間的一種啟動方式，溫啟動隻會執行Activity相關的生命周期方法，不會執行程序的建立等操作。

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

Android性能優化之啟動優化實戰前言啟動分類啟動的測量方式優化工具的選擇優雅擷取方法耗時異步優化延遲初始化懶加載其他方案總結

看上面的任務的流程圖，讀者朋友們覺得哪些是我們優化的方向呢？其實我們能做的隻有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性能優化之啟動優化實戰前言啟動分類啟動的測量方式優化工具的選擇優雅擷取方法耗時異步優化延遲初始化懶加載其他方案總結

Android性能優化之啟動優化實戰前言啟動分類啟動的測量方式優化工具的選擇優雅擷取方法耗時異步優化延遲初始化懶加載其他方案總結

前言

啟動分類

冷啟動：

熱啟動：

溫啟動：

啟動的測量方式

ADB指令：

手動打點方式：

優化工具的選擇

TraceView：

SysTrace：

優雅擷取方法耗時

異步優化

延遲初始化

懶加載

其他方案

總結

推薦閱讀：

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

繼續閱讀

專訪鄧凡平：深入了解Android

與專家面對面：Android開發入門問與答

Android MVP架構MVCMVP

mvp初探

Android常用工具類簡介目錄

android常用工具類轉載自：http://www.trinea.cn/android/android-common-utils/Android常用工具類

Android常用工具類ToastUtilsSizeUtilsLogUtilsRetrofitManagerAnimUtil

Android Studio 0.8.0解決 Failure [INSTALL_FAILED_OLDER_SDK] 問題

Android – ListView 中添加按鈕，動态删除添加ItemView的操作

Kotlin的ListView與RecyclerView的簡單應用

關于公司的那些坑：Android Studio篇

android SQLite事務和kotlin協程

無法正常編譯錯誤Compilation failed to complete

關于Gradle配置的小結

AOP程式設計_Android優雅權限架構(1)概念基礎，2021金三銀四前言正文大綱正文

Android APK檔案反編譯Android APK檔案反編譯