基于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.