Research on the development of Android plugin--Basic article

On the development of Android plugin

The plugin for Android has been discussed for a long time, but there is no very mature plug-in framework available for us to use. Here we try to compare the Java, we use the plug-in is what kind of process, and how we will be porting this process to the Android framework to use. A lot of code is internal information, do not like to spray, thank you ~

Why plug-in?

• More and more functions
• Code, installation package is getting bigger
• Minor updates also need to be republished
• frequently updated, installation costs are too high
• Users cannot selectively load the required modules
• ......

Plug-in benefits

• The main installation package is small
• Forced modularity for reduced coupling
• Reduce the number of overall updates
• Plug-ins can be silently updated individually
• Users have a choice
• ......

Plug-in requirements

• No independent operation of the entrance
• Master app control, download, install, delete, silently upgrade, open and close
• Main app and plugin resource sharing

Composition of the installation package

Plugins that need to be installed

Comparing the composition of an installation package, we have to deal with a lot of things:

• The main app can launch specific plugins in intent mode, with the map type parameter or JSON string parameter
• Using the same Android:shareduserid, resource data sharing
• Search for plugins based on Shareduserid
• Queryintentactivities Find all activity (or other) plug-ins that match this action
• Query method can get the path of the plug-in and implement the class name of the interface class
• You can get a path by retrieving Shareduserid, but you can't get to the class name
• You can typically use a description file (XML, JSON) to describe the plug-in structure
• Createpackagecontext ()
• Getresourcesforapplication ()

load Normal class dynamically
-Java can dynamically load the. jar class file with ClassLoader, can Android?
-Pathclassloader
-Dexclassloader

Interface class

package com.plug;public interface InterfacePlug {    public String function_01();    public int function_02(int a,int b);}

Implementation class

import com.plug.InterfacePlug;public class PlugImpl  implements InterfacePlug{    @Override    public String function_01() {        return null;    }    @Override    public int function_02(int a, int b) {        return a+b;    }}

Main Application class

package com.host;public class MyhostActivity extends Activity {    public void useDexClassLoader() {        DexClassLoader cDexClassLoader =                new DexClassLoader("/mnt/sdcard/Myplugdex.jar", "/data/data/com.host", null, this.getClass()                        .getClassLoader());        try {            Class<?> class1 = cDexClassLoader.loadClass("com.plug.PlugImpl");            InterfacePlug interfacePlug = (InterfacePlug) class1.newInstance();            int ret = interfacePlug.function_02(12, 13);            tv.setText(" return value :" + ret);        } catch (Exception e) {        }    }}

You can export only the implementation class when you export the plug-in package, or it will appear

Classref in pre-verified class resolvedtounexpected implementation重复定义错误

Of course, the resolution of the installation package and plug-in installation is much more than the loading of class files, we also need:

• What if it's not a normal class?
• How does the system component receive callbacks?
• How do I load resources?
• PackageInfo processing?
• The treatment of resources?
• Assets's treatment?

Dynamically loading system components and resources

Pluginlib

Pluginhost

Plugintest

our simple plug-in framework is as follows:

The main app lists the installed plugins, click Start corresponding pluginactivity

Of course, we can also follow this simple mechanism to complete a complete plug-in system.

• Can basically complete an activity

• You can continue adding plugins for other components to complete more features (service,receiver,contentprovider,application?). ）

Disadvantages of this plug-in mechanism

• The information registered in the manifest is controlled by the system, so the plugin needs permission information to be pre-registered in the main program.
• There are some limitations to the implementation, such as the invocation of plug-in host and the mutual invocation between plugins.

Plugin Framework on GitHub, fragment-based open source plugin framework

• Https://github.com/mmin18/AndroidDynamicLoader
• UI based on Fragment
• reflect the resources
• Page jumps by URI

/*
* @author Zhoushengtao (Zhou San)
* @since January 27, 2015 14:02:22
* @weixin stchou_zst
* @blog http://blog.csdn.net/yzzst
* @ Exchange Learning QQ Group: 341989536
* @ Private qq:445914891
/

Research on the development of Android plugin--Basic article