getwindow().getDecorView().post(new Runnable() {
    @Override
    public void run() {
        //Todo something
    }
});

本文分享自微信公众号 - 58技术（architects_58）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

Android APP启动方式、启动流程及启动优化分析

本文章向大家介绍Android app应用启动的一些相关知识，包括app启动方式、app启动流程和app启动优化等知识！

 app应用启动方式

1、冷启动

 当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。冷启动因为系统会重新创建一个新的进程分配给它，所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。

2、热启动

当启动应用时，后台已有该应用的进程（例：按back键、home键，应用虽然会退出，但是该应用的进程是依然会保留在后台，可进入任务列表查看），所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动。热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application，因为一个应用从新进程的创建到进程的销毁，Application只会初始化一次。

 app应用启动流程

为方便排版，去掉部分方法中的参数：

1. 从Activity类的startActivity()方法开始，这个方法会调用Activity类中的public void startActivityForResult()方法
2. startActivityForResult()方法会调用Instrumentation类中的public ActivityResult execStartActivity()方法，这个方法加上了{@hide}对外是不可见的
3. execStartActivity()方法中有如下的调用语句ActivityManagerNative.getDefault().startActivity()，它调用了IActivityManager类中的startActivity()方法
4. 但IActivityManager其实只是一个接口，这里实际调用的是public abstract classActivityManagerNative这个类(它继承自Binder类)的内部类ActivityManagerProxy中的public int startActivity()方法，ActivityManagerProxy实现了IActivityManager接口
5. ActivityManagerProxy类的public int startActivity()方法中有如下代码，mRemote.transact(START_ACTIVITY_TRANSACTION,data,reply,0)，这里mRemote是一个IBinder对象，这个对象在ActivityManagerProxy构造方法中实例化，实际由外部类ActivityManagerNative的static public IActivityManager asInterface(IBinder obj)方法实例化，asInterface(IBinder obj)方法中参数实际在ActivityManagerNative类的static public IActivityManager getDefault()方法中，由ServiceManager.getService("activity")实例化
6. mRemote.transact(START_ACTIVITY_TRANSACTION,0)这条语句通过IBinder的transact()方法，将方法中的参数跨进程传递给ActivityManagerService类
7. 以上除ActivityManagerService类之外的类都位于android.app包下
8. 下面进入ActivityManagerService类，它位于源码的/frameworks/base/services/java/com/android/server/am/路径下，包名是com.android.server.am
9. ActivityManagerService继承了ActivityManagerNative类，从ActivityManagerProxy类的mRemote.transact()传递过来的参数，被传递到ActivityManagerService类的onTransact()方法来处理
10. ActivityManagerService类的onTransact()方法实际上通过super.onTransact(code,flags)这条语句又调用了ActivityManagerNative类中的onTransact()方法
11. super.onTransact(code,flags)这条语句会调用到ActivityManagerService类的public final int startActivity()方法
12. ActivityManagerService类的startActivity()方法会调用到ActivityStack类的startActivityMayWait()方法
13. ActivityStack类位于com.android.server.am包下，startActivityMayWait()方法final int startActivityLocked()方法
14. startActivityLocked()方法最后会调用final boolean resumetopActivityLocked()方法
15. resumetopActivityLocked()方法会调用private final void startSpecificActivityLocked()方法
16. startSpecificActivityLocked()方法会调用startProcessLocked()方法
17. startProcessLocked()方法会调用android.os.Process类的public static final int start()方法
18. int pid = Process.start("android.app.ActivityThread",mSimpleProcessManagement ? app.processName : null,uid,gids,debugFlags,null)
19. 下面进入android.os包下的Process类中
20. start()方法会调用private static int startViaZygote()方法
21. startViaZygote()方法会调用private static int zygoteSendArgsAndGetPid()方法
22. zygoteSendArgsAndGetPid()方法会使用socket与zygote进程通信
23. sZygoteSocket = new LocalSocket();
24. sZygoteSocket.connect(new LocalSocketAddress(ZYGOTE_SOCKET,LocalSocketAddress.Namespace.RESERVED));
25. 下面进入com.android.internal.os包下的ZygoteInit类
26. ZygoteInit类里面含有LocalSocketServer的实例，会与上面提到的zygoteSendArgsAndGetPid()方法使用socket进行通信
27. 实际逻辑在ZygoteConnection这个类中的boolean runOnce()方法中
28. runOnce()方法会调用dalvik.system.Zygote这个类中的静态方法forkAndSpecialize()
29. 下面进入dalvik.system包中的Zygote类
30. forkAndSpecialize()最终调用了native的方法native public static int forkAndSpecialize()
31. 在c代码中开启应用程序的进程
32. 应用的进程从android.app包下的ActivityThread类开始运行
33. ActivityThread类中含有main()方法
34. ActivityThread.main()是应用的启动入口，在应用程序启动的时候就会调用

 app的启动优化：

基于上面的启动流程我们尽量做到如下几点

1. Application的创建过程中尽量少的进行耗时操作
2. 如果用到SharePreference,尽量在异步线程中操作
3. 减少布局的层次,并且生命周期回调的方法中尽量减少耗时的操作

通过此文，希望能帮助到大家，谢谢大家对本站的支持！

Android 勇闯高阶性能优化之启动优化篇

背景

用户不会在乎你的项目是不是过大，里面是不是有很多初始化的逻辑。他只在乎你-慢了。

所以咱们这篇文章有两个目的：

启动速度提升(用户眼中的大神就是你)

优化代码逻辑和规范(别让自己成为继任者中的XX)

今天咱们就来了解一下应用启动内部机制和启动速度优化。

启动内部机制

应用有三种启动状态：

• 冷启动；
• 温启动；
• 热启动。

冷启动

冷启动是指应用从头开始：冷启动发生在设备启动后第一次启动应用程序 (Zygote>fork>app) ，或系统关闭应用程序后。

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

• 加载和启动应用程序。
• 启动后立即显示应用程序的空白启动页面。
• 创建应用程序进程。

一旦系统创建了应用程序进程，应用程序进程就负责接下来的阶段：

• 创建应用的实体。
• 启动主线程。
• 创建主页面。
• 绘制页面上的View。
• 布局页面。
• 执行首次的绘制。

如下图：

• Displayed Time：初始显示时间
• reportFullyDrawn()：完全显示的时间

注意：在创建 Application 和创建 Activity 期间可能会出现性能问题。

创建 Application

当应用程序启动时，空白启动页面保留在屏幕上，直到系统首次完成应用程序的绘制。

如果你重写了Application.onCreate()，系统将调用Application 上的onCreate()方法。之后，应用程序生成主线程，也称为UI线程，并将创建主Activity的任务交给它。

创建Activity

应用进程创建你的Activity后，Activity会执行以下操作：

• 初始化值。
• 调用构造函数。
• 调用 Activity 当前生命周期状态的回调方法，如 Activity.onCreate()。

注意：onCreate() 方法对加载时间的影响最大，因为它执行开销最高的工作：加载UI的布局和渲染，以及初始化Activity运行所需的对象。

热启动

热启动时，系统将应用从后台拉回前台，应用程序的 Activity 在内存中没有被销毁，那么应用程序可以避免重复对象初始化，UI的布局和渲染。

如果 Activity 被销毁则需要重新创建。

和冷启动的区别： 不需要创建 Application。

温启动

温启动介于冷启动和热启动中间吧。例如：

用户按返回键退出应用，然后重新启动。进程可能还没有被杀死，但应用必须通过调用onCreate（）重新创建 Activity。

系统回收了应用的内存，然后用户重新运行应用。应用进程和Activity都需要重新启动。

咱们看看他们共同消耗多长时间。

查询的启动时间

初始显示时间(Time to initial display)

在 Android 4.4（API 级别 19）及更高版本中，logcat 包含一个输出行，其中包含一个名为 Displayed 的值。 此值表示启动流程和完成在屏幕上绘制相应活动之间经过的时间量。 经过的时间包含以下事件序列：

• 启动进程。
• 初始化对象。
• 创建并初始化Activity。
• 加载布局。
• 第一次绘制你的应用程序。

注意这里查看日志需要如下操作：

报告的日志行类，如下图：

//冷启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s355ms
//温启动(进程被杀死)
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s46ms
//热启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +289ms
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +253ms

图例讲解：

第一个时间，冷启动时间：+1s355ms；

然后我们在后台杀死进程，再次启动应用；

第二个时间，温启动时间：+1s46ms；

这里咱们在后台杀死进程所以：应用进程和Activity需要重新启动。

第三个时间：热启动时间：+289ms 和 +253ms；

按返回键，仅退出activity。所以耗时比较短。

当然整体看这个应用开启时间并不长，因为 Demo 的 Application 和 Activity 都没有进行太多的操作。

完全显示时间(Time to full display)

你可以使用 reportFullyDrawn() 方法来测量应用程序启动和所有资源和视图层次结构的完整显示之间经过的时间。在应用程序执行延迟加载的情况下，这可能很有价值。在延迟加载中，应用程序不会阻止窗口的初始绘制，而是异步加载资源并更新视图层次结构。

这里我在Activity.onCreate()中加了个工作线程。并在里面调用reportFullyDrawn() 方法。代码如下：

@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Log.e(this.getClass().getName(), "onCreate");
    setContentView(R.layout.activity_main);
    ...
    new Thread(new Runnable() {
        @Override
        public void run() {
            try {
                Thread.sleep(3000);
                reportFullyDrawn();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }).start();
}

报告的日志行类，如下图：

I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s970ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s836ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s107ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s149ms

图例讲解：

然后你会发现界面出来好一会才打这个日志。看到这里我觉得好多人已经知道怎么去优化启动速度了。

性能迟缓分析

看到上面的实验其实三种启动情况，受我们影响的方面在于 application 和 activity 。

Application 初始化

当你的代码覆盖 Application 对象并在初始化该对象时执行繁重的工作或复杂的逻辑时，启动性能可能会受到影响。 产生的原因包括：

• 应用程序的初始onCreate（）函数。如：执行了不需要立即执行的初始化。
• 应用程序初始化的任何全局单例对象。如：一些不必要的对象。
• 可能发生的任何磁盘I/O、反序列化或紧密循环。

解决方案

无论问题在于不必要的初始化还是磁盘I/O，解决方案都是延迟初始化。换句话说，你应该只初始化立即需要的对象。不要创建全局静态对象，而是转向单例模式，应用程序只在第一次需要时初始化对象。

此外，考虑使用依赖注入框架（如Hilt）

Activity初始化

活动创建通常需要大量高开销工作。 通常，有机会优化这项工作以实现性能改进。

产生的原因包括：

• 加载大型或复杂的布局。
• 阻止在磁盘或网络 I/O 上绘制屏幕。
• 加载和解码Bitmap。
• VectorDrawable 对象。
• Activity 初始化任何全局单例对象。
• 所有资源初始化。

解决方案如下。

布局优化

• 通过减少冗余或嵌套布局来扁平化视图层次结构。
• 布局复用(< include/>和 < merge/> )
• 使用ViewStub，不加载在启动期间不需要可见的 UI 部分。

代码优化

• 不必要的初始化还是磁盘I/O，延迟初始化
• 资源初始化分类，以便应用程序可以在不同的线程上延迟执行。
• 动态加载资源和Bitmap

关于这两块的优化后续会有单独的文章去写。

阻塞实验

Application 阻塞 2秒， Activity 阻塞 2秒

SccApp.class

public class SccApp extends Application {
    @RequiresApi(api = Build.VERSION_CODES.P)
    @Override
    public void onCreate() {
        super.onCreate();
        String name = getProcessName();
        MLog.e("ProcessName:"+name);
        getProcessName("com.scc.demo");
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

MainActivity.class

public  class MainActivity extends ActivityBase implements View.OnClickListener {
    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.e(this.getClass().getName(), "onCreate");
        setContentView(R.layout.activity_main);
        ...
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(3000);
                    reportFullyDrawn();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

报告的日志，如下：

//冷启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +5s458ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +8s121ms
//温启动(进程被杀死)
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +5s227ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +7s935ms
//热启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +2s304ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +5s189ms
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +2s322ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +5s169ms

将Appliacation 和Activity阻塞的2秒都放在工作线程去操作

这个就是把代码放在如下代码中执行即可，就不全部贴出来了。

        new Thread(new Runnable() {
            @Override
            public void run() {
                ...
            }
        }).start();

运行结果如下：

//冷启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s227ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s957ms
//温启动(进程被杀死)
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s83ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s828ms
//热启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +324ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s169ms
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +358ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s207ms

APP 启动黑/白屏

Android 应用启动时，尤其是大型应用, 经常出现几秒钟的黑屏或白屏，黑屏或白屏取决于主界面 Activity 的主题风格。

优雅的解决黑白屛

Android 应用启动时很多大型应用都会有一个广告(图片及视频)页或闪屏页(2-3S)。这并不是开发者想要放上去的，而是为了避免上述启动白屏导致用户体很差。当然你可以珍惜这2-3秒做一个异步加载或者请求。

写到这里。应用启动模式、启动时间、启动速度优化算是完事了。当然后面如果有更好的优化方案还会继续补充。

到此这篇关于Android 勇闯高阶性能优化之启动优化篇的文章就介绍到这了,更多相关Android 启动优化内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！

Android 性能优化之 App 应用启动分析与优化

前言：

     昨晚新版本终于发布了，但是还是记得有测试反馈 app 启动好长时间也没进入 app 主页，所以今天准备加个班总结一下 App 启动那些事！

app 的启动方式：

 1.）冷启动

     当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。冷启动因为系统会重新创建一个新的进程分配给它，所以会先创建和初始化 Application 类，再创建和初始化 MainActivity 类（包括一系列的测量、布局、绘制），最后显示在界面上。

 2.）热启动

     当启动应用时，后台已有该应用的进程（例：按 back 键、home 键，应用虽然会退出，但是该应用的进程是依然会保留在后台，可进入任务列表查看），所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动。热启动因为会从已有的进程中来启动，所以热启动就不会走 Application 这步了，而是直接走 MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个 MainActivity 就行了，而不必创建和初始化 Application，因为一个应用从新进程的创建到进程的销毁，Application 只会初始化一次。

app 的启动流程：

   通过上面的两种启动方式可以看出 app 启动流程为：

    Application 的构造器方法 ——>attachBaseContext ()——>onCreate ()——>Activity 的构造方法 ——>onCreate ()——> 配置主题中背景等属性 ——>onStart ()——>onResume ()——> 测量布局绘制显示在界面上

app 的启动优化：

    基于上面的启动流程我们尽量做到如下几点

1. Application 的创建过程中尽量少的进行耗时操作

2. 如果用到 SharePreference, 尽量在异步线程中操作

3. 减少布局的层次，并且生命周期回调的方法中尽量减少耗时的操作

app 启动遇见黑屏或者白屏问题

  1.）产生原因

     其实显示黑屏或者白屏实属正常，这是因为还没加载到布局文件，就已经显示了 window 窗口背景，黑屏白屏就是 window 窗口背景。

    示例：

 2.）解决办法

     通过设置设置 Style

（1）设置背景图 Theme

    通过设置一张背景图。 当程序启动时，首先显示这张背景图，避免出现黑屏

<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
        <item name="android:screenOrientation">portrait</item>
        <item name="android:windowBackground">>@mipmap/splash</item>
        <item name="android:windowIsTranslucent">true</item>
        <item name="android:windowNoTitle">true</item>
</style>

（2）设置透明 Theme

   通过把样式设置为透明，程序启动后不会黑屏而是整个透明了，等到界面初始化完才一次性显示出来

<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
        <item name="android:windowNoTitle">true</item>
        <item name="android:windowBackground">@android:color/transparent</item>
        <item name="android:windowIsTranslucent">true</item>
        <item name="android:screenOrientation">portrait</item>
</style>

两者对比：

• Theme1 程序启动快，界面先显示背景图，然后再刷新其他界面控件。给人刷新不同步感觉。

• Theme2 给人程序启动慢感觉，界面一次性刷出来，刷新同步。

（3）修改 AndroidManifest.xml

 1 <application
 2         android:name=".App"
 3         android:allowBackup="true"
 4         android:icon="@mipmap/ic_launcher"
 5         android:label="@string/app_name"
 6         android:supportsRtl="true">
 7         <activity android:name=".MainActivity"
 8          android:theme="@style/AppTheme">
 9             <intent-filter>
10                 <action android:name="android.intent.action.MAIN" />
11 
12                 <category android:name="android.intent.category.LAUNCHER" />
13             </intent-filter>
14         </activity>
15 
16     //......
17 
18 </application>

解决后示例：

3.）常见的 Theme 主题

 1 android:theme="@android:style/Theme.Dialog" //Activity显示为对话框模式
 2 
 3 android:theme="@android:style/Theme.NoTitleBar" //不显示应用程序标题栏
 4 
 5 android:theme="@android:style/Theme.NoTitleBar.Fullscreen" //不显示应用程序标题栏，并全屏
 6 
 7 android:theme="Theme.Light " //背景为白色
 8 
 9 android:theme="Theme.Light.NoTitleBar" //白色背景并无标题栏
10 
11 android:theme="Theme.Light.NoTitleBar.Fullscreen" //白色背景，无标题栏，全屏
12 
13 android:theme="Theme.Black" //背景黑色
14 
15 android:theme="Theme.Black.NoTitleBar" //黑色背景并无标题栏
16 
17 android:theme="Theme.Black.NoTitleBar.Fullscreen" //黑色背景，无标题栏，全屏
18 
19 android:theme="Theme.Wallpaper" //用系统桌面为应用程序背景
20 
21 android:theme="Theme.Wallpaper.NoTitleBar" //用系统桌面为应用程序背景，且无标题栏
22 
23 android:theme="Theme.Wallpaper.NoTitleBar.Fullscreen" //用系统桌面为应用程序背景，无标题栏，全屏
24 
25 android:theme="Theme.Translucent" //透明背景
26 
27 android:theme="Theme.Translucent.NoTitleBar" //透明背景并无标题
28 
29 android:theme="Theme.Translucent.NoTitleBar.Fullscreen" //透明背景并无标题，全屏
30 
31 android:theme="Theme.Panel " //面板风格显示
32 
33 android:theme="Theme.Light.Panel" //平板风格显示

关于Android性能优化(一)：APP启动优化和android app启动优化的介绍现已完结，谢谢您的耐心阅读，如果想了解更多关于58同城 Android App启动优化实践、Android APP启动方式、启动流程及启动优化分析、Android 勇闯高阶性能优化之启动优化篇、Android 性能优化之 App 应用启动分析与优化的相关知识，请在本站寻找。