最近我在编写一个 Android 上的驱动程序，这个驱动程序的某些部分用到了 Unix domain socket，守护进程和客户端进程使用 C/S 模式进行通信。在调试程序的时候发现一个非常奇怪的问题：如果客户端开启若干个线程连上 socket，send/recv 若干消息之后立即退出进程，从日志上看，server 端有 10% 左右的概率无法正常回收资源。
一开始我以为是我自己程序写的有问题，毕竟这个驱动是使用纯 C 语言实现的，并且用到了 epoll 的 ET 模式，这种非阻塞的编程模型的确有许多微妙的地方，一不小心就容易出错。我排查了很久都没有发现问题所在，更有趣的是，虽然看起来我的程序无法回收资源，但是在压力测试下他也能正常工作，完全没有资源泄漏的迹象；实在没办法，我就祭出了大杀器 strace。不看不知道，一看就好笑：strace 显示，我的程序逻辑是正常的，它正确地调用了相关的资源释放函数！但是，logcat 中没有相关的日志，在客户端退出之后 server 端的日志就戛然而止了。看起来，好像不是我程序的问题，而是系统的 logcat 丢失了日志？
一直以来，App 进程保活都是各大厂商，特别是头部应用开发商永恒的追求。毕竟App 进程死了，就什么也干不了了；一旦 App 进程死亡，那就再也无法在用户的手机上开展任何业务，所有的商业模型在用户侧都没有立足之地了。
早期的 Android 系统不完善，导致 App 侧有很多空子可以钻，因此它们有着有着各种各样的姿势进行保活。譬如说在 Android 5.0 以前，App 内部通过 native 方式 fork 出来的进程是不受系统管控的，系统在杀 App 进程的时候，只会去杀 App 启动的 Java 进程；因此诞生了一大批“毒瘤”，他们通过 fork native 进程，在 App 的 Java 进程被杀死的时候通过 am命令拉起自己从而实现永生。那时候的 Android 可谓是魑魅横行，群魔乱舞；系统根本管不住应用，因此长期以来被人诟病耗电、卡顿。同时，系统的软弱导致了 Xposed 框架、阻止运行、绿色守护、黑域、冰箱等一系列管制系统后台进程的框架和 App 出现。
不过，随着 Android 系统的发展，这一切都在往好的方向演变。
去年发布的 Android P上引入了针对非公开API的限制，对开发者来说，这绝对是有史以来最重大的变化之一。前天 Google 发布了 Android Q 的 Beta 版，越来越多的 API 被加入了黑名单，而且 Google 要求下半年 APP 必须 target 28，这意味着现在的深灰名单也会生效；可以预见，在不久的将来，我们要跟大量的 API 说再见了。
去年我给出了一种绕过Android P对非SDK接口限制的简单方法，经验证，这办法在 Android Q 的 Beta 版上依然能正常使用。虽然这个方法需要进行内存搜索，理论上有可能失败，但实际上它曾在 VirtualXposed 和 太极 中得到了较为广泛的验证，从未收到过由于反射失败而导致问题的反馈。而且据我所知，有若干用户量不少的 APP 在线上使用了我提供的 FreeReflection 库，想来应该也是没有问题的吧。
不过今天，我打算给出另外一种绕过限制的办法。这个办法目前来说是最优方案，我个人使用了一个多月，不存在任何问题。
从我写下 Android插件化原理解析 系列第一篇文章至今，已经过去了两年时间。这期间，插件化技术也得到了长足的发展；与此同时，React Native，PWA，App Bundle，以及最近的Flutter也如火如荼。由于实现插件化需要太多的黑科技，它给项目的维护成本和稳定性增加了诸多不确定性；我个人认为，2017年手淘Atlas插件化项目的开源标志着插件化的落幕，2018年Android 9.0上私有API的限制几乎称得上是盖棺定论了——曾经波澜壮阔的插件化进程必将要退出历史主流。如今的插件化技术朝两个方向发展：其一，插件化的工程特性：模块化/解耦被抽离，逐渐演进为稳定、务实的的组件化方案；其二，插件化的黑科技特性被进一步发掘，inline hook/method hook大行其道，走向双开，虚拟环境等等。
虽然插件化终将落幕，但是它背后的技术原理包罗万象，值得每一个希望深入Android的小伙伴们学习。
很遗憾曾经的系列文章没有写完，现在已经没机会甚至可以说不可能去把它完结了；不过幸运的是，我的良师益友包老师（我习惯称呼他为包哥）写了一本关于插件化的书——《Android插件化开发指南》，书中讲述了过去数年浩浩荡荡的插件化历程以及插件技术的方方面面；有兴趣的小伙伴可以买一本看看。
众所周知，Android P 引入了针对非 SDK 接口（俗称为隐藏API）的使用限制。这是继 Android N上针对 NDK 中私有库的链接限制之后的又一次重大调整。从今以后，不论是native层的NDK还是 Java层的SDK，我们只能使用Google提供的、公开的标准接口。这对开发者以及用户乃至整个Android生态，当然是一件好事。但这也同时意味着Android上的各种黑科技有可能会逐渐走向消亡。
作为一个有追求的开发者，我们既要尊重并遵守规则，也要有能力在必要的时候突破规则的束缚，带着镣铐跳舞。恰好最近有人反馈 VirtualXposed 在 Android P上无法运行，那么今天就来探讨一下，如何突破Android P上针对非SDK接口调用的限制。
Xposed是Android系统上久负盛名的一个框架，它给了普通用户任意 DIY 系统的能力；比如典型的微信防撤回、自动抢红包、修改主题字体，以及模拟位置等等等等。不过，使用Xposed的前提条件之一就是需要Root。随着Android系统的演进，这一条件达成越来越难了；那么，能不能不用Root就可以享用Xposed的功能呢？
我们想一下，Xposed为什么需要Root？从现在的实现来看，因为Xposed需要修改系统文件，而这些文件只有root权限才能修改；但是这只是当前实现的特性（修改系统分区文件），而非根本原因。Xposed要实现的最终目的是在任意App进程启动之前能任意加载 特定Xposed模块 的代码；这些特定的Xposed模块中能在App进程启动之前有机会执行特定代码，从而控制任意进程的行为。归根结底，Xposed需要控制别的进程，而没有高级权限（Root），越俎代庖是不行的。
有没有别的实现方式？
两年前阿里开源了Dexposed 项目，它能够在Dalvik上无侵入地实现运行时方法拦截，正如其介绍「enable ‘god’ mode for single android application」所言，能在非root情况下掌控自己进程空间内的任意Java方法调用，给我们带来了很大的想象空间。比如能实现运行时AOP，在线热修复，做性能分析工具（拦截线程、IO等资源的创建和销毁）等等。然而，随着ART取代Dalvik成为Android的运行时，一切都似乎戛然而止。
今天，我在ART上重新实现了Dexposed，在它能支持的平台（Android 5.0 ~ 7.1 Thumb2/ARM64)上，有着与Dexposed完全相同的能力和API；项目地址在这里 epic，感兴趣的可以先试用下:) 然后我们聊一聊ART上运行时Method AOP的故事。
Android上的热修复框架 AndFix 想必已经是耳熟能详，它的原理实际上很简单：方法替换——Java层的每一个方法在虚拟机实现里面都对应着一个ArtMethod的结构体，只要把原方法的结构体内容替换成新的结构体的内容，在调用原方法的时候，真正执行的指令会是新方法的指令；这样就能实现热修复，详细代码见 AndFix。
为什么可以这么做呢？那得从 Android 虚拟机的方法调用过程说起。作为一个系列的开篇，本文不打算展开讲虚拟机原理等内容，首先给大家一道开胃菜；后续我们再深入探索ART。
众所周知，AndFix是一种 native 的hotfix方案，它的替换过程是用 c 在 native层完成的，但其实，我们也可以用纯Java实现它！而且，代码还非常精简，且看——
半年前写了一篇文章，介绍 如何调试Android Framework，但是只提到了Framework中Java代码的调试办法，但实际上有很多代码都是用C++实现的；无奈当时并并没有趁手的native调试工具，无法做到像Java调试那样简单直观（gdb+eclipse/ida之流虽然可以但是不完美），于是就搁置下了。
Android Studio 2.2版本带来了全新的对Android Native代码的开发以及调试支持，另外LLDB的Android调试插件也日渐成熟，我终于可以把这篇文章继续下去了！本文将带来Android Framework中native代码的调试方法。
在正式介绍如何调试之前，必须先说明一些基本的概念。调试器在调试一个可执行文件的时候，必须知道一些调试信息才能进行调试，这个调试信息可多可少（也可以没有）。最直观的比如行号信息，如果调试器知道行号信息，那么在进行调试的时候就能知道当前执行到了源代码的哪一行，如果调试器还知道对应代码的源文件在哪，那么现代IDE的调试器一般就能顺着源码带你飞了，这就是所谓的源码调试。相反，如果没有行号和源码信息，那么只能进行更低级别的调试了，调试器只能告诉你一些寄存器的值；而当前运行的代码也只是PC寄存器所指向的二进制数据，这些数据要么是虚拟机指令，要么是汇编指令；这就是所谓的无源码调试。显然无源码调试相比源码级别的调试要麻烦的多；接下来将围绕这两个方面分别介绍。
有史以来，Android源码编译环境的搭建始终是一件麻烦事儿。网上有数不清的文章介绍如何编译Android源代码，但是他们要么方法复杂、步骤太多；要么自称解决了一些编译问题（需要修改头文件，系统配置等），让人对其可信度产生质疑。有的童鞋硬着头皮照做了，但是由于伟大的GFW，大部分都死在了第一步——repo脚本都下载不下来，就算下载过了过不了gerrit那一关。另外，就算你具备科学上网的能力，下载时间又成为了拦路虎；普通的VPN通常需要下载七八个小时，简直就是痛不欲生。久而久之，很多人对下载编译Android源码望而却步。
今天，我给大家提供一个极其简单、稳定的方案，来解决Android源码的下载编译问题。
首先，下载问题可以通过镜像解决；清华镜像 和 科大镜像 都是非常不错的选择，正常情况下一到两个小时即可下载完一个Android源码分支。
然后就是编译环境问题。由于Android源码庞大，依赖复杂；一旦使用的编译工具链有细微的不同就可能引发编译失败。官方文档 推荐使用Ubuntu 14.04进行编译。如果我们用Windows或者Mac系统，传统方式是使用虚拟机；但是在今天，我们完全可以使用 Docker 替代！！借助Docker，我们可以不用担心编译环境问题；不论我们的开发机是什么系统，可以使用Docker创建Ubuntu Image，并且直接在这个Ubuntu系统环境中创建编译所需要的工具链（JDK，ubuntu系统的依赖库等等）；而且，Docker运行的Ubuntu的系统开销比虚拟机低得多，这样下载以及编译速度就有了质的提升。更重要的是，这个环境可以作为一个Image打包发布！这样，你在不同的开发机，还有你与你的同事之间有了同一套编译环境，这会省去很多不必要的麻烦。关于Docker的更多内容，见 Docker官网