【Android 14源码分析】Activity启动流程-3

忽然有一天,我想要做一件事:去代码中去验证那些曾经被“灌输”的理论。
                  
                  
                                           – 服装学院的IT男

本篇已收录于Activity短暂的一生系列
欢迎一起学习讨论Android应用开发或者WMS
V:WJB6995
Q:707409815

正文

由于篇幅原因,整个启动流程分为以下3篇进行分析:

Activity启动流程-1

Activity启动流程-2

Activity启动流程-3

本篇介绍阶段三的逻辑,这部分的分析上篇阶段二的触发点是同级的,也就是在阶段一中 TaskFragment::resumeTopActivity 触发的。
进程是怎么创建的不是当前分析的重点,所以快速过一遍流程。

1 阶段三–触发进程创建

执行pause后会执行 ActivityTaskManagerService::startProcessAsync,最后也是通过 ActivityManagerService来触发启动进程的。
看看AMS这块执行进程创建的调用流程

# ActivityTaskManagerService

    void startProcessAsync(ActivityRecord activity, boolean knownToBeDead, boolean isTop,
            String hostingType) {
        try {
            if (Trace.isTagEnabled(TRACE_TAG_WINDOW_MANAGER)) {
                Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "dispatchingStartProcess:"
                        + activity.processName);
            }

            // 发送消息,启动进程,调用 ActivityManagerInternal::startProcess
            final Message m = PooledLambda.obtainMessage(ActivityManagerInternal::startProcess,
                    mAmInternal, activity.processName, activity.info.applicationInfo, knownToBeDead,
                    isTop, hostingType, activity.intent.getComponent());
            mH.sendMessage(m);
        } finally {
            Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
        }
    }

这里通过 Handler 来完成,ActivityManagerInternal::startProcess 的实现在 ActivityManagerService 的内部类 LocalService 中。

# ActivityManagerService$LocalService

        public void startProcess(String processName, ApplicationInfo info, boolean knownToBeDead,
                boolean isTop, String hostingType, ComponentName hostingName) {
            try {
                if (Trace.isTagEnabled(Trace.TRACE_TAG_ACTIVITY_MANAGER)) {
                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "startProcess:"
                            + processName);
                }
                synchronized (ActivityManagerService.this) {
                    // 继续调用
                    startProcessLocked(processName, info, knownToBeDead, 0 /* intentFlags */,
                            new HostingRecord(hostingType, hostingName, isTop),
                            ZYGOTE_POLICY_FLAG_LATENCY_SENSITIVE, false /* allowWhileBooting */,
                            false /* isolated */);
                }
            } finally {
                Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
            }
        }
        @GuardedBy("this")
        final ProcessRecord startProcessLocked(String processName,
                ApplicationInfo info, boolean knownToBeDead, int intentFlags,
                HostingRecord hostingRecord, int zygotePolicyFlags, boolean allowWhileBooting,
                boolean isolated) {
            return mProcessList.startProcessLocked(processName, info, knownToBeDead, intentFlags,
                    hostingRecord, zygotePolicyFlags, allowWhileBooting, isolated, 0 /* isolatedUid */,
                    false /* isSdkSandbox */, 0 /* sdkSandboxClientAppUid */,
                    null /* sdkSandboxClientAppPackage */,
                    null /* ABI override */, null /* entryPoint */,
                    null /* entryPointArgs */, null /* crashHandler */);
        }

流程走到 ProcessList::startProcessLocked 。

# ProcessList
    boolean startProcessLocked(......) {
                ......
                mService.mProcStartHandler.post(() -> handleProcessStart(
                    app, entryPoint, gids, runtimeFlags, zygotePolicyFlags, mountExternal,
                    requiredAbi, instructionSet, invokeWith, startSeq));     
                ......   
        }
        private void handleProcessStart(......) {
            创建一个用于启动进程的 Runnable 对象
            final Runnable startRunnable = () -> {
                try {    // 调用 startProcess 方法启动进程,并获取启动结果 ProcessStartResult
                        final Process.ProcessStartResult startResult = startProcess(app.getHostingRecord(),
                            entryPoint, app, app.getStartUid(), gids, runtimeFlags, zygotePolicyFlags,
                            mountExternal, app.getSeInfo(), requiredAbi, instructionSet, invokeWith,
                            app.getStartTime());
                         // 在锁定 ActivityManagerService 后,处理进程启动结果
                        synchronized (mService) {
                            // 更新应用的状态,如设置PID,更新生命周期状态等
                            handleProcessStartedLocked(app, startResult, startSeq);
                        }
                } catch (RuntimeException e) {
                    ......异常处理
                }
            };
            ......
        }
    
    1. 通过 ProcessList::startProcess 来启动应用进程
    1. 启动玩之后 ProcessList::handleProcessStartedLocked 会更新应用的状态,如设置PID,更新生命周期状态等

ProcessList::handleProcessStartedLocked 经过几次重载会调用下面的方法

# ProcessList
    ActivityManagerService mService = null;

    boolean handleProcessStartedLocked(ProcessRecord app, int pid, boolean usingWrapper,
                long expectedStartSeq, boolean procAttached) {
                ......
                StringBuilder buf = mStringBuilder;
                buf.append("Start proc ");
                buf.append(pid);
                buf.append(':');
                buf.append(app.processName);
                buf.append('/');
                UserHandle.formatUid(buf, app.getStartUid());
                if (app.getIsolatedEntryPoint() != null) {
                    buf.append(" [");
                    buf.append(app.getIsolatedEntryPoint());
                    buf.append("]");
                }
                buf.append(" for ");
                buf.append(app.getHostingRecord().getType());
                if (app.getHostingRecord().getName() != null) {
                    buf.append(" ");
                    buf.append(app.getHostingRecord().getName());
                }
                // 输出日志
                mService.reportUidInfoMessageLocked(TAG, buf.toString(), app.getStartUid());
                ......
        }

1.1创建进程小结

创建进行逻辑我没深入了解过,所以简单看了下调用逻辑,以 AMS::reportUidInfoMessageLocked 结束的原因是因为其会打印下面的这个创建进程的关键日志:

07-26 19:19:05.477  8737  8782 I ActivityManager: Start proc 19643:com.example.myapplication/u0a198 for next-top-activity {com.example.myapplication/com.example.myapplication.MainActivity}

经常看日志看启动了哪个进程搜的日志就是在这里打印的。

这部分的调用链如下:

ActivityTaskManagerService::startProcessAsync
    ActivityManagerService$LocalService::startProcess
        ActivityManagerService::startProcessLocked
            ProcessList::startProcessLocked
                ProcessList::handleProcessStart
                    ProcessList::startProcess                               -- 启动进程
                    ProcessList::handleProcessStartedLocked
                        ActivityManagerService::reportUidInfoMessageLocked  -- 打印日志

2. 阶段三–应用进程创建

进程创建完成后会执行 ActivityThread::main 方法,所以应用端进程创建结束的逻辑从这个方法开始分析。

2.1 应用端处理

# ActivityThread

    // ApplicationThread 是 AMS 作为 C 端时,与应用进程通信的方式
    final ApplicationThread mAppThread = new ApplicationThread();

    public static void main(String[] args) {
        ......
        // 主线程Looper
        Looper.prepareMainLooper();
        ......
        ActivityThread thread = new ActivityThread();
        // 下一步
        thread.attach(false, startSeq);
        // 主线程Looper
         Looper.loop();
    }
    private void attach(boolean system, long startSeq) {
        ......
            final IActivityManager mgr = ActivityManager.getService();
            try {
                //重点 *2. 将mAppThread告知AMS,用于AMS与应用进程通信
                mgr.attachApplication(mAppThread, startSeq);
            } catch (RemoteException ex) {
                throw ex.rethrowFromSystemServer();
            }
        ......
    }

应用端的调用链比较简单:

ActivityThread::main
    Looper::prepareMainLooper
    ActivityThread::init
    ActivityThread::attach
        ActivityManagerService::attachApplication  -- 跨进程
    Looper::loop

应用进程(电话)创建完毕后,在 main 方法里会执行 attach 就是要将自己的信息告知AMS,毕竟 AMS 是管理模块。

2.2 system_service端处理

system_service 端 ActivityManagerService 知道有进程启动了,这个行为也可能会触发系统组显示逻辑的改变,所以比如也会做响应处理

2.1 调用链

ActivityManagerService::attachApplication
    ActivityManagerService::attachApplicationLocked
        ActivityThread::bindApplication
            ActivityTaskManagerService.LocalService::attachApplication  
                WindowContainer::forAllRootTasks  --- 省略forAllRootTasks等固定堆栈
                    Task::forAllRootTasks
                        WindowContainer::forAllActivities
                            ActivityRecord::forAllActivities
                                RootWindowContainer.AttachApplicationHelper::test
                                    RootWindowContainer.AttachApplicationHelper::test
                                        ActivityTaskSupervisor::realStartActivityLocked  -- 构建LaunchActivityItem

在这里插入图片描述
接上一篇知道如果进程启动了 ActivityTaskSupervisor::startSpecificActivity 就会走进去ActivityTaskSupervisor::realStartActivityLocked 。
但是可能会好奇怎么就知道要执行应用 MainActivity 到 onCreate 就一定是在这个方法里呢? 调试方法有很多,比如加 log ,打堆栈,但是对应这个逻辑比较简单的是,需要执行 Activity 启动到 onCreate 的控制在 LaunchActivityItem 中,而 LaunchActivityItem在 framework 的引用除了本身,就只有在 ActivityTaskSupervisor。

在这里插入图片描述

2.2 主流程

# ActivityManagerService

    // 当应用进程调用attachApplication 执行
    public final void attachApplication(IApplicationThread thread, long startSeq) {
        if (thread == null) {
            throw new SecurityException("Invalid application interface");
        }
        synchronized (this) {
            // 获取 应用进程的信息后执行attachApplicationLocked
            int callingPid = Binder.getCallingPid();
            final int callingUid = Binder.getCallingUid();
            final long origId = Binder.clearCallingIdentity();
            // 执行
            attachApplicationLocked(thread, callingPid, callingUid, startSeq);
            Binder.restoreCallingIdentity(origId);
        }
    }

    private boolean attachApplicationLocked(@NonNull IApplicationThread thread,
            int pid, int callingUid, long startSeq) {
            // 需要启动应用的进程数据
            ProcessRecord app;
            ......
            if (pid != MY_PID && pid >= 0) {
                synchronized (mPidsSelfLocked) {
                    // 通过mPidsSelfLocked获取
                    app = mPidsSelfLocked.get(pid);
                }
                ......
            } 
            ...... 
            // 触发ActivityThread::bindApplication 逻辑
            if (app.getIsolatedEntryPoint() != null) {
                ......
            } else if (instr2 != null) {
                // bindApplication
                ......    
            } else {
                // 重点* 1. bindApplication
                thread.bindApplication(processName, appInfo,
                        app.sdkSandboxClientAppVolumeUuid, app.sdkSandboxClientAppPackage,
                        providerList, null, profilerInfo, null, null, null, testMode,
                        mBinderTransactionTrackingEnabled, enableTrackAllocation,
                        isRestrictedBackupMode || !normalMode, app.isPersistent(),
                        new Configuration(app.getWindowProcessController().getConfiguration()),
                        app.getCompat(), getCommonServicesLocked(app.isolated),
                        mCoreSettingsObserver.getCoreSettingsLocked(),
                        buildSerial, autofillOptions, contentCaptureOptions,
                        app.getDisabledCompatChanges(), serializedSystemFontMap,
                        app.getStartElapsedTime(), app.getStartUptime());
            }
            ......
            if (!mConstants.mEnableWaitForFinishAttachApplication) {
                // 重点* 2. 
                finishAttachApplicationInner(startSeq, callingUid, pid);
            } else {
                  app.setPendingFinishAttach(true);
            }
            ......
    }

ActivityManagerService::finishAttachApplicationInner 是 U 把原来的逻辑提取新增的方法。

# ActivityManagerService

        public ActivityTaskManagerInternal mAtmInternal;

        private void finishAttachApplicationInner(long startSeq, int uid, int pid) {
            ......
            if (normalMode) {
                try {
                    // 重点 触发构建 LaunchActivityItem 流程
                    didSomething = mAtmInternal.attachApplication(app.getWindowProcessController());
                } catch (Exception e) {
                    Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
                    badApp = true;
                }
            }
            ......
        }

这里是触发 LaunchActivityItem 的流程主线, mAtmInternal是 ATMS 的内部类 LocalService 。

# ActivityTaskManagerService$LocalService

        @Override
        public boolean attachApplication(WindowProcessController wpc) throws RemoteException {
            ......
            return mRootWindowContainer.attachApplication(wpc);
            ......
        }

流程来到 RootWindowContainer 预感要开始处理窗口显示逻辑。

# RootWindowContainer
        private final AttachApplicationHelper mAttachApplicationHelper = new AttachApplicationHelper();

        boolean attachApplication(WindowProcessController app) throws RemoteException {
            try {
                return mAttachApplicationHelper.process(app);
            } finally {
                mAttachApplicationHelper.reset();
            }
        }

# RootWindowContainer
    // 实现 Consumer 接口
    private class AttachApplicationHelper implements Consumer<Task>, Predicate<ActivityRecord> {
        ......
        boolean process(WindowProcessController app) throws RemoteException {
            mApp = app;
            for (int displayNdx = getChildCount() - 1; displayNdx >= 0; --displayNdx) {
                // 重点* 调用每个容器的 forAllRootTasks
                getChildAt(displayNdx).forAllRootTasks(this);
                ......
            }
            ......
        }
        ......
    }

这里看到传递了“this”,所以 AttachApplicationHelper 必然实现了 Consumer 接口, 直接看其 accept 实现即可。

# RootWindowContainer$AttachApplicationHelper

  private class AttachApplicationHelper implements Consumer<Task>, Predicate<ActivityRecord> {
        ......
        boolean process(WindowProcessController app) throws RemoteException {
            mApp = app;
            for (int displayNdx = getChildCount() - 1; displayNdx >= 0; --displayNdx) {
                // 重点*1. 调用每个容器的 forAllRootTasks
                getChildAt(displayNdx).forAllRootTasks(this);
                ......
            }
            ......
        }
        @Override
        public void accept(Task rootTask) {
            ......
            if (rootTask.getVisibility(null /* starting */)
                    == TASK_FRAGMENT_VISIBILITY_INVISIBLE) {
                // 如果Task 不可见则不需要处理
                return;
            }
            // 执行 topRunningActivity
            mTop = rootTask.topRunningActivity();
            // 重点*2. 执行accept 让容器下的每个 ActivityRecord 执行 test
            rootTask.forAllActivities(this);
        }
        @Override
        public boolean test(ActivityRecord r) {
            // 判断 ActivityRecord 是否满足需要启动条件
            if (r.finishing || !r.showToCurrentUser() || !r.visibleIgnoringKeyguard
                    || r.app != null || mApp.mUid != r.info.applicationInfo.uid
                    || !mApp.mName.equals(r.processName)) {
                return false;
            }
            try {
                // 重点*3. 执行 realStartActivityLocked  尝试实际启动 Activity
                if (mTaskSupervisor.realStartActivityLocked(r, mApp,
                        mTop == r && r.getTask().canBeResumed(r) /* andResume */,
                        true /* checkConfig */)) {
                    mHasActivityStarted = true;
                }
            } catch (RemoteException e) {
                ......
            }
            return false;
        }
  }

这部分的逻辑也就是一路执行,比较疑惑的点也许是进入 AttachApplicationHelper::proces 方法后的几个 Lambda 表达式容易绕晕。
简单梳理一下,首先是从 RootWindowContainer 开始执行的,目的就是想要执行到所有 ActivityRecord 然后判断一下它的情况是不是需要启动对应的 Activity 。

    1. AttachApplicationHelper::proces 里的 “getChildAt” 对应的是每个屏幕,也就是 DisplayContent ,然后再遍历其下的每个 RootTask ,让其执行 accept 函数
    1. AttachApplicationHelper::accept 目前是对象是 Task ,准确的说是 RootTask 。如果这个 Task 是可见的,则又开始遍历其下的所有 ActivityRecord ,让其执行 test 函数
    1. AttachApplicationHelper::test 方法是真正干活的地方,所有一堆条件判断这个 ActivityRecord 是否满足
    • r.finishing:活动是否正在结束
    • !r.showToCurrentUser() :活动是否对当前用户可见
    • !r.visibleIgnoringKeyguard :活动是否可见,即使有屏幕保护器
    • r.app != null :活动的应用程序是否已经存在
    • mApp.mUid != r.info.applicationInfo.uid :应用程序的UID是否与预期的不同
    • !mApp.mName.equals(r.processName):应用程序的名称是否与活动的进程名称不同
      感觉比较重要的就是前面3个条件,这个 ActivityRecord 是不是需要显示给用户,如果需要则执行 ActivityTaskSupervisor::realStartActivityLocked 试图启动 Activity 。

3. 阶段三总结

阶段三的流程相对来逻辑简单一些,知道个调用链就好,流程目的就是执行 ActivityTaskSupervisor::realStartActivityLocked 。

这部分的堆栈如下图:

在这里插入图片描述

加上应用端的调用链,完成调用链如下:

ActivityThread::main
    Looper::prepareMainLooper
    ActivityThread::init
    ActivityThread::attach
        ActivityManagerService::attachApplication  -- 跨进程
            ActivityManagerService::attachApplicationLocked
                ActivityThread::bindApplication
                ActivityManagerService::finishAttachApplicationInner
                    ActivityTaskManagerService$LocalService::attachApplication
                        RootWindowContainer::attachApplication
                            RootWindowContainer$AttachApplicationHelper::process -- 开始遍历
                                WindowContainer::forAllRootTasks  --- 省略forAllRootTasks等固定堆栈
                                    Task::forAllRootTasks  -- 1. 遍历所有root Task
                                        RootWindowContainer$AttachApplicationHelper::accept  -- 1.1 root Task执行accept
                                            WindowContainer::forAllActivities  -- 2. 遍历下面的所有ActivityRecord
                                                ActivityRecord::forAllActivities 
                                                    RootWindowContainer$AttachApplicationHelper::test  -- 2.1 ActivityRecord执行test
                                                        ActivityTaskSupervisor::realStartActivityLocked  -- 试图启动Activity
    Looper::loop

对应时序图:

在这里插入图片描述
大概流程图如下:

在这里插入图片描述
这一阶段主要就是应用进程启动后,试图拉起对应的 Activity ,能不能启动的条件就是没有正在 pause 的 Activity 了。
主要逻辑就是触发 ActivityTaskSupervisor::realStartActivityLocked

4. 阶段四–真正启动Activity

阶段四其实就是触发应用端创建 Activity 。

4.1 realStartActivityLocked

这个方法是要真去触发 Activity 启动的,根据前面的流程图,阶段二,三的最终就是想执行到这个方法里面,来触发 Activity 启动。

这个方法的最终目的就是通过事务执行 LaunchActivityItem 和 PauseActivityItem ,也就是会触发应用端 TargetActivity 启动,并执行生命周期到 onCreate 和 onResume 。

# ActivityTaskSupervisor 

    boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc,
            boolean andResume, boolean checkConfig) throws RemoteException {
            //  重点* 1. 判断是否执行完了pause 
            if (!mRootWindowContainer.allPausedActivitiesComplete()) {
                // While there are activities pausing we skipping starting any new activities until
                // pauses are complete. NOTE: that we also do this for activities that are starting in
                // the paused state because they will first be resumed then paused on the client side.
                // 如果还有Activity没完成pause,则打印日志并return
                ProtoLog.v(WM_DEBUG_STATES,
                        "realStartActivityLocked: Skipping start of r=%s some activities pausing...",
                        r);
                return false;
            }
            // 重点* 2. 表示ActivityRecord已连接到相应的进程
            r.setProcess(proc);
            ......
            // event日志: wm_restart_activity 
            EventLogTags.writeWmRestartActivity(r.mUserId, System.identityHashCode(r),
                        task.mTaskId, r.shortComponentName);
            ......
                // 重点* 3.1 创建事务,用于Activity启动
                // Create activity launch transaction.
                final ClientTransaction clientTransaction = ClientTransaction.obtain(
                        proc.getThread(), r.token);
                final boolean isTransitionForward = r.isTransitionForward();

                // 获取Activity所在 TaskFragment Token
                final IBinder fragmentToken = r.getTaskFragment().getFragmentToken();
                // 重点* 3.2 将构建的 LaunchActivityItem 添加到 clientTransaction 中
                clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
                        System.identityHashCode(r), r.info,
                        // TODO: Have this take the merged configuration instead of separate global
                        // and override configs.
                        mergedConfiguration.getGlobalConfiguration(),
                        mergedConfiguration.getOverrideConfiguration(), r.compat,
                        r.getFilteredReferrer(r.launchedFromPackage), task.voiceInteractor,
                        proc.getReportedProcState(), r.getSavedState(), r.getPersistentSavedState(),
                        results, newIntents, r.takeOptions(), isTransitionForward,
                        proc.createProfilerInfoIfNeeded(), r.assistToken, activityClientController,
                        r.shareableActivityToken, r.getLaunchedFromBubble(), fragmentToken));

                // 重点* 3.3 设置预期的最终状态为 ResumeActivityItem
                final ActivityLifecycleItem lifecycleItem;
                if (andResume) {
                    // Resume逻辑,启动走的这。 表示需要执行到onCreate
                    lifecycleItem = ResumeActivityItem.obtain(isTransitionForward);
                } else {
                    //  Pause 逻辑
                    lifecycleItem = PauseActivityItem.obtain();
                }
                clientTransaction.setLifecycleStateRequest(lifecycleItem);
                // 重点* 3.4 执行事务
                mService.getLifecycleManager().scheduleTransaction(clientTransaction);
                ......
    }

根据代码的标注解释:

    1. 根据注释,如果有 Activity 正在 pause 则不允许任何 Activity 启动。换句话说就是想要启动一个 Activity 必须其他的 Activity 需要 pause 的都完成了 pause 流程
    1. 对应上一篇提到的 ActivityRecord::attachedToProcess 方法如果需要返回 true ,则必须在这里执行 setProcess 方法,否则 ActivityRecord 下的 app 变量就是 null
    1. 这里就是开始真正执行启动 Activity 的地方了,是通过事务执行的,分为以下几步
    • 3.1 构建一个事务
    • 3.2 设置 LaunchActivityItem ,这一步会将 Activity 的生命周期执行到 onCreate
    • 3.3 设置 ResumeActivityItem ,这一步会将 Activity 的生命周期执行到 onResume
    • 3.4 执行事务

后续逻辑就是在应用端执行 Activity 的创建,以及生命周期处理了,这部分本篇大概看一遍流程,以分析到 Activity 的创建为止。

4.2 创建Activity

这部分的调用链如下:

LaunchActivityItem::execute
    ActivityThread::handleLaunchActivity
        ActivityThread::performLaunchActivity
            Instrumentation::newActivity -- 创建Activity
            Activity::attach  -- 处理Window相关
                Window::init
                Window::setWindowManager
            Instrumentation::callActivityOnCreate -- onCreate流程
                Activity::performCreate
                    Activity::onCreate  --over

时序图图下:

在这里插入图片描述

接下来看 LaunchActivityItem::execute

# LaunchActivityItem 
    public void execute(ClientTransactionHandler client, IBinder token,
            PendingTransactionActions pendingActions) {
        Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
        ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
                mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
                mPendingResults, mPendingNewIntents, mActivityOptions, mIsForward, mProfilerInfo,
                client, mAssistToken, mShareableActivityToken, mLaunchedFromBubble,
                mTaskFragmentToken);
        client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
        Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
    }

这里的 client 是 ClientTransactionHandler 类型, 而 ActivityThread 是 ClientTransactionHandler 子类。

重点是这边创建了 ActivityClientRecord ,第一个参数就是我们要找的token

逻辑来到应用进程 ActivityThread

# ActivityThread

    public Activity handleLaunchActivity(ActivityClientRecord r,
                PendingTransactionActions pendingActions, Intent customIntent) {
                    ......
                    
                    final Activity a = performLaunchActivity(r, customIntent);
                    ......
                }

    private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
        ......
                Activity activity = null;
                try {
                    // 重点* 1. 通过Instrumentation 反射创建Activity
                    java.lang.ClassLoader cl = appContext.getClassLoader();
                    activity = mInstrumentation.newActivity(
                            cl, component.getClassName(), r.intent);
                    ......
                }
                try {
                    ......
                    // 重点* 2. 执行 attach 流程
                    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, r.activityConfigCallback,
                            r.assistToken, r.shareableActivityToken);
                    ......
                    if (r.isPersistable()) {
                        mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
                    } else {
                        重点* 3. onCreate流程
                        mInstrumentation.callActivityOnCreate(activity, r.state);
                    }
                }
        ......
    }

这里有3个重点:

    1. Activity 是通过反射创建的。 到这里其实 Activity 启动流程基本分析完了
    1. 执行 Activity::attach 。这里会触发创建 Window
    1. 触发 Activity::onCreate

Activity 已经创建好了,那就剩下 onCreate 了。

# Instrumentation
    public void callActivityOnCreate(Activity activity, Bundle icicle) {
        prePerformCreate(activity);
        // onCreate流程
        activity.performCreate(icicle);
        postPerformCreate(activity);
    }

# Activity
    final void performCreate(Bundle icicle) {
        performCreate(icicle, null);
    }

    final void performCreate(Bundle icicle, PersistableBundle persistentState) {
        ......
        if (persistentState != null) {
            onCreate(icicle, persistentState);
        } else {
            // 执行onCreate
            onCreate(icicle);
        }
        ......
    }

写过应用的都知道,默认都是一个参数的onCreate。

至此,Activity 启动流程分析完毕。

在 ActivityTaskSupervisor::realStartActivityLocked 方法看到给事务加了个 ResumeActivityItem , 因为 LaunchActivityItem 只是创建,但是创建完成后,需要执行到对应的生命周期。

正常情况都是希望执行到onResume,所以会设置 ResumeActivityItem 。

4.3 阶段四小结

在这里插入图片描述
无论是阶段二还是阶段三触发了 ActivityTaskSupervisor::realStartActivityLocked 方法,并且还满足启动 Activity 条件,则会触发应用端进程 Activity 的创建和生命周期的执行。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mfbz.cn/a/886542.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

鸿蒙harmonyos next纯flutter开发环境搭建

公司app是用纯flutter开发的&#xff0c;目前支持android和iOS&#xff0c;后续估计也会支持鸿蒙harmonyos。目前谷歌flutter并没有支持咱们国产手机操作系统鸿蒙harmonyos&#xff0c;于是乎国内有个叫OpenHarmony-SIG的组织&#xff0c;去做了鸿蒙harmonyos适配flutter开发的…

安卓主板_MTK4G/5G音视频记录仪整机及方案定制

音视频记录仪方案&#xff0c;采用联发科MT6877平台八核2* A78 6* A55主频高达2.4GHz, 具有高能低耗特性&#xff0c;搭载Android 12.0智能操作系统&#xff0c;可选4GB32GB/6GB128GB内存&#xff0c;运行流畅。主板集成NFC、双摄像头、防抖以及多种无线数据连接&#xff0c;支…

【web安全】——sql注入

1.MySQL基础 1.1information_schema数据库详解 简介&#xff1a; 在mysql5版本以后&#xff0c;为了方便管理&#xff0c;默认定义了information_schema数据库&#xff0c;用来存储数据库元数据信息。schemata(数据库名)、tables(表名tableschema)、columns(列名或字段名)。…

java设计模式介绍

常见的设计模式有哪些呢&#xff1f; 单例模式&#xff08;Singleton Pattern&#xff09;&#xff1a; 就像是武林中的“独孤求败”&#xff0c;一个类只有一个实例&#xff0c;并提供一个全局访问点。 常用于需要控制资源访问的场景&#xff0c;比如数据库连接池。 工厂模式…

828华为云征文|部署音乐流媒体服务器 mStream

828华为云征文&#xff5c;部署音乐流媒体服务器 mStream 一、Flexus云服务器X实例介绍二、Flexus云服务器X实例配置2.1 重置密码2.2 服务器连接2.3 安全组配置2.4 Docker 环境搭建 三、Flexus云服务器X实例部署 mStream3.1 mStream 介绍3.2 mStream 部署3.3 mStream 使用 四、…

51c自动驾驶~合集1

我自己的原文哦~ https://blog.51cto.com/whaosoft/11466109 #HTCL 超过所有视觉方案&#xff01;HTCL&#xff1a;分层时间上下文问鼎OCC 本文是对ECCV2024接受的文章 HTCL: 的介绍&#xff0c;HTCL在SemanticKITTI基准测试中超过了所有基于相机的方法&#xff0c;甚至在和…

java中创建不可变集合

一.应用场景 二.创建不可变集合的书写格式&#xff08;List&#xff0c;Set&#xff0c;Map) List集合 package com.njau.d9_immutable;import java.util.Iterator; import java.util.List;/*** 创建不可变集合:List.of()方法* "张三","李四","王五…

每日OJ题_牛客_游游的水果大礼包_枚举_C++_Java

目录 牛客_游游的水果大礼包 题目解析 C代码 Java代码 牛客_游游的水果大礼包 游游的水果大礼包 (nowcoder.com) 描述&#xff1a; 游游有n个苹果&#xff0c;m个桃子。她可以把2个苹果和1个桃子组成价值a元的一号水果大礼包&#xff0c;也可以把1个苹果和2个桃子…

拆解维修飞科剃须刀

原因 用了好几年的剃须刀&#xff0c;经过一次更换电池。后来上面的盖帽松动&#xff0c;无法合盖&#xff0c;经过把弹片矫正后修复。最近一次”大力出奇迹“的操作直接断送了这个老伤员最后的可能性。最终只能花了将近十块大洋买了一套盖着和中间座。简单更换了一下。 记录…

Unity NetCode 客户端连接不上服务器,局域网模式 Failed to connect to server.

报错代码: Failed to connect to server. 报错截图&#xff1a; 解决办法: 服务端:绑定127.0.0.1和端口 客户端:写好对应服务端ip和端口 如何查看服务端所在局域网IP&#xff0c;192.xxx.xxx.xx,就不用教了吧。 注意这个钩&#xff0c;得点下&#xff0c;默认不勾选。 意…

【注册/登录安全分析报告:孔夫子旧书网】

前言 由于网站注册入口容易被黑客攻击&#xff0c;存在如下安全问题&#xff1a; 暴力破解密码&#xff0c;造成用户信息泄露短信盗刷的安全问题&#xff0c;影响业务及导致用户投诉带来经济损失&#xff0c;尤其是后付费客户&#xff0c;风险巨大&#xff0c;造成亏损无底洞…

docker运行arm64架构的镜像、不同平台镜像构建

背景 Docker 允许开发者将应用及其依赖打包成一个轻量级、可移植的容器&#xff0c;实现“一次构建&#xff0c;到处运行”的目标。然而&#xff0c;不同的操作系统和硬件架构对容器镜像有不同的要求。例如&#xff0c;Linux 和 Windows 系统有不同的文件系统和系统调用&#…

【Xcode Command Line Tools】安装指南

安装指令 xcode-select --install安装 完成安装 验证 $ xcode-select -p /Library/Developer/CommandLineTools

OpenCV-图像拼接

文章目录 一、基本原理二、步骤三、代码实现1.定义函数2.读取图像3.图像配准&#xff08;1&#xff09;.特征点检测&#xff08;2&#xff09;.特征匹配 4.透视变换5.图像拼接 四、图像拼接的注意事项 图像拼接是一种将多张有重叠部分的图像合并成一张无缝的全景图或高分辨率图…

Ascend C算子加速:优化与创新

Ascend C算子加速&#xff1a;优化与创新 随着大模型的迅速发展和人工智能计算需求的剧增&#xff0c;优化硬件性能变得尤为重要。针对这一需求&#xff0c;昇腾推出了Ascend Operator Library&#xff08;AOL&#xff09;算子加速库&#xff0c;专注于为开发者提供高效的算子…

C++ | 定长内存池 | 对象池

文章目录 C | 定长内存池 | 对象池一、内存池的引入二、代码中的内存池实现 - ObjectPool类&#xff08;一&#xff09;整体结构&#xff08;二&#xff09;内存分配 - New函数&#xff08;三&#xff09;内存回收 - Delete函数 三、内存池在TreeNode示例中的性能测试演示四、脱…

数据结构编程实践20讲(Python版)—03栈

本文目录 03 栈 StackS1 说明S2 示例基于列表的实现基于链表的实现 S3 问题&#xff1a;复杂嵌套结构的括号匹配问题求解思路Python3程序 S4 问题&#xff1a;基于栈的阶乘计算VS递归实现求解思路Python3程序 S5 问题&#xff1a;逆波兰表示法(后缀表达式)求值求解思路Python3程…

进度条(倒计时)Linux

\r回车(回到当前行开头) \n换行 行缓冲区概念 什么现象&#xff1f; 什么现象&#xff1f;&#xff1f; 什么现象&#xff1f;&#xff1f;&#xff1f; 自己总结&#xff1a; #pragma once 防止头文件被重复包含 倒计时 在main.c中&#xff0c;windows.h是不可以用的&…

【数据结构】什么是平衡二叉搜索树(AVL Tree)?

&#x1f984;个人主页:修修修也 &#x1f38f;所属专栏:数据结构 ⚙️操作环境:Visual Studio 2022 目录 &#x1f4cc;AVL树的概念 &#x1f4cc;AVL树的操作 &#x1f38f;AVL树的插入操作 ↩️右单旋 ↩️↪️右左双旋 ↪️↩️左右双旋 ↪️左单旋 &#x1f38f;AVL树的删…

C++ | Leetcode C++题解之第451题根据字符出现频率排序

题目&#xff1a; 题解&#xff1a; class Solution { public:string frequencySort(string s) {unordered_map<char, int> mp;int maxFreq 0;int length s.size();for (auto &ch : s) {maxFreq max(maxFreq, mp[ch]);}vector<string> buckets(maxFreq 1)…