当前位置：文档之家 › Android 热修复 Tinker接入及源码浅析

Android 热修复 Tinker接入及源码浅析

  • 格式：doc
  • 大小：313.00 KB
  • 文档页数：21

Android 热修复Tinker接入及源码浅析一、概述放了一个大长假，happy，先祝大家2017年笑口常开。

假期中一行代码没写，但是想着马上要上班了，赶紧写篇博客回顾下技能，于是便有了本文。

热修复这项技术，基本上已经成为项目比较重要的模块了。

主要因为项目在上线之后，都难免会有各种问题，而依靠发版去修复问题，成本太高了。

现在热修复的技术基本上有阿里的AndFix、QZone的方案、美团提出的思想方案以及腾讯的Tinker等。

其中AndFix可能接入是最简单的一个（和Tinker命令行接入方式差不多），不过兼容性还是是有一定的问题的；QZone方案对性能会有一定的影响，且在Art模式下出现内存错乱的问题(其实这个问题我之前并不清楚，主要是tinker在MDCC上指出的);美团提出的思想方案主要是基于Instant Run的原理，目前尚未开源，不过这个方案我还是蛮喜欢的，主要是兼容性好。

这么看来，如果选择开源方案，tinker目前是最佳的选择，tinker的介绍有这么一句：Tinker已运行在微信的数亿Android设备上，那么为什么你不使用Tinker呢？好了，说了这么多，下面来看看tinker如何接入，以及tinker的大致的原理分析。

希望通过本文可以实现帮助大家更好的接入tinker，以及去了解tinker的一个大致的原理。

二、接入Tinker接入tinker目前给了两种方式，一种是基于命令行的方式，类似于AndFix的接入方式；一种就是gradle的方式。

考虑早期使用Andfix的app应该挺多的，以及很多人对gradle的相关配置还是觉得比较繁琐的，下面对两种方式都介绍下。

（1）命令行接入接入之前我们先考虑下，接入的话，正常需要的前提（开启混淆的状态）。

对于API一般来说，我们接入热修库，会在Application#onCreate中进行一下初始化操作。

然后在某个地方去调用类似loadPatch这样的API去加载patch文件。

对于patch的生成简单的方式就是通过两个apk做对比然后生成；需要注意的是：两个apk做对比，需要的前提条件，第二次打包混淆所使用的mapping文件应该和线上apk是一致的。

最后就是看看这个项目有没有需要配置混淆；有了大致的概念，我们就基本了解命令行接入tinker，大致需要哪些步骤了。

依赖引入dependencies {// ...//可选，用于生成application类provided('com.tencent.tinker:tinker-android-anno:1.7.7')//tinker的核心库compile('com.tencent.tinker:tinker-android-lib:1.7.7')}顺便加一下签名的配置：android{//...signingConfigs {release {try {storeFile file("release.keystore")storePassword "testres"keyAlias "testres"keyPassword "testres"} catch (ex) {throw new InvalidUserDataException(ex.toString())}}}buildTypes {release {minifyEnabled truesigningConfig signingConfigs.releaseproguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' }debug {debuggable trueminifyEnabled truesigningConfig signingConfigs.releaseproguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' }}}文末会有demo的下载地址，可以直接参考build.gradle文件，不用担心这些签名文件去哪找。

API引入API主要就是初始化和loadPacth。

正常情况下，我们会考虑在Application的onCreate中去初始化，不过tinker推荐下面的写法：@DefaultLifeCycle(application = ".SimpleTinkerInApplication",flags = ShareConstants.TINKER_ENABLE_ALL,loadVerifyFlag = false)public class SimpleTinkerInApplicationLike extends ApplicationLike {public SimpleTinkerInApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) {super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);}@Overridepublic void onBaseContextAttached(Context base) {super.onBaseContextAttached(base);}@Overridepublic void onCreate() {super.onCreate();TinkerInstaller.install(this);}}ApplicationLike通过名字你可能会猜，并非是Application的子类，而是一个类似Application 的类。

tinker建议编写一个ApplicationLike的子类，你可以当成Application去使用，注意顶部的注解：@DefaultLifeCycle，其application属性，会在编译期生成一个SimpleTinkerInApplication 类。

所以，虽然我们这么写了，但是实际上Application会在编译期生成，所以AndroidManifest.xml 中是这样的：<applicationandroid:name=".SimpleTinkerInApplication".../>编写如果报红，可以build下。

通过该文会对一个编译时注解的运行流程和基本API有一定的掌握，文中也会对tinker该部分的源码做解析。

上述，就完成了tinker的初始化，那么调用loadPatch的时机，我们直接在Activity中添加一个Button设置：public class MainActivity extends AppCompatActivity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(yout.activity_main);}public void loadPatch(View view) {TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");}}我们会将patch文件直接push到sdcard根目录；所以一定要注意：添加SDCard权限，如果你是6.x以上的系统，自己添加上授权代码，或者手动在设置页面打开SDCard读写权限。

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />除以以外，有个特殊的地方就是tinker需要在AndroidManifest.xml中指定TINKER_ID。

<application><meta-dataandroid:name="TINKER_ID"android:value="tinker_id_6235657" />//...</application>到此API相关的就结束了，剩下的就是考虑patch如何生成。

patch生成tinker提供了patch生成的工具，源码见：tinker-patch-cli，打成一个jar就可以使用，并且提供了命令行相关的参数以及文件。

命令行如下：java -jar tinker-patch-cli-1.7.7.jar -old old.apk -new new.apk -config tinker_config.xml -out output需要注意的就是tinker_config.xml，里面包含tinker的配置，例如签名文件等。

这里我们直接使用tinker提供的签名文件，所以不需要做修改，不过里面有个Application 的item修改为与本例一致：<loader value="com.zhy.tinkersimplein.SimpleTinkerInApplication"/>大致的文件结构如下：可以在tinker-patch-cli中提取，或者直接下载文末的例子。

上述介绍了patch生成的命令，最后需要注意的就是，在第一次打出apk的时候，保留下生成的mapping文件，在/build/outputs/mapping/release/mapping.txt。

可以copy到与proguard-rules.pro同目录，同时在第二次打修复包的时候，在proguard-rules.pro 中添加上：-applymapping mapping.txt11保证后续的打包与线上包使用的是同一个mapping文件。

合集下载

Android开发学习进程0.28腾讯TBS接入和相关问题

Android开发学习进程0.28腾讯TBS接入和相关问题

Android开发学习进程0.28腾讯TBS接⼊和相关问题TBS 的接⼊和使⽤TBS 的接⼊腾讯TBS是X5内核的升级版，可以当作webview 来打开⽹页，可以以⽤来打开docx doc pdf 等⽂件，这⾥主要使⽤的是⽂件功能。

依赖接⼊api 'com.tencent.tbs.tbssdk:sdk:43939'这是笔者2021/2/25编辑时最新版本，最新可在官⽹查询。

如果依赖⽂件下载有问题可⼿动下载jia包，本地依赖包可放在 app/libs 下，⽂件夹可⾃⾏创建，同时在 app/src/main/jniLibs/armeabi 下存放.so ⽂件。

再module 的gradle⽂件defaultConfig下添加ndk {abiFilters "armeabi", "x86", "mips", "armeabi-v7a"}这是为了避免64位⼿机不兼容的情况，强制打包。

部分博客仅添加了 “armeabi” ⼀项。

TBS 的使⽤1 在继承的application中初始化QbSdk.PreInitCallback cb = new QbSdk.PreInitCallback() {@Overridepublic void onViewInitFinished(boolean arg0) {//x5內核初始化完成的回调，为true表⽰x5内核加载成功，否则表⽰x5内核加载失败，会⾃动切换到系统内核。

Log.e(TAG, "加载内核是否成功:" + arg0);}@Overridepublic void onCoreInitFinished() {Log.e(TAG, "加载内核是否成功:");}};//x5内核初始化接⼝QbSdk.initX5Environment(getApplicationContext(), cb);这⾥解释下，initX5Environment初始化⽅法中回调是可以写做 null的，但为了验证是否成功加载内核，还是有必要重写⼀下⽅法。

ANDROID源码结构分析

ANDROID源码结构分析

ANDROID源码结构分析Android是一个开源的操作系统，其源代码以Apache License 2.0开源许可证的形式向公众发布。

它的源码结构非常庞大而复杂，涵盖了各种组件和功能，以支持不同形式的设备和应用。

本文将对Android源码的结构进行详细分析，让读者对Android系统的内部构建有更深入的理解。

Android源码主要分为四个部分：内核、硬件抽象层（HAL）、Android运行时环境（ART/Dalvik）和框架层。

这些部分协同工作，形成了Android完整的系统架构。

1. 内核部分：Android操作系统的底层是Linux内核，它提供了访问硬件设备、内存管理、进程管理、安全性等基本功能。

Android对Linux内核进行了一些定制，以适应移动设备的特性和需求，比如增加了对电池管理、相机功能、音频系统的支持等。

Android的内核代码位于kernel目录下，包括了Linux内核的源码以及Android特有的补丁。

2. 硬件抽象层（HAL）：HAL层负责将底层硬件与操作系统之间的交互抽象出来，为上层应用提供统一的接口。

HAL层的代码位于硬件厂商提供的硬件抽象层的目录下，通常是在device或vendor目录下，有些库会放在硬件设备目录中。

3. Android运行时环境：Android系统采用了Java虚拟机（Dalvik 或ART）作为应用程序运行的环境。

Dalvik是Android4.4之前的默认虚拟机，而ART是Android5.0及之后的默认虚拟机。

Android运行时环境负责将应用程序的Java字节码翻译成机器码，执行应用程序代码。

运行时环境的代码位于art和dalvik目录下。

4. 框架层：框架层包括了各种系统服务、应用程序接口（API）和系统应用程序。

这些框架组件实现了Android系统的核心功能，比如窗口管理、通信服务、多媒体播放、数据存储等。

框架层的代码位于frameworks目录下，其中包括了各种子目录用于存放不同功能模块的代码，比如native相关的代码在native目录下，多媒体相关的代码在media目录下等。

android的unifykeys的工作原理

android的unifykeys的工作原理

android的unifykeys的工作原理
Android的UnifyKeys的工作原理涉及到Android系统的内部机制和软件架构。

UnifyKeys是一个用于Android应用程序的开源库，它允许开发者在应用程序中统一处理各种键值对，包括从配置文件、环境变量、命令行参数等来源获取的键值对。

UnifyKeys的工作原理主要基于以下步骤：
集成库：首先，开发者需要将UnifyKeys库集成到他们的Android项目中。

这通常涉及到在项目的构建文件中添加UnifyKeys库的依赖项。

配置键值对源：开发者需要配置UnifyKeys以指定键值对的来源。

这可以通过在代码中设置配置对象或使用外部配置文件来完成。

解析键值对：当应用程序启动时，UnifyKeys会自动解析配置文件、环境变量和命令行参数中的键值对。

这些键值对被提取到一个统一的数据结构中，以便于访问和使用。

提供键值对访问：通过UnifyKeys提供的API，开发者
可以在应用程序中方便地访问和使用这些键值对。

这些API 提供了诸如获取特定键的值、检查键是否存在等功能。

动态更新：UnifyKeys还支持动态更新键值对。

这意味着当外部配置发生变化时，应用程序可以自动重新加载配置并应用最新的键值对，而无需重新启动应用程序。

安全性：UnifyKeys还考虑了安全性问题。

它支持加密和解密敏感数据，以确保键值对在传输和存储时的安全性。

总之，Android的UnifyKeys通过集成、配置、解析、访问和动态更新等步骤实现了统一处理各种键值对的功能，为开发者提供了一个方便、安全的方式来管理和使用键值对数据。

startactivityinner 源码 解析

startactivityinner 源码 解析

startactivityinner 源码解析摘要：1.Android 中的StartActivity 方法介绍2.StartActivity 的工作原理3.StartActivity 参数解析4.常见问题及解决方法5.实战案例分享正文：作为一名Android 开发者，熟练掌握StartActivity 方法对于实现应用程序的跳转功能至关重要。

本文将详细介绍Android 中的StartActivity 方法，解析其工作原理，并分析常见问题及解决方法。

最后，将通过实战案例分享，帮助大家更好地理解和应用StartActivity。

1.Android 中的StartActivity 方法介绍在Android 中，StartActivity 方法是Activity 类中的一个方法，用于启动另一个Activity。

通过调用这个方法，可以实现不同界面之间的跳转，使得应用程序的功能更加丰富。

StartActivity 方法的定义如下：```javapublic void startActivity(Intent intent)```参数：- Intent：表示要启动的Activity 的Intent 对象。

2.StartActivity 的工作原理StartActivity 方法启动另一个Activity 的过程可以分为以下几个步骤：- 创建一个Intent 对象，表示要启动的Activity。

- 调用startActivity 方法，将Intent 对象传递给目标Activity。

- 目标Activity 接收到Intent 对象，根据Intent 中的信息创建对应的实例。

- 目标Activity 实例启动，并设置界面布局。

- 源Activity 完成跳转，退出屏幕。

3.StartActivity 参数解析在StartActivity 方法中，Intent 对象包含了要启动的Activity 相关信息。

以下是Intent 对象中常用的参数：- action：表示Activity 启动的类型，例如ACTION_VIEW、ACTION_EDIT 等。