Activity启动过程分析

通常我们在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启动涉及到的类

首先要简单介绍一下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启动的一个时序图。

《Activity启动过程分析》 Activity启动过程.png

总结

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

  • Activity对象是怎么创建的?
  • Window对象是什么时候创建的?
  • LayoutInflater什么时候创建的?
  • 为什么在Activity中的布局中或者Fragment的中View获取的Context都是其所在的Activity对象?
  • 为什么自定义View一定要有两个参数的构造函数?
  • Activity的生命周期方法是被谁回调的?
  • Application是什么时候创建的?
  • ClassLoader对象是什么时候创建的?
  • 子线程可以启动Activity、Service吗?
  • 下拉通知栏,会影响Activity生命周期吗?

笔者初入Android开发没多久的时候,有次面试,面试官问我在子线程中启动Activity可以吗?我回答可以,因为我试过,但是问我为什么我却不知道。如果那时候看了Activity启动过程的源码,看了Binder机制的话,应该很容易的就回答出来了。

参考

    原文作者:sososeen09
    原文地址: https://www.jianshu.com/p/13b07beacb1f
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞