基于ANDROID和PC平臺的點餐軟件開發與數字化食堂運行

湯嘉蕾，任遂曄，張瑞杰，劉 羲 、、.上海海洋大學，上海 006 .南京農業大學，江蘇南京 0009

0 引言

眾所周知，食堂是大學生賴以生存的必要場所之一。然而，每個學校的食堂在高峰時段都可以用人滿為患來形容，沒有合理的秩序，沒有井然有序的排隊，取而代之的只有喧鬧和你推我搡，這無形的給那些餓著肚子來食堂尋找福音的學生迎頭一棒。大家不得不另尋出路，其中主要的替代方案就是外賣，不僅增加了成本也帶來了衛生方面的威脅。由此，我們小組借鑒了現有的外賣點餐系統開始了我們對食堂數字化轉變的進程。

1 理念概括

1.1 食堂信息化

我們等人希望將食堂所有菜色公開，每天堅持更新，使得同學們直白的在點餐前了解到所有菜色，從而加快點餐的速度，提高食堂效率。

1.2 點餐數字化

我們希望打造一個食堂點餐平臺，使得食堂的點餐可以加入網絡技術的元素，使其成為名符其實的E-食堂。

1.3 阿姨工作簡單，機械化

阿姨是食堂工作中的主要對象也是核心，她們的工作難度直接體現在食堂的綜合效率上，現在我們希望通過網絡，消除一些同學阿姨之間的溝通障礙，讓阿姨做一份輕松，高效率的工作。

2 初期調查&縮小范圍

在確定了我們的工作目標后，我們開展了第一步調查工作。雖然我們四人達成了共識，開始對食堂進行相應的改進措施，但是群眾基礎也是十分重要的一環。我們擬定了一些問題例如：1）您等待的極限時間是多少；2）您對食堂數字化抱有正面或負面態度。隨后我們將結果匯總，在600 份隨機調查問卷中我們驚喜的發現，98%的學生對現有的食堂效率不滿，其中又有90%的學生對數字化食堂表示期待。這不僅證明我們對食堂的改革是必要的，也在群眾中打好了良好的基礎，對后期試運行埋下了伏筆。

在確定食堂數字化的大方向后，我們需要一個主要工作方向，因為在有限的時間內我們不可能做到面面俱到。在一次討論中，一個成員又拿出了“餓了么”給我們參考，我們幾個人一拍即合決定做食堂點餐系統。起初我們決定翻版“餓了么”等知名網上點餐系統來做出一個校園食堂點餐網頁，隨后我們發現網頁打開緩沖較慢并且不太適合手機，于是我們將目光放在了服務端軟件上，我們將最終成果定義為一款點餐軟件，而不是以網頁形式來呈現。

3 需求分析&相關數據采集

我們分析一下，食堂效率低下主要原因有兩個，首先是學生不知道菜名導致學生不斷的詢問，使得阿姨浪費時間去解釋，另一個是菜價，阿姨不知道明確的菜價會給結算過程帶來不必要的麻煩，使得沒問學生打飯時間間接地被延長，使得學生的滿意度下降。所以點餐軟件必須能夠提供詳細的菜單菜價方便學生和工作人員。菜單需要分塊，分為早餐，午餐和晚餐區域，清楚易懂簡單明了。在整個界面中，可以根據用戶的愛好來將菜單按不同順序排列。

創新一直是成功的先驅，為了提高系統的科學性，吸引健康飲食的學生，我們對各種菜有卡路里統計，并且可以更具熱量的從小到大排序，讓同學們一目了然。為了提高點餐的效率，方便同學們從百余種菜色中選到心儀的可口美食，我們的系統同樣可以提供關鍵字搜索功能，以及菜單保存功能。錦上添花的是，系統同樣提供自動結算功能，每周一，消費金額將自動從卡上扣除（選擇）。

提高效率的同時，準確率也必須相應提高，點完餐后怎樣正確的拿到自己點的飯菜，個人信息的鍵入是十分的必要的，系統必須有相應的身份識別與認證這樣才能保證每位同學都能心滿意足嘗到心儀的飯菜。

在分析相關需求后，我們里除了相關需要采集的數據，它們是：

1）阿姨平均打飯時間；

2）食堂高峰時間跨度；

3）對食堂的滿意度以及對網上點餐的看法；

4）網速；

5）高峰時段食堂人數。

隨后我們開展了各項數據采集活動，我們覺得對于現在食堂的進程，阿姨打飯是其核心，我們通過觀察每一位阿姨在20min 內的打飯人數，計算出平均每位阿姨在面對一位學生的打飯時間是45s。然而通過實地觀察，我們通過從中午11 點40 分到12 點40 一小時的觀察。我們發現食堂高峰時間段為11 點50 ～12 點30 一共40min，這對我們以后系統的開放時段很有參考作用。通過調查問卷我們隨機抽了300 位學生做了調查，我們發現97%的學生對食堂的擁擠表示無奈，其中85%的學生對點餐系統很感興趣。還有一個數據是網速，我們通過4 臺筆記本 通過WIRESHARK 軟件測試了一下食堂的網速，結果發現平均網速在1.2mb ～1.4mb/S ，這對服務端來說是個很好的基礎。最后我們統計了一下高分時段的人數，這里我們運用到了一些建模的思想。我們測量了一下，一扇食堂的門有3個學生的寬度，一個食堂有平均4 個門，學生走路速度為1m每秒，高峰時段校園里人與人距離在2m 左右也就是說食堂一分鐘進360 個左右，然而我們也估算了一下食堂一層的容量為2000 人，在1000 人時顯得非常擁擠了，人也就開始不進來了，也就是說大約整個人流激增的過程為3min，進來的人數約為1080 個左右，而平均每位用餐時間為20min，20min 后，又會產生一個人數激增點。通過計算機的預測，平均一位學生的網上點餐時間為25S 而阿姨打菜時間為9S 比人工點餐節省了11S，這是一個十分可觀的結果。

4 開發進程

在定下軟件需求之后，軟件開發如火如荼的開展了起來。我們將平臺選在c#上，這是一種面向對象的、運行于.NET Framework 之上的高級程序設計語言。也是現在最主要的編程語言之一。

在確定編程語言后，系統結構也是一個重要的部分。我們毫不猶豫的先行采用了主流的TCP 特性網絡交互模式，其中在是否選擇點對點模式或者外接服務器模式，我們進行了激烈的討論。在考慮到校園網的種種限制后，我們還是選擇了外接服務器框架模式， 如圖：

服務器和客戶端是單獨開發的，而軟件最大的難點是在網絡架構上即客戶端與服務端的連接。我們首先使用計算機Ip地址和端口號創建一個System.Net.Sockets.TcpListener 類型的實例，然后在該實例上調用Start()方法，從而開啟對指定端口的偵聽。而后通過netstat-a 命令行 使客戶端的代碼建立起了連接，服務器端開始偵聽以后，可以在TcpListener實例上調用預定義方法來獲取與一個客戶端的連接。從而使得客戶端和服務端連通起來。在解決一系列的難題后，我們預期的基于PC 平臺的軟件大功告成。在下載了幾個皮膚包以后，一個漂亮的系統雛形呈現在我們面前。

在完成PC 平臺上的軟件后，我們覺得有必要將這款軟件做的更人性化，最完美的選擇就是將其移植到安卓平臺。雖說是移植，但是對于服務端來說是一定要重新編程的，這無疑對我們小組成員來說是個巨大的挑戰，因為沒有一個成員接觸過安卓系統，但是我們抱著奮斗精神，一邊看著書一邊開始實踐。首先我們開始搭建安卓平臺，我們從谷歌上下載了帶adt的eclipse，安裝jdk 后我們正式的開啟了安卓軟件開發。我們首先試著將Android 端和原有服務端相連接，但是被拒絕，這時的我們煞費苦心的去尋找原因，在經過4,5 個日日夜夜的奮斗后，我們得知安卓2.3 以后為提高用戶體驗主線程禁止聯網 聯網需要建立子線程 把api 等級改為9（2.3） 問題解決。但與此同時我們發現了傳輸數據亂碼的問題，于是我們繼續尋找原因所在。在查找網上資料后，我們得知c#（服務端）與java（客戶端，android）的編碼方式不同造成的 同時改為UTF-8 即可解決亂碼問題。到此為止網絡構架問題基本解決，開發過程也沒有遇到什么大問題，在努力一個月后，我們終于將我們開發的APP 連接上了電腦的服務端，到此我們的開發宣告結束。整個項目也完成了80%。

5 結論

這款基于ANDROID 和PC 平臺的點餐軟件對整個食堂的運行可以說是一把來自于萊克辛頓中的槍，具有里程碑時的作用，它使食堂的工作發生了質的改變。但是我們也很客觀的看到了它的不足，比如界面粗糙，網絡連接時常出現錯誤等。這也是很好的發展空間，需要我們進一步努力去將它完善，并且運用到實際中去。

[1]靳巖，姚尚朗.Google Android開發入門與實戰[M].人民郵電出版社.

[2]Christian Nagel,Bill Evjen,Jay Glynn.Professimal C# 4 and NET 4[M].Wiley Publishing.

[3]Android開發文檔.[Online]Available：http：//developer.android.com.

[4]微軟MSDN.[Online]Available：http：//msdn.microsoft.com/zh-cn/.

[5]葉達峰.Eclipse編程技術與實例[M].北京人民郵電出版社，2006.

[6]Java Socket與C#通信中中文亂碼問題的解決方案.[Online]Available：http：//blog.csdn.net/aboy123/article/details/8274858.