iOS 2.0 版本切入点

转载自：http://www.infoq.com/cn/articles/Version_2_0

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

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

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

 

图1，应用整体架构

自下而上，最底层的是API Server ，也就是服务端，这篇文章着重讨论客户端架构，对这两层不多说。

Network 和Local Storage

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

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

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

Items

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

Services

Services 是对业务逻辑的封装，Data Center 关注如何获取Items，Services 则关注如何组织Items，如：怎么构建搜索参数，如何翻页，列表排序等。Services 把复杂的业务逻辑封装成类名、方法名和参数，供上层调用。这一层的变化较上面提到的几层要频繁的多，因为Services 随着业务变化而变化，已经不是纯技术层面了。

View Controllers

View Controllers 顾名思义，就是Cocoa 框架中的ViewController，在这些ViewController 里只有展示逻辑。这一层并不关心返回的Items 是什么含义，为什么要如此组合，View Controllers 只关心什么Items 需要什么视图、采用是什么颜色等。

Tools

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

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

在如上描述的框架下构建一个iOS 应用可以让整个工程的代码层次清晰起来，然而一个高效的互联网应用，仅有层次清晰还远远不够，还需要更多其他方法降低应用的开发和运维成本。

WebView

首先，恰当使用WebView 可以大大提升应用的灵活性，降低开发成本。使用WebView 要与创建Web 应用区别开，创建Web 应用是整个应用的视觉控件全部基于WebView 创建，少量的本地代码辅助交互；而在这里说的是在一个应用中，在不影响视觉和交互体验的前提下，使用WebView 完成一部分视觉元素。

在应用中使用WebView 分为两种，一种是整张视图使用WebView 创建，这种方式适用于非关键界面，为了降低成本，或是处在Beta 阶段的界面，仍然有许多细节需要调整。 这种使用方式WebView 的复杂度较高，需要在WebView 中实现Cookie 记录、HttpRequest 自定义、与本地代码交互等操作。

图2，复杂的WebView

例如，微信的FAQ 页面，这是一个非关键页面，但内容变化有比较频繁，所以使用WebView 来实现。微信的这个WebView 界面并未做任何伪装，就是以一个原生WebView 的样式示人。在实际应用中，如果对视觉要求较高，可以通过修改NavigationBar、ToolBar和WebView 中的一些特有手势进行伪装，使其看起来更像一个本地视图。

图3，微信FAQ

另一种是WebView 嵌入本地代码中，适合展示较复杂的视觉元素，既可以由WebView 直接从网络加载内容，也可单独加载HTML 代码，以本地形式渲染。这种WebView 相较上一种使用方式简单许多，只需要实现与本地代码交互的部分即可。

图4，简单的WebView

新浪微博的微博详情页就是以这种方式实现，微博正文和来源使用WebView实现，其他部分是本地代码。由于微博正文内的表情较多，因此图文混排的情况较复杂，所以使用局部WebView 实现是一个非常好的方法。

图5，微博详情页

在WebView 之外，大量的交互和视觉是由本地视觉控制器（ViewControllers ）管理的。传统的iOS 应用由UINavigationController 中的堆栈储存ViewControllers 对象，通过push 和pop 方法直接管理。这种方式管理的ViewControllers 耦合性非常强，之间存在依赖，不能单独存在。而强耦合在应对变化中总会非常麻烦，因此需要对这种强耦合的方式进行一些修改和封装，适应互联网应用的特点。

URL Scheme

使用URL Scheme 管理ViewControllers 最初是Facebook 开发的Three20 框架实现（由于该框架体积庞大已被官方放弃，不建议使用，https://github.com/gaosboy/urlmanager 是一个轻量级的开源URL Scheme 管理控件）。URL Scheme 的特点在于 ViewController 中需要的信息全部通过参数的形式传递，通过一个URL 来标示、创建和管理ViewController。

图6，URL Scheme 原理图

URL Scheme 的原理是维护一张URL - ViewController Class Name 的关系表，在这种关系表中开发者要定义一个私有协议，以区分HTTP 请求的URL，例如：sf:// 。ViewControllerA 通过需要调用ViewControllerB 时，首先要构造一个与ViewControllerB相对的URL，传入URL 管理器。管理器通过查关系表找到相对的ViewController，并通过NSClassFromString 方法初始化活的对象实例。在该实例初始化过程中，要完成对其URL 的解析，从URL 的参数和路径中获取接下来试图渲染所需要的全部信息。

通过URL Scheme 管理ViewControllers 可以实现从任意ViewController 对任意ViewController 的调用，而且这些调用是完全动态的，只需要构造一个URL 加入相应参数即可，实现了ViewController 之间的解耦。

SegmentFault 官方应用是对以上所述的原则和架构的一次实践，你可以通过https://github.com/gaosboy/iOSSF 获取到该项目的代码。每一款iOS 应用都有其独一无二的特点，这是由应用本身的业务特点决定的，因此一套架构体系无法完全适应。针对应用自身特点，在以上提到的原则下对架构作出合理调整，建立一个使用自身应用的架构体系。在iOS 应用开发过程中，遇到任何问题都可以到http://segmentfault.com/t/ios 进行交流，让大家帮你构建一个合理的应用。

总之，在应用从1.0 向2.0 的过渡中，最重要的一点是应用架构趋于合理，为接下来的版本迭代做好技术储备，能够应对快速变化的需求，让版本迭代的节奏跟上需求变化的速度。