韓玉會

摘 要：iOS平臺應(yīng)用開發(fā)占據(jù)了智能移動平臺應(yīng)用開發(fā)的半壁江山，App應(yīng)用需求量大，而蘋果智能移動設(shè)備及其應(yīng)用軟件也是新型移動行業(yè)的潮流引導(dǎo)者。文中以iOS系統(tǒng)平臺應(yīng)用開發(fā)為例，綜合運用比較分析及實證研究等方法，深入討論了iOS系統(tǒng)應(yīng)用開發(fā)常用的開發(fā)模型及其特點、框架設(shè)計原則、程序邏輯及代碼編寫規(guī)范，工程規(guī)范等問題，并結(jié)合實踐經(jīng)驗探討了各類規(guī)范的應(yīng)用原則，分類總結(jié)了iOS平臺應(yīng)用開發(fā)的主要工程規(guī)范及實際實施方法，對從事iOS系統(tǒng)開發(fā)的人員具有重要參照價值，對所有智能移動平臺應(yīng)用開發(fā)均有一定參考意義。

關(guān)鍵詞：iOS系統(tǒng)；應(yīng)用開發(fā)；規(guī)范化；App應(yīng)用

中圖分類號：TP311 文獻標識碼：A 文章編號：2095-1302（2017）06-00-03

0 引 言

眾所周知，軟件開發(fā)規(guī)范化是保證軟件開發(fā)效率和質(zhì)量的重要手段，在智能移動終端應(yīng)用開發(fā)領(lǐng)域更是如此。iOS應(yīng)用主要運行在iPhone、iPod、iPad以及Apple TV等蘋果系列產(chǎn)品上，市場占有率高，用戶群體龐大，因此各類應(yīng)用種類繁多，且更新迅速。iOS應(yīng)用開發(fā)的規(guī)范性成為保證iOS應(yīng)用開發(fā)速度和效率的重要手段。由于iOS的封閉性，其應(yīng)用開發(fā)的各類規(guī)范如流程規(guī)范、程序規(guī)范、代碼規(guī)范、UI設(shè)計規(guī)范等相對固定，對于iOS應(yīng)用開發(fā)者，尤其對入門新手而言，熟悉各類規(guī)范并在實際應(yīng)用開發(fā)中靈活應(yīng)用，才能最大程度減少錯誤，避免意外發(fā)生。

1 開發(fā)模型選擇

開發(fā)模型是宏觀角度項目整體設(shè)計規(guī)范的體現(xiàn)，合適的開發(fā)模型可以提高項目開發(fā)效率，減少開發(fā)成本，并降低項目風(fēng)險。瀑布模型是最早提出的開發(fā)模型，從上向下，從整體到部分逐步實現(xiàn)功能，符合人們分析問題的一般思路，與之相對應(yīng)的還有噴泉模型，從下向上組合項目整體功能。此外，軟件項目開發(fā)中常見的開發(fā)模型還有原型模型，線性模型、螺旋模型、增量模型和敏感開發(fā)模型等，在移動應(yīng)用開發(fā)實踐中，一般都是各種模型的混合使用，即不同部分根據(jù)具體情況采用不同的開發(fā)方法，充分利用彼此之間的互補性。通過iOS應(yīng)用開發(fā)項目實踐分析，總結(jié)了如下幾條規(guī)律：

（1）UI模塊在設(shè)計明確時采用線性模型，依據(jù)不同界面邏輯線性開發(fā)，UI設(shè)計不明確時，采用快速原型模型，以降低項目風(fēng)險。

（2）數(shù)據(jù)通訊在后臺服務(wù)器接口明確時采用線性模型，按照請求、解析、顯示的順序完成。在后臺接口不明確的情況下，采用邊做邊改的螺旋模型，可暫時擱置顯示部分功能。

（3）項目子模塊的開發(fā)采用瀑布模型，線性符合大眾開發(fā)思維。功能模塊逐級實現(xiàn)項目，可采用增量開發(fā)模型。

（4）對于需求分析不足的項目，特別是用戶希望盡快看到實物以確定設(shè)計的項目，宜采用快速原型模型。

（5）開發(fā)周期比較短的項目，為了提高開發(fā)效率并控制風(fēng)險，宜采用敏感開發(fā)模型。

iOS移動平臺的應(yīng)用開發(fā)多采用混合開發(fā)模型，混合開發(fā)模型能夠融合不同模型的優(yōu)點，使項目的開發(fā)更高效、可行。通過實踐熟悉各種模型的特點，在開發(fā)中才能選取真正適合的模型，有的放矢，最大程度降低開發(fā)成本，提高開發(fā)效率。

2 合適的框架

在應(yīng)用開發(fā)的規(guī)范性方面，框架至關(guān)重要。一個合適的框架雖然不能解決所有問題，但它可以降低問題的復(fù)雜度，減少產(chǎn)生錯誤的概率。

2.1 清晰的層次結(jié)構(gòu)

定義清晰的層次結(jié)構(gòu)，首先要明確各層的主要功能：

（1）表示層（Presentation Layer）負責(zé)用戶界面設(shè)計（UI設(shè)計）和用戶界面視圖控制器（UIViewController）的功能實現(xiàn)。

（2）業(yè)務(wù)邏輯服務(wù)層（Business/Service Layer））主要負責(zé)數(shù)據(jù)邏輯定義和轉(zhuǎn)發(fā)調(diào)用關(guān)系，鏈接上下兩層，承上啟下。

（3）數(shù)據(jù)訪問層（Data Access Layer），負責(zé)具體的應(yīng)用程序編程接口（API）構(gòu)造，各層內(nèi)部根據(jù)業(yè)務(wù)邏輯的復(fù)雜度又可采用多層結(jié)構(gòu)。以數(shù)據(jù)訪問層為例，其內(nèi)部又可以細分為網(wǎng)絡(luò)層和持久化層。

一般而言，表示層直接使用邏輯層提供的模型（Model）實現(xiàn)用戶界面設(shè)計（UI設(shè)計），有時會出現(xiàn)模型不一致但需求相同的界面展現(xiàn)，比如在有的App中，會話界面、搜索界面和收藏界面都需要相同的圖片，而這三個模塊的模型定義可能不同，要解決這個問題，就需要增加額外的視圖模型（ViewModel）層，用于解決模型不一致問題。

2.2 橫向分析

橫向上，各模塊互相獨立，模塊間僅通過設(shè)定的幾個有限接口通訊。最理想的狀態(tài)是除核心功能模塊外，其他模塊都可拔插。橫向模塊的業(yè)務(wù)需求依賴性強，橫向模塊一般依賴于業(yè)務(wù)需求，常被定義成各種服務(wù)（Service）或管理器（Manager），推薦做法是由統(tǒng)一的管理器負責(zé)相應(yīng)服務(wù)的加載、卸載、監(jiān)聽和分發(fā)。此舉容易實現(xiàn)模塊的可插拔，保證了公用特性的一致處理。微信的設(shè)計開發(fā)就遵從這一原則，幾乎所有的模塊都從MM Service繼承而來，由MM Service Center進行統(tǒng)一管理。

2.3 縱向分析

縱向上，各層次間依賴關(guān)系清晰，基本不出現(xiàn)逆向依賴。縱向的層次劃分所有App都相似，一般分為三個層次：

（1）遵守SOLID（單一功能、開閉原則、里氏替換、接口隔離以及依賴反轉(zhuǎn)）原則，每個類功能單一且封裝，對象（類，模塊，函數(shù)等）對于擴展是開放的，對于修改是封閉的，隔離接口并反轉(zhuǎn)依賴關(guān)系，即高層模塊不依賴低層模塊，兩者都依賴于抽象接口。抽象接口不依賴于具體實現(xiàn)，具體實現(xiàn)依賴于抽象接口。這些設(shè)計原則并非iOS 系統(tǒng)應(yīng)用開發(fā)所獨有，所有軟件設(shè)計都應(yīng)遵循這些基本設(shè)計規(guī)則。

（2）定義自己的UI基類，如UI View，UI View Controller，UI Table view Cell等。定義后，所有子類（View，Controller，Cell等）都能方便的繼承已經(jīng)定義好的基類共有行為。但需注意控制基類的規(guī)模，防止其過度膨脹，大基類不僅增加了排查問題的難度，還增加了代碼的理解難度。在實踐應(yīng)用中，基類中只能包含具有普遍性的特性和方法，其余都在子類中實現(xiàn)。

（3）提供方便好用的工具類。一些好用的工具類往往會成為框架的重要組成部分，方便快捷地解決局部問題，同時又不引入過多的復(fù)雜度。例如使用鍵值監(jiān)聽（KVO）容易發(fā)生add0（）方法和remove（）方法的不配對調(diào)用，那么就需引入TH Observers And Binders或者FB的KVO Controller來解決這一問題。有時，某些核心模塊需要被多個模塊依賴，要降低其與其他模塊的耦合度，可以引入類似XMPP的GCD Multicast Delegate工具進行解耦。

3 程序代碼規(guī)范

3.1 代碼規(guī)范

（1）符合蘋果命名規(guī)范：類名開頭大寫，至少三個字符做前綴，內(nèi)部方法使用兩個下劃線做前綴，以駝峰法命名方法和變量，最大限度避免與系統(tǒng)類庫重名。蘋果系統(tǒng)類庫以及絕大多數(shù)第三方開源庫均如此?；蛟S可在有些蘋果源代碼樣例中看到用m打頭的類成員變量，由于這些都是遺產(chǎn)代碼，可以接受，但自己編寫的代碼應(yīng)避免使用。

（2）無論使用K&R Style還是Allman Style，在一個文件內(nèi)只能使用一種形式，二者不可混用。

（3）在保證良好的代碼可讀性前提下，盡量使代碼簡短。多使用小類和小方法，由統(tǒng)一函數(shù)返回。較小的類和和方法可使讀者更多地關(guān)注類邏輯，而輕視具體實現(xiàn)細節(jié)。統(tǒng)一的函數(shù)返回可以減少意外錯誤，降低錯誤排查難度。

3.2 良好的程序邏輯

面對錯綜復(fù)雜的程序關(guān)系，化繁為簡的主要方法就是功能細化，iOS應(yīng)用開發(fā)者也不例外。每個類必須有單一職責(zé)，方法要有明確的輸入和輸出，這是編程的基本原則。通常情況下，用類名和注釋來體現(xiàn)類或方法職責(zé)的單一性。如果一個類包含比較復(fù)雜且變化多端的方法，可以把這個方法上升到一個新類的邏輯層面，分離出去，達到重用的目的，在別的類中也可以使用。從程序邏輯角度看，把一個內(nèi)部邏輯升級到一個邏輯實體，該邏輯實體以后可以獨立變化，為隔離變化點。

在編程中，如果同一個邏輯在系統(tǒng)不同位置有不同的情景需要，就要用到接口。如圖1所示，某些情況下Class A需要Class B如B1，某些情景中Class A需要B如B2，這就要求類邏輯可替換，為了明確每個類的對外服務(wù)，通常為每個類都實現(xiàn)相應(yīng)接口，如圖2所示。而每個類都有了可被替換的功能，即模塊可替換。

4 合適的工程結(jié)構(gòu)

工程開始前為整個工程創(chuàng)建統(tǒng)一的工作空間（workspace），每種類型的資源存放于各自獨立的目錄下，分門別類存放資源文件，工程組所有人員都要嚴格遵守，同時建立合理的工程目錄結(jié)構(gòu)。工程目錄結(jié)構(gòu)如圖3所示。

Core用工程的通用機制實現(xiàn)，如規(guī)定統(tǒng)一的任務(wù)管理、模塊管理和基礎(chǔ)服務(wù)管理等。General是公用的類和方法，包括視圖控制器（ViewController）和UITableViewCell的基類（Base），公用Category，公用UI組件（CustomUI），公用輔助方法（Helper）和宏定義（Marco），公用數(shù)據(jù)模型Model，不同程序單元Sections，其中包括登錄及設(shè)置等部分。設(shè)置部分又可按功能劃分為當前單元的自定義UI組件，管理類模塊及視圖控制器（ViewController）等，最后是第三方庫Vendors。

5 流程規(guī)范

5.1 需求分析

這一階段的基本任務(wù)是確定項目的基本需求和開發(fā)的總體策略。根據(jù)項目整體需求討論研究，逐步細化功能直到產(chǎn)生明確的需求功能點，生成項目功能需求表。移動應(yīng)用領(lǐng)域的專家指出，現(xiàn)階段的App營銷核心不是內(nèi)容而是功能，因此需求分析階段對功能設(shè)定與后期推廣有非常重要的影響。

5.2 方案策劃

根據(jù)項目功能需求表確定的明確需求對App進行規(guī)劃，確定頁面和布局設(shè)計及業(yè)務(wù)邏輯的交互關(guān)系，形成策劃方案和App設(shè)計邏輯圖。

5.3 UI設(shè)計

基于App設(shè)計邏輯圖構(gòu)建最終產(chǎn)品的UI原型，并由美術(shù)設(shè)計師對原型進行UI界面配色、設(shè)計及各種不同分辨率的適配，形成最終App界面設(shè)計方案。

5.4 功能實現(xiàn)

基于App界面設(shè)計方案，形成程序架構(gòu)設(shè)計方案，并由工程師團隊進行開發(fā)，完成產(chǎn)品設(shè)計并實現(xiàn)相應(yīng)功能。

5.5 項目測試

App功能開發(fā)完成后，基于需求功能表、UI設(shè)計與程序架構(gòu)設(shè)計，對整個App、后臺管理系統(tǒng)進行全面終測，形成測試報告。開發(fā)人員根據(jù)測試人員發(fā)現(xiàn)的問題進行調(diào)試修復(fù)。

5.6 發(fā)布推廣

經(jīng)內(nèi)部測試，確認功能實現(xiàn)與用戶需求無誤對接后，便可打包并發(fā)布到蘋果商店（App Store）。蘋果公司的審核較嚴格，要做好再次修改的心理準備，且等待審核通過的時間較長。

6 規(guī)范應(yīng)用原則

軟件開發(fā)需要合適的規(guī)范，這是廣泛認同的理念，因為只有遵守規(guī)范才能減少開發(fā)過程中意外的出現(xiàn)。但在實踐應(yīng)用中卻會碰到一些情況，如怎么鑒別哪些規(guī)范是強制執(zhí)行，哪些是推薦執(zhí)行。強制執(zhí)行的規(guī)范可提升程序的可讀性、降低二義性，但對一些有想法的開發(fā)人員，或者已經(jīng)形成自己編碼習(xí)慣的程序員而言，這些規(guī)范又是桎梏。但若把大部分規(guī)范設(shè)定為推薦執(zhí)行，無良好引導(dǎo)，則規(guī)范容易被忽視。比如蘋果自己的開發(fā)語言規(guī)范和《Google Objective-C Style Guide》等，這些規(guī)范一般只有兩種分級，即推薦和不推薦。而我更推薦把代碼規(guī)范分為五個等級，即強制要求，強烈推薦（但不強制），良好，可接受和不可接受，用強制要求和不可接受兩種級別來保證規(guī)范的實施，同時，又兼顧個人愛好和習(xí)慣。以上討論的開發(fā)模型和開發(fā)流程規(guī)范都可歸為良好，程序代碼規(guī)范為強制要求，合適的框架可歸為強烈推薦。

7 結(jié) 語

本文以iOS系統(tǒng)平臺應(yīng)用開發(fā)為例，討論了iOS系統(tǒng)應(yīng)用開發(fā)常用的開發(fā)模型特點、框架設(shè)計原則、程序邏輯及代碼編寫規(guī)范，工程規(guī)范及規(guī)范應(yīng)用原則等問題，根據(jù)實踐經(jīng)驗分類總結(jié)了iOS平臺應(yīng)用開發(fā)的主要規(guī)范及工程實施方法，對所有智能移動平臺的應(yīng)用開發(fā)均有參考意義。然而，信息時代，隨著人們需求的不斷變化，iOS智能移動平臺應(yīng)用開發(fā)也將是一個高速發(fā)展，不斷變化的領(lǐng)域，未來的iOS應(yīng)用開發(fā)還會有新的規(guī)范或標準需要開發(fā)者或研究者們?nèi)ヌ接懞脱芯俊?/p>

參考文獻

[1]王云.iOS平臺客戶端應(yīng)用開發(fā)規(guī)范化研究[D].北京：北京郵電大學(xué)，2013.

[2]李勇.iOS系統(tǒng)與應(yīng)用安全分析方法研究[D].上海：上海交通大學(xué)，2015.

[3]陳佳霖，王軼駿，薛質(zhì).iOS系統(tǒng)數(shù)據(jù)安全研究[J].信息安全與通信保密，2012（8）：100-102.

[4]田龍過，閆河.智能手機APP界面設(shè)計探討[J].西部廣播電視，2014（21）：153-154.

[5]劉朝華.基于iOS平臺車位共享系統(tǒng)設(shè)計與實現(xiàn)[J].物聯(lián)網(wǎng)技術(shù)，2017，7（3）：101-103.

[6]凌寧.基于iOS系統(tǒng)的安全性研究[D].北京：北京郵電大學(xué)，2014.

[7]周高木.基于iOS的動態(tài)幾何研究與實現(xiàn)[D].成都：電子科技大學(xué)，2012.

[8]楊蕙馨，王碩，馮文娜.網(wǎng)絡(luò)效應(yīng)視角下技術(shù)標準的競爭性擴散——來自Android之爭的實證研究[J].中國工業(yè)經(jīng)濟，2014（9）：135-147.