Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> Android開發 >> 關於android開發 >> 美團Android DEX自動拆包及動態加載簡介

美團Android DEX自動拆包及動態加載簡介

編輯:關於android開發

美團Android DEX自動拆包及動態加載簡介


 

概述

作為一個android開發者,在開發應用時,隨著業務規模發展到一定程度,不斷地加入新功能、添加新的類庫,代碼在急劇的膨脹,相應的apk包的大小也急劇增加, 那麼終有一天,你會不幸遇到這個錯誤:

  1. 生成的apk在android 2.3或之前的機器上無法安裝,提示INSTALL_FAILED_DEXOPT
  2. 方法數量過多,編譯時出錯,提示:
     Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536

    而問題產生的具體原因如下:

    1. 無法安裝(Android 2.3 INSTALL_FAILED_DEXOPT)問題,是由dexopt的LinearAlloc限制引起的,在Android版本不同分別經歷了4M/5M/8M/16M限制,目前主流4.2.x系統上可能都已到16M, 在Gingerbread或者以下系統LinearAllocHdr分配空間只有5M大小的, 高於Gingerbread的系統提升到了8M。Dalvik linearAlloc是一個固定大小的緩沖區。在應用的安裝過程中,系統會運行一個名為dexopt的程序為該應用在當前機型中運行做准備。dexopt使用LinearAlloc來存儲應用的方法信息。Android 2.2和2.3的緩沖區只有5MB,Android 4.x提高到了8MB或16MB。當方法數量過多導致超出緩沖區大小時,會造成dexopt崩潰。

    2. 超過最大方法數限制的問題,是由於DEX文件格式限制,一個DEX文件中method個數采用使用原生類型short來索引文件中的方法,也就是4個字節共計最多表達65536個method,field/class的個數也均有此限制。對於DEX文件,則是將工程所需全部class文件合並且壓縮到一個DEX文件期間,也就是Android打包的DEX過程中, 單個DEX文件可被引用的方法總數(自己開發的代碼以及所引用的Android框架、類庫的代碼)被限制為65536;

      插件化? MultiDex?

      解決這個問題,一般有下面幾種方案,一種方案是加大Proguard的力度來減小DEX的大小和方法數,但這是治標不治本的方案,隨著業務代碼的添加,方法數終究會到達這個限制,一種比較流行的方案是插件化方案,另外一種是采用google提供的MultiDex方案,以及google在推出MultiDex之前Android Developers博客介紹的通過自定義類加載過程, 再就是Facebook推出的為Android應用開發的Dalvik補丁, 但facebook博客裡寫的不是很詳細;我們在插件化方案上也做了探索和嘗試,發現部署插件化方案,首先需要梳理和修改各個業務線的代碼,使之解耦,改動的面和量比較巨大,通過一定的探討和分析,我們認為對我們目前來說采用MultiDex方案更靠譜一些,這樣我們可以快速和簡潔的對代碼進行拆分,同時代碼改動也在可以接受的范圍內; 這樣我們采用了google提供的MultiDex方式進行了開發。

      插件化方案在業內有不同的實現原理,這裡不再一一列舉,這裡只列舉下Google為構建超過65K方法數的應用提供官方支持的方案:MultiDex。

      首先使用Android SDK Manager升級到最新的Android SDK Build Tools和Android Support Library。然後進行以下兩步操作:

      1.修改Gradle配置文件,啟用MultiDex並包含MultiDex支持:

        android {
          compileSdkVersion 21 buildToolsVersion 21.1.0
      
          defaultConfig {
              ...
              minSdkVersion 14
              targetSdkVersion 21
              ...
      
              // Enabling MultiDex support.
              MultiDexEnabled true
              }
              ...
          }
          dependencies { compile 'com.android.support:MultiDex:1.0.0'
      }

      2.讓應用支持多DEX文件。在官方文檔中描述了三種可選方法:

      在AndroidManifest.xml的application中聲明android.support.MultiDex.MultiDexApplication;
      如果你已經有自己的Application類,讓其繼承MultiDexApplication;
      如果你的Application類已經繼承自其它類,你不想/能修改它,那麼可以重寫attachBaseContext()方法:

      @Override 
      protected void attachBaseContext(Context base) {
          super.attachBaseContext(base);
          MultiDex.install(this);
      }

      並在Manifest中添加以下聲明:

       
          
              
              ...
              
          

      如果已經有自己的Application,則讓其繼承MultiDexApplication即可.

      Dex自動拆包及動態加載

      MultiDex帶來的問題

      在第一版本采用MultiDex方案上線後,在Dalvik下MultiDex帶來了下列幾個問題:

      1. 在冷啟動時因為需要安裝DEX文件,如果DEX文件過大時,處理時間過長,很容易引發ANR(Application Not Responding);
      2. 采用MultiDex方案的應用可能不能在低於Android 4.0 (API level 14) 機器上啟動,這個主要是因為Dalvik linearAlloc的一個bug (Issue 22586);
      3. 采用MultiDex方案的應用因為需要申請一個很大的內存,在運行時可能導致程序的崩潰,這個主要是因為Dalvik linearAlloc 的一個限制(Issue 78035). 這個限制在 Android 4.0 (API level 14)已經增加了, 應用也有可能在低於 Android 5.0 (API level 21)版本的機器上觸發這個限制;

        而在ART下MultiDex是不存在這個問題的,這主要是因為ART下采用Ahead-of-time (AOT) compilation技術,系統在APK的安裝過程中會使用自帶的dex2oat工具對APK中可用的DEX文件進行編譯並生成一個可在本地機器上運行的文件,這樣能提高應用的啟動速度,因為是在安裝過程中進行了處理這樣會影響應用的安裝速度,對ART感興趣的可以參考一下ART和Dalvik的區別.

        MultiDex的基本原理是把通過DexFile來加載Secondary DEX,並存放在BaseDexClassLoader的DexPathList中。

        下面代碼片段是BaseDexClassLoader findClass的過程:

        protected Class findClass(String name) throws ClassNotFoundException {
            List suppressedExceptions = new ArrayList();
            Class c = pathList.findClass(name, suppressedExceptions);
            if (c == null) {
                ClassNotFoundException cnfe = new ClassNotFoundException(Didn't find class  + name +  on path:  + pathList); 
                for (Throwable t : suppressedExceptions) {
                    cnfe.addSuppressed(t);
                }
                throw cnfe;
            }
            return c;
        }

        下面代碼片段為怎麼通過DexFile來加載Secondary DEX並放到BaseDexClassLoader的DexPathList中:

        private static void install(ClassLoader loader, List additionalClassPathEntries,
                                    File optimizedDirectory)
                throws IllegalArgumentException, IllegalAccessException,
                NoSuchFieldException, InvocationTargetException, NoSuchMethodException {
            /* The patched class loader is expected to be a descendant of
             * dalvik.system.BaseDexClassLoader. We modify its
             * dalvik.system.DexPathList pathList field to append additional DEX
             * file entries.
             */
            Field pathListField = findField(loader, pathList);
            Object dexPathList = pathListField.get(loader);
            ArrayList suppressedExceptions = new ArrayList();
            expandFieldArray(dexPathList, dexElements, makeDexElements(dexPathList,
                    new ArrayList(additionalClassPathEntries), optimizedDirectory,
                    suppressedExceptions));
            try {
                if (suppressedExceptions.size() > 0) {
                    for (IOException e : suppressedExceptions) {
                        //Log.w(TAG, Exception in makeDexElement, e);
                    }
                    Field suppressedExceptionsField =
                            findField(loader, dexElementsSuppressedExceptions);
                    IOException[] dexElementsSuppressedExceptions =
                            (IOException[]) suppressedExceptionsField.get(loader);
        
                    if (dexElementsSuppressedExceptions == null) {
                        dexElementsSuppressedExceptions =
                                suppressedExceptions.toArray(
                                        new IOException[suppressedExceptions.size()]);
                    } else {
                        IOException[] combined =
                                new IOException[suppressedExceptions.size() +
                                        dexElementsSuppressedExceptions.length];
                        suppressedExceptions.toArray(combined);
                        System.arraycopy(dexElementsSuppressedExceptions, 0, combined,
                                suppressedExceptions.size(), dexElementsSuppressedExceptions.length);
                        dexElementsSuppressedExceptions = combined;
                    }
        
                    suppressedExceptionsField.set(loader, dexElementsSuppressedExceptions);
                }
            } catch(Exception e) {
            }
        }

        Dex自動拆包及動態加載方案簡介

        通過查看MultiDex的源碼,我們發現MultiDex在冷啟動時容易導致ANR的瓶頸, 在2.1版本之前的Dalvik的VM版本中, MultiDex的安裝大概分為幾步,第一步打開apk這個zip包,第二步把MultiDex的dex解壓出來(除去Classes.dex之外的其他DEX,例如:classes2.dex, classes3.dex等等),因為android系統在啟動app時只加載了第一個Classes.dex,其他的DEX需要我們人工進行安裝,第三步通過反射進行安裝,這三步其實都比較耗時, 為了解決這個問題我們考慮是否可以把DEX的加載放到一個異步線程中,這樣冷啟動速度能提高不少,同時能夠減少冷啟動過程中的ANR,對於Dalvik linearAlloc的一個缺陷(Issue 22586)和限制(Issue 78035),我們考慮是否可以人工對DEX的拆分進行干預,使每個DEX的大小在一定的合理范圍內,這樣就減少觸發Dalvik linearAlloc的缺陷和限制; 為了實現這幾個目的,我們需要解決下面三個問題:

        1. 在打包過程中如何產生多個的DEX包?
        2. 如果做到動態加載,怎麼決定哪些DEX動態加載呢?
        3. 如果啟動後在工作線程中做動態加載,如果沒有加載完而用戶進行頁面操作需要使用到動態加載DEX中的class怎麼辦?

          我們首先來分析如何解決第一個問題,在使用MultiDex方案時,我們知道BuildTool會自動把代碼進行拆成多個DEX包,並且可以通過配置文件來控制哪些代碼放到第一個DEX包中, 下圖是Android的打包流程示意圖:

          /

          為了實現產生多個DEX包,我們可以在生成DEX文件的這一步中, 在Ant或gradle中自定義一個Task來干預DEX產生的過程,從而產生多個DEX,下圖是在ant和gradle中干預產生DEX的自定task的截圖:

          tasks.whenTaskAdded { task ->
              if (task.name.startsWith('proguard') && (task.name.endsWith('Debug') || task.name.endsWith('Release'))) {
                  task.doLast {
                      makeDexFileAfterProguardJar();
                  }
                  task.doFirst {
                      delete ${project.buildDir}/intermediates/classes-proguard;
          
                      String flavor = task.name.substring('proguard'.length(), task.name.lastIndexOf(task.name.endsWith('Debug') ? Debug : Release));
                      generateMainIndexKeepList(flavor.toLowerCase());
                  }
              } else if (task.name.startsWith('zipalign') && (task.name.endsWith('Debug') || task.name.endsWith('Release'))) {
                  task.doFirst {
                      ensureMultiDexInApk();
                  }
              }
          }

          上一步解決了如何打包出多個DEX的問題了,那我們該怎麼該根據什麼來決定哪些class放到Main DEX,哪些放到Secondary DEX呢(這裡的Main DEX是指在2.1版本的Dalvik VM之前由android系統在啟動apk時自己主動加載的Classes.dex,而Secondary DEX是指需要我們自己安裝進去的DEX,例如:Classes2.dex, Classes3.dex等), 這個需要分析出放到Main DEX中的class依賴,需要確保把Main DEX中class所有的依賴都要放進來,否則在啟動時會發生ClassNotFoundException, 這裡我們的方案是把Service、Receiver、Provider涉及到的代碼都放到Main DEX中,而把Activity涉及到的代碼進行了一定的拆分,把首頁Activity、Laucher Activity、歡迎頁的Activity、城市列表頁Activity等所依賴的class放到了Main DEX中,把二級、三級頁面的Activity以及業務頻道的代碼放到了Secondary DEX中,為了減少人工分析class的依賴所帶了的不可維護性和高風險性,我們編寫了一個能夠自動分析Class依賴的腳本, 從而能夠保證Main DEX包含class以及他們所依賴的所有class都在其內,這樣這個腳本就會在打包之前自動分析出啟動到Main DEX所涉及的所有代碼,保證Main DEX運行正常。

          隨著第二個問題的迎刃而解,我們來到了比較棘手的第三問題,如果我們在後台加載Secondary DEX過程中,用戶點擊界面將要跳轉到使用了在Secondary DEX中class的界面, 那此時必然發生ClassNotFoundException, 那怎麼解決這個問題呢,在所有的Activity跳轉代碼處添加判斷Secondary DEX是否加載完成?這個方法可行,但工作量非常大; 那有沒有更好的解決方案呢?我們通過分析Activity的啟動過程,發現Activity是由ActivityThread 通過Instrumentation來啟動的,我們是否可以在Instrumentation中做一定的手腳呢?通過分析代碼ActivityThread和Instrumentation發現,Instrumentation有關Activity啟動相關的方法大概有:execStartActivity、newActivity等等,這樣我們就可以在這些方法中添加代碼邏輯進行判斷這個Class是否加載了,如果加載則直接啟動這個Activity,如果沒有加載完成則啟動一個等待的Activity顯示給用戶,然後在這個Activity中等待後台Secondary DEX加載完成,完成後自動跳轉到用戶實際要跳轉的Activity;這樣在代碼充分解耦合,以及每個業務代碼能夠做到顆粒化的前提下,我們就做到Secondary DEX的按需加載了, 下面是Instrumentation添加的部分關鍵代碼:

              public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target,
                                                      Intent intent, int requestCode) {
                  ActivityResult activityResult = null;
                  String className;
                  if (intent.getComponent() != null) {
                      className = intent.getComponent().getClassName();
                  } else {
                      ResolveInfo resolveActivity = who.getPackageManager().resolveActivity(intent, 0);
          
                      if (resolveActivity != null && resolveActivity.activityInfo != null) {
                          className = resolveActivity.activityInfo.name;
                      } else {
                          className = null;
                      }
                  }
          
                  if (!TextUtils.isEmpty(className)) {
                      boolean shouldInterrupted = !MeituanApplication.isDexAvailable();
                      if (MeituanApplication.sIsDexAvailable.get() || mByPassActivityClassNameList.contains(className)) {
                          shouldInterrupted = false;
                      }
                      if (shouldInterrupted) {
                          Intent interruptedIntent = new Intent(mContext, WaitingActivity.class);
          
                          activityResult = execStartActivity(who, contextThread, token, target, interruptedIntent, requestCode);
                      } else {
                          activityResult = execStartActivity(who, contextThread, token, target, intent, requestCode);
                      }
                  } else {
                      activityResult = execStartActivity(who, contextThread, token, target, intent, requestCode);
                  }
          
                  return activityResult;
              }
          
              public Activity newActivity(Class clazz, Context context, IBinder token,
                                          Application application, Intent intent, ActivityInfo info,
                                          CharSequence title, Activity parent, String id, Object lastNonConfigurationInstance)
                      throws InstantiationException, IllegalAccessException {
          
                  String className = ;
                  Activity newActivity = null;
                  if (intent.getComponent() != null) {
                      className = intent.getComponent().getClassName();
                  }
          
                  boolean shouldInterrupted = !MeituanApplication.isDexAvailable();
                  if (MeituanApplication.sIsDexAvailable.get() || mByPassActivityClassNameList.contains(className)) {
                      shouldInterrupted = false;
                  }
                  if (shouldInterrupted) {
                      intent = new Intent(mContext, WaitingActivity.class);
                      newActivity = mBase.newActivity(clazz, context, token,
                              application, intent, info, title, parent, id,
                              lastNonConfigurationInstance);
                  } else {
                      newActivity = mBase.newActivity(clazz, context, token,
                              application, intent, info, title, parent, id,
                              lastNonConfigurationInstance);
                  }
                  return newActivity;
              }

          實際應用中我們還遇到另外一個比較棘手的問題, 就是Field的過多的問題,Field過多是由我們目前采用的代碼組織結構引入的,我們為了方便多業務線、多團隊並發協作的情況下開發,我們采用的aar的方式進行開發,並同時在aar依賴鏈的最底層引入了一個通用業務aar,而這個通用業務aar中包含了很多資源,而ADT14以及更高的版本中對Library資源處理時,Library的R資源不再是static final的了,詳情請查看google官方說明,這樣在最終打包時Library中的R沒法做到內聯,這樣帶來了R field過多的情況,導致需要拆分多個Secondary DEX,為了解決這個問題我們采用的是在打包過程中利用腳本把Libray中R field(例如ID、Layout、Drawable等)的引用替換成常量,然後刪去Library中R.class中的相應Field。

          總結

          上面就是我們在使用MultiDex過程中進化而來的DEX自動化拆包的方案, 這樣我們就可以通過腳本控制來進行自動化的拆分DEX,然後在運行時自由的加載Secondary DEX,既能保證冷啟動速度,又能減少運行時的內存占用。

           

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved