1. ActivityThread:虽然名字是Thread,但是本身并不继承自任何一个Thread类,其Thread的功能是通过内部维护的handler(mH)实现的.

  2. ActivityThread的static main函数(入口):

    • 前面是一系列的初始化:
    • 重要的初始化: Looper.prepareMainLooper(),为当前线程配置一个Looper并放在Looper类的相应的ThreadLocal中. 为了能讲当前线程作为一个handlerThread使用.
    • new 一个 ActivityThread(thread)并接着调用attach(false);
    • sMainThreadHandler设为thread的getHandler()
    • 初始化AsyncTask类.
    • Looper.loop()开始工作,理论上将永远循环再次函数,如果此函数结束,会直接抛出一个RuntimeException(“Main thread loop unexpectedly exited”)
  3. 和static main相对的:(public static ActivityThread systemMain()):

    • new 一个 ActivityThread 并attach(true)然后返回.
    • 该函数会被ActivityManagerService和UserManagerService调用.
  4. H类: 每个ActivityThread对象都有一个H对象(mH):

    • H 类其实就是自定义的Handler类.
    • 自定了handleMessage(Message msg)函数,会根据不同的msg执行相应操作
    • 这些msg包含的操作包括:
      • 对某个Activity的操作(launch/stop/pause…)
      • 对某个Service的操作
      • 对Applocation的操作
      • 对provider的操作
      • show/hide window
    • mH所依附的线程就是创建它的线程.就是ActivityThread对应的线程.
  5. ApplicationThread类: 每一个ActivityThread都有一个ApplicationThread(mAppThread):

    • ApplicationThread extends ApplicationThreadNative
    • ApplicationThreadNative extends Binder implements IApplicationThread
    • IApplicationThread的注释(可以看到其实就是application给activity manager的一个RPC对象, activity manager的指令通过binder机制下达到此对象,此对象做相应操作):

    System private API for communicating with the application. This is given to the activity manager by an application when it starts up, for the activity manager to tell the application about things it needs to do.

  6. 里面有一堆的scheduleXXXActivity,就是对某个Activity对象做操作(stop/pause…, 会有一个IBinder token作为对Activity对象的标示),而ApplicationThread也没有更多操作,仅仅是简单的将此操作放在ActivityThread的操作队列mH中(queueOrSendMessage(…))
  7. scheduleLaunchActivity(…): 创建并运行一个Activity:
    • 会有一堆参数传递过来,包括:
      • intent(启动Activity的Intent)
      • curConfig(启动此Activity时的Configuration)
      • IBinder token(用来标示activity对象以及远端通讯用的binder)
      • ……….
    • 这些参数都会被封装在new出来的ActivityClientRecord中,除了curConfig外, 这个curConfig会作为ActivityThread的mPendingConfiguration.
    • 最后以H.LAUNCH_ACTIVITY作为msg结合new的ActivityClientRecord对象将这个task放在mH的执行队列中.
  8. handleLaunchActivity(ActivityClientRecord r, Intent customIntent):

    • 是在mH收到LAUNCH_ACTIVITY以后调用的函数, 在这种情况下,customIntent = null.
    • unscheduleGcIdler(), 取消之前schedule的GC任务.
    • handleConfigurationChanged(),确保mResoureManager apply了最近的Configuration
    • performLaunchActivity(r, customIntent)得到一个Activity对象.
    • 对应的ActivityClientRecord会保存当前的Configuration到自己的createdConfig.
    • 执行Actiivty的onResume(通过handleResumeActivity()方法)
    • 如果当前activity没有finish(!mFinished)并且ActivityClientRecord中的startsNotResumed,那么会进一步执行Activity的onPasue(mInstrumentation.callActivityOnPause(r.activity)).
  9. Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent):

    • 首先如果r的packageInfo没有,那么会通过getPackageInfo结合r的activityInfo/compatInfo来获取一个packageInfo.
    • 尝试获取r的intent的getComponent()(返回ComponentName), 如果没有,那么会调用r.intent的resolveActivity(mInitialApplication.getPackageManager())来获取一个component并给r.intent设置上. 如果发现r.activityInfo已经指定了targetActivity(这种情况是指Activity 是 alias,targetActivity才代表真正的Activity), 那么直接根据此targetActivity构造一个component即可.
    • 利用r.packageInfo.getClassLoader()得到classloader,然后调用Instrumentation的newActivity(classloader, component.getClassName(), r.intent)获得一个activity对象, 该classloader也会被保存在r的ExtrasClassLoader中以及r的state中.
    • r.packageInfo.makeApplication(false, mInstrumentation)得到一个Application对象app, 这里就是Application对象的创建了
    • 如果之前成功的得到了Activity:

      • 调用createBaseContextForActivity(r, activity)获得一个Context
      • 通过r.activityInfo.loadLabel(appContext.getPackageManager())获得Activity的title.
      • 以mCompatConfiguration作为config调用activity.attach(….), 传入了很多参数:

        activity.attach(appContext, this, getInstrumentation(), r.token,
        r.ident, app, r.intent, r.activityInfo, title, r.parent, r.embeddedID, r.lastNonConfigurationInstances, config)

      • 如果customIntent不是null, 会将activity的mIntent设为customIntent.

      • activity.mStartedActivity = false;
      • r.activityInfo.getThemeResource()得到theme, 如果不是0,会activity.setTheme(theme).
      • mInstrumentation.callActivityOnCreate(activity, r.state) 调到了Activity的onCreate回调.
      • r.activity = activity; r.stopped = true(代表此Activity目前还是stop的);
      • 如果actiivty没有finish(!mFinished),那么会activity.performStart(), 调用Activity的onStart()回调
      • 如果actiivty没有finish(!mFinished)并且r.state也不是null, 那么会通过Instrumentation的callActivityOnRestoreInstanceState(activity, r.state)来调用Activity的OnRestoreInstanceState(r.state),可见saveInstance的信息都在ActivityClientInfo的state中
      • 如果actiivty没有finish(!mFinished),mInstrumentation.callActivityOnPostCreate(activity, r.state)调用了Activity的onPostCreate(…)回调,这一步也会传递r.state
      • r.paused = true 代表Activity的当前状态是pasue.
      • mActivities.put(r.token, r),将创建的Activity对象放在ActivityThread对象的Activity列表中, 标示是r.token.
  10. handleResumeActivity(IBinder token, boolean clearHide, boolean isForward,
    boolean reallyResume):

    • 取消GC.
    • performResumeActivity(token, clearHide),该函数会在ActivityClientRecord(r)还有pendingIntents的情况下,deliverNewIntents(r, r.pendingIntents)(会进一步调到Activity的OnNewIntent).
    • deliverResults(r, r.pendingResults)会将r上的pendingResults传递给Activity ->dispatchActivityResult->onActivityResult
    • 调用Activity的performResume(), 并且 r.paused = false r.stopped = false r.state = null
    • 如果activity的window还没有add到window manager,而activity也没有结束自己或者start其他的activity, 那么就将activity的window加入到window manager中:
      • actiivty是否可见取决于activity的!mStartedActivity,如果发现不可见,那么会尝试进行ActivityManagerNative的willActivityBeVisible来判定该activity是否可见.
      • 如果r的window是null,并且!activity.mFinished以及activity是可见的:
        • 那么r的window会设置为activity的getWindow(),进一步获得window里的DecorView,并将此DecorView设置为不可见.
        • 获得activity的windowManager, 通过r.window.getAttributes()得到一个WindowManager.LayoutParams(l), Activity的mDecor会设置为Window的DecorView.
        • 如果activity对用户是可见的(a.mVisibleFromClient),那么将decorView加入到activity的windowManager(也是ViewManager)中,a.mWindowAdded = true.
        • window这时候已经可见了。如果发现r的newConfig可用,那么会调用performConfigurationChanged(r.activity, r.newConfig)来配置新的Configuration.
        • 还有可能调用到windowManager的updateViewLayout(decor, l).
        • 最后调用Activity的makeVisible()(会确保Activity的DecorView被添加进window,并且将DecorView设置为可见). 并且ActivityThread的mNumVisibleActivities也会++.
        • 最后告知ActivityManagerNative activity以及resume了.
  11. class ActivityInfo extends ComponentInfo implements Parcelable

    • 这个类的作用注释说的挺明白了:

    Information you can retrieve about a particular application activity or receiver. This corresponds to information collected from the AndroidManifest.xml’s activity; and receiver tags.

  12. 这个类封装了所有从AndroidManifest.xml中解析出来的关于Activity的信息.为了方便读取信息,直接定义了很多public变量成员来存储相关的信息。
  13. ActivityInfo也是在ApplicationThread的scheduleLaunchActivity时传进来的,即应该是activity manager来指定的
  14. 类似的还有ApplicationInfo/ServiceInfo/ProviderInfo/…
  15. handleWindowVisibility(IBinder token, boolean show):

    • 根据token就可以获得相应的ActivityClientRecord (r).
    • 如果是设为不可见(!show)并且Activity没有stop(!r.stopped),那么就会performStopActivityInner(r, null, show, false)将Activity stop.
    • 如果是可见而Activity是stop的,那么会r.activity.performRestart() r.stopped = false将Activity start.
    • 最后才回根据是否可见设置Activity的decorView.
  16. Bundle performPauseActivity(ActivityClientRecord r, boolean finished, boolean saveState):

    • 如果已经是paused(r.paused), 那么只有activity已经finished, 那么直接返回null,否则报错.
    • 如果已经是finished,那么会将activity的mFinished设为true.
    • 如果没有finish(!r.activity.mFinished)并且指定了需要saveState,那么会new一个Bundle, 会调用Instrumentation的callActivityOnSaveInstanceState(r.activity, state)进而回调到Activity的OnSaveInstanceState, 而保存信息的bundle则会被设给r的state(可以看到,Activity的state信息在其pasue之后是通过对应的ActivityClientRecord保存维持的)
    • 接下来就调用mInstrumentation.callActivityOnPause(r.activity)回调到Activity的onPause(…).
    • 然后将r的pasued设为true.
    • 下一步会处理注册在ActivityThread中的mOnPauseListeners(类型是OnActivityPausedListener),首先要将pause的Activity的Listener从mOnPauseListeners中remove,然后才会逐个调用listener的onPaused(r.activity).
    • 最后返回该Activity保存信息用的state bundle.
  17. performStopActivity(IBinder token, boolean saveState):

    • 通过token获得对应的ActivityClientRecord r, 然后调用performStopActivityInner(r, null, false, saveState)
    • performStopActivityInner的注释值得看看:

    对于server和client来说,stop的概念有些不同,对于server来说,stop意味着save当前state,并且在完成时返回结果,但是呢,window依然是可见的。对于client来说, onStop()/onStart()标示着activity UI可见性的改变.

  18. 一些关键点:
    • 只有在提供的StopInfo有效时才回进行关键操作.
    • 也是只有在activity没有finish**并且指定saveState时(performPause也有这个选项)才回进行saveInstanceState.不过只有在r的state是null时才回这么做,也就是说如果pause时已经save了,那么就不会有save操作**
    • 如果!KeepShown,那么就调用activity的performStop(),并将r的stoppped设为true.
    • 最后r的paused设为true.
  19. handleStopActivity(IBinder token, boolean show, int configChanges):

    • 获取对应的ActivityClientRecord r 立即执行performStopActivityInner.
    • 会根据show来设置Activity的可见性.
    • 还需要等待所有的pending writter都已经commit了.
    • 然后会post一个stopInfo(extends Runnable)到mH上,之所以不立即执行是为了让其他的peding work能有机会完成.
  20. class StopInfo implements Runnable:

    • run函数执行了ActivityManagerNative.getDefault().activityStopped(…)告知ActivityManager Activity已经stop.
  21. ActivityClientRecord performDestroyActivity(IBinder token, boolean finishing, int configChanges, boolean getNonConfigInstance):

    • 获得相应的ActivityClientRecord r.
    • 获取被destroy的Activity的 class.
    • 如果finishing, 那么activity的mFinsihed = true.
    • 如果!r.paused, 那么会mInstrumentation.callActivityOnPause(r.activity). r.paused = true.
    • 如果!r.stopped, 那么 r.activity.performStop(), r.stopped = true.
    • 上面两步等于是在Activity被destroy时将pause和stop执行一遍(如果不是的话)
    • mInstrumentation.callActivity**OnDestroy**(r.activity),并且将r对应的window进行closeAllPanels()
    • 最后将对应的token从mActivities remove, 引用消除.
    • 返回r.
  22. void handleDestroyActivity(IBinder token, boolean finishing, int configChanges, boolean getNonConfigInstance)

    • 一开始就调用了performDestroyActivity并得到了被destroy的Activity的ActivityClientRecord r.
    • cleanUpPendingRemoveWindows(r)将pending的removewindow直接remove.
    • 获得Activity的widowManager,并得到Activity的DecorView v.
    • 从widowManager中removeViewImmediate Activity的DecorView.
    • WindowManagerGlobal结合Activity的DecorView的WindowToken进行closeAll. 并将Activity的mDecor设为null.
    • 后面还有一次对Activity的getBaseContext()的scheduleFinalCleanup.
    • 如果确实是finishing,那么会告知对端ActivityManager Activity已经被destroy了, ActivityManagerNative.getDefault().activityDestroyed(token).
  23. Bitmap createThumbnailBitmap(ActivityClientRecord r):

    • 用来创建Activity stop时的截图(Thumbnail).
    • 如果之前没有申请过一个bitmap(mAvailThumbnailBitmap == null),那么这里会直接调用Bitmap.createBitmap来创建一块bitmap,并且eraseColor(0)填充整个bitmap为0这个颜色(应该是全透明).
    • 然后基于此bitmap创建一块canvas(对此Canvas的操作都会落到bitmap上),并调用activity的onCreateThumbnail(…)来获得合适的thumbnail.
    • 最后返回thumbnail.
  24. handleNewIntent(NewIntentData data)->performNewIntents(data.token, data.intents):

    • 根据data中的token获得相应的ActivityClientRecord r,然后如果r 不是paused, 那么会临时(mTemporaryPause=true)mInstrumentation.callActivityOnPause(r.activity),进行deliverNewIntents(…)
    • deliverNewIntents函数就是逐个遍历Intents,并且对相应Activity调用mInstrumentation.callActivityOnNewIntent(r.activity, intent)。
    • 然后会再将Activity resume(performResume() + TemporaryPause = false).
  25. createBaseContextForActivity(…)在launch Activity时会被调用,其作用就是new 一个 ContextImpl()(可见一个Activity有自己的contextImpl),并根据r.packageInfo, r.token对context进行init(init(r.packageInfo, r.token, this)), 并将context的OuterContext设置为Activity. 后面还有一个对于debug的特殊处理. 最后返回new的contextImpl并作为Activity的attach参数, 在此attach中,会通过ContextWrapper的attachBaseContext将mBase设为此new的ContextImpl,ContextWrapper如同其名一样,是一个wrapper用的是装饰模式,不过其本身实现基本都是对内部封装的mBase的直接转发.

  26. attach(boolean system):

    • system = true:
      • new 一个Instrumentation并赋给mInstrumentation
      • new 一个ContextImpl并且此ContextImpl会作为Instrumentation.newApplication的参数. 在该new出来时,会调用此contextImpl的init函数:(init(getSystemContext().mPackageInfo, null, this))
      • new 一个Application(通过Instrumentation的newApplication方法),并将此app加到ActivityThread的mAllApplications中(一个List).
      • 将之前的new的application作为mInitialApplication.
      • 待用application的onCreate()函数
    • system = false:

    • 对system的处理完毕以后,会为ViewRootImpl增加一个ConfigCallback:

      • Override onConfigurationChanged(Configuration newConfig):
        在Configuration变化时,会先lock mResourcesManager,mResourcesManager会apply newConfig, 如果确实发生了change, 那么如果mPendingConfiguration不存在或者newConfig比mPendingConfiguration better(参加Configuration的isOtherSeqNewer(…)函数),那么会queue一个 H.CONFIGURATION_CHANGED来告知 configuration的变化.

更多相关文章

  1. 箭头函数的基础使用
  2. 类和 Json对象
  3. Python技巧匿名函数、回调函数和高阶函数
  4. Android程序入口ActivityThread和Android应用程序启动流程详解
  5. 基于Android的Linux内核的电源管理
  6. 简单的Android(安卓)UI组件使用
  7. Android中SensorManager.getRotationMatrix函数原理解释
  8. Android(安卓)Handler机制
  9. 修改Android系统属性SystemProperties.set("sys.powerctl", "shu

随机推荐

  1. 《第一行代码--Android》读书笔记之网络
  2. Android(安卓)常用Intent封装
  3. Android(安卓)分享
  4. Android(安卓)3D与JNI结合的小例子
  5. android隐藏软键盘
  6. android studio在build过程中出现的错误
  7. android 按钮按下效果
  8. H5唤起APP
  9. ubuntu 64 位 开发 android 需要安装的 3
  10. Android的Looper的无限循环为啥不会ANR?