【Android】Application的几点见解_android application

写在前面

原本是打算在自己的demo自定义一个Application，后来想到Application在Android中扮演着这么重要的角色，还没有梳理过，所以打算通过类的依赖关系、创建过程、如何自定义等几方面来聊聊对Application的见解，本着不贪多贪全的前提下有了这篇文章。

Application依赖继承关系

先看看Application这个类继承关系图

看了这个类图首先可以轻松回答一道面试题：在一个应用中程序中有多少个context实例？答案是：Application（1个）+ Activity的数量 + Service的数量。回答的更准确的话，可以强调前提是单进程应用。如果是多进程应用的话，就是各个进程的计算结果相加了。

这里还能看到设计模式中装饰器模式的使用，修饰类（ContextWrapper）和被修饰类（ContextImpl）都继承相同的父类（Context）；同时修饰类内部持有父类（Context）这个成员变量（Base：Context），其值可通过构造函数或方法（attachBaseContext(Context base)）传入。

既然Application的父类ContextWrapper本质是一个修饰类，那么其真正具备骨架能力应该是在传入被修饰类（ContextImpl）之后，想知道何时被传入的，就需要接着了解Application被创建的全流程了~

Application的创建过程

基于Android SDK 30 API Level画了下面这张应用启动流程图

这里介绍几个关键的要点：（1）main入口、（2）向AMS绑定ApplicationThread、（3）AMS调用ApplicationThread bindApplication()方法、（4）创建Application、（5）Application attach绑定上下文context、（6）Application onCreate可以开始具体业务。

应用程序的入口一般是main方法，从上图中可以看到，在Android中也不例外，首先调用了ActivityThread的main方法。

由于需要获取系统服务AMS（Activity Manager Service），而各种各样的系统服务都是在ServiceManger进程维护着，这里就涉及到跨进程通信IPC（图中浅蓝色为背景的就代表着另一个进程），Android跨进程通信基本结构如下：

想想Service使用的AIDL方式进行的IPC是不是就是符合这样的结构。掌握了这个规律之后，只要一看到带有proxy字眼的，可以猜出其大概率是跨进程通信中的调用方，而带有stub字眼的大概率就是跨进程通信的服务方了。

继续回到启动流程图，应用进程获取系统服务的目的主要是将自身的ApplicationThread实例传递给系统进程，抛开跨进程而言，就是传递了一个回调进去（如图中所说的向AMS绑定ApplicationThread）。ApplicationThread是继承自IApplicationThread.Stub，这里有个Stub字眼，所以认为该类是一个服务方，实际确实是，它实现了AIDL方法，提供给系统在适当时候回调。

接着系统服务会调用ApplicationThread的bindApplication方法又回到了应用进程，通过ActivityThread的内部类H（继承了Handler）进行发送BIND_APPLICATION消息，以及由ActivityThread来进行具体的消息处理。具体内容主要就包括了创建Application，以及创建上下文具体实现类ContextImpl，然后调用Application的attach方法，将ContextImpl实例传入到Application中，Application内部是再通过调用attachBaseContext方法向context赋值给成员变量Base，至此Application实例已经具备了完整的能力了。接着会触发Application的onCreate方法，应用可以在这个方法中进行一些相关的全局初始化等操作。

应用启动流程大致就介绍这些了，大家可以对着上面的时序图和源码一起做进一步的分析，希望所绘的图能够对启动流程的理解能有一定帮助。

自定义Application

通过了解了Application的启动流程，应该对自定义Application会更加的得心应手了。

先来看看下面这个自定义Application简单样例

public class MyApplication extends Application {
   private static final String TAG = MyApplication.class.getSimpleName();

   private static MyApplication INSTANCE;

   public static MyApplication getInstance() {
      return INSTANCE;
   }

   @Override
   public void onCreate() {
      super.onCreate();
      Log.i(TAG, "onCreate");
      INSTANCE = this;
      registerActivityLifecycleCallbacks(new MyActivityLifecycleCallbacks());
   }

   @Override
   protected void attachBaseContext(Context base) {
      super.attachBaseContext(base);
      Log.i(TAG, "attachBaseContext");
   }
} 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

自定义Application需要继承系统的Application。

通常Application都会对外提供一个静态方法用于需要获取Application单实例，实现方案是直接内部创建一个静态成员变量，然后在onCreate方法中进行赋值，并对外暴露获取方法即可。这里你或许会疑惑为什么没有使用到标准的创建单例模式的方法，那是因为在上一小节时序图中其实有一个没有提到的小细节，在LoadedApk类的makeApplication方法中会判断当前应用是否已经有application实例，如果有直接返回，所以系统已经为我们保证了Application是单例。

由于在onCreate中Application已经持有了被修饰对象ContextImpl，即能力已经完整了，所以推荐一般需要放在Application中的初始化业务尽量放在onCreate方法中，如示例代码在该方法中通过如下代码进行Activity生命周期的监听注册（Activity声明周期监听常用于获取当前最上层的页面、每个页面停留时长打点等各种业务场景）

registerActivityLifecycleCallbacks(new MyActivityLifecycleCallbacks());

附上MyActivityLifecycleCallbacks类

/**
 * Activity生命周期回调接口实现
 */
class MyActivityLifecycleCallbacks implements Application.ActivityLifecycleCallbacks {
   public static final String TAG = MyActivityLifecycleCallbacks.class.getSimpleName();

   @Override
   public void onActivityCreated(@NonNull Activity activity, @Nullable Bundle savedInstanceState) {
      Log.i(TAG, "onActivityCreated: " + activity.getClass().getSimpleName());
   }

   @Override
   public void onActivityStarted(@NonNull Activity activity) {
      Log.i(TAG, "onActivityStarted: " + activity.getClass().getSimpleName());
   }

   @Override
   public void onActivityResumed(@NonNull Activity activity) {
      Log.i(TAG, "onActivityResumed: " + activity.getClass().getSimpleName());
   }

   @Override
   public void onActivityPaused(@NonNull Activity activity) {
      Log.i(TAG, "onActivityPaused: " + activity.getClass().getSimpleName());
   }

   @Override
   public void onActivityStopped(@NonNull Activity activity) {
      Log.i(TAG, "onActivityStopped: " + activity.getClass().getSimpleName());
   }

   @Override
   public void onActivitySaveInstanceState(@NonNull Activity activity, @NonNull Bundle outState) {
      Log.i(TAG, "onActivitySaveInstanceState: " + activity.getClass().getSimpleName());
   }

   @Override
   public void onActivityDestroyed(@NonNull Activity activity) {
      Log.i(TAG, "onActivityDestroyed: " + activity.getClass().getSimpleName());
   }
} 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

在自定义好Application之后，不好忘了需要在AndroidManifest文件的application结点的name属性添加上自定义的Application类，否则该自定义类不会被系统识别成启动类。

<application
    android:name=".android.application.MyApplication">
</application> 
1
2
3

总结

本文主要通过类的依赖关系、创建过程、如何自定义等几方面来聊聊对Application的见解，由于系统的复杂性，并不能保证个人的见解就是完全准确的，也并不能面面俱到，如果您对这方面也感兴趣或者有独到见解，亦或者觉得我所述的哪些地方不够准确的，欢迎随时交流，互相成长~

通过类的依赖关系、创建过程、如何自定义等几方面来聊聊对Application的见解，由于系统的复杂性，并不能保证个人的见解就是完全准确的，也并不能面面俱到，如果您对这方面也感兴趣或者有独到见解，亦或者觉得我所述的哪些地方不够准确的，欢迎随时交流，互相成长~

最后，如果大伙有什么好的学习方法或建议欢迎大家在评论中积极留言哈，希望大家能够共同学习、共同努力、共同进步。

小编在这里祝小伙伴们在未来的日子里都可以 升职加薪，当上总经理，出任CEO，迎娶白富美，走上人生巅峰！！

不论遇到什么困难，都不应该成为我们放弃的理由！

很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从那里入手去学习，需要一份小编整理出来的学习资料的关注我主页或者点击扫描下方二维码免费领取~

这里是关于我自己的Android 学习，面试文档，视频收集大整理**，有兴趣的伙伴们可以看看~

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