App架构设计经验谈:展现层的设计

App架构设计经验谈:展现层的设计

三层架构中，数据层和业务层都已经作过了简单的分享，最后，就剩下展现层了。本篇就给各位分享下我在展现层设计方面的一些经验心得。

展现层是三层架构中最复杂的一层了，须要考虑的包括但不限于界面布局、屏幕适配、文字大小、颜色、图片资源、提示信息、动画等等。展现层也是变化最频繁的一个层面，天天改得最多的就是界面了。所以，展现层也是最容易变得混乱不堪的一个层面。一个良好的展现层，应该有较好的可读性、健壮性、维护性、扩展性。

三原则

我在Android项目重构之路:界面篇中提到过三个原则，要设计好展现层，至少须要遵循好这三条基本的原则：

1. 保持规范性：定义好开发规范，包括书写规范、命名规范、注释规范等，并按照规范严格执行；

2. 保持单一性：布局就只作布局，内容就只作内容，各自分离好，每一个方法、每一个类，也只作一件事情；

3. 保持简洁性：保持代码和结构的简洁，每一个方法，每一个类，每一个包，每一个文件，都不要塞太多代码或资源，感受多了就应该拆分。

关于这三个原则详细的解说，界面篇已经讲过的，我这里就再也不重复。在此，我只作些补充。

关于规范，Android方面，我已经分享过一套Android技术积累:开发规范，主要分为书写规范、命名规范、注释规范三部分。iOS方面，苹果已经有一套Coding Guidelines，主要属于命名方面的规范。当咱们制定本身的开发规范时，首先就要遵照苹果的这份规范，在此基础上再加上本身的规范。

最重要的不是开发规范的制定，而是开发规范的执行。若是没有按照开发规范去执行，那开发规范就等于形同虚设，那代码混乱的问题依然得不到解决。

另外，Android系统自己已经对资源进行了很好的分离，字符串、颜色值、尺寸大小、图片、动画等等都用不一样的xml文件定义。而iOS系统在这方面就逊色不少，只能本身实现，其中一种实现方案就是经过plist文件的方式实现和Android同样的机制。

工程结构

工程结构其实就是模块的划分，无非分为两类：按业务划分或按组件划分。

好比一个电商App，可能会有首页、附近、分类、个人四大模块，工程结构也根据这四大模块进行划分，Android可能就分为了四个模块包：

• com.domain.home 首页

• com.domain.nearby 附近

• com.domain.category 分类

• com.domain.user 个人

一样的，iOS则分为四个分组：home、nearby、category、user。

以后，每一个模块下相应的页面就放入相应的模块。那么，问题来了，商品详情页应该属于哪一个模块呢？首页会跳转到商品详情页，附近也会跳转到商品详情页，分类也会跳转到商品详情页，用户查看订单时也能跳转到商品详情页。有些页面，并不能很明显的区分出属于哪一个模块的。我接手过的，按业务划分的二手项目中（即不是由我搭建的项目），我要找一个页面时，我认为应该属于A模块的，但在A模块却找不到，问了同事才知道在B模块。相似的状况出现过不少次，并且不止出如今我身上，对业务不熟悉的开发人员都会出现这个问题。并且，对业务不熟悉的开发人员开发新的页面或功能时，若是对业务理解不深，划分出错，那也将成为问题，其余人员要找该页面时更难找到了。

所以，我更喜欢按组件划分的工程结构，由于组件每一个人都懂，无论对业务熟不熟悉，查找起来都明显方便不少。Android按组件划分大体以下：

• com.domain.activities 存放全部的Activity

• com.domain.fragments 存放全部的Fragment

• com.domain.adapters 存放全部的Adapter

• com.domain.services 存放全部的Service

• com.domain.views 存放全部的自定义View

• com.domain.utils 存放全部的工具类

iOS的分组则大体以下：

• controllers 存放全部ViewController

• cells 存放全部Cell，包括TableViewCell和CollectionViewCell

• views 存放全部自定义控件或对系统控件的扩展

• utils 存放全部的工具类

基类的定义

Android的Activity、Fragment、Adapter，iOS的ViewController，分别定义一个基类，将大部分通用的变量和方法定义和封装好，将减小不少工做量，并且有了统一的设置，也会减小代码的混乱。好比我在Android项目重构之路:实现篇中提到的KBaseActivity和KBaseAdapter的实现就是例子，固然还能够抽离出更多变量和方法。

每一个Activity的onCreate()方法，通常分为三步：

1. 变量的初始化；

2. View的初始化；

3. 加载数据。

所以，其实能够将onCreate()方法拆分红三个方法：

1. initVariables()

2. initViews()

3. loadData()

在基类中将这三个方法定义为抽象方法，由子类去实现，这样，子类就不须要实现onCreate()方法了，只要实现更细化的上述三个方法便可。

iOS的ViewController也是一样的方式，这里就不重复了。