AIDL，广播，Provider注意的一些小细节

关于使用AIDL需要注意的几个点

• 服务端的进程可能异常停止，此时客户端拿到的binder是失效的，所以要为拿到的binder设置监听，即linkToDeath(实现接口的匿名内部类)；然后在接口实例的方法里面调用unlinkToDeath()，之后可以进行服务重绑定
• 当为服务端注册客户端监听时，客户端使用的Listener接口应该是定义为AIDL接口，普通接口不能跨进程，服务端集合使用RemoteCallBackList
• 当客户端调用服务端的方法时，服务端的调用线程阻塞，注意在非UI线程中处理，同理，服务端通过listener调用客户端的更新方法时,也会阻塞，服务端也应该在非UI线程调用
• 通常，使用AIDL绑定服务时，由于服务是跨进程，所以是bindService而不是startService，绑定的服务，服务的生命周期方法为onCreate,onBind,onUnBind,onDestroy，生命周期依赖于发起绑定的context，而startService需要调用stopService，否则除非进程停止，服务不会死亡
• AIDL通信的原理大抵是，如果非跨进程，asInterface返回的直接是binder实例本身(即我们实现的抽象类实例)；如果跨进程，则是返回内部代理类实例proxy，然后调用相应方式时，其实是先调用onTransact完成一些初始化，然后完成对象序列化写入内存，再通过调用transact反序列化还原对象，然后再调用最终的方法完成写入，如果是读取，则过程是transact先读写序列化写入，onTransact里面执行完transact后再反序列化还原，再返回消息

顺便提一下广播以及非UI线程不能更新UI的问题

• 在许多编程中，UI更新都是单线程的，好像多线程会有潜在死锁的风险，其实也不是很清楚。但是想象一下，假设多线程可以更新UI，屏幕一定会花，那么就必须进行同步，并且高并发时候大量同步性能肯定会下降很多
• 至于广播为什么不建议onRecive开启线程，原因是广播“朝生夕灭”，一旦广播是个独立的进程，那么广播执行结束进程死亡，所拥有的子线程的会死亡即使没有执行完毕。但如果广播和主线程一个进程，其实要让他开启子线程也不是不可

关于Provider的grantUriPermission属性

• 使用Provider可以指定访问权限为permission（全局读写），writePerission（只写），readPermission（只读），访问该provider时原因必须使用use-permission申请权限，如果有应用没有申请，想访问怎么办呢？可以在provider使用grantUriPermission=true，默认false;表示允许临时赋予访问者相应的权限，通过Intent.setFlag，在用Intent召唤一个访问本provider的应用时使用，赋予权限