Convert Figma logo to code with AI

CtripMobile logoDynamicAPK

Solution to implement multi apk dynamic loading and hot fixing for Android App. (实现Android App多apk插件化和动态加载,支持资源分包和热修复)

3,029
873
3,029
59

Top Related Projects

8,125

A powerful Android Dynamic Component Framework.

Android V1 and V2 Signature Channel Package Plugin

Quick Overview

DynamicAPK is a framework developed by Ctrip Mobile that enables dynamic loading of Android application components, allowing developers to update their apps without the need for a full app update. This approach can significantly reduce the app's size and improve the user experience.

Pros

  • Dynamic Loading: DynamicAPK allows developers to dynamically load and unload application components, reducing the initial app size and enabling faster updates.
  • Modular Design: The framework promotes a modular design approach, making it easier to manage and maintain different parts of the application.
  • Improved User Experience: By reducing the app size and enabling faster updates, DynamicAPK can improve the overall user experience.
  • Reduced Maintenance Costs: The dynamic loading feature can help reduce the costs associated with app updates and maintenance.

Cons

  • Complexity: Integrating DynamicAPK into an existing project may add complexity to the development process, requiring additional setup and configuration.
  • Potential Performance Impact: Dynamically loading components may have a slight performance impact, which needs to be carefully managed and monitored.
  • Dependency Management: Developers need to carefully manage the dependencies between the dynamically loaded components to ensure compatibility and stability.
  • Limited Platform Support: DynamicAPK is currently designed for Android platforms, and there may be limited support for other platforms.

Code Examples

Since DynamicAPK is a framework for Android, here are a few code examples demonstrating its usage:

// Initializing the DynamicAPK framework
DynamicAPK.init(this);

// Dynamically loading a module
DynamicAPK.loadModule("my_module", new DynamicAPK.ModuleLoadCallback() {
    @Override
    public void onModuleLoaded(Module module) {
        // Module is now loaded and ready to use
    }

    @Override
    public void onModuleLoadFailed(Exception e) {
        // Handle module load failure
    }
});

// Unloading a module
DynamicAPK.unloadModule("my_module");

// Checking if a module is loaded
boolean isModuleLoaded = DynamicAPK.isModuleLoaded("my_module");

These examples demonstrate how to initialize the DynamicAPK framework, dynamically load and unload modules, and check the load status of a module.

Getting Started

To get started with DynamicAPK, follow these steps:

  1. Add the DynamicAPK dependency to your project's build.gradle file:
dependencies {
    implementation 'com.ctrip.android:dynamic-apk:1.0.0'
}
  1. Initialize the DynamicAPK framework in your application's onCreate() method:
public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        DynamicAPK.init(this);
    }
}
  1. Integrate DynamicAPK into your app's architecture by defining and managing your application's modules. Refer to the DynamicAPK documentation for detailed instructions on how to do this.

  2. Utilize the DynamicAPK API to dynamically load and unload modules as needed, as shown in the code examples above.

Competitor Comparisons

8,125

A powerful Android Dynamic Component Framework.

Pros of Atlas

  • Atlas provides a more comprehensive solution for dynamic loading and hot-patching, including support for resources, native libraries, and other assets.
  • Atlas has a larger and more active community, with more contributors and a wider range of use cases.
  • Atlas offers better performance and stability, with a more mature and optimized codebase.

Cons of Atlas

  • Atlas has a steeper learning curve and requires more configuration and setup compared to DynamicAPK.
  • Atlas may be overkill for simpler use cases, where DynamicAPK could be a more lightweight and easier-to-use solution.
  • Atlas has a larger codebase and dependency footprint, which could be a concern for some projects.

Code Comparison

DynamicAPK:

public class DynamicApkManager {
    public static void loadDynamicApk(Context context, String apkPath) {
        try {
            AssetManager assetManager = context.getAssets();
            Method addAssetPath = assetManager.getClass().getMethod("addAssetPath", String.class);
            addAssetPath.invoke(assetManager, apkPath);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Atlas:

public class AtlasUpdater {
    public static void update(Context context, String apkPath) {
        try {
            AtlasDelegate.getInstance().update(context, apkPath);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

The key difference is that Atlas provides a more comprehensive and abstracted API for dynamic loading, while DynamicAPK has a more direct and lower-level approach.

Android V1 and V2 Signature Channel Package Plugin

Pros of VasDolly

  • VasDolly supports dynamic loading of resources, which can reduce the initial APK size and improve the app's startup performance.
  • VasDolly provides a plugin-based architecture, allowing developers to easily integrate new features without modifying the core codebase.
  • VasDolly has a well-documented API and a large community, making it easier to get started and find support.

Cons of VasDolly

  • VasDolly may have a steeper learning curve compared to DynamicAPK, as it requires a deeper understanding of the plugin-based architecture.
  • VasDolly may have a larger codebase and dependencies, which could potentially increase the overall complexity of the project.

Code Comparison

DynamicAPK:

public class DynamicApkManager {
    public static void loadDynamicApk(String apkPath) {
        // Load the dynamic APK
        DexClassLoader classLoader = new DexClassLoader(apkPath, getCacheDir().getAbsolutePath(), null, getClassLoader());
        // Invoke the entry point of the dynamic APK
        Class<?> entryClass = classLoader.loadClass("com.example.dynamic.EntryPoint");
        Method entryMethod = entryClass.getMethod("main", String[].class);
        entryMethod.invoke(null, new Object[] { new String[0] });
    }
}

VasDolly:

public class VasDollyManager {
    public static void loadPlugin(String pluginPath) {
        // Load the plugin
        PluginManager.getInstance().loadPlugin(pluginPath);
        // Invoke the entry point of the plugin
        PluginManager.getInstance().invokePlugin("com.example.plugin.EntryPoint", "main", new Object[0]);
    }
}

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Introduction

What is DynamicAPK?

DynamicAPK is a solution that contains framework, tool and configuration to implement multi apk/dex dynamic loading. It can help reorganize Android project configuration and development model to achieve sub-projects parallel development (in the form of android studio module), while supporting hot fix (repairing online bug), on-demand loading seldom-used modules. All dynamically loaded modules not only contain code but also contain resources if you need.

DynamicAPK is already uesed in Ctrip Android App (Simplified Chinese Version). Ctrip is the biggest online travel agency in China, while 72 percent of orders are from App.

Benefits

  • Less transformation effort (no activity/fragment/resource proxy stuff)

    DynamicAPK doesn't need activity or fragment proxy to manage their life cycle. Modules' resources are processed by modified aapt, so resource reference in R.java is not different with normal Android project. Developers can maintain their original development paradigm.

  • Parallel development

  • Speed up compilation

  • Speed up app booting

    MultiDex solution offered by Google will execute dex decompression, dexopt, load operation in the main thread. That means a very long process, while users will see significant long black screen and more likely to encounter the ANR. By DynamicAPK, app loads only the necessary modules, other modules are loaded on demand.

  • Hot fix (code and resource)

  • On-demand module (code and resource) downloading and loading

Comparasion

  • DynamicLoadApk

    Heavy develpment paradigm transformation: use "that" instead of "this", activity should inherit from their proxy avtivity (The proxy activity manage life cycle).

    Restrictions of starting activity within module apk.

    Doesn't support Service and BroadcastReceiver.

  • AndroidDynamicLoader

    Heavy develpment paradigm transformation:

    Changes the usage of resources: MyResources.getResource(Me.class) instead of context.getResources().

    Use Fragment as UI container, each page is implemented in Fragment instead of Activity. So you need use URL mapping to start new page.

  • android-pluginmgr

    Not tested in released App.

    Doesn't support Service and BroadcastReceiver.

  • DroidPlugin from Qihu360

    Very interesting framework! DroidPlugin can start totally independent app (not installed) in your app. The features are more suitable for Qihu360 security app because the bundle apk is totally irrelevant to host apk.

    Doesn't support custom nitification.

Implementation

Android Build Process

We focus on aapt, javac, proguard and dex process. The key of dynamic loading is about two things:

Code compilation and loading

Java compilation is nothing special, while class loading needs some hacking. Android's DexClassLoader has some restrictions, so we use Android's system PathClassLoader. PathClassLoader has a member pathList, as the name suggests it is essentially a List to load classes from each dex path in the list at runtime. So we can add our dynamically loaded dex at the head of the list. In fact, Google's official MultiDex library is also implemented by the method. The following snippet shows the details:

MultiDex.java

private static void install(ClassLoader loader, List<File> 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);
    expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList,
         new ArrayList<File>(additionalClassPathEntries), optimizedDirectory));
}

For different versions of Android, class loading has a slightly different way. Reference [MultiDex Source] (https://android.googlesource.com/platform/frameworks/multidex/+/d79604bd38c101b54e41745f85ddc2e04d978af2/library/src/android/support/multidex/MultiDex.java).

Resource compilation and loading

Resource compilation is proceesed by Android tool: aapt, which is located in <SDK> / build-tools / <buildToolsVersion> / aapt, with many [command line parameter] (http: //7xns6i.com1.z0 .glb.clouddn.com / ctrip-pluggable / aapt.txt "aapt Command Line Reference"). Some of them deserve special attention:

  • -I Add an existing package to base include set

    This parameter is to add an existing package in the dependency path. In Android, the compilation of resources also need rely on android.jar. "android.jar" is not an ordinary jar package, which contains the existing SDK library class, compiled resources and resource index file (resources.arsc). Similarly, we can also use this parameter references an existing apk packages as dependencies resources to participate in the compilation.

  • -G A file to output proguard options into.

    In resource compilation, component class and method references will result in runtime reflection invocation, so this kind of symbol can not be confused. -G parameter will derive classes and interfaces found in the resource compilation process that must be kept. It will participate to the confusion in the late stage as an additional configuration file.

  • -J Specify where to output R.java resource constant definitions

    In Android, all resources will be generated as corresponding constant ID, the ID will be merged to R.java file. Resource ID in R.java is a four-byte int type. Actually it consists of three fields. The first byte represents the package, the second byte represents type, three and four bytes represent real ID. E.g:     

    //android.jar resources, PackageID is 0x01
    public static final int cancel = 0x01040000;
    

     // User app resources, PackageID is 0x7F public static final int zip_code = 0x7f090f2e; ```

We modifed aapt to provide each module different PackageID, so there will be no conflict.
  • To add new aapt --apk-module parameter.

    As previously mentioned, we specified for each module project unique PackageID field, so we can find where to find and load resources. In the resource loading section there will be more details.    

  • To add new aapt --public-R-path parameter.

    Android system resources can be referenced by its fully qualified name android.R to refer specific source. If we use base.package.name.R for modules to refer public app common resources, that means we need modify every existed resource reference code. It's error-prone and less transparent in the future development. We add --public-R-path parameter to specify base.R's location and make copy of common resource ID into modules' R.java.

Resource loading is processed by AssetManager and Resources class. We can access them in the Context.

Context.java

/** Return an AssetManager instance for your application's package. */
public abstract AssetManager getAssets();

/** Return a Resources instance for your application's package. */
public abstract Resources getResources();

They are two abstract methods, implementation is in ContextImpl class. After initialization of ContextImpl class objects, each subclass of Context such as Activity, Service and other components can access resources by these two methods.

ContextImpl.java

private final Resources mResources;

@Override
public AssetManager getAssets() {
   return getResources().getAssets();
}

@Override
public Resources getResources() {
   return mResources;
}

Since we allocate PackageID (the first byte of resource ID) by aapt to know where to find resource's apk, we override these two methods to find specific resource.

And there is a hidden method addAssetPath in AssetManager, so we can add a resource path to AssetManager.

/ **
* Add an additional set of assets to the asset manager. This can be
* Either a directory or ZIP file. Not for use by applications. Returns
* The cookie of the added asset, or 0 on failure.
* {hide}
* /
public final int addAssetPath(String path) {
   synchronized(this) {
       int res = addAssetPathNative(path);
       makeStringBlocks(mStringBlocks);
       return res;
   }
}

We just need to reflect this method, then add all apk's location to AssetManager. AssetManager will finish the resource loading by compiled resources.arsc resources within apk.

To achieve "seamless" experience, we need last step: using the Instrumentation to take over all creation of Activity , Service and other components. Activity, Service and other system components will be loaded in the main thread by android.app.ActivityThread. ActivityThread class has a member mInstrumentation, that is responsible for creating Activity and other operations. So it's the best candidate for loading our modified resource class. Every time the system creates Activity, we replace its mResources by our DelegateResources that will know how to load resources. Done!

Usage

aapt

  • Use parameter --apk-module to allocate packageID

    E.g: ex: aapt ...... --apk-module 0x58 (PackageID in ResourceID is 0x58)

  • Use parameter --public-R-path to merge R.java (RMerge.cpp)

    Then the output R file contains the base apk R.java and the module apk R.java.

Build

Simplified Chinese Version

介绍

DynamicAPK是一套用于实现多dex/apk加载的解决方案。它可以帮助你重新组织Android工程的配置和开发模式,实现多个子工程并行开发(以android studio module的形式),同时支持hot fix(在线修复有问题的功能), 插件式载入不常用的功能(下载插件后再载入)。所有动态加载的插件不仅包含代码,也可以包含资源(资源的动态加载比代码要麻烦很多),因此是以APK形式实现的。

DynamicAPK已经在携程旅行Android App中使用,欢迎关注携程移动技术公众号:CtripMobile

价值

  • 更少的迁移成本(无需做任何activity/fragment/resource的proxy实现)

    DynamicAPK不需要实现任何activity或fragment proxy来管理他们的生命周期。修改后的aapt会处理插件中的资源,因此R.java中的资源引用和普通Android工程没有区别。开发者可以保持原有的开发范式,无需做特殊的更改。

  • 并发开发

  • 提升编译速度

  • 提升启动速度

    Google提供的MultiDex方案,会在主线程中执行所有dex的解压、dexopt、加载操作,这是一个非常漫长的过程,用户会明显的看到长久的黑屏,更容易造成主线程的ANR,导致首次启动初始化失败。DynamicAPK可以在App启动时仅加载必须的模块,其他模块按需加载。

  • Hot fix (包含代码和资源)

  • 按需下载和加载任意功能模块(包含代码和资源)

对比

  • DynamicLoadApk

    迁移成本很重:需要使用『that』而不是『this』,所有activity都需要继承自proxy avtivity(proxy avtivity负责管理所有activity的生命周期)。

    无法启动apk内部的activity。

    不支持Service和BroadcastReceiver。

  • AndroidDynamicLoader

    迁移成本很重:

    使用资源时要用MyResources.getResource(Me.class)而不是context.getResources()

    使用Fragment作为UI容器,所有每个页面都是使用Fragment而不是Activity,需要使用URL mapping才能实现页面跳转。

  • android-pluginmgr

    未经过生产环境App测试。

    不支持Service和BroadcastReceiver。

  • DroidPlugin from 奇虎360

    非常有趣的框架!DroidPlugin能够在一个App内启动一个没有安装的App。这个特性可能更适合360的安全产品,因为被启动的App和宿主App完全没有任何关联,相互间不能支持资源和代码调用。

    不支持自定义推送栏。

实现细节

更深入的分析文章详见 InfoQ -《携程Android App插件化和动态加载实践》

使用方法

aapt

  • 使用参数 --apk-module 来分配PackageID

    E.g: ex: aapt ...... --apk-module 0x58 (ResourceID的PackageID定义为0x58)

  • 使用个参数 --public-R-path 来合并R.java (实现文件在RMerge.cpp中)

    生成的R.java文件会合并基础APK和模块APK中的R.java。

Build