Service与Android系统实现（1）-- 应用程序里的Service （三）

双向Remote Service

在AIDL编程环境里实际上是支持反向调用的，原理跟我们实现一个Remote Service一样，就是通过把Proxy与Stub反过来，就得到了这样的回调式的aidl编程。唯一的区别是，当我们的Stub在Activity时实现时，我们实际上跟后台线程执行也没有区别，Callback并非是在主线程里执行的，于是不能进行重绘界面的工作。于是，我们必须像后台线程编程一样，使用Handler来处理界面显示处理。

定义AIDL

前面我们说过aidl是可以互相引用的，于是我们可以借用这样的机制，通过引用另一个新增的aidl文件来加强我们前面的单向的TaskService版本。我们先增加一个新的ITaskServiceCallback.aidl文件，与ITaskService保持同一目录：

package org.lianlab.services;
onewayinterface ITaskServiceCallback {
   void valueCounted(int value);
}

在这一定义里，我们新增加了一个ITaskServiceCallback的接口类，基本上与我们前面的ITaskService.aidl一样，在这个接口类里，我们新加了一个valueCounted()方法，这一方法将会被Service所使用。

在这个文件里，唯一与ITaskService.aidl不同之处在于，我们使用了一个oneway的标识符，oneway可以使aidl调用具有异步调用的效果。在默认情况下，基于aidl的调用都会等待远端调用完成之后再继续往下执行，但有时我们可能希望在跨进程调用会有异步执行的能力，我们在发出调用请求后会立即返回继续执行，调用请求的结果会通过其他的callback返回，或是我们干脆并不在乎成功与否，此时就可以使用oneway。当然，从我们前面分析aidl底层进行的工作，我们可以知道，所谓的远程调用，只不过是通过Binder发送出去一个命令而已，所以在aidl里面如果使用了oneway限定符，也就是发送了命令就收工。

然后，我们修改一下我们的ITaskService.aidl，使我们可以使用上这个新加入的回调接口：

package org.lianlab.services;
import org.lianlab.services.ITaskServiceCallback;
interface ITaskService {
    intgetPid (ITaskServiceCallback callback);
}

在Service端调用回调方法

我们会引用前面定义好的ITaskServiceCallback.aidl文件，通过包名+接口的方式进行引用。为了省事，我们直接在原来的getPid()方法里进行修改，将新定义的ITaskServiceCallback接口类作为参数传递给getPid()接口。于是，在Service端Stub对象里实现的getPid()方法，将可以使用这一回调对象：

package org.lianlab.services;
import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.os.Process;
import android.os.RemoteException;

public class TaskService extends Service {

   static private int mCount = 0;

   @Override
   public IBinder onBind(Intent intent) {
       if (ITaskService.class.getName().equals(intent.getAction())) {
           return mTaskServiceBinder;
       }
       return null;
    }

   private final ITaskService.Stub mTaskServiceBinder = newITaskService.Stub() {
       public int getPid(ITaskServiceCallback callback) { 1
           mCount ++ ;     2
           try {   3
                callback.valueCounted(mCount);    4
           } catch (RemoteException e) {
                e.printStackTrace();
           }
           return Process.myPid();
       }
    };
}

加入了回调之后的代码结构并没有大变，只增加了3部分的内容，通过这三部分的内容，我们此时便可以记录我们的getPid()总共被调用了多少次。

1. getPid()方法，是通过aidl定义来实现的，否则会报错。所以我们这里新的getPid()会按照aidl里的定义加入ITaskServiceCallback对象作为参数，与ITaskService对象相反，这一对象实际上是由客户端提供给Service端调用的。
2. 为了记录下getPid()被调用了多少次，我们使用了一个mCount来进行计数，这一int为static类型，于是在Service生存周期里会始终有效。但这部分的改动与我们的回调改进并无直接关系。
3. 在使用回调接口ITaskServiceCall之前，因为这是一个远程引用，我们会需要捕捉Remote Exception，由客户端抛出的异常将在这里被捕获处理。
4. 调用ITaskServiceCall里定义的回调方法，将处理发送给客户端。此时，因为是oneway，这时很多就会从回调方法里返回，继续执行原来的getPid()，再将处理结果以返回值的形式发送回客户端。

加入了回调之后，对Service端的实现并没有增加多大的工作量，因为作为回调，实现是放在客户端上来完成的。

在Client端加入回调实现

因为我们的aidl接口已经发生了变动，于是需要将新加的ITaskServiceCall.aidl与改变过的ITaskService.aidl文件拷贝到应用程序工程里。我们再来看一下客户端实现代码需要作怎样的调整：

package org.lianlab.services;
import android.os.Bundle;
import android.os.Handler;
import android.os.IBinder;
import android.os.RemoteException;
import android.app.Activity;
import android.content.ComponentName;
import android.content.Context;
import android.content.Intent;
import android.content.ServiceConnection;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.TextView;

import org.lianlab.services.R;

public class MainActivity extends Activity {

   ITaskService mTaskService = null;
   private TextView mCallbackText;
   private Handler mHandler = new Handler();

   @Override
   public void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);

       try {
           bindService(newIntent(ITaskService.class.getName()), mTaskConnection,
                    Context.BIND_AUTO_CREATE);
       } catch (SecurityException e) {
           e.printStackTrace();
       }

       setContentView(R.layout.activity_main);

        ((TextView)findViewById(R.id.textView1)).setOnClickListener(new OnClickListener() {
           @Override
           public void onClick(View v) {
                if (mTaskService != null) {
                    try {
                        int mPid = -1;
                        mPid =mTaskService.getPid(mCounter); 1
                        ((TextView)findViewById(R.id.textView1))
                               .setText("Service pid is " + mPid);
                    } catch (RemoteException e){
                        e.printStackTrace();
                    }
                } else {
                    ((TextView)findViewById(R.id.textView1)).setText("No service connected");
                }
           }
       });

       mCallbackText = (TextView) findViewById(R.id.callbackView); 2
       mCallbackText.setText("Clicked 0 times");
    }

   @Override
   public void onDestroy() {
       super.onDestroy();
       if (mTaskService != null) {
           unbindService(mTaskConnection);
       }
    }

   private ServiceConnection mTaskConnection = new ServiceConnection() {
       public void onServiceConnected(ComponentName className, IBinder service){
           mTaskService = ITaskService.Stub.asInterface(service);
       }

       public void onServiceDisconnected(ComponentName className) {
           mTaskService = null;
       }
    };

   private ITaskServiceCallback.Stub mCounter = newITaskServiceCallback.Stub() {       3
       public void valueCounted(final int n) {
           mHandler.post(new Runnable() {     4
                public void run() {
                   mCallbackText.setText("Clicked " + String.valueOf(n) + "  times");
                }
           });
       }
    };

}

新加入的回调接口对象，也没给我们带来多大的麻烦，我们最重要是提供一个实例化的ITaskServiceCallback.Stub对象，然后通过getPid()将这一远程对象的引用发送给Service端。之后，Service处理后的回调请求，则会通过Binder会回到客户端，调用在Stub对象里实现的回调方法。所以我们实际增加的工作量，也仅是写一个ITaskServiceCallback.Stub接口类的实现而已：

1. 我们需要使用通过getPid()，将ITaskServiceCallback.Stub传递给Service。因为这一对象是用于Service使用的，于是我们必须在使用前先创建，然后再以引用的方式进行传递，像我们代码例子里的mCounter对象。
2. 这一部分的改动，只是为了让我们检查效果时更方便，我们通过一个新加的id为callbackView的textView，来显示getPid()被调多次的效果。
3. 这是我们真正所需的改动，通过新建一个ITaskServiceCallback.Stub对象，于是当前进程便有了一个Stub实体，用于实现aidl里定义的valueCounted()接口方法，对Binder过来这一接口方法的调用请求作响应。
4. valueCounted()是一个回调方法，从编程模型上我们可以类似的看成是由Service进程所执行的代码，于是我们需要通过Handler()来处理显示。当然，在实现上不可能如此神奇，我们可以把一个方法搬运到另一个进程空间里运行，但valueCounted()既然也不是在主线程环境里执行，而是通过线程池来响应Binder请求的，于是跟后台线程的编程方式一样，我们使用Handler来处理回显。Handler本身是一种很神奇的实现机制，它可以弱化编程环境里的有限状态机的硬性限制，也可以使代码在拓展上变得更灵活，我们会在后续内容里加以说明。

从上面的代码可以看出，我们通过aidl创建回调方法好像比我们直接通过aidl写一个Remote Service还要简单。事实上，并非回调创建方便，在原则上，我们本只需要一个Stub对象便可以得到我们想要的RPC能力了，只不过出于管理存活周期的需要，才融入到了Service管理框架里，因为这种Service使用上的需求才带来了一些编程上的开销