html导航在线制作,基于HTML5&Js的在线导航系统架构

本文主要就项目中应用HTML5&Javascript开发导航系统时,遇到的问题做一总结及分享.具体从以下三个方面进行说明:

1.发现和解决问题

导航系统有这么几个特点:多任务性,实时性,交互性,数据多样性.

针对上述特点个人在进行架构设计时,采用如下解决方案:

(1)多任务性:采用HTML5的Webworker解决方案.

HTML5的webWorkers提供了js的后台处理解决方案,它允许将复杂耗时的单纯js逻辑处理放在浏览器后台线程中进行处理，让js不阻塞UI线程的渲染。

(2)实时性:主要体现在实时渲染. HTML5的Canvas可以解决这个问题,

HTML5的Canvas(画布)可以用来绘制图形，图案，允许使用脚本动态渲染点阵图像。简单来说，Canvas就是允许你在HTML5中，使用Javascript去绘制你喜欢的任何图形，包括文字，图片、线、点、各种形状等。这正是导航系统所需要的基础矢量绘图功能.

(3)交互性:主要体现在导航人机交互界面HMI框架的设计.项目采用 利用开源类库zepto来搭建导航HMI框架的方案解决此问题.

zepto是一个专为mobile WebKit浏览器(如：Safari和Chrome)而开发的一个JavaScript类库.能够帮助开发人员简单、快速地完成开发任务。最重要的是这个JS类库，是超轻量级的，只有5KB.

HMI框架在设计时,主要考虑:

1)实现页面结构和数据的分离。

2)实现html和js的分离。

3)减少组件间的耦合，实现业务模块的组件化，独立性。

4)方便多人并行开发和测试。

基础框架图如下:

该框架实现了HMI基本功能(包括画页的迁移,数据的传递).框架中,画页是基于div设计的,即每一个画页使用一个div来表示,画页的迁移过程就是控制div显示与否的过程.

开发人员在制作页面时,每个页面需要制作一个HTML(内部是一个div)文件和一个页面类(js)文件,页面文件(html)用来描述页面的构成和元素,页面类(js)用来获取数据，渲染页面和增加页面元素的监听.

(4)数据多样性:主要体现在数据格式及数据来源的多样性.

1)导航用二进制数据的解析方案

通常我们使用的导航数据都是紧密排列的二进制格式数据,此种数据,我们采用的解析方案是:使用ArrayBuffer进行解析.ArrayBuffer表示二进制数据的原始缓冲区，该缓冲区用于存储各种类型化数组的数据。实际应用时,将ArrayBuffer传递到类型化数组或 DataView 对象,来解释缓冲区中相关数据类型.

2)导航用配置文件的解析方案

配置文件的解析,在Javascript中比较简单,直接使用Json进行存储和读取即可.Json是一种轻量级的数据交换格式,在Javascript中可以将对象直接转换为Json数据,也可反向将Json转换为对象.

3)导航数据的本地存储

导航数据的本地存储采用HTML5的localStorage特性.localStorage是浏览器用于存储本地数据的一个对象.其保存的数据,一般情况下是永久保存的.在应用时,我们使用localStorage来保存配置文件和缓存数据.

在进行架构设计时,除了考虑上述因素外,还要考虑如下问题:

(1)导航NaviCore框架设计

在设计之初,我们考虑NaviCore框架需具备如下特点:

1)具备Js脚本按需加载特性.

由于导航系统比较庞大,js脚本必然非常多,脚本之间的引用关系如果控制不好后期将成为很大问题,为解决此问题,我们采用Js脚本按需加载的解决方案,即当某个脚本js需要使用其他脚本中的数据或对象时,采用某种方式(如:像C语言的Include或Java的Import),在文件开头做一声明,框架根据声明进行加载,达到按需加载的目的.

2)实现类的继承关系

Javascript的继承关系是通过prototype实现的,但prototype有一些不足(如:父类的构造函数不是像JAVA中那样在给子类进行实例化时执行),因此,我们重新设计了一套类的继承模型,实现了类的继承,类的构造函数执行.

3)减少模块间的耦合，增加独立性。

为减少模块间耦合,增加独立性,我们设计了一套事件通知机制,该机制支持浏览器事件,支持dom对象绑定,也可以绑定到某一个类对象,采用观测者模式设计,大大减少了模块间的耦合度.

(2)异常处理

我们使用Javascript中的try catch处理异常.请大家注意,一定要指定window.onerror错误处理函数。这样可以第一时间捕捉到程序未捕捉的异常.

2.预见与避免错误

在设计阶段,我们预计,后期性能问题可能是比较棘手的问题.因此,在设计阶段专门针对性能相关问题点进行了分析和设计.

1.对于更新频率较高的过程的分析.

(1)Map刷新频率可能会很高，这可能会导致系统负荷较高.

采用异步地图刷新机制,并控制地图刷新频率,保证系统负荷.

(2)DG对声音文件下载频率较高,导致网络带宽被长时间占用.

采用声音文件分类下载机制,共通声音文件直接放入安装包,常用声音文件缓存到本地的方式减少带宽占用.

2.对于耗时较长的处理过程的分析.

如果主线程中有耗时较长的处理过程,则必然会阻塞UI响应,影响用户体验.对此,我们采用在程序执行入口加入性能监控代码的方式,保证第一时间找到问题点.对于耗时较长的处理过程,采用Webworker解决方案,将其放入后台独立线程中进行处理.

3.分析和总结

本项目总结的技术方案和设计文档有:AD架构设计文档,概要设计文档,详细设计文档,HMI架构设计方案.