android 业务解耦
当一个超级android应用由几个甚至几十个大模块组成,需要几十个人同时开发时,业务模块间的低耦合,模块内部高内聚显得尤为重要。提高代码可读性,提高团队之间的协同开发是大家绕不开的话题。在经历了几个比较大型的项目之后,对业务模块解耦的个人心得做个总结。业务解耦主要从下几个层面进行:
一、方法解耦
类中包含的成员方法是业务逻辑的最基本的单元,方法解耦是最低层面的解耦。遵循的基本原则:“一个方法只干一件事情“。不要在一个方法内部再去调另外一个方法,当内部方法使用较多时需要在方法内部做太多的逻辑判断。
二、层次解耦
大家经常采用,mvp,mvc,mvvm架构。mvc其实很难做到层次分明,在业务不复杂的情况下,可以使用。当业务过于复杂时,建议采用MVP(虽然有那么些诟病),层次之间的调用可采用回调方式,不建议采用反射或者类似EventBus的做法,主要是多次的反射调用导致性能问题,另外一个是层次之间调用关系松散,降低代码可读性。
三、功能模块内解耦
1、当一个页面较为复杂时,可以将页面按功能模块拆成多个功能组件,考虑性能问题,功能组件可以采用ViewStub,在使用的时候进行渲染,当然也可以采用Fragment(注意规避多个坑),每个功能组件又可以按层次解耦,比如实现MVP模式。
2、当多个功能业务有重合部分,可抽离公共部分做基础类,各个业务继承基础类
四、功能模块间解耦
1、当业务较为复杂时,大家通常的思路是组件化模块化。可以采用事物总线模型,将各个业务模块抽离接口给其他模块调用。或者采用第五种方式进行解耦。
五、插件之间的解耦
1、可以采用注解的方式将需要暴露给第三方调用的方法,被注解的方法将以注册的方式获取到 方法的定义放到map里,其他插件将以反射的方式进行调用。这里的反射调用并不频繁,对性能影响不大。需要在合适的时候进行注册,以及移除,比如可以在activity的onCreate里注册,在onDestory里进行反注册,这样减少map里方法的数量,避免类被释放造成的调用失败以及list的内存增长。
网友评论