iOS系統應用開發規范研究

韓玉會

摘 要：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.