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

趙宇鵬+關(guān)穎

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

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

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

1.需求分析

經(jīng)過調(diào)查，目前食堂就餐難的問題主要由以下三點原因?qū)е拢?/p>

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

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

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

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

2.開發(fā)流程

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

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

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

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

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

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

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

（1）訂單配送問題

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

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

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

（2）客戶端?；顔栴}

客戶端?；畹囊馑季褪强蛻舳说姆?wù)程序要一直駐留在內(nèi)存中為客戶提供服務(wù)，除非客戶在設(shè)置中手動關(guān)閉。這個問題是一個非常棘手的問題，因為目前主流的外賣軟件，如“餓了么”、“百度外賣”也沒有得到徹底的解決，導(dǎo)致該問題的主要原因有：

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

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

探索過程及解決方案：

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

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

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

經(jīng)過多次失敗，在近乎絕望的時候，通過反編美圖秀秀這個應(yīng)用，又看到新的曙光，那就是Native層?；睢０l(fā)現(xiàn)安卓系統(tǒng)的一個漏洞，安卓系統(tǒng)在force close進程的時候，系統(tǒng)忽略c進程的存在?？墒呛髞砀孪到y(tǒng)到6.0后這個方法又不靈了，經(jīng)過查資料得知這個漏洞在6.0系統(tǒng)上修復(fù)了。

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

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

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

再結(jié)合需求：

ⅰ需要讓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進程已經(jīng)創(chuàng)建并可能在對b1文件加鎖，此時刪除文件b2，代表a進程已經(jīng)加鎖完畢，允許b進程讀取a進程的鎖，b進程同理。

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

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

（3）時間問題

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

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

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

4.結(jié)語

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

參考文獻：

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

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

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

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

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