# 3 Activity设计框架
### 3.1 外特性空间的Activity
我们先来看看,Android应用开发人员接触的外特性空间中的Activity,对于AMS来讲,这个Activity就是客服端的Activity。应用程序员在建立Android应用时,构建Activity的子类就是Andoid外特性空间展现的接口。我们可以从下面的简单的例子描述看看Activity,到底如何建立的。
~~~
DemoActivity extend Activity
{
onCreate
onResume
onPause
onStop
}
~~~
在Android的外特性空间(SDK)中,Android应用程序员根本不知道进程是什么时候起来的,系统消息是如何传递过来的。这个DemoActivity是如何实例化的呢?并且该Activity是托管在哪个进程的呢?本节的分析将给出答案。
我们从ActivityThread中可以看到在应用进程中的Activity都被放置在mActivities中。
[![image_thumb3](https://box.kancloud.cn/2016-05-05_572b1a25bf03b.gif "image_thumb3")](#)
这些ActivityRecord记录了应用进程中,程序员建立的Activity子类的实例,我们称之为外特性空间的Activity。这些Activity类实例是放在应用程序端进行实际交互的Activity,而为了管理这些Activity,AMS内核中还有一个影子Activity,被称为HistoryRecord。
3.2 Activity与HistoryRecord的关系
在整个系统中,Activity实际上有两个实体。一个在应用进程中跟应用程序员打交道的Activity,一个是在AMS的中具有管理功能的History Record。应用进程中的Activity都登记ActivityThread实例中的mActivity数组中,而在AM端,HistroytRecord实例放置在mHistroy栈中。mHistory栈是Android管理Activity的场所,放置在栈顶的就是User看到的处于活动状态的Activity。
Activity与HistrotyRecord的关系图可以表示如下:
[![image_thumb6](https://box.kancloud.cn/2016-05-05_572b1a25d3511.gif "image_thumb6")](#)
Activity的内核实体是依靠在ProcessRecord的成员变量中,通过ProcessRecord我们可以访问到所有的属于该Process的Activity。而在ProcessRecord记录了与应用进程之间的联系:IActivtityThread接口。通过该接口,可以访问到所对应的Activity的方法。在Launch Activity时,AMS将对应的HistoryRecord作为token传递到客服端和客服端的Activity建立联系。在AMS中Activity状态变化时,将通过该联系找到客服端的Activity,从而将消息或者动作传递应用程序面对的接口:xxxActivity。
### 3.3 Actvity的Launch过程
1)发起请求startActivity(intent)
2)Activity Service Manager接收到请求执行StartActivity函数。
建立:HistoryRecord实例r.
将r 加入到mHistory顶。
(3)通过app.thread.scheduleLaunchActvity( [app,r)@ActivityThread.java](#)
(4)在App应用中建立新的ActivityRecord。
(5)建立新的Activity对象并放入到ActivityRecord中。
(6)将ActivityRecord加入到mActivites@ActivityThread
(7)发起Activity.onCreate(..),,该onCreate就是在你的应用程序XXXActivity中的onCreate。
[![image_thumb10](https://box.kancloud.cn/2016-05-05_572b1a25edd5b.gif "image_thumb10")](#)
### 3.4 Activity的Resume
(1)Activity什么时候被Resume
[![image_thumb13](https://box.kancloud.cn/2016-05-05_572b1a2613625.gif "image_thumb13")](#)
(2)Rusume的过程
通过该过程的研究我们会进一步的了解到AMS与应用进程的交互过程。
在AMS端,满足resume条件都会调用:Resume的核心函数:[resumeTopActivityLocked@ActivityManagerService](#)
XXX当前栈顶的HistroyRecord
1)窗口切换:隐藏前一个Activity的窗口,
2)更新LRUList,(LRUList是淘汰应用程序的依据之一)
3) XXX.app.thread.scheduleResumeActivity(XXX,
isNextTransitionForward());
4)completeResumeLocked
setFocusedActivityLocked
mFocusActivity=xxx //此时焦点Actvitiy切换了。
WM.setFocusedApp(xxx,
mWindowManager.executeAppTransition();
mNoAnimActivities.clear();
在应用程序端:
(5)scheduleResumeActivity
handleResumeActivity(IBinder token, boolean clearHide, boolean isForward) {
ActivityRecord r = performResumeActivity(token, clearHide);
ActivityRecord r = mActivities.get(token);
r.activity.performResume()
performResume
整个Resume的过程如下:
[![image_thumb16](https://box.kancloud.cn/2016-05-05_572b1a262dd95.gif "image_thumb16")](#)
- 前言
- (一)分析方法论探讨之设计意图
- (二)方法论探讨之概念空间篇
- (三)手机之硬件形态
- (四)手机的软件形态
- (五)基本空间划分
- (六)IPC框架分析 Binder,Service,Service manager
- (七)Service深入分析
- (八)Android 启动过程详解
- (九)Zygote Service
- (十)Android GWES之基本原理篇
- (十一)Android GWES之消息系统
- (十二)Android GEWS窗口管理之基本架构原理
- (十三)Android GWES之Android窗口管理
- (十四)Android GWES之输入系统
- (十五)Android输入系统之输入路径详解
- (十六)Android电话系统-概述篇
- (十七)电话系统之rilD
- (十八)Android电话系统之RIL-Java
- (十九)电话系统之GSMCallTacker
- (二十)Android应用程序框架之无边界设计意图
- (二十一)Android应用框架之AndroidApplication
- (二十二)Android应用框架之Activity
- (二十三)Andoird GDI之基本原理及其总体框架
- (二十四)Android GDI之显示缓冲管理
- (二十五)Android GDI之共享缓冲区机制
- (二十六)Android GDI之SurfaceFlinger
- (二十七)Android GDI 之SurfaceFlinger之动态结构示意图
- (二十八)Android GDI之Surface&Canvas