异步加载
建议使用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文件字段内联对热修复会有些影响，需要开发时如果使用了热修复方案需要考虑这块
删除access$xxx方法
Java编译器在编译过程中，内部类与外部类访问私有成员时，为了保持类的封装性会生成的access$xxx方法，大量的access方法会导致dex增加，classloader加载时间延长，同时调用方法相对于直接调用file又会对性能有些影响，具体可以参考西瓜视频apk瘦身之 Java access 方法删除
启动阶段抑制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%时间。
参考：
