最近在搞低端机上的性能优化，碰上一堆头疼的问题。有一个特别坑的玩意，那就是谷歌自己写的一套绝世“好代码“，用户手机上经常用到的负一屏的基础架构。本来我两年前开始搞这玩意的时候觉得没啥，滚动同步 UI 嘛，而且还要跨进程，那看起来 binder 通信不就是不二之选：桌面滚动到边缘触发 EdgeEffect，EdgeEffect 来通过 binder 通知负一屏滚动了多少，然后负一屏那边在回调真正的滚动进度回桌面。这一套行云流水的操作下来可以说是没什么问题吧，至少其他厂家也在用，谷歌自己也在用。
之前由于业务上需要，需要按照不同的配置项给同一个项目打包出两个不同的产物（有点类似于渠道包，不过比渠道包复杂得多）。
假如有一个项目，你需要从源码中获取某个标识符，来确定打包的渠道，你需要在源码编译时候去决定打包的内容。当然，具体场景肯定没这么简单，是包含了大量具体的复杂逻辑执行的。于是你创建一个项目，包含了如下的代码:
通过查看编译后产生的Java文件，观察其结构
构造后的AIDL类产生了一个同名接口，这个接口包含了AIDL内声明的所有方法，并且继承了android.os.IInterface。接口包含了两个静态类：
Default类默认实现了AIDL接口以及IInterface的asBinder()方法，但都为空实现。
增加了运行时的权限申请
强制执行 StrictMode API，Intent 的 Uri 中 scheme 不能为 file 类型。如果要共享文件，需要使用 content:// 类型的 data。如果要共享文件，则使用 FileProvider。