- 被“in”标记的参数，就是接收实际数据的参数，这个跟我们普通参数传递一样的含义。在AIDL中，“out” 指定了一个仅用于输出的参数，换而言之，这个参数不关心调用方传递了什么数据过来，但是这个参数的值可以在方法被调用后填充（无论调用方传递了什么值过来，在方法执行的时候，这个参数的初始值总是空的），这就是“out”的含义，仅用于输出。
- 而“inout”显然就是“in”和“out”的合体了，输入和输出的参数。区分“in”、“out”有什么用？这是非常重要的，因为每个参数的内容必须编组（序列化，传输，接收和反序列化）。in/out标签允许Binder跳过编组步骤以获得更好的性能。
上述的MessageModel为消息的实体类，该类在AIDL中传递，实现了Parcelable序列化接口，代码如下：
手动实现Parcelable接口比较麻烦，安利一款AS自动生成插件android-parcelable-intellij-plugin创建完MessageModel这个实体类，别忘了还有一件事要做：”在AIDL中传递的对象，需要在类文件相同路径下，创建同名、但是后缀为.aidl的文件，并在文件中使用parcelable关键字声明这个类“。代码如下：
对于没有接触过aidl的同学，光说就能让人懵逼，来看看此时的项目结构压压惊：
我们刚刚新增的3个文件：
- MessageSender.aidl -> 定义了发送消息的方法，会自动生成名为MessageSender.Stub的Binder类，在服务端实现，返回给客户端调用
- MessageModel.java -> 消息实体类，由客户端传递到服务端，实现了Parcelable序列化
- MessageModel.aidl -> 声明了MessageModel可在AIDL中传递，放在跟MessageModel.java相同的包路径下
OK，相信此时懵逼已解除~
2.5 在服务端创建MessageSender.aidl这个AIDL接口自动生成的Binder对象，并返回给客户端调用，服务端MessageService代码如下：
MessageSender.Stub是Android Studio根据我们MessageSender.aidl文件自动生成的Binder对象（至于是怎样生成的，下文会有答案），我们需要把这个Binder对象返回给客户端。
2.6 客户端拿到Binder对象后调用远程方法
调用步骤如下：
- 在客户端的onServiceConnected方法中，拿到服务端返回的Binder对象；
- 使用MessageSender.Stub.asInterface方法，取得MessageSender.aidl对应的操作接口；
- 取得MessageSender对象后，像普通接口一样调用方法即可。
此时客户端代码如下：
在客户端中我们调用了MessageSender的sendMessage方法，向服务端发送了一条消息，并把生成的MessageModel对象作为参数传递到了服务端，最终服务端打印的结果如下：
这里有两点要说：
- 服务端已经接收到客户端发送过来的消息，并正确打印；
- 服务端和客户端区分两个进程，PID不一样，进程名也不一样；
到这里，我们已经完成了最基本的使用AIDL进行跨进程方法调用，也是Step.0的整个细化过程，可以再回顾一下Step.0，既然已经学会使用了，接下来…全剧终。。。
如果写到这里全剧终，那跟咸鱼有什么区别…
知其然，知其所以然
我们通过上述的调用流程，看看从客户端到服务端，都经历了些什么事，看看Binder的上层是如何工作的，至于Binder的底层，这是一个非常复杂的话题，本文不深究。（如果看到这里你又想问什么是Binder的话，请手动倒带往上看…）
我们先来回顾一下从客户端发起的调用流程：
- MessageSender messageSender = MessageSender.Stub.asInterface(service);
- messageSender.sendMessage(messageModel);
抛开其它无关代码，客户端调跨进程方法就这两个步骤，而这两个步骤都封装在 MessageSender.aidl 最终生成的 MessageSender.java 源码（具体路径为：build目录下某个子目录，自己找，不爽你来打我啊 ）
请看下方代码和注释，前方高能预警…
只看代码的话，可能会有点懵逼，相信结合代码再看下方的流程图会更好理解：
从客户端的sendMessage开始，整个AIDL的调用过程如上图所示，asInterface方法，将会判断onBind方法返回的Binder是否存处于同一进程，在同一进程中，则进行常规的方法调用，若处于不同进程，整个数据传递的过程则需要通过Binder底层去进行编组（序列化，传输，接收和反序列化），得到最终的数据后再进行常规的方法调用。
敲黑板：对象跨进程传输的本质就是 序列化，传输，接收和反序列化 这样一个过程，这也是为什么跨进程传输的对象必须实现Parcelable接口
跨进程的回调接口
在上面我们已经实现了从客户端发送消息到跨进程服务端的功能，接下来我们还需要将服务端接收到的远程服务器消息，传递到客户端。有同学估计会说：“这不就是一个回调接口的事情嘛”，设置回调接口思路是对的，但是在这里使用的回调接口有点不一样，在AIDL中传递的接口，不能是普通的接口，只能是AIDL接口，所以我们需要新建一个AIDL接口传到服务端，作为回调接口。
新建消息收取的AIDL接口MessageReceiver.aidl：
接下来我们把回调接口注册到服务端去，修改我们的MessageSender.aidl:
以上就是我们最终修改好的aidl接口，接下来我们需要做出对应的变更：
- 在服务端中增加MessageSender的注册和反注册接口的方法；
- 在客户端中实现MessageReceiver接口，并通过MessageSender注册到服务端。
客户端变更，修改MainActivity：
客户端主要有3个变更：
- 增加了messageReceiver对象，用于监听服务端的消息通知；
- onServiceConnected方法中，把messageReceiver注册到Service中去；
- onDestroy时候解除messageReceiver的注册。
下面对服务端MessageServie进行变更：
服务端主要变更：
- MessageSender.Stub实现了注册和反注册回调接口的方法；
- 增加了RemoteCallbackList来管理AIDL远程接口；
- FakeTCPTask模拟了长连接通知客户端有新消息到达。（这里的长连接可以是XMPP，Mina，Mars，Netty等，这里弄个假的意思意思，有时间的话咱开个帖子聊聊XMPP）
-
这里还有一个需要讲一下的，就是RemoteCallbackList，为什么要用RemoteCallbackList，普通ArrayList不行吗？当然不行，不然干嘛又整一个RemoteCallbackList ，registerReceiveListener 和 unregisterReceiveListener在客户端传输过来的对象，经过Binder处理，在服务端接收到的时候其实是一个新的对象，这样导致在 unregisterReceiveListener 的时候，普通的ArrayList是无法找到在 registerReceiveListener 时候添加到List的那个对象的，但是它们底层使用的Binder对象是同一个，RemoteCallbackList利用这个特性做到了可以找到同一个对象，这样我们就可以顺利反注册客户端传递过来的接口对象了。
-
RemoteCallbackList在客户端进程终止后，它能自动移除客户端所注册的listener，它内部还实现了线程同步，所以我们在注册和反注册都不需要考虑线程同步，的确是个666的类。（至于使用ArrayList的幺蛾子现象，大家可以自己试试，篇幅问题，这里就不演示了）
到此，服务端通知客户端相关的代码也写完了，运行结果无非就是正确打印就不贴图了，可以自己Run一下，打印的时候注意去选择不同的进程，不然瞪坏屏幕也没有日志。
DeathRecipient
你以为这样就完了？too young too simple…
不知道你有没有感觉到，两个进程交互总是觉得缺乏那么一点安全感…比如说服务端进程Crash了，而客户端进程想要调用服务端方法，这样就调用不到了。此时我们可以给Binder设置一个DeathRecipient对象，当Binder意外挂了的时候，我们可以在DeathRecipient接口的回调方法中收到通知，并作出相应的操作，比如重连服务等等。
DeathRecipient的使用如下：
- 声明DeathRecipient对象，实现其binderDied方法，当binder死亡时，会回调binderDied方法；
- 给Binder对象设置DeathRecipient对象。
在客户端MainActivity声明DeathRecipient：
Binder中两个重要方法：
- linkToDeath -> 设置死亡代理 DeathRecipient 对象；
- unlinkToDeath -> Binder死亡的情况下，解除该代理。
此外，Binder中的isBinderAlive也可以判断Binder是否死亡
权限验证
就算是公交车，上车也得嘀卡对不，如果希望我们的服务进程不想像公交车一样谁想上就上，那么我们可以加入权限验证。
介绍两种常用验证方法：
- 在服务端的onBind中校验自定义permission，如果通过了我们的校验，正常返回Binder对象，校验不通过返回null，返回null的情况下客户端无法绑定到我们的服务；
- 在服务端的onTransact方法校验客户端包名，不通过校验直接return false，校验通过执行正常的流程。
自定义permission，在Androidmanifest.xml中增加自定义的权限：
服务端检查权限的方法：
根据不同进程，做不同的初始化工作
相信前一两年很多朋友还在使用Android-Universal-Image-Loader来加载图片，它是需要在Application类进行初始化的。打个比如，我们用它来加载图片，而且还有一个图片选择进程，那么我们希望分配更多的缓存给图片选择进程，又或者是一些其他的初始化工作，不需要在图片选择进程初始化怎么办？
这里提供一个简单粗暴的方法，博主也是这么干的…直接拿到进程名判断，作出相应操作即可：
每个进程创建，都会调用Application的onCreate方法，这是一个需要注意的地方，我们也可以根据当前进程的pid，拿到当前进程的名字去做判断，然后做一些我们需要的逻辑，我们这个例子，拿到的两个进程名分别是：
- **客户端进程：**com.example.aidl
- 服务端进程：com.example.aidl:remote
总结
- 多进程app可以在系统中申请多份内存，但应合理使用，建议把一些高消耗但不常用的模块放到独立的进程，不使用的进程可及时手动关闭；
- 实现多进程的方式有多种：四大组件传递Bundle、Messenger、AIDL等，选择适合自己的使用场景；
- Android中实现多进程通讯，建议使用系统提供的Binder类，该类已经实现了多进程通讯而不需要我们做底层工作；
- 多进程应用，Application将会被创建多次；
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
重要知识点
下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。
高级进阶篇——高级UI，自定义View（部分展示）
UI这块知识是现今使用者最多的。当年火爆一时的Android入门培训，学会这小块知识就能随便找到不错的工作了。不过很显然现在远远不够了，拒绝无休止的CV,亲自去项目实战，读源码，研究原理吧！
- 面试题部分合集
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
S1PWdT-1712759673821)]
- 面试题部分合集
[外链图片转存中…(img-LXNb0NB1-1712759673821)]
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-wG99DQh8-1712759673822)]
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
