- 开启进程的方式：使用 android:process 。进程名以":"开头的进程属于当前应用的私有进程。
- 多进程会照成几个方面的问题：静态成员和单例模式完全失效、线程同步机制完全失效、SharedPreferences的可靠性下降、Application会多次创建。
- Serializable的serialVersionUID的作用是反序列化时比对类版本用的，如果序列化的文件中的serialVersionUID和当前类的serialVersionUID不一致，说明当前了和序列化时的类发生了某些变化，反序列化时就会报错。
- onTransact方法运行在服务端中的Binder线程池中，如果此方法返回false，那么客户端的请求会失败，因此可以利用这个特性来做权限验证。
- Binder的工作机制，客户端发起远程请求时，当前线程会被挂起直至服务器进程返回数据。
- 服务端的Binder方法运行在Binder的线程池中，所以Binder方法不管是否耗时都应该采用同步的方式实现。
- Android系统对SharedPreferences的读/写有一定的缓存策略，在内存中会有一份SharedPreferences文件的缓存，因此在多线程模式下，系统对它的读/写就变得不可靠。
- AIDL的方式可以支持在服务端中调用客户端的回调函数和客户端通信：提供一个AIDL接口，在接口中定义回调函数，每个用户都需要实现这个接口。在服务端中使用RemoteCallbackList的register或unregister接收客户端的回调对象。遍历RemoteCallbackList时必须配对使用beginBroadcast和finishBroadcast。
- 客户端的listener方法运行在客户端的Binder线程池中。因此服务端在调用客户端的listener方法要注意不能在UI线程中调用。
- 客户端的onServiceConnected和onServiceDisconnected方法运行在UI线程中。
- Binder的linkToDeath和unlinkToDeath给Binder设置死亡代理，当Binder死亡的时候可以收到通知。onServiceDisconnected方法也可以感知Binder的意外死亡。binderDied运行在客户端的Binder线程池中，onServiceDisconnected运行在客户端的UI线程中。
- AIDL的权限验证：在onBind或onTransact方法中验证。验证方法可以用permission、包名。
- 当有多个业务模块的AIDL文件时，服务端可以只提供一个Service，暴露queryBinder接口根据业务模块返回相应的Binder对象给客户端。使用的是Binder连接池，AIDL 文件是：
interface IBinderPool {
IBinder queryBinder(int binderCode)
}
-
Messenger适用于低并发的一对多即时通讯，无RPC需求，或者无须返回结果的RPC需求。
整个Binder模型的原理步骤 & 源码分析
网友评论