1 背景

随着社会经济水平的提高和旅游业的快速发展，人们的支付能力和旅行欲望在不断增强，探索新的旅行地点的需求也越来越迫切。为满足人们的出行需求，解决出行难题，众多的以出行为主的网站及APP应运而生，如12306、携程、去哪儿等。这些软件或网站的出现极大的方便了人们的出行，为出行提供了极大的便利，但是在使用的过程中，依旧存在着一定的不足。突出的问题体现在，在换乘查询方面各个网站和APP的功能都不够完善，例如12306网站虽然提供了中转查询功能，但是较多城市之间并不能查到换乘信息，而且只提供一次转站的查询，增加了用户出行路线查询的成本，用户体验较差，是用户出行问题的一大痛点。

为解决这一问题，本产品重点关注列车换乘问题，力求改善以往换乘查询中存在的问题，为用户提供便捷。iRoute——铁路出行线路辅助规划系统实现对我国任意两个铁路站点之间通达乘车方案的搜索。通过铁路站点列表辅助输入站点，并基于站内和市内换乘预估所需的时间，搜索可行的方案。分类管理搜索结果，主要考虑直达、一次换乘和两次换乘的情况。通过勾选感兴趣的路线，在地图中进行实时渲染，便于进行直观地比较。

2 需求分析

在用户规划出行路线的过程中，经常会遇到以下情景：

用户A打算出游，使用携程查询火车票，发现没有直达车次，只能分段搜索，不知道在哪个站换乘方便，尝试了很多换乘站才找到合适的，耗费了大量的时间。

用户B要去一个比较偏远的地方出差，使用12306购买火车票，没有直达车次，也没有一次换乘的方案，还是得尝试多次，两次换乘也太麻烦了吧。

用户C回家，使用12306购买火车票，没有直达车次，查询到了一次换乘的方案，但是两趟车次之间时间间隔太短了，想要间隔久一点。

用户D出行，使用12306购买火车票，查询出多条方案，不知道怎么选择，想更直观一些。

通过对以上情景的分析，归纳出用户出行路线规划的需求点包括：

1）没有直达车次时，提供换乘方案。

2）没有一次换乘方案时，提供两次换乘方案。

3)提供用户可选择换乘时间的功能。

4)提供多个换乘方案直观对比的功能。

3 产品设计

3.1 产品定位

本产品旨在为用户提供铁路出行方案，为用户出行提供便利，目标用户为有铁路出行需求的用户。

3.2 产品名称与Slogan

本产品与用户出行路线息息相关，具有个性选择、筛选出行路线的特征，因此将产品名称设计为“iRoute”，Slogon设计为“让铁路出行更方便”，紧密围绕产品的核心功能和特点。

3.3 模块结构

iRoute主要包括四个模块：地图展示、路线查询、路线信息浏览、路线展示与对比。

iRoute结构设计

3.4 核心功能

iRoute产品的核心功能在于查询铁路出行方案，用户通过输入或选择始发站与终点站，设置换乘时间（站内换乘，市内换乘）参数，获取查询结果。车次结果通过直达、一次换乘、两次换乘组织，并在各类别内的标签化最短时间、最少站点的路线。用户通过勾选感兴趣的路线方案，通过比较路线查看车次的详细信息，并通过地图直观地展示。

3.5 交互设计

产品由四个页面构成，相互关联如下所示。

iRoute交互设计

1）Welcome Page

Welcome Page通过Image和Text组件组成系统的欢迎页，setTimeout方法设置3秒定时跳转页面至Map Page。

Welcome Page

2） Map Page

Map Page由ScrollingAppBarLayout、BottomSheetBehaviorWrapper、MergedAppBarLayoutWrapper、SMap等组件构成。对比乘车路线时上拉BottomSheet组件，显示对比路线的缩略信息，ViewPager组件左右滑动可以实时渲染不同路线，如下图左所示。再次上拉车次信息的可视范围扩大到整屏，此时显示更详细的路线信息，如下图右所示。该设计使得用户与界面的交互性更强，更加人性化，操作设计符合人的思维过程，具有良好的用户体验。

MapPage1 MapPage2

3）Input Page

Input Page总体纵向排列，通过两个TextInput组件接收用户输入的站点名称，使用SectionList展示所有站点名称。

“设置换乘预估时间按钮”通过Collapsible组件能够显示、隐藏换乘时间设置部分，查看车站列表时，用户可以选择隐藏时间设置部分，增大列表的可视范围。如下图左所示。点击“搜路线”按钮向服务器层发送请求，进行查询，查询过程显示Loading组件以提示用户等待结果，如下图右所示。

Collapsible组件 Loading组件

4）Result Page

Result Page通过ActionButton组件实现管理路线、重新查询和对比路线的操作，按钮位于页面右下角，避免遮挡信息的显示，也符合大部分用户右手操作的习惯，如下图做所示。PlanCard组件渲染每一个乘车方案，通过勾选方案前的复选框，并点击ActionButton中的“比较路线”，返回Map Page渲染路线、进行比较，如下图右所示。

Result Page1 Result Page2

3.6 配色方案

系统总体色调以蓝色、白色为主，与地理底图的总体色调和谐统一。由于地图要素较多、较为复杂，因此系统的总体色调设计为相同色系，且深色系基本用于尺寸较小的组件和状态栏，使得系统给予用户轻松、明亮、清新的视觉效果。

4 实现方案

4.1 系统总体架构

总体架构如下图所示：

系统总体架构图

服务器层：服务器层部署铁路车次信息和站点经纬度信息数据库，当用户请求查询时，通过fretch方法向服务器发送POST请求，在服务器层通过算法计算得到结果。

API接口层：在API接口层用户输入起始站、终点站、换乘时间等数据，请求查询是作为参数传至服务器层，并将服务器层的计算结果输出。

路线渲染层：通过SuperMap提供的iMobile

for Reactnative将乘车路线在地图上进行渲染，该开发工具是SuperMap iMobile推出的一款基于React-Native框架的移动应用开发工具，能够使用JavaScript开发语言，开发出在Android和iOS操作系统下运行的原声移动GIS应用。

基础框架层：总体开发基于React-Native框架进行。Mobx与redux类似，都是用来维护复杂react应用的状态，但是Mobx使用起来更加直观，具有很高的扩展性。

4.2 算法设计

4.2.1 数据获取及存储

首先从数据库中获取数据，使用pymysql模块，将数据库中各个表中数据整理得到两个列表和三个字典。分别是alltrainnum,allstation（分别存储所有的车次数据和所有的火车站）和direc,data,same（分别存储经过一个火车站的所有车次；一趟列车的途经站和每个站点的到达和出发时间；同城市火车站）

4.2.2 实现过程

对于起始站和终点站，通过字典direc分别获得经过其的所有车次，然后求交集并判断得到符合条件的就是直达列车。没有交集的就说明没有直达列车，此时，对于刚刚通过direc字典获得的两个列表，分别遍历里面的车次，并分别求出起始站和终点站可以直达的地方，存为两个列表x1和x2，求交集，如果交集不为空，说明可以通过一次换乘到达，再求出对应的车次和时间即可。当交集为空时，说明一次换乘也不能到达,现在就对x1和x2里面的车站重复之前的操作，便可求得多次换乘的方案。

4.2.3 算法优化

数据库中的timedata和timedata1这两个表中的数据就是用来优化算法的，里面记录了所有两个车站间一次换乘的最短时间，在多次换乘中，知道这个数据会减少大量不必要的循环，节省系统开支，让检索可以在几秒内得出结果，所有可能的方案都以json格式输出。

4.3 关键技术

4.3.1 Mobx

MobX 是一个通过对开发者透明的函数响应式编程（TFRP）方式，让状态管理变得简单、具有高扩展性的库，并且这个库经过了严格的测试。MobX的思想非常简单：来源于应用的状态的任何事物，都能被自动获得。

Mobx/MobxReact 中有三个核心概念，observable、observer、action：

observable: 通过observable(state) 定义组件的状态，包装后的状态是一个可观察数据（Observable Data）。

Observer: 通过observer(ReactComponent) 定义组件。

Action: 通过 action 来修改状态。

MobX 给已有的数据结构增加了可观察的能力（如对象、数组、类实例等）。你只需要很简单地使用@observable 装饰你的类属性（property）即可。使用 observable 就像将对象中的属性转变成 Excel 中的单元格，但不同的是，这些值并不仅限于初级类型，也可作用于引用、对象、数组等类型。如果你使用 React，你只需增加 observer 装饰器，即可将你的无状态组件转换为可响应组件。

React 和 MobX 是一对强大的组合。React 提供一个把应用程序的状态渲染成组件树的机制。 MobX 则提供了存储和更新应用状态的机制。

React 和 MobX 都提供了非常优秀、独特的方式以解决应用开发中遇到的共同问题。 React 利用虚拟 DOM 来优化 UI 的渲染，以减少 DOM 操作成本。 MobX 则提供了优化将应用状态同步到 React 组件内的机制，通过使用了一种响应式的状态依赖图，该依赖图严格只在需要的时候更新，并且不会出现代码腐化。

4.3.2 数据驱动的渲染机制

利用Mobx这种响应式的编程方式，结合react

native，本系统实现了一种基于数据驱动的APP渲染机制，来处理复杂的应用状态和数据渲染。

4.3.3 数据管理

客户端将服务器返回的计算结果保存在了一个事先准备好的observable容器当中，这个容器和其他状态一样都保存在了一个对象当中。这个对象在整个app生命周期中始终存在，扮演状态管理者的角色，称之为store。store维护了整个app的所有状态和数据，也就是说，当store发生变化的时候，app相应的部分的react组件就会重新渲染。

4.3.3.1 组件实时渲染

以展示单独一个路线方案的react组件为例。当服务器返回数据之后，store中其对应的容器发生变化，这个变化将会使其观察者observer发出响应。观察者内部存在这样一种机制：遍历所有路线方案，为每个方案生成其对应的react组件。所有的组件都是基于数据生成的。当路线数据发生变化时，观察者会再次发出响应，基于新的数据渲染出新的组件。

同样的。组件也可以修改store中的数据。例如，同一个observable数据有两个观察者。当其中一个观察者修改了数据的时候，另一个观察者会对这一变化做出响应，这样就解决了兄弟组件，或者非同源组件之间通信的问题，避免了复杂的props和state传递。

4.3.3.2 地图实时渲染

系统的地图采用了imobile_for_reactnative的地图api，用于在地图上渲染单独一种路线方案的车站信息。

imobile_for_reactnative提供了非常方便的方法来渲染一个标记，在系统中将这个方法封装在了一个Mobx提供的autorun函数中。autorun函数会在其内部使用的observable数据发生变化时自动调用。相比之下，这个方法的用途更多是产生一个伴随效应，而不是产生一个新的值。例如，系统中存在一个observable容器，用于保存当前选中的方案。将这个容器传入到autorun函数中，当选中方案变化的时候，autorun函数就会响应，产生一个伴随效应：在地图上渲染新的标记，代表当前方案要经过的火车站点。