移动端应用框架总结

做所有架构相关的事都是为提高开发效率,提高代码的复用性和扩展性。

一,模块化

架构一般会把整个App模块化,有点包括:

1、不只提高了代码的复用度,还可以实现真正的功能复用,比如同样的功能模块如果实现了自完备性,可以在多个app中复用

2、业务隔离,跨团队开发代码控制和版本风险控制的实现

3、模块化对代码的封装性、合理性都有一定的要求,提升开发同学的设计能力。

基础模块包括扫描模块,图片库模块,webiew 模块,网络模块,camerasdk 模块,分享模块等。这些都是可以跨app复用的。这样公司要开发一个新的app,就不用重新去写这些模块。

View组件模块包括平时常用的view组件,包括上拉下拉等,也是都可以跨app复用。

等app够大了之后,业务模块也要进行分离,像天猫,手淘,一个详情模块就要一个团队去负责。

二,解耦

分模块之后,业务模块间会互相引用,对于开发来说,虽然解决了代码的耦合问题,对于代码的引用关系却没有改变。模块多了之后,这个关系可以复杂成一个庞大的蜘蛛网,这对于后期维护来说,成本是巨大的。

解耦就是说A模块不直接引用B模块的代码,目前有两种方式:

  • middleman

  • urlRoute

(1)middleman

将所有的模块依赖这个middleman,让middleman来处理各个模块的关系,模块A如果需要依赖模块B,完全可以考middleman来处理,并且返回模块A所需要的模块B的内容,这样就解决了解耦。

(2)urlRoute

基本上现在很多的App架构里面都会有“统一跳转” 这一套东西的,包括天猫,手淘,这个不光是对模块解耦有帮助,对于统一化运营都是有极好的帮助的,比如app里面的任何页面,或者任何操作都是通过一个URL来唤起的话,这样是不是就把各个复杂的业务之间解耦了呢,通信都使用URL.

如果模块之间不是通过页面来联系,而是为了获取其他模块的功能,可以考虑service来完成解耦。

三,模块的设计

像基础模块和view模块会被其他业务模块依赖,所以设计的时候要注意接口保持稳定,模块的依赖上下层要清晰,越底下的模块需要越稳定。

一般不修改接口名称,通过新增接口来扩展新功能。

每个模块只做好一件事,不要出现大杂烩的情况。

使用第三方代码时,要自己进行封装成一个模块,这样一方面能统一处理异常,另一方面要替换时也无需修改其他地方的代码。

参考链接:

iOS移动端架构的那些事

模块化与解耦

Android APP架构心得

标签: none

评论已关闭