activity是android的一个基本的组件。讨论生命周期,taskstack等等的话题的时候。就不得不去看一下android framework层的源码了。

  生命周期,实际就是系统调用android代码的时候做的回调函数,复写之后,就会和android app运行为一体。简单的来说,和activity有关的类有很多。其中和生命周期有关的,就是管理activity的类。包括activityThread,activityManagerNative,activityManagerService 和activityStack:

  activityThread: 每一个java程序都有一个main函数,android也不例外。每一个app都是一个进程,这里既是一个app的起始点。gui的编程无非就是在循环中不断的读取消息,然后处理消息。这里的消息包括了各种系统定义的消息,还有ui的消息。activityThread里面有一个H内部类(就是Handler),这里面就定义了各种的消息处理,包括各个生命周期函数的方法调用消息:LAUNCH_ACTIVITY,PAUSE_ACTIVITY等等。

tip:为什么会有H内部类?假如有了这个疑问,就是没有体会gui编程的本质。消息循环,android开发我感觉弱化了这一概念。假如没有消息循环,窗口就不能判断各种事件,不能作出处理。细想一下,只有响应式的这种设计,才是gui编程的基本原理。没有其他可以代替。所以Handler处理的消息机制是android ui运行的基本ok,这个毋庸置疑了。H存在是合理的不可替代的。为什么会有activityThread?他的出现实际上就是作为消息循环的框架出现的。管理了框架中的各个元件的管理和生成,android4大基本组件activity,service,provider都在activityThread中管理。所以activityThread存在是必然的。

  activityManagerNative和activityManagerService:他两个出于不同的包里面,一个是core的app下,一个是services的am包下。来说一下,activityManagerService是zygote创建系统服务,也就是说这个服务和我们的android app是两个进程之间。android的ipc通信使用的是binder机制。这个机制也是android的核心之一,也就是通过activityManagerNative调用了activityManagerService里面的方法,调用了系统功能。

tip:他两的存在性就不必强调了,多任务系统的进程通信一直都是值得关注的问题。而binder机制提供了这种功能。这两个类的作用就是使得app和系统更加有序的交互。

  activityStack:栈,是的这个就是activity栈,他也在系统服务包中,说明这个栈管理的是所有的activity的功能。所有的存在的activity都会存储在这个栈中,里面有历史栈,resume栈等,保存着各种的activity操作信息。

tip:activitystack由于android程序一般都是占满屏幕的,所以切换不易,必须要有一种操作的规律和习惯。栈是人们潜意识中很认可的一种结构,android是基于linux支持多进程很好。windowphone7.5的时候就一般了,而且操作很不习惯。玩了很久才弄明白。但不得不说metro风格确实是一大亮点。

解释完这些,我们就了解了android activity的生成过程,细想一下,是通过intent开开启activity的,调用了startActivity,有一个activity的默认操作类Instrumentation来调用了activityManagerNative,然后通过binder调用activityManagerService的方法调用activitystack的管理方法添加activity,启动actvityThread,然后发送消息给H进行显actvity。

  在说说生命周期,整个期间是如何进行回调的?其中的调用过程十分复杂,我想我必须研究的足够的时候在写其中的奥妙,可是还是没有完。遇到了一个问题就是在oncreate中想得到view的宽高。网络上有很多方法,但是只有知道系统的调用原理和流程,才会理解为什么那样做。

  首先不说如何解决?说一下为什么oncreate中得不到view的宽高?都知道view绘制有3步:测量,布局,绘制。也就是oncreate的时候view就没有做这几个步骤。那setcontentview中做了什么?

回到生命周期:

  onreate和ondestory中是指activity被创建了,也就是初始化的时候的回调,这个时候做的都是初始化工作,setcontentview也仅仅就是解析xml然后进行了view的创建。但是布局和大小信息都不确定。

  onstart和onstop中指的activity被显示,这个看似是很鸡肋的,我们都没有多使用过,确实,这个时期,就是显示了actvity的窗口,activity可视了。这时候可以layout测绘了?没有,这时候显示的是除了我们setcontentview里面布局之外的东西,也就是有一个actionbar和一个白色背景,当然这要看你的布局是怎么定义的了。这算什么意思?这些布局不都是一起的吗?为什么没有我设置的?细细想,还确实不是一起的,先不谈phonewindow和decorview,我们定义过titlebar没有?没有,这是系统的,实际上这一时期是为了显示activity的,不做其他的。

  onresume和onpause指activity在可以交互,坑爹的时刻到了,大多数人认为这个时期一定是加载了我们的布局,实际上在这个时期是要使得布局和前台进行交互,但是在布局测绘之前系统回调了onresume,导致很多人认为onresume之前一定有layout的测绘信息,这个是错误的。你可以查看源码activityThread中关于handleResumeActivity里面的源码,最后调用了activity的makeVisible进行了view的显示。也就是说这一个时刻仅仅是告诉我们actvity要到前台交互的时候了,千万不可和布局的东西混为一谈。

   这也就说明了为什么会出现之前的问题,这时候怎么办?所有生命周期的函数都没有在layout的时候调用的,没有生命周期的函数,我们还有回调函数,其实view有一个getViewTreeObserver,可以再viewtree的回调函数中进行值的获取,这种方式是可行的,也就是等到测绘layout之后在进行取值,当然还有一种就是自己进行测绘,利用measure,有的人说不行,实际上他根本就不会使用measure,MeasureSpec是其中的关键,他如何利用一个int来表示了模式和大小两个状态,不明白一共有3种模式,一味的递参数(0,0)那么只能呵呵了。这种方式是可行的,我会在以后view的绘制中专门叙述这些概念。

  其实我是想说另一种方式,我在网上没有看到,可能有人实现过。就是使用view.post来进行一个把runnable的方法放到主线程中运行,这个方法可行吗?其关键就是这个代码什么时候执行?是立刻?不是,既是在oncreate中使用这个也会在onresume之后运行,这实际上把一个消息放入消息循环中,由于消息队列是阻塞式的,当执行完所有的显示activity的方法之后才会执行这个消息。做了大量的实验。证明这一点事毋庸置疑的,所以我认为系统创建的消息包括launchactvity和resumeactivity的一些消息一定是view.post这条消息之前的,实际上我尝试源码中的证据,你可以看到的是只看到了H.LAUNCH_ACTIVITY这一个消息(虽然也有H.RESUME_ACTIVITY但是在初始创建期间不会调用),也就是说这个消息处理函数handleLaunchActivity里面执行完了oncreate,就接着执行了onstart和onresume一系列的生命周期函数,并不是每一个回调都作为一个消息。这的理由是合理的:1.你不必使用多个消息,应为这个过程本身就是连续的(当然我指的连续不是代码上的连续,而是逻辑上的连续)。2.这也就是解释了为什么在oncreate里面提交的消息,会在onresume之后执行。

  当然这个问题就算解决了,应该思考的不是这个问题,而是android的这些生命周期的是如何协调的?可以看到生命周期是和用户交互最为紧密的。我会在研究源码的同时把后续blog写出来。