基于iOS平臺(tái)智能點(diǎn)餐系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)*

周建亮 北京郵電大學(xué)網(wǎng)絡(luò)與交換技術(shù)國家重點(diǎn)實(shí)驗(yàn)室東信北郵信息技術(shù)有限公司

朱曉民 北京郵電大學(xué)網(wǎng)絡(luò)與交換技術(shù)國家重點(diǎn)實(shí)驗(yàn)室東信北郵信息技術(shù)有限公司

1 引言

近年來移動(dòng)互聯(lián)網(wǎng)的發(fā)展呈現(xiàn)出勢不可擋的勢頭，在信息化時(shí)代，人們的生活節(jié)奏越來越快，時(shí)間對于任何人來說都是很重要的。當(dāng)用戶拿到一張菜單時(shí)，面對很多菜品信息，瀏覽所有的菜品信息非常耗時(shí)，且對菜品的選擇也比較耗費(fèi)精力。因此，餐飲業(yè)智能點(diǎn)餐系統(tǒng)是非常有必要的。當(dāng)下移動(dòng)終端的APP開發(fā)正好非常契合餐飲業(yè)點(diǎn)餐的需求，它的便利、易操作等特性深受人們的喜愛，因此本文在iOS平臺(tái)的基礎(chǔ)上設(shè)計(jì)并實(shí)現(xiàn)了一套智能點(diǎn)餐系統(tǒng)。

2 系統(tǒng)總體設(shè)計(jì)與模塊分析

該系統(tǒng)分為兩部分：一部分是UI展示及用戶信息的收集，呈現(xiàn)在iPad端；另一部分是Server端，負(fù)責(zé)對數(shù)據(jù)進(jìn)行處理。

圖1是整個(gè)系統(tǒng)的結(jié)構(gòu)圖，每一部分是一個(gè)模塊，下面將簡單介紹各個(gè)模塊的功能。

圖1 系統(tǒng)總體架構(gòu)圖

2.1 登錄模塊

登錄模塊主要有3個(gè)功能：?？停ㄊ侵高^去在餐廳有就餐記錄的用戶）登錄驗(yàn)證、非?？偷卿?、新用戶注冊。登錄模塊主要流程如圖2所示。

圖2 登錄模塊流程圖

商家對于?？团c非常客的推薦是不同的，因此需要區(qū)分這兩種登錄模式。對于?？蛠碚f商家有常客的歷史記錄，因此登錄后產(chǎn)生的推薦信息是與非?？偷膬?nèi)容不一樣的。另外，在登錄模塊中還需要有注冊模塊，注冊模塊主要就是收集新用戶個(gè)人信息。另外，還有一點(diǎn)是流程圖中所沒有表現(xiàn)出來的，無論對于哪一種登錄方式，用戶都可能登錄失敗，因此登錄失敗后，系統(tǒng)會(huì)彈出一個(gè)Alertview（提示框），用于提示用戶登錄失敗的原因。登錄失敗原因可能會(huì)有很多，但一般可以分為兩類，一類是用戶輸入有問題；另一類是系統(tǒng)原因，而系統(tǒng)原因有可能是網(wǎng)絡(luò)故障或者后臺(tái)數(shù)據(jù)庫出問題等。當(dāng)?shù)卿浭r(shí)，系統(tǒng)需要告知用戶出錯(cuò)的原因。

2.2 分類模塊

這部分會(huì)按照分類展示菜品，如按照主食、湯菜、酒水、肉菜、素菜、涼菜分類，目的就是在用戶不接受系統(tǒng)提供的推薦菜品時(shí)，可以讓用戶快速地按照分類信息尋找自己需要的菜品。

2.3 菜品模塊

這個(gè)模塊比較簡單，就是提供菜品相關(guān)的詳細(xì)信息，如菜品的圖片、介紹菜品的短視頻、菜品的文字介紹，其他用戶對菜品的詳細(xì)評價(jià)信息。主要是幫助用戶了解當(dāng)前菜品的相關(guān)詳細(xì)信息。

這個(gè)模塊還有另外一個(gè)重要的信息，就是顯示當(dāng)前菜品被點(diǎn)的份數(shù)，從用戶角度來講這個(gè)需求是很合理的，有的時(shí)候用戶可能又回到之前已經(jīng)點(diǎn)過的菜品信息了，而用戶可能記得不大清楚是否已點(diǎn)過此菜品，這里會(huì)用到一種稱為觀察者的設(shè)計(jì)模式。

2.4 訂單模塊

這個(gè)部分相對來說是比較重要的，從客戶端到Server端對于整個(gè)推薦系統(tǒng)來說都是異常關(guān)鍵的。當(dāng)用戶的一次訂單信息產(chǎn)生后，我們需要將這部分信息記錄下來，將這部風(fēng)信息記錄到數(shù)據(jù)庫中，是推薦部分的數(shù)據(jù)基礎(chǔ)。如圖3所示，對于訂單頁中的每一份菜品，我們還可以增加、減少份數(shù)。另外，如果用戶覺得某個(gè)菜品不需要了，還可以刪除。當(dāng)然，當(dāng)用戶需要?jiǎng)h除的時(shí)候會(huì)彈出一個(gè)Alertview來提示用戶確認(rèn)刪除以防止用戶錯(cuò)誤地刪除某個(gè)需要的菜品。最后，當(dāng)用戶確定了菜品后，就可以提交菜單了。

圖3 訂單模塊圖

2.5 Data Manager模塊

這個(gè)模塊是為了簡化數(shù)據(jù)業(yè)務(wù)處理，減少模塊之間的耦合度，使用了設(shè)計(jì)模式中的外觀模式，也是面向接口編程的一種實(shí)現(xiàn)方案。具體接口設(shè)計(jì)如圖4所示。

圖4 Data Manager接口設(shè)計(jì)圖

由于接口比較多，圖4中只是一部分的接口。這個(gè)接口是全局都要訪問的，因此可以看到sharedData這個(gè)類函數(shù)，這個(gè)類函數(shù)的功能就是把此類設(shè)計(jì)成了一個(gè)單例類。無論是哪個(gè)模塊需要什么數(shù)據(jù)只要訪問這個(gè)類就可以，任何模塊都不需要知道具體是怎么實(shí)現(xiàn)的，只需要處理返回的數(shù)據(jù)與錯(cuò)誤信息。當(dāng)返回?cái)?shù)據(jù)有誤時(shí)，可以提示相關(guān)的信息。

2.6 AF Networking模塊

這個(gè)模塊主要就是負(fù)責(zé)iPad客戶端與服務(wù)器端的網(wǎng)絡(luò)交互，使用的技術(shù)主要是NSURLConnection以及NSOperation技術(shù)，實(shí)現(xiàn)了多線程并發(fā)的功能，提高了客戶端與服務(wù)器的交互效率。

2.7 Cache模塊

Cache模塊的功能主要是提供在客戶端的緩存功能，主要目的就是為了提高存取數(shù)據(jù)的效率，最終目的是為了改善用戶體驗(yàn)，使用的是LRU算法，并且設(shè)計(jì)了二級(jí)緩存策略，如圖5所示。

之所以會(huì)設(shè)計(jì)這個(gè)模塊，也是因?yàn)樵趯?shí)現(xiàn)過程中發(fā)現(xiàn)了一些確實(shí)存在的問題。整個(gè)系統(tǒng)要展示很多的圖片，而圖片的資源又非常大，導(dǎo)致于一旦瀏覽過多的圖片資源會(huì)使得整個(gè)系統(tǒng)的內(nèi)存負(fù)擔(dān)增大。使用Instrument工具，觀察整個(gè)系統(tǒng)的運(yùn)行狀況可以發(fā)現(xiàn)，當(dāng)瀏覽一個(gè)新菜品信息時(shí)，整個(gè)系統(tǒng)內(nèi)存增加了2～3M的數(shù)據(jù)，多的時(shí)候甚至達(dá)到6M，這是很可怕的數(shù)據(jù)，很容易發(fā)生Memory Warning，很可能系統(tǒng)就會(huì)Crash。根據(jù)檢測結(jié)果發(fā)現(xiàn)這些數(shù)據(jù)并沒有被及時(shí)地釋放，所以本系統(tǒng)隨后又增加了這個(gè)模塊，以使訪問速度與內(nèi)存占用空間達(dá)到一個(gè)比較好的平衡。

圖5 Cache模塊流程圖

2.8 Server模塊

負(fù)責(zé)處理用戶請求，根據(jù)用戶的請求做出相應(yīng)的反應(yīng)并與數(shù)據(jù)庫進(jìn)行交互，進(jìn)行數(shù)據(jù)的存取操作。

2.9 數(shù)據(jù)庫模塊

數(shù)據(jù)庫是用于存儲(chǔ)數(shù)據(jù)的倉庫，使用的技術(shù)是MySQL。

2.10 推薦模塊

推薦模塊分為兩個(gè)部分，一個(gè)是iPad客戶端的部分，另外一個(gè)部分是服務(wù)器端，iPad客戶端用戶展示推薦菜品的展示，也就是我們所能看見的部分。

服務(wù)器端是非常關(guān)鍵的部分，為達(dá)到“智能”的目的，除了采用已經(jīng)比較成熟的推薦算法外，筆者還設(shè)計(jì)了一套基于“人數(shù)”的推薦策略。經(jīng)常會(huì)遇到這樣的場景：若干人去餐廳就餐，然后服務(wù)員把菜單拿上來，點(diǎn)菜的時(shí)候無從下手，推來推去，最后比較浪費(fèi)時(shí)間，而且點(diǎn)的菜也不一定合適。而筆者設(shè)計(jì)的這套推薦策略能比較智能地解決這個(gè)問題。眾所周知一般情況下，固定人數(shù)點(diǎn)的菜品數(shù)量一般變化不大而且非常相近的菜也不會(huì)點(diǎn)兩份?；谶@樣的情況，首先基于人數(shù)推薦若干套同樣人數(shù)大眾所喜愛的菜品，然后用戶會(huì)從這若干套菜品中選擇一套比較符合他們期望的菜品，但有可能會(huì)有一兩個(gè)菜品可能有忌口或者不是很合適，需要替換，這時(shí)系統(tǒng)會(huì)使用協(xié)同過濾算法推薦相近的菜品（見圖6）。

圖6 基于“人數(shù)”的推薦策略圖

●對于非?？偷耐扑]

很顯然非?？蜎]有歷史點(diǎn)餐記錄，因此對于這部分用戶，商家沒有辦法按照其歷史記錄來推薦菜品。但可以按照其他用戶的數(shù)據(jù)來為非?？陀脩敉扑]菜品，按照其他用戶對菜品的評價(jià)而從中分析計(jì)算出得分比較高的內(nèi)容推薦給這部分用戶。這是這個(gè)系統(tǒng)最基礎(chǔ)的推薦部分。

首先，肯定要看用戶是否選擇基于人數(shù)的推薦，若不選擇則推薦給所有其他用戶評價(jià)比較高的菜品，當(dāng)選擇一道菜品后，然后推薦與該道菜品關(guān)聯(lián)度最高的菜品，則進(jìn)入人數(shù)推薦的策略。

●對于常客的推薦

?？团c非?？褪怯袇^(qū)別的，因?yàn)槌？蛽碛凶约旱臍v史數(shù)據(jù)，可以按照歷史數(shù)據(jù)來產(chǎn)生推薦菜品。

3 關(guān)鍵技術(shù)

3.1 多線程技術(shù)

由于終端需要與服務(wù)器交互，因此必然會(huì)涉及到異步請求數(shù)據(jù)，這部分會(huì)對整個(gè)系統(tǒng)的用戶體驗(yàn)產(chǎn)生很大的影響，其中用到的多線程技術(shù)主要有：

●NSThread，這是比較輕量的線程技術(shù)，每個(gè)線程的生命周期都是自己管理的，使用起來可能有點(diǎn)麻煩。

●NSOperation，這是面向?qū)ο蟮囊环N線程管理技術(shù)，使用起來比較方便，可以很好地控制任務(wù)并發(fā)數(shù)量，并且可以添加人物之間的相互依賴關(guān)系。

●GCD，這一套多線程技術(shù)，底層全部是通過C函數(shù)實(shí)現(xiàn)的，可以比較高效地利用系統(tǒng)CPU資源。

3.2 Runoop技術(shù)

Runloop是與多線程相互配合的一種技術(shù)，Runoop事實(shí)上可以被理解為Event Cycle（事件循環(huán)），簡單地說就是可以提高CPU的使用效率。比如進(jìn)行網(wǎng)絡(luò)資源的獲取時(shí)，這時(shí)候CPU不用等待就可以去干其他的事情。

3.3 設(shè)計(jì)模式

由于整個(gè)系統(tǒng)的完成都是在面向?qū)ο蟮幕A(chǔ)上，所以設(shè)計(jì)模式也是尤為關(guān)鍵的。各個(gè)模塊之間需要進(jìn)行數(shù)據(jù)的交互，為了減少各個(gè)模塊的耦合度，需要合理地利用設(shè)計(jì)模式，如MVC、觀察者模式、代理模式在系統(tǒng)中都用得非常多。

4 結(jié)束語

本文基于iOS平臺(tái)設(shè)計(jì)并實(shí)現(xiàn)了智能點(diǎn)餐系統(tǒng)，利用設(shè)計(jì)模式的相關(guān)知識(shí)使得整個(gè)系統(tǒng)的結(jié)構(gòu)非常清晰，在穩(wěn)定性、可擴(kuò)展性方面都表現(xiàn)得相當(dāng)不錯(cuò)，以后功能擴(kuò)展及維護(hù)能明顯地降低開發(fā)成本，另外使用UIKit及多線程技術(shù)使得整個(gè)系統(tǒng)的UE非常流暢。

1 張亮.推薦系統(tǒng)中協(xié)同過濾推薦算法若干問題的研究.北京郵電大學(xué).2009

2 王茜,王均波.一種改進(jìn)的協(xié)同過濾推薦算法.計(jì)算機(jī)科學(xué).2010

3 楊宏焱.企業(yè)級(jí)iOS應(yīng)用開發(fā)實(shí)戰(zhàn).2013,1

4 Joe Conway,Aaron Hillegass著.夏偉頻譯.iOS編程.2013,3

5 達(dá)爾林普爾,納斯特著.高朝勤譯.Objective-C基礎(chǔ)教程.人民郵電出版社.2009

6 Carlo Chung著.劉威譯.Objective-C編程之道:iOS設(shè)計(jì)模式解析.人民郵電出版社.2011