拆分.png
简介
随着这几年项目逐渐维护周期越来越长,经历项目从开发,迭代,再到后期的维护.逐渐意识到在日常开发中,前期的架构对项目的重要性.一个好的架构,方便了后边的项目迭代维护.假如项目开始阶段没考虑到项目架构,单纯的写代码堆积功能.后期迭代起来简直爆炸,感觉就像沼泽地上跳舞(其实想说粪坑中跳舞来着)
从开始觉得什么架构不架构的就是刚代码堆起来,到哎呀Mvp ,Mvvm模式想啊用一用,再到后来项目真改不下去了.这时候的心态是,爆炸吧,哪个傻逼这样写的,一看作者是自己)然后自己看不下去了那就重构吧.然后默默的开始拆项目,拆着,着学习着...一步步的掉着头发,填着自己挖的坑.
叨叨结束进入正文.
现在写的项目大体上是基于模块化架构,拆分各种不同的业务,MVP+MVVM 拆分页面代码
思路
项目臃肿分为需求臃肿,耦合性高,和单页面臃肿耦合性高.这时候我做的答题思路是项目整体模块化,各个模块拆分解决业务逻辑的耦合臃肿,MVP+MVVM拆分单个页面的数据处理,页面展示.
1.项目拆分-->模块化
模块化 顾名思义就是将需求细分成一个个单独的模块,然后根据业务需求拼接成一个App.
拆分模块
基础模块
1.User数据信息模块
2.网络模块
3.Base模块(基类,统一风格展示)
4.通用模块(Util,路由跳转,事件分发)
5.数据持久化模块(DB/文件存储/Sp)
6.三方SDK模块(分享,登录,地图,支付...方便统一管理三方库)
业务模块
1.App主模块(启动的主模块用于挂载各种子模块)
2.图片/视频/文件处理模块(可再拆分个图片.视频展示的模块)
3.版本更新/广告/统计模块(需要定时更新的可以都放在这里)
4.其他的根据业务需要可以拆分成各个模块.什么电商,IM,直播等模块
2.页面拆分-->MVP/MVVM/LiveData
具体到某个页面的拆分现成的方案很多了,要么拆分数据请求和数据展示,要么将数据直接动态绑定到XML,或者就是LiveData 等各种方案让我们告别一个Activity上万行代码的情况.
现用方案:
MVP+MVVM:MVP拆分网络请求和数据绑定,MVVM简化findViewById()和动态绑定数据
3.扩展
模块化方案,各个模块之间调用,通讯怎么办呢?
我们项目中使用的是阿里开源方案 Arouter,有兴趣的小伙伴可以去看看.
另外原生观察者作为跨页面也挺方便的,EventBus 暂时我还没遇到非他不可得情况
总结
项目开发前期将业务和基础的各个模块拆分出来,虽然增加了工作量.但是项目后期迭代维护是真心的省事儿,让开发者专注业务的实现就可以了.各个模块相互不关联,有新需求了可以快速的拿各模块拼接成一个新App,So easy.
网友评论