在一个Activity的java程序中，具体看问题描述

本文将对Activity的工作过程进行分析。

主要学习以下内容:

(1)系统内部是如何启动一个Activity的

(2)新Activity的对象是何时创建的

(3)Activity的各个生命周日是被系统何时回调的

Activity启动流程分两种，一种是启动正在运行的app的Activity，即启动子Activity。如无特殊声明默认和启动该activity的activity处于同一进程。如果有声明在一个新的进程中，则处于两个进程。另一种是打开新的app，即为Launcher启动新的Activity。后边启动Activity的流程是一样的，区别是前边判断进程是否存在的那部分。

Activity的启动流程整体如下:

一Activity启动阶段

(一)涉及到的概念

进程：Android系统为每个APP分配至少一个进程

IPC：跨进程通信，Android中采用Binder机制。

(二)涉及到的类

ActivityStack：Activity在AMS的栈管理，用来记录已经启动的Activity的先后关系，状态信息等。通过ActivityStack决定是否需要启动新的进程。

ActivitySupervisor：管理 activity 任务栈

ActivityThread：ActivityThread 运行在UI线程（主线程），App的真正入口。

ApplicationThread：用来实现AMS和ActivityThread之间的交互。

ApplicationThreadProxy：ApplicationThread 在服务端的代理。AMS就是通过该代理与ActivityThread进行通信的。

IActivityManager：继承与IInterface接口，抽象出跨进程通信需要实现的功能

AMN：运行在server端（SystemServer进程）。实现了Binder类，具体功能由子类AMS实现。

AMS：AMN的子类，负责管理四大组件和进程，包括生命周期和状态切换。AMS因为要和ui交互，所以极其复杂，涉及window。

AMP：AMS的client端代理（app进程）。了解Binder知识可以比较容易理解server端的stub和client端的proxy。AMP和AMS通过Binder通信。

Instrumentation：仪表盘，负责调用Activity和Application生命周期。测试用到这个类比较多。

(三)涉及到的进程

(1)Launcher所在的进程

(2)AMS所在的SystemServer进程

(3)要启动的Activity所在的app进程

如果是启动根Activity，就涉及上述三个进程。

如果是启动子Activity，那么就只涉及AMS进程和app所在进程。

(四)具体流程

Launcher：Launcher通知AMS要启动activity。

startActivitySafely->startActivity->InstrumentationexecStartActivity()(AMPstartActivity)->AMSstartActivity

AMS:PMS的resoveIntent验证要启动activity是否匹配。如果匹配，通过ApplicationThread发消息给Launcher所在的主线程，暂停当前Activity(即Launcher)。

暂停完，在该activity还不可见时，通知AMS，根据要启动的Activity配置ActivityStack。然后判断要启动的Activity进程是否存在

存在：发送消息LAUNCH_ACTIVITY给需要启动的Activity主线程，执行handleLaunchActivity

不存在：通过socket向zygote请求创建进程。进程启动后，ActivityThreadattach

判断Application是否存在，若不存在，通过LoadApkmakeApplication创建一个。在主线程中通过threadattach方法来关联ApplicationThread。

在通过ActivityStackSupervisor来获取当前需要显示的ActivityStack。

继续通过ApplicationThread来发送消息给主线程的Handler来启动Activity （handleLaunchActivity）。

handleLauchActivity：调用了performLauchActivity，里边Instrumentation生成了新的activity对象，继续调用activity生命周期。

IPC过程：

双方都是通过对方的代理对象来进行通信。

1app和AMS通信：app通过本进程的AMP和AMS进行Binder通信

2AMS和新app通信：通过ApplicationThreadProxy来通信，并不直接和ActivityThread通信

(五)参考函数流程

Activity启动流程（从Launcher开始）：

第一阶段： Launcher通知AMS要启动新的Activity（在Launcher所在的进程执行）

第二阶段：AMS先校验一下Activity的正确性，如果正确的话，会暂存一下Activity的信息。然后，AMS会通知Launcher程序pause Activity（在AMS所在进程执行）

第三阶段：pause Launcher的Activity，并通知AMS已经paused（在Launcher所在进程执行）

第四阶段：检查activity所在进程是否存在，如果存在，就直接通知这个进程，在该进程中启动Activity；不存在的话，会调用Processstart创建一个新进程（执行在AMS进程）

第五阶段： 创建ActivityThread实例，执行一些初始化 *** 作，并绑定Application。如果Application不存在，会调用LoadedApkmakeApplication创建一个新的Application对象。之后进入Loop循环。（执行在新创建的app进程）

第六阶段：处理新的应用进程发出的创建进程完成的通信请求，并通知新应用程序进程启动目标Activity组件（执行在AMS进程）

第七阶段： 加载MainActivity类，调用onCreate声明周期方法（执行在新启动的app进程）

从另一个角度下图来概括：

下面简要介绍一下启动的过程：

        Step 1 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerServicestartActivity接口； 

        Step 2 ActivityManagerService调用ActivityStackstartActivityMayWait来做准备要启动的Activity的相关信息；

        Step 3 ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerServicestartActivity接口的进程，对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了；

        Step 4 ApplicationThread不执行真正的启动 *** 作，它通过调用ActivityManagerServiceactivityPaused接口进入到ActivityManagerService进程中，看看是否需要创建新的进程来启动Activity；

        Step 5 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，因为新的Activity就在原来的Activity所在的进程中进行启动；

        Step 6 ActivityManagerServic调用ApplicationThreadscheduleLaunchActivity接口，通知相应的进程执行启动Activity的 *** 作；

        Step 7 ApplicationThread把这个启动Activity的 *** 作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。

ViewModel旨在以注重生命周期的方式存储和管理界面相关的数据(配合它里面的livedata)。

11 将Activity的UI处理和数据处理分离，分开管理，解耦且高效。

12 ViewModel在屏幕旋转等系统配置更改后被继续保留，避免再次请求数据，浪费网络资源。重建该 Activity时，它接收的ViewModel实例与之前的Activity持有的ViewModel相同。

只有当Activity真正销毁时，框架才会调用getViewModelStore()clear()清除所有的ViewModel。

13 避免页面销毁后，数据返回后刷新界面导致crash，例如页面发起请求后，数据还没返回就关闭activity，数据返回后，刷新界面，因view不存在而crash。

14 两个Fragment可以使用其Activity的ViewModel来处理通信。

15 和onSaveInstanceState()对比，onSaveInstanceState()仅适合可以序列化再反序列化的少量数据，而不适合数量可能较大的数据，如用户列表或位图。

16 ViewModelScope，为应用中的每个ViewModel定义了ViewModelScope。如果ViewModel已清除，则在此范围内启动的协程都会自动取消。

ViewModelStoreOwner：是一个接口，ComponentActivity和Fragment实现了这个接口，所以我们在Activity或者Fragment中使用ViewModelProvider传入的this就可以了。

ViewModelStore：ViewModelStore主要是用来存储ViewModel对象的，内部有一个HashMap集合用来存储ViewModel对象。

ComponentActivity持有一个ViewModelStore，可以通过ViewModelStoreOwner中的getViewModelStore()方法获取。（为啥不直接在Activity获取ViewModelStore，再获取ViewModel呢？因为ViewModel要通过ViewModelProviderFactory创建）

Factory：是一个接口，用来创建ViewModel的

调用get方法后，会调用第二个get方法，传递key（DEFAULT_KEY + ":" + canonicalName）给第二个get方法

首先根据提供的key从ViewModelStore中获取一个ViewModel对象

如果这个获取到的ViewModel对象实例存在，那么就将其返回

如果该ViewModel对象不存在，就通过Factory创建一个ViewModel对象，并将其存储到ViewModelStore中，并将这个新创建的ViewModel对象返回。

这里面存在三个Factory：Factory，KeyedFactory和OnrequeryFactory，keyedFactory和Factory相比就是create方法中多了一个key参数。

ViewModelStore获取到ViewModel时，会判断当前mFactory是否是OnRequeryFactory类型的，是的话会回调onRequery方法

那么OnRequeryFactory回调onRequery有什么用呢？其实ViewModel不仅可以因为配置改变可以恢复Activity数据，也能恢复因为系统资源紧张而回收掉的Activity数据，只不过后者需要依靠SaveStateHandler

总结：ViewModelProvider获取到ViewModel：

1，首先创建ViewModelProvider传入ViewModelStoreOwner和Factory

2，调用ViewModelProvider的get方法，从ViewModelStore中获取ViewModel，有则直接返回，没有就通过反射创建一个，加入ViewModelStore中后，返回。

ViewModel是从ViewModelStore中获取

ViewModelStore是通过ViewModelStoreOwnergetViewModelStore方法获取

ComponentActivity实现了ViewModelStoreOwner接口和HasDefaultViewModelProviderFactory

getViewModelStore()通过两种方法获取到ViewModelStore

1，从NonConfigurationInstances中拿到

2，new一个出来

NonConfigurationInstances，用来包装不受配置更改影响的数据

Activity的NonConfigurationInstances在系统配置改变时保存了ViewModelStore和fragments等

系统配置发生改变时，AMS会调用ActivityThread的handleRelaunchActivity，并且通过当前Activity对应的ActivityRecord构建一个ActivityClientRecord传递过来

Activity的生命周期方法是在ActivityThread中执行的

Activity的retainNonConfigurationInstances 调用了onRetainNonConfigurationInstance

在调用onDestory()方法前，会创建一个NonConfigurationInstances对象，将viewModelStore存储在NonConfigurationInstances，然后将NonConfigurationInstances存储在ActivityClientrecord中。

ActivityThread的handleLaunchActivity最终会调用

performLaunchActivity，最终调用到activityattach，传入了lastNonConfigurationInstances

这样对于新的Activity来说，获取到的就是之前Activity的NonConfigurationInstance，其中的ViewModelStore也是之前的，ViewModel自然也是之前的。

这样就保证了在系统配置改变时，ViewModel不变了。

总结：

1，系统配置改变时，构建一个NonConfigurationInstance，将ViewModelStore保持到NonConfigurationInstance，再将NonConfigurationInstance保存到ActivityClientrecord的lastNonConfigurationInstances

2，恢复时，将ActivityClientrecord的lastNonConfigurationInstances传递给新的Activity，再通过getViewModelStore()获取时就能从新的Activity的lastNonConfigurationInstances获取ViewModelStore，进而获取之前的ViewModel

（1，系统配置发生改变时，调用handleRelaunchActivity，在这个方法中会先取出activity对应的ActivityClientrecord，然后调用handleDestroyActivity，在这个方法中，会调用ComponentActivity 的onRetainNonConfigurationInstance()，在这个方法中，会构建一个NonConfigurationInstance，将ViewModelStore保持到NonConfigurationInstance，再将NonConfigurationInstance保存到ActivityClientrecord的lastNonConfigurationInstances

2，恢复时，调用到handleLaunchActivity，在这个方法中会调用activityattach方法，在这个方法中，将ActivityClientrecord的lastNonConfigurationInstances传递给新的Activity的lastNonConfigurationInstances变量。获取ViewModelStore时，会从Activity的lastNonConfigurationInstances去获取（如果没有就新创建一个）如果有的话，自然就是之前的ViewModelStore，里面的ViewModel自然也是之前的。）

Activity正常销毁时，会通过getViewModelStore()clear()清理所有的ViewModel。

1， >

以上就是关于在一个Activity的java程序中，具体看问题描述全部的内容，包括:在一个Activity的java程序中，具体看问题描述、Android之Activity全面解析，有些知识点容易忘记、全面解析Activity: Activity的工作过程等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！