Android冷啟動優(yōu)化的3個小案例分享

更新時間：2023年07月26日 11:18:08 作者：卓修武K

為了提高App的冷啟動耗時，除了在常規(guī)的業(yè)務(wù)側(cè)進行耗時代碼優(yōu)化之外，為了進一步縮短啟動耗時，需要在純技術(shù)測做一些優(yōu)化探索，本期我們從類預加載、Retrofit 、ARouter方面進行了進一步的優(yōu)化，感興趣的同學跟著小編一起來看看吧

背景

為了提高App的冷啟動耗時，除了在常規(guī)的業(yè)務(wù)側(cè)進行耗時代碼優(yōu)化之外，為了進一步縮短啟動耗時，需要在純技術(shù)測做一些優(yōu)化探索，本期我們從類預加載、Retrofit 、ARouter方面進行了進一步的優(yōu)化。從測試數(shù)據(jù)上來看，這些優(yōu)化手段的收益有限，可能在中端機上加起來也不超過50ms的收益，但為了冷啟動場景的極致優(yōu)化，給用戶帶來更好的體驗，任何有收益的優(yōu)化手段都是值得嘗試的。

類預加載

一個類的完整加載流程至少包括加載、鏈接、初始化，而類的加載在一個進程中只會觸發(fā)一次，因此對于冷啟動場景，我們可以異步加載原本在啟動階段會在主線程觸發(fā)類加載過程的類，這樣當原流程在主線程訪問到該類時就不會觸發(fā)類加載流程。

Hook ClassLoader 實現(xiàn)

在Android系統(tǒng)中，類的加載都是通過PathClassLoader 實現(xiàn)的，基于類加載的父類委托機制，我們可以通過Hook PathClassLoader 修改其默認的parent 來實現(xiàn)。

首先我們創(chuàng)建一個MonitorClassLoader 繼承自PathClassLoader,并在其內(nèi)部記錄類加載耗時

class MonitorClassLoader(
    dexPath: String,
    parent: ClassLoader, private val onlyMainThread: Boolean = false,
) : PathClassLoader(dexPath, parent) {
    val TAG = "MonitorClassLoader"
    override fun loadClass(name: String?, resolve: Boolean): Class<*> {
    val begin = SystemClock.elapsedRealtimeNanos()
    if (onlyMainThread && Looper.getMainLooper().thread!=Thread.currentThread()){
        return super.loadClass(name, resolve)
    }
    val clazz = super.loadClass(name, resolve)
    val end = SystemClock.elapsedRealtimeNanos()
    val cost = end - begin
    if (cost > 1000_000){
        Log.e(TAG, "加載 ${clazz} 耗時 ${(end - begin) / 1000} 微秒 ,線程ID ${Thread.currentThread().id}")
    } else {
        Log.d(TAG, "加載 ${clazz} 耗時 ${(end - begin) / 1000} 微秒 ,線程ID ${Thread.currentThread().id}")
    }
    return  clazz;
}
}

之后，我們可以在Application attach階段反射替換 application實例的classLoader 對應的parent指向。

核心代碼如下：

    companion object {
        @JvmStatic
        fun hook(application: Application, onlyMainThread: Boolean = false) {
            val pathClassLoader = application.classLoader
            try {
                val monitorClassLoader = MonitorClassLoader("", pathClassLoader.parent, onlyMainThread)
                val pathListField = BaseDexClassLoader::class.java.getDeclaredField("pathList")
                pathListField.isAccessible = true
                val pathList = pathListField.get(pathClassLoader)
                pathListField.set(monitorClassLoader, pathList)
                val parentField = ClassLoader::class.java.getDeclaredField("parent")
                parentField.isAccessible = true
                parentField.set(pathClassLoader, monitorClassLoader)
            } catch (throwable: Throwable) {
                Log.e("hook", throwable.stackTraceToString())
            }
        }
    }

主要邏輯為

反射獲取原始 pathClassLoader 的 pathList
創(chuàng)建MonitorClassLoader，并反射設(shè)置正確的 pathList
反射替換原始pathClassLoader的 parent指向 MonitorClassLoader實例

這樣，我們就獲取啟動階段的加載類了

基于JVMTI 實現(xiàn)

除了通過 Hook ClassLoader的方案實現(xiàn)，我們也可以通過JVMTI 來實現(xiàn)類加載監(jiān)控。

通過注冊ClassPrepare Callback, 可以在每個類Prepare階段觸發(fā)回調(diào)。

當然這種方案，相比 Hook ClassLoader 還是要繁瑣很多，不過基于JVMTI 還可以做很多其他更強大的事。

類預加載實現(xiàn)

目前應用通常都是多模塊的，因此我們可以設(shè)計一個抽象接口，不同的業(yè)務(wù)模塊可以繼承該抽象接口，定義不同業(yè)務(wù)模塊需要進行預加載的類。

/**
 * 資源預加載接口
 */
public interface PreloadDemander {
    /**
     * 配置所有需要預加載的類
     * @return
     */
    Class[] getPreloadClasses();
}

之后在啟動階段收集所有的 Demander實例，并觸發(fā)預加載

/**
 * 類預加載執(zhí)行器
 */
object ClassPreloadExecutor {
    private val demanders = mutableListOf<PreloadDemander>()
    fun addDemander(classPreloadDemander: PreloadDemander) {
        demanders.add(classPreloadDemander)
    }
    /**
     * this method shouldn't run on main thread
     */
    @WorkerThread fun doPreload() {
        for (demander in localDemanders) {
            val classes = demander.preloadClasses
            classes.forEach {
                val classLoader = ClassPreloadExecutor::class.java.classLoader
                Class.forName(it.name, true, classLoader)
    			}
			}
    }
}

收益

第一個版本配置了大概90個類，在終端機型測試數(shù)據(jù)顯示這些類的加載需要消耗30ms左右的cpu時間，不同類加載的消耗時間差異主要來自于類的復雜度比如繼承體系、字段屬性數(shù)量等，以及類初始化階段的耗時，比如靜態(tài)成員變量的立即初始化、靜態(tài)代碼塊的執(zhí)行等。

方案優(yōu)化思考

我們目前的方案配置的具體類列表來源于手動配置，這種方案的弊端在于，類的列表需要開發(fā)維護，在版本快速迭代變更的情況下維護成本較大，并且對于一些大型App，存在著非常多的AB實驗條件，這也可能導致不同的用戶在類加載上是會有區(qū)別的。

在前面的小節(jié)中，我們介紹了使用自定義的 ClassLoader可以手動收集啟動階段主線程的類列表，那么我們是否可以在端上每次啟動時自動收集加載的類，如果發(fā)現(xiàn)這個類不在現(xiàn)有的名單中則加入到名單，在下次啟動時進行預加載。當然具體的策略還需要做詳細設(shè)計，比如控制預加載名單的列表大小，被加入預加載名單的類最低耗時閾值，淘汰策略等等。

Retrofit ServiceMethod 預解析注入

背景

Retrofit 是目前最常用的網(wǎng)絡(luò)庫框架，其基于注解配置的網(wǎng)絡(luò)請求方式及Adapter的設(shè)計模式大大簡化了網(wǎng)絡(luò)請求的調(diào)用方式。不過其并沒有采用類似APT的方式在編譯時生成請求代碼，而是采用運行時解析的方式。

當我們調(diào)用Retrofit.create(final Class service) 函數(shù)時，會生成一個該抽象接口的動態(tài)代理實例。

接口的所有函數(shù)調(diào)用都會被轉(zhuǎn)發(fā)到該動態(tài)代理對象的invoke函數(shù)，最終調(diào)用loadServiceMethod(method).invoke 調(diào)用。

在loadServiceMethod函數(shù)中，需要解析原函數(shù)上的各種元信息，包括函數(shù)注解、參數(shù)注解、參數(shù)類型、返回值類型等信息，并最終生成ServiceMethod 實例，對原接口函數(shù)的調(diào)用其實最終觸發(fā)的是這個生成的ServiceMethod invoke函數(shù)的調(diào)用。

從源碼實現(xiàn)上可以看出，對ServiceMethod的實例做了緩存處理，每個Method 對應一個ServiceMethod。

耗時測試

這里我模擬了一個簡單的 Service Method，并調(diào)用archiveStat 觀察首次調(diào)用及其后續(xù)調(diào)用的耗時，注意這里的調(diào)用還未觸發(fā)網(wǎng)絡(luò)請求，其返回的是一個Call對象。

從測試結(jié)果上看，首次調(diào)用需要觸發(fā)需要消耗1.7ms,而后續(xù)的調(diào)用只需要消耗50微妙左右。

優(yōu)化方案

由于首次調(diào)用接口函數(shù)需要觸發(fā)ServiceMethod實例的生成，這個過程比較耗時，因此優(yōu)化思路也比較簡單，收集啟動階段會調(diào)用的函數(shù)，提前生成ServiceMethod實例并寫入到緩存中。

serviceMethodCache 的類型本身是ConcurrentHashMap,所以它是并發(fā)安全的。

但是源碼中進行ServiceMethod緩存判斷的時候還是以 serviceMethodCache為Lock Object 進行了加鎖，這導致多線程觸發(fā)同時首次觸發(fā)不同Method的調(diào)用時，存在鎖等待問題

這里首先需要理解為什么這里需要加鎖，其目的也是因為parseAnnotations 是一個好事操作，這里是為了實現(xiàn)類似 putIfAbsent的完全原子性操作。但實際上這里加鎖可以以對應的Method類型為鎖對象，因為本身不同Method 對應的ServiceMethod實例就是不同的。我們可以修改其源碼的實現(xiàn)來避免這種場景的鎖競爭問題。

當然針對我們的優(yōu)化場景，其實不修改源碼也是可以實現(xiàn)的，因為 ServiceMethod.parseAnnotations 是無鎖的，畢竟它是一個純函數(shù)。因此我們可以在異步線程調(diào)用parseAnnotations 生成ServiceMethod 實例，之后通過反射寫入 Retrofit實例的 serviceMethodCache 中。這樣存在的問題是不同線程可能同時觸發(fā)了一個Method的解析注入，但由于serviceMethodCache 本身就是線程安全的，所以它只是多做了一次解析，對最終結(jié)果并無影響。

ServiceMethod.parseAnnotations是包級私有的，我們可以在當前工程創(chuàng)建一個一樣的包，這樣就可以直接調(diào)用該函數(shù)了。核心實現(xiàn)代碼如下

package retrofit2
import android.os.Build
import timber.log.Timber
import java.lang.reflect.Field
import java.lang.reflect.Method
import java.lang.reflect.Modifier
object RetrofitPreloadUtil {
    private var loadServiceMethod: Method? = null
    var initSuccess: Boolean = false
    //    private var serviceMethodCacheField:Map<Method,ServiceMethod<Any>>?=null
    private var serviceMethodCacheField: Field? = null
    init {
        try {
            serviceMethodCacheField = Retrofit::class.java.getDeclaredField("serviceMethodCache")
            serviceMethodCacheField?.isAccessible = true
            if (serviceMethodCacheField == null) {
                for (declaredField in Retrofit::class.java.declaredFields) {
                    if (Map::class.java.isAssignableFrom(declaredField.type)) {
                        declaredField.isAccessible =true
                        serviceMethodCacheField = declaredField
                        break
                    }
                }
            }
            loadServiceMethod = Retrofit::class.java.getDeclaredMethod("loadServiceMethod", Method::class.java)
            loadServiceMethod?.isAccessible = true
        } catch (e: Exception) {
            initSuccess = false
        }
    }
    /**
     * 預加載 目標service 的 相關(guān)函數(shù)，并注入到對應retrofit實例中
     */
    fun preloadClassMethods(retrofit: Retrofit, service: Class<*>, methodNames: Array<String>) {
        val field = serviceMethodCacheField ?: return
        val map = field.get(retrofit) as MutableMap<Method,ServiceMethod<Any>>
        for (declaredMethod in service.declaredMethods) {
            if (!isDefaultMethod(declaredMethod) && !Modifier.isStatic(declaredMethod.modifiers)
                && methodNames.contains(declaredMethod.name)) {
                try {
                    val parsedMethod = ServiceMethod.parseAnnotations<Any>(retrofit, declaredMethod) as ServiceMethod<Any>
                    map[declaredMethod] =parsedMethod
                } catch (e: Exception) {
                    Timber.e(e, "load method $declaredMethod for class $service failed")
                }
            }
        }
    }
    private fun isDefaultMethod(method: Method): Boolean {
        return Build.VERSION.SDK_INT >= 24 && method.isDefault;
    }
}