Android 性能优化—— 启动优化提升60％

应用启动速度

一个应用App的启动速度能够影响用户的首次体验，启动速度较慢(感官上)的应用可能导致用户再次开启App的意图下降，或者卸载放弃该应用程序

本文将从两个方向优化应用的启动速度 :

1.视觉体验优化 2.代码逻辑优化

视觉优化

应用程序启动有三种状态，每种状态都会影响应用程序对用户可见所需的时间：冷启动，热启动和温启动

关于这3种启动方式，可以查看谷歌开发文档

大家常说的是冷启动和热启动

1.冷启动：当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动 2.热启动：当启动应用时，后台已有该应用的进程（例：按back键、home键，应用虽然会退出，但是该应用的进程是依然会保留在后台，可进入任务列表查看），所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动

在冷启动时，应用程序从头开始。在其他状态下，系统需要将正在运行的应用程序从后台运行到前台。我们建议您始终根据冷启动的假设进行优化。这样做也可以改善热启动和温启动的性能

在冷启动开始时，系统有三个任务。这些任务是：

1.加载并启动应用程序 2.启动后立即显示应用程序空白的启动窗口 3.创建应用程序进程

一旦系统创建应用程序进程，应用程序进程就会负责下一阶段，这些阶段包括：

1.创建app对象 2.启动主线程(main thread) 3.填充加载布局Views 4.在屏幕上执行View的绘制过程.measure -> layout -> draw

应用程序进程完成第一次绘制后，系统进程会交换当前显示的背景窗口，将其替换为主活动。此时，用户可以开始使用该应用程序

因为App应用进程的创建过程是由手机的软硬件决定的，所以我们只能在这个创建过程中视觉优化

启动主题优化

所谓的主题优化，就是应用程序在冷启动的时候(1~2阶段)，设置启动窗口的主题

因为现在 App 应用启动都会先进入一个闪屏页(LaunchActivity) 来展示应用信息

默认情况下会出现白屏现象，系统默认会在启动应用程序的时候启动空白窗口，直到 App 应用程序的入口 Activity 创建成功，视图绘制完毕系统默认会在启动应用程序的时候启动空白窗口，直到 App 应用程序的入口 Activity 创建成功，视图绘制完毕系统默认会在启动应用程序的时候启动空白窗口，直到 App 应用程序的入口 Activity 创建成功，视图绘制完毕

解决方法可查看Android启动界面SplashActivit的实现方法

代码优化

Android中如何计算 App 的启动时间

根据上面启动时间的输出统计，我们就可以先记录优化前的冷启动耗时，然后再对比优化之后的启动时间

Application 优化

Application 作为应用程序的整个初始化配置入口，时常担负着它不应该有的负担~

有很多第三方组件（包括App应用本身）都在 Application 中抢占先机，完成初始化操作

但是在 Application 中完成繁重的初始化操作和复杂的逻辑就会影响到应用的启动性能

通常，有机会优化这些工作以实现性能改进，这些常见问题包括：

1.复杂繁琐的布局初始化 2.阻塞主线程 UI 绘制的操作，如 I/O 读写或者是网络访问 3.Bitmap 大图片或者 VectorDrawable加载 4.其它占用主线程的操作

我们可以根据这些组件的轻重缓急之分，对初始化做一下分类

1.必要的组件一定要在主线程中立即初始化(入口 Activity 可能立即会用到) 2.组件一定要在主线程中初始化，但是可以延迟初始化 3.组件可以在子线程中初始化

**放在子线程的组件初始化建议延迟初始化 **，这样就可以了解是否会对项目造成影响

所以对于上面的分析，我们可以在项目中 Application 的加载组件进行如下优化：

将Bugly，x5内核初始化，SP的读写，友盟等组件放到子线程中初始化。（子线程初始化不能影响到组件的使用）

new Thread(new Runnable() {
            @Override
            public void run() {
                //设置线程的优先级，不与主线程抢资源
                Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
                //子线程初始化第三方组件
                Thread.sleep(5000);//建议延迟初始化，可以发现是否影响其它功能，或者是崩溃！
            }
        }).start();

将需要在主线程中初始化但是可以不用立即完成的动作延迟加载（原本是想在入口 Activity 中进行此项操作，不过组件的初始化放在 Application 中统一管理为妙）

handler.postDelayed(new Runnable() {
            @Override
            public void run() {
                //延迟初始化组件
            }
        }, 3000);

闪屏页业务优化

最后还剩下那些为数不多的组件在主线程初始化动作，例如埋点，点击流，数据库初始化等，不过这些消耗的时间可以在其它地方相抵

需求背景：应用App通常会设置一个固定的闪屏页展示时间，例如2000ms，所以我们可以根据用户手机的运行速度，对展示时间做出调整，但是总时间仍然为 2000ms

闪屏页展示总时间 = 组件初始化时间 + 剩余展示时间

也就是2000ms的总时间，组件初始化了800ms，那么就再展示1200ms即可

Application 初始化后会调用 attachBaseContext() 方法，再调用 Application 的 onCreate()，再到入口 Activity的创建和执行 onCreate() 方法。所以我们就可以在 Application 中记录启动时间

//Application
@Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        SPUtil.putLong("application_attach_time", System.currentTimeMillis());//记录Application初始化时间
    }

有了启动时间，我们得知道入口的 Acitivty 显示给用户的时间（View绘制完毕）,在onWindowFocusChanged()的回调时机中表示可以获取用户的触摸时间和View的流程绘制完毕，所以我们可以在这个方法里记录显示时间

//Activity
@Override
    public void onWindowFocusChanged(boolean hasFocus) {
        super.onWindowFocusChanged(hasFocus);
  
          long appAttachTime = SPUtil.getLong("application_attach_time");
          long diffTime = System.currentTimeMillis() - appAttachTime;//从application到入口Acitity的时间
 
         //所以闪屏页展示的时间为 2000ms - diffTime.
    }

所以我们就可以动态的设置应用闪屏的显示时间，尽量让每一部手机展示的时间一致，这样就不会让手机配置较低的用户感觉漫长难熬的闪屏页时间（例如初始化了2000ms，又要展示2000ms的闪屏页时间.），优化用户体验

广告页优化

闪屏页过后就要展示金主爸爸们的广告页了

因为项目中广告页图片有可能是大图，APng动态图片，所以需要将这些图片下载到本地文件，下载完成后再显示，这个过程往往会遇到以下两个问题：

广告页的下载，由于这个是一个异步过程，所以往往不知道加载到页面的合适时机
广告页的保存，因为保存是 I/O 流操作，很有可能被用户中断，下次拿到破损的图片

因为不清楚用户的网络环境，有些用户下载广告页可能需要一段时间，这时候又不可能无限的等候。所以针对这个问题我们可以开启 IntentService 用来下载广告页图片

在入口 Acitivity 中开启 IntentService 来下载广告页。或者是其它异步下载操作

在广告页图片文件流完全写入后记录图片大小，或者记录一个标识

在下次的广告页加载中可以判断是否已经下载好了广告页图片以及图片是否完整，否则删除并且再次下载图片

另外因为在闪屏页中仍然有剩余展示时间，所以在这个时间段里如果用户已经下载好了图片并且图片完整，就可以显示广告页。否则进入主 Activity ，因为 IntentService 仍然在后台继续默默的下载并保存图片~

最后

如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。