如何看待阿里开源的dexposed框架?

从AOP的角度来看，这是效率的大幅度提升。首先它不需要任何编译器的插桩或者代码改写，对正常运行不引入任何性能开销。这是AspectJ之类的框架没法比拟的优势。其次，对所改写方法的性能开销也极低（微秒级），基本可以忽略不计。这就决定了它是一个不可多得的AOP解决方案，虽然仅限Android下，而且有些限制和兼容性制约。

从工程的角度来看，热补丁仅仅是牛刀小试，它真正的威力在于『线上调试』。做App开发的同学一般会羡慕服务端开发的同学，遇到问题之后有充足的日志和各种监控数据方便排查问题，最不济也可以临时加调试代码；而App出点啥问题只要没有『先见之明』的埋点，基本上就是两眼一抹黑。这边PM和老大在背后咆哮，你坐在电脑前面都不知道从哪下手。但是基于Dexposed实现的线上调试可以实现真正意义上的远程调试，点对面甚至是点对点的。根本不用担心没有事先埋点，需要加调试、加日志什么的，随时部署，分分钟后就可以看到需要的调试信息，无论是方法参数值、返回值，抛出的异常，还是调用路径，十万八千里外的凶案现场全部了如指掌，直如身临其境。找到问题之后，马上打个补丁，再远程调试看一下是不是圆满解决。这个用途在工程上的意义是真正跨越性的。

从技术的角度来看，基于Xposed原理实现的AOP不仅可以hook自己的代码，还可以hook同进程的Android SDK代码，这也就可以让我们有能力在App中填上Google自己挖的坑，避免用一些非常痛苦的workaround，对于一些复杂的安全漏洞尤其有效。

最后，从开源的角度来看，Dexposed本身从名字而言就是对Xposed的致敬，我们也通过开源Dexposed反哺社区，与整个社区共同分享和推进我们的成果。（即便Apache协议本身并没有连带开源的约束）

BTW，搞不懂Dexposed与Xposed关键性差别，也不懂开源社区文化和游戏规则就说抄袭的同学，可以去洗洗睡了，我都懒得反驳了。

利益相关：Dexposed开源项目曾经的主导者。

手淘的热部署就是依赖xposed_bridge

这没有什么抄袭一说，轮子拿来用就好。

xposed框架之所以需要root，

是因为它要劫持zygote进程来hook系统方法；

手淘的热部署只需要劫持自己程序(classLoader)内的方法，即xposed在程序内的去root化实现，通过hook来改写某个方法。不过这个不支持art，有新的解决方案，暂时不细说。