• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

Android 重构方案

开发技术 开发技术 2周前 (09-12) 20次浏览

前言

最近面试了很多候选人,发现很多同学在简历上都写得非常厉害,负责架构设计,项目重构之类的。但是问起来,很多人都说不出个所以然来。今天我们不谈架构设计,我们聊一下重构。我面试时候经常会问,你是怎么重构的,从哪些方面入手。大部分的人基本上回答就是换一下网络请求的框架,图片处理的框架,好一些的能够说出一些MVP/MVVM,再好一点的能够说出一些模块化,组件化的东西。给我最大的感觉就是为了重构重构,或者是无中生有的重构,没有全面的思考过为什么要这样做。我们重构的目的就是为了让项目的可读性,可维护性,扩展性更强。后期其他同学接手,不至于把祖宗都问候一遍。刚好,最近我一直在维护一个2010年到现在的一个项目,谈一谈重构的过程。

1、注释, activity、fragment、类、方法 一定要有注释

每一个页面,类,方法,都要有对应的注释,写明作者是谁,时间,还有是做什么,这样对后面的同学梳理流程的时候,会顺畅很多。毕竟自己觉得自己写的代码很清晰,在其他人眼中就不一定是这样了。
activity:C:Program FilesAndroidAndroid StudiopluginsandroidlibtemplatesactivitiesEmptyActivityrootsrcapp_package
在头部添加

/**
 * @Description: 
 * @Author: huangjialin
 * @CreateDate: ${.now?string("yyyy-MM-dd")}
 */

普通类的,可以直接在studio中进行设置 settings — > File and Code Templates — >File Header 中添加

/**     
  * @Description:     java类作用描述 
  * @Author:         huangjialin
  * @CreateDate:     ${DATE} ${TIME}
  */

命名规范,统一,包括资源,java文件,布局,方法名,字段等等

这里推荐使用插件:Alibaba Java Coding Guidelines
要求:
1、(从命名上能够知道这个是activity,fragment还是adapter等等)
2、见其名,能知其意

在我重构的过程中,遇到很多这样的
Android 重构方案

这是直接从项目中进行截图的,我都不担心会出现什么泄密的情况。这样的命名,就只比使用A,B,C这样的命名好一点而已。好的命名基本上能够知道这个类,页面,方法是干什么的,对后面维护的同学也是非常友好的。

java文件命名,一定要做到见其名,知其意,即使名字长一些也是可以的,比如说aaaActivity ,aaaFragment…,这个aaa基本就是这个文件是做什么的。布局,方法名,字段这些,也是如此,但是命名的同时,也要注意编码规范。
针对于资源的命名,不光要能从名字中知道含义,还需要考虑后期组件化后,可能会产生的资源冲突
这里建议在module的build.gradle中添加

//给 Module 内的资源名增加前缀, 避免资源名冲突
resourcePrefix "${project.name.toLowerCase().replaceAll("-", "_")}_"   

这样给资源命名是会提示添加上对应module的前缀了。

3、工具类封装

Log,Toast,SharedPreferences,dialog,animation 等等等等,特别是对于经历过多人维护的项目,很多工具类都有很几套,一人弄一套,所以我们要做的就是统一,一个项目中不要出现多个重复的工具类,否则对于后期维护那是很困难的。

4、第三方jar的统一 如网络,图片等等

比如说我维护的这个项目,2010年写的到现在,光网络请求的就有四个,最早以前就是用HttpURLConnection,然后又有Volley,然后到Okhttp,接着就是Retrofit + okhttp,导致了现在一个很严重的问题,新人维护都不敢乱动,一直堆代码,当然,现在这样的请求是没事,但是如果后期,比如说需要更改域名,加密,在头部添加一些参数,等等等等 ,那倒霉的永远是最后一个接手的人。
当然这里需要注意两个问题
第一:不要一上来就直接全部替换,要循序渐进,直接全部替换,那么风险会非常大,对开发人员,测试人员,压力都会很大。
第二:既然要统一,那么选用个框架比较好?我个人的看法是首先是选择稳定性好的,性能好的,自己擅长的。

5、模块化->组件化,MVP/MVVM

做到这一步,多少对项目有些熟悉了,接下来要先做的是架构的分层还是代码的分离,取决于自身对项目的熟悉程度,如果项目中已经做了模块化,那么需要考虑的是以下几点:
1、此时的模块分离的粒度是否符合当前,可能当时分层的时候是合理的,但是随着业务的增加,是不是存在一些臃肿的代码,需不需要更加细致的分离。这个需要根据项目来决定的。
2、项目越大,那就考虑组件化,组件化是在模块化的基础上弄的,所以一定要先模块化在组件化。
3、组件化需要分层更加细致,比如第三方jar层,公共组件层,组件层,调试层等等,还需要考虑组件间的耦合,通信等,具体的可以专门去学习组件化。
4、插件化,如果做完组件化,在做插件化,那么插件化将会容易很多,同理,需不需要做插件化,根据公司项目来决定。

MVP/MVVM
这个主要是针对于代码的隔离,如果项目中已经使用了mvp,那就接着用mvp,不要因为一些东西出来了,比如现在Google强推一个jetpack,就马上换MVVM,那样风险是非常大的,如果都是allinone在一个activity,那么直接就使用MVVM来进行重构。LiveData + ViewModel优势是很大的。

组件化 + MVP + MVVM可参考:https://www.cnblogs.com/huangjialin/p/13086553.html

6、涉及模式的使用

到这一步,基本对整个项目都是有一个明显的认识了,到这里就要考虑业务了,需要考虑更多的是业务的扩展性好不好,可读性好不好,好不好维护了。在这里我们可以根据自己实际的项目来使用一些设计模式,比如单例,观察者,工厂,Build模式,策略模式 等等

7、网络数据结构重构

这个看公司业务来决定,这个处理的是后端返回的数据结构是否需要统一,这里看公司和前后端的情况来决定。毕竟这个改动,不光是前端改,也需要后端同学改动了,工作量大,风险很高。

8、性能优化:卡顿,内存,启动,布局优化,apk体积

到这一步,重构代码这部分,基本OK了,现在需要考虑的是应用的性能问题了,这里我列出来,我个人觉得从左到右 优先级由高到底 的顺序来处理,具体怎么做,参考这里。
卡顿优化:https://www.cnblogs.com/huangjialin/p/13389421.html
内存优化:https://www.cnblogs.com/huangjialin/p/13327949.html
启动优化:https://www.cnblogs.com/huangjialin/p/13292042.html
布局优化:https://www.cnblogs.com/huangjialin/p/13353541.html

9、文档输出

非常重要!!!非常重要!!!非常重要!!!
这一步没做好,很容易导致前面做的前功尽弃。所以需要一边重构,一边输出文档,后面接手的人,会感谢你的。

10、重构之路,任重而道远,需要定期重构。

除非非常大的重构,否则重构不需要特意排期,只要我们发现某个地方不合理,都可以进行重构,但是需要通知测试人员注意测试。重构之路,任重而道远 !!!!!!!!!!!!!!!!


程序员灯塔 , 版权所有
转载请注明原文链接:https://www.wangt.cc/2020/09/android-%e9%87%8d%e6%9e%84%e6%96%b9%e6%a1%88/
喜欢 (0)