趙宇鵬+關(guān)穎

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

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

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

1.需求分析

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

（1）因?yàn)樯险n時(shí)間相同，導(dǎo)致學(xué)生就餐時(shí)間重合。

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

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

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

2.開發(fā)流程

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

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

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

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

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

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

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

（1）訂單配送問題

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

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

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

（2）客戶端保活問題

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

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

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

探索過程及解決方案：

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

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

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

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

于是又在Native層進(jìn)行了進(jìn)一步的探索：

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

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

再結(jié)合需求：

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

ⅱ等b進(jìn)程做同樣的操作之后，兩邊同時(shí)讀取對(duì)方的鎖。

最后的同步方案是：

ⅰ4個(gè)文件，a進(jìn)程文件a1，a，b進(jìn)程文件b1，b2。

ⅱa進(jìn)程加鎖文件a，b進(jìn)程同理。

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

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

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

同步完成后，兩個(gè)進(jìn)程同時(shí)監(jiān)聽對(duì)方的鎖，一方掛掉另一方立刻可以監(jiān)聽到。這套方案在5.0+上可以做到互相監(jiān)聽對(duì)方死亡狀態(tài)，因?yàn)槎际亲枞椒?，所以無(wú)耗電效率問題。

（3）時(shí)間問題

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

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

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

4.結(jié)語(yǔ)

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

參考文獻(xiàn)：

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

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

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

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

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