第1篇：打车app阅读练习及答案
打车app阅读练习及答案
打车 App
①在北京上地的某软件园周边，十几辆出租车闲散地停在路旁。一辆出租车内，的哥打着盹，时不时地望一眼架在仪表台上的手机，时刻等待着来自打车APP的“嘀嘀”召唤。
②为了在北京上地这个偏离市中心的地方方便拉上顾客，两个月前，的哥们都装上了各种打车APP。打车App软件又称手机打车软件，简称打车软件，是一类可安装在智能手机系统中的应用客户端。利用智能手机的GPS数据，地理信息系统和相应推送服务机制，实现乘客和司机之间的信息交互。
③人们下载了这种手机客户端，就能随时随地叫车。在打车软件上注册手机号后，手机自动定位，地图上可以看到周边5公里有众多出租车可供选择，按下“按住说话”键说出自己要去的目的地，并进行发送，可选择加价金额。叫车后稍许等待，界面会跳出“订车成功”的提示，随即订购到的出租车司机电话联系打车乘客。而出租车上可装起多个智能终端，随时接受乘客叫车。
④打车软件缓解了人、车之间信息不对称的矛盾，具有广泛的生存基础。根据中国社科院新近发布的调查报告，在北京等一些城市，53.77%的人打车需要等10分钟以上；另一方面，出租车的空驶率非常高，有时甚至能达到40%，加剧了城市拥堵。打车软件提供的信息撮合机制，减少了出租车的空驶时间，提升了利用率，其在缓解打车难问题方面具有突出的优势。
⑤按照打车软件的约车规则，乘客在叫车时，可以主动加价以吸引出租车司机愿意来载客。比如，本来正常打表，要20元车费，但在早晚高峰打不到车的时候，乘客在叫车时可选择加5元、加10元、加20元等选项，以提高叫车的成功率，这一点违反了出租车不得议价的规定。这加剧了出租车资源的分配不公。在加价机制的“激励”下，可能会导致加价现象蔓延、市场混乱。
⑥打车软件的`司机注册时，无法核验，容易混入假的士，招来黑车；也有不少乘客担心，自己的行踪等信息上了互联网，可能会被滥用，存在安全风险。
⑦从驾驶的角度来讲，本来就是不允许用手机的。而使用该软件时，需要打电话确认乘客位置，一边打电话一边开车违反交规，存在安全隐患。
⑧市场空间够大、定位够准确、盈利够容易，这些统统是环绕在打车App软件“头”上的光环。全国各地尤其是一线城市，普遍存在的打车难问题，令打车App软件拥有了生存的土壤和价值。然而，打车App如何寻求出租车公司合作、私家车能否引入等问题，都令其陷入了“中国式困境”。 App软件开发公司指出：在过去的一年，大概有30款像嘀嘀打车、摇摇招车、的士在线这样的打车App软件上线。虽然有市场、有需求，但是打车App未来的发展仍然面临一系列的问题。未来盈利之路，依然很长。
⑨对此，首都师范大学教授郭海燕指出：“打车软件是一项新生事物，发展有待引导，与其封堵不如介入。”应该鼓励打车软件在实践中运用，避免简单禁止、粗暴管理，以达到“三赢”的效果，北京的经验值得借鉴。
15．请简要说明文章第①段的作用。（3分）
16．本文从哪几个方面介绍打车APP的？（3分）
17．请简要分析第④段中加点词“有时”能不能删去？为什么？（4分）
另一方面，出租车的空驶率非常高，有时甚至能达到40%，加剧了城市拥堵。
18．请从说明方法的角度分析文章最后一段的作用。（3分）
答案：
15.第一自然段从北京的哥不时地关注手机等待召唤写起，（1分）点明本文的说明对象——打车APP，（1分）激发读者的阅读兴趣，引出下文对打车APP的具体介绍。（1分）
16.本文从什么是打车APP、打车APP的使用、优势和特点、缺陷和不足、发展前景等方面介绍了说明对象。
17.不能删。“有时”是“有的时候”、“个别时候”的意思，起限制作用。（1分）这表明出租车的空驶率非常高，有的时候甚至能达到40%，并不是一直达到40%。（1分）“有时”体现了说明文语言的准确性、严密性。（1分）如果删去，则表明出租车空驶率始终达到40%，表意太绝对，与事实不符。（1分）
18.引用。（1分）引用了首都大学教授对打车软件的发展建议，具体说明了打车软件发展之路很长，有待引导。（1分）引用教授的言论，更具权威性和说服力。（1分）
第2篇：打车APP技术解决方案
打车APP解决方案
需要定制开发一个打车APP，本文档则分别从功能与技术两个方面介绍了该项目的解决方案。预期目标
该项目的想要实现的预期目标其实说起来非常简单，只要通过APP能够完成叫车服务即可，图1描述了该项目的本质需求。
图1 项目需求
从图1中可以看出，本项目的本质需求从大的方面来说其实就三个方面：
首先满足用户的打车需求，让用户可以及时获取出行服务，并且可以享受到一些优惠活动。 其次要满足司机的载客需求，降低出租车的空载率，增加司机的收入。
最后，如果可以，最终在线上完成支出操作，使得可以更好的管理出租车司机。这里可以通过与第三方支付进行合作达到目的。
为了可以更好达成以上需求，通过这三个本质的需求可以引申出来一些周边的辅助需求，主要有一下几点：
在匹配用户和司机双方的供需信息时，可以增加一些语音功能，不仅使得用户操作更方便，也使得司机可以在不影响开车的情况下或许信息。
增加加价功能，在用户与司机双方认可的前提下，如果遇到比较极端的出行服务，可以适当的·217·
进行加价，这样可以更高的调动司机的积极性，并且对用户来说也不失公允。
在使用完订车服务后，可以增加评价功能，完成评价体系，可以让更好的司机以及更好的乘客脱颖而出，也为出租车公司提供了更好的考核依据。提示：以上这些功能只是笔者本暂时想到的，如果还有其他需要改动的需求，可以随时增加或修改。以上这些所有的需求点，在移动互联网时代，通过打车APP的定位功能可以非常高效的满足以上所有的需求。功能框架
通过对预期目标的需求分析，可以很容易的得出本项目的需要实现的功能，图2给出了本项目所有功能点的框架图。
图2 本项目功能框架图
图2详细给出了本项目的功能框架，从大的方面来说可以分为三个端口，分别是司机端、用户端以及企业管理端。
提示：以上功能点只是暂时建议的功能点，除了几个核心的功能点之外，其余所有的辅助功能点都是选购的，例如运营功能，可以后期根据委托方具体的运营需求再进行确定。
2.1 司机端
司机端是出租车司机操作的平台，主要用来满足司机载客的需求，使得出租车的空车率得到降低。司机端主要包含以下几个功能点：
一键抢单：当用户发布叫车需求后，临近的可以满足服务的出租车司机可以进行抢单操作，有且只会有1个司机抢到订单。该功能是司机端的核心功能之一
语音读单：出租车司机大部分时间是无法去阅读订单内容的，也无法操作手机的，语音读单可以帮助司机更及时方便的了解叫单的内容。
·218·
管理功能：其中包括我的订单，我的账务，我的消息以及司机服务排名，这些功能可以帮助司机更好的维护自己的服务历史记录。
2.2 用户端
用户端是出租车公司以及司机为用户提供服务的主要窗口，用户对服务体验的好坏也直接影响了本软件的使用率以及公司整体的业绩。用户端主要包含一下几个功能点：
叫车功能：其中有即时叫车功能与语音叫车功能。用户使用该APP的主要目的就是满足其能够及时叫到车的需求，因此本功能是用户端的核心功能之一。在叫车的同时可以附带是否可以拼车，是否给加价等辅助功能。
预约功能：用户用车有时候会提前预约订车，例如预约几点去机场等需求，该需求也是用户端核心功能之一。
代驾功能：有很多情况用户因为规定无法驾驶自己的汽车，因此通过APP也可以公布自己需要代驾的服务需求。
管理功能：其中包括我的订单，我的账务，我的消息等管理功能，方便用户随时查看自己的用车历史记录，除此之外，在每次使用完叫车服务后，还可以对司机进行评价回复。
2.3 企业管理端
这部分主要是让服务提供企业方便的在后台进行运营维护，方便的了解各种数据，为企业的决策提供数据支持，企业管理端主要包含以下几个方面的管理：
企业日常管理：该部分主要是可以方便的管理车辆、司机、订单、用户、账务、评价等信息。除此之外，还可以对出租车进行全局监控。
企业运营管理：这里主要是为企业运营提供帮助的功能，其中包括公告，优惠政策、统计报表等功能，通过这些功能不仅方便企业及时做出决策，也可以方便企业做一些线上的活动，刺激用户使用。
安全权限：因为所有的数据都在企业管理后台这里，因此这里的数据安全，以及权限管理则非常有必要。
提示：除了以上两个核心管理功能之外，企业管理者还可以方便监控本系统与第三方平台对接的情况。技术体系
为了满足以上的功能需求，需要强而有力的技术体系作为支撑才行，因此技术体系就显得非常重要了。根据本系统的特点，笔者推荐使用RESTful风格来架构整个技术体系，该风格可使得后台所有的功能是以服务的形式统一为前端提供功能支持。图3给出了该项目技术体系。
·219·
图3 本项目技术体系图
通过图3可以看到，本项目的整体技术体系主要氛围三层，分别是前端展现层、API服务层以及物理数据层，下面给出了这三个层主要用途：
前段
展现层：主要是为用户进行呈现信息的，这里的用户包括司机、客户以及企业管理者，这些用户分别通过手机或者浏览器来访问本系统的各种服务，其中手机端适配当前量大主流的操作系统：Android与IOS。
API服务层：该层展现了RESTful架构风格，可以看到所有的功能都以服务的形式独立开来，而这些所有的服务都已API的形式对外呈现，这样前端不管是Android、IOS还是Web都可以按照统一的标准进行访问。
物理数据层：这里主要是用来存储数据的地方了，这里提供各种存储数据的方式，其中MySQL主要用来存储业务数据，redis主要用来存储位置坐标数据，而OS主要用来存储大型二进制数据。提示：除了以上这些功能以外，还有一些服务中间件，这些中间件虽然不是直接体现在某个功能上，但是可以用来来协调各个服务之间，以及服务层与数据层之间的关系。例如上面提到的MQ服务可以提供消息广播服务，而Cache则可以提供缓存方案，以提高系统的性能。架构体系
按照以上的技术体系结构，这里给出了4种架构体系，这4种架构分别应对不同量级的需求，下面则分别来介绍下这几种架构方案。
4.1 架构方案A 方案A是比较简单的一种方案，由于该方案成本低廉，运维成本则几乎为0，因此该方案是项目初 ·220·
期推荐选择的方案。图4给出了该方案的架构图。
图4 架构方案A示意图
通过图4可以看出本方案是非常简单的方案，因为架构简单，使得该方案非常容易维护，成本也非常低廉，但同时，该方案也无法支撑高并发的需求。下面给出了该方案的一些参数：
支撑流量上限100W 机房可以选择公有云服务，例如阿里云。也可以自购主机、自选IDC机房。 存在的问题：IDC网络故障、IDC提供商响应不及时。
可以优化方案：搭建配置服务器，使用IP直联的形式会一定程度上减少域名带来的问题。综上所诉，在项目刚开始阶段，用户流量不是很大的情况下，该方式还是比较实用的，性价比比较高的。
4.2 架构方案B 随着业务的发展，流量逐步达到了单机的极限，如果并发流量超过100W的时候，方案A就无法满足需求，而方案B则在A的基础上进行了扩充，使用集群来处理高并发的业务需求。图5给出了方案B的架构图。
图5 架构方案B示意图
·221·
可以看出，方案B在方案A的基础之上得到了有效的改善，也由以前单机nginx改为LVS提供负载均衡服务，而服务层则是以集群的形式提供强劲的性能，数据库也做了主从模式的集群化架构方案。该方案主要有以下特点：
支撑并发流量3000W~2亿
机房最好自购主机、自选IDC机房，并搭建LNMP集群环境。 引入MongoDB解决空间索引问题。
订单分配系统，则是将LBS服务，分单服务以及redis坐标数据独立出来，形成订单分配系统独立维护。
增加基于nagios的监控系统，可以监控系统的运行情况，其中包括，基础信息（cpu，内存等）、Nginx、MySQL、Cache、MongoDB等
成本在方案A基础上有了增加，并且日常需要2运维工程师来维护系统。
4.3 架构方案C 随着业务量的继续上涨，各种活动的展开，用户流量会越来越多，如果达到全国范围的用户级别的时候，方案B就会显得有些力不从心了，此时可以有一下三种办法来应对这个问题：
优化：API逻辑优化、LVS性能瓶颈可以尝试搭建LVS集群+DNS轮询，内网带宽极限可以尝试压缩cache中的数据，分单系统会导致DB压力过大，这个时候可以适当的进行调整来消去峰值。
柔性：对系统重新进行分析，看清业务与系统开销的对应关系。不常用的二级服务选择性的进行停用。对服务分级，对某些一级服务可以进行降级。
扩容：数据库硬件升级，Push服务集群化改造，开发定制化LBS服务算法替代Redis以及MongoDB。
然而以上这些应对办法，也只是治标不治本，无法根治方案B所展现出来的各种问题，而这个时候方案C就孕育而生了。图6给出了方案C 的架构图、提示：方案C的改造成本以及建造会非常高，但是可以根本上解决问题，因此一般情况下不会选择方案C，除非做到了滴滴这样全国性出行服务规模。
图6 架构方案C示意图
·222·
图6只是给出了方案C的总览图，其中每一个虚线块都可以成立一个项目组单拉出来进行研发，例如图6左下方的数据同步系统，其中包括了DB集群、KV集群等。下面给出了方案C的参数特点。
支撑并发流量在5亿左右
架构服务化，并且分城市部署，每个重要城市自选IDC机房。 成本则需要50+的研发团队以及7个人左右的运维团队。
支持SPDY协议，SPDY协议是Google提出的基于传输控制协议(TCP)的应用层协议，通过压缩、多路复用和优先级来缩短加载时间。该协议是一种更加快速的内容传输协议。
使用DevOps开发运营模式，为了按时交付软件产品和服务，开发和运营工作必须紧密合作。 尝试建立内部私有云，通过云技术、大数据的优势解决一些复杂的问题。总结
本文档分别从预期目标、功能框架、技术体系以及架构体系这4个方面对打车APP的解决方案进行了系统的描述，让所有人在项目动工之前对项目的总体情况有了大致的了解。其中架构方案这里也从简单到复杂给出了三套架构方案，以适合企业不同时期的发展，并满足了软件的可扩展性。
第3篇：《打车软件岂能一禁了之？》阅读练习及答案
《打车软件岂能一禁了之？》阅读练习及答案
打车软件岂能一禁了之？
⑴打车软件拥有开放的定位系统，解决了驾驶员与乘客信息不对称的问题，在一定程度上使乘客打车和出租车运营都变得更为便捷和高效。而打车优惠补贴这一营销手段的出现，更让“打车软件”风靡一时。
⑵然而，公众还来不及“享受”打车软件带来的便利，一系列问题便随之而来：打车软件需在智能手机上操作，使得不会使用智能手机，只习惯电话约车的中老年乘客饱受“打车难”的困扰；因为打车软件可以看到乘客的目的地，还要加价叫车功能，出租车司机 “挑活”情况加剧；行驶过程中司机为接单摆弄手机，由此引发的交通事故也呈上升趋势。为此，有人呼吁政府部门应及时出手，全面禁用打车软件，使出租车市场回归原有的秩序。
⑶手机打车软件并非国内首创，一些国外软件已经运行多年，其经验值得借
第4篇：打车app开发功能及报价方案
打车app开发功能及报价方案
智能手机的出现改变了人们的生活，由此，各种各样的手机APP开始被广泛使用，打车软件就是其中之一，其对人们出行带来的便利性不可或缺，所以越来越多人关心如何更好地开发一款打车APP，【亦强软件】根据以往的开发经验，提出以下解决方案。
目前，亦强软件开发的打车APP乘客端的核心功能为实时定位、一键叫车、专车分类、预估价格、在线支付、订单评价/投诉，司机端则包含注册司机、接受派单、申请改派、个人中心、我的钱包等核心功能。
一、首先，乘客端和司机端有一些相同的基本功能：（1）注册
可以通过输入手机号码获得验证码再设定密码注册（2）登录 可以通过账户密码或手机短信动态码登录（3）忘记密码
忘记密码可以通过手机获取验证码登录再重设密码（4）个人资料
个人资料里可以设置头像、昵称、性别、年龄
