Tinker 1.9.13.1：微信开源的 Android 热修复框架的新里程碑

在现今移动应用开发领域，Android以其开源性和广泛的设备兼容性，占据了重要的市场地位。然而，随着应用功能的日益复杂，如何在不重新安装应用的情况下修复已发布应用中的错误，成为了开发者们面临的一大挑战。为此，微信开源了Tinker这一Android热修复框架，旨在帮助开发者更高效地解决这一问题。

最近，Tinker发布了其1.9.13.1版本，此次更新带来了多项重要改进和优化，为开发者提供了更为稳定、高效的热修复体验。

首先，Tinker 1.9.13.1将Patch Apply的重试次数增加到20次。这意味着在patch加载失败时，系统将自动尝试重新加载patch，最多可达20次。这一改进显著提高了patch加载的成功率，降低了因网络波动等原因导致的加载失败的可能性。

其次，新版本对Tinker运行时库对support-annotations的依赖进行了优化，将其从runtimeClasspath改为compileOnly。这一改动避免了在接入Tinker时引入整个appcompat包，有效减小了应用的体积，同时提高了应用的运行效率。

此外，Tinker 1.9.13.1还修复了加固模式下patch无法加载成功的问题。加固技术是一种常用的应用保护手段，可以有效防止应用被反编译和篡改。然而，在某些加固模式下，patch的加载可能会受到影响。此次更新解决了这一问题，使得加固模式下的应用也能顺利加载和使用patch。

同时，针对Android P（即Android 9）系统下patch加载失败的问题，Tinker 1.9.13.1也进行了修复。Android P引入了一系列新的系统特性和安全机制，这对热修复框架的兼容性提出了更高的要求。通过此次更新，Tinker成功实现了在Android P系统下的稳定运行。

除此之外，新版本还修复了后台进程在patch加载时偶尔发生的ANR（Application Not Responding）问题。ANR问题是指应用在特定时间内无法响应系统的输入事件，这可能导致用户体验的下降。通过改进主进程对patch.info的更新方式，Tinker 1.9.13.1有效降低了ANR问题的发生概率。

另外，针对P中因apache类被内联导致的crash问题，Tinker 1.9.13.1也进行了修复。这一问题通常是由于编译器优化导致的类内联引起的，通过调整编译器的设置或修改代码结构，可以解决这个问题。

最后，Tinker 1.9.13.1还引入了shadowJar插件，彻底解决了生成的Tinker CLI工具报ClassNotFound的问题。这一改进使得开发者在使用Tinker CLI工具时，不再需要担心找不到类的问题，提高了开发效率和便捷性。

除了以上改进和优化之外，Tinker 1.9.13.1还修复了主dex中的类数量莫名变大的问题。经过调查，发现这是由于在minSDK=21时，AGP（Android Gradle Plugin）启用了native-multidex导致的。这一改动使得gradle中配置的maindex list参数被忽略，从而导致了类数量的增加。通过调整配置或升级AGP版本，可以解决这个问题。

综上所述，Tinker 1.9.13.1的发布为Android热修复框架带来了新的里程碑。通过增加Patch Apply的重试次数、优化运行时库依赖、修复加固模式和Android P下的加载问题、解决后台进程ANR问题、修复因apache类被内联导致的crash以及引入shadowJar插件等改进和优化措施，Tinker为开发者提供了更为稳定、高效的热修复体验。相信在未来的开发中，Tinker将继续发挥其重要作用，帮助开发者更好地应对应用错误修复的挑战。