Android 项目代码重构思想总结

代码重构的根本思想是模块化、灵活性、高内聚、低耦合。

Android 项目代码重构:

将与业务逻辑无关的公共基本资源、工具类等等抽取到一个lib 工程中,主程序中只放与业务逻辑相关的代码和工具类:

1、将公共资源类进行抽取,包括:

string.xml

color.xml

styel.xml

drable  中自定义的shap 、selector、anim

这些资源基本是和程序业务逻辑无关的,将其放到主工程中只会增加代码量影响对程序业务逻辑的理解。

工程项目所特有的资源可以采取继承于lib库工程中资源,对特有部分进行覆盖,例如lib工程style 中定义基础 的button 形状 包括默认大小、默认背景、文字大小等,主工程中定义特有style 时现继承于lib工程中style 再根据实际需求覆盖其中的元素如文字颜色、背景颜色等。定义好后,工程中再统一以此作为base style 直接引用 或者 再进行深一层细化定制。

抽取过程中 如果发现是比较有益的 可以公用的东西尽量往上一层抽取 ,只要是与工程无关的尽量抽取到lib 工程中,开发过程前期可能耗费更多精力,但当一个项目下来,你除了收获项目相关的经验外,还拥有了一个与项目无关的、强大的基本资源库,进行新项目开发时,你可以基于一个已经不断优化过的基础资源库进行开发,很多低层次代码、工作不再需要重复性劳动。

ps:个人对UI设计的一点见解:

在精力允许的情况下,能自己xml实现的效果尽量不要使用美工切图。比如按钮、渐变背景、纯色背景等等、都可以自己去画。

使用切图严重依赖美工的个人素质和切图质量 且会增大应用的体积,在后期更改程序风格配色时需要替换切图调整,而假如以上资源使用自己定义的背景xml 资源 只需更改颜色字段即可调整应用配色、风格。

如果让我自己做一个应用,我最理想的效果就是 程序资源中只有一张图,那就是桌面图标,当然只是理想状态、一般的应用 还是有一些特殊的图标或者难以实现的效果需要使用切图。

但作为开发人员,我感觉应尽量减少对美工、对切图的依赖。

我喜欢的一个理念:

No design is the best design。

2、将与程序逻辑无关的工具类进行抽取:

比图 BitmapUtils、Toast工具类、log工具类、时间工具类等等,总之,遵循一个Top原则:与程序业务逻辑无关的工具类,都抽取到lib工程中。

一个项目做完的时候,你收获的不止有业务处理经验,还有一个强大的工具类库。你的编程经验、理念的提升可以使你在做一个新项目时从架构上更合理,而工具类的抽取可以使你再开启一个新项目时不必再重复那些低端的重复劳动,基本类库你都有、你需要关注的只是这个程序的业务逻辑、只需关注程序的业务与上一个有什么不同。

总之,项目重构完之后,理想的状态是:

项目主工程中,所放的资源、工具类是继承于基础lib工程,但只与该项目相关的,所有与程序业务逻辑程序界面风格等无关的基础资源和工具类都在Lib工程中。减少重复性劳动、减少对美工切图的依赖、将基础资源真正抽取出来,主工程只关注业务逻辑。

未完待续。。。。。

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-17 18:08:28

Android 项目代码重构思想总结的相关文章

Arcgis For Android项目代码proguard混淆问题总结

一.普通Android项目代码混淆(项目中不包含第三方类库) 步骤1:在project.properties文件中,把下面这段话注释去掉: proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt 二.对于Arcgis For Android项目进行混淆时,由于使用arcgis的第三方类库,对项目混淆时需要对第三方类库进行排除. 步骤1:在project.properties文件中,把下

Android项目代码混淆

项目根目录有两个文件: 1.project.properties # This file is automatically generated by Android Tools. # Do not modify this file -- YOUR CHANGES WILL BE ERASED! # # This file must be checked in Version Control Systems. # # To customize properties used by the Ant

android 项目代码的优化

不使用getter 和setter,虚方法调用的代价比直接字段访问高昂许多 cursor的及时关闭 注意使用static final修饰常量 http用gzip压缩 convertview的复用以及ViewHolder的使用 必要的异步任务 加载页面时,耗时的任务放在异步任务中进行 图片的缓存机制 打包后用zipalign进行对齐

使用Jenkins进行android项目的自动构建(3)

建立Jenkins项目 1. "新增作业"->填写作业名称->选择"建置 Maven 2 或 3 專案"->OK.新增成功后会进入"組態設定",暂时先保留默认值,稍后再进行设定. 2. 按一下"马上建置",会显示"已排入建置",然后在"建置歷程"会见到#1的链接,点入该链接并选择"終端機輸出",这时会见到一个失败的构建记录.当然会失败,因为我们还未为

Android项目导入工程Module

在Android开发过程中,我们经常引用一些模块,或者自己封装好的Project.在Android Studio某个项目是可以引入多个Module的.这样导入Module的好处方便对源码修改以适合自己的需求. 常见: 从github下载的Android项目代码,一般都会有Example的使用样例,和工具的封装模块. eg. 在本项目中导入MPAndroidChart下的MPChartLibM Module, 可以进行如下操作: File -> New -> Import Module ->

Android 项目重构之路:实现篇

前两篇文章<Android项目重构之路:架构篇>和<Android项目重构之路:界面篇>已经讲了我的项目开始搭建时的架构设计和界面设计,这篇就讲讲具体怎么实现的,以实现最小化可用产品(MVP)的目标,用最简单的方式来搭建架构和实现代码. IDE采用Android Studio,Demo实现的功能为用户注册.登录和展示一个券列表,数据采用我们现有项目的测试数据,接口也是我们项目中的测试接口. 项目搭建 根据架构篇所讲的,将项目分为了四个层级:模型层.接口层.核心层.界面层.四个层级之

Android 项目重构之路:架构篇

去年10月底换到了新公司,做移动研发组的负责人,刚开始接手android项目时,发现该项目真的是一团糟. 首先是其架构,是按功能模块进行划分的,本来按模块划分也挺好的,可是他却分得太细,总共分为了17个模块,而好几个模块也就只有两三个类而已.但应用本身其实比较简单,要按功能模块来分的话,最多五个模块就够了. 另外,有好多模块划分也很模糊,也有很多类按其功能其实可以属于多个模块的,也有些类定义不明确,做了不该做的事.有时候,我要找一个界面的Activity,按照其功能应该属于A模块的,可是在A模块

Android 项目重构之路:界面篇

在前一篇文章<Android项目重构之路:架构篇>中已经简单说明了项目的架构,将项目分为了四个层级:模型层.接口层.核心层.界面层.其中,最上层的界面,是变化最频繁的一个层面,也是最复杂最容易出问题的一个层面,如果规划不好,很容易做着做着,又乱成一团了. 要规划好界面层,至少应该遵循几条基本的原则: 保持规范性:定义好开发规范,包括书写规范.命名规范.注释规范等,并按照规范严格执行: 保持单一性:布局就只做布局,内容就只做内容,各自分离好:每个方法.每个类,也只做一件事情: 保持简洁性:保持代

(转)Android项目重构之路:实现篇

前两篇文章Android项目重构之路:架构篇和Android项目重构之路:界面篇已经讲了我的项目开始搭建时的架构设计和界面设计,这篇就讲讲具体怎么实现的,以实现最小化可用产品(MVP)的目标,用最简单的方式来搭建架构和实现代码. IDE采用Android Studio,Demo实现的功能为用户注册.登录和展示一个券列表,数据采用我们现有项目的测试数据,接口也是我们项目中的测试接口. 项目搭建 根据架构篇所讲的,将项目分为了四个层级:模型层.接口层.核心层.界面层.四个层级之间的关系如下图所示: