基于iOS平臺智能點餐系統的設計與實現*

周建亮 北京郵電大學網絡與交換技術國家重點實驗室東信北郵信息技術有限公司

朱曉民 北京郵電大學網絡與交換技術國家重點實驗室東信北郵信息技術有限公司

1 引言

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

2 系統總體設計與模塊分析

該系統分為兩部分：一部分是UI展示及用戶信息的收集，呈現在iPad端；另一部分是Server端，負責對數據進行處理。

圖1是整個系統的結構圖，每一部分是一個模塊，下面將簡單介紹各個模塊的功能。

圖1 系統總體架構圖

2.1 登錄模塊

登錄模塊主要有3個功能：常客（是指過去在餐廳有就餐記錄的用戶）登錄驗證、非常客登錄、新用戶注冊。登錄模塊主要流程如圖2所示。

圖2 登錄模塊流程圖

商家對于常客與非常客的推薦是不同的，因此需要區分這兩種登錄模式。對于常客來說商家有常客的歷史記錄，因此登錄后產生的推薦信息是與非常客的內容不一樣的。另外，在登錄模塊中還需要有注冊模塊，注冊模塊主要就是收集新用戶個人信息。另外，還有一點是流程圖中所沒有表現出來的，無論對于哪一種登錄方式，用戶都可能登錄失敗，因此登錄失敗后，系統會彈出一個Alertview（提示框），用于提示用戶登錄失敗的原因。登錄失敗原因可能會有很多，但一般可以分為兩類，一類是用戶輸入有問題；另一類是系統原因，而系統原因有可能是網絡故障或者后臺數據庫出問題等。當登錄失敗時，系統需要告知用戶出錯的原因。

2.2 分類模塊

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

2.3 菜品模塊

這個模塊比較簡單，就是提供菜品相關的詳細信息，如菜品的圖片、介紹菜品的短視頻、菜品的文字介紹，其他用戶對菜品的詳細評價信息。主要是幫助用戶了解當前菜品的相關詳細信息。

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

2.4 訂單模塊

這個部分相對來說是比較重要的，從客戶端到Server端對于整個推薦系統來說都是異常關鍵的。當用戶的一次訂單信息產生后，我們需要將這部分信息記錄下來，將這部風信息記錄到數據庫中，是推薦部分的數據基礎。如圖3所示，對于訂單頁中的每一份菜品，我們還可以增加、減少份數。另外，如果用戶覺得某個菜品不需要了，還可以刪除。當然，當用戶需要刪除的時候會彈出一個Alertview來提示用戶確認刪除以防止用戶錯誤地刪除某個需要的菜品。最后，當用戶確定了菜品后，就可以提交菜單了。

圖3 訂單模塊圖

2.5 Data Manager模塊

這個模塊是為了簡化數據業務處理，減少模塊之間的耦合度，使用了設計模式中的外觀模式，也是面向接口編程的一種實現方案。具體接口設計如圖4所示。

圖4 Data Manager接口設計圖

由于接口比較多，圖4中只是一部分的接口。這個接口是全局都要訪問的，因此可以看到sharedData這個類函數，這個類函數的功能就是把此類設計成了一個單例類。無論是哪個模塊需要什么數據只要訪問這個類就可以，任何模塊都不需要知道具體是怎么實現的，只需要處理返回的數據與錯誤信息。當返回數據有誤時，可以提示相關的信息。

2.6 AF Networking模塊

這個模塊主要就是負責iPad客戶端與服務器端的網絡交互，使用的技術主要是NSURLConnection以及NSOperation技術，實現了多線程并發的功能，提高了客戶端與服務器的交互效率。

2.7 Cache模塊

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

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

圖5 Cache模塊流程圖

2.8 Server模塊

負責處理用戶請求，根據用戶的請求做出相應的反應并與數據庫進行交互，進行數據的存取操作。

2.9 數據庫模塊

數據庫是用于存儲數據的倉庫，使用的技術是MySQL。

2.10 推薦模塊

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

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

圖6 基于“人數”的推薦策略圖

●對于非常客的推薦

很顯然非常客沒有歷史點餐記錄，因此對于這部分用戶，商家沒有辦法按照其歷史記錄來推薦菜品。但可以按照其他用戶的數據來為非常客用戶推薦菜品，按照其他用戶對菜品的評價而從中分析計算出得分比較高的內容推薦給這部分用戶。這是這個系統最基礎的推薦部分。

首先，肯定要看用戶是否選擇基于人數的推薦，若不選擇則推薦給所有其他用戶評價比較高的菜品，當選擇一道菜品后，然后推薦與該道菜品關聯度最高的菜品，則進入人數推薦的策略。

●對于常客的推薦

常客與非常客是有區別的，因為常客擁有自己的歷史數據，可以按照歷史數據來產生推薦菜品。

3 關鍵技術

3.1 多線程技術

由于終端需要與服務器交互，因此必然會涉及到異步請求數據，這部分會對整個系統的用戶體驗產生很大的影響，其中用到的多線程技術主要有：

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

●NSOperation，這是面向對象的一種線程管理技術，使用起來比較方便，可以很好地控制任務并發數量，并且可以添加人物之間的相互依賴關系。

●GCD，這一套多線程技術，底層全部是通過C函數實現的，可以比較高效地利用系統CPU資源。

3.2 Runoop技術

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

3.3 設計模式

由于整個系統的完成都是在面向對象的基礎上，所以設計模式也是尤為關鍵的。各個模塊之間需要進行數據的交互，為了減少各個模塊的耦合度，需要合理地利用設計模式，如MVC、觀察者模式、代理模式在系統中都用得非常多。

4 結束語

本文基于iOS平臺設計并實現了智能點餐系統，利用設計模式的相關知識使得整個系統的結構非常清晰，在穩定性、可擴展性方面都表現得相當不錯，以后功能擴展及維護能明顯地降低開發成本，另外使用UIKit及多線程技術使得整個系統的UE非常流暢。

1 張亮.推薦系統中協同過濾推薦算法若干問題的研究.北京郵電大學.2009

2 王茜,王均波.一種改進的協同過濾推薦算法.計算機科學.2010

3 楊宏焱.企業級iOS應用開發實戰.2013,1

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

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

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