与平常不一样，在这篇博客里我想谈谈关于移动应用哲学方面的东西，而不是冷冰冰的代码。现在已经有很多移动应用平台，其中有一些比如塞班 (Symbian)应用很广泛。而基于java的也有很多，比J2ME, OSGI R4, LIMO等等，那多一个java的平台又有什么值得新奇呢？每个人都有自己的答案而我认为Android的出现是一个很大的因素。当我研究Android 这个平台时，两年前我写的一篇论文（这里坐下广告，不好意思）不断的浮现在我的大脑，这篇论文里讲了四个主要的移动中间件模式。
环境感知
传统的中间件对系统进行了严格的分层，这意味这他屏蔽了应用程序得到底层的事件(event)的可能。比如，当不能发送一个远程调用时，中间层会不 断重试，最后会发送一个普通错误到服务的使用者。环境感知意味着这里没有所谓的“屏蔽”，应用程序知道它所处的周围环境。本质上环境变化是异步的并且用事 件的现实发送。一点要强调的是只有应用程序才能决定哪些环境事件是重要的以及如何处理它们。例如当一个应用程序察觉到廉价而快速的网络连接（译注：比如 wifi）不再存在时，应用可以切回到缓慢而昂贵的移动网络。这种选择可能不适合一个游戏，因为一般我们不允许游戏在断线的情况下连接昂贵的移动网络，这 个时候程序报错，或者切换到单机的模式。（译注：这里的环境感知更多指代码上的上下文，不特指手机的重力感应、地理位置感应、环境光感应等功能）
反射
反射一般意味着程序能够在运行时，根据自身的数据结构进行计算（得到当前的结构、根据环境对结构求值，如果需要的话最后更新结构）。在移动计算中， 反射是一个关键的技术，特别是应用需要环境感知的功能时。即使一个中等数量的环境状态也能产生数量巨大的状态组合。如果应用和中间件建立在单一古老的方 式，它们必须面对所有的状态组合的情况，这回让情况变得难以处理，而且需要更多内存。为了使内存痕迹(footprint)最小，系统设计更清楚明了，中 间层必须解耦合成更小的组件。这样，应用可以选择它需要的组件然后组成中间层来更好的为应用服务。当环境变化时，应用根据环境变化来改变组件或者组件的配 置。
离线访问
离线是移动计算的内在属性。离线的原因可能是物理的（不在服务区）或者是社会的（移动访问太贵或者在某种情况下是不可接受的）。为了提供可接受的用户体验，在离线模式下必须也能继续操作。要实现这关键的技术是数据和代码的重组。数据重组可以用成熟的数据同步技术实现。
异步通信
网络计算一般采用远程过程调用（RPC）的方式。RPC模仿单处理器上的过程调用，当被调用过程运行时，调用过程挂起。因此，RPC本质上是同步 的。而移动传输网络有这样的特点：长时间的不稳定的延迟和频繁的传输错误。在这种环境下，通信必须是异步的（基于事件的或者消息也可以归于此类）。这影响 了通信语义。
这篇论文接下来设计了一个OSGI的框架，但那时过去的事了。所以你可以猜到当我看到Android实现了上面的那些特征时我有多么惊讶。 Android中的Intent分发框架对于环境感知来说是非常适合的，正当前的Android实现里，Intent的匹配逻辑相当简单（通过 action和category匹配），但是如果目标平台允许（考虑到电量消耗，处理器速度），把它扩展成一个功能强大的匹配逻辑也不需要很多的工作，而 且当这种匹配逻辑反复调用时，速度更快。
另外，离线操作- 可同步的内容提供者（provider），也是平台的一个部分。平台唯一缺失的部分是一个功能强大的异步通信框架，比如队列。XMPP服务就提供了这个功能，不过刚刚被移除了。
Android不仅仅是另外的一个基于java的移动平台，事实上是唯一的一个采用了移动中间层研究结果（译注：指作者的论文）的平台，因此它本身就很有趣，即使它没有开发者竞赛和它的奖励。它将来的命运主要要看商业上的因素，不管如何，它的架构仍然领先其他对手好几步。
