title: Atlas之启动过程(一)

date: 2017-05-02 15:00:00

概述

Atlas整个启动过程的时序如下图所示，本篇只关注下图中的1-5步。

Atlas之启动过程(一) - 图1

入口

我们都知道，app的入口是application，那么atlas的入口application是什么呢，看一下app模块中manifest中的定义

Atlas之启动过程(一) - 图2

看样子，是DemoApplication

真的是这样的吗？

当然不是

我们看一下反编译后的manifest

Atlas之启动过程(一) - 图3

为什么会是AtlasBridgeApplication呢，manifest中明明写的很清楚 : DemoApplication。

事实上为了接入的方便，Atlas在编译期就替换了入口application。不过，Atlas保证在运行期时会调用DemoApplication的相关方法。

1. AtlasBridgeApplication.attachBaseContext

我们看一下AtlasBridgeApplication中的相关方法

  1. @Override
  2. protected void attachBaseContext(Context base) {
  3.     super.attachBaseContext(base);
  4.     //...一些逻辑
  6.     //1. 构造BridgeApplicationDelegate对象
  7.     Class BridgeApplicationDelegateClazz = getBaseContext().getClassLoader().loadClass("android.taobao.atlas.bridge.BridgeApplicationDelegate");
  8.     Constructor<?> con = BridgeApplicationDelegateClazz.getConstructor(parTypes);
  9.     mBridgeApplicationDelegate = con.newInstance(this,getProcessName(...);
  11.     //2. 执行BridgeApplicationDelegate的attachBaseContext方法
  12.     Method method = BridgeApplicationDelegateClazz.getDeclaredMethod("attachBaseContext");
  13.     method.invoke(mBridgeApplicationDelegate);
  14. }

可以看到，代码虽长，但其实就只干了两件事。

  • 反射并构造BridgeApplicationDelegate的实例
  • 执行BridgeApplicationDelegate的attachBaseContext方法。

先看BridgeApplicationDelegate的构造方法。

  1. //BridgeApplicationDelegate.java
  2. public BridgeApplicationDelegate(Application rawApplication...){
  3.     mRawApplication = rawApplication;
  4.     PackageManagerDelegate.delegatepackageManager(
  5.         rawApplication.getBaseContext()
  6.     );
  7. }

没什么内容，直接跟进delegatepackageManager的函数实现

  1. //PackageManagerDelegate.java
  2. public static void delegatepackageManager(Context context){
  3.       mBaseContext = context;
  4.       //1. 反射pm
  5.       PackageManager manager = mBaseContext.getPackageManager();
  6.       Class ApplicationPackageManager = Class.forName("android.app.ApplicationPackageManager");
  7.       Field field = ApplicationPackageManager.getDeclaredField("mPM");
  8.       field.setAccessible(true);
  9.       Object rawPm = field.get(manager);
  10.       //2. 动态代理pm
  11.       Class IPackageManagerClass = Class.forName("android.content.pm.IPackageManager");
  12.       mPackageManagerProxyhandler = new PackageManagerProxyhandler(rawPm);            
  13.       mProxyPm = Proxy.newProxyInstance(mBaseContext.getClassLoader(), new Class[]{IPackageManagerClass}, mPackageManagerProxyhandler);
  14.       //3. 替换pm
  15.       field.set(manager, mProxyPm);
  16. }

可以看到，这段代码的核心思想就是将系统的pm，替换为我们实现的PackageManagerProxyhandler。我们先不关注PackageManagerProxyhandler的实现，接着看BridgeApplicationDelegate中函数attachBaseContext的实现。

2. BridgeApplicationDelegate. attachBaseContext

BridgeApplicationDelegate.java

  1. public void attachBaseContext(){
  2.     //2.1 hook之前准备工作
  3.     AtlasHacks.defineAndVerify();
  5.     //2.2 回调预留接口
  6.    launcher.initBeforeAtlas(mRawApplication.getBaseContext());
  8.    //2.3 初始化atlas     
  9.    Atlas.getInstance().init(mRawApplication, mIsUpdated);
  11.    //2.4 处理provider    
  12.     AtlasHacks.ActivityThread$AppBindData_providers.set(mBoundApplication,null);
  13. }

函数实现大概分为四个部分，也是本篇文章的重点关注部分

  • hook之前的准备工作
  • 回调预留接口
  • 初始化atlas
  • 处理provider

我们也一个来看。

3. AtlasHacks.defineAndVerify

在开始分析之前，我们要知道，Android上动态加载方案，始终都绕不过三个关键的点:

  • 动态加载class
  • 动态加载资源
  • 处理四大组件 能够让动态代码中的四大组件在Android上正常跑起来

为了实现这三个目标，会在系统关键调用的地方进行Hook。比如，为了能够动态加载class，通常都会对classloader上动一些手脚，resource也是类似。

这里多提一句，在四大组件的处理上，atals与插件化有着很大的差异。

  • 插件化的核心思想其实是埋坑机制+借尸还魂 ：通过预先在manifest中预留N个组件坑，在runtime时，通过“借尸还魂”实现四大组件的运行。
  • atlas不一样，它是在编译期就已经各个bundle的manifest写入到apk中。所以运行时，bundle中的组件可以和常规声明的组件一样正常运行，不用再做额外的处理。

回过头来，我们看看atlas为了实现上述目的，做了哪些准备工作。在跟进defineAndVerify函数的实现之前，先看一下AtlasHacks类中定义的字段

  1. //AtlasHacks.java
  3.      // Classes
  4.     public static HackedClass<Object>                           LoadedApk;
  5.     public static HackedClass<Object>                           ActivityThread;
  6.     public static HackedClass<android.content.res.Resources>    Resources;
  8.     // Fields
  9.     public static HackedField<Object, Instrumentation>          ActivityThread_mInstrumentation;
  10.     public static HackedField<Object, Application>              LoadedApk_mApplication;
  11.     public static HackedField<Object, Resources>                LoadedApk_mResources;
  13.     // Methods
  14.     public static HackedMethod                                  ActivityThread_currentActivityThread;
  15.     public static HackedMethod                                  AssetManager_addAssetPath;
  16.     public static HackedMethod                                  Application_attach;
  17.     public static HackedField<Object, ClassLoader>              LoadedApk_mClassLoader;
  19.     // Constructor
  20.     public static Hack.HackedConstructor                        PackageParser_constructor;

给这段代码点个赞，非常的干净和清晰。代码定义了atlas框架所需要hook的所有的类、方法、属性等等字段。

  • 处理资源，hook Resources
  • 处理class，hook LoadedApk_mClassLoader
  • …

现在，在看defineAndVerify函数的实现

  1. //AtlasHacks.java
  2. public static boolean defineAndVerify() throws AssertionArrayException {
  3.      allClasses();
  4.      allConstructors();
  5.      allFields();
  6.      allMethods();
  7. }

实际上这四个级别的函数调用，对应之前定义的字段，为这些字段进行赋值。

  1. //AtlasHacks.java
  2. public static void allClasses() throws HackAssertionException {
  3.     LoadedApk = Hack.into("android.app.LoadedApk");
  4.     ActivityThread = Hack.into("android.app.ActivityThread");
  5.     Resources = Hack.into(Resources.class);
  6.     ActivityManager = Hack.into("android.app.ActivityManager");
  7.     //...
  8. }
  10. public static void allFields() throws HackAssertionException {
  11.     ActivityThread_mInstrumentation = ActivityThread.field("mInstrumentation").ofType(Instrumentation.class);
  12.     ActivityThread_mAllApplications = ActivityThread.field("mAllApplications").ofGenericType(ArrayList.class);
  13. }
  15. //...

这几个函数的代码并不复杂，是对定义的Class、Field、Method和Contructor 这些字段进行初始化赋值工作。

执行到这里时，atlas框架的准备工作完成，接下来，就是整个框架的初始化了。

4 回调预留接口

时序图中的第4步，即BridgeApplicationDelegate的attachBaseContext方法中，，做了一个接口回调。

BridgeApplicationDelegate.java

  1. public void attachBaseContext(){
  2.    String preLaunchStr = (String) RuntimeVariables.getFrameworkProperty("preLaunch");
  3.    AtlasPreLauncher launcher = (AtlasPreLauncher) Class.forName(preLaunchStr).newInstance();
  4.    launcher.initBeforeAtlas(mRawApplication.getBaseContext());
  5.    //...
  6. }

函数通过“preLaunch”字段读取一个类名，反射该类上的initBeforeAtlas方法。

AtlasPreLauncher实际上是一个接口，供接入者使用。在这个点，atlas还没有开始对系统进行hook，仍然是Android原生态的运行时环境。

那么这个preLaunch的字段在哪里定义的呢，我们反推一下。

RuntimeVariables.java

  1. public static Object getFrameworkProperty(String fieldName){
  2.     //...
  3.     Field field = FrameworkPropertiesClazz.getDeclaredField(fieldName);
  4.     return field.get(FrameworkPropertiesClazz);
  5. }

实现很简单，读取FrameworkProperties上的静态属性字段，接着跟进。

  1. public class FrameworkProperties {
  2. }

什么情况，怎么什么都没有? 所谓反常即为?，直接看反编译后的代码

FrameworkProperties.java

  1. public class FrameworkProperties{
  2.   //...
  3.   public static String autoStartBundles;
  4.   public static String preLaunch;
  6.   static{
  7.     autoStartBundles = "com.taobao.firstbundle";
  8.     preLaunch = "com.taobao.demo.DemoPreLaunch";
  9.   }
  10. }

从反编译后的代码可以看到，”prelaunch”对应的内容是com.taobao.demo.DemoPreLaunch,那么这个值是在 什么时候写入又是在哪里配置 的呢？

大家回想一下，在之前Atlas之Gradle配置中提到过，atlas的gradle插件在编译期搞了很多事情，我们看gradle中的设置

  1. atlas{
  2.      tBuildConfig {
  3.         autoStartBundles = ['com.taobao.firstbundle']
  4.         preLaunch = 'com.taobao.demo.DemoPreLaunch'
  5.     }
  6. }

和FrameworkProperties中的字段完美对应。

这个部分牵涉开发-编译-运行三个阶段，放一张图捋一下关系。

Atlas之启动过程(一) - 图4

5 atlas.init

准备工作做好之后，就是初始化了。

Atlas.java

  1. public void init(Application application,boolean reset) {
  2.     //读取配置项
  3.     ApplicationInfo appInfo = mRawApplication.get...;
  4.     mRealApplicationName = appInfo.metaData.getString("REAL_APPLICATION");
  5.     boolean multidexEnable = appInfo.metaData.getBoolean("multidex_enable");
  7.     if(multidexEnable){
  8.       MultiDex.install(mRawApplication);
  9.    }
  10.     //...   
  11. }

首先是读取manifest中的配置数据multidexEnable和mRealApplicationName，这两个数据也是在编译期由atlas插件写到manifest中的。

Atlas之启动过程(一) - 图5

multidexEnable 是true，这个在gradle中可配

mRealApplicationName 实际上是DemoApplication,即app工程在manifest中指定的启动路径。

捋清楚这几个参数之后，往下看Atlas框架初始化实现

Atlas.java

  1. public void init(Application application,boolean reset) {
  2.    //...
  3.    Atlas.getInstance().init(mRawApplication, mIsUpdated);
  4. }
  6. public void init(Application application,boolean reset) throws AssertionArrayException, Exception {
  7.      //...
  9.      //1. 换classloader 
  10.      AndroidHack.injectClassLoader(packageName, newClassLoader);
  11.      //2. 换Instrumentatio
  12.      AndroidHack.injectInstrumentationHook(new InstrumentationHook(AndroidHack.getInstrumentation(), application.getBaseContext()));
  13.      //3. hook ams
  14.      try {
  15.          ActivityManagerDelegate activityManagerProxy = new ActivityManagerDelegate();
  16.          Object gDefault = null;
  17.          if(Build.VERSION.SDK_INT>25 || (Build.VERSION.SDK_INT==25&&Build.VERSION.PREVIEW_SDK_INT>0)){
  18.              gDefault=AtlasHacks.ActivityManager_IActivityManagerSingleton.get(AtlasHacks.ActivityManager.getmClass());
  19.          }else{
  20.                gDefault=AtlasHacks.ActivityManagerNative_gDefault.get(AtlasHacks.ActivityManagerNative.getmClass());
  21.          }
  22.          AtlasHacks.Singleton_mInstance.hijack(gDefault, activityManagerProxy);
  23.       }catch(Throwable e){}
  24.       //4. hook H
  25.       AndroidHack.hackH();
  26. }

这段代码，就是对系统关键节点进行了hook，具体的hook实现这里就不贴出了，如果感兴趣，可以参考demo源码以及田维术的blog，如何hook，以及为什么在这里hook，在文章中都讲的非常清楚。

函数中的hook点

hook点 实例
ActivityThread.mLoadedApk.mClassLoader DelegateClassLoader
ActivityThread.mInstrumentation InstrumentationHook
ActivityManagerNative.gDefault.get ActivityManagerDelegate
android.app.ActivityThread\$H.mCallback ActivityThreadHook

6. 处理provider

在第2步的2.4部分，对provider进行了处理

BridgeApplicationDelegate.java

  1. public void attachBaseContext(){
  2.     //...
  4.    //2.4 处理provider
  5.    Object mBoundApplication = AtlasHacks.ActivityThread_mBoundApplication.get(activityThread);
  6.    mBoundApplication_provider = AtlasHacks.ActivityThread$AppBindData_providers.get(mBoundApplication);
  7.    if(mBoundApplication_provider!=null && mBoundApplication_provider.size()>0){
  8.            AtlasHacks.ActivityThread$AppBindData_providers.set(mBoundApplication,null);
  9.     }
  10. }

第4行代码读取provider数据，如果有provider信息的话，则在第6行从系统删除，让系统认为apk并没有申请任何provider。

为什么这么做?回顾一下app启动的流程

Atlas之启动过程(一) - 图6

可以看到，在第4步和第7步两个关键调用之间，第5步调用了函数installContentProviders,跟进去看一下。

  1. private void installContentProviders(Context context, List<ProviderInfo> providers) {
  2.     for (ProviderInfo cpi : providers) {
  3.         installProvider(context, null, cpi,...);
  4.     }
  5. }

收集了所有provider的信息，然后调用installProvider函数

  1. private IActivityManager.ContentProviderHolder installProvider(Context context,IActivityManager.ContentProviderHolder holder, ProviderInfo info,...) {
  2.     final java.lang.ClassLoader cl = c.getClassLoader();
  3.    localProvider = (ContentProvider)cl.loadClass(info.name).newInstance();
  4.    //...
  5. }

可以看到，函数是根据在manifest中登记的provider信息，实例化对象。

那么问题来了，有些provider是存在于bundle中的，主dex中并不存在。如果不处理，在这里程序会因为ClassNotFind崩溃。所以这里要先清除掉provier的信息，延迟加载。

上篇先到这里，各位先喝口水，再来下篇的分析。