基于移動終端的食堂訂餐配送系統(tǒng)的設計與實現(xiàn)

趙宇鵬+關穎

摘 要： 學校食堂是大學生賴以生存的必要場所之一。然而每個學校的食堂在高峰時段都可以用人滿為患形容，沒有合理的秩序，沒有井然有序的排隊，取而代之的是喧鬧和你推我搡，無形中給那些餓著肚子來食堂尋找福音的學生迎頭一棒。大家不得不另覓出路，很多學生會選擇外賣，不僅會增加成本還會帶來衛(wèi)生方面的隱患。因此這里借鑒現(xiàn)有外賣訂餐系統(tǒng)開發(fā)了適用于高校食堂的訂餐配送系統(tǒng)，加速了高校食堂運營管理的數(shù)字化進程。

關鍵詞： 高校食堂 訂餐配送系統(tǒng) 數(shù)字化

隨著智能手機的應用，GPS、4G等高速網絡傳輸技術及多平臺的在線支付業(yè)務的成熟，為高校學生就餐走進學生的口袋提供了可能。針對現(xiàn)在大學食堂普遍存在的用餐高峰期擁堵、學生叫外賣貴、外賣食品衛(wèi)生得不到保證且送餐時間較長等現(xiàn)象，開發(fā)了適用于高校食堂的點餐配送系統(tǒng)，以解決學生食堂就餐難的問題。

1.需求分析

經過調查，目前食堂就餐難的問題主要由以下三點原因導致：

（1）因為上課時間相同，導致學生就餐時間重合。

（2）學生就餐前對食堂菜品種類未知，各個窗口都要問，導致食堂極其混亂擁塞。

（3）學生對菜品價格未知，導致買飯時都要問一問，食堂銷售人員不得不花時間解答，浪費了大量時間。

解決方案：對于食堂人數(shù)過多的問題，采用讓學生為學生送餐的方案，減少食堂就餐人數(shù)，即每個學生既是就餐者，又是送餐者。對于學生對菜品未知的問題，可以將每日菜單公布到網上，這樣學生就不用奔波于食堂各個檔口之間了。因此本系統(tǒng)主要實現(xiàn)下面兩大功能：（1）展示食堂每個檔口的菜品的詳細信息，方便學生點餐。（2）為送餐者和訂餐者提供交互平臺。

2.開發(fā)流程

（1）確定開發(fā)平臺

本系統(tǒng)是基于互聯(lián)網實現(xiàn)的，因此選定了主流的TCP特性網絡交互模式，其中就是否選擇點對點模式還是外接服務器模式進行了激烈的討論。在考慮到校園網的種種限制后，還選擇了外接服務器的方式。而移動端，考慮到WEB頁面?zhèn)鬏斔牧髁枯^多，響應時間較原聲控件慢等因素，最終選擇了目前市場占有率最高的Android平臺而舍棄了HTML5網頁平臺。

（2）系統(tǒng)設計

本系統(tǒng)共有四種角色，分別是管理員（校方使用）、商家（食堂使用）、送餐人（兼職學生使用）和訂餐人（學生使用）。四個角色有不同的客戶端，有不同的私鑰，由服務器統(tǒng)一管理，即使仿制客戶端無法獲得其他用戶組的權限。

（3）系統(tǒng)流程

本系統(tǒng)的流程圖如下圖所示。

3.細節(jié)問題處理

（1）訂單配送問題

系統(tǒng)在設計過程中遇到的第一個難點就是訂餐者所下的訂單如何分配給送餐者，經過研究討論決定實行以下方案：

①同宿舍的送餐員將優(yōu)先收到訂單，不同宿舍的送餐員將在訂單生成的5分鐘之后才能收到此訂單。

②送餐員在獲取送餐列表時進行一次訂單刷新，在其他送餐員瀏覽該訂單的詳細信息時，通過推送方式告訴其他送餐員（類似于微信顯示的“對方正在輸入……”），本軟件將顯示：“其他送餐員正在瀏覽”，以確保送餐員實時掌握訂單信息。當其他送餐員接單后，服務器將發(fā)送信息通知客戶端將此訂單刪除，該信息需要客戶端發(fā)送回執(zhí)，以確保信息準確送達。當客戶端處于前臺可見狀態(tài)時，系統(tǒng)將啟用長連接模式，保證信息的實時更新（其他狀態(tài)將使用心跳連接模式）。

（2）客戶端保活問題

客戶端保活的意思就是客戶端的服務程序要一直駐留在內存中為客戶提供服務，除非客戶在設置中手動關閉。這個問題是一個非常棘手的問題，因為目前主流的外賣軟件，如“餓了么”、“百度外賣”也沒有得到徹底的解決，導致該問題的主要原因有：

①Android系統(tǒng)的升級，使得其內存機制愈發(fā)嚴格。在Android4.0及以下，前臺服務是很難被殺死的，而Android 4.1.1后，前臺服務被殺是輕而易舉的。在Android 6.0之后，通過JNI使用C程序fork出的進程與其同一進程組的進程會一同被殺死。

②國內廠商定制的ROM及360等安全軟件對進程的管制。目前，國內手機大都有自己定制的手機系統(tǒng)，如華為的EMUI，小米的MIUI，魅族的Flyme等，廠商為了提高市場競爭力，對Android進程的清理要比Google原生系統(tǒng)還要嚴格。

探索過程及解決方案：

第一次，嘗試將Service設置為前臺進程的方案，有了前臺進程的優(yōu)先級，在android系統(tǒng)清理內存的時候，被殺死的優(yōu)先級僅高于前臺的activity，也就是正在和用戶交互的頁面，可是經過實踐后發(fā)現(xiàn)，在系統(tǒng)設置的正在運行中殺進程本身就不具威脅，在系統(tǒng)設置的所有應用中選擇強行停止，仍然可以強停掉。

第二次，嘗試添加廣播監(jiān)聽android.intent.action.USER_ PRESENT事件的監(jiān)聽，通過靜態(tài)注冊廣播接收者監(jiān)聽用戶解鎖，在用戶解鎖屏幕時，檢查服務是否正在運行。但是這個事件只有解鎖才有，如果用戶沒有設置鎖屏，那么這個事件就是沒有的。

第三次，嘗試設置鬧鐘定時喚醒的方式。起初不知道這種方式，后來在尋找解決辦法的過程中，反編了微信、QQ的程序，發(fā)現(xiàn)他們用的就是這種方式，但是用在本系統(tǒng)上并不好用。后來經過查資料得知，國產的oem廠商把微信、QQ加入免殺名單，自然不會被殺死。

經過多次失敗，在近乎絕望的時候，通過反編美圖秀秀這個應用，又看到新的曙光，那就是Native層保活。發(fā)現(xiàn)安卓系統(tǒng)的一個漏洞，安卓系統(tǒng)在force close進程的時候，系統(tǒng)忽略c進程的存在。可是后來更新系統(tǒng)到6.0后這個方法又不靈了，經過查資料得知這個漏洞在6.0系統(tǒng)上修復了。

于是又在Native層進行了進一步的探索：

模仿計算機安全課上分析的金豬報喜病毒，那個病毒開了兩個進程相互守護，就用這個病毒解決問題，但是嘗試時發(fā)現(xiàn)不到十分鐘手機就燙手了，雖然目的達到了，但是顯然不合理。

之后又想到操作系統(tǒng)課上講的文件鎖，不論Windows還是linux都有一套文件的進程同步機制，為了各個進程間文件的同步問題，一個進程可以給一個文件上鎖，操作完了之后再解鎖，其他進程如果擔心同步問題，會首先檢查一下文件是否有鎖，如果有鎖，代表別人正在操作，就會延遲對文件的操作。

再結合需求：

ⅰ需要讓a進程先把文件1鎖了，然后不讀文件。

ⅱ等b進程做同樣的操作之后，兩邊同時讀取對方的鎖。

最后的同步方案是：

ⅰ4個文件，a進程文件a1，a，b進程文件b1，b2。

ⅱa進程加鎖文件a，b進程同理。

ⅲa進程創(chuàng)建a2文件，然后輪詢查看b2文件是否存在，如果不存在，代表b進程還沒創(chuàng)建，b進程同理

ⅳa進程輪詢到b2文件存在了，代表b進程已經創(chuàng)建并可能在對b1文件加鎖，此時刪除文件b2，代表a進程已經加鎖完畢，允許b進程讀取a進程的鎖，b進程同理。

ⅴa進程監(jiān)聽文件a2，如果a2被刪除，代表b進程進行到了步驟4，已經對b1加鎖完成，可以開始讀取b1文件的鎖，b進程同理。

同步完成后，兩個進程同時監(jiān)聽對方的鎖，一方掛掉另一方立刻可以監(jiān)聽到。這套方案在5.0+上可以做到互相監(jiān)聽對方死亡狀態(tài)，因為都是阻塞方法，所以無耗電效率問題。

（3）時間問題

在5.1上，鬧鐘在被強制關閉后，同樣會失效，之前的拉起方案行不通了，那么開始想如何將對方的進程拉起來通過打印log，仔細觀察發(fā)現(xiàn)，強制關閉的時候，系統(tǒng)殺應用對應進程的時候，速度非常快。

查看源碼，可以看出intent的發(fā)送實際上是Activity Manager Native這個類，它持有一個binder，用來與系統(tǒng)的Activity Manager Service通信，當發(fā)送intent的時候會初始化一個Parcel，通過binder transcate發(fā)送出去。時間都消耗在了Parcel的創(chuàng)建上。于是將耗時操作放在進程開始的時候完成，等到監(jiān)聽到進程掛掉，直接調用。經過測試，5.1上可以實現(xiàn)雙向守護，但是很遺憾，6.0上又不好用。

經過進一步排查，發(fā)現(xiàn)通過以上方式用binder transcate的方法無法啟動一個service。后來經過嘗試發(fā)現(xiàn)廣播是可以實現(xiàn)預期功能的。同樣的原理用Activity Manager Native中的binder transcate一個Parcel啟動一個BroadCast拉起進程。這樣6.0系統(tǒng)也可以實現(xiàn)保活。

4.結語

這款基于ANDROID平臺的點餐配送軟件對整個食堂的運行可以說是一把來自于萊克辛頓中的槍，具有里程碑的作用，它使食堂的工作發(fā)生質的改變。但是客觀上存在不足，如界面粗糙，壓力測試過程中發(fā)現(xiàn)在用戶過萬以后，數(shù)據(jù)庫服務器過載等問題。因此，將在今后工作中不斷完善這個系統(tǒng)，爭取做得更好。

參考文獻：

[1]BillPhillips，BrianHardy.Android編程權威指南[M].北京：人民郵電出版社，2014.

[2]徐宜生.Android群英傳[M].北京：電子工業(yè)出版社，2015.

[3]任玉剛.Android開發(fā)藝術探索[M].北京：電子工業(yè)出版社，2015.

[4]李剛.輕量級JavaEE企業(yè)應用實戰(zhàn)[M].北京：電子工業(yè)出版社，2014.

[5]周志明.深入理解JAVA虛擬機[M].北京：機械工業(yè)出版社，2013.