android 业务解耦

android 业务解耦

当一个超级android应用由几个甚至几十个大模块组成，需要几十个人同时开发时，业务模块间的低耦合，模块内部高内聚显得尤为重要。提高代码可读性，提高团队之间的协同开发是大家绕不开的话题。在经历了几个比较大型的项目之后，对业务模块解耦的个人心得做个总结。业务解耦主要从下几个层面进行：

一、方法解耦

类中包含的成员方法是业务逻辑的最基本的单元，方法解耦是最低层面的解耦。遵循的基本原则：“一个方法只干一件事情“。不要在一个方法内部再去调另外一个方法，当内部方法使用较多时需要在方法内部做太多的逻辑判断。

二、层次解耦

大家经常采用，mvp,mvc，mvvm架构。mvc其实很难做到层次分明，在业务不复杂的情况下，可以使用。当业务过于复杂时，建议采用MVP（虽然有那么些诟病），层次之间的调用可采用回调方式，不建议采用反射或者类似EventBus的做法，主要是多次的反射调用导致性能问题，另外一个是层次之间调用关系松散，降低代码可读性。

三、功能模块内解耦

1、当一个页面较为复杂时，可以将页面按功能模块拆成多个功能组件，考虑性能问题，功能组件可以采用ViewStub，在使用的时候进行渲染，当然也可以采用Fragment(注意规避多个坑),每个功能组件又可以按层次解耦，比如实现MVP模式。

2、当多个功能业务有重合部分，可抽离公共部分做基础类，各个业务继承基础类

四、功能模块间解耦

1、当业务较为复杂时，大家通常的思路是组件化模块化。可以采用事物总线模型，将各个业务模块抽离接口给其他模块调用。或者采用第五种方式进行解耦。

五、插件之间的解耦

1、可以采用注解的方式将需要暴露给第三方调用的方法，被注解的方法将以注册的方式获取到 方法的定义放到map里，其他插件将以反射的方式进行调用。这里的反射调用并不频繁，对性能影响不大。需要在合适的时候进行注册，以及移除，比如可以在activity的onCreate里注册，在onDestory里进行反注册，这样减少map里方法的数量，避免类被释放造成的调用失败以及list的内存增长。