App启动优化

2020-03-21 本文已影响0人 Liuqc

异步加载

建议使用IntentService，内部会创建个HandlerThread加载完成后会调用stopSelf方法

延迟加载

可以把一些不需要及时初始化的第三方sdk以及网络请求,放在IdelHandle队列中

启动页布局优化

在主题中设置android:windowBackground为启动页drawable，主要是防止一些低端机器，启动时间过长，出现黑屏或者白屏现象

主页面优化

布局层次优化，尽量减少嵌套
过度绘制优化
复杂布局异步加载
布局懒加载
耗时异步加载

启动阶段尽量不启动子进程

子进程会共享CPU资源，导致主进程CPU紧张。此外，在多进程情况下一定要可以在onCreate中去区分进程做一些初始化工作。如果必须要启动子进程，一定要在Application的onCreate方法中判断需要初始化的资源

SharedPreferences优化

使用apply代替commit
禁止使用SharedPreferences保存大量数据，大数据可以使用数据库保存

线程优化

线程过多会导致cpu频繁切换,降低线程运行效率

控制线程数量
统一的线程池
注意线程中的锁，是否可以引起锁的等待、死锁
根据需要正确的设置优先

页面数据预加载

在主页空闲时，将其它页面的数据加载好保存到内存或数据库，等到打开该页面时，判断已经预加载过，就直接从内存或数据库取数据并显示。

注意启动顺序

ContentProvider在使用 android:multiprocess="true"，会随应用一起启动，这种方式可以用来初始化我们一些资源，但是有个注意点ContentProvider是在Application的attechContext之后再onCreate之前初始化的

private void handleBindApplication(AppBindData data) {
    ...
     Application app;
        final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskWrites();
        final StrictMode.ThreadPolicy writesAllowedPolicy = StrictMode.getThreadPolicy();
        try {
            //通过反射方式创建application对象，调用attach方法
            app = data.info.makeApplication(data.restrictedBackupMode, null);

            // Propagate autofill compat state
            app.setAutofillCompatibilityEnabled(data.autofillCompatibilityEnabled);

            mInitialApplication = app;

            // don't bring up providers in restricted mode; they may depend on the
            // app's custom Application class
            if (!data.restrictedBackupMode) {
                if (!ArrayUtils.isEmpty(data.providers)) {
                   //初始化ContentProvider
                   installContentProviders(app, data.providers);
                    // For process that contains content providers, we want to
                    // ensure that the JIT is enabled "at some point".
                    mH.sendEmptyMessageDelayed(H.ENABLE_JIT, 10*1000);
                }
            }

            // Do this after providers, since instrumentation tests generally start their
            // test thread at this point, and we don't want that racing.
            try {
                mInstrumentation.onCreate(data.instrumentationArgs);
            }
    ...
}

MuiltDex优化

这方面的优化主要针对于Android5.0以下机型

方案一：
首先把启动时必须加载的类放在主dex中，另外启动子进程去加载其他dex，主进程此时开启自旋锁，等到子进程加载完成后，通知主进程取消自旋继续执行。这用方案可以有效的避免ANR，但是需要创建子进程，无意之间又增加启动耗时
方案二：
把必须加载的类全部分到主dex,其他dex进行懒加载。此方案不适用启动业务多的情况
方案三：
判断当前dex是否已经dexopt优化过，如果优化过直接加载，否则放在子线程去加载。总的来说，这种方案用户体验较好，缺点在于太过复杂，每次都需重新扫描依赖集，而且使用的是比较大的间接依赖集
方案四：
通过阅读源码可知，当dexclassload加载dex时，会调用dexopt去优化dex生成odex,这个过程是比较耗时的，如果能直接加载dex，然后在启动完成空闲时开启一个子线程去执行这一过程。在源码得知Dalvik_dalvik_system_DexFile_openDexFile_bytearray可以直接加载dex返回cooked

const DalvikNativeMethod dvm_dalvik_system_DexFile[] = {
    { "openDexFile",        "(Ljava/lang/String;Ljava/lang/String;I)I",
        Dalvik_dalvik_system_DexFile_openDexFile },
    { "openDexFile",        "([B)I",
        Dalvik_dalvik_system_DexFile_openDexFile_bytearray },
    { "closeDexFile",       "(I)V",
        Dalvik_dalvik_system_DexFile_closeDexFile },
    { "defineClass",        "(Ljava/lang/String;Ljava/lang/ClassLoader;I)Ljava/lang/Class;",
        Dalvik_dalvik_system_DexFile_defineClass },
    { "getClassNameList",   "(I)[Ljava/lang/String;",
        Dalvik_dalvik_system_DexFile_getClassNameList },
    { "isDexOptNeeded",     "(Ljava/lang/String;)Z",
        Dalvik_dalvik_system_DexFile_isDexOptNeeded },
    { NULL, NULL, NULL },
};

需要通过dlsym获取dvm_dalvik_system_DexFile，根据函数名称以及签名遍历查找

    void *ldvm = (void *) dlopen("libdvm.so", RTLD_LAZY);
    dvm_dalvik_system_DexFile = (JNINativeMethod *) dlsym(ldvm, "dvm_dalvik_system_DexFile");
    int i = 0;
    void (**fnPtrout)(u4 const *, union JValue *);
    while (dvm_dalvik_system_DexFile[i].name != NULL) {
        LOGD("lookup %d %s", i, dvm_dalvik_system_DexFile[i].name);
        if ((strcmp("openDexFile", dvm_dalvik_system_DexFile[i].name) == 0)
            && (strcmp("([B)I", dvm_dalvik_system_DexFile[i].signature) == 0)) {
            *fnPtrout = dvm_dalvik_system_DexFile[i].fnPtr;
            return 1;
        }
        i++;
    }

具体方案可以参数抖音BoostMultiDex优化实践：Android低版本上APP首次启动时间减少80%
例子QuickMultidex

APK文件重排布

安装包重排布是站在IO优化的角度去优化的，核心原理是将启动阶段所需要的文件排布在一起，尽可能利用liunx中packagecache机制减少IO，提升启动速度

资源方面具体方案可以参考支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能
代码方面可以参考 Redex 初探与 Interdex：Andorid 冷启动优化

R文件内联

一个dex中最多能有method数量或者filed数量64K，目前开发多module开发，在普通的library中R文件不是final类型的类型的，这样会导致filed数量增加，从而导致dex包增加，在Android5.0以下Classload加载优化dex时间会变长，R文件字段内联对热修复会有些影响，需要开发时如果使用了热修复方案需要考虑这块

启动阶段抑制GC

由于java是运行在jvm虚拟机中的，垃圾回收使用的是GC，在GC过程中目前使用的CMS等垃圾回收期，在垃圾回收过程中会短暂挂起所有的ART运行时线程，如果能在启动阶段抑制GC能有效的提高启动速度，但是需要hook系统底层，可能会出现兼容性问题<p>
以下是Android7.0 mark_sweep中片段源码

void MarkSweep::RunPhases() {
  Thread* self = Thread::Current();
  InitializePhase();
  Locks::mutator_lock_->AssertNotHeld(self);
  //是否是并行
  if (IsConcurrent()) {
    GetHeap()->PreGcVerification(this);
    {
      ReaderMutexLock mu(self, *Locks::mutator_lock_);
      MarkingPhase();
    }
    //挂起所有的ART运行时线程
    ScopedPause pause(this);
    GetHeap()->PrePauseRosAllocVerification(this);
    PausePhase();
    //恢复所有的ART运行时线程
    RevokeAllThreadLocalBuffers();
  } else {
    ScopedPause pause(this);
    GetHeap()->PreGcVerificationPaused(this);
    MarkingPhase();
    GetHeap()->PrePauseRosAllocVerification(this);
    PausePhase();
    RevokeAllThreadLocalBuffers();
  }
  {
    // Sweeping always done concurrently, even for non concurrent mark sweep.
    ReaderMutexLock mu(self, *Locks::mutator_lock_);
    ReclaimPhase();
  }
  GetHeap()->PostGcVerification(this);
  FinishPhase();
}

具体方案可以参数
支付宝客户端架构解析：Android 客户端启动速度优化之「垃圾回收」

绕过verifyClass

由jvm类加载机制可知，在加载class时都需要校验，如果能绕过校验直接到链接阶段，能节省好多耗时。
最大优化场景在于首次安装和覆盖安装时，在Dalvik平台上，一个2MB的Dex正常需要350ms，将classVerifyMode设为VERIFY_MODE_NONE后，只需150ms，节省超过50%时间。

参考：