高德API下基于SMM架构的车辆疏导系统搭建分析,计算机应用技术论文

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