一开始对于靠着readme就混了几百个star 我是嫌弃的.
在阅读他们开源的东西的时候,确实是我读过开源项目里面算是友好的, 至少注释是这样子的. 尤其是有阿里atlas 这种反面例子做对比, 这里不得不吐槽atlas 代码中处处体现了历史变更的痕迹, 甚至是一些过时的注释. replugin 在注释方面确实做的不错, 在关键节点加了很多注释
在android 支持版本都在api 14起跳的今天, RePlugin 还在兼容到了api 9.
RePlugin 上也有历史的痕迹, 比如里面的v5插件这种东西,去掉会更好.
技术上
个人认为RePlugin 亮点其实是在多进程的支持上,一个hook 的新思路上,以及整体使用的反射的地方也是比较少的.
在一片使用hook系统api的方式,RePlugin确实走出了小清新风格.
但是插件支持模式有点单一, 就是你的插件没法成为别人插件的基础.. 因为每个插件的资源是不分区的. 一个插件就像一座孤岛
-------分割线----
这里简单说一下四大组件插件化的实现原理
Activity 在启动的时候替换成了合适的占坑的activity , ,然后ClassLoader loadClass 的时候根据占坑Activity 到真正Activity 的映射关系,输入占坑Activity,返回真正Activity 的类,避免了需要hook.
BroadcastReceiver 是把所有静态注册动态注册在一个代理Receiver, 收到广播在代理Receiver 进行分发.
Service 实现逻辑是这里其实是是直接在UI线程调用了service 的相关生命周期的方法.同时启动一个service来提高service所在进程优先级.
ContentProvider 这里使用的是代理ccontentprovide,在对应的生命周期使用反射将对应类生成出来. 然后调用对应的声明周期方法.
为了做到开发者无感知, 他们使用了gradle 插件来修改class 字节. 比如把Activity 改成PluginActivity, 拦截Service和ContentProvider 调用点.
