发布时间 : 星期日 文章Android Activity原理分析更新完毕开始阅读
路线；
onResume完全是为了实现在onRestart的时候而引入的，但是在第一次启动的时候也被执行； 它是和onPause相对的；
onPause:它表示暂停，比如一个新的activity弹出来覆盖在旧的activity上，那么旧的activity将会先进入pause状态；
onStop:如果新的activity弹出来后完全覆盖了旧的activity，那么旧的那个activity将会进入到onStop状态；
onDestory:进入Stop状态的activity会被定期清理，比如为了节省内存，比如是用户故意的配置，比如是用户通过finish系统调用，activity都会被Destory，释放掉所有的资源； 如果我们从launcher里面随便点击一个应用的图标A将会走这些流程： onCreate——>onStart——>onResume
当一个新的activity B弹出来的时候，那么A activity将会走下面的逻辑：
onPause->onStop或者就是onPause，视新出来的activity是否完全遮住activity A；
如果activity B被关闭，那么如果这时候A 处于pause状态，那么它就简单的执行onResume;如果它处于onStop，那么它会执行onRestart,onStart,onResume;
也就是说，一个activity的启动，肯定会走onStart或onResume；
当这个activity资源已经释放了，要重新启动，那么才会执行onCreate；
从上面的结论来说，一个activity的onCreate函数需要负责资源的申请，变量的初始化等； 当暂停的时候需要做一些数据，状态的保存等；
在Stop的时候该关闭的就关闭了，该释放的就释放，不能留到onDestory;
Android的文档上说，在杀掉一个Activity之前，唯一一个一定会被保证执行的函数是onPause,也就是说连onStop也不一定是可靠的，而onDestory就更不可靠了，你甚至都无法知道它什么时候将会被执行；
好，有了这些整体的认识，下面就是一个详细的介绍，以一个activity启动过程为线索，介绍上面的七个状态的调用逻辑；
当然，纯属分析，并没有多少实际的用处；
5.
5.1
Activity的各个状态的切换细节 Activity的启动过程
5.1.1 客户端执行逻辑
接下来的过程涉及比较多的代码，不太可能关注到每一个细节，我主要是以上面的七个状态函数的执行为线索； 那是很久很久以前，
我们需要回到Launcher的代码，当用户点击了一个应用的图标的时候，会触发onClick函数,逻辑如下：
?Tech, 2010-2-5 Page 5 of 38
onClick(View v)这个是点击主界面的程序图标的逻辑 final Intent intent = ((ApplicationInfo) tag).intent;startActivitySafely startActivity(intent);startActivity(Intent intent)ContextWrapper.javamBase.startActivity(intent);这个mBase申明为Context类型的，但实际绝大多数为ApplicationContext类型的；
前面的流程都是因为Activity本身其实是继承于ContextThemeWrapper它又继承于ContextWrapper，它继承于Context，而
class ApplicationContext extends Context，
所以最后这个函数的实现由ApplicationContext来完成；
事实上，很多工作，特别是一些共性的功能的实现多数是由这个类来完成的，包括和WindowManager，ActivityManager的交互也是它来完成的； 咱们继续看：
?Tech, 2010-2-5 Page 6 of 38
public void startActivity(Intent intent)ApplicationContext.javamMainThread.getInstrumentation().execStartActivity(getOuterContext(), mMainThread.getApplicationThread(), null, null, intent, -1)execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode)ActivityManagerNative.getDefault().startActivity(whoThread, intent,intent.resolveTypeIfNeeded(who.getContentResolver()), null, 0, token, target != null ? target.mEmbeddedID : null,requestCode, false, false)
这里第二个框图通过mMainThread.getInstrumentation进入了另外一个神奇的类，不太好跟，它是由文件Instrumentation.java来实现的，通常这个类是进入到我们前面说过的七个状态的入口； 这个函数通过ActivityManagerNative.getDefault().startActivity来完成剩下的工作； 如果你是第一次看Android的类似的代码，我想你肯定会抓狂，这一系列的类，会把人逼疯；我可以告诉你一个很简单的办法，通常看到带Native的类，你把Native替换成Service，再把调用的函数在这个新的类的实现的文件里面找，肯定能找到，这是一条捷径； 如果你一定要知道这里面的细节的话，需要看很多东西，而且必须要理解Binder的原理，java层的Service如果要提供接口给客户端，通常会采用这样的方式，这个getDefault返回的本质上是ActivityManagerService的BpBinder，通过它调用的函数通过Binder调用后会进入到
ActivityManagerService里面的同名函数，这一块，我想由专门的文档来描述；现在只需要记住，这类型的调用都会进入到activityManagerService类，就可以了；也就是说逻辑控制已经从Launcher的进程切换到了ActivitymanagerService的进程了； 我下面通过两个图简单描述这个Binder调用过程：
?Tech, 2010-2-5 Page 7 of 38
startActivity(IApplicationThread caller, Intent intent, String resolvedType, Uri[] grantedUriPermissions, int grantedMode, IBinder resultTo, String resultWho, int requestCode, boolean onlyIfNeeded, boolean debug)ActivityManagerNative.java
mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0); 这里的信息会通过驱动提供的共享内存传递到ActivityManagerService，然后通过一个单独的Binder处理线程会把这些信息从共享内存取出来分发处理，处理函数通常叫onTransact;
onTransactActivityManagerService.javasuper.onTransact(code, data, reply, flags); case START_ACTIVITY_TRANSACTION:
这个图的执行逻辑已经到了activityManagerService这边了，onTransact函数也就根据不同的消息类型调用不同的函数来处理，接着往下看：
int result = startActivity(app, intent, resolvedType,grantedUriPermissions, grantedMode, resultTo, resultWho,requestCode, onlyIfNeeded, debug);
?Tech, 2010-2-5 Page 8 of 38