APP部分启动过程与Activity的生命周期调用过程

发表于 | 阅读 次
字数统计: 1,327 | 阅读时长 ≈ 6

不擅长 长篇大论，直接以问题作为切入点来进行源码分析。

1.Java层的入口是main(),那么Android有没有main()？里面在做什么操作？
2.Android是如何启动的，Activity的生命周期是如何调用的？
3.setContentView究竟是在干什么？
4.view的绘制流程究竟是怎样的？
5.Zygote,Binder,Launcher,各种Manager等等都是些什么玩意… 参考链接
6.面试为什么总问这些问题？即便是懂了，之后也会忘，而且对应用层开发有什么实际性的帮助？
7.热修复，组件化，插件化等热门技术都要怎么搞？

1和2的答案：
Android应用程启动入口 ActivityThread的main()方法

Looper.prepareMainLooper();//handler机制，
ActivityThread thread = new ActivityThread();//实例化ResourcesManager
thread.attach(false);//****核心源码***** 最初的初始化
Looper.loop();

attach方法()核心源码分析
ViewRootImpl，Binder，暂时不分析，从ActivityManager开始

private void attach(boolean system) {
      final IActivityManager mgr = ActivityManager.getService();
      try {
          mgr.attachApplication(mAppThread);
      } catch (RemoteException ex) {
          throw ex.rethrowFromSystemServer();
      }

getService()源码分析
主要是用到单例，所有的类进入都会变成单例，这种设计模式暂时不分析，只需要知道，他是通过跨进程的方式来调用。

attachApplication在这里的作用其实实际上是将ActivityThread和ApplciationThread将其关联，把activity相关信息存储在applciationThread里面，apllicationThread的类为activity的各种状态做了相对应的准备工作

 public static IActivityManager getService() {
    return IActivityManagerSingleton.get();
}

private static final Singleton<IActivityManager> IActivityManagerSingleton =
        new Singleton<IActivityManager>() {
            @Override
            protected IActivityManager create() {
                final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
                final IActivityManager am = IActivityManager.Stub.asInterface(b);
                return am;
            }
        };

ActivityManager(app进程)和ActivityManagerService(系统进程)，通过binder机制，由系统来调用，不是自身来new Manager，而是系统来管理。实际上ActivityManager是有系统服务所调用管理，并且通过在binder接口当中进行调用，这也是可以解释为什么Activity是跨进程访问

那么为什么系统管理，而不是单独给他们配置呢？？

attachApplication(ApplicationThread)源码分析
这里是一个接口，内部的Proxy中实现这个方法

public interface IActivityManager extends IInterface {

void attachApplication(IApplicationThread var1) throws RemoteException;

//内部的Proxy实现了IActivityManager
private static class Proxy implements IActivityManager 

public void attachApplication(IApplicationThread app) throws RemoteException {
            Parcel _data = Parcel.obtain();
            Parcel _reply = Parcel.obtain();

            try {
                _data.writeInterfaceToken("android.app.IActivityManager");
                _data.writeStrongBinder(app != null?app.asBinder():null);
                this.mRemote.transact(11, _data, _reply, 0);
                _reply.readException();
            } finally {
                _reply.recycle();
                _data.recycle();
            }
        }


private class ApplicationThread extends IApplicationThread.Stub 
ApplicationThread是继承了Stub,内部scheduleXXXActivity()函数，也就是说是在调用activity的生命周期。

以最为典型的就是scheduleLaunchActivity() 启动activity

   // we use token to identify this activity without having to send the
    // activity itself back to the activity manager. (matters more with ipc)

   @Override
    public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
            ActivityInfo info, Configuration curConfig, Configuration overrideConfig,
            CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor,
            int procState, Bundle state, PersistableBundle persistentState,
            List<ResultInfo> pendingResults, List<ReferrerIntent> pendingNewIntents,
            boolean notResumed, boolean isForward, ProfilerInfo profilerInfo）
      //实际上就是在这里创建的activity
     ActivityClientRecord r = new ActivityClientRecord();
      r.activityInfo = info;
      //一大堆配置文件，省略
      //H实际上就是一个handler
        sendMessage(H.LAUNCH_ACTIVITY, r);
    }


//这里实际上就是用handler机制传递数据，那么就可以直接开始找handleMessage，看接收数据
  private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) {
    if (DEBUG_MESSAGES) Slog.v(
        TAG, "SCHEDULE " + what + " " + mH.codeToString(what)
        + ": " + arg1 + " / " + obj);
    Message msg = Message.obtain();
    msg.what = what;
    msg.obj = obj;
    msg.arg1 = arg1;
    msg.arg2 = arg2;
    if (async) {
        msg.setAsynchronous(true);
    }
    mH.sendMessage(msg);
}

//这里暂时只分析activity部分，其他省略，很明显看的出来是在调用activity的生命周期。
//我们只需要关注LAUNCH_ACTIVITY部分在做什么操作
  public void handleMessage(Message msg) {
        switch (msg.what) {
            case LAUNCH_ACTIVITY: {
            final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
             handleLaunchActivity(r, null, "LAUNCH_ACTIVITY");
                 break;
            case RELAUNCH_ACTIVITY: {
                ActivityClientRecord r = (ActivityClientRecord)msg.obj;
                handleRelaunchActivity(r);
                 break;
            }
            case PAUSE_ACTIVITY: {
                handlePauseActivity();
            } 
                  break;
            case PAUSE_ACTIVITY_FINISHING: {
                handlePauseActivity();
            }
                  break;
            //略

 //handleLaunchActivity源码分析
 private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
    //开启activity
    Activity a = performLaunchActivity(r, customIntent);
    handleResumeActivity(r.token, false, r.isForward,
                !r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);
    }

   if (a != null) {
        r.createdConfig = new Configuration(mConfiguration);
        reportSizeConfigurations(r);
        Bundle oldState = r.state;
      //resume方法
        handleResumeActivity(r.token, false, r.isForward,
                !r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);

        if (!r.activity.mFinished && r.startsNotResumed) {
          //pause方法
            performPauseActivityIfNeeded(r, reason);

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
     ActivityInfo aInfo = r.activityInfo;
    Activity activity = null;
    try {
  //  反射构建了一个activity
        java.lang.ClassLoader cl = appContext.getClassLoader();
        activity = mInstrumentation.newActivity(
                cl, component.getClassName(), r.intent);

           //调用了activity的attach()；
            activity.attach();    
            //activity设置theme
            activity.setTheme(theme);
            if (r.isPersistable()) {
              // 调用activity的onCreate()方法
                mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
            } else {
                mInstrumentation.callActivityOnCreate(activity, r.state);
            }
           mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state,
                                r.persistentState);
                    mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);

    return activity;
}

问题1和2的总结就是：当点击APP的时候，是由系统服务通过binder来调用，
通过各种scheduXXXXXActivity()内部调用sendMessage，然后通过handler进行传递，根据不同的状态来进行调用不同的生命周期

抄一波别人的图

6的答案:组件化，插件化那些 就是模仿framework来的，热修复也是，都是模仿源码，从里面找灵感。
架构师很多的设计思想都是通过源码中来的，当年的MVP是模仿Java GUI来的，所以 研究底层，就是为了做知识储备，发酵酝酿，就等你开窍，搞出个新东西出来，造福百姓。
毕竟只会用三方库，写傻代码的猿肯定迟早会被淘汰的。获取别人的思想，当别人出现这样的业务场景时，Android底层是如何处理的

核心还是binder和handler

下一篇文章将回答问题3，4，5，之后有时间会依次整理热修复 组件化和插件化源码分析。

igding wechat
2018 依计行事 持续精进
坚持原创技术分享，您的支持将鼓励我继续创作！