详解Android中的ActivityThread和APP启动过程

ActiviryThread

ActivityThread的初始化

ActivityThread即Android的主线程,也就是UI线程,ActivityThread的main方法是一个APP的真正入口,MainLooper在它的main方法中被创建。

//ActivityThread的main方法
public static void main(String[] args) {
    ...
    Looper.prepareMainLooper();
    ActivityThread thread = new ActivityThread();
    //在attach方法中会完成Application对象的初始化,然后调用Application的onCreate()方法
    thread.attach(false);

    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }
    ...
    Looper.loop();
    throw new RuntimeException("Main thread loop unexpectedly exited");
}

接下来从主线程Looper的初始化和ApplicationThread及Activity的创建启动两方面,通过源码了解学习下大致的流程。

主线程Looper的初始化

Looper.prepareMainLooper();相关的代码如下

//主线程Looper的初始化
public static void prepareMainLooper() {
    prepare(false);
    synchronized (Looper.class) {
        if (sMainLooper != null) {
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();
    }
}

//普通线程Looper的初始化
public static void prepare() {
    prepare(true);
}

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

看过Handler源码就知道,主线程Looper的初始化和普通线程Looper的初始化很相似,但还是有以下几个区别

1.普通线程的Prepare()默认quitAllowed参数为true,表示允许退出,而主线程也就是ActivityThread的Looper参数为false,不允许退出。这里的quitAllowed参数,最终会传递给MessageQueue,当调用MessageQueue的quit方法时,会判断这个参数,如果是主线程,也就是quitAllowed参数为false时,会抛出异常。

//Looper的退时会判断quitAllowed
void quit(boolean safe) {
    if (!mQuitAllowed) {
        throw new IllegalStateException("Main thread not allowed to quit.");
    }
    synchronized (this) {
        ...
    }
}

2.我们注意到主线程Looper初始化之后,赋值给了成员变量sMainLooper,这个成员的作用就是向其他线程提供主线程的Looper对象。这下我们就应该知道为什么Looper.getMainLooper()方法能获取主线程的Looper对象了

public static Looper getMainLooper() {
    synchronized (Looper.class) {
        return sMainLooper;
    }
}

主线程Handler的初始化

在ActivityThread的main方法中我们注意到一行代码:

ActivityThread thread = new ActivityThread();
thread.attach(false);
if (sMainThreadHandler == null) {
    sMainThreadHandler = thread.getHandler();
}

见名知意,这是获取主线程的Handler,那么主线程的Handler是在什么时候初始化的呢?

//与之相关的代码如下:
//ActivityThread的成员变量
final H mH = new H();

final Handler getHandler() {
    return mH;
}

从以上代码中可以看到,主线程的Handler作为ActivityThread的成员变量,是在ActivityThread的main方法被执行,ActivityThread被创建时而初始化,而接下来要说的ApplicationThread中的方法执行以及Activity的创建都依赖于主线程Handler。至此我们也就明白了,主线程(ActivityThread)的初始化是在它的main方法中,主线程的Handler以及MainLooper的初始化时机都是在ActivityThread创建的时候。

ApplicationThread及Activity的创建和启动

以上的代码和流程,就是对 MainLooper 和 ActivityThread 的初始化,我们接下来看一下 ActivityThread 的初始化及其对应的 attach 方法,在thread.attach方法中,ActivityManagerService通过attachApplication方法,将ApplicationThread对象绑定到ActivityManagerService,ApplicationThread是ActivityThread的私有内部类,实现了IBinder接口,用于ActivityThread和ActivityManagerService的所在进程间通信。

//ActivityThread的attach方法:
private void attach(boolean system) {
    ...
    if (!system) {
        final IActivityManager mgr = ActivityManager.getService();
        try {
            mgr.attachApplication(mAppThread);
        } catch (RemoteException ex) {
            throw ex.rethrowFromSystemServer();
        }else{
            ...
        }
    }
}

//ActivityManagerService中的方法:
public final void attachApplication(IApplicationThread thread) {
    synchronized (this) {
        int callingPid = Binder.getCallingPid();
        final long origId = Binder.clearCallingIdentity();
        attachApplicationLocked(thread, callingPid);
        Binder.restoreCallingIdentity(origId);
    }
}

这里的个人理解是:在每个ActivityThread(APP)被创建的时候,都需要向ActivityManagerService绑定(或者说是向远程服务AMS注册自己),用于AMS管理ActivityThread中的所有四大组件的生命周期。

上述AMS的代码中attachApplicationLocked方法比较复杂,主要功能有两个,详见注释,这里忽略了很多代码细节,具体的流程可以看源码

//AMS中的方法,主要功能有以下两步
private final boolean attachApplicationLocked(IApplicationThread thread, int pid) {
    ...
    //主要用于创建Application,用调用onCreate方法
    thread.bindApplication(...);
    ...
    //主要用于创建Activity
    if (mStackSupervisor.attachApplicationLocked(app)) {
        ...
    }
}

1.thread.bindApplication:主要用于创建Application,这里的thread对象是ApplicationThread在AMS中的代理对象,所以这里的bindApplication方法最终会调用ApplicationThread.bindApplication()方法,该方法会向ActivityThread的消息对应发送BIND_APPLICATION的消息,消息的处理最终会调用Application.onCreate()方法,这也说明Application.onCreate()方法的执行时机比任何Activity.onCreate()方法都早。

//ActivityThread中的bindApplication方法
public final void bindApplication(...) {
    ...
    // 该消息的处理,会调用handleBindApplication方法
    sendMessage(H.BIND_APPLICATION, data);
}
//ActivityThread中的handleBindApplication方法
private void handleBindApplication(AppBindData data) {
    ...
    try {
        Application app = data.info.makeApplication(data.restrictedBackupMode, null);
        mInitialApplication = app;
        ...
        try {
            mInstrumentation.callApplicationOnCreate(app);
        } catch (Exception e) {
        }
    } finally {
    }
}

//LoadedApk中的方法,用于创建Application
public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) {
    //如果存在Application的实例,则直接返回,这也说明Application是个单例
    if (mApplication != null) {
        return mApplication;
    }

    Application app = null;
    //...这里通过反射初始化Application

    if (instrumentation != null) {
        try {
            //调用Application的onCreate方法
            instrumentation.callApplicationOnCreate(app);
        } catch (Exception e) {
        }
    }
    return app;
}

2.mStackSupervisor.attachApplicationLocked(app):用于创建Activity,mStackSupervisor是AMS的成员变量,为Activity堆栈管理辅助类实例,该方法最终会调用ApplicationThread类的scheduleLaunchActivity方法,该方法也是类似于第一步,向ActivityThread的消息队列发送创建Activity的消息,最终在ActivityThread中完成创建Activity的操作。

boolean attachApplicationLocked(ProcessRecord app) throws RemoteException {
    ...
    if (realStartActivityLocked(hr, app, true, true)) {
        ...
    }
    ...
}

final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,
    boolean andResume, boolean checkConfig) throws RemoteException {
    ...
    try {
        //调用ApplicationThread的scheduleLaunchActivity用于启动一个Activity
        app.thread.scheduleLaunchActivity(...);
    } catch (RemoteException e) {

    }
}

ApplicationThread的scheduleLaunchActivity方法会向ActivityThread发送LAUNCH_ACTIVITY信息,用于启动一个Activity,该消息的处理会调用ActivityThread的handleLaunchActivity方法,最终启动一个Activity

以上就是从ActivityThread的main方法执行到Activity的创建之间的流程,至于ActivityThread的main方法执行时机,以及执行前的流程和Activity的具体创建过程,可以接着看APP的启动过程

APP的启动

系统的启动过程

在学习APP的启动之前先简单了解下系统的启动,有助于我们更好的学习APP的启动。系统的启动过程很复杂,这里简单化,只关心大致流程和涉及到的一些名词以及相关类的作用

APP的启动可以简单总结为一下几个流程:

加载BootLoader --> 初始化内核 --> 启动init进程 --> init进程fork出Zygote进程 --> Zygote进程fork出SystemServer进程

  • 系统中的所有经常进程都是由Zygote进程fork出来的
  • SystemServer进程是系统进程,很多系统服务,例如ActivityManagerService、PackageManagerService、WindowManagerService…都是存在该进程被创建后启动
  • ActivityManagerServices(AMS):是一个服务端对象,负责所有的Activity的生命周期,AMS通过Binder与Activity通信,而AMS与Zygote之间是通过Socket通信
  • ActivityThread:本篇的主角,UI线程/主线程,它的main()方法是APP的真正入口
  • ApplicationThread:一个实现了IBinder接口的ActivityThread内部类,用于ActivityThread和AMS的所在进程间通信
  • Instrumentation:可以理解为ActivityThread的一个工具类,在ActivityThread中初始化,一个进程只存在一个Instrumentation对象,在每个Activity初始化时,会通过Activity的Attach方法,将该引用传递给Activity。Activity所有生命周期的方法都有该类来执行

APP的启动过程

APP的启动,我们使用一张图来说明这个启动过程,顺便也总结下上面所说的ActivityThread的main方法执行到Activity的创建之间的流程。

1.点击桌面APP图标时,Launcher的startActivity()方法,通过Binder通信,调用system_server进程中AMS服务的startActivity方法,发起启动请求

2.system_server进程接收到请求后,向Zygote进程发送创建进程的请求

3.Zygote进程fork出App进程,并执行ActivityThread的main方法,创建ActivityThread线程,初始化MainLooper,主线程Handler,同时初始化ApplicationThread用于和AMS通信交互

4.App进程,通过Binder向sytem_server进程发起attachApplication请求,这里实际上就是APP进程通过Binder调用sytem_server进程中AMS的attachApplication方法,上面我们已经分析过,AMS的attachApplication方法的作用是将ApplicationThread对象与AMS绑定

5.system_server进程在收到attachApplication的请求,进行一些准备工作后,再通过binder IPC向App进程发送handleBindApplication请求(初始化Application并调用onCreate方法)和scheduleLaunchActivity请求(创建启动Activity)

6.App进程的binder线程(ApplicationThread)在收到请求后,通过handler向主线程发送BIND_APPLICATION和LAUNCH_ACTIVITY消息,这里注意的是AMS和主线程并不直接通信,而是AMS和主线程的内部类ApplicationThread通过Binder通信,ApplicationThread再和主线程通过Handler消息交互。 ( 这里猜测这样的设计意图可能是为了统一管理主线程与AMS的通信,并且不向AMS暴露主线程中的其他公开方法)

7.主线程在收到Message后,创建Application并调用onCreate方法,再通过反射机制创建目标Activity,并回调Activity.onCreate()等方法

8.到此,App便正式启动,开始进入Activity生命周期,执行完onCreate/onStart/onResume方法,UI渲染后显示APP主界面

APP启动过程的部分代码思考

在上面学习APP的启动过程中,看源码的同时注意到一个代码,就是主线程Handler在接收到LAUNCH_ACTIVITY创建Activity的消息后,创建Activity的部分代码如下:

//主线程Handler接收到创建Activity的消息LAUNCH_ACTIVITY后,最终会调用performLaunchActivity方法
//performLaunchActivity方法会通过反射去创建一个Activity,然后会调用Activity的各个生命周期方法
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    ...
    ContextImpl appContext = createBaseContextForActivity(r);
    Activity activity = null;
    try {
        //这里是反射创建Activity
        java.lang.ClassLoader cl = appContext.getClassLoader();
        activity = mInstrumentation.newActivity(
                cl, component.getClassName(), r.intent);
        StrictMode.incrementExpectedActivityCount(activity.getClass());
        r.intent.setExtrasClassLoader(cl);
        r.intent.prepareToEnterProcess();
        if (r.state != null) {
            r.state.setClassLoader(cl);
        }
    }

    try {
        //这里注意,又调用了一次Application的创建方法,但是前面分析过,Application是个单例,所以这里的实际上是获取Application实例,但是这里为什么会再次调用创建Application的方法呢?

        Application app = r.packageInfo.makeApplication(false, mInstrumentation);
        ...
    }
    ...
    return activity;
}

在上面的代码中,简单注释了一下在Activity的创建方法中,会再次调用Application的创建方法(第一次调用是在接收到BIND_APPLICATION消息的时候),个人觉得这里再次调用Application的创建方法,除了获取已经存在的Application实例这种情况,另外一种情况还有可能是要创建的这个Activity属于另外一个进程,当去启动这个新进程中的Activity时,会先去创建新进程和Application实例,因为我们知道一个常识:

1.APP中有几个进程,Application会被创建几次

2.新进程中所有变量和单例会失效,因为新进程有一块新的内存区域

那么这两点的关系就是,因为新进程中Application实例会为空,所以会再次去创建Application实例,这也就是第一点中我们所说的常识:APP中有几个进程,Application会被创建几次

//创建Application的方法
public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) {
    //如果存在Application的实例,则直接返回,这也说明Application是个单例
    if (mApplication != null) {
        return mApplication;
    }

    Application app = null;
    //...创建Application
    return app;
}

那么依次类推,Service作为四大组件之一,类似于Activity的创建和启动,创建Service的方法中会不会也调用了创建Application的方法(makeApplication方法),答案是肯定的!和Activity的创建类似,当我们调用startService的时候,也是通过Binder向AMS发送创建Service的请求,AMS准备后再向APP进程发送scheduleCreateService的请求,然后主线程handle收到CREATE_SERVICE的消息,调用handleCreateService创建Service的方法。在创建Service的方法handleCreateService中也调用了创建Application的方法,具体代码看源码吧。所以我们也彻底明白了为什么APP中有几个进程,Application会被创建几次,以及Application为什么是个单例。

总结

APP的启动过程很复杂,代码错综交横,这里分析了大概流程,学习这部分的过程中还是有很多收获,例如知道了AMS与主线程的关系,主线程main方法中就是APP的入口,Binder通信机制和handler消息机制在这个过程中的重要作用,Application的创建时机以及Application为什么是单例,为什么有几个进程就创建几个Application…等等 。

以上就是详解Android中的ActivityThread和APP启动过程的详细内容,更多关于Android ActivityThread APP启动过程的资料请关注我们其它相关文章!

时间: 2021-06-07

Android应用实现安装后自启动的方法

和网上大多数方法一样,使用广播手段: ACTION_PACKAGE_ADDED 一个新应用包已经安装在设备上,数据包括包名(最新安装的包程序不能接收到这个广播) ACTION_PACKAGE_REPLACED 一个新版本的应用安装到设备,替换之前已经存在的版本 ACTION_PACKAGE_CHANGED 一个已存在的应用程序包已经改变,包括包名 ACTION_PACKAGE_REMOVED 一个已存在的应用程序包已经从设备上移除,包括包名(正在被安装的包程序不能接收到这个广播) ACTION_

Android 多线程实现重复启动与停止的服务

Android 多线程实现重复启动与停止的服务 多线程环境下为了避免死锁,一般提倡开放调用,开放调用可以避免死锁,它的代价是失去原子性.但是在有些时候会显得逻辑错误, 例如: class A{ private boolean mIsStarted; void start(){ boolean changed = false; synchronized(this){ if(!mIsStarted){ mIsStarted = true; changed = false; } if(changed)

Android程序静默安装安装后重新启动APP的方法

 一:需求简介 之前boss提出一个需求,运行在广告机上的app,需要完成自动升级的功能,广告机是非触摸屏的,不能通过手动点击,所以app必须做到自动下载,自动安装升级,并且安装完成后,app还要继续运行,最好不借助其它app来实现以上功能.  二:实现思路 实现这个功能第一个想到的方法就是静默安装,由于广告机已经root,静默安装比较顺利,安装app的主要代码如下: /* @pararm apkPath 等待安装的app全路径,如:/sdcard/app/app.apk **/ private

Android 代码设置开机自启动App的方法

有的时候想要用户一旦打开手机.我们的APP就自动运行了. 代码如下: 创建一个监听. /** * create by:sunlei on 2017/7/7 15:48 * e-mail:872822645@qq.com * introduce: */ public class ContentReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { I

Android的权限设置及自启动设置方法

在开发项目中,遇到了两大麻烦: 1.涉及到的系统的权限较多(拍照.录音.定位.拨号等). 对于这点,有很多人会拒绝这些权限,那就尴尬了,他们又不懂只会跟我们反应这什么破app,这个不好用,那个不好使,更可恶的是不同手机的系统设置都长不一样,根本就不好跟他们讲在那里进行设置.于是想到解决的办法就是:在app中添加一个设置权限按钮让app直接跳到它的权限设置界面,这就方便多了.代码段如下: /** * 跳转到权限设置界面 */ private void getAppDetailSettingInte

Android实战APP启动速度优化

APP启动速度非常重要,APP启动速度慢,可能会造成用户体验不良好,尤其是在最近用Android studio之后,如果长时间不打开app,启动速度就会特别的慢,下面我们一起探讨一下影响app启动速度的原因,以及解决方案. 检测启动时间 首先我们要知道app的启动时间,然后你也可以凭着感觉来,这里我教大家一个装逼的方法: adb shell am start -W [packageName]/[.MainActivity] 用adb命令可以检测启动时间,示例如下: ./adb shell am

android引导用户开启自启动权限的方法

前言: 最近在做项目的过程中遇到了以下一个需求,虽然看起来不难实现,但是在实现的过程中遇到了各种坑,记录一下,今后方便查看!!! 需求: 用户第一次安装APP,点击授权按钮,跳转至授权的页面(不同手机跳转到不同的授权页面),用户授权成功之后,点击返回按钮,直接进入主页面 问题: 1.如何适配不同机型 2.不同机型的授权页面显示不同弹窗(比如三星显示悬浮窗,小米显示弹窗) 3.小米弹窗始终无法显示 4.在授权页面点击返回按钮,怎么直接跳转到主页面 问题1:适配不同机型 这个是借鉴的一篇博文(忘记地

android开机自启动APP及使用adb命令测试方法

android开机自动运行APP实现方式其实很简单.在android系统运行时,会发出"android.intent.action.BOOT_COMPLETED"这个系统广播,因此我们监听它,并进行打开APP的操作即可.现在大多数的android手机系统都默认禁止第三方安装的APP开机自启动,只有系统APP(system/app)才默认有这个权限,所以一般都需要去安全中心或者手机管家中去设置为允许.这里说个题外话,手机软件除非特殊情况,不然最好不要做开机自启动,开机自启动一般适用于an

Android线程管理之ActivityThread

ActivityThread功能 它管理应用进程的主线程的执行(相当于普通Java程序的main入口函数),并根据AMS的要求(通过IApplicationThread接口,AMS为Client.ActivityThread.ApplicationThread为Server)负责调度和执行activities.broadcasts和其它操作. 在Android系统中,在默认情况下,一个应用程序内的各个组件(如Activity.BroadcastReceiver.Service)都会在同一个进程(

android线程消息机制之Handler详解

android线程消息机制主要由Handler,Looper,Message和MessageQuene四个部分组成.平常在开发中,我们常用来在子线程中通知主线程来更新,其实整个安卓生命周期的驱动都是通过Handler(ActivityThread.H)来实现的. 首先我们先介绍这四个类的作用: Handler:消息的发送者.负责将Message消息发送到MessageQueue中.以及通过Runnable,Callback或者handleMessage()来实现消息的回调处理 Looper:是消

Android 线程thread的两种实现方法(必看)

这篇文章中有三点需要提前说明一下, 一:在android中有两种实现线程thread的方法: 一种是,扩展java.lang.Thread类 另一种是,实现Runnable接口 二:Thread类代表线程类,它的两个最主要的方法是: run()--包含线程运行时所执行的代码 Start()--用于启动线程 三: Handler 机制,它是Runnable和Activity交互的桥梁,在run方法中发送Message,在Handler里,通过不同的Message执行不同的任务. 下面分别给出两种线

Android相机管理工具类

本文实例为大家分享了Android相机管理工具类的具体代码,供大家参考,具体内容如下 package com.utils.tools; import java.io.BufferedOutputStream; import java.io.File; import java.io.FileOutputStream; import com.shennongshi.dingdong.R; import com.shennongshi.dingdong.pztools.IntentConstant.R

Android手机管理工具类详解

Android手机管理工具类 AppPhoneMgr分享给大家,供大家参考,具体内容如下 工具类内的方法: getInstance          : 单例对象 getSDKVersionNumber  : 获取手机系统版本号 getPhoneModel        : 获取手机型号 getPhoneWidth        : 获取手机宽度 getPhoneHeight       : 获取手机高度 getPhoneImei         : 获取手机imei串号 ,GSM手机的 IME

Android 线程之自定义带消息循环Looper的实例

Android 线程之自定义带消息循环Looper的实例 Android系统的UI线程是一种带消息循环(Looper)机制的线程,同时Android也提供了封装有消息循环(Looper)的HandlerThread类,这种线程,可以绑定Handler()对象,并通过Handler的sendMessage()函数向线程发送消息,通过handleMessage()函数,处理线程接收到的消息.这么说比较抽象,那么,本文就利用基础的Java类库,实现一个带消息循环(Looper)的线程,以帮助初学者理解

Android线程中设置控件的值提示报错的解决方法

本文实例讲述了Android线程中设置控件的值提示报错的解决方法.分享给大家供大家参考,具体如下: 在Android线程中设置控件的值一般会与Handler联合使用,如下: package com.yarin.android.Examples_04_15; import android.app.Activity; import android.os.Bundle; import android.os.Handler; import android.os.Message; import andro

Linux线程管理必备:解析互斥量与条件变量的详解

做过稍微大一点项目的人都知道,力求程序的稳定性和调度的方便,使用了大量的线程,几乎每个模块都有一个专门的线程处理函数.而互斥量与条件变量在线程管理中必不可少,任务间的调度几乎都是由互斥量与条件变量控制.互斥量的实现与进程中的信号量(无名信号量)是类似的,当然,信号量也可以用于线程,区别在于初始化的时候,其本质都是P/V操作.编译时,记得加上-lpthread或-lrt哦. 有关进程间通信(消息队列)见:进程间通信之深入消息队列的详解 一.互斥量 1. 初始化与销毁: 对于静态分配的互斥量, 可以

Android线程的优先级设置方法技巧

对于Android平台上的线程优先级设置来说可以处理很多并发线程的阻塞问题,比如很多无关紧要的线程会占用大量的CPU时间,虽然通过了MultiThread来解决慢速I/O但是合理分配优先级对于并发编程来说十分重要.Android在线程方面主要使用的是Java本身的Thread类,我们可以在Thread或Runnable接口中的run方法首句加入Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); //设置线程优先级为后台,这

如何正确使用Android线程详解

前言 对于移动开发者来说,"将耗时的任务放到子线程去执行,以保证UI线程的流畅性"是线程编程的第一金科玉律,但这条铁则往往也是UI线程不怎么流畅的主因.我们在督促自己更多的使用线程的同时,还需要时刻提醒自己怎么避免线程失控. 多线程编程之所以复杂原因之一在于其并行的特性,人脑的工作方式更符合单线程串行的特点.一个接着一个的处理任务是大脑最舒服的状态,频繁的在任务之间切换会产生"头痛"这类系统异常.人脑的多任务和计算机的多任务性能差异太大导致我们在设计并行的业务逻辑之