Android 冷启动优化解析，字节跳动 8 年老 Android 面试官经验谈
Status: okActivity: com.xx.xxx/com.xx.xxxx.welcome.view.WelcomeActivityThisTime: 242TotalTime: 242WaitTime: 288Complete
ThisTime:是指调用过程中最后一个 Activity 启动时间到这个 Activity 的 startActivityAndWait 调用结束;
TotalTime:是指调用过程中第一个 Activity 的启动时间到最后一个 Activity 的 startActivityAndWait 结束。
WaitTime:是 startActivityAndWait 这个方法的调用耗时;
reportFullyDrawn
在某些特殊场景，我们可能不单单启动页的绘制完成回调时间就足够了，我们需要连启动页的闪屏广告接口数据成功回调之后才算一个完整的时间，这时我们可以使用 reportFullyDrawn
public class WelcomeActivity extends MvpActivity<WelcomePresenter> implements WelcomeMvp.View {@Overrideprotected void onCreate(@Nullable Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_welcome);// 请求数据 mvpPresenter.config();
}@Overridepublic void finishRequest() {// 数据回调 reportFullyDrawn();}}
PS:这个方式 minSdkVersion 需要 API19+，所以要对 SDK 版本进行设置或判断。
####Traceview
Traceview 是 Android 设备的一个非常好用的性能分析工具，它可以通过详细的界面，让我们跟踪程序的性能，并且能清晰地查看到每一个函数的耗时和调用次数。
####Systrace
Syst
race 非常直观地展示每个线程上面的 API 的调用顺序和耗时情况。
Traceview 和 Systrace 都是 DDMS 面板的工具，但是现在 AS3.0 以上的版本不再建议使用了，所以这里就不详述，如果有兴趣的同学，可以看我上一篇文章《Android 应用优化之流畅度实操》，里面有详细地说明这两个工具的用法。
####hugo
github.com/JakeWharton…
我们可以利用 JakeWharton 的 hugo，通过注解的方式获取对应的类或者函数所消耗的时间。我们可以利用它对启动页 Activity 的生命周期来抠细节。
##启动优化实操
####用户体验优化
在冷启动优化的主要体验个人认为就是消除启动时的白屏/黑屏，因为白屏/黑屏对于用户使用的第一印象就是慢、卡顿。我们可以设置启动页的主题来达到目的。
<style name="WelcomeTheme" parent="Theme.AppCompat.Light.NoActionBar.FullScreen"><item name="android:windowBackground">@drawable/shape_welcome</item><item name="android:windowDrawsSystemBarBackgrounds">false</item></style>
windowDrawsSystemBarBackgrounds 是对部分有系统操作栏的设置。接着是这个窗口背景色的布局；
<layer-list xmlns:android="http://schemas.android.com/apk/res/android" android:opacity="opaque"><item android:drawable="@android:color/white"/><item><bitmapandroid:src="@drawable/welcome_bg"android:gravity="center"/></item></layer-list>
启动页的广告展示完跳转到首页，然后我们设置回我们的通用样式，可以在清单文件，也可以在代码中设置；
<activity···android:theme="@style/AppBaseFrameTheme"/>
通过对启动页的主题设置后，就会将白屏/黑屏抹去，用户点击 App 的图标就展示启动图，让用户先产生启动很快的“错觉”。同时这里可以通过动画，让启动页与首页之间的过渡更加自然。
##Application 启动优化
从上图一的分析总结中，我对优化点 Application 的生命周期进行了加粗提示，接着我们回来对这部分进行优化实操。
Application#attachBaseContext()
Application 启动会经过 attachBaseContext()-->onCreate()；这时大家从 attachBaseContext 的生命周期联想到什么？没错就是 MultiDex 分包机制。想必大家都会发现，自从我们方法数超出了 65535 处理了分包之后，启动白屏/黑屏的问题就出现了，分包机制是导致冷启动缓慢的重要原因，而现在部分应用采用插件化的方式来避免 MultiDex 带来的白屏问题，这虽然是一种方法，但是开发成本实在高，对于不少应用来说是不必要的。我们来聊一下 MultiDex 优化，首先 MultiDex 可分成运行时和编译时两个部分：
编译期：将 App 中的 class 以某种策略拆分在多个 dex 中，为了减少第一个 dex 也就主 dex 中包含的 class 数；
运行期： App 启动时，虚拟机只加载主 dex 中的 class。app 启动以后，使用 Multidex.install，通过反射机制修改 ClassLoader 中的 dexElements 来加载其他 dex；
从网上的多篇实践分析中，他们主要采用的是异步方式。因为 App 起始会先加载主 dex 包，那么我们可以自主去处理分包的工作，我们将启动页和首页需要的库、组件等主要 class 分在主 dex 中，从而达到精分主 dex 包的大小，具体的操作写法，大家可以参考网上 MultiDex 启动优化文章，但是大家要注意在主 dex 的分包过程中，主 dex 经过我们一系列的优化操作减少了主 dex 的大小，因此也增大了 NoClassDefFoundError 的异常的可能，此时会导致我们的应用启动失败的风险，所以在优化后我们一定做好测试工作。
Application#onCreate()
经过 attachBaseContext()后就到 onCreate()生命周期，想必我们大部分的应用，会在这里对我们使用到的第三方库和组件进行初始化工作。由于版本不断迭代，第三方库的初始化都是直接写在 onCreate()中，大量的初始化工作导致该生命周期过于沉重，我们应该对这些第三方库进行分类。下面是我整理我司 App 启动的工作分类：
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论