何为Android中的RPC模式?

相信有的读者还不是很理解,这里和大家做一个简单的介绍.RPC模式：Remote Procedure Call即远程进程调用.

在Android操作系统中,各个组件运行在各自的进程中,它们相互之间是不能访问的.但是在程序之间不可避免的要传递一些对象、参数等,这就需要 实现进程间的相互通信.android采用了一种轻量级的实现方式—>RPC模式来完成进程之间的通信.通过定义接口语言(android interface definition language——AIDL)来完成进程之间相互访问的代码.例如：#1你需要在Activity中访问Service中的某一个方法,就可以采用这种方式来实现了.

AIDL语言是android的一种接口描述语言,编译器可以通过AIDL文件生成一段代码(注意：这段代码是自动生成的),通过预先定义的接口达到两个进程内部通信进程的目的.

详细的说下#1例子是什么个意思：如果需要在一个Activity中访问另一个Service中的某个对象,需要先将对象转化成AIDL可识别的参数(可能是多个参数),然后使用AIDL来传递这些参数,在消息的接收端,使用这些参数封装成自己需要的对象.

总的来说：android中的AIDL RPC是通过接口来实现的,类似Windows中的COM或者Corba,但它是轻量级的,客户端和被调用实现之间是通过代理模式实现的,代理类和被代理类实现同一个Ibinder接口.

接下来我就一个具体的案例和大家讲讲RPC模式的具体实现步骤：

第一步：毫无疑问,是创建AIDL接口文件.第一个问题来了,怎样创建AIDL文件?

其实有这个疑问很正常,我上网搜了一些资料,问题解决.

在当前的Activity所在的Package右击,new一个file,取名BookInfo.aidl.该文件中的具体内容如下：

package com.ceo.remoteservice.activity;
//BookInfo的接口文件
interface BookInfo {
   void setName(String name);
   void setPrice(float price);
   void setPublish(String publish);
    
   //显示book信息
   String display();
}

该接口文件中主要包括：当前的package name,接口中的方法的声明.编写完成后ctrl+s,可以发现在gen文件夹下自动生成了BookInfo.java文件.如下图所示：

需要注意的是该文件是系统自动生成的,尽量不要改动里面的代码,以免带来不必要的错误.

第二步：声明一个类public class BookInfoImpl extends BookInfo.Stub

private float price;
private String name,publish;
    
@Override
public String display() throws RemoteException {
    return "书名：" + name + "价格：" + price + "出版社：" + publish;
}
    
@Override
public void setName(String name) throws RemoteException {
    this.name = name;
}
    
@Override
public void setPrice(float price) throws RemoteException {
    this.price = price;
}
    
@Override
public void setPublish(String publish) throws RemoteException {
    this.publish = publish;
}

该文件下实现的这些方法都是在接口文件中定义的.

第三步：向客户端暴露我们的接口,定义一个远程服务的类public class RemoteService extends Service

private Stub bookifo = new BookInfoImpl();

在onBind方法里面直接return bookifo;

第四步：主要就是MainActivity的编写了

最后运行结果如图：

至此,所有关于Android中的RPC模式、AIDL接口语言、以及怎样在Activity中访问另一个Service中的对象就全部介绍完毕了.

有需要整个项目源代码的留下邮箱,或直接加我qq,我会发给大家.

2011.10.20.pm

jack.li

QQ:523072842
Email:523072842@qq.com

原文发表在：http://www.birchlee.com/post/2011/10/19/27.aspx

JavaScript常常遇到一些键值对，以前用二维数组实现，今天索性模拟了一下Dictionary帮助类。

原理：创建一个对象，包含两个数组，键数组和值数组，调用JavaScript Array对象的方法。

W3C参考地址：http://www.w3school.com.cn/js/jsref_obj_array.asp

BuildDictionary()方法用于创建一个包含两个数组的Dictionary对象

AddItem方法 调用JavaScript的 Array对象的push方法，用于将key,value追加到相应的数组。

UpdateItem方法用于更改相应的value

DeleteItem方法 调用JavaScript的Array对象的Splice方法用于删除元素，第一个参数是需要删除的元素的index,第一个参数代表删除的个数。

GetKeyStr用于得到Keys数组拼接后的字符串

GetValueStr用于得到Values数组拼接后的字符串

共包含五个方法：

/*创建Dictionary*/
function BuildDictionary() {
dic = new Object();
dic.Keys = new Array(); //键数组
dic.Values = new Array(); //值数组
return dic;
}

/*添加 key,value*/
function AddItem(key, value, dic) {
var keyCount = dic.Keys.length;
if (keyCount > 0) {
var flag = true;
for (var i = 0; i < keyCount; i++) {
if (dic.Keys[i] == key) {
flag = false;
break; //如果存在则不添加
}
}
if (flag) {
dic.Keys.push(key)
dic.Values.push(value);
}
}
else {
dic.Keys.push(key)
dic.Values.push(value);
}
return dic;
}
/*更改key,value*/
function UpdateItem(key, value, dic) {
var keyCount = dic.Keys.length;
if (keyCount > 0) {
var flag = -1;
for (var i = 0; i < keyCount; i++) {
if (dic.Keys[i] == key) {
flag = i;
break; //查找相应的index
}
}
if (flag > -1) {
dic.Keys[flag] = key;
dic.Values[flag] = value;
}
return dic;
}
else {
return dic;
}
}
/*移除key value*/
function DeleteItem(key, dic) {
var keyCount = dic.Keys.length;
if (keyCount > 0) {
var flag = -1;
for (var i = 0; i < keyCount; i++) {
if (dic.Keys[i] == key) {
flag = i;
break; //查找相应的index
}
}
if (flag > -1) {
dic.Keys.splice(flag,1); //移除
dic.Values.splice(flag, 1); //移除
}
return dic;
}
else {
return dic;
}
}

/*获取Key字符串,用符号拼接*/
function GetKeyStr(separator,dic)
{
var keyCount=dic.Keys.length;
if(keyCount>0)
{
return dic.Keys.join(separator);
}
else
{
return ”;
}
}
/*获取Value字符串,用符号拼接*/
function GetValueStr(separator,dic)
{
var keyCount=dic.Keys.length;
if(keyCount>0)
{
return dic.Values.join(separator);
}
else
{
return ”;
}
}

使用方法：创建一个全局的变量，操作这个全局变量就可以使用了。

在此抛砖引玉了

上一篇写了一下装箱拆箱的定义和IL分析，这一篇我们看下使用泛型和不使用泛型引发装箱拆箱的情况

1. 使用非泛型集合时引发的装箱和拆箱操作

看下面的一段代码：

代码声明了一个ArrayList对象，向ArrayList中添加两个数字1，2；然后使用foreach将ArrayList中的元素打印到控制台。

在这个过程中会发生两次装箱操作和两次拆箱操作，在向ArrayList中添加int类型元素时会发生装箱，在使用foreach枚举 ArrayList中的int类型元素时会发生拆箱操作，将object类型转换成int类型，在执行到Console.WriteLine时，还会执行 两次的装箱操作；这一段代码执行了6次的装箱和拆箱操作；如果ArrayList的元素个数很多，执行装箱拆箱的操作会更多。

你可以通过使用ILSpy之类的工具查看IL代码的box，unbox指令查看装箱和拆箱的过程

2. 使用泛型集合的情况

请看如下代码：

代码和1中的代码的差别在于集合的类型使用了泛型的List，而非ArrayList；我们同样可以通过查看IL代码查看装箱拆箱的情况，上述代码只会在Console.WriteLine()方法时执行2次装箱操作，不需要拆箱操作。

可以看出泛型可以避免装箱拆箱带来的不必要的性能消耗；当然泛型的好处不止于此，泛型还可以增加程序的可读性，使程序更容易被复用等等。

本文使用的C#代码如下：

C#的IL代码如下：

ASP.NET是一个非常强大的构建Web应用的平台，它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用。

绝大多数的人只熟悉高层的框架如： WebForms 和 WebServices –这些都在ASP.NET层次结构在最高层。

这篇文章的资料收集 整理自各种微软公开的文档，通过比较 IIS5、IIS6、IIS7 这三代 IIS 对请求的处理过程， 让我们熟悉 ASP.NET的底层机制并对请求(request)是怎么从Web服务器传送到ASP.NET运行时有所了解。通过对底层机制的了解，可以让我们对 ASP.net 有更深的理解。

IIS 5 的 ASP.net 请求处理过程

对图的解释：

IIS 5.x 一个显著的特征就是 Web Server 和真正的 ASP.NET Application 的分离。作为 Web Server 的IIS运行在一个名为 InetInfo.exe 的进程上，InetInfo.exe 是一个Native Executive，并不是一个托管的程序，而我们真正的 ASP.NET Application 则是运行在一个叫做 aspnet_wp 的 Worker Process 上面，在该进程初始化的时候会加载CLR，所以这是一个托管的环境。

ISAPI：  指能够处理各种后缀名的应用程序。 ISAPI 是下面单词的简写 ：Internet Server Application Programe Interface，互联网服务器应用程序接口。

IIS 5 模式的特点：

1、首先，同一台主 机上在同一时间只能运行一个 aspnet_wp 进程，每个基于虚拟目录的 ASP.NET Application 对应一个 Application Domain ，也就是说每个 Application 都运行在同一个 Worker Process 中，Application之间的隔离是基于 Application Domain 的，而不是基于Process的。

2、其 次，ASP.NET  ISAPI 不但负责创建 aspnet_wp Worker Process，而且负责监控该进程，如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限，ASP.NET  ISAPI 会负责结束掉该进程。当 aspnet_wp 结束掉之后，后续的 Request 会导致ASP.NET ISAPI 重新创建新的 aspnet_wp Worker Process。

3、最后，由于 IIS 和 Application 运行在他们各自的进程中，他们之间的通信必须采用特定的通信机制。本质上 IIS 所在的 InetInfo 进程和 Worker Process 之间的通信是同一台机器不同进程的通信（local interprocess communications），处于Performance的考虑，他们之间采用基于Named pipe的通信机制。ASP.NET ISAPI和Worker Process之间的通信通过他们之间的一组Pipe实现。同样处于Performance的原因，ASP.NET ISAPI 通过异步的方式将Request 传到Worker Process 并获得 Response，但是 Worker Process 则是通过同步的方式向 ASP.NET ISAPI 获得一些基于 Server 的变量。

IIS6 的 ASP.net 请求处理过程

对图的解释：

IIS 5.x 是通过 InetInfo.exe 监听 Request 并把Request分发到Work Process。换句话说，在IIS 5.x中对Request的监听和分发是在User Mode中进行，在IIS 6中，这种工作被移植到kernel Mode中进行，所有的这一切都是通过一个新的组件：http.sys 来负责。

注：为了避免用户应 用程序访问或者修改关键的操作系统数据，windows提供了两种处理器访问模式：用户模式（User Mode）和内核模式（Kernel Mode）。一般地，用户程序运行在User mode下，而操作系统代码运行在Kernel Mode下。Kernel Mode的代码允许访问所有系统内存和所有CPU指令。

在User Mode下，http.sys接收到一个基于 aspx 的http request，然后它会根据IIS中的 Metabase 查看该基于该 Request 的 Application 属于哪个Application Pool， 如果该Application Pool不存在，则创建之。否则直接将 request 发到对应Application Pool 的 Queue中。

每个 Application Pool 对应着一个Worker Process：w3wp.exe，毫无疑问他是运行在User Mode下的。在IIS Metabase 中维护着 Application Pool 和worker process的Mapping。WAS（Web Administrative service）根据这样一个mapping，将存在于某个Application Pool Queue的request 传递到对应的worker process(如果没有，就创建这样一个进程)。在 worker process 初始化的时候，加载ASP.NET ISAPI，ASP.NET ISAPI 进而加载CLR。最后的流程就和IIS 5.x一样了：通过AppManagerAppDomainFactory 的 Create方法为 Application 创建一个Application Domain；通过 ISAPIRuntime 的 ProcessRequest处理Request，进而将流程进入到ASP.NET Http Runtime Pipeline。

IIS 7  的 ASP.net 请求处理过程

IIS7 站点启动并处理请求的步骤如下图：

步骤 1 到 6 ，是处理应用启动，启动好后，以后就不需要再走这个步骤了。

上图的8个步骤分别如下：

1、当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时，HTTP.sys 拦截到这个请求。

2、HTTP.sys contacts WAS to obtain information from the configuration store.

3、WAS 向配置存储中心请求配置信息。applicationHost.config。

4、WWW 服务接受到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。

5、WWW 服务使用配置信息去配置 HTTP.sys 处理策略。

6、WAS starts a worker process for the application pool to which the request was made.

7、The worker process processes the request and returns a response to HTTP.sys.

8、客户端接受到处理结果信息。

W3WP.exe 进程中又是如果处理得呢？？ IIS 7 的应用程序池的托管管道模式分两种： 经典和集成。 这两种模式下处理策略各不相通。

IIS 6 以及 IIS7 经典模式的托管管道的架构

在IIS7之前，ASP.NET 是以 IIS ISAPI extension 的方式外加到 IIS，其实包括 ASP 以及 PHP，也都以相同的方式配置（PHP 在 IIS 采用了两种配置方式，除了 IIS ISAPI extension 的方式，也包括了 CGI 的方式，系统管理者能选择 PHP 程序的执行方式），因此客户端对 IIS 的 HTTP 请求会先经由 IIS 处理，然后 IIS 根据要求的内容类型，如果是 HTML 静态网页就由 IIS 自行处理，如果不是，就根据要求的内容类型，分派给各自的 IIS ISAPI extension；如果要求的内容类型是 ASP.NET，就分派给负责处理 ASP.NET 的 IIS ISAPI extension，也就是 aspnet_isapi.dll。下图是这个架构的示意图。

IIS  7 应用程序池的托管管道模式  经典  模式也是这样的工作原理。 这种模式是兼容IIS 6 的方式， 以减少升级的成本。

IIS6 的执行架构图，以及 IIS7  应用程序池配置成经典模式的执行架构图

IIS  7 应用程序池的 托管管道模式  集成模式

而 IIS 7 完全整合 .NET 之后，架构的处理顺序有了很大的不同（如下图），最主要的原因就是 ASP.NET 从 IIS 插件（ISAPI extension）的角色，进入了 IIS 核心，而且也能以 ASP.NET 模块负责处理 IIS 7 的诸多类型要求。这些 ASP.NET 模块不只能处理 ASP.NET 网页程序，也能处理其他如 ASP 程序、PHP 程序或静态 HTML 网页，也因为 ASP.NET 的诸多功能已经成为 IIS 7 的一部份，因此 ASP 程序、PHP 程序或静态 HTML 网页等类型的要求，也能使用像是Forms认证（Forms Authentication）或输出缓存（Output Cache）等 ASP.NET 2.0 的功能（但须修改 IIS 7 的设定值）。也因为 IIS 7 允许自行以 ASP.NET API 开发并加入模块，因此 ASP.NET 网页开发人员将更容易扩充 IIS 7 和网站应用程序的功能，甚至能自行以 .NET 编写管理 IIS 7 的程序（例如以程控 IIS 7 以建置网站或虚拟目录）。

IIS 7 的执行架构图（集成托管信道模式下的架构）

小结

IIS5 到 IIS6 的改进，主要是 HTTP.sys 的改进。

IIS6 到 IIS7 的改进，主要是 ISAPI 的改进。

参考资料：

ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI

http://www.cnblogs.com/artech/archive/2007/09/09/887528.html

ASP.NET Internals – IIS and the Process Model

http://dotnetslackers.com/articles/iis/ASPNETInternalsIISAndTheProcessModel.aspx

模组化的IIS 7 与.NET 能力整合

http://www.microsoft.com/taiwan/technet/columns/profwin/33-iis7-componentization-integration.mspx

Introduction to IIS 7.0 Architecture

http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/

最近在项目中进行压力测试遇到了数据库的死锁问题，简言之，如下的代码在 SERIALIZABLE 隔离级别造成了死锁：

在搞清楚这个问题的过程中做了不少的实验，与各位共享。这一篇是开篇，主要说明的是 SQL Server 的四种（其实还有别的）经典的事务隔离级别，以及在不同的隔离级别下锁的使用手段，以及所带来的不同的数据一致性。

SQL Server 中锁的种类（Schema操作就暂时不涉及了）

各个事务隔离级别下锁的使用

SQL Server 中有四种事务隔离级别，具体的大家去参建 MSDN。下面列出在不同的事务隔离级别下这些锁是如何使用的：

我们可以利用这些知识形象说明各个隔离级别下的数据一致性：

Read Uncommitted 级别

（1）脏读

（2）更新丢失

（3）不可重复读

（4）幻读

Read Committed 级别

（1）脏读

（2）更新丢失

（3）不可重复读

（4）幻读

Repeatable Read 级别

（1）脏读

（2）更新丢失

（3）不可重复读

（4）幻读

Serializable 级别

（1）脏读

（2）更新丢失

（3）不可重复读

（4）幻读

我们从上图可以比较直观的看到以下的结论

这一篇到此为止，下一篇详细介绍 Key-Range Lock 并分析开篇提到的死锁问题。

之前在“反向Ajax，第1部分：Comet介绍”（英文版）文章中学习了“基于 Multipart XMLHttpRequest 的 Comet”的知识，然后用 ASP.NET MVC 实现了一个，详见用 ASP.NET MVC 实现基于 Multipart XMLHttpRequest 的 Comet。

今天继续学习了基于 XMLHttpRequest long polling 的 Comet，又用 ASP.NET MVC 实现了一个，在这篇文章中分享一下。

先了解一下什么是XMLHttpRequest long polling？

这是一种推荐的实现Comet的做法，打开一个到服务器端的Ajax请求然后等待响应。服务器端需要一些特定的功能来允许请求被挂起，只要一有事件 发生，服务器端就会在挂起的请求中送回响应并关闭该请求。然后客户端就会使用这一响应并打开一个新的到服务器端的长生存期的Ajax请求。

This is a recommended method to implement Comet is to open an Ajax request to the server and wait for the response. The server requires specific features on the server side to allow the request to be suspended. As soon as an event occurs, the server sends back the response in the suspended request and closes it. The client then consumes the response and opens a new long-lived Ajax request to the server.

我个人的理解是，看起来就像在Web环境中客户端能订阅服务端的事件，服务器端通过事件去通知客户端。如果服务器端用 ASP.NET 来实现，可以利用 .NET 的事件驱动机制，很有意思，下面的示例代码将展示这一点。

先看Web前端js代码：

jQuery(function ($) {
    function long_polling() {
        $.getJSON('/comet/LongPolling', function (data) {
            if (data.d) {
                $('#logs').append(data.d + "<br/>");
            } 
            long_polling();
        });
    }
    long_polling();
});

js代码很简单，就是一个递归调用（调用在callback时进行的），通过JQuery的$.getJSON发起Ajax请求，’/comet /LongPolling’ 表示请求的服务端 CometController 的 LongPolling Action 的网址。这里我们可以看出实现 Comet 的难点不在 Web 前端，而是在服务器端。

接下来重点看 Web 服务器 ASP.NET MVC Controller 的代码。

首先要注意的是为了响应 XMLHttpRequest long polling 请求，我们需要实现一个异步控制器（AsyncController），如果您对 AsyncController 不熟悉，建议阅读MSDN上的文章 Using an Asynchronous Controller in ASP.NET MVC 。

先上 Controller 的实现代码：

（注：该控制器实现的功能是每隔5秒钟向客户端发送服务器当时间）

public class CometController : AsyncController
{
    //LongPolling Action 1 - 处理客户端发起的请求
    public void LongPollingAsync()
    {
        //计时器，5秒种触发一次Elapsed事件
        System.Timers.Timer timer = new System.Timers.Timer(5000);
        //告诉ASP.NET接下来将进行一个异步操作
        AsyncManager.OutstandingOperations.Increment();
        //订阅计时器的Elapsed事件
        timer.Elapsed += (sender, e) =>
            {
                //保存将要传递给LongPollingCompleted的参数
                AsyncManager.Parameters["now"] = e.SignalTime;
                //告诉ASP.NET异步操作已完成，进行LongPollingCompleted方法的调用
                AsyncManager.OutstandingOperations.Decrement();
            };
        //启动计时器
        timer.Start();
    }

    //LongPolling Action 2 - 异步处理完成，向客户端发送响应
    public ActionResult LongPollingCompleted(DateTime now)
    {
        return Json(new { d = now.ToString("MM-dd HH:mm:ss ") + 
            "-- Welcome to cnblogs.com!" }, 
            JsonRequestBehavior.AllowGet);
    }
}

实现异步控制器需要继承 System.Web.Mvc.AsyncController，并将 Action 分解为两个，比如 Action 叫 LongPolling，则分解为 LongPollingAsync 与 LongPollingCompleted 。LongPollingAsync 接受客户端请求，并发起异步操作；异步操作完成，调用LongPollingCompleted。

AsyncManager.OutstandingOperations.Increment(); 告诉ASP.NET接下来将进行一个异步操作。

AsyncManager.OutstandingOperations.Decrement(); 告诉ASP.NET异步操作完成，请调用LongPollingCompleted()方法。

示例代码中的异步操作就是将服务器当前时间作为参数传递给 LongPollingCompleted() 方法，LongPollingCompleted() 获取服务器当前时间并传递给客户端，客户端收到后将之显示出来，将继续发起 Ajax 请求 … 这样周而复始，实现了基于 XMLHttpRequest long polling 的 Comet。

示例代码运行结果如下：

小结

以前觉得 Comet 是很高深的东西，自己动手做了之后，发觉原来没那么难。所以，重要的是动手去做！

如果不能在实际项目中去做，那就写一篇博客吧！

代码下载

CometMvcDemo_LongPolling.rar