Tinker使用指南

最新推荐文章于 2024-05-08 03:32:12 发布
最新推荐文章于 2024-05-08 03:32:12 发布
阅读量4.4k 收藏 6
点赞数 2
分类专栏： 热修复 文章标签： 热修复 tinker Android
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/it_xf/article/details/80910336
版权

随着技术的发展，我们来到了热修复时代，网上一大堆关于热修复的文章和框架，相信能来到这里，你也知道什么叫热修复吧，让我用通俗的语言给大家定义一个概念：

热修复就是在无需重新安装应用的情况下，修改目前存在的bug，或者新增功能

这样讲是不是蛮好理解的。

然后我们再众多热修复框架中，选择Tinker作为我们实现热修复的手段。那就来吧！

前言

其实怎么接入tinker，官方已经给出了方法，但是我们在接入的时候，难免会遇到不少问题（官方文档不是非常非常详细背锅）。其实官方文档写的还是蛮详细的，只是我们在照着文档操作的时候，还是有那么一点不顺畅，中间遇到一些小问题，所以我希望大家在观看我这篇文章后，能够丝滑接入Tinker，并得到成就感。那，我们就开始吧！

依赖接入

假设你已经创建好一个新项目了（我用的Android studio 3.1.2），首先我们先给这个应用加上依赖吧，需要加依赖的地方有2个，我们一个一个来：

  • 在项目根build.gradle添加以下依赖：
classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.9.1')
  • 在应用目录添加以下依赖
// 可选，用于生成application类 
compileOnly('com.tencent.tinker:tinker-android-anno:1.9.1')
// tinker的核心库
implementation('com.tencent.tinker:tinker-android-lib:1.9.1') 
// Google提供的分包小助手
implementation "com.android.support:multidex:1.0.3"

Gradle配置

注：以下配置，均在app的gradle文件中做配置

在项目的build.gradle中配置，在做配置前，我们先创建两个签名文件，一个作为正式版的签名，另一个作为debug版的签名吧，然后放到项目中，这是为了使以后直接就生成签名后的apk文件，免得生成apk以后还要自己去签一次名。
这里我偷个懒，直接用tinker-sample-android中的签名吧，签名放这里。
这里写图片描述

我们先来配置下签名，在android{}中做以下配置：

android{
    ...
    // 这里做签名的配置
    signingConfigs {
        release {
            try {
                storeFile file("./keystore/release.keystore")
                storePassword "testres"
                keyAlias "testres"
                keyPassword "testres"
            } catch (ex) {
                throw new InvalidUserDataException(ex.toString())
            }
        }

        debug {
            storeFile file("./keystore/debug.keystore")
        }
    }
    ...
}

然后我们再指定下构建的种类：

android {
    ...
    buildTypes {
        release {
            minifyEnabled true
            signingConfig signingConfigs.release
            proguardFiles getDefaultProguardFile('proguard-android.txt'), project.file('proguard-rules.pro')
        }
        debug {
            debuggable true
            minifyEnabled false
            signingConfig signingConfigs.debug
        }
    }
    ...
}

还记得我们添加了Google提供的分包小助手吗，我们需要开启这个分包的功能：

android {
    ...
    defaultConfig {
        ...
        multiDexEnabled true // 开启dex分包
        ...
    }
}

好的，以上就把android{}中的东西配置的差不多了，接下来我们需要配置点其他东西，具体配置可以参照官方的build.gradle，不过官方配置的东西太多了，但我没打算配置这么多东西，所以来看看我们的版本（其实也挺多），直接上码？

def bakPath = file("${buildDir}/bakApk/")

/**
 * you can use assembleRelease to build you base apk
 * use tinkerPatchRelease -POLD_APK=  -PAPPLY_MAPPING=  -PAPPLY_RESOURCE= to build patch
 * add apk from the build/bakApk
 */
ext {
    // 是否使用Tinker
    tinkerEnabled = true
    // 原先编译好的APK包
    tinkerOldApkPath = "${bakPath}/app-debug-1018-17-32-47.apk"
    // 使用原APK的混淆方式
    tinkerApplyMappingPath = "${bakPath}/app-debug-1018-17-32-47-mapping.txt"
    // R文件，跟原APK的R做对比，以便知道哪些资源文件做了变化
    tinkerApplyResourcePath = "${bakPath}/app-debug-1018-17-32-47-R.txt"
    // 这里是APK风味构建啥的（是否为支付应用等等），如果APK不涉及这些东西，可以忽略
    tinkerBuildFlavorDirectory = "${bakPath}/app-1018-17-32-47"
}

def getTinkerEnabled(){
    ext.tinkerEnabled
}
def getTinkerApplyMappingPath() {
    ext.tinkerOldApkPath
}
def getTinkerApplyResourcePath(){
    ext.tinkerApplyResourcePath
}

if (ext.tinkerEnabled) {
    apply plugin: 'com.tencent.tinker.patch'

    // 全局信息相关的配置项
    tinkerPatch {

        // 是否打开tinker的功能。
        tinkerEnable = getTinkerEnabled()

        // 基准apk包的路径，必须输入，否则会报错。
        oldApk = "${bakPath}/app-debug-0704-16-30-41.apk"

        // 选填，用于编译补丁apk路径。如果路径合法，即不再编译新的安装包，使用oldApk与newApk直接编译。
//        newApk =

        // 选填，设置编译输出路径。默认在build/outputs/tinkerPatch中
//        outputFolder = null

        // 如果出现以下的情况，并且ignoreWarning为false，我们将中断编译。因为这些情况可能会导致编译出来的patch包带来风险：
        // 1. minSdkVersion小于14，但是dexMode的值为"raw";
        // 2. 新编译的安装包出现新增的四大组件(Activity, BroadcastReceiver...)；
        // 3. 定义在dex.loader用于加载补丁的类不在main dex中;
        // 4. 定义在dex.loader用于加载补丁的类出现修改；
        // 5. resources.arsc改变，但没有使用applyResourceMapping编译。
//        ignoreWarning = false

        // 在运行过程中，我们需要验证基准apk包与补丁包的签名是否一致，我们是否需要为你签名。
        useSign = true

        // 编译相关的配置项
        buildConfig {

            // 可选参数；在编译新的apk时候，我们希望通过保持旧apk的proguard混淆方式，从而减少补丁包的大小。这个只是推荐设置，不设置applyMapping也不会影响任何的assemble编译。
            applyMapping = getTinkerApplyMappingPath()

            // 可选参数；在编译新的apk时候，我们希望通过旧apk的R.txt文件保持ResId的分配，这样不仅可以减少补丁包的大小，同时也避免由于ResId改变导致remote view异常。
            applyResourceMapping = getTinkerApplyResourcePath()

            // 在运行过程中，我们需要验证基准apk包的tinkerId是否等于补丁包的tinkerId。这个是决定补丁包能运行在哪些基准包上面，一般来说我们可以使用git版本号、versionName等等。
            tinkerId = "tinkerdemo"

            // 如果我们有多个dex,编译补丁时可能会由于类的移动导致变更增多。若打开keepDexApply模式，补丁包将根据基准包的类分布来编译。
            keepDexApply = false

            // 是否使用加固模式，仅仅将变更的类合成补丁。注意，这种模式仅仅可以用于加固应用中。
            isProtectedApp = true

            // 是否支持新增非export的Activity(1.9.0新加的功能)
            supportHotplugComponent = false

        }

        // dex相关的配置项
        dex {
            // 只能是'raw'或者'jar'。
            // 对于'raw'模式，我们将会保持输入dex的格式。
            // 对于'jar'模式，我们将会把输入dex重新压缩封装到jar。如果你的minSdkVersion小于14，你必须选择‘jar’模式，而且它更省存储空间，但是验证md5时比'raw'模式耗时。默认我们并不会去校验md5,一般情况下选择jar模式即可。
            dexMode = "jar"

            // 需要处理dex路径，支持*、?通配符，必须使用'/'分割。路径是相对安装包的，例如assets/...
            pattern = ["classes*.dex",
                       "assets/secondary-dex-?.jar"]

            // 这一项非常重要，它定义了哪些类在加载补丁包的时候会用到。这些类是通过Tinker无法修改的类，也是一定要放在main dex的类。
            // 这里需要定义的类有：
            // 1. 你自己定义的Application类；
            // 2. Tinker库中用于加载补丁包的部分类，即com.tencent.tinker.loader.*；
            // 3. 如果你自定义了TinkerLoader，需要将它以及它引用的所有类也加入loader中；
            // 4. 其他一些你不希望被更改的类，例如Sample中的BaseBuildInfo类。这里需要注意的是，这些类的直接引用类也需要加入到loader中。或者你需要将这个类变成非preverify。
            // 5. 使用1.7.6版本之后的gradle版本，参数1、2会自动填写。若使用newApk或者命令行版本编译，1、2依然需要手动填写
            loader = [
                    // 不会修改的类放在这里，格式如下
                    // "com.qxf.tinkerdemo.BuildConfig"
            ]
        }

        // lib相关的配置项
        lib {
            // 需要处理lib路径，支持*、?通配符，必须使用'/'分割。与dex.pattern一致, 路径是相对安装包的，例如assets/...
            pattern = ["lib/*/*.so"]
        }

        // res相关的配置项
        res {
            // 需要处理res路径，支持*、?通配符，必须使用'/'分割。与dex.pattern一致, 路径是相对安装包的，例如assets/...，务必注意的是，只有满足pattern的资源才会放到合成后的资源包。
            pattern = ["res/*", "assets/*", "resources.arsc", "AndroidManifest.xml"]

            // 支持*、?通配符，必须使用'/'分割。若满足ignoreChange的pattern，在编译时会忽略该文件的新增、删除与修改。 最极端的情况，ignoreChange与上面的pattern一致，即会完全忽略所有资源的修改。
            ignoreChange = ["assets/sample_meta.txt"]

            // 对于修改的资源，如果大于largeModSize，我们将使用bsdiff算法。这可以降低补丁包的大小，但是会增加合成时的复杂度。默认大小为100kb
            largeModSize = 100
        }

        // 用于生成补丁包中的'package_meta.txt'文件
        packageConfig {
            // configField("key", "value"), 默认我们自动从基准安装包与新安装包的Manifest中读取tinkerId,并自动写入configField。在这里，你可以定义其他的信息，在运行时可以通过TinkerLoadResult.getPackageConfigByName得到相应的数值。但是建议直接通过修改代码来实现，例如BuildConfig。
            configField("patchMessage", "tinker is sample to use")
            /**
             * just a sample case, you can use such as sdkVersion, brand, channel...
             * you can parse it in the SamplePatchListener.
             * Then you can use patch conditional!
             */
            configField("platform", "all")
            /**
             * patch version via packageConfig
             */
            configField("patchVersion", "1.0")
        }
        //or you can add config filed outside, or get meta value from old apk
        //project.tinkerPatch.packageConfig.configField("test1", project.tinkerPatch.packageConfig.getMetaDataFromOldApk("Test"))
        //project.tinkerPatch.packageConfig.configField("test2", "sample")

        // 7zip路径配置项，执行前提是useSign为true
        sevenZip {
            // 例如"com.tencent.mm:SevenZip:1.1.10"，将自动根据机器属性获得对应的7za运行文件，推荐使用。
            zipArtifact = "com.tencent.mm:SevenZip:1.1.10"
            // 系统中的7za路径，例如"/usr/local/bin/7za"。path设置会覆盖zipArtifact，若都不设置，将直接使用7za去尝试。
            // path = "/usr/local/bin/7za"
        }
    }

    List<String> flavors = new ArrayList<>();
    project.android.productFlavors.each { flavor ->
        flavors.add(flavor.name)
    }
    boolean hasFlavors = flavors.size() > 0
    def date = new Date().format("MMdd-HH-mm-ss")

    /**
     * bak apk and mapping
     */
    android.applicationVariants.all { variant ->
        /**
         * task type, you want to bak
         */
        def taskName = variant.name

        tasks.all {
            if ("assemble${taskName.capitalize()}".equalsIgnoreCase(it.name)) {

                it.doLast {
                    copy {
                        def fileNamePrefix = "${project.name}-${variant.baseName}"
                        def newFileNamePrefix = hasFlavors ? "${fileNamePrefix}" : "${fileNamePrefix}-${date}"

                        def destPath = hasFlavors ? file("${bakPath}/${project.name}-${date}/${variant.flavorName}") : bakPath
                        from variant.outputs.first().outputFile
                        into destPath
                        rename { String fileName ->
                            fileName.replace("${fileNamePrefix}.apk", "${newFileNamePrefix}.apk")
                        }

                        from "${buildDir}/outputs/mapping/${variant.dirName}/mapping.txt"
                        into destPath
                        rename { String fileName ->
                            fileName.replace("mapping.txt", "${newFileNamePrefix}-mapping.txt")
                        }

                        from "${buildDir}/intermediates/symbols/${variant.dirName}/R.txt"
                        into destPath
                        rename { String fileName ->
                            fileName.replace("R.txt", "${newFileNamePrefix}-R.txt")
                        }
                    }
                }
            }
        }
    }
    project.afterEvaluate {
        //sample use for build all flavor for one time
        if (hasFlavors) {
            task(tinkerPatchAllFlavorRelease) {
                group = 'tinker'
                def originOldPath = ext.tinkerBuildFlavorDirectory
                for (String flavor : flavors) {
                    def tinkerTask = tasks.getByName("tinkerPatch${flavor.capitalize()}Release")
                    dependsOn tinkerTask
                    def preAssembleTask = tasks.getByName("process${flavor.capitalize()}ReleaseManifest")
                    preAssembleTask.doFirst {
                        String flavorName = preAssembleTask.name.substring(7, 8).toLowerCase() + preAssembleTask.name.substring(8, preAssembleTask.name.length() - 15)
                        project.tinkerPatch.oldApk = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release.apk"
                        project.tinkerPatch.buildConfig.applyMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release-mapping.txt"
                        project.tinkerPatch.buildConfig.applyResourceMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release-R.txt"

                    }

                }
            }

            task(tinkerPatchAllFlavorDebug) {
                group = 'tinker'
                def originOldPath = ext.tinkerBuildFlavorDirectory
                for (String flavor : flavors) {
                    def tinkerTask = tasks.getByName("tinkerPatch${flavor.capitalize()}Debug")
                    dependsOn tinkerTask
                    def preAssembleTask = tasks.getByName("process${flavor.capitalize()}DebugManifest")
                    preAssembleTask.doFirst {
                        String flavorName = preAssembleTask.name.substring(7, 8).toLowerCase() + preAssembleTask.name.substring(8, preAssembleTask.name.length() - 13)
                        project.tinkerPatch.oldApk = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug.apk"
                        project.tinkerPatch.buildConfig.applyMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug-mapping.txt"
                        project.tinkerPatch.buildConfig.applyResourceMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug-R.txt"
                    }

                }
            }
        }
    }
}

还是挺多的对不？我知道你要CV大法了。

简单配置

按照以上步骤，我相信你应该已经配置完毕了，接下来我们就要开始使用了，如何在代码中使用这些东西呢。

在Tinker里面，有一个叫着ApplicatioLike的东西，这个东西，看着名字挺像Application的让人怀疑它是Application的子类，其实不是的，不过这个类你完全可以把它当作一个Application来使用，好吧，我们来使用一下吧。
首先我们创建一个类MyApplicationLike来继承Application，OK，里面要怎么写呢？

@DefaultLifeCycle(
        // 将 要自动生成的application的类，指定生成位置和类名
        application = "com.qxf.tinkerdemo.MyApplication",
        flags = ShareConstants.TINKER_ENABLE_ALL,
        //loaderClassName, 我们这里使用默认即可!
        loaderClass = "com.tencent.tinker.loader.TinkerLoader",
        loadVerifyFlag = false)
public class MyApplicationLike extends ApplicationLike {

    public MyApplicationLike(
            Application application,
            int tinkerFlags,
            boolean tinkerLoadVerifyFlag,
            long applicationStartElapsedTime,
            long applicationStartMillisTime,
            Intent tinkerResultIntent) {

        super(
                application,
                tinkerFlags,
                tinkerLoadVerifyFlag,
                applicationStartElapsedTime,
                applicationStartMillisTime,
                tinkerResultIntent);
    }

@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    public void registerActivityLifecycleCallbacks(Application.ActivityLifecycleCallbacks callback) {
        getApplication().registerActivityLifecycleCallbacks(callback);
    }

}

（上面的代码，别光顾着复制到自己的项目中就完了，记得看一下，有注释的= =）

然后我们build以下项目，我们会发现项目中的这里，自动生成了一个类：
这里写图片描述
既然现在有application了，那我们就在AndroidManifest.xml中做一些配置吧。

首先加上两个权限，内存读写权限，至于Android版本大于6.0的手机，记得要做一下动态授权，以免到时候找不到补丁包：

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

然后加上自动生成的application：

<application
        android:name=".MyApplication"
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        <!--顺便加上这个服务，tinker自带的-->
        <service android:name="com.tencent.tinker.lib.service.DefaultTinkerResultService" />
    </application>

既然application已经配置完毕了，我们再回头来看看MyApplicationLike这个类，这个类里面要写一些东西，来表示我们不止会配置，还会用。
我们要重写onBaseContextAttached方法，那就来吧：

    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    @Override
    public void onBaseContextAttached(Context base) {
        super.onBaseContextAttached(base);

        // 分包需要的东西
        MultiDex.install(base);

        // LoadReporter类定义了Tinker在加载补丁时的一些回调
        LoadReporter loadReporter = new DefaultLoadReporter(getApplication());
        // PatchReporter类定义了Tinker在修复或者升级补丁时的一些回调
        PatchReporter patchReporter = new DefaultPatchReporter(getApplication());
        // PatchListener类是用来过滤Tinker收到的补丁包的修复、升级请求，也就是决定我们是不是真的要唤起:patch进程去尝试补丁合成。
        PatchListener patchListener = new DefaultPatchListener(getApplication());
        // UpgradePatch类是用来升级当前补丁包的处理类，一般来说你也不需要复写它。
        AbstractPatch upgradePatchProcessor = new UpgradePatch();

        TinkerInstaller.install(this,
                loadReporter, patchReporter, patchListener,
                DefaultTinkerResultService.class, upgradePatchProcessor);

    }

老实说，其实这里的也算配置= =

不过到这里到时候，我们的Tinker，简单的配置，基本就都完成了。

实践

现在我们要开始正式使用tinker了。
tinker的使用过程（概念）：

 1. 运行含有bug的app
 2. 加载补丁
 3. 重启应用
 4. bug消失

我们无法判断应用是否有bug，因为上线的时候肯定是感觉各个地方都没有问题才上线的吧（汗！）

我们这样来测试吧，MainActivity做两个按钮，一个加载补丁的按钮，一个测试按钮。嗯，说干就干！

界面搭建：
这里写图片描述
界面就这么简单了
点击事件的逻辑如下：

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.load:
                // 加载补丁
                TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),
                        Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed_7zip.apk");
                break;
            case R.id.test:
                show.setText("测试结果："+"bug");
                break;
        }
    }

接下来我们将这个打包成APK，在这里打包
这里写图片描述
打包完毕后，在这里会生成一个apk
这里写图片描述
将这个apk安装到手机上，然后点击一下测试，好吧，你们已经猜到答案了：
这里写图片描述

然后我们来修复以下这个伪bug，就这样修复吧

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.load:
                // 加载补丁
                TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),
                        Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed_7zip.apk");
                break;
            case R.id.test:
                show.setText("测试结果："+"bug已被修复");
                break;
        }
    }

我们把生成的刚刚生成的APK的名字，复制到app下的build.gradle中oldApk这里，像这样
这里写图片描述
然后我们利用tinker的打包工具tinkerPatchDebug生成补丁
这里写图片描述
生成的补丁将会来到这里
这里写图片描述

接下来重点来了，我们要将这个文件放到手机的指定位置/storage/emulated/0
（毕竟是个demo，就不把补丁放到服务器上，然后从服务器下载到手机上再加载补丁了），所以我就直接通过adb命令直接把文件push到手机上了。

push命令这里大概说一下：

adb push 电脑上的文件的路径 手机路径

这里写图片描述
这里顺便说一个你们可能已经知道了的快捷键，选中studio中的文件，crtl+shift+c 可以直接复制文件的绝对路径

好了，现在我们重新打开应用看看怎么样了，重新打开应用，点击加载补丁，加载完补丁后，点击测试，还是有bug，不过重启应用后，再次点击，我们将会看到，bug已经被修复了
这里写图片描述

tinker的简单使用差不多就是这样，各种配置完毕后，得到补丁，加载补丁，重启应用，bug消失。

常见问题

在使用tinker的时候，可能会遇到一些小问题，我这里大概说几个：

  1. 找不到补丁文件
    多半都是你没有加读写权限，可能你加了，但是由于你手机是Android6.0以上，所以需要动态获取权限

  2. tinkerId is not set!!!
    如果按照我的方式来，应该不会出现这些问题，出现这个问题的主要原因多半都是按照官方说明接入的，由于官方获取tinkerId是通过得到git提交的提交码得到的，所以只需要把代码通过git提交一次就可以得到tinkerId了，不过我不喜欢这样做，因为像我这种写一行代码都可能会提交的人来说，tinkerId会一直变动。

  3. Annotation processors must be explicitly declared now.
    有可能在使用Tinker的时候，会报这个错，解决方案也很简单：

javaCompileOptions { annotationProcessorOptions { includeCompileClasspath = true } }

将这句代码，加入android{}下的defaultConfig{}里面即可

加固
这里多提一句，isProtectedApp，关于这个属性，如果要使用加固的功能，需要把这个值设置为true，搬一下官方的话就是：
tinker 1.7.8 可以通过 isProtectedApp 开启加固支持，这种模式仅仅可以使用在加固应用中。
支持加固的厂商有：

腾讯云·乐固
爱加密
梆梆加固
360加固(需要5月8号后的加固版本)

其他 请自行测试，只要满足下面规则的都可以支持
这里是否支持加固，需要加固厂商明确以下两点：
1.不能提前导入类；
2.在art平台若要编译oat文件，需要将内联取消。

其他常见问题或许你可以在官方常见问题这里找到答案。

最后

Tinker提供的东西不止我这里写的这么简单，大家可以参考Tinker自定义扩展，其实Tinker还是很灵活的，推荐大概看下自定义扩展里面的内容，然后在把官方的例子tinker-sample-android下载下来好好看看官方是这么实现的，相信你能够了解到更多的东西。

你缺少想象力
关注
  • 2
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
深入比较：Python GUI开发工具Tkinter与PyQt的优劣分析
mrdeam的博客
06-25 923
GUI（图形用户界面）应用程序是用户与计算机交互的重要方式之一，而Python作为一种流行的编程语言，在GUI开发领域有着丰富的选择。本文将介绍两种常用的Python GUI工具包：Tkinter和PyQt，并对它们进行比较，帮助开发者选择适合自己项目需求的工具。
Tinker的简单使用（超级详细）
sfz60123的博客
11-21 5172
第一步：下载tinker的demo（可以自己先跑通） 出现问题可以去官网wike去看 下面说接入tinker，跑一个简单的demo 1、在项目目录的build.gradle文件里面引入 buildscript { dependencies { classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.7
热修复——Tinker的集成与使用
weixin_33831673的博客
12-06 350
一、简述 Tinker是微信官方的Android热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用Tinker来更新你的插件。 上面是Tinker官方Wiki的原话，意思嘛相信大家都看得明白，但注意啦，它并没有说Tinker可以让补丁实时生效（也叫无感知更新），它必须在打上补丁后重启App（重启进程），补丁才会发挥作用，这跟阿里的...
Android 热修复框架 Tinker ( 三 )
liujun2son
01-09 561
这篇博客是基于Android 热修复框架 Tinker ( 一)写的，在看这篇博客之前请先看Android 热修复框架 Tinker ( 一 )。1.方法替换注意：下面是居于上一篇文章的项目（已经集成Tinker）1.编写avtivity_main.xml<?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android="htt
Android Tinker 基本使用教程
明耀的博客
03-31 1672
转载：Android Tinker 基本使用教程 为什么使用Tinker 当前市面的热补丁方案有很多，其中比较出名的有阿里的AndFix、美团的Robust以及QZone的超级补丁方案。但它们都存在无法解决的问题，这也是正是我们推出Tinker的原因。 这个Tinker官方给出的一个图表： 1.怎么使用： Tinker 的使用还是比较简单的，这是Tinker官方的github链接 : https://github.com/Tencent/tinker. 官方上面的文档很久没更新了，可以直接下载他最新的de
Thinker 使用详解
345丶
11-26 4546
AndFix基本介绍 ​ 已经好几年没有维护了，阿里出了一个收费的。这个已经被放弃了。这里只是简单的介绍一下用法 ​ AndFix是一个在线修复bug的解决方案，而不是重新发布Android App。它是作为Android库发布的。Andfix是“Android热修复”的缩写。 ​ AndFix支持Android 2.3 - 7.0版本，支持ARM和X86架构，支持Dalvik和ART r...
热修复框架tinker的使用简介
helloworld19870427的专栏
04-26 876
一、说明 Tinker 是一个开源项目(Github链接)，它是微信官方的 Android 热补丁解决方案，它支持动态下发代码、So 库以及资源，让应用能够在不需要重新安装的情况下实现更新，当前市面的热补丁方案有很多，其中比较出名的有阿里的 AndFix、美团的 Robust 以及 QZone 的超级补丁方案。但它们都存在无法解决的问题，这也是正是我推出 Tinker 的原因，这是官方的文档：h...
接入Tinker热修复和踩坑
lt的博客
09-15 2223
前言 公司最近项目上线后总是遇见各种问题或bug,而我最近就一直在背黑锅,幸亏最近不用上Google Play了,赶紧加上热更新来脱离苦海吧,谁知道接入Tinker的过程中也踩了将近一周的坑,哎...一言难尽 为什么选择Tinker我就对比了也懒得说了(其实是因为隔壁阿里收费) 而且需要注意,中间很多版本不要使用最新的,要使用我写的,不然有问题了找都找不到(我在这中间查,试,测,中间用了不知道多长时间) 正文 此次接入Tinker是直接用的Tinker,没有使用Bugly的方式 官方地址 不多
Tinker集成和遇坑总结
life90的博客
01-19 2754
1.tinker集成步骤 添加依赖 初始化 生成补丁 下发补丁 1.添加依赖 添加project依赖 添加model依赖 添加tinkerPatch.gradle   添加project依赖：打开项目project的gradle添加以下代码 buildscript { repositories { jcenter() google() ...
Tinker热修复方案（适合新手入门，因为我也初次搞这东西）
qq_42416278的博客
07-18 389
首先双手奉上官方文档 官方文档直通车 首先我们要知道为什么使用热修复？ 热修复就是让用户不知道的情况下对App进行打补丁修复,比如用户反馈发现重大bug然后就会找到程序员进行及时修改,对App进行修复然后再从新打包上线,这样比较耗费人力,所以就出现了热修复,通过事先定设定的借口从网上下载无bug的代码来替换有bug的代码,这样比较省事用户体验也好,尤其是对于用户量多的App,一个bug不只...
TinkerTest:Android Tinker demo例子
05-12
**Android Tinker 深入理解与实战指南** 在 Android 应用开发中，热修复技术已经成为提升用户体验和快速响应线上问题的关键手段。Tinker，由腾讯开发的一款开源的 Android 热修复框架，旨在帮助开发者实现应用的...
TinkerDemo
02-20
**微信热修补Tinker快速集成指南** 在移动应用开发领域，为了提高用户体验并减少应用的停机时间，热修补技术应运而生。微信Tinker就是一款强大的Android热补丁框架，它允许开发者在不更新应用的情况下修复线上出现...
Bugly Android 应用升级 SDK 使用指南
最新发布
08-05
在接入sdk之前，请务必认真阅读《开发者合规指南》和《Bugly SDK个人信息保护规则》 接入前准备 Google Play版本是否可以有Tinker相关代码？ 概述 自动导入（推荐） 使用Android Studio创建project gradle配置（重要...
Android 开发指南
12-29
16. **热修复与插件化**：对于大规模应用，热修复技术（如Tinker）和插件化框架（如Dexposed、SplitCompat）能有效解决线上问题和更新迭代。 17. **Android应用发布**：学习如何打包、签名应用，并通过Google Play ...
awesome-asus-tinker-board：华硕Tinker Board资源精选列表
02-05
通过这些资源，你可以深入学习Tinker Board的使用，开发出属于自己的独特应用，实现从理论到实践的跨越。 总之，"awesome-asus-tinker-board"集合了华硕Tinker Board开发和应用的精华，对于任何想要利用这款设备...
Tinker 使用
lk2021991的博客
03-18 1125
Tinker时微信推出的热修复框架，优点就是很稳定，可以gradle打包，缺点是这个修复不是实时的，需要重启。这是由于其实现的原理决定的，简单的说他是通过把生成的不定apk,加载进来，通过与基线apk的整合生成新的dex集合，最后生成oat文件。这只是整合成的文件而已，并没有影响ClassLoader的加载既存在的dex类。而重启之后Tinker会通过反射获取BaseDexClass...
Android 腾讯热修复方案Tinker基本使用
qq_32136827的博客
03-20 505
Android客户端腾讯系Tinker热修复方案
热修复——Tinker的集成与使用(1)
2401_84148981的博客
05-08 793
基础包就是已经上架的apk文件（假设是1.0版本）。这其实很好理解，在新版本的App上架之前（假设是2.0版本），我们会用到Tinker来修复1.0版App中存在的bug，这时就需要用到Tinker来产生补丁包文件，而补丁包文件的本质，就是修复好Bug的App与1.0版本App之间的文件差异。
tinker 和 tinker panic 区别
05-25
Tinker是一个开源的命令行工具，可以用来快速创建和管理项目，它可以自动化地完成一些常见的任务，例如创建文件、安装依赖、运行测试等。 而Tinker Panic是一个基于Tinker的GUI工具，它提供了图形化界面，可以帮助用户更方便地管理Tinker项目。Tinker Panic提供了与Tinker相同的功能，但是它是使用图形化界面来执行这些功能的。 因此，Tinker和Tinker Panic的区别在于它们的用户界面不同，Tinker是一个命令行工具，而Tinker Panic是一个GUI工具。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值