小学做试题网站,苏州建网站多少钱,东莞网站建设在哪里,绵阳市建设网招标公告一个Android应用是如何被启动的 前言总结1. 启动Application1.1 拉起一个新的进程1.2 启动Application1.3 AMS阶段1.4 创建Instrumentation和Application 2. 启动Activity2.1 回到AMS#xff0c;启动第一个Activity 参考资料 前言
基于源码API 28#xff0c;30以后的版本启动… 一个Android应用是如何被启动的 前言总结1. 启动Application1.1 拉起一个新的进程1.2 启动Application1.3 AMS阶段1.4 创建Instrumentation和Application 2. 启动Activity2.1 回到AMS启动第一个Activity 参考资料 前言
基于源码API 2830以后的版本启动第一个Activity的逻辑不一样
我会只拿出我们需要关注的代码部分因为源码太多全都看看不过来的。所以每次截代码都有省略 前言 源码只截取需要看的部分其他部分会省略。
源码基于API 28也就是Android9.0也就是源码还有ActivityStackSupervisor的这个版本 其他版本代码不太一样没有ActivityStackSupervisor但是原理是相同的。
AOSP的源码在这个网站上看http://aospxref.com/
总结
用流程总结app启动
用户点击应用图标或者其他方式打开app要打开app的进程可能是桌面进程可能是别的Intent通知zygote进程fork出一个新的进程用于承载app。ActivityThread通过main方法启动通过跨进程通信通知SystemServer进程SystemServer的AMS去找PMS拿对应的进程信息。AMS将进程信息PackageInfo返还给应用进程ActivityThread创建Instrumentation和通过反射的方式创建ApplicationInstrumentation调用application的生命周期。
用流程总结第一个Activity启动
AMS遍历mPackages里面的Activity标签之后找到启动时所需要的那个Activity根据Intent里面的那个启动标签。准备一个事务clientTransaction里面包括了Activity的启动(Callback)和拉到前台(lifecycleState)两件事。
后面的流程参考上一篇文章的第六节我们只需要知道一旦往ActivityThread发了一个ClientTransaction之后后面的流程就完全是固定的。
AMSActivityManagerService源码解析Activity是如何被打开的 https://blog.csdn.net/qq_41872247/article/details/125031721
1. 启动Application
1.1 拉起一个新的进程
首先我们需要明确一点的是启动一个app他的起点来自于桌面进程桌面进程在用户点击app图标准备拉起app的时候就会让Zygote进程去即使的fork一个新的app进程出来然后寻找到这个新的app的ActivityThread类的Main方法进行执行。
这部分见https://blog.csdn.net/qq_41872247/article/details/125211491
1.2 启动Application
接下来我们就来到了ActivityThread的Main方法
public final class ActivityThread extends ClientTransactionHandlerimplements ActivityThreadInternal {private ApplicationThread mAppThread// 启动类public static void main(String[] args) {ActivityThread thread new ActivityThread();thread.attach(false, startSeq);}private void attach(boolean system, long startSeq) {if(!system) {final IActivityManager mgr ActivityManager.getService();try {mgr.attachApplication(mAppThread, startSeq);} catch (RemoteException ex) {throw ex.rethrowFromSystemServer();}}}private class ApplicationThread extend IApplicationThread.Stub {}
}到attach我们就通过跨进程进行binder通信了拿到了AMS对象。我们传的对象ApplicationThread就是ActivityThread的一个内部类持有外部引用这个类就是负责和AMS通信。
1.3 AMS阶段
public class ActivityManagerService extends IActivityManager.Stubimplements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {public final void attachApplication(IApplicationThread thread, long startSeq) {synchronized (this) {attachApplicationLocked(thread, callingPid, callingUid, startSeq);}}private boolean attachApplicationLocked(NonNull IApplicationThread thread,int pid, int callingUid, long startSeq) {ProcessRecord app;// 这段代码从PMS中请求App的数据if (app null startSeq 0) {final ProcessRecord pending mPendingStarts.get(startSeq);if (pending ! null pending.startUid callingUid pending.startSeq startSeq handleProcessStartedLocked(pending, pid, pending.usingWrapper,startSeq, true)) {app pending;}}if (app.isolatedEntryPoint ! null) {thread.runIsolatedEntryPoint(app.isolatedEntryPoint, app.isolatedEntryPointArgs);} else if (app.instr ! null) {// 走这里thread.bindApplication(processName, appInfo, providers,app.instr.mClass,profilerInfo, app.instr.mArguments,app.instr.mWatcher,app.instr.mUiAutomationConnection, testMode,mBinderTransactionTrackingEnabled, enableTrackAllocation,isRestrictedBackupMode || !normalMode, app.persistent,new Configuration(getGlobalConfiguration()), app.compat,getCommonServicesLocked(app.isolated),mCoreSettingsObserver.getCoreSettingsLocked(),buildSerial, isAutofillCompatEnabled);} else {thread.bindApplication(processName, appInfo, providers, null, profilerInfo,null, null, null, testMode,mBinderTransactionTrackingEnabled, enableTrackAllocation,isRestrictedBackupMode || !normalMode, app.persistent,new Configuration(getGlobalConfiguration()), app.compat,getCommonServicesLocked(app.isolated),mCoreSettingsObserver.getCoreSettingsLocked(),buildSerial, isAutofillCompatEnabled);}}
}AMS这部分先去PMS里面拿到当前app的相关数据之前写在AndroidManifest里面的解析后存在mPackages的内容 然后再返回来给ApplicationThread走到thread.bindApplication。
1.4 创建Instrumentation和Application
public final class ActivityThread extends ClientTransactionHandlerimplements ActivityThreadInternal {private class ApplicationThread extend IApplicationThread.Stub {public final void bindApplication(很多入参) {AppBindData data new AppBindData();// ....将App的数据都放进data里面sendMessage(H.BIND_APPLICATION, data);}}
}这里第一次sendMsg了就是handler的那套流程最后走到的是外侧的一个bindApplication方法
public final class ActivityThread extends ClientTransactionHandlerimplements ActivityThreadInternal {private static class AndroidOs extends ForwardingOs {private void handleBindApplication(AppBindData data) {// 一般都是走上面if (ii ! null) {initInstrumentation(ii, data, appContext);} else {mInstrumentation new Instrumentation();mInstrumentation.basicInit(this);}//.....省略无关代码Application app;try {// 创建appllicationapp data.info.makeApplicationInner(data.restrictedBackupMode, null);//......// Instrumentation自己的onCreate方法等于自己的生命周期忽视它mInstrumentation.onCreate(data.instrumentationArgs);//......mInstrumentation.callApplicationOnCreate(app);}}private void initInstrumentation(InstrumentationInfo ii, AppBindData data, ContextImpl appContext) {try {final ClassLoader cl instrContext.getClassLoader();mInstrumentation (Instrumentation)cl.loadClass(data.instrumentationName.getClassName()).newInstance();}//init只是把一大堆东西给他赋值到成员变量里面mInstrumentation.init(this, instrContext, appContext, component,data.instrumentationWatcher, data.instrumentationUiAutomationConnection);}}
}他在这段代码中做了几件事
创建Instrumentation对象创建Application对象调用Application的生命周期
Instrumentation的创建过程上面已经有了接下来看makeApplicationInner是如何创建Application的
public final class LoadedApk {private Application makeApplicationInner(boolean forceDefaultAppClass,Instrumentation instrumentation, boolean allowDuplicateInstances) {Application app null;app mActivityThread.mInstrumentation.newApplication(cl, appClass, appContext);return app;}
}public class Instrumentation {public Application newApplication(ClassLoader cl, String className, Context context)throws InstantiationException, IllegalAccessException, ClassNotFoundException {// getFactory我们具体就不看了最终就是返回一个AppComponentFactory的对象Application app getFactory(context.getPackageName()).instantiateApplication(cl, className);app.attach(context); //这个attach就是我们自己定义的Application类的生命周期的那个attach由Instrumentation直接调用return app;}
}public class AppComponentFactory {public NonNull Application instantiateApplication(NonNull ClassLoader cl,NonNull String className)throws InstantiationException, IllegalAccessException, ClassNotFoundException {// 走到最后还是反射创建的对象。return (Application) cl.loadClass(className).newInstance();}
}虽然中间跨了很多个类但是还是可以看得出来根本的那行代码还是反射创建Application对象。
最后看看Application的生命周期是如何被Instrumentation调用的
public class Instrumentation {public void callApplicationOnCreate(Application app) {app.onCreate();}
}结果就是直接调用没有任何转折。
2. 启动Activity
2.1 回到AMS启动第一个Activity
代码回到AMS刚刚AMS的代码还未执行完。
public class ActivityManagerService extends IActivityManager.Stubimplements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {private boolean attachApplicationLocked(NonNull IApplicationThread thread,int pid, int callingUid, long startSeq) {//.. bind之后发生的事// See if the top visible activity is waiting to run in this process...// 查看在这个进程中顶部的Activity是否正在等待运行... 其实就是启动顶部Activity了if (normalMode) {try {if (mStackSupervisor.attachApplicationLocked(app)) {didSomething true;}} catch (Exception e) {Slog.wtf(TAG, Exception thrown launching activities in app, e);badApp true;}}}
}public class ActivityStackSupervisor extends ConfigurationContainer implements DisplayListener,RecentTasks.Callbacks {boolean attachApplicationLocked(ProcessRecord app) throws RemoteException {final String processName app.processName;boolean didSomething false;for (int displayNdx mActivityDisplays.size() - 1; displayNdx 0; --displayNdx) {final ActivityDisplay display mActivityDisplays.valueAt(displayNdx);for (int stackNdx display.getChildCount() - 1; stackNdx 0; --stackNdx) {final ActivityStack stack display.getChildAt(stackNdx);if (!isFocusedStack(stack)) {continue;}stack.getAllRunningVisibleActivitiesLocked(mTmpActivityList);final ActivityRecord top stack.topRunningActivityLocked();final int size mTmpActivityList.size();for (int i 0; i size; i) {final ActivityRecord activity mTmpActivityList.get(i);if (activity.app null app.uid activity.info.applicationInfo.uid processName.equals(activity.processName)) {try {// 通过好几层的for循环遍历app里面所有的Activity去寻找并启动app的启动页if (realStartActivityLocked(activity, app,top activity /* andResume */, true /* checkConfig */)) {didSomething true;}} catch (RemoteException e) {throw e;}}}}}if (!didSomething) {ensureActivitiesVisibleLocked(null, 0, !PRESERVE_WINDOWS);}return didSomething;}final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,boolean andResume, boolean checkConfig) throws RemoteException {try {// 准备启动Activity的事务final ClientTransaction clientTransaction ClientTransaction.obtain(app.thread,r.appToken);// 这里准备了一个LaunchActivityItem作为Callback记住他后面会用到clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),System.identityHashCode(r), r.info,mergedConfiguration.getGlobalConfiguration(),mergedConfiguration.getOverrideConfiguration(), r.compat,r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,r.persistentState, results, newIntents, mService.isNextTransitionForward(),profilerInfo));final ActivityLifecycleItem lifecycleItem;if (andResume) {// 这里我们是启动Activity所以走resumelifecycleItem ResumeActivityItem.obtain(mService.isNextTransitionForward());} else {lifecycleItem PauseActivityItem.obtain();}// 这里准备了一个ResumeActivityItem作为LifecycleState记住他后面会用到clientTransaction.setLifecycleStateRequest(lifecycleItem);// 发送这个事务mService.getLifecycleManager().scheduleTransaction(clientTransaction);}}
}AMS遍历了一下启动进程的所有Activity找到启动时要用的那个走到了realStartActivityLocked准备启动。
后面的流程参考这篇文章的第六节是完全一样的 AMSActivityManagerService源码解析Activity是如何被打开的 https://blog.csdn.net/qq_41872247/article/details/125031721
参考资料
码牛学院VIP课程 VIP12-2021.12.03-這染机制-01 Activity. View. WMS的协调kerwin
AOSP的源码网站http://aospxref.com/
