浅谈android与Xen之间的一点共性

      不管是个人计算机还是云计算中很重要的一个环节就是内存管理，也可以说是资源共享的问题。运行在系统上的独立个体要独立的运行，其使用的资源必须也具有绝对的独立性，即是要提供隔离措施，否则除了正常的IPC同步之外，系统必须还要花费远超过IPC同步机制所需要的工作量来处理这些不必要的问题。个体之间的交互（IPC），简言之，即是两个个体之间要互访彼此的资源，这样系统不得不为IPC提供必须的同步机制。与不隔离个体资源的情况相比，系统要处理的同步需求就少了很多了。

这种即要互相隔离有时还要互动的若即若离的关系从操作系统的诞生之初就一直延续到现在。

今天，勇妹与我讨论问题时，提到一篇文章，讲Xen在云计算平台中如何节省内存的，当然这篇文章中的技术还没有应用到实际当中去。

        文章大体思想是：在Xen上运行了很多的虚拟机（dom1，dom2......domN），其中肯定是有些dom的系统需求，硬件需求具有相似性，而如果Xen作为VMM不加区分的为这些dom统统提供虚拟内存，那势必会造成极大内存的浪费，对于那些具有相似性的dom，如果能将这些相似性作为VMM上的共享资源来分配的话，那么能够节省的资源又是可观的。但是如果要这样做的话，潜在的许多问题就亟待解决了。比如说，什么样的资源是可以共享的呢？嗯， 有点跑题了。

我们知道，Xen作为VMM虽然对其上所运行的dom是扮演的管理员的角色，但是Xen对于各个dom在内存中的数据是无法理解的（准确的说应该是无法从整体上、逻辑上进行理解的，因为VMM对单个内存页单元还是可读的），这样就带来一个问题，谁来决定哪些dom可以共享资源呢？ Xen？可能不行吧，如果Xen对资源具有决策权的，那势必需要对资源具有一定的理解，本来Xen对domN的内存只具有理解单个内存页的能力就被提升了。

不能由dom0来决策，那就有domN自己来决策吧。需要由domN来决定的是什么？我想有这么几点：a. 哪些资源是可以共享的；b. 谁可以访问这些资源，说的更细一点，应该是谁对哪些资源具有什么样的操作权限。

 

好了，这个问题现在有点和andriod类似了。在android里面每个App对应一个Dalvik VM实例，在内核中对应一个以app_num为user id的进程，与传统的linux进程已pid来标示进程的方式不同，这里为每个App分配了一个唯一的app_num做为user id 而淡化了pid的作用，不同的user id之间互相隔离。为了处理App之间的IPC行为，Android提供了Intent/Intent filter来协调App之间的IPC行为。值得一提的是Android为App提供了一个shareUserID的机制，Android设备上的App发布时都带有各个开发者独有的签名，shareUserID规定具有相同的userID的App可以启用shareUserID机制来共享内存，即是说使用了shareUserID机制的Apps是无需经过中间代理还进行IPC的，他们的之间可以互访彼此的内存，我想这也是为什么Android系统占用内存比较小的原因之一吧。

 

如此说来，Android shareUserID机制是可以用到云计算平台上去的（或许在做为google云计划一部分的Android系统设计时就考虑到这个机制在与计算方面的可用性了吧），当然，我觉得完全照搬到云计算平台上去的可能性是不合适的。首先，云计算平台是一个具有相当开放性的平台，运行在上面domN更是来自不同的不明用户，而Android只是某一个用户的手机设备，两者的安全敏感性是不一样的。再者，shareUserID在Android系统中是否存在安全隐患还是一个未知数。 总之，这样的共享机制要想使用到云计算中google还有很长的路要走呢。

 

唉， 吭吭哧哧写了这么一点，本人水平有限，Xen也不大动，Android接触了才半个月，惭愧。 偶有感于两者的相似，写下了这么一篇博文，若此文有幸经您过目，不足之处、有误之处还劳驾指出，鄙人感激不尽了。