Android Broadcast 分析——超时或异常

上一篇（处理篇）最后留了一个问题：串行广播需要一个接着一个执行，如果其中某一个接收器处理的时候挂掉了，或者耗时很长还没处理完，是不是后面的接收器就无法处理了呢。我们在这里看一下 android 是不是已经想到这些了。我们先照例把相关代码位置啰嗦一下（4.2.2）： 12345#

Android Binder 分析——内存管理

android 为了高效的 IPC 通信做了很多工作，内存管理就属于其中之一。传统的 IPC 传递数据，至少需要2次拷贝，一次为进程1到内核，一次为内核到进程2，但是得益 android binder 的内存管理，数据拷贝只有1次，就从这里速度比传统的要快1倍。这里慢慢分析。还是

前面 binder 说了那多，但是有一个关键的一点前面忽略掉了，就是 binder 对象是传递给另外一个进程使用的，然后还引伸出一个问题，Proc A 是怎么通过 binder 接口找到 Proc B 进行 IPC 调用的。那这篇主要就是分析这些，照例先把源代码位置啰嗦一下（4

上一篇把 SS 传递 binder 对象说了， SS 传递是要依靠 SM 的。但是普通应用的服务是没权向 SM 注册的，就是说普通应用获取普通服务的接口不能像 SS 那样，通过 SM 的接口去取。这篇就来讲讲普通应用中 binder 对象的传递。那这篇主要就是分析这些，照例先把

前面普通服务篇那里说到 ActivityManager（AM）里锁的问题，其实不光 AM，WindowManager（WM）、PackageMananger（PM）中基本上很多对外的业务函数里面都是加锁的，所以这些 SS 里面有会有带 Locked 结尾的函数（这些函数都是在锁

前面说了 binder 的原理，和 parcel，当时也说了实现 IBinder 接口（Bp 端、Bn 端）代码都非常的机械，人工写的话，不仅浪费时间，而且很有可能会出错（复制、粘贴后忘记改某个地方）。所以 android 弄了代码自动生成的东西。然后还美名其曰 XX 语言——

binder 是跨进程间的通信，那就是说有本地和远程之说，通过前面几篇也知道 Bp 需要发请求到 Bn 端。但是写过网络通信程序的都知道，远程不一定“靠谱”，就是说可能某些时候远程服务器挂了。所以一般网络通信程序会弄一个心跳的机制，就是每隔一段时间向服务发一些东西，看服务是否还有

gradle 目前 android studio 采用的全新打包方式，其实也算不上全新了，因为已经改用 2、3 年了吧。相对 ant 来说，gradle 在打不同渠道包，和不同渠道包的定制上比 ant 要优秀不少。改用 gradle 也快一年了，这里稍微记录一下用法和一些坑。简

我个人是觉得 git 比 svn 好用得多的 … 但是公司版本管理用的是 svn，那也得用咯。常用命令 svn co git checkout … 可以接完整仓库的 url，例如： https://svn.yy.com/repos/src/dwmobile/kktest 。

Material Design 是 google 大力推广的 android app 设计模式。我个人还是挺喜欢的，因为界面比较简洁，动画效果也不错。但是要从头实现这些效果也不是一件容易的事，所以为了拉拢开发者，google 推出了一系列 support library： sup