Activity作为四大组件中最重要的组件，在Replugin中对它的支持的架构设计也是最复杂的，所以本篇分析我们就来看看Activity的启动流程。

以下这张图简要的画出类Activity启动的过程，当然简化了一些流程：

• Pmbase根据Intent找到对应的插件
• 分配坑位Activity，与插件中的Activity建立一对一的关系并保存在PluginContainer中
• 让系统启动坑位Activity，因为它是在Manifest中注册过的
• Android系统会尝试使用RepluginClassLoader加载坑位Activity的Class对象
• RepluginClassLoader 通过建立的对应关系找到插件Activity，并使用PluginDexClassLoader 加载插件Activity 的Class对象并返回
• Android系统就使用这个插件中的Activity的Class对象来运行生命周期函数

Android系统就是这样被欺骗了！

activity.jpg

• 如果有必要，需要先下载插件

  下载过程会通过回调让用户去实现，比如显示进度，安装等。

  if (download) {
      if (PluginTable.getPluginInfo(plugin) == null) {
          if (isNeedToDownload(context, plugin)) {
              return RePlugin.getConfig().getCallbacks().onPluginNotExistsForActivity(context, plugin, intent, process);
          }
      }
  }
  

• 检查插件状态

  如果插件状态不正确，或者首次加载大插件，会通过回调让用户处理，用户可以可以在回调里定制自己的行为，比如弹出提示框，加载进度条等。

  if (PluginStatusController.getStatus(plugin) < PluginStatusController.STATUS_OK) {
      return RePlugin.getConfig().getCallbacks().onPluginNotExistsForActivity(context, plugin, intent, process);
  }
  
  if (!RePlugin.isPluginDexExtracted(plugin)) {
      PluginDesc pd = PluginDesc.get(plugin);
      if (pd != null && pd.isLarge()) {
          return RePlugin.getConfig().getCallbacks().onLoadLargePluginForActivity(context, plugin, intent, process);
      }
  }
  

• 寻找坑位，启动坑位Activity

  调用在PluginLibraryInternalProxy.startActivity()中调用PluginCommImpl.loadPluginActivity来寻找坑位Activity。

  请注意注释中的分支C，如果是第一次去获取信息，会首先去加载插件的Dex文件以及资源等，并创建PluginDexClassLoader。这个分支我们在后面来讲解。

  public ComponentName loadPluginActivity(Intent intent, String plugin, String activity, int process) {
      ActivityInfo ai = null;
      String container = null;
      PluginBinderInfo info = new PluginBinderInfo(PluginBinderInfo.ACTIVITY_REQUEST);
  
      try {
          ai = getActivityInfo(plugin, activity, intent); //分支C:获取 ActivityInfo
          // 根据 activity 的 processName，选择进程 ID 标识
          if (ai.processName != null) {
              process = PluginClientHelper.getProcessInt(ai.processName);
          }
          // 容器选择（启动目标进程，如果有必要的话，一般默认会使用UI进程）
          IPluginClient client = MP.startPluginProcess(plugin, process, info);
        ......
          // 远程分配坑位
          container = client.allocActivityContainer(plugin, process, ai.name, intent);
      } catch (Throwable e) {
      }
  
      PmBase.cleanIntentPluginParams(intent);
    ......
      return new ComponentName(IPC.getPackageName(), container);
  }
  

  来重点看看坑位分配，这是一个远程调用，调用了Persistent进程中的PluginProcessPer.allocActivityContainer函数，进一步调用bindActivity函数。

  final String bindActivity(String plugin, int process, String activity, Intent intent) {
      Plugin p = mPluginMgr.loadAppPlugin(plugin); //获取插件对象
    ......
      ActivityInfo ai = p.mLoader.mComponents.getActivity(activity); //获取ActivityInfo
    ......
      String container;
      // 自定义进程
      if (ai.processName.contains(PluginProcessHost.PROCESS_PLUGIN_SUFFIX2)) {
          String processTail = PluginProcessHost.processTail(ai.processName);
          container = mACM.alloc2(ai, plugin, activity, process, intent, processTail);
      } else {
          container = mACM.alloc(ai, plugin, activity, process, intent);
      }
    ......
      return container;
  }
  

  这里mACM.alloc2调用allocLocked函数真正的执行了坑位分配的任务。这段代码简单明了，注意坑位找好以后会返回一个AcitivtyState对象，这里面保存了坑位Activity和真实要启动的Activity之间的对应关系。并且这个对应关系会被保存起来，在RepluginClassLoader在加载类的时候会被拿出来使用，以获取要运行的Activity的class对象。

  private final ActivityState allocLocked(ActivityInfo ai, HashMap<String, ActivityState> map, String plugin, String activity, Intent intent) {
      // 首先找上一个活的，或者已经注册的，避免多个坑到同一个activity的映射
      for (ActivityState state : map.values()) {
          if (state.isTarget(plugin, activity)) {
              return state;
          }
      }
      // 新分配：找空白的，第一个
      for (ActivityState state : map.values()) {
          if (state.state == STATE_NONE) {
              state.occupy(plugin, activity);
              return state;
          }
      }
      ActivityState found;
      // 重用：则找最老的那个
      found = null;
      for (ActivityState state : map.values()) {
          if (!state.hasRef()) {
              if (found == null) {
                  found = state;
              } else if (state.timestamp < found.timestamp) {
                  found = state;
              }
          }
      }
      if (found != null) {
          found.occupy(plugin, activity);
          return found;
      }
      // 强挤：最后一招，挤掉：最老的那个
      found = null;
      for (ActivityState state : map.values()) {
          if (found == null) {
              found = state;
          } else if (state.timestamp < found.timestamp) {
              found = state;
          }
      }
      if (found != null) {
          found.finishRefs();
          found.occupy(plugin, activity);
          return found;
      }
      return null;
  }
  

  坑位找到啦！PluginLibraryInternalProxy.startActivity()中开始启动坑位Activity，就在分支D的位置，这个分支我们稍微延后一点来展开。

  public boolean startActivity(Context context, Intent intent, String plugin, String activity, int process, boolean download) {
      ......
      ComponentName cn = mPluginMgr.mLocal.loadPluginActivity(intent, plugin, activity, process);  // 找到坑位组件
      ......
      // 将Intent指向到“坑位”
      intent.setComponent(cn);
      ......
      context.startActivity(intent);  //分支D: 启动坑位Activity
  
      return true;
  }
  

  看到这里你一定会疑惑，难道这样插件的Activity就启动起来啦吗？这启动的明明就是一个坑位Activity啊？别着急，接着就是前面一直强调的唯一hook点发挥作用的时候啦！！

• Dex的加载以及Activity的加载启动

  上面有一个分支C你还记得吗？我们将它与Activity的加载流程放在一起来讲，因为这两者是紧密相关的。

  先来看分支C。

  • PluginCommImpl.getActivityInfo调用PmBase.loadAppPlugin获取插件对象，从下面注释的分支可以看出，Replugin 是支持使用 IntentFilter 来启动组件的，完美支持原生特性，是不是很赞！

    public ActivityInfo getActivityInfo(String plugin, String activity, Intent intent){
        Plugin p = mPluginMgr.loadAppPlugin(plugin);  //获取插件对象
        ......
        ActivityInfo ai = null;
    
        //activity 不为空时，从插件声明的 Activity 集合中查找
        if (!TextUtils.isEmpty(activity)) {
            ai = p.mLoader.mComponents.getActivity(activity);
        } else {
            //activity 为空时，根据 Intent 匹配
            ai = IntentMatcherHelper.getActivityInfo(mContext, plugin, intent);
        }
        return ai;
    }
    

  • PmBase.loadAppPlugin会最终调用Plugin.loadLocked()函数，这个函数有两个参数，第一个是加载类型，一共有四种加载类型，在这里使用的是Plugin.LOAD_APP，因为运行插件需要所有的东西。第二个参数是是否使用缓存，通常情况下我们会现在缓存中查找插件信息，这样会更快。只是如果大量插件加载到内存会不会占用太多的内存，感兴趣的同学可以自己研究研究。

    这里如果第一次加载失败，Replugin还会做一次重试，相关代码几乎相同，这里就省略了。

    private boolean loadLocked(int load, boolean useCache) {
        // 这里先处理一下，如果cache命中，省了后面插件提取（如释放Jar包等）操作，直接返回缓存数据
        if (useCache) {
            boolean result = loadByCache(load);
            if (result) {
                return true;
            }
        }
        ......
        boolean rc = doLoad(logTag, context, parent, manager, load);  // 真正的加载
    
        if (rc) {
            try {
                // 至此，该插件已开始运行
                PluginManagerProxy.addToRunningPluginsNoThrows(mInfo.getName());
            } catch (Throwable e) {
            }
            return true;
        }
        ......
        File odex = mInfo.getDexFile();
        if (odex.exists()) {
            odex.delete();
        }
        rc = doLoad(logTag, context, parent, manager, load);
        ......
        return true;
    }
    

  • Plugin.doLoad()当然就是来加载插件的Dex文件，资源，以及so文件等等。

    private final boolean doLoad(String tag, Context context, ClassLoader parent, PluginCommImpl manager, int load) {
        if (mLoader == null) {
            // 中间省略这一段代码是释放so文件，请自行阅读代码，代码清晰简单
            ......
            // 加载Dex，获取组件信息
            mLoader = new Loader(context, mInfo.getName(), mInfo.getPath(), this);
            if (!mLoader.loadDex(parent, load)) {
                return false;
            }
            // 在Persistent进程中更新插件信息，设置插件为“使用过的”
            try {
                PluginManagerProxy.updateUsedIfNeeded(mInfo.getName(), true);
            } catch (RemoteException e) {
            }
    
            // 若需要加载Dex，则还同时需要初始化插件里的Entry对象
            if (load == LOAD_APP) {
                // NOTE Entry对象是可以在任何线程中被调用到
                if (!loadEntryLocked(manager)) {
                    return false;
                }
            }
        }
    }
    

  • Loader.loadDex函数会获取Dex中的组件的信息，包括Manifest中的组件属性，比如进程属性，TaskAffinity属性，注册静态广播等等。但这里值得重点强调的是之前核心概念里提及的PluginDexClassLoader终于出现并被初始化了。

    final boolean loadDex(ClassLoader parent, int load) {
        try {
           ......  // 这里省略了一些基本的加载动作
            mClassLoader = Plugin.queryCachedClassLoader(mPath);
            if (mClassLoader == null) {
                ......
                mClassLoader = RePlugin.getConfig().getCallbacks().createPluginClassLoader(mPath, out, soDir, parent);     //  创建PluginDexClassLoader
                ......  
            }
            ......
            mPkgContext = new PluginContext(mContext, android.R.style.Theme, mClassLoader, mPkgResources, mPluginName, this);   // 创建插件的Context对象
        } catch (Throwable e) {
            return false;
        }
    
        return true;
    }
    

    到此为止，插件Dex的加载算是全部完成，下面还剩最后一步，我们的插件就算真正的启动运行起来了。

  • 这里我们要接着前面启动坑位Activity的地方接着讲，要启动Activity首先要去加载对应的类，系统会调用Classloader的loadClass方法，这里就是调用Replugin提供的替代者RepluginClassLoader的方法。接着又会调用PMF.loadClass，其实就是调用Pmbase.loadClass

    protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
        Class<?> c = null;
        c = PMF.loadClass(className, resolve);  
        if (c != null) {
            return c;
        }
        try {
            c = mOrig.loadClass(className); // 如果上面没有找到，那就在Host当中找
            return c;
        } catch (Throwable e) {
        }
        return super.loadClass(className, resolve);
    }
    

  • PmBase.loadClass看起来代码很多，对于Activity来说，其实我们只需要关注下面这一小段即可，mClient是PluginProcessPer的实例，而PluginProcessPer是IPluginClient的实现类。

    final Class<?> loadClass(String className, boolean resolve) {
        ......
        if (mContainerActivities.contains(className)) {
            Class<?> c = mClient.resolveActivityClass(className);
            if (c != null) {
                return c;
            }
            ......
        }
        ......
    }
    

  • 这里先从PluginContainers的实例对象mACM中去查找ActivityState，对这个类还有印象吗？它就是在分配坑位的时候，我们用来保存坑位组件与真实组件对应关系的类。然后在缓存中找到插件名对应的插件对象，因为在分配坑位的时候插件信息已经加载过了，不需要重新加载。接着取出插件的ClassLoader对象，这个对象正是加载插件时创建的PuginDexClassLoader的实例了。然后利用插件的PuginDexClassLoader对象来加载真实Activity的class对象。

    final Class<?> resolveActivityClass(String container) {
        String plugin = null;
        String activity = null;
        // 找到坑位Activity与真实Activity的对应关系对象
        PluginContainers.ActivityState state = mACM.lookupByContainer(container);
        ......
        plugin = state.plugin;
        activity = state.activity;
        ......
        Plugin p = mPluginMgr.loadAppPlugin(plugin); //通过插件名从缓存中加载Plugin对象
        ......
        ClassLoader cl = p.getClassLoader();
        Class<?> c = null;
        try {
            c = cl.loadClass(activity);
        } catch (Throwable e) {
        }
        return c;
    }
    

    找到插件Activity的类对象后，Android系统就开始运行Activity的启动流程了，这些事情由ActivityManagerService和ActivityThread负责。就这样，Replugin用插件中的Activity替换了坑位Activity，我们的插件被运行起来啦！！很巧妙的设计～

小结

以上的内容就是一个插件Activity要运行起来，Replugin的基本代码流程，这里要说明一下，源码中的逻辑远不止这么点，如果你有兴趣可以跟着这篇文章在源码中过一遍，有很多不是那么复杂的逻辑这里并没有讲到，当然也有一些重要的地方因为代码并不复杂也没有讲到。

下一篇Replugin 全面解析（3） 会对插件的加载和运行做更完整和详细的讲解！