Tinker 自定义扩展

本文主要是介绍Tinker 自定义扩展，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Tinker 自定义扩展

自定义Application类

程序启动时会加载默认的Application类，这导致我们补丁包是无法对它做修改了。如何规避？在这里我们并没有使用类似InstantRun hook Application的方式，而是通过代码框架的方式来避免，这也是为了尽量少的去反射，提升框架的兼容性。

这里我们要实现的是完全将原来的Application类隔离起来，即其他任何类都不能再引用我们自己的Application。我们需要做的其实是以下几个工作：

1. 将我们自己Application类以及它的继承类的所有代码拷贝到自己的ApplicationLike继承类中，例如SampleApplicationLike。你也可以直接将自己的Application改为继承ApplicationLike;
2. Application的attachBaseContext方法实现要单独移动到onBaseContextAttached中；
3. 对ApplicationLike中，引用application的地方改成getApplication();
4. 对其他引用Application或者它的静态对象与方法的地方，改成引用ApplicationLike的静态对象与方法；

更详细的事例，大家可以参考下面的一些例子以及SampleApplicationLike的做法。

Application代理类

为了使真正的Application实现可以在补丁包中修改，我们把Appliction类的所有逻辑移动到ApplicationLike代理类中。

-public class YourApplication extends Application {
+public class SampleApplicationLike extends DefaultApplicationLike 

同时我们需要将gradle的dex loader中的Application改为新的YourApplication。

dex {
loader = ["com.tencent.tinker.loader.*",//warning, you must change it with your application"tinker.sample.android.YourApplication",       
}

具体实现可参考SampleApplicationLike, 其中对Application类的调用可以修改成：

public void registerActivityLifecycleCallbacks(Application.ActivityLifecycleCallbacks callback) {application.registerActivityLifecycleCallbacks(callback);
}

若你的应用代理Application的ClassLoader、Resource以及AssetsManger，可以使用以下方法设置。

applicationLike.setResources(res);
applicationLike.setClassLoader(classloader);
applicationLike.setTAssets(assets);

事实上，你也可以在你的Application类加入代理，但是在Application中尽量不要引用自己的类，将真正的实现放在外面。

public class YourrApplication extends Application {ActivityLifecycleCallbacks activityLifecycleCallbacks;public void setTinkerActivityLifecycleCallbacks(ActivityLifecycleCallbacks activityLifecycleCallbacks) {this.activityLifecycleCallbacks = activityLifecycleCallbacks;}

修改你的Application类

然后将你的Application类继承TinkerApplication.java。除了构造方法之外，你最好不要引入其他的类，这将导致它们无法通过补丁修改。

public class SampleApplication extends TinkerApplication {public SampleApplication() {super(//tinkerFlags, tinker支持的类型，dex,library，还是全部都支持！ShareConstants.TINKER_ENABLE_ALL,//ApplicationLike的实现类，只能传递字符串 "tinker.sample.android.app.SampleApplicationLike",//Tinker的加载器，一般来说用默认的即可"com.tencent.tinker.loader.TinkerLoader",//tinkerLoadVerifyFlag, 运行加载时是否校验dex与,ib与res的Md5false);}  
}

具体的数值含义如下：

Warning: 这里务必不能写成SampleApplicationLike.class.getName()，只能通过传递字符串的方式。为了减少错误的出现，推荐使用Annotation生成Application类

使用Annotation生成Application类

为了隐藏你的Application类，我们更加推荐你使用tinker-android-anno在运行时生成你的Application类。这样保证你无法修改你的Application类，不会因为错误操作导致引入更多无法修改的类。

@DefaultLifeCycle(
application = ".SampleApplication",                       //application类名
flags = ShareConstants.TINKER_ENABLE_ALL,                 //tinkerFlags
loaderClass = "com.tencent.tinker.loader.TinkerLoader",   //loaderClassName, 我们这里使用默认即可!
loadVerifyFlag = false)                                   //tinkerLoadVerifyFlag
public class SampleApplicationLike extends DefaultApplicationLike

若采用Annotation生成Application,需要将原来的Application类删掉。到此为止，Tinker初步的接入已真正的完成，你已经可以愉快的使用Tinker来实现补丁功能了。

可选的自定义类

在Tinker中你可以自定义一些类，它们需要在构造Tinker实例时作为参数传递，在TinkerManager的installTinker中，你可以根据自己的需要自定义其中的一些类:

//or you can just use DefaultLoadReporter
LoadReporter loadReporter = new SampleLoadReporter(appLike.getApplication());
//or you can just use DefaultPatchReporter
PatchReporter patchReporter = new SamplePatchReporter(appLike.getApplication());
//or you can just use DefaultPatchListener
PatchListener patchListener = new SamplePatchListener(appLike.getApplication());
//you can set your own upgrade patch if you need
AbstractPatch upgradePatchProcessor = new UpgradePatch();
//you can set your own repair patch if you need
AbstractPatch repairPatchProcessor = new RepairPatch();
TinkerInstaller.install(appLike,loadReporter, patchReporter, patchListener,SampleResultService.class, upgradePatchProcessor, repairPatchProcessor);

你也可以使用sampleInstallTinker，即全部使用默认参数。

各个类具体的功能与使用方法如下：

自定义LoadReporter类

LoadReporter类定义了Tinker在加载补丁时的一些回调，我们为你提供了默认实现DefaultLoadReporter.java.

一般来说, 你可以继承DefaultLoadReporter实现你自己感兴趣的事件回调，例如SampleLoadReporter.java.

我们在sample中也写了一个默认的回调上报例子，可参考SampleTinkerReport.

需要注意的有以下两点：

1. 回调运行在加载的进程，它有可能是各个不一样的进程。我们可以通过tinker.isMainProcess或者tinker.isPatchProcess知道当前是否是主进程，patch补丁合成进程。
2. 回调发生的时机是我们调用installTinker之后，某些进程可能并不需要installTinker。

现对各个回调作简要的说明:

所有的错误码都定义在ShareConstants.java，onLoadPackageCheckFail 的相关错误码解析如下：

onLoadException的错误码具体如下：

回调中定义的fileType定义如下：

加载过程的具体的错误类型与错误码可查看DefaultLoadReporter.java的注释。

对于onLoadPatchVersionChanged与onLoadFileNotFound的复写要较为谨慎，因为版本升级杀掉其他进程与文件丢失发起恢复任务，都是我认为比较重要的操作。

自定义PatchReporter类

PatchReporter类定义了Tinker在修复或者升级补丁时的一些回调，我们为你提供了默认实现DefaultPatchReporter.java.

一般来说, 你可以继承DefaultPatchReporter实现你自己感兴趣的事件回调，例如SamplePatchReporter.java.

需要注意的是:

isUpgrade：区分补丁合成的类型。是由于文件丢失而发起的RepariPatch, 还是收到新的补丁而发起的UpgradePatch。

PatchReporter中onPatchPackageCheckFail的错误码与LoadReporter的一致。

自定义PatchListener类

PatchListener类是用来过滤Tinker收到的补丁包的修复、升级请求，也就是决定我们是不是真的要唤起:patch进程去尝试补丁合成。我们为你提供了默认实现DefaultPatchListener.java。

一般来说, 你可以继承DefaultPatchListener并且加上自己的检查逻辑，例如SamplePatchListener.java。

若检查成功，我们会调用TinkerPatchService.runPatchService唤起:patch进程，去尝试完成补丁合成操作。反之，会回调检验失败的接口。事实上，你只需要复写patchCheck函数即可。若检查失败，会在LoadReporter的onLoadPatchListenerReceiveFail中回调。

public int patchCheck(String path, boolean isUpgrade)

以DefaultPatchListener为例，说明默认我们检查的条件，你可以定义自己的错误码，也可以沿用这里的错误码。

自定义AbstractResultService类

AbstractResultService类是:patch补丁合成进程将合成结果返回给主进程的类。我们为你提供了默认实现DefaultTinkerResultService.java。

一般来说, 你可以继承DefaultTinkerResultService实现自己的回调，例如SampleResultService.java。当然，你也需要在AndroidManifest上添加你的Service。

<serviceandroid:name=".service.SampleResultService"android:exported="false"
/>

默认我们在DefaultTinkerResultService会杀掉:patch进程，假设当前是补丁升级并且成功了，我们会杀掉当前进程，让补丁包更快的生效。若是修复类型的补丁包并且失败了，我们会卸载补丁包。下面对PatchResult的定义做详细说明：

在SampleResultService.java中，我们没有立刻杀掉当前进程去应用补丁，而选择在当前应用在退入后台或手机锁屏时这两个时机。你也可以在自杀前，通过发送service或者broadcast inent来尽快重启进程。

自定义TinkerLoader类

TinkerLoader类是用来加载补丁的核心类，你可以实现自己的加载逻辑。但是一般不建议那么做，如果你一定要你需要保证以下两条规则:

1. 将你的实现的类以及它用到的所有类都加入到dex.loader中;
2. 保证上述的类都在main dex中。

只要简单的将loaderClass参数中的"com.tencent.tinker.loader.TinkerLoader"，换成你的实现类的名称即可，这里只能传递字符串。

@DefaultLifeCycle(
application = ".SampleApplication",                       //application类名
flags = ShareConstants.TINKER_ENABLE_ALL,                 //tinkerFlags
loaderClass = "com.tencent.tinker.loader.TinkerLoader")   //loaderClassName, 我们这里使用默认即可!
public class SampleApplicationLike extends DefaultApplicationLike 

Tinker Notification id设置

为了提高TinkerPatchService的进程优先级，我们将它设置为Foreground。对于sdk>18的版本，使用innerService方式使通知栏不会显示。

Warning, 这里占用了id为-1119860829.若你的app存在与它相同的id, 可以使用以下API重新设置

TinkerPatchService.setTinkerNotificationId(id);
Tinker.with(context).setPatchServiceNotificationId(id);

自定义RepairPatch与UpgradePatch类

RepairPatch类是用来修复当前补丁包的处理类，也就是上面isUpgradePatch为false的情况。一般来说你不需要复写它，如果你复写了，只要把新的实例传递给TinkerInstaller即可。

UpgradePatch类是用来升级当前补丁包的处理类，也就是上面isUpgradePatch为true的情况，一般来说你也不需要复写它。

可以看到整个Tinker框架非常灵活，基本所有的逻辑都放在可复写的类或回调中，你可以轻松的完成自身需要的自定义工作。

你可以根据需要自定义以上的一些类，然后我们继续学习Tinker API概览。

这篇关于Tinker 自定义扩展的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！