一、前言：

通常我们在Activity中启动一个另一个Activity，就是调用Activity的startActivity方法，这个最终会调用到Activity的startActivityForResult方法。那你有没有想过Activity的启动到底经历了哪些过程，我们今天就来分析一下。

在具体分析之前，要先说明一下，Activity的启动流程在细节挺繁琐的，比如启动另一个App的Activity或者启动不同的launchMode的Activity，在细节上都会有不同。我们这次的源码分析着重分析一下流程，为了简单起见，就以分析一个Activity启动app内部另一个standard模式的Activity为主。

Activity启动另一个Activity之前，当前的Activity先要执行onPause，被启动的Activity才会执行到onResume方法。这中间实际上是会执行4次IPC过程的：

• 当前Activity发起启动另一个Activity的请求——>ActivityManagerService
• ActivityManagerService——> 通知App暂停当前Activity
• 当前App告知已经暂停了当前的Activity——> ActivityManagerService
• ActivityManagerService ——> 通知App启动新的Activity

注：本次源码分析采用Android7.0，不同版本的源码在细节上会有不同，比如，在Android8.0上ActivityManagerService就改成了以AIDL的方式来写，请不要太纠结API的不同。

二、Activity启动涉及到的类

首先要简单介绍一下Activity启动过程涉及到的类，以便于更好的理解这个启动过程。

• ActivityThread：App启动的入口
• ApplicationThread：ActivityThread的内部类，继承Binder，可以进程跨进程通信。
• ApplicationThreadProxy：ApplicationThread的一个本地代理，其它的client端通过这个对象调用server端ApplicationThread中方法。
• Instrumentation：负责发起Activity的启动、并具体负责Activity的创建以及Activity生命周期的回调。一个应用进程只会有一个Instrumentation对象，App内的所有Activity都持有该对象的引用。
• ActivityManagerService：简称AMS，是service端对象，负责管理系统中所有的Activity
• ActivityManagerProxy：是ActivityManagerService的本地代理
• ActivityStack：Activity在AMS的栈管理，用来记录已经启动的Activity的先后关系，状态信息等。通过ActivityStack决定是否需要启动新的进程。
• ActivityRecord：ActivityStack的管理对象，每个Activity在AMS对应一个ActivityRecord，来记录Activity的状态以及其他的管理信息。其实就是服务器端的Activity对象的映像。
• TaskRecord：AMS抽象出来的一个“任务”的概念，是记录ActivityRecord的栈，一个“Task”包含若干个ActivityRecord。AMS用TaskRecord确保Activity启动和退出的顺序。

介绍完这些，我们开始进入正题

三、Activity的启动过程

Activity启动最终会调用到startActivityForResult方法，我们只需要关注mParent == null中的逻辑即可。mParent代表的是ActivityGroup，其最开始是为了在一个界面中嵌入多个子Activity，在API13的时候就已经废弃了，可以使用Fragment表示一个界面的多个区域。

# android.app.Activity
public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
                                   @Nullable Bundle options) {
    if (mParent == null) {
        Instrumentation.ActivityResult ar =
                mInstrumentation.execStartActivity(
                        this, mMainThread.getApplicationThread(), mToken, this,
                        intent, requestCode, options);
        if (ar != null) {
            mMainThread.sendActivityResult(
                    mToken, mEmbeddedID, requestCode, ar.getResultCode(),
                    ar.getResultData());
        }
        ...
    } else {
        ...
    }
}

调用了Instrumentation的execStartActivity方法，在这里通过ActivityManagerNative.getDefault()方法获取ActivityManagerService的一个本地代理对象ActivityManagerProxy，然后调用了其startActivity方法：

# android.app.Instrumentation
public ActivityResult execStartActivity(
        Context who, IBinder contextThread, IBinder token, Activity target,
        Intent intent, int requestCode, Bundle options) {
    IApplicationThread whoThread = (IApplicationThread) contextThread;
    ...
    try {
       ... 
        int result = ActivityManagerNative.getDefault()
                .startActivity(whoThread, who.getBasePackageName(), intent,
                        intent.resolveTypeIfNeeded(who.getContentResolver()),
                        token, target != null ? target.mEmbeddedID : null,
                        requestCode, 0, null, options);
        checkStartActivityResult(result, intent);
    } catch (RemoteException e) {
        throw new RuntimeException("Failure from system", e);
    }
    return null;
}

我们看一下ActivityManagerNative，继承了Binder并实现了IActivityManager接口，ActivityManagerService就是继承了ActivityManagerNative。

public abstract class ActivityManagerNative extends Binder implements IActivityManager

public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback

class ActivityManagerProxy implements IActivityManager

ActivityManagerNative实际上获取的就是其内部类ActivityManagerProxy对象。ActivityManagerProxy只是ActivityManagerService的本地代理对象，其startActivity方法会调用到AMS的startActivity方法。而且要注意，这个startActivity方法会把ApplicationThread对象传递到AMS所在进程，当然了AMS拿到的实际上是ApplicationThread的代理对象ApplicationThreadProxy，AMS就要通过这个代理对象与我们的App进程进行通信。

# android.app.ActivityManagerNative
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
    protected IActivityManager create() {
        IBinder b = ServiceManager.getService("activity");
        if (false) {
            Log.v("ActivityManager", "default service binder = " + b);
        }
        IActivityManager am = asInterface(b);
        if (false) {
            Log.v("ActivityManager", "default service = " + am);
        }
        return am;
    }
};

static public IActivityManager asInterface(IBinder obj) {
    if (obj == null) {
        return null;
    }
    IActivityManager in =
            (IActivityManager)obj.queryLocalInterface(descriptor);
    if (in != null) {
        return in;
    }

    return new ActivityManagerProxy(obj);
}

static public IActivityManager getDefault() {
    return gDefault.get();
}

注：在Android8.0，由于使用AIDL的方式来写ActivityManagerService，ActivityManagerNative已经过期。

我们接着看一下AMS的startActivity方法：

# com.android.server.am.ActivityManagerService
public final int startActivity(IApplicationThread caller, String callingPackage,
                               Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
                               int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) {
    return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
            resultWho, requestCode, startFlags, profilerInfo, bOptions,
            UserHandle.getCallingUserId());
}

startActivity方法紧接着调用了其startActivityAsUser方法。

@Override
public final int startActivityAsUser(IApplicationThread caller, String callingPackage,
                                     Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
                                     int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, int userId) {
    enforceNotIsolatedCaller("startActivity");
    userId = mUserController.handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(),
            userId, false, ALLOW_FULL_ONLY, "startActivity", null);
    // TODO: Switch to user app stacks here.
    return mActivityStarter.startActivityMayWait(caller, -1, callingPackage, intent,
            resolvedType, null, null, resultTo, resultWho, requestCode, startFlags,
            profilerInfo, null, null, bOptions, false, userId, null, null);
}

接着调用了ActivityStarter的startActivityMayWait方法，由于方法很长，我们只保留关键的流程部分：

# com.android.server.am.ActivityStarter
final int startActivityMayWait(IApplicationThread caller, int callingUid,
        String callingPackage, Intent intent, String resolvedType,
        IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
        IBinder resultTo, String resultWho, int requestCode, int startFlags,
        ProfilerInfo profilerInfo, IActivityManager.WaitResult outResult, Configuration config,
        Bundle bOptions, boolean ignoreTargetSecurity, int userId,
        IActivityContainer iContainer, TaskRecord inTask) {
   
        ...
        int res = startActivityLocked(caller, intent, ephemeralIntent, resolvedType,
                aInfo, rInfo, voiceSession, voiceInteractor,
                resultTo, resultWho, requestCode, callingPid,
                callingUid, callingPackage, realCallingPid, realCallingUid, startFlags,
                options, ignoreTargetSecurity, componentSpecified, outRecord, container,
                inTask);

         ...
    }
}

ActivityStarter调用了自身的startActivityLocked方法，这又是一个很长的方法，保留关键的流程如下。

# com.android.server.am.ActivityStarter

final int startActivityLocked(IApplicationThread caller, Intent intent, Intent ephemeralIntent,
        String resolvedType, ActivityInfo aInfo, ResolveInfo rInfo,
        IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
        IBinder resultTo, String resultWho, int requestCode, int callingPid, int callingUid,
        String callingPackage, int realCallingPid, int realCallingUid, int startFlags,
        ActivityOptions options, boolean ignoreTargetSecurity, boolean componentSpecified,
        ActivityRecord[] outActivity, ActivityStackSupervisor.ActivityContainer container,
        TaskRecord inTask) {
    int err = ActivityManager.START_SUCCESS;
    ...
    try {
        mService.mWindowManager.deferSurfaceLayout();
        err = startActivityUnchecked(r, sourceRecord, voiceSession, voiceInteractor, startFlags,
                true, options, inTask);
    } finally {
        mService.mWindowManager.continueSurfaceLayout();
    }
    postStartActivityUncheckedProcessing(r, err, stack.mStackId, mSourceRecord, mTargetStack);
    return err;
}

ActivityStarter又调用了自身的startActivityUnchecked方法，

# com.android.server.am.ActivityStarter

private int startActivityUnchecked(final ActivityRecord r, ActivityRecord sourceRecord,
        IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
        int startFlags, boolean doResume, ActivityOptions options, TaskRecord inTask) {
    ...
    if (mDoResume) {
        ...
        if (!mTargetStack.isFocusable()
            ...
        } else {
            mSupervisor.resumeFocusedStackTopActivityLocked(mTargetStack, mStartActivity,
                    mOptions);
        }
    } else {
       ...
    }
    ...
    return START_SUCCESS;
}

在ActivityStarter中调用了ActivityStackSupervisor的resumeFocusedStackTopActivityLocked方法。

# com.android.server.am.ActivityStackSupervisor

boolean resumeFocusedStackTopActivityLocked(
        ActivityStack targetStack, ActivityRecord target, ActivityOptions targetOptions) {
    if (targetStack != null && isFocusedStack(targetStack)) {
        return targetStack.resumeTopActivityUncheckedLocked(target, targetOptions);
    }
    ... 
}

在ActivityStackSupervisor的resumeFocusedStackTopActivityLocked中又调用了ActivityStack的resumeTopActivityUncheckedLocked方法。

# com.android.server.am.ActivityStack

boolean resumeTopActivityUncheckedLocked(ActivityRecord prev, ActivityOptions options) {
   ...
    boolean result = false;
    try {
        // Protect against recursion.
        mStackSupervisor.inResumeTopActivity = true;
        ...
        result = resumeTopActivityInnerLocked(prev, options);
    } finally {
        mStackSupervisor.inResumeTopActivity = false;
    }
    return result;
}

ActivityStack在resumeTopActivityUncheckedLocked又调用了其自身的resumeTopActivityInnerLocked方法。

# com.android.server.am.ActivityStack
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
     ..
    // We need to start pausing the current activity so the top one can be resumed...
    ...
    if (mResumedActivity != null) {
        if (DEBUG_STATES) Slog.d(TAG_STATES,
                "resumeTopActivityLocked: Pausing " + mResumedActivity);
        pausing |= startPausingLocked(userLeaving, false, next, dontWaitForPause);
    }
    ...
}

由于当前的Activity执行了onResume，所以mResumedActivity != null 条件满足，就会调用startPausingLocked方法先暂停当前的Activity。注意：这个过程必然是一个IPC过程。我们看一下startPausingLocked方法。

# com.android.server.am.ActivityStack
final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,
        ActivityRecord resuming, boolean dontWait) {

    ActivityRecord prev = mResumedActivity;
    ...

    if (prev.app != null && prev.app.thread != null) {
        if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "Enqueueing pending pause: " + prev);
        try {
            ...
            prev.app.thread.schedulePauseActivity(prev.appToken, prev.finishing,
                    userLeaving, prev.configChangeFlags, dontWait);
        } catch (Exception e) {
           ...
        }
    } else {
       ...
    }
    ...
}

prev.app.thread表示的是IApplicationThread对象，在这里就是指的发起启动的Activity所在进程的ApplicationThread的本地代理ApplicationThreadProxy。调用它的schedulePauseActivity方法，很明显是一次IPC过程，最终调用到server端，也就是发起启动的Activity所在进程ApplicationThread的schedulePauseActivity方法。

# android.app.ActivityThread$$ApplicationThread

public final void schedulePauseActivity(IBinder token, boolean finished,
        boolean userLeaving, int configChanges, boolean dontReport) {
    int seq = getLifecycleSeq();
    if (DEBUG_ORDER) Slog.d(TAG, "pauseActivity " + ActivityThread.this
            + " operation received seq: " + seq);
    sendMessage(
            finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY,
            token,
            (userLeaving ? USER_LEAVING : 0) | (dontReport ? DONT_REPORT : 0),
            configChanges,
            seq);
}

通过Hander的转发，接着会调用到ActivityThread的handlePauseActivity方法。

# android.app.ActivityThread

private void handlePauseActivity(IBinder token, boolean finished,
        boolean userLeaving, int configChanges, boolean dontReport, int seq) {
    ActivityClientRecord r = mActivities.get(token);
    ...
    if (r != null) {
    ...
        performPauseActivity(token, finished, r.isPreHoneycomb(), "handlePauseActivity");
    ...
        // Tell the activity manager we have paused.
        if (!dontReport) {
            try {
                ActivityManagerNative.getDefault().activityPaused(token);
            } catch (RemoteException ex) {
                throw ex.rethrowFromSystemServer();
            }
        }
        mSomeActivitiesChanged = true;
    }
}

在ActivityThread的handlePauseActivity中，首先会调用performPauseActivity来暂停当前的Activity，经过层层调用，会调用到Intrumentation的callActivityOnPause方法，最终调用Activity的onPause方法，这一块的流程比较简单，在这里就不再详细分析了，感兴趣的可以自己研究下。
暂停之后，会调动ActivityManagerNative.getDefault().activityPaused(token)，这个很明显又是一次IPC过程，就是告诉AMS，已经暂停当前的Activity，可以启动新的Activity 了。
我们来看一下AMS的的activityPaused方法：

# com.android.server.am.ActivityManagerService
@Override
public final void activityPaused(IBinder token) {
    final long origId = Binder.clearCallingIdentity();
    synchronized(this) {
        ActivityStack stack = ActivityRecord.getStackLocked(token);
        if (stack != null) {
            stack.activityPausedLocked(token, false);
        }
    }
    Binder.restoreCallingIdentity(origId);
}

AMS中的activityPaused又调用了ActivityStack的activityPausedLocked方法。

# com.android.server.am.ActivityStack

final void activityPausedLocked(IBinder token, boolean timeout) {
    ...
    final ActivityRecord r = isInStackLocked(token);
    if (r != null) {
        mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r);
        if (mPausingActivity == r) {
            if (DEBUG_STATES) Slog.v(TAG_STATES, "Moving to PAUSED: " + r
                    + (timeout ? " (due to timeout)" : " (pause complete)"));
            completePauseLocked(true, null);
            return;
        } else {
           ...
        }
    }
   ...
}

在这个方法中又调用了ActivityStack自身的completePauseLocked方法，

# com.android.server.am.ActivityStack
private void completePauseLocked(boolean resumeNext, ActivityRecord resuming) {
    ActivityRecord prev = mPausingActivity;
    if (resumeNext) {
        final ActivityStack topStack = mStackSupervisor.getFocusedStack();
        if (!mService.isSleepingOrShuttingDownLocked()) {
            mStackSupervisor.resumeFocusedStackTopActivityLocked(topStack, prev, null);
        } else {
           ...
        }
    }
    ...
}

然后又调用了ActivityStackSupervisor的resumeFocusedStackTopActivityLocked方法，这视乎又重新调用了一遍，真复杂啊。
这个流程我们上面讲过了，ActivityStackSupervisor会继续调用ActivityStack的resumeTopActivityUncheckedLocked方法，然后ActivityStack又调用其resumeTopActivityInnerLocked方法，调来调去，又到这个方法里面了，上次在这里是执行了前一个Activity的onPause方法。这次会调用到ActivityStackSupersivor的startSpecificActivityLocked方法。

# com.android.server.am.ActivityStack
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
    
    // We need to start pausing the current activity so the top one can be resumed...
    final boolean dontWaitForPause = (next.info.flags & FLAG_RESUME_WHILE_PAUSING) != 0;
    boolean pausing = mStackSupervisor.pauseBackStacks(userLeaving, next, dontWaitForPause);
    if (mResumedActivity != null) {
        if (DEBUG_STATES) Slog.d(TAG_STATES,
                "resumeTopActivityLocked: Pausing " + mResumedActivity);
        pausing |= startPausingLocked(userLeaving, false, next, dontWaitForPause);
    }

    ...
    ActivityStack lastStack = mStackSupervisor.getLastStack();
    if (next.app != null && next.app.thread != null) {
        ...
    } else {
        ...
        mStackSupervisor.startSpecificActivityLocked(next, true, true);
    }

    if (DEBUG_STACK) mStackSupervisor.validateTopActivitiesLocked();
    return true;
}

分析到这里，好像我们的就要开始启动我们的目标Activity了，好激动有木有！
在ActivityStackSupersivor的startSpecificActivityLocked方法中会判断Activity所在进程是否存在，如果不存在的话就要创建一个新的进程。在这里，我们是Activity启动其App内部的另一个Activity，所以进程肯定是存在的，会走到realStartActivityLocked方法中。

# com.android.server.am.ActivityStackSupervisor
void startSpecificActivityLocked(ActivityRecord r,
        boolean andResume, boolean checkConfig) {
    ... 
    if (app != null && app.thread != null) {
        try {
    ...
            realStartActivityLocked(r, app, andResume, checkConfig);
            return;
        } catch (RemoteException e) {
           ...
        }

    }

    mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
            "activity", r.intent.getComponent(), false, false, true);
}

再来看一下ActivityStackSupersivor的realStartActivityLocked方法，这次似乎真的要启动一个Activity了。

# com.android.server.am.ActivityStackSupervisor

final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,
        boolean andResume, boolean checkConfig) throws RemoteException {
    ...
    try {

        app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
                System.identityHashCode(r), r.info, new Configuration(mService.mConfiguration),
                new Configuration(task.mOverrideConfig), r.compat, r.launchedFromPackage,
                task.voiceInteractor, app.repProcState, r.icicle, r.persistentState, results,
                newIntents, !andResume, mService.isNextTransitionForward(), profilerInfo);
       ...

    } catch (RemoteException e) {
       ...
    }
    ...
    return true;
}

看了代码，果然，调用了app.thread.scheduleLaunchActivity方法，app.thread我们前面讲过，就是IApplicationThread对象，实际上就是ApplicationThreadProxy对象，经过IPC过程会调用到ApplicationThread的scheduleLaunchActivity方法，我们来看一下：

# android.app.ActivityThread$$ApplicationThread
@Override
public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
        ActivityInfo info, Configuration curConfig, Configuration overrideConfig,
        CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor,
        int procState, Bundle state, PersistableBundle persistentState,
        List<ResultInfo> pendingResults, List<ReferrerIntent> pendingNewIntents,
        boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) {

    ...
    sendMessage(H.LAUNCH_ACTIVITY, r);
}

通过Hander的转发，接着会调用到ActivityThread的handlePauseActivity方法。

# android.app.ActivityThread
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
    ...
    Activity a = performLaunchActivity(r, customIntent);

    if (a != null) {
    ...
        handleResumeActivity(r.token, false, r.isForward,
                !r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);
      ...
    } else {
       ...
    }
}

handlePauseActivity内部调用performLaunchActivity方法：

# android.app.ActivityThread
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    ...
    Activity activity = null;
    try {
        java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
        activity = mInstrumentation.newActivity(
                cl, component.getClassName(), r.intent);
        ...
    } catch (Exception e) {
       ...
    }

    try {
        Application app = r.packageInfo.makeApplication(false, mInstrumentation);
        ...
        if (activity != null) {
            Context appContext = createBaseContextForActivity(r, activity);
            ...
            activity.attach(appContext, this, getInstrumentation(), r.token,
                    r.ident, app, r.intent, r.activityInfo, title, r.parent,
                    r.embeddedID, r.lastNonConfigurationInstances, config,
                    r.referrer, r.voiceInteractor, window);

            ...
            activity.mCalled = false;
            if (r.isPersistable()) {
                mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
            } else {
                mInstrumentation.callActivityOnCreate(activity, r.state);
            }
           ...
            r.activity = activity;
            r.stopped = true;
            if (!r.activity.mFinished) {
                activity.performStart();
                r.stopped = false;
            }
            if (!r.activity.mFinished) {
                if (r.isPersistable()) {
                    if (r.state != null || r.persistentState != null) {
                        mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state,
                                r.persistentState);
                    }
                } else if (r.state != null) {
                    mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
                }
            }
            if (!r.activity.mFinished) {
                activity.mCalled = false;
                if (r.isPersistable()) {
                    mInstrumentation.callActivityOnPostCreate(activity, r.state,
                            r.persistentState);
                } else {
                    mInstrumentation.callActivityOnPostCreate(activity, r.state);
                }
                if (!activity.mCalled) {
                    throw new SuperNotCalledException(
                        "Activity " + r.intent.getComponent().toShortString() +
                        " did not call through to super.onPostCreate()");
                }
            }
        }
        r.paused = true;

        mActivities.put(r.token, r);

    } catch (SuperNotCalledException e) {
        throw e;

    } catch (Exception e) {
       ...
    }

    return activity;
}

在performLaunchActivity内部，创建了Activity对象，并调用了activity的attach方法，在这个方法中绑定一些属性，并且创建了Activity所属的Window对象。接着Instrumentation会调用callActivityOnCreate、callActivityOnRestoreInstanceState、callActivityOnPostCreate等来完成Activity生命周期的回调。不过有一点很有意思，在这个方法中Activity自己调用了其performStart方法，但这个方法内部又调用了Instrumentation的callActivityOnStart方法，进而又调用了Activity的onStart方法。绕过来绕过去，总之，Activity生命周期方法的调用均是通过Instrumentation来控制的。

至此，Activity的启动过程算是分析完了，太费脑筋了，需要来一瓶营养快线补补身体。流程太多，不好记，但是有句话说的好 "一图胜千言"，下面我们来看一下Activity启动的一个时序图。

图片.png

四、总结：

源码分析过程是比较绕，比较烧脑的过程，不要太纠结去API的调用，尽量侧重流程。分析源码，最好带着问题去分析，不要为了分析而分析，尽量在分析过程中寻找自己想要的答案。比如：

1、Activity对象是怎么创建的？

• Activity 对象是在应用程序启动时由 Android 系统创建的。当用户启动应用程序并点击应用程序图标时，系统会为其创建一个新的进程，并在其中创建主 Activity。

• 具体来说，在 AndroidManifest.xml 文件中配置的启动 Activity 将作为应用程序的入口点，并成为该进程的第一个组件。系统会自动实例化该 Activity 并调用其 onCreate() 方法，该方法用于初始化该 Activity 的状态和资源。

• 在后续的生命周期中，Activity 对象会根据需要动态创建或销毁。例如，当用户从一个 Activity 转到另一个 Activity 时，系统会销毁前一个 Activity，并创建新的 Activity。当应用程序被关闭时，系统会依次销毁所有的 Activity，并释放相关资源。

• 需要注意的是，在某些情况下，您可以通过使用 Intent 或 startActivityForResult() 等机制来启动其他应用程序的 Activity。在这种情况下，与该 Activity 相关联的生命周期和资源管理由该应用程序负责，而不是你的应用程序。

2、Window对象是什么时候创建的？

• Window 对象是在 Activity 被创建时由 Android 系统自动创建的。在 Activity 的生命周期中，Window 对象的创建和销毁与 Activity 的创建和销毁密切相关。

• 具体而言，在 Activity 的 onCreate() 方法中，系统会调用 Activity 的 getWindow() 方法来获取该 Activity 的 Window 对象，并将其作为返回值返回。这个 Window 对象用于显示该 Activity 的用户界面和管理与用户交互的事件。

• 一个 Activity 可以拥有多个 Window 对象，但通常情况下只会有一个主要的 Window 对象，用于显示 Activity 的内容。如果需要显示额外的窗口（如对话框或弹出菜单等），则可以通过调用 Dialog 类或 PopupWindow 类的构造函数来创建它们的 Window 对象。

• 需要注意的是，与大多数 Android 组件一样，Window 对象也有其自己的生命周期。当 Activity 被销毁时，与之关联的 Window 对象也会被销毁，并释放相关资源。因此，应该避免在 Activity 被销毁后继续使用其 Window 对象，以避免出现异常或内存泄漏等问题。

3、LayoutInflater什么时候创建的？

• LayoutInflater 是在 Activity 运行期间动态创建的。当 Activity 调用 setContentView() 方法时，系统会使用 LayoutInflater 对布局文件进行解析，并将其转换为 View 对象。

• 在调用 setContentView() 方法时，系统会自动创建一个 LayoutInflater 对象。这个 LayoutInflater 对象通常是由该 Activity 的 Context 对象创建的，因此它可以访问应用程序的资源和服务。

• LayoutInflater 在解析布局文件时使用了缓存机制，以提高性能并避免重复的解析过程。一旦布局文件被解析并转换为 View 对象，就不需要再次解析了。如果您需要对同一布局文件进行多次解析，则可以使用 LayoutInflater 的 cloneInContext() 方法来创建一个新的 LayoutInflater 对象，并将其与另一个 Context 关联起来，以避免影响原始的 LayoutInflater 缓存。

• 需要注意的是，LayoutInflater 只能用于解析布局文件，它不能直接用于创建 View 对象。如果您需要在代码中动态创建 View 对象，则可以使用 View 或其子类的构造函数进行创建。

4、为什么在Activity中的布局中或者Fragment的中View获取的- Context都是其所在的Activity对象？

• 在 Android 中，每个 View 都必须与一个 Context 对象相关联。这个 Context 对象通常是其所在的 Activity 或 Fragment 的 Context。

• 当布局文件中的 View 被加载到 Activity 或 Fragment 中时，它们会自动继承其父级的 Context 对象。因此，在 Activity 或 Fragment 中访问 View 时，它们将返回其所在的 Activity 或 Fragment 对象作为 Context。

• 这也意味着，如果您在自定义 View 中需要使用 Context 对象，最好的方法是将其传递给构造函数并保存为成员变量，而不是直接从 View 中获取 Context。这样可以确保您的 View 在任何上下文中都能正常工作，并且可以避免潜在的内存泄漏问题。

• 需要注意的是，在使用 Context 对象时要小心，特别是在涉及到生命周期或资源管理方面的操作时。在不需要使用 Context 对象时，应该尽可能地避免持有它，以免导致内存泄漏或其他问题。

4、为什么自定义View一定要有两个参数的构造函数？

在 Android 中，自定义 View 必须有两个参数的构造函数，即：

public CustomView(Context context, AttributeSet attrs)

这是因为在布局文件中声明自定义 View 时，系统会自动调用该构造函数来创建 View 的实例，并将布局文件中定义的属性传递给该实例。

• 第一个参数 context 表示上下文，用于获取资源和访问系统服务。
• 第二个参数 attrs 则表示包含了布局文件中定义的所有属性的值的 AttributeSet 对象。

如果您不重写这个构造函数，那么当您在布局文件中使用自定义 View 时，系统将无法正确地解析它所定义的属性，从而导致出现运行时错误。

需要注意的是，自定义 View 构造函数的第二个参数 AttributeSet 并不是必须的。如果您的自定义 View 不需要使用 XML 属性，可以只提供一个参数的构造函数。但是，为了保持一致性，建议始终实现两个参数的构造函数。

5、Activity的生命周期方法是被谁回调的？

Activity 的生命周期方法是被 Android 系统回调的。当 Activity 发生状态改变时，例如创建、启动、停止或销毁等，系统会自动调用对应的生命周期方法。

下面是 Activity 常用的生命周期方法及其描述：

• onCreate()：当 Activity 第一次被创建时调用。
• onStart()：当 Activity 可见但未获得焦点时调用。
• onResume()：当 Activity 可见并且获得焦点时调用。
• onPause()：当 Activity 失去焦点但仍然可见时调用。
• onStop()：当 Activity 不再可见时调用。
• onDestroy()：当 Activity 被销毁时调用。

除了上述方法之外，还有一些其他的生命周期方法，如 onRestart()、onSaveInstanceState() 和 onRestoreInstanceState() 等，它们在特定情况下被调用。这些方法的调用顺序也是固定的，并且可以通过重写这些方法来控制 Activity 的行为和状态。

6、Application是什么时候创建的？

在 Android 应用程序的生命周期中，Application 对象是在应用程序启动时由系统创建的。当用户第一次启动应用程序时，系统会为其创建一个进程并开始执行应用程序的代码。

• 在该进程中，Application 对象是第一个被创建的组件，它负责管理应用程序的全局状态和资源。在 Application 对象被创建之前，任何其他组件（如 Activity）都不能被创建。
• 一旦 Application 对象被创建，它将一直存在于整个应用程序的生命周期中，直到应用程序被终止。因此，我们可以利用 Application 对象来保存应用程序中需要在多个组件之间共享的数据，以及初始化全局的资源和服务等。

需要注意的是，Application 对象是运行在主线程上的，因此应该避免在 Application 对象中执行长时间运行的操作，否则可能会导致应用程序无响应甚至崩溃。

7、ClassLoader对象是什么时候创建的？

ClassLoader 对象在 Java 程序运行期间动态创建，用于加载类文件。ClassLoader 是在需要加载类时动态创建的，可以根据不同的需求创建不同的 ClassLoader 实例。

在 Java 应用程序启动时，会默认创建三个 ClassLoader 对象：

• Bootstarp ClassLoader：它负责加载 Java API 中核心类库，是由 JVM 自带的，无法被用户代码直接引用。
• Extension ClassLoader：它负责加载 Java 的扩展类库，默认情况下从 ${java.home}/lib/ext 目录下加载类库。
• Application ClassLoader（也称为 System ClassLoader）：它负责加载应用程序的类库，即我们自己编写的代码。

除了这三个默认的 ClassLoader 对象之外，开发人员还可以根据需要创建自定义的 ClassLoader。它们通常用于实现特定的功能，如动态更新应用程序、热加载类等。

8、子线程可以启动Activity、Service吗？

在 Android 中，子线程不能直接启动 Activity 或 Service。这是因为这些组件必须在主线程中创建和运行。

如果您的应用程序需要从子线程中启动 Activity 或 Service，则可以使用以下方法：

• 使用 Handler 将操作传递回主线程并在主线程中启动 Activity 或 Service。
• 使用 runOnUiThread() 方法将操作传递回主线程并在主线程中启动 Activity 或 Service。
• 使用 AsyncTask 或 RxJava 等异步编程框架，在 doInBackground() 方法中执行计算密集型操作，并在 onPostExecute() 方法中启动 Activity 或 Service。

无论您选择哪种方法，都应该避免在主线程中执行耗时操作，以避免出现应用程序无响应（ANR）的情况。

9、下拉通知栏，会影响Activity生命周期吗？

下拉通知栏不会直接影响 Activity 的生命周期。当用户下拉通知栏时，Activity 仍然处于活动状态并可以响应事件。

但是，如果您的应用程序正在执行某些与 Activity 生命周期相关的操作（例如保存和恢复数据、处理配置更改等），则可能会影响 Activity 的生命周期。此时，您需要确保正确地处理这些事件，并且在必要的情况下保存和恢复 Activity 状态。

值得注意的是，当用户下拉通知栏时，系统可能会暂停或停止 Activity。如果系统需要释放资源以支持其他应用程序或操作系统功能，则可能会发生这种情况。但是，这只会在极端情况下发生，并且您的应用程序应该能够正确处理这种情况。

参考作者：sososeen09
链接：//www.greatytc.com/p/13b07beacb1f