韩玉会

摘 要：iOS平台应用开发占据了智能移动平台应用开发的半壁江山，App应用需求量大，而苹果智能移动设备及其应用软件也是新型移动行业的潮流引导者。文中以iOS系统平台应用开发为例，综合运用比较分析及实证研究等方法，深入讨论了iOS系统应用开发常用的开发模型及其特点、框架设计原则、程序逻辑及代码编写规范，工程规范等问题，并结合实践经验探讨了各类规范的应用原则，分类总结了iOS平台应用开发的主要工程规范及实际实施方法，对从事iOS系统开发的人員具有重要参照价值，对所有智能移动平台应用开发均有一定参考意义。

关键词：iOS系统；应用开发；规范化；App应用

中图分类号：TP311 文献标识码：A 文章编号：2095-1302（2017）06-00-03

0 引 言

众所周知，软件开发规范化是保证软件开发效率和质量的重要手段，在智能移动终端应用开发领域更是如此。iOS应用主要运行在iPhone、iPod、iPad以及Apple TV等苹果系列产品上，市场占有率高，用户群体庞大，因此各类应用种类繁多，且更新迅速。iOS应用开发的规范性成为保证iOS应用开发速度和效率的重要手段。由于iOS的封闭性，其应用开发的各类规范如流程规范、程序规范、代码规范、UI设计规范等相对固定，对于iOS应用开发者，尤其对入门新手而言，熟悉各类规范并在实际应用开发中灵活应用，才能最大程度减少错误，避免意外发生。

1 开发模型选择

开发模型是宏观角度项目整体设计规范的体现，合适的开发模型可以提高项目开发效率，减少开发成本，并降低项目风险。瀑布模型是最早提出的开发模型，从上向下，从整体到部分逐步实现功能，符合人们分析问题的一般思路，与之相对应的还有喷泉模型，从下向上组合项目整体功能。此外，软件项目开发中常见的开发模型还有原型模型，线性模型、螺旋模型、增量模型和敏感开发模型等，在移动应用开发实践中，一般都是各种模型的混合使用，即不同部分根据具体情况采用不同的开发方法，充分利用彼此之间的互补性。通过iOS应用开发项目实践分析，总结了如下几条规律：

（1）UI模块在设计明确时采用线性模型，依据不同界面逻辑线性开发，UI设计不明确时，采用快速原型模型，以降低项目风险。

（2）数据通讯在后台服务器接口明确时采用线性模型，按照请求、解析、显示的顺序完成。在后台接口不明确的情况下，采用边做边改的螺旋模型，可暂时搁置显示部分功能。

（3）项目子模块的开发采用瀑布模型，线性符合大众开发思维。功能模块逐级实现项目，可采用增量开发模型。

（4）对于需求分析不足的项目，特别是用户希望尽快看到实物以确定设计的项目，宜采用快速原型模型。

（5）开发周期比较短的项目，为了提高开发效率并控制风险，宜采用敏感开发模型。

iOS移动平台的应用开发多采用混合开发模型，混合开发模型能够融合不同模型的优点，使项目的开发更高效、可行。通过实践熟悉各种模型的特点，在开发中才能选取真正适合的模型，有的放矢，最大程度降低开发成本，提高开发效率。

2 合适的框架

在应用开发的规范性方面，框架至关重要。一个合适的框架虽然不能解决所有问题，但它可以降低问题的复杂度，减少产生错误的概率。

2.1 清晰的层次结构

定义清晰的层次结构，首先要明确各层的主要功能：

（1）表示层（Presentation Layer）负责用户界面设计（UI设计）和用户界面视图控制器（UIViewController）的功能实现。

（2）业务逻辑服务层（Business/Service Layer））主要负责数据逻辑定义和转发调用关系，链接上下两层，承上启下。

（3）数据访问层（Data Access Layer），负责具体的应用程序编程接口（API）构造，各层内部根据业务逻辑的复杂度又可采用多层结构。以数据访问层为例，其内部又可以细分为网络层和持久化层。

一般而言，表示层直接使用逻辑层提供的模型（Model）实现用户界面设计（UI设计），有时会出现模型不一致但需求相同的界面展现，比如在有的App中，会话界面、搜索界面和收藏界面都需要相同的图片，而这三个模块的模型定义可能不同，要解决这个问题，就需要增加额外的视图模型（ViewModel）层，用于解决模型不一致问题。

2.2 横向分析

横向上，各模块互相独立，模块间仅通过设定的几个有限接口通讯。最理想的状态是除核心功能模块外，其他模块都可拔插。横向模块的业务需求依赖性强，横向模块一般依赖于业务需求，常被定义成各种服务（Service）或管理器（Manager），推荐做法是由统一的管理器负责相应服务的加载、卸载、监听和分发。此举容易实现模块的可插拔，保证了公用特性的一致处理。微信的设计开发就遵从这一原则，几乎所有的模块都从MM Service继承而来，由MM Service Center进行统一管理。

2.3 纵向分析

纵向上，各层次间依赖关系清晰，基本不出现逆向依赖。纵向的层次划分所有App都相似，一般分为三个层次：

（1）遵守SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）原则，每个类功能单一且封装，对象（类，模块，函数等）对于扩展是开放的，对于修改是封闭的，隔离接口并反转依赖关系，即高层模块不依赖低层模块，两者都依赖于抽象接口。抽象接口不依赖于具体实现，具体实现依赖于抽象接口。这些设计原则并非iOS 系统应用开发所独有，所有软件设计都应遵循这些基本设计规则。

（2）定义自己的UI基类，如UI View，UI View Controller，UI Table view Cell等。定义后，所有子类（View，Controller，Cell等）都能方便的继承已经定义好的基类共有行为。但需注意控制基类的规模，防止其过度膨胀，大基类不仅增加了排查问题的难度，还增加了代码的理解难度。在实践应用中，基类中只能包含具有普遍性的特性和方法，其余都在子类中实现。

（3）提供方便好用的工具类。一些好用的工具类往往会成为框架的重要组成部分，方便快捷地解决局部问题，同时又不引入过多的复杂度。例如使用键值监听（KVO）容易发生add0（）方法和remove（）方法的不配对调用，那么就需引入TH Observers And Binders或者FB的KVO Controller来解决这一问题。有时，某些核心模块需要被多个模块依赖，要降低其与其他模块的耦合度，可以引入类似XMPP的GCD Multicast Delegate工具进行解耦。

3 程序代码规范

3.1 代码规范

（1）符合苹果命名规范：类名开头大写，至少三个字符做前缀，内部方法使用两个下划线做前缀，以驼峰法命名方法和变量，最大限度避免与系统类库重名。苹果系统类库以及绝大多数第三方开源库均如此。或许可在有些苹果源代码样例中看到用m打头的类成员变量，由于这些都是遗产代码，可以接受，但自己编写的代码应避免使用。

（2）无论使用K&R Style还是Allman Style，在一个文件内只能使用一种形式，二者不可混用。

（3）在保证良好的代码可读性前提下，尽量使代码简短。多使用小类和小方法，由统一函数返回。较小的类和和方法可使读者更多地关注类逻辑，而轻视具体实现细节。统一的函数返回可以减少意外错误，降低错误排查难度。

3.2 良好的程序逻辑

面对错综复杂的程序关系，化繁为简的主要方法就是功能细化，iOS应用开发者也不例外。每个类必须有单一职责，方法要有明确的输入和输出，这是编程的基本原则。通常情况下，用类名和注释来体现类或方法职责的单一性。如果一个类包含比较复杂且变化多端的方法，可以把这个方法上升到一个新类的逻辑层面，分离出去，达到重用的目的，在别的类中也可以使用。从程序逻辑角度看，把一个内部逻辑升级到一个逻辑实体，该逻辑实体以后可以独立变化，为隔离变化点。

在编程中，如果同一个逻辑在系统不同位置有不同的情景需要，就要用到接口。如图1所示，某些情况下Class A需要Class B如B1，某些情景中Class A需要B如B2，这就要求类逻辑可替换，为了明确每个类的对外服务，通常为每个类都实现相应接口，如图2所示。而每个类都有了可被替换的功能，即模块可替换。

4 合适的工程结构

工程开始前为整个工程创建统一的工作空间（workspace），每种类型的资源存放于各自独立的目录下，分门别类存放资源文件，工程组所有人员都要严格遵守，同时建立合理的工程目录结构。工程目录结构如图3所示。

Core用工程的通用机制实现，如规定统一的任务管理、模块管理和基础服务管理等。General是公用的类和方法，包括视图控制器（ViewController）和UITableViewCell的基类（Base），公用Category，公用UI组件（CustomUI），公用辅助方法（Helper）和宏定义（Marco），公用数据模型Model，不同程序单元Sections，其中包括登录及设置等部分。设置部分又可按功能划分为当前单元的自定义UI组件，管理类模块及视图控制器（ViewController）等，最后是第三方库Vendors。

5 流程規范

5.1 需求分析

这一阶段的基本任务是确定项目的基本需求和开发的总体策略。根据项目整体需求讨论研究，逐步细化功能直到产生明确的需求功能点，生成项目功能需求表。移动应用领域的专家指出，现阶段的App营销核心不是内容而是功能，因此需求分析阶段对功能设定与后期推广有非常重要的影响。

5.2 方案策划

根据项目功能需求表确定的明确需求对App进行规划，确定页面和布局设计及业务逻辑的交互关系，形成策划方案和App设计逻辑图。

5.3 UI设计

基于App设计逻辑图构建最终产品的UI原型，并由美术设计师对原型进行UI界面配色、设计及各种不同分辨率的适配，形成最终App界面设计方案。

5.4 功能实现

基于App界面设计方案，形成程序架构设计方案，并由工程师团队进行开发，完成产品设计并实现相应功能。

5.5 项目测试

App功能开发完成后，基于需求功能表、UI设计与程序架构设计，对整个App、后台管理系统进行全面终测，形成测试报告。开发人员根据测试人员发现的问题进行调试修复。

5.6 发布推广

经内部测试，确认功能实现与用户需求无误对接后，便可打包并发布到苹果商店（App Store）。苹果公司的审核较严格，要做好再次修改的心理准备，且等待审核通过的时间较长。

6 规范应用原则

软件开发需要合适的规范，这是广泛认同的理念，因为只有遵守规范才能减少开发过程中意外的出现。但在实践应用中却会碰到一些情况，如怎么鉴别哪些规范是强制执行，哪些是推荐执行。强制执行的规范可提升程序的可读性、降低二义性，但对一些有想法的开发人员，或者已经形成自己编码习惯的程序员而言，这些规范又是桎梏。但若把大部分规范设定为推荐执行，无良好引导，则规范容易被忽视。比如苹果自己的开发语言规范和《Google Objective-C Style Guide》等，这些规范一般只有两种分级，即推荐和不推荐。而我更推荐把代码规范分为五个等级，即强制要求，强烈推荐（但不强制），良好，可接受和不可接受，用强制要求和不可接受两种级别来保证规范的实施，同时，又兼顾个人爱好和习惯。以上讨论的开发模型和开发流程规范都可归为良好，程序代码规范为强制要求，合适的框架可归为强烈推荐。

7 结 语

本文以iOS系统平台应用开发为例，讨论了iOS系统应用开发常用的开发模型特点、框架设计原则、程序逻辑及代码编写规范，工程规范及规范应用原则等问题，根据实践经验分类总结了iOS平台应用开发的主要规范及工程实施方法，对所有智能移动平台的应用开发均有参考意义。然而，信息时代，随着人们需求的不断变化，iOS智能移动平台应用开发也将是一个高速发展，不断变化的领域，未来的iOS应用开发还会有新的规范或标准需要开发者或研究者们去探讨和研究。

参考文献

[1]王云.iOS平台客户端应用开发规范化研究[D].北京：北京邮电大学，2013.

[2]李勇.iOS系统与应用安全分析方法研究[D].上海：上海交通大学，2015.

[3]陈佳霖，王轶骏，薛质.iOS系统数据安全研究[J].信息安全与通信保密，2012（8）：100-102.

[4]田龙过，闫河.智能手机APP界面设计探讨[J].西部广播电视，2014（21）：153-154.

[5]刘朝华.基于iOS平台车位共享系统设计与实现[J].物联网技术，2017，7（3）：101-103.

[6]凌宁.基于iOS系统的安全性研究[D].北京：北京邮电大学，2014.

[7]周高木.基于iOS的动态几何研究与实现[D].成都：电子科技大学，2012.

[8]杨蕙馨，王硕，冯文娜.网络效应视角下技术标准的竞争性扩散——来自Android之争的实证研究[J].中国工业经济，2014（9）：135-147.