Android项目重构之路:界面篇

前一篇 《Android项目重构之路:架构篇》 把项目分成模型、接口、核心、界面四层。界面变化最频繁、也最容易乱。规划界面层，至少守住规范性、单一性、简洁性。

一、规范性

编码习惯各不相同：缩进有人 4 空格、有人 2 空格；变量有人 mValue、有人直接 value。不设规范，久了必乱。规范没有统一标准，下面几点仅供参考。

缩进

很多人习惯 Tab。不管规范是 4 空格还是 2 空格，统一设置好 Tab size，就不用每人去敲空格。

命名

好名字一眼能看出干什么、什么类型。有人把 TextView 缩成 tv、ListView 缩成 lv，不熟悉的人看不懂，不如 text、list 明确。id 命名结构可以是：控件_范围_功能，例如 edit_login_password。

单位

文字用 sp，其他元素用 dp，跟分辨率无关。SDK 里文字默认 sp，其他元素默认却是 px，也没提供 dp 接口，所以自己写 dp/px 转换很有必要。

最重要的不是规范怎么定义，而是严格执行。定义了却不遵守，等于没有。

二、单一性

面向对象有单一职责：一个类只有一个变化原因。这里的单一性还管方法、包，直到分层。单一是降耦合的关键。

界面的单一

布局和数据要分离。Android 已经用 layout 和 Activity 解耦：layout 排布局，Activity 展示数据。数据的获取和展示也要分离。很多团队把请求接口、拿数据、检查、更新 UI 全塞进 Activity/架构篇 读者也反映过这情况。加缓存要改界面，控件换数据也要改界面——已经有两个变化原因，违反单一职责。界面每个维度都要分开：布局、获取、检查、展示。

包和类的单一

定义包之前先想清职责。例如 com.keegan.activity 只放 Activity，com.keegan.adapter 只放适配器，com.keegan.util 是工具包。有人把 adapter 写在 Activity 里，因为“只用这一处”。做一段时间会发现无法复用，小需求调整要改很多地方。把 adapter 独立出来并抽基类之后，新增和修改都少很多。别让一个类做太多事。

方法的单一

一个方法封装一个行为；行为还能拆成更细的步骤。关键不在怎么定义这个行为，而在怎么拆。例如 onCreate 做初始化，可拆成：控件初始化、逻辑变量、数据加载和展示；加载和展示再拆：缓存、网络、展示。每个细化行为都独立成方法。

资源文件的单一

字符串进 strings.xml，数组进 arrays.xml，颜色进 colors.xml，尺寸进 dimens.xml。不要在代码或布局里直接写死。要国际化或改尺寸时，直接写死的地方会改不完。

保持单一性必定伴随重构。需求会变、代码会扩，扩着扩着就破坏单一，再重构回来。

三、简洁性

代码最怕臃肿：可读性差、维护麻烦、扩展更别提。判断标准很简单：直接读就能理解意图；意图不明显，说明还不够简洁。类、包、资源文件同样适用。

包的组织

按组件类型分包，不要按业务模块。业务会变，组件类型基本不变。新人可能不懂业务，但对组件清楚，入手快。

类和接口的命名

组件类加后缀：Activity、Fragment、Adapter；实体加 BO，工具加 util，实现加 Impl。接口层后缀 Api，核心层后缀 Action。

资源文件的分类

strings.xml 存所有字符串，分类放；某一类太多就拆文件，例如标题拆到 strings_title.xml：

• 页面标题：title_{页面}
• 按钮：btn_{按钮事件}
• 标签：label_{标签文字}
• 选项卡：tab_{选项卡文字}
• Toast：toast_{消息}
• 编辑框提示：hint_{提示信息}
• 图片描述：desc_{图片文字}
• 对话框：dialog_{文字}

三条原则相辅相成：单一和简洁是规范的标准；严格执行规范，后两条才有效。具体实现下一篇再讲。

原文出处：Keegan小钢

一句话总结：界面层靠规范统一风格，靠单一拆开布局/数据/资源，靠简洁让人读代码就能懂；扩展破坏了这三条，就重构回来。