解读ArcGIS Runtime SDKs

　　本文试图解读新的ArcGIS Runtime SDKs及其本质，与ArcGIS移动SDK，for iOS/Windows Phone/Android，之间的关系，以及这三种移动SDK后续发展的一些猜想。
　　ArcGIS Runtime SDKs是随ArcGIS 10.1 beta一起发布的一套横跨桌面和移动端的，跨平台，轻量级的GIS开发SDK的总称。

　　从上图中我们可以看出，ArcGIS Runtime SDKs家族包括了以下内容：

• ArcGIS Runtime SDK for Android
• ArcGIS Runtime SDK for iOS
• ArcGIS Runtime SDK for Windows Phone
• ArcGIS Runtime SDK for Windows Mobile
• ArcGIS Runtime SDK for Java
• ArcGIS Runtime SDK for Qt
• ArcGIS Rutnime SDK for WPF

　　之所以说ArcGIS Runtime SDKs横跨桌面和移动端，是因为它既包含了iOS/Windows Phone/Android等移动平台的开发SDK，也包含了可以开发传统桌面程序（C/S程序）的WPF、Java、QT等SDK；而后三种SDK则可开发出Windows和Linux平台下的具有丰富交互效果和良好体验的应用程序。其实ArcGIS Runtime还包括了一些现成的应用程序，比如iOS/Windows Phone/Android各自市场上都能下载到的“ArcGIS”程序，ArcGIS Mobile中的“ArcGIS”程序等。
　　说起轻量级，首先要看看ArcGIS 10.1产品架构的一些变化。

　　ArcGIS 10.1中，产品的划分更加明确和简单。主要分为四个部分，桌面GIS（传统的ArcMap，ArcGlobe等），ServerGIS（全新架构的ArcGIS Server），轻量级GIS（ArcGIS Explorer，Runtime SDKs及其对应的应用程序）和ArcGIS Online。前三部分都是围绕ArcGIS Online这个云GIS平台的，在不同程度上都与ArcGIS Online有交互，或可将数据直接部署上去，或作为它的客户端（云+端）。而轻量级GIS就是为了能够在任何地点，任何平台，任何设备上访问云平台提供的GIS能力。
　　ArcGIS Runtime SDKs正是在这种背景下诞生的。其实它也分为狭义和广义上的两种解释。狭义的ArcGIS Runtime SDK是指桌面上的WPF，Java和Qt，它们的消息早在半年前就已经流出。它们的出现，是为了逐步替代强大而相对臃肿的ArcGIS Engine这个产品。做过Engine开发的朋友都知道，即使是最简单的显示地图的需求，理论上都必须在客户机上安装ArcGIS Engine Runtime这个运行时（注意不是ArcGIS Runtime），安装包通常400m左右。而利用新的ArcGIS Runtime SDK for WPF/Java/Qt开发出的程序，完全是绿色程序，不需要在客户机上安装任何部件（.Net Framework和JRE不计）即可运行，因为所有的依赖库直接和程序拷贝在一起即可。如果你喜欢ArcGIS Runtime SDK开发的程序的部署过程——拷贝到u盘里/插入目标计算机/运行，那么你一定也喜欢它的卸载过程——关闭程序/拔掉u盘。
　　广义上的ArcGIS Runtime SDKs是上述列表中，诸多SDKs的统称。除了包含狭义的ArcGIS Runtime SDK，可以看到加入了移动端部分：ArcGIS Runtime SDK for iOS/Windows Phone/Android/Windows Mobile，而它们其实是新瓶装旧酒，分别对应以前的ArcGIS SDK for iOS/Windows Phone/Android和ArcGIS Mobile，只是换了产品名称而已。为什么会换名称？为什么还有ArcGIS Mobile这个“另类”的东西？这得从ArcGIS Runtime SDK的功能说起。
　　做过ArcGIS Web API（ArcGIS API for Javascript/Flex/Silverlight）开发的朋友，应该可以很快理解狭义Runtime这个产品的所有功能。目前ArcGIS Runtime的功能与ArcGIS Web API，ArcGIS移动API（iOS/Windows Phone/Android）基本相同，都是基于ArcGIS REST API的。比如地图服务（动态/缓存）的加载，GraphicsLayer/FeatureLayer，基于FeatureService的数据编辑，Identify/Find/Query操作，GeometryService，Geoprocessing Service的调用等。它们的开发思路和代码编写几乎是一样的，比如ArcGIS API for Silverlight和目前的ArcGIS Runtime SDK for WPF，如出一辙（后者的前身就是ArcGIS API for WPF）。但狭义上的ArcGIS Runtime SDK与ArcGIS Web API不同之处在于，前者可以加载本地数据，包括Map Package/Tile Package/Locator Package/Geoprocessing Package。Map Package是包括.mxd文档和所有引用数据在内的压缩包，其余类似。最早的Package是9.3.1产品中的LayerPackage，它不仅包含了.lyr图层配置信息，还打包了图层所引用的实际数据。早期的ArcGIS Online平台允许用户上传LayerPackage以便分享，现在看来，直到此时Runtime产品的出现才将Package的概念发扬光大，并且为以后的所谓云GIS提供了更多的数据共享途径。对本地数据的读取是否破坏了基于ArcGIS REST API的框架呢？其实没有。ArcGIS API for WPF/Java/QT中，都内置了一个c++写的Web Server，读取本地数据后，会自动发布成这个Web Server上的REST服务来供Runtime SDK使用，所以一切功能，还是由REST API提供的。收起题外话，ArcGIS Runtime SDK的框架，是针对轻量级GIS产品（不包括ArcGIS Web API）的，它拥有统一的编程模型，可以用一致的开发思路，做出C/S，及移动端应用（Web API开发出B/S应用），为开发人员提供了极大的便利。这也是为什么将它们统称为ArcGIS Runtime SDKs的原因。
　　在来说说ArcGIS Runtime for Windows Mobile（原来的ArcGIS Mobile）这个产品。之所以将它也归为ArcGIS Runtime SDK，是不无道理的。使用过ArcGIS Mobile的朋友一定知道，它的一个核心理念就是将数据划分为Basemap Layer和Operational Layer。前者是指起可视化参考作用的数据，一般是栅格底图或地图服务切片；后者是包含矢量信息在内的业务数据。ArcGIS Runtime中所涉及到Package，恰好与之对应。Tile Package对应Basemap Layer，Map Package对应Operational Layer。可以说，ArcGIS Mobile的设计理念，在整个ArcGIS Runtime产品家族中，得到了很好的延续。其实ArcGIS Mobile是个十分优秀的产品……
　　到此，新的三个移动SDK（iOS/Windows Phone/Android）也归为ArcGIS Runtime SDKs的原因也就明了了，主要原因是都基于REST API的框架。另外基本可以肯定，它们都会使用相同的数据模型，即各种Package。由此不难推断，以后iOS/Windows Phone/Android平台上移动SDK的离线功能，也会依赖于Tile Package和Map Package。上周刚刚发布的ArcGIS API for iOS 2.1（以后要叫ArcGIS Runtime SDK for iOS）版本中，已经印证了这种猜测——加入了对Tile Package的支持，实现了原生的底图数据离线功能。其它两个移动平台的离线功能，敬请期待。
　　由iPad这个产品引发的变革已经展开，移动设备数量正在爆炸性的增长，桌面设备和移动设备之间的概念会越来越模糊。Windows 8的发布预示着微软已经做出了改变，它即可以运行在桌面电脑上，也可以运行在平板设备中。有人说Windows 8的意义对于微软不亚于当年的Windows 95，我同意这个观点。Esri也做出了积极的改变，新的产品体系，新的产品命名，新的ArcGIS Runtime。