iOS 应用2.0版怎么做

http://pingguohe.net/2013/02/14/version_2_0/

移动互联网如火如荼，iOS 应用+ Android 应用+ 手机站似乎成了所有互联网公司的标配，你的网站要是还没有个iOS 应用，似乎都不好意思跟人打招呼。

iOS 应用诞生毕竟才只有不到5年的时间，各个方面还都处在起步阶段。不管是出于团队缺乏经验，还是那个“唯快不破”的铁律，往往这些iOS 应用的第一个版本都比较简陋，尤其在技术架构上。这篇文章，我想跟大家探讨的就是这个问题，当你的iOS应用已经有一个版本在线的情况下，如何去构建一款可以支持高效迭代，快速响应的2.0版。

首先，应用的架构要层次清晰。把不依赖版本更新变化的，以来版本更新变化的，不需要变化的，业务逻辑，视图逻辑，工具，等这些内容梳理清楚，单独处理。


图1，应用整体架构

自下而上，最底层的是API Server ，也就是服务端，和经常踩到大便一般的网络，这篇文章着重讨论客户端架构，对这两层不多说。

Network 和Local Storage 是整个应用的数据来源。Local Storage 除了存储资源数据，还缓存来自Network 的数据。在这一层中，所有数据都以原始的未经格式化的结构存在，或是文本，或是文本的数组和字典。

Network 是客户端与服务端的沟通桥梁，一般建议使用开源控件（如：AFNetworking）实现。在大便一样的网络情况下，请求会出现各种异常，因此这些控件中提供的请求控制方法会提供很多便利，去处理这些问题。

Local Storage 除以文件形式直接存储图片等资源文件外，信息类数据，如：用户信息，配置信息等，建议使用Cocoa 框架中提供的Core Data，对SQLite 的一个非常好的封装。直接使用文件存储要注意写入频率，高频率的I/O 操作非常占用资源，一般来说把数据直接放在内存中，只有需要的时候，如：关闭应用或关键数据写入（用户密码）才进行回写。

Items 是整个应用中对数据对象的封装，某种程度上就是Value Object 的集合。 一个数据类型的Item 可以是最原始的数组或字典，也可以是封装成如Java 中的POJO 一般，或者更复杂的带有基本处理方法的数据对象。 Data Center 是Items 的控制中心，把网络请求，网络异常处理，缓存机制，等完全封装起来。Data Center 响应上层的数据请求，向Network 或Local Storage 索取原始数据，并拼装成Items 中定义的数据结构，返回给上层。

Services 是对业务逻辑的封装，Data Center 关注如何获取Items，Services 则关注如何组织Items，如：怎么构建搜索参数，如何翻页，列表排序等。Services 把复杂的业务逻辑封装成类名，方法名和参数，供上层调用。这一层的变化较上面提到的几层要频繁的多，因为Services 随着业务变化而变化，已经不是纯技术层面了。
View Controllers 顾名思义，就是Cocoa 框架中的ViewController，在这些ViewController 里只有展示逻辑。这一层并不关心返回的Items 是什么含义，为什么要如此组合，View Controllers 只关心什么Items 需要什么视图，采用是什么颜色，等。

Tools 是几乎贯穿整个应用的工具和扩展集合，工具如：字符串md5 加密，数组扁平化，等；扩展如：UIView 框架设置，URL 拼装，等。

在这个架构下，Items 和Tools 几乎是静态的，没有逻辑。Network、Data Center和Local Storage 从技术角度封装逻辑，在版本迭代过程中几乎不发生变化。Services 这一层是版本迭代中调整的重点，他的厚度取决于这款应用的业务复杂度。View Controllers 的内容改变更加频繁，甚至不依赖版本更新，需要通过API Server 的的信息修改界面展示，需要较高的可定制性。