你的位置:首页 > 软件开发 > 操作系统 > Android 项目重构之路:界面篇

Android 项目重构之路:界面篇

发布时间:2015-11-19 19:01:32
在前一篇文章《Android项目重构之路:架构篇》中已经简单说明了项目的架构,将项目分为了四个层级:模型层、接口层、核心层、界面层。其中,最上层的界面,是变化最频繁的一个层面,也是最复杂最容易出问题的一个层面,如果规划不好,很容易做着做着,又乱成一团了。要规划好界面层,至少应该遵 ...

在前一篇文章《Android项目重构之路:架构篇》中已经简单说明了项目的架构,将项目分为了四个层级:模型层、接口层、核心层、界面层。其中,最上层的界面,是变化最频繁的一个层面,也是最复杂最容易出问题的一个层面,如果规划不好,很容易做着做着,又乱成一团了。

要规划好界面层,至少应该遵循几条基本的原则:

  1. 保持规范性:定义好开发规范,包括书写规范、命名规范、注释规范等,并按照规范严格执行;
  2. 保持单一性:布局就只做布局,内容就只做内容,各自分离好;每个方法、每个类,也只做一件事情;
  3. 保持简洁性:保持代码和结构的简洁,每个方法,每个类,每个包,每个文件,都不要塞太多代码或资源,感觉多了就应该拆分。

规范性

每个人的编码习惯和风格都不同,不说那些缺乏良好编码习惯的开发人员,就连那些已经养成良好编码习惯的人员,很多方面都会不同。比如缩进,有的喜欢4个空格,有的喜欢两个空格;比如变量名,有的喜欢m开头,例如mValue,有的喜欢直接就命名为value。如果不设定好规范,让每个人都按照自己的习惯和风格去编码,久了肯定乱,尤其当团队中存在还没养成良好编码习惯的人员时,更容易乱。所谓无规矩不成方圆,若无规范,久必乱。定义好规范,才能统一风格,才可提高代码可读性,同时也提高了维护性,还减低了引入bug的机会。

开发规范并没有统一的标准,在这里,我只是根据自己的经验对一些点提供一点建议,仅供参考。

  • 缩进

    很多人都习惯用Tab缩进,不管是规范4个空格还是2个空格,统一设置好Tab缩进的size就好了,这样就不用让每个人都去敲空格。

  • 命名

    一个好的命名,一眼就可以从名字中看到它是干嘛的,做什么用,什么类型等等。举个id命名的例子,看到有些团队喜欢将一些控件缩写,比如TextView缩写为tv,ListView缩写为lv,这种缩写倒是挺简洁的,但是并不能一眼就能看出它是什么,对于不熟悉的人来说,谁知道tv和lv是什么啊,还不如用text和list更明确些。我喜欢的id命名结构为:控件_范围_功能,例如:edit_login_password,这是一个登录页的密码输入框。

  • 单位

    文字大小的单位应该统一用sp,其他元素用dp。因为这两个单位是与设备分辨率无关的,能够解决在不同分辨率设备上显示效果不同的问题。另外,SDK里面,对文字大小系统默认是用sp单位的,但其他元素单位默认却不是dp,而是px的,同时也没有提供dp的设置接口,所以,自己写两个dp和px转换的方法是很有必要的。

最重要的并不在于规范怎么定义,而是在于规范的严格执行。如果规范定义好了,但却不遵守,那规范就等于形同虚设,因此,规范一旦设定,就要严格执行。

单一性

我们都知道,面向对象设计中,有一个基本原则就是单一职责原则,它规定一个类应该只有一个发生变化的原因。而这里说的单一性,不只是规定类,也规定了方法、包,甚至到最大层面的分层架构。保持单一性是减低耦合度的关键标准,其目的就是各方面的解耦。架构上的分层就是最大层面的解耦,而方法上的单一就是最小层面的解耦了。

  • 界面的单一

    界面上的单一,首先是界面的布局和界面的数据应该分离。这一点,Android已经用layout和Activity做好解耦了,我们只要确保用layout文件排好布局,在Activity展示数据就好了。另外,界面数据的获取和展示也应该分离。很多开发团队习惯将数据的获取和展示都放在Activity或Fragment里完成的,架构篇的读者里也有人反映了这个情况,请求接口、获取数据、检查数据、显示数据更新UI,全都在界面上完成的。这样子的话,当数据的获取发生改变时,比如要添加缓存,这时候界面就需要改动了,当数据的展示也需要修改时,比如某个控件要展示其他数据,界面也一样需要改动,也就是说,界面上已经有两个发生变化的原因,这就违反了单一职责原则。

    原标题:Android 项目重构之路:界面篇

    关键词:Android

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。

可能感兴趣文章

我的浏览记录