由客户端内部通讯引发的插件化开发的随想和实践

背景

最近在写一个基于Android的IPC实现的一个小工具，主要实现的就是能够在手机查看被监视程序的值的变化和日志等。因为用了入侵的方式，所以需要被监视APK集成一个SDK。程序界面一览:

大概还是一个半成品的样子，后续会写一些Root以后才有的功能。

遇到的问题

在实际的开发中，因为主程序中会包含各个集成SDK的Client端的数据，所以主程序的数据接受到最后UI的呈现，就面临了一个传输的选择。在客户端的开发中，我们解决内部的通信问题一般有三种方式：

• 基于事件总线（EventBus, PubSubEvent等）;
• 协议化（內建Server，接收方和发送方约定好数据格式）;
• 接口。

第一种方式极大的提高了我们的开发效率，但是后续带来整体代码的恶化简直是我们维护代码调试代码的灾难。第二种方式內建Server的话，确实很好的解决了我们耦合的问题，但是也带来了一些问题，其一是性能，数据模型的转换在频繁的通信中会带来性能的损耗，其二是开发效率，因为是协议传输，所以一方有变更，另一方也要做相应的变更。那第三种方式接口，因为本身是强引用，所以易于调试和维护，其次也没有数据模型的转换。所以我倾向于用接口去解决数据传输的问题。

过往的经验

在过往开发桌面端的经验中，我们大量运用依赖注入的方式来解决模块与模块的耦合问题，同时也可以用来解决模块与仓储之间传输数据的问题。这也是传统的桌面端开发中，插件式开发的经典实现。用之前写过的一个程序举个例子:

整个工程的结构是这样的：MailAccount作为主程序，MailAccount.Interface是MailAccount唯一的引用项，MailAccount.Extra.Trial和MailAccount.Extra.Standard是完全独立的dll的项目。

整个程序实现的效果是这样的，当MailAccount的exe文件运行时，如果目录下没有任何其他的dll，则不运行任何内容，只是一个空白页面，但是当目录下有Trial或者Standard任意一个dll时，则运行相应dll中的内容。

首先看下Trail和Standard的实现:

namespace MailAccount.Extra.Trial
{
    [Export("Trial", typeof(IUserAction))]
    public class UserTrial : IUserAction
    {
        public bool DoWork<T>(IEnumerable<T> source)
        {
            if(source.Count() > 5)
            {
                return false;
            }
            return true;
        }
    }
}

namespace MailAccount.Extra.Standard
{
    [Export("Standard", typeof(IUserAction))]
    public class UserStandard : IUserAction
    {
        public bool DoWork<T>(IEnumerable<T> source)
        {
            return true;
        }
    }
}

Trail和Standard都实现了IUserAction的接口，并对其中功能做了自己的具体实现。

再看下MailAccount中启动的时候做了什么：

public class Bootstrapper
    {
        private const string SEARCH_PATTERN = "MailAccount.Extra.*.dll";

        protected CompositionContainer MainContainer { get; private set; }

        public void Run()
        {
            Container container = this.CreateContainer();

            InfrastructureCatalog baseCatalog = this.CreateBaseCatalog();

            VarifyAndLoadBaseCatalog(baseCatalog, container);

            container.Configure();

            this.MainContainer = container.MainContainer;

            CreateMainWindow();
        }

        private Container CreateContainer()
        {
            return new Container();
        }

        private InfrastructureCatalog CreateBaseCatalog()
        {
            InfrastructureCatalog baseCatalog = new InfrastructureCatalog();
            baseCatalog.Add(this.GetType().Assembly);
            DirectoryInfo dirInfo = new DirectoryInfo(@".");
            foreach (FileInfo fileInfo in dirInfo.EnumerateFiles(SEARCH_PATTERN))
            {
                try
                {
                    baseCatalog.Add(fileInfo.FullName);
                }
                catch(Exception ex)
                {
                    LogHelper.Error(ex.Message);
                }
            }


            return baseCatalog;
        }

        private void VarifyAndLoadBaseCatalog(InfrastructureCatalog baseCatalog, Container container)
        {
            if (baseCatalog != null && baseCatalog.Items != null)
            {
                foreach (AssemblyCatalog catalog in baseCatalog.Items.Distinct())
                {
                    if (container.AggregateCatalog.Catalogs.FirstOrDefault(c => c.ToString() == catalog.ToString()) == null)
                    {
                        container.AggregateCatalog.Catalogs.Add(catalog);
                    }
                }
            }
        }

        public void CreateMainWindow()
        {
            MainWindow mainWindow = MainContainer.GetExportedValue<MainWindow>("MainWindow");

            IUserAction trial = null;
            IUserAction standard = null;

            try
            {
                trial = MainContainer.GetExportedValue<IUserAction>("Trial");
            }
            catch(Exception ex)
            {
                LogHelper.Error(ex.Message);
            }

            try
            {
                standard = MainContainer.GetExportedValue<IUserAction>("Standard");
            }
            catch (Exception ex)
            {
                LogHelper.Error(ex.Message);
            }

            if (standard != null)
            {
                mainWindow.userAction = standard;
            }
            else if(trial != null)
            {
                mainWindow.userAction = trial;
            }
            else
            {
                MessageBox.Show("程序验证失败");
                Environment.Exit(0);
            }

            Application.Current.MainWindow = mainWindow;
            Application.Current.MainWindow.Show();
        }
    }
}

在MailAccount启动时，我们初始化一个容器，然后遍历当前目录下的与MailAccount.Extra.*.dll能匹配的dll，在放入到容器中。因为我们在dll中显式的Export并声明了key为Standard，所以容器能够在MainContainer.GetExportedValue<IUserAction>("Standard")的时候找到这个类并初始化。当然我们也可以生成新的符合要求的dll，实现热拔插，当然这是后话。

Android中实践的前期准备

因为过往的经验，所以我在检索Android这边信息的时候，是尝试用插件化或者组件化这种字眼来搜索的。但是我却发现了一个有趣的现象，在Android这个圈子里，组件化或者插件化，大家都默认这个技术是用来实现热更新的，并且当我看了各个开源repo的开始文档后，发现总有各种限制或者缺陷，比如在特定手机上无法进行资源转换，不支持Activity(process、configChanges)的部分属性等等。总之真正的工程实践中会面临很多缺陷。

所以我放弃了这些开源repo，继续走依赖注入框架的方式。在Android的开发中，我们常用的依赖注入的框架其实有两个RoboGuice和Dagger。不过真正意义上讲，虽然Dagger2也叫Dagger，但是开发商变了（square->google），实现方式也变了（运行时反射->编译时生成），所以可以理解为我们其实有三个依赖注入的框架可选。在框架的选择上，我最终还是选择了Dagger2，原因有两个，第一个是大厂质量能保证，第二个是我不存在热拔插的需求，运行时编译生成能提高程序的运行效率。

实践

选择完依赖注入的框架后，我定义了整个程序的层次结构。每一个框都作为一个独立的Module存在，方便单独的Module的管理。那么我在Plugin这块是怎么实践的呢？假设我们要新增一个plugin，我需要做些什么？正如开始所说的，因为通信方式中，我选择了使用接口，所以我首先要定义一个接口。以出参监视功能为例，我需要定义一个IOutParaPlugin接口：

public interface IOutParaPlugin extends IPlugin {
    boolean isGathering();
    void setIsGathering(boolean isGathering);
    void registerOutPara(OutPara outPara);
    void setOutPara(OutPara outPara, String value);
    void clientDisconnect(String pkgName);
}

IPlugin是我们所有插件的接口类，其主要功能是提供功能的名称和功能入口UI：

public interface IPlugin {
    String getPluginName();
    Fragment getPluginFragment();
    ILBApp getApp();
}

这个定义的接口放置在我们的Abs的Module中，我们可以新建一个plugin.op的module来实现我们的功能。

除了实现了基本的Plugin的功能外，我们还要声明一个module的类来供Dagger生成编译时的信息。

@Module
public abstract class OutParaModule {
    @Provides
    @Named(AliasName.OUT_PARA_PLUGIN)
    @Singleton
    public static IOutParaPlugin provideOutParaPlugin(ILBApp app,
                                                      @Named(AliasName.OUT_PARA_BRIDGE) Lazy<UIOutParaBridge> outParaBridgeLazy) {
        return new OutParaPlugin(app, outParaBridgeLazy);
    }

    @Provides
    @Named(AliasName.OUT_PARA_BRIDGE)
    @Singleton
    public static UIOutParaBridge provideOutParaBridge(ILBApp app,
                                                       @Named(AliasName.CLIENT_MANAGER) IClientManager clientManager,
                                                       @Named(AliasName.OUT_PARA_PLUGIN) Lazy<IOutParaPlugin> outParaPluginLazy) {
        return new UIOutParaBridge(app, clientManager, outParaPluginLazy);
    }

    @PreActivity
    @ContributesAndroidInjector
    abstract OutParaDetailActivity outParaDetailActivityInjector();

    @PreFragment
    @ContributesAndroidInjector
    abstract OutParaFragment outParaFragmentInjector();
}

在Module中，我们定义了我们的OutParaPlugin在外部可以被注入，当然我们还给了它一个别名，当有多处注入不同实现IOutParaPlugin类时，我们可以用别名来区分。

定义完Module以后，我们要在主app中引用：

@Singleton
@Component(modules = {
        LBAppModule.class,
        ClientModule.class,
        OutParaModule.class,
        InParaModule.class,
        LogModule.class,
        FloatingModule.class
})
interface LBComponent extends AndroidInjector<LBApp> {
    @Component.Builder
    abstract class Builder extends AndroidInjector.Builder<LBApp> {

    }
}

这样，在主app的MainActiviy中我们可以这样引用：

@Inject @Named(AliasName.OUT_PARA_PLUGIN) IOutParaPlugin outPlugin;

在Activity被onCreate的时候注入并获取OutParaPlugin的实例：

@Override
protected void onCreate(Bundle savedInstanceState) {
    AndroidInjection.inject(this);
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    ButterKnife.bind(this);
    active = true;

    initPlugin(outPlugin, inPlugin, logPlugin);
    initDrawer();
    initFragment();

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
        requestDrawOverLays();
    }
}

此时，我们获取plugin后，可以用getPluginName()初始化侧滑栏的菜单，当用户点击时，再通过getPluginFragment()进入Plugin内部相关的UI。我们也可以实现新的IOutParaPlugin的module来快速替换现有的plugin。

总结

将工程插件化，是约束代码边界的一个很好的实践。将庞大的工程拆分成一个个子工程，从编译上做到隔离，将不同的工程交由不同的人负责，避免了相互之间代码更改，同时提高了代码的可维护性。

参考信息

微信Android模块化架构重构实践
Prism6下的MEF：第一个Hello World
Android Dagger (2.10/2.11) Butterknife MVP
Prism PubSub Event