经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » 移动开发 » Android » 查看文章
《犬夜叉2021》我想通过Binder找到你
来源：cnblogs　　作者：jimuzz　　时间：2021/1/18 15:59:03　　对本文有异议

image

前言

本故事纯属虚构，如有不通顺的逻辑请轻喷。??

《犬夜叉2021》

第一章：我还能找到你吗，阿篱

犬夜叉和奈落大决战之后，四魂之玉、食骨之井消失，谁也不知道去了哪，而犬夜叉和阿篱再次被分割到两个世界。

于是犬夜叉拜托一位研究世界宇宙的法师——积木，来帮助他找到阿篱。

时间转眼来到了2021年，积木终于发现了这个世界的秘密。。

其实我们所在的整个宇宙叫做Android宇宙，犬夜叉和阿篱所处的两个世界其实是两个进程，两个世界可以通过食骨之井相连接。

所以想让犬夜叉重新联系到阿篱，必须再找到当年的食骨之井。

第二章：食骨之井改名Binder井？

“犬夜叉，我终于找到了”

“找到什么了？是阿篱吗？阿篱找到了？？？？”

“没有，不过我找到了关键的东西——食骨之井”

“在哪，快带我去”

于是，积木法师带着犬夜叉来到一间屋子里：

这间屋子门面上写着《内核屋》三个大字，犬夜叉一个箭步飞了进去，在里面果然找到了当年那个食骨之井，但是又有点不一样，因为它被改了名，旁边一个破碎的板子上写着——Binder井。板子上还同时刻有使用说明：

Binder井
这口井联系这两个世界，你看到的也许不是真实的，请慎用！
如需使用，请找到当年遗落的四魂之玉，现在它叫SM之玉（ServiceManager）。
找到SM之玉，心里默念你想联系的那个世界那个人，如果她在那个世界的SM之玉碎片中留下了地址，那么你就能找到她。

“积木法师，你知道SM之玉吗，哪里可以找到它”，犬夜叉问到。

第三章：四魂之玉——ServiceManager

“说到SM之玉，还要从宇宙的起源说起，Android宇宙创建初期，诞生了第一个有人的世界（用户进程），叫做Init世界，而SM之玉就是由这个世界创建的。

SM之玉创建后，启动了Binder井，成为了他的守护神。

但是它的真身存在于单独的世界中，无法获得。为了让人们能够使用到它，它特意在每个世界都留下了自己的碎片（代理）。”

“在哪在哪，快告诉我”。

“第0街道（句柄值固定为0）”，积木法师指了一个方向说到。

第四章：阿篱，我想你了

犬夜叉急忙去第0街道找到了SM之玉的碎片，然后回到Binder井旁边，心里默念道：

“
SM之玉，
求求你帮我找到阿篱吧。
”

忽然，Binder井刮出一阵狂风，一个虚影出现在了犬夜叉的面前。

是阿篱～

“阿篱，你能听到我说话吗？”

“犬夜叉，我能听到，没想到还能看到你”，阿篱的虚影说到。

“我想你了，阿篱...”

故事End

故事结束了。

再帮大家理一下故事梗概，其实也就是Binder的工作流程：

  • 阿篱（服务端） 为了让犬夜叉（客户端） 找到她，在四魂之玉（ServiceManager） 上留下了他们世界（进程） 的地址。
  • 犬夜叉在第0街道（句柄为0） 找到了四魂之玉碎片（ServiceManager代理）。
  • 通过四魂之玉碎片，犬夜叉看到了阿篱的虚影（服务端代理），并通过虚影告诉了阿篱，想她了（通信）。

当然，故事毕竟是故事，并不能完全说清楚。

所以下面就完整看看Binder的工作流程和原理～

代码实现犬夜叉的需求

首先，我们使用AIDL来实现刚才故事中的场景——让犬夜叉和阿篱两个不同进程的人说上话：

  1. //IMsgManager.aidl
  3. interface IMsgManager {
  4.       String getMsg();
  5.       void tell(in String msg);
  6. }
  8. //阿篱
  9. public class AliWorldService extends Service {
  11.     private static final String TAG = "lz1";
  13.     @Nullable
  14.     @Override
  15.     public IBinder onBind(Intent intent) {
  16.         return mBinder;
  17.     }
  19.     private Binder mBinder = new IMsgManager.Stub() {
  20.         @Override
  21.         public String getMsg() throws RemoteException {
  22.             String tellMsg="犬夜叉...是我";
  23.             Log.e(TAG, "阿篱：" + tellMsg);
  24.             return tellMsg;
  25.         }
  27.         @Override
  28.         public void tell(String msg) throws RemoteException {
  29.             Log.e(TAG, "我是阿篱，我收到了你说的:" + msg);
  30.         }
  31.     };
  32. }
  34. <service
  35.     android:name=".binder.AliWorldService"
  36.     android:process=":aliworld">
  37. </service>
  40. //犬夜叉
  41. public class QycWorldActivity extends Activity {
  42.     private static final String TAG = "lz1";
  44.     @Override
  45.     protected void onCreate(@Nullable Bundle savedInstanceState) {
  46.         super.onCreate(savedInstanceState);
  47.         setContentView(R.layout.activity_qyc);
  49.         Intent i = new Intent(this, AliWorldService.class);
  50.         bindService(i, mConnection, Context.BIND_AUTO_CREATE);
  51.     }
  53.     private ServiceConnection mConnection = new ServiceConnection() {
  54.         @Override
  55.         public void onServiceConnected(ComponentName name, IBinder service) {
  56.             IMsgManager msgManager = IMsgManager.Stub.asInterface(service);
  57.             try {
  58.                 String tellMsg="阿篱，是你吗";
  59.                 Log.e(TAG, "犬夜叉：" + tellMsg);
  60.                 msgManager.tell(tellMsg);
  63.                 String msg = msgManager.getMsg();
  64.                 Log.e(TAG, "我是犬夜叉，我收到了你说的：" + msg);
  66.             } catch (RemoteException e) {
  67.                 e.printStackTrace();
  68.             }
  69.         }
  71.         @Override
  72.         public void onServiceDisconnected(ComponentName name) {
  74.         }
  75.     };
  77.     @Override
  78.     protected void onDestroy() {
  79.         super.onDestroy();
  80.         unbindService(mConnection);
  81.     }
  83. }

运行，打印结果：

  1. E/lz1: 犬夜叉：阿篱，是你吗
  2. E/lz1: 我是阿篱，我收到了你说的：阿篱，是你吗
  3. E/lz1: 阿篱：犬夜叉...是我
  4. E/lz1: 我是犬夜叉，我收到了你说的：犬夜叉...是我

AIDL原理

代码比较简单，服务器端新建一个Binder对象并传到onBind方法中，客户端bindservice之后，获取到服务端的代理接口，就可以进行方法的调用了。

AIDL其实只是一个帮助我们实现进程间通信的工具，它会根据我们写的AIDL文件代码，生成相应的java接口代码，其内部也是通过Binder实现的。

我们可以通过build——generated——aidl_source_output_dir——debug——out文件路径找到AIDL为我们生成的接口类。代码如下：

  1. public interface IMsgManager extends android.os.IInterface {
  3.     public static abstract class Stub extends android.os.Binder implements com.example.studynote.binder.IMsgManager {
  5.         //1
  6.         private static final java.lang.String DESCRIPTOR = "com.example.studynote.binder.IMsgManager";
  8.         public Stub() {
  9.             this.attachInterface(this, DESCRIPTOR);
  10.         }
  12.         //2
  13.         public static com.example.studynote.binder.IMsgManager asInterface(android.os.IBinder obj) {
  14.             if ((obj == null)) {
  15.                 return null;
  16.             }
  17.             android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
  18.             if (((iin != null) && (iin instanceof com.example.studynote.binder.IMsgManager))) {
  19.                 return ((com.example.studynote.binder.IMsgManager) iin);
  20.             }
  21.             return new com.example.studynote.binder.IMsgManager.Stub.Proxy(obj);
  22.         }
  24.         @Override
  25.         public android.os.IBinder asBinder() {
  26.             return this;
  27.         }
  30.         //4
  31.         @Override
  32.         public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
  33.             java.lang.String descriptor = DESCRIPTOR;
  34.             switch (code) {
  35.                 case INTERFACE_TRANSACTION: {
  36.                     reply.writeString(descriptor);
  37.                     return true;
  38.                 }
  39.                 case TRANSACTION_getMsg: {
  40.                     data.enforceInterface(descriptor);
  41.                     java.lang.String _result = this.getMsg();
  42.                     reply.writeNoException();
  43.                     reply.writeString(_result);
  44.                     return true;
  45.                 }
  46.                 case TRANSACTION_tell: {
  47.                     data.enforceInterface(descriptor);
  48.                     java.lang.String _arg0;
  49.                     _arg0 = data.readString();
  50.                     this.tell(_arg0);
  51.                     reply.writeNoException();
  52.                     return true;
  53.                 }
  54.                 default: {
  55.                     return super.onTransact(code, data, reply, flags);
  56.                 }
  57.             }
  58.         }
  60.         private static class Proxy implements com.example.studynote.binder.IMsgManager {
  61.             private android.os.IBinder mRemote;
  63.             Proxy(android.os.IBinder remote) {
  64.                 mRemote = remote;
  65.             }
  67.             @Override
  68.             public android.os.IBinder asBinder() {
  69.                 return mRemote;
  70.             }
  72.             public java.lang.String getInterfaceDescriptor() {
  73.                 return DESCRIPTOR;
  74.             }
  77.             //3
  78.             @Override
  79.             public java.lang.String getMsg() throws android.os.RemoteException {
  80.                 android.os.Parcel _data = android.os.Parcel.obtain();
  81.                 android.os.Parcel _reply = android.os.Parcel.obtain();
  82.                 java.lang.String _result;
  83.                 try {
  84.                     _data.writeInterfaceToken(DESCRIPTOR);
  85.                     mRemote.transact(Stub.TRANSACTION_getMsg, _data, _reply, 0);
  86.                     _reply.readException();
  87.                     _result = _reply.readString();
  88.                 } finally {
  89.                     _reply.recycle();
  90.                     _data.recycle();
  91.                 }
  92.                 return _result;
  93.             }
  95.             @Override
  96.             public void tell(java.lang.String msg) throws android.os.RemoteException {
  97.                 android.os.Parcel _data = android.os.Parcel.obtain();
  98.                 android.os.Parcel _reply = android.os.Parcel.obtain();
  99.                 try {
  100.                     _data.writeInterfaceToken(DESCRIPTOR);
  101.                     _data.writeString(msg);
  102.                     mRemote.transact(Stub.TRANSACTION_tell, _data, _reply, 0);
  103.                     _reply.readException();
  104.                 } finally {
  105.                     _reply.recycle();
  106.                     _data.recycle();
  107.                 }
  108.             }
  109.         }
  111.         static final int TRANSACTION_getMsg = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
  112.         static final int TRANSACTION_tell = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);
  113.     }
  115.     public java.lang.String getMsg() throws android.os.RemoteException;
  117.     public void tell(java.lang.String msg) throws android.os.RemoteException;
  118. }

代码比较长，我们依次来分析下：

  • DESCRIPTOR。Binder的唯一标示。

在Stub类的构造方法中，就是通过attachInterface方法将当前的Binder和这个唯一标示进行了绑定。

  • asInterface()。将服务端的Binder对象转换成客户端所需的接口类型对象。

这个方法是客户端调用的，在这个方法中，会通过queryLocalInterface(DESCRIPTOR)方法，传入唯一标示，来获取对应的Binder。
如果是服务端和客户端在同一个进程，那么就会返回服务端的Binder对象，也就是Stub对象本身，然后就直接调用对象的方法了。
如果在不同进程，也就是我们一般的跨进程情况，就会返回封装后的Stub.Proxy这个代理对象。

  • Proxy.getMsg/tell

接着就看看代理类里面的方法，也就是我们在客户端（Activity）中实际调用的方法。

这其中有两个比较重要的对象 :_data对象和 _reply对象，都是Parcel类型的，这里会对数据进行一个序列化操作，这样才能进行跨进程传输。

如果方法传有参数，就会把参数写到_data对象，然后调用transact方法发起远程调用请求（RPC），同时当前线程挂起，等待服务端执行完请求。

  1.     mRemote.transact(Stub.TRANSACTION_getMsg, _data, _reply, 0);

可以看到，传入了一个int类型的code——TRANSACTION_getMsg，这个code其实就是为了要确定调用的是哪个方法。

等请求结束后，当前线程继续，会从_reply对象中取出返回结果。

整个IPC流程就结束了。那服务器到底是在哪里进行任务执行的呢？继续看onTransact方法。

  • onTransact

onTransact方法就是服务端要做的事了，运行在服务端的Binder线程池中。

当客户端发起远程调用请求后，会通过系统底层封装，其实也就是内核层的Binder驱动，然后交给服务端的onTransact方法。

在该方法中，首先通过code知晓是哪个方法，然后就执行目标方法，并将序列化结果写到reply中，RPC过程结束，交给客户端处理。

  1. case TRANSACTION_getMsg: {
  2.                     data.enforceInterface(descriptor);
  3.                     java.lang.String _result = this.getMsg();
  4.                     reply.writeNoException();
  5.                     reply.writeString(_result);
  6.                     return true;
  7.                 }

最后画张图总结下AIDL整个流程：

image

Binder

经过了上述AIDL的例子，大家是不是对Binder又进一步了解了呢？

在java层面，其实Binder就是一个实现了IBinder接口的类。

真正跨进程的部分还是在客户端发起远程调用请求之后，系统底层封装好，交给服务端的时候。而这个系统底层封装，其实就是发生在Linux内核中。

而在内核中完成这个通信关键功能的还是Binder，这次不是Binder类了，而是Binder驱动。

驱动你可以理解为一种硬件接口，可以帮助操作系统来控制硬件设备。

Binder驱动被添加运行到Linux内核空间，这样，两个不同进程就可以通过访问内核空间来完成数据交换：把数据传给Binder驱动，然后处理好再交给对方进程,完成跨进程通信。

而刚才通过AIDL的例子我们可以知道，客户端在请求服务端通信的时候，并不是直接和服务端的某个对象联系，而是用到了服务端的一个代理对象，通过对这个代理对象操作，然后代理类会把方法对应的code、传输的序列化数据、需要返回的序列化数据交给底层，也就是Binder驱动。（这也解释了为什么犬夜叉看到的是阿篱的虚影，而不是真身??）

然后Binder驱动把对应的数据交给服务器端，等结果计算好之后，再由Binder驱动把数据返回给客户端。

ServiceManager

到这里，可能就会有朋友会发现有点不对劲，刚才不是说还有个ServiceManager吗？这里AIDL通信中咋没有呢，漏了啊？？

ServiceManager其实是为了管理系统服务而设置的一种机制，每个服务注册在ServiceManager中，由ServiceManager统一管理，我们可以通过服务名在ServiceManager中查询对应的服务代理，从而完成调用系统服务的功能。所以ServiceManager有点类似于DNS，可以把服务名称和具体的服务记录在案，供客户端来查找。

在我们这个AIDL的案例中，能直接获取到服务端的Service，也就直接能获取到服务端的代理类IMsgManager，所以就无需通过ServiceManager这一层来寻找服务了。

而且ServiceManager本身也运行在一个单独的进程，所以它本身也是一个服务端，客户端其实是先通过跨进程获取到ServiceManager的代理对象，然后通过ServiceManager代理对象再去找到对应的服务。

而ServiceManager就像我们刚才AIDL中的Service一样，是可以直接找到的，他的句柄永远是0，是一个“众所周知”的句柄，所以每个APP程序都可以通过binder机制在自己的进程空间中创建一个ServiceManager代理对象。
（这也解释了为什么四魂之玉在另外一个世界，其实就在另外一个进程，我们只能通过句柄值为0找到四魂之玉的碎片，其实也就是代理??）

所以通过ServiceManager查找系统服务并调用方法的过程是进行了两次跨进程通信。

APP进程——>ServiceManager进程——>系统服务进程（比如AactivityManagerService）

下面我们就拿ActivityManagerService举例看看怎么通过ServeiceManager获取到系统服务。

系统服务通信举例

熟悉APP启动流程的朋友都知道，startActivityForResult方法会转到mInstrumentation.execStartActivity方法中，而这里获取AMS服务的过程就用到了Binder机制:

  2. //mInstrumentation.execStartActivity
  3.     int result = ActivityManager.getService()
  4.                 .startActivity(whoThread, who.getBasePackageName(), intent,
  5.                         intent.resolveTypeIfNeeded(who.getContentResolver()),
  6.                         token, target != null ? target.mEmbeddedID : null,
  7.                         requestCode, 0, null, options);
  8.     checkStartActivityResult(result, intent);
  11.     public static IActivityManager getService() {
  12.         return IActivityManagerSingleton.get();
  13.     }
  15.     private static final Singleton<IActivityManager> IActivityManagerSingleton =
  16.             new Singleton<IActivityManager>() {
  17.                 @Override
  18.                 protected IActivityManager create() {
  19.                     final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
  20.                     final IActivityManager am = IActivityManager.Stub.asInterface(b);
  21.                     return am;
  22.                 }
  23.             };

主要看这一句：ServiceManager.getService(Context.ACTIVITY_SERVICE)

这不就是ServiceManager吗，按照我们之前理解的那样，这里传入了一个name——Context.ACTIVITY_SERVICE，然后就能获取到对应服务的代理类，也就是IBinder对象，这里也就是对应的AMS的代理对象——IActivityManager。

然后就可以对AMS进行一系列操作了。

这里的AMS服务其实对应的服务端，而我们调用的一方也就是APP本身的进程，就作为客户端。

剩下的问题就是，AMS是什么时候注册到ServiceManager的呢？答案在SystemServer中，之前的文章中说过，AMS的启动是在SystemServer中完成的，其实启动的同时也完成了在ServiceManager中的注册，这里贴下AMS的启动和注册服务代码，不熟悉的朋友可以翻翻SystemServer的源码或者我之前的文章。

  1.     //SystemServer.java
  2.     private void startBootstrapServices() {
  3.         //...
  5.         //启动AMS
  6.         mActivityManagerService = mSystemServiceManager.startService(
  7.                 ActivityManagerService.Lifecycle.class).getService();
  8.         mActivityManagerService.setSystemServiceManager(mSystemServiceManager);
  9.         mActivityManagerService.setInstaller(installer);
  12.         //为系统进程设置应用程序实例并启动。
  13.         mActivityManagerService.setSystemProcess();
  14.     }
  16.     public void setSystemProcess() {
  17.         try {
  18.             ServiceManager.addService(Context.ACTIVITY_SERVICE, this, /* allowIsolated= */ true,
  19.                     DUMP_FLAG_PRIORITY_CRITICAL | DUMP_FLAG_PRIORITY_NORMAL | DUMP_FLAG_PROTO);
  20.         }
  21.     }

到此，完整的Binder流程也介绍完了，再补一张Binder机制的流程图：

image

总结

所以Binder到底是什么呢？我想你心里已经有了答案，这里借用《Android开发艺术探索》书中的内容总结下，希望大家好好回味下～

  1. 直观的说，Binder是一个类，实现了IBinder接口。
  3. 从IPC（进程间通信）角度来说，Binder是Android中一种跨进程通信方式。
  5. 还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder。
  7. 从Android FrameWork角度来说，Binder是ServiceManager连接各种Manager（ActivityManager，WindowManager等等）和响应ManagerService的桥梁。
  9. 从Android应用层来说，Binder是客户端和服务端进行通信的媒介。

Android体系架构

思维导图链接

参考

《Android开发艺术探索》
Binder学习指南
Android进程间通信（IPC）机制Binder简要介绍和学习计划
Android系统的Binder机制之一——Service Manager

拜拜

有一起学习的小伙伴可以关注下?? 我的公众号——码上积木，每天剖析一个知识点，我们一起积累知识，形成完整体系架构。公众号回复111可获得面试题《思考与解答》以往期刊。

原文链接：http://www.cnblogs.com/jimuzz/p/14275621.html

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Android热门文章

  • 安卓虚拟定位实现与反作弊思路
  • Android之Activity启动流程详解（基于api28）
  • MAUI开发Android程序使PDA扫码广播消息转发至Web页面
  • android开发技巧杂谈
  • 高通CSR8675蓝牙音频芯片介绍
  • Android Studio列表用法之一：ListView图文列表显示（实例）
  • 分析Android 11.0Settings源码之主界面加载
  • 联发科MT6731 4G智能功能手机处理器芯片介绍
  • android 请求接口报错 org.apache.http.conn.HttpHostConnectException: Connection to http://192.168.1.90:9090 refused
  • GSYVideoPlayer使用记录

    • Android推荐文章

  • Jetpack Compose(7)——触摸反馈
  • 安卓开发日志采集和分析面面谈
  • Android桌面Launcher源码浅析
  • Android启动过程-万字长文(Android14)
  • Android Studio制作简单登录界面
  • FFmpeg开发笔记（九）Linux交叉编译Android的x265库
  • 在Android开发中如何使用OpenSL ES库播放解码后的pcm音频文件？
  • Android 开机流程介绍
  • 安卓端出现https请求失败的一次问题排查
  • Android 编译介绍

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号