ArcGIS Runtime Quartz版本架构深度解析

4
分享 2015-12-27
Esri于2015年8月正式推出了新一代的ArcGIS Runtime版本——Quartz。Quartz中文是石英,浮现于脑海中的,自然是闪闪发光的晶体。见名知意,Esri对这一版本充满自豪,寄予厚望。本篇我们就来聊一聊这一全新的版本。
Esri于2015年8月正式推出了新一代的ArcGIS Runtime版本——Quartz。根据Esri官方声明,Quartz版本无疑是迄今为止ArcGIS Runtime最重要的版本发布。
在Quartz版本中,Esri采用了一种全新且独特的建构方式;所有的重要新功能都将建立在这一新型的产品架构上,从而确保各平台上关键功能的发布都趋于一致。这里,小编仅列出若干亮点:
  • 与在线和离线地图的交互
  • 本地跨平台开发
  • 3D查看和分析
  • 矢量地图绘制和可视化,如矢量切片
  • 与Portal的交互
  • 实时分析,包括通用的基于GPU计算框架的体系架构和特定的分析工具

在最终版本发布之前,Esri将会循序渐进地推出若干Beta版本,分别针对于特定的工作流,以帮助用户渐进式地丰满自己的开发。其中,Beta1重点讲述在线工作流;Beta2着眼于离线和本地数据的使用以及跨平台开发;随后,3D和实时分析的Beta版也将陆续推出。
接下来,小编将以ESRI于2015年9月10日分享的《Quartz Architecture Deep Dive》 这篇文章为核心,和大家一起初步探讨Quartz这一新版本的整体架构。 在Quartz版本中,通过原生C++代码与特定平台API代码相结合,架构设计层面充分发挥了所在平台的功能;应用层面上实现了用户开发过程中所使用的API与平台上其他原生API的无缝集成。 
下面是ArcGIS Runtime架构概览图。
  

C++运行时核心(runtime core)针对各平台分别进行本地编译,从而实现了最佳的性能。它充分利用平台硬件包括GPU来确保高性能的地图显示和分析计算,同时尽可能保证电池的高效利用。C++核心层并未直接暴露给用户,而是通过特定于平台的API层向用户提供相应的功能。
早期版本的ArcGIS Runtime着重于提供一个高性能的地图绘制引擎通过web服务向客户端传输并显示内容,以及一个本地客户端API用以操作远端GIS服务,如地理编码,路径分析和空间分析。这些web服务通常由ArcGIS Server、ArcGIS Online提供或运行于桌面级ArcGIS Runtime(如 ArcGIS Runtime for Java, .NET和QT等)的Local Server上。
随着ArcGIS Runtime 10.2.3的发布,C++运行时核心所支持的GIS功能显著增加。首先,本地数据管理新增了runtime geodatabase(托管于SQLite数据库中)的开发;这一runtime geodatabase可支持简单的要素模型,帮助用户构建完整的编辑方案,并可根据需求将编辑更新同步至要素服务。其次,引入了基于本地内容(即离线数据)的方向和地址查找(即网络分析和地理编码)。上述功能使得用户可自如地实现全离线,全在线和部分在线等各种应用场景。
10.2.3版本宣布了一个全新阶段的开始。在此之前,对于ArcGIS应用开发者而言,ArcGIS Engine是Windows和Linux桌面上的唯一选择。自10.2.3开始,ArcGIS Runtime扩展至各个可支持的ArcGIS Runtime平台。在过去的一年中,越来越多的功能新增到后续版本中,但是,我们会发现,这些新增功能并非存在于所有的平台上。
ArcGIS Runtime 架构的演进
Quartz版本将成为Runtime发布至今新增功能最多的版本。新的图层类型,更多的渲染和符号,对web map读写的支持,3D,本地矢量和栅格图层的支持,基于GPU的空间分析,这些功能都将包含在内。
这些新增功能将意味着更多新的API的提供,也意味着需要对现有API的进行改变以实现大量涌入的全新概念。
下面是10.2版本的API架构图。
  

正如前面所说的,原生API 封装了C++ runtime core的功能。要实现这一点,就需要一定的互操作代码。一些互操作代码在运行时需要强制调用,例如在进行Java和Android开发时,必须利用JNI代码来确保Java对C++ runtime core的调用。相反的,某些平台API则不需要互操作层,如 iOS和OS X 上所使用的Objective C 是可以直接调用C++代码的。即使在这种情况下,也并不会简单地将C++ runtime core API暴露给用户,因为有很多概念对于core的实现很重要,但是对使用者并不重要。
这些API互操作层的设计和编译特定于每个原生API。虽然允许各平台上的API之间看起来都是相似的,但是仍然允许不同。那些已经开发出多个runtime API的用户也会意识到这些差异。所有由平台设计模式所产生的差异是可以接受的,但是,由不同平台上实现同一API 的两个设计者所导致的逻辑模型的差异则是不允许的。
在已经发布的版本中,Runtime架构在不断地演化。适应于新的平台,暴露出新的功能,ArcGIS Runtime 已经从一个纯粹的web service客户端,逐步演进为一个能脱离于其他环境而仅在设备上就可方便执行大量操作的强大的GIS运行时。所有这些都是通过修改和发展现有架构实现的。然后,于此同时,无论是对于内部架构层面,还是对于API的使用者,这一进程中也暴露出各种限制因素。
Quartz API 架构
如前所述,由于Quartz这一新版本中要包含大量用以实现新功能的新增API,且10.2版本本身也存在若干架构缺陷,ESRI将于Quartz上引入新的内部架构。新的架构带来了诸多便利。对于API的使用者而言,有4个方面的作用最为明显,逻辑模型和行为层面API的一致性,更高的代码质量,性能的改善,各平台下更加同步的功能交付。虽然仍然需要一些交互代码以确保跨架构的调用,但是新架构的目的就在于保证特定于API的交互代码减小至最少。因此,我们创建了新的内部通用API。

通用API对逻辑模型和runtime core实现之间映射关系的具体实现进行了封装。因为这是所有API共享相同逻辑模型(具有相同行为)的地方。它也确保了特定于API的互操作代码(图中绿色区域所示)维持在最低限度。这就意味着API间的重复代码会更少,从而改善了代码质量且新增功能可以以一种更一致的方式体现在所有的API中。
尽管新的架构下API间的差异仍然存在,但是这些差异将会非常小,而且是由特定于平台架构和功能所导致的。 ESRI的API小组将尽最大努力确保Runtime Common API的通用概念模型对于各平台都采用一种合适的设计模式,以确保用户感到得心应手。
新架构对于现有 API 的影响
正如上面所讨论的,这一新的体系结构具备显著的优势。然而,至新版本的改变必然需要付出一些代价。不是每个API都发生了改变,但是,例如地图,几何和Portal相关的API都发生了变化。这些变化将在后续文章中详细介绍。 没有人喜欢为了改变而改变,但是Quartz版本上的架构变化必然会给用户带来巨大的便利,值得为此而付出努力。
注:翻译章节可能存在疏漏和错误之处,建议大家对照原文深入理解。如有建议,欢迎多多给我留言! 参考链接:
1)http://blogs.esri.com/esri/arcgis/2015/09/10/quartz-architecture-deep-dive/ 
2)http://blogs.esri.com/esri/arcgis/2015/08/26/quartz-beta-1-is-now-available/


文章来源:http://blog.csdn.net/zssai2015/article/details/50449064

3 个评论

学习了
这里有你卓越贡献啊!
good good study

要回复文章请先登录注册