在上一篇文章《分享 2011年Esri用户大会技术亮点总结之二：ArcGIS Runtime》中，大家已经对ArcGIS Runtime产品有了基本的了解。本文试图解读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。
原文转自菩提老王的博客