基于移动终端的食堂订餐配送系统的设计与实现

赵宇鹏+关颖

摘 要： 学校食堂是大学生赖以生存的必要场所之一。然而每个学校的食堂在高峰时段都可以用人满为患形容，没有合理的秩序，没有井然有序的排队，取而代之的是喧闹和你推我搡，无形中给那些饿着肚子来食堂寻找福音的学生迎头一棒。大家不得不另觅出路，很多学生会选择外卖，不仅会增加成本还会带来卫生方面的隐患。因此这里借鉴现有外卖订餐系统开发了适用于高校食堂的订餐配送系统，加速了高校食堂运营管理的数字化进程。

关键词： 高校食堂 订餐配送系统 数字化

随着智能手机的应用，GPS、4G等高速网络传输技术及多平台的在线支付业务的成熟，为高校学生就餐走进学生的口袋提供了可能。针对现在大学食堂普遍存在的用餐高峰期拥堵、学生叫外卖贵、外卖食品卫生得不到保证且送餐时间较长等现象，开发了适用于高校食堂的点餐配送系统，以解决学生食堂就餐难的问题。

1.需求分析

经过调查，目前食堂就餐难的问题主要由以下三点原因导致：

（1）因为上课时间相同，导致学生就餐时间重合。

（2）学生就餐前对食堂菜品种类未知，各个窗口都要问，导致食堂极其混乱拥塞。

（3）学生对菜品价格未知，导致买饭时都要问一问，食堂销售人员不得不花时间解答，浪费了大量时间。

解决方案：对于食堂人数过多的问题，采用让学生为学生送餐的方案，减少食堂就餐人数，即每个学生既是就餐者，又是送餐者。对于学生对菜品未知的问题，可以将每日菜单公布到网上，这样学生就不用奔波于食堂各个档口之间了。因此本系统主要实现下面两大功能：（1）展示食堂每个档口的菜品的详细信息，方便学生点餐。（2）为送餐者和订餐者提供交互平台。

2.开发流程

（1）确定开发平台

本系统是基于互联网实现的，因此选定了主流的TCP特性网络交互模式，其中就是否选择点对点模式还是外接服务器模式进行了激烈的讨论。在考虑到校园网的种种限制后，还选择了外接服务器的方式。而移动端，考虑到WEB页面传输所耗流量较多，响应时间较原声控件慢等因素，最终选择了目前市场占有率最高的Android平台而舍弃了HTML5网页平台。

（2）系统设计

本系统共有四种角色，分别是管理员（校方使用）、商家（食堂使用）、送餐人（兼职学生使用）和订餐人（学生使用）。四个角色有不同的客户端，有不同的私钥，由服务器统一管理，即使仿制客户端无法获得其他用户组的权限。

（3）系统流程

本系统的流程图如下图所示。

3.细节问题处理

（1）订单配送问题

系统在设计过程中遇到的第一个难点就是订餐者所下的订单如何分配给送餐者，经过研究讨论决定实行以下方案：

①同宿舍的送餐员将优先收到订单，不同宿舍的送餐员将在订单生成的5分钟之后才能收到此订单。

②送餐员在获取送餐列表时进行一次订单刷新，在其他送餐员浏览该订单的详细信息时，通过推送方式告诉其他送餐员（类似于微信显示的“对方正在输入……”），本软件将显示：“其他送餐员正在浏览”，以确保送餐员实时掌握订单信息。当其他送餐员接单后，服务器将发送信息通知客户端将此订单删除，该信息需要客户端发送回执，以确保信息准确送达。当客户端处于前台可见状态时，系统将启用长连接模式，保证信息的实时更新（其他状态将使用心跳连接模式）。

（2）客户端保活问题

客户端保活的意思就是客户端的服务程序要一直驻留在内存中为客户提供服务，除非客户在设置中手动关闭。这个问题是一个非常棘手的问题，因为目前主流的外卖软件，如“饿了么”、“百度外卖”也没有得到彻底的解决，导致该问题的主要原因有：

①Android系统的升级，使得其内存机制愈发严格。在Android4.0及以下，前台服务是很难被杀死的，而Android 4.1.1后，前台服务被杀是轻而易举的。在Android 6.0之后，通过JNI使用C程序fork出的进程与其同一进程组的进程会一同被杀死。

②国内厂商定制的ROM及360等安全软件对进程的管制。目前，国内手机大都有自己定制的手机系统，如华为的EMUI，小米的MIUI，魅族的Flyme等，厂商为了提高市场竞争力，对Android进程的清理要比Google原生系统还要严格。

探索过程及解决方案：

第一次，尝试将Service设置为前台进程的方案，有了前台进程的优先级，在android系统清理内存的时候，被杀死的优先级仅高于前台的activity，也就是正在和用户交互的页面，可是经过实践后发现，在系统设置的正在运行中杀进程本身就不具威胁，在系统设置的所有应用中选择强行停止，仍然可以强停掉。

第二次，尝试添加广播监听android.intent.action.USER_ PRESENT事件的监听，通过静态注册广播接收者监听用户解锁，在用户解锁屏幕时，检查服务是否正在运行。但是这个事件只有解锁才有，如果用户没有设置锁屏，那么这个事件就是没有的。

第三次，尝试设置闹钟定时唤醒的方式。起初不知道这种方式，后来在寻找解决办法的过程中，反编了微信、QQ的程序，发现他们用的就是这种方式，但是用在本系统上并不好用。后来经过查资料得知，国产的oem厂商把微信、QQ加入免杀名单，自然不会被杀死。

经过多次失败，在近乎绝望的时候，通过反编美图秀秀这个应用，又看到新的曙光，那就是Native层保活。发现安卓系统的一个漏洞，安卓系统在force close进程的时候，系统忽略c进程的存在。可是后来更新系统到6.0后这个方法又不灵了，经过查资料得知这个漏洞在6.0系统上修复了。

于是又在Native层进行了进一步的探索：

模仿计算机安全课上分析的金猪报喜病毒，那个病毒开了两个进程相互守护，就用这个病毒解决问题，但是尝试时发现不到十分钟手机就烫手了，虽然目的达到了，但是显然不合理。

之后又想到操作系统课上讲的文件锁，不论Windows还是linux都有一套文件的进程同步机制，为了各个进程间文件的同步问题，一个进程可以给一个文件上锁，操作完了之后再解锁，其他进程如果担心同步问题，会首先检查一下文件是否有锁，如果有锁，代表别人正在操作，就会延迟对文件的操作。

再结合需求：

ⅰ需要让a进程先把文件1锁了，然后不读文件。

ⅱ等b进程做同样的操作之后，两边同时读取对方的锁。

最后的同步方案是：

ⅰ4个文件，a进程文件a1，a，b进程文件b1，b2。

ⅱa进程加锁文件a，b进程同理。

ⅲa进程创建a2文件，然后轮询查看b2文件是否存在，如果不存在，代表b进程还没创建，b进程同理

ⅳa进程轮询到b2文件存在了，代表b进程已经创建并可能在对b1文件加锁，此时删除文件b2，代表a进程已经加锁完毕，允许b进程读取a进程的锁，b进程同理。

ⅴa进程监听文件a2，如果a2被删除，代表b进程进行到了步骤4，已经对b1加锁完成，可以开始读取b1文件的锁，b进程同理。

同步完成后，两个进程同时监听对方的锁，一方挂掉另一方立刻可以监听到。这套方案在5.0+上可以做到互相监听对方死亡状态，因为都是阻塞方法，所以无耗电效率问题。

（3）时间问题

在5.1上，闹钟在被强制关闭后，同样会失效，之前的拉起方案行不通了，那么开始想如何将对方的进程拉起来通过打印log，仔细观察发现，强制关闭的时候，系统杀应用对应进程的时候，速度非常快。

查看源码，可以看出intent的发送实际上是Activity Manager Native这个类，它持有一个binder，用来与系统的Activity Manager Service通信，当发送intent的时候会初始化一个Parcel，通过binder transcate发送出去。时间都消耗在了Parcel的创建上。于是将耗时操作放在进程开始的时候完成，等到监听到进程挂掉，直接调用。经过测试，5.1上可以实现双向守护，但是很遗憾，6.0上又不好用。

经过进一步排查，发现通过以上方式用binder transcate的方法无法启动一个service。后来经过尝试发现广播是可以实现预期功能的。同样的原理用Activity Manager Native中的binder transcate一个Parcel启动一个BroadCast拉起进程。这样6.0系统也可以实现保活。

4.结语

这款基于ANDROID平台的点餐配送软件对整个食堂的运行可以说是一把来自于莱克辛顿中的枪，具有里程碑的作用，它使食堂的工作发生质的改变。但是客观上存在不足，如界面粗糙，压力测试过程中发现在用户过万以后，数据库服务器过载等问题。因此，将在今后工作中不断完善这个系统，争取做得更好。

参考文献：

[1]BillPhillips，BrianHardy.Android编程权威指南[M].北京：人民邮电出版社，2014.

[2]徐宜生.Android群英传[M].北京：电子工业出版社，2015.

[3]任玉刚.Android开发艺术探索[M].北京：电子工业出版社，2015.

[4]李刚.轻量级JavaEE企业应用实战[M].北京：电子工业出版社，2014.

[5]周志明.深入理解JAVA虚拟机[M].北京：机械工业出版社，2013.