摘 要： 随着社会经济的发展，人民生活水平的提高，车辆扎堆寸步难行，这是我国“城市病”的典型症状。堵车很大原因是车辆行驶没有全局规划，本项目在高德API下二次开发，设计并搭建了基于SMM架构的车辆疏导系统。本文从软件技术出发，完成车辆管理服务器端的设计和终端APP开发，再使用相应指标对该系统进行了效率分析与性能检测。
关键词 : 车辆疏导;系统搭建;效率分析;
Spring Boot是一个基于Spring框架，可供快速开发，特别适合构建微服务系统。其另外还封装了各类套件，比如mybatis、hibernate、redis、mongodb等。该框架搭建起来的应用，它会嵌入Tomcat、Jetty或者Undertow等服务器，并且不需要传统的WAR文件进行部署，也就是说搭建Spring Boot项目并不需要单独下载Tomcat等传统的服务器；同时提供通过Maven（或者Grandle）依赖的starter，这些starter可以直接获取开发所需的相关包，通过这些starter项目就能Java Application的形式运行Spring Boot的项目，而无须其他服务器配置；对于配置，Spring Boot提供Spring框架的最大自动化配置，大量使用自动配置，使得开发者对Spring的配置尽量减少；此外还提供了一些监测、自动检测的功能和外部配置，与此同时没有附加代码和XML的配置要求。
1、 系统介绍
本项目在高德API下二次开发，设计并搭建了基于SMM架构的车辆疏导系统，本次设计是在Windows平台下，使用Spring Boot作为系统的后台整体基础架构，使用Java语言完成终端安卓APP的编写，项目使用阿里云服务器部署并上线。系统功能包括车辆报备、车辆定位、路线规划、路程反馈等，疏导系统会根据目的地、出发地以及路径策略设置，为用户量身设计出行方案。同时可结合实时交通，帮助用户绕开拥堵路段，提供更贴心、更人性化的出行体验。
2 、软件设计
2.1 、服务器搭建。
后台采取stringboot+mysql+mybatis搭建服务器接口，实现数据传输及存储。stringboot来管理整个应用中所有对象的创建、初始化、销毁，及对象间关联关系的维护。同时作为View层的实现者，完成用户的请求接收功能，完成用户请求的转发及对用户的响应。mysql是服务器数据库，My Batis作为Dao层的实现者实现对用户车辆信息、车辆轨迹、信息推送等数据库的增删改查功能。
2.2、 APP的开发。
APP由主应用服务中间层以及后台管理系统相配合，通过app、数据库的设计，以及对服务器和支付api的引用，实现一套完整的车辆疏导。终端采取MVP架构搭建app框架，使用面向接口编程思想将View层与Model层进行完全分离，业务代码和逻辑代码解耦；主界面UI采用View Pager嵌套Fragment的方式，进行完全lazy Load，根据Fragment生命周期的可见性来判断界面的可见性来加载网络数据，优化网络api的设置，减少数据解析时间和网络访问时间，提高性能；界面内的通信均采用jetpack live Data，以及lifecycle Handler进行通信，有效防止数据丢失及不必要的内存泄露；网络模块使用Retrofit加载网络数据，对获取到的数据进行解析并序列化，结合Disk Lru Cache实现二级缓存，达到节省流量的同时，也能免去重复地解析数据的步骤，提高APP整体的浏览流畅度。图片显示基于glide做了图片显示的优化，尤其对gif图片的优化，在原生基础上进行了NDK层面优化，提升了glide性能，配合Photo View实现图片缓存同时，也实现图片的放大缩小，防止OOM现象。
3 、技术关键
3.1、 环信即时通讯集成
全类型消息：支持文字、表情、图片、语音、视频、附件、地理位置、扩展消息、透传消息、自定义消息等全类型消息收发；实时音视频：支持1对1、多对多音视频、音视频连麦等场景。低成本低延时、高品质、抗丢包抗抖动、百万级并发、全球多节点覆盖；推送服务：服务端支持对接APNS（苹果）、Google、华为、小米、OPPO、VIVO、魅族等各大消息推送平台；
3.2、高德地图猎鹰轨迹服务
多种路线规划：驾车路线规划、公交路线规划、骑行路线规划、步行路线规划；自定义避让区域或道路：想不走哪里就不走哪里；轨迹纠偏：针对定位偏移、定位缺失、定位间隔大等情况造成的轨迹异常，猎鹰提供基于路网和路径规划的轨迹纠偏补路功能，可将偏移点纠正到正确的道路上，呈现连贯、平滑的轨迹；空间检索：提供多种空间检索能力，支持检索圆形、多边形、行政区范围内的终端，可实现搜索当前地图视野内终端或指定区域内终端的功能；轨迹存储：基于成熟稳定的阿里云服务，对用户上传的轨迹数据进行存储，保证数据稳定；轨迹查询：针对用户已经上传成功的轨迹，我们提供高性能的轨迹查询服务，开发者可随时查询任意时间段的轨迹。
3.3、腾讯优图车辆属性识别集成
准确率高：准确率高于90%，基于海量大数据持续迭代，不断优化识别精度；适用场景广：对于道路卡口、出入口、街拍图片均具有较好的识别效果，同时支持车身正向、侧向等不同角度情况下的识别；交通车辆信息结构化：对于道路、停车场等各种监控场景，结构化车辆信息数据，可用于相关数据检索或信息挖掘。
3、遇到的问题以及解决方案
3.1 、问题1：电量消耗过大
系统集成多组件开发，多耗电大户同时运行。电量优化程度在一定程度上决定了用户的体验感。我们需要考虑的是如何优化电量使用，让我们的App不会因为电量消耗过高被用户排斥，或者被其他安全应用报告，以此确保用户黏性。
问题解析：
(1）优化应用的后台耗电：避免后台长时间获取Wake Lock、Wi Fi和蓝牙的扫描等。
(2）网络优化：指定三种不同状态消耗方案（Full power：高功率状态，移动网络连接被激活，允许设备以最大的传输速率进行操作；Low power：低功耗状态，对电量的消耗差不多是Full power状态下的50%;Standby：空闲态，没有数据连接需要传输，电量消耗最少。）
(3）计算优化（在native层开发时，可以利用ARM neon指令集做并行运算）
(4）界面优化（离开界面后停止相关活动，例如关闭动画，耗电操作判断前后台，如果是后台则不执行相关操作。）
(5）定位优化（根据场景谨慎选择定位模式：对定位准确度没那么高的场景可以选择低精度模式。可以考虑网络定位代替GPS。使用后务必及时关闭，减少更新频率，例如定位开启一定时间后超过某个阈值可以执行一个兜底策略：强制关闭GPS。）
3.2、 问题2：系统崩溃
1）确定重点：A确认严重程度。B优先解决Top崩溃或对业务有重大影响的崩溃：如启动、支付过程的崩溃c Java崩溃：如果是OOM，需进一步查看日志中的内存信息和资源信息，下面会分析。C Native崩溃：查看signal、code、fault addr以及崩溃时的Java堆栈
2）查找共性：机型、系统、ROM、厂商、ABI这些信息都可以作为共性参考，对于下一步复现问题有明确指引。
3）尝试复现：复现之后再增加日志或使用Debugger、GDB进行调试。
使用以上步骤，我们解决了几个常见的异常：
异常1:Android 7.0 Toast Bad Token Exception
解决：代理Toast里的m TN(handler）就可以实现捕获异常
异常2:Shared Preference apply引起的ANR问题
解决：拿到Hook Activity Thrad的Handler变量，给其设置一个Callback,Handler的dispatch Message中会先处理callback。最后在Callback中调用队列的清理工作，注意队列清理需要反射调用Queued Work。
异常3:Timeout Exceptin异常
解决：它是由系统的Finalizer Watchdog Daemon抛出来的，我们对该异常进行了规避。stop方法，在Android 6.0之前会有线程同步问题。因为6.0之前调用thread To Stop的interrupt方法是没有加锁的，所以可能会有线程同步的问题。
3.3、 问题3：内存抖动
需求：在APP中需要加载大量服务器图片
难点：我们的APP需要申请一块内存来存放图片的时候，系统认为我们的程序需要的内存过大，不分配给我们的APP，抛出OOM异常
解决方案：1.异步开启子线程进行耗时的操作，通过Handler+Message在子线程发送消息到主线程进行更新UI;2.对于加载图片过多时导致的OOM内存溢出问题，引入Image Loader开源框架解决，Image Loader里的线程使用了线程池，从而避免了过多的线程频繁的创建和销毁；3.对图片采用软引用，及时进行recycle（）操作及等比例缩小图片；4.listview每次仅加载屏幕能显示的内容，其余数据处于准备显示状态。
本文主要研究车辆疏导系统的搭建及优化问题。系统搭建完后，在电量优化、崩溃分析、内存抖动三个方面对系统进行了效率测试、异常捕捉及问题分析，并提供解决方案。实验结果表明，经过我们的优化，达到节省流量同时，也能免去重复的解析数据的步骤，系统整体的稳定性和浏览流畅度得到了的很大的提升。
参考文献
[1]陈鹏基于Android应用的性能监控系统的研究与实现[D]华南理I大学, 2015.
[2]李少杰面向移动智能终端应用性能测试平台的研究[D].华南理工大学, 2014.
[3]黄琦. Android智能手机应用软件自动化测试工具的设计和开发[D].安徽大学, 2012.
