放了一个大长假,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 true
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile(‘proguard-android.txt’), ‘proguard-rules.pro’
}
debug {
debuggable true
minifyEnabled true
signingConfig signingConfigs.release
proguardFiles 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);
}
@Override
public void onBaseContextAttached(Context base) {
super.onBaseContextAttached(base);
}
@Override
public void onCreate() {
super.onCreate();
TinkerInstaller.install(this);
}
}
ApplicationLike通过名字你可能会猜,并非是Application的子类,而是一个类似Application的类。
tinker建议编写一个ApplicationLike的子类,你可以当成Application去使用,注意顶部的注解:@DefaultLifeCycle
,其application属性,会在编译期生成一个SimpleTinkerInApplication
类。
所以,虽然我们这么写了,但是实际上Application会在编译期生成,所以AndroidManifest.xml
中是这样的:
<application
android:name=“.SimpleTinkerInApplication”
…/>
编写如果报红,可以build下。
这样其实也能猜出来,这个注解背后有个Annotation Processor在做处理,如果你没了解过,可以看下:
通过该文会对一个编译时注解的运行流程和基本API有一定的掌握,文中也会对tinker该部分的源码做解析。
上述,就完成了tinker的初始化,那么调用loadPatch的时机,我们直接在Activity中添加一个Button设置:
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
public void loadPatch(View view) {
TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),
Environment.getExternalStorageDirectory().getAbsolutePath() + “/patch_signed.apk”);
}
}
我们会将patch文件直接push到sdcard根目录;
所以一定要注意:添加SDCard权限,如果你是6.x以上的系统,自己添加上授权代码,或者手动在设置页面打开SDCard读写权限。
除以以外,有个特殊的地方就是tinker需要在AndroidManifest.xml
中指定TINKER_ID。
<meta-data
android:name=“TINKER_ID”
android:value=“tinker_id_6235657” />
//…
到此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修改为与本例一致:
大致的文件结构如下:
可以在tinker-patch-cli中提取,或者直接下载文末的例子。
上述介绍了patch生成的命令,最后需要注意的就是,在第一次打出apk的时候,保留下生成的mapping文件,在/build/outputs/mapping/release/mapping.txt
。
可以copy到与proguard-rules.pro
同目录,同时在第二次打修复包的时候,在proguard-rules.pro
中添加上:
-applymapping mapping.txt
保证后续的打包与线上包使用的是同一个mapping文件。
tinker本身的混淆相关配置,可以参考:
如果,你对该部分描述不了解,可以直接查看源码即可。
测试
首先随便生成一个apk(API、混淆相关已经按照上述引入),安装到手机或者模拟器上。
然后,copy出mapping.txt文件,设置applymapping
,修改代码,再次打包,生成new.apk。
两次的apk,可以通过命令行指令去生成patch文件。
如果你下载本例,命令需要在[该目录]下执行。
最终会在output文件夹中生成产物:
我们直接将patch_signed.apk push到sdcard,点击loadpatch,一定要观察命令行是否成功。
本例修改了title。
点击loadPatch,观察log,如果成功,应用默认为重启,然后再次启动即可达到修复效果。
到这里命令行的方式就介绍完了,和Andfix的接入的方式基本上是一样的。
值得注意的是:该例仅展示了基本的接入,对于tinker的各种配置信息,还是需要去读tinker的文档(如果你确定要使用)tinker-wiki。
(2)gradle接入
gradle接入的方式应该算是主流的方式,所以tinker也直接给出了例子,单独将该tinker-sample-android以project方式引入即可。
引入之后,可以查看其接入API的方式,以及相关配置。
在你每次build时,会在build/bakApk
下生成本地打包的apk,R文件,以及mapping文件。
如果你需要生成patch文件,可以通过:
./gradlew tinkerPatchRelease // 或者 ./gradlew tinkerPatchDebug
生成。
生成目录为:build/outputs/tinkerPatch
需要注意的是,需要在app/build.gradle中设置相比较的apk(即old.apk,本次为new.apk),
ext {
tinkerEnabled = true
//old apk file to build patch apk
tinkerOldApkPath = “${bakPath}/old.apk”
//proguard mapping file to build patch apk
tinkerApplyMappingPath = “${bakPath}/old-mapping.txt”
}
提供的例子,基本上展示了tinker的自定义扩展的方式,具体还可以参考:
所以,如果你使用命令行方式接入,也不要忘了学习下其支持哪些扩展。
三、Application是如何编译时生成的
从注释和命名上看:
//可选,用于生成application类
provided(‘com.tencent.tinker:tinker-android-anno:1.7.7’)
明显是该库,其结构如下:
典型的编译时注解的项目,源码见tinker-android-anno。
入口为com.tencent.tinker.anno.AnnotationProcessor
,可以在该services/javax.annotation.processing.Processor
文件中找到处理类全路径。
再次建议,如果你不了解,简单阅读下Android 如何编写基于编译时注解的项目该文。
直接看AnnotationProcessor的process
方法:
@Override
public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
processDefaultLifeCycle(roundEnv.getElementsAnnotatedWith(DefaultLifeCycle.class));
return true;
}
直接调用了processDefaultLifeCycle:
private void processDefaultLifeCycle(Set<? extends Element> elements) {
// 被注解DefaultLifeCycle标识的对象
for (Element e : elements) {
// 拿到DefaultLifeCycle注解对象
DefaultLifeCycle ca = e.getAnnotation(DefaultLifeCycle.class);
String lifeCycleClassName = ((TypeElement) e).getQualifiedName().toString();
String lifeCyclePackageName = lifeCycleClassName.substring(0, lifeCycleClassName.lastIndexOf(‘.’));
lifeCycleClassName = lifeCycleClassName.substring(lifeCycleClassName.lastIndexOf(‘.’) + 1);
String applicationClassName = ca.application();
if (applicationClassName.startsWith(“.”)) {
applicationClassName = lifeCyclePackageName + applicationClassName;
}
String applicationPackageName = applicationClassName.substring(0, applicationClassName.lastIndexOf(‘.’));
applicationClassName = applicationClassName.substring(applicationClassName.lastIndexOf(‘.’) + 1);
String loaderClassName = ca.loaderClass();
if (loaderClassName.startsWith(“.”)) {
loaderClassName = lifeCyclePackageName + loaderClassName;
}
// /TinkerAnnoApplication.tmpl
final InputStream is = AnnotationProcessor.class.getResourceAsStream(APPLICATION_TEMPLATE_PATH);
final Scanner scanner = new Scanner(is);
final String template = scanner.useDelimiter(“\A”).next();
final String fileContent = template
.replaceAll(“%PACKAGE%”, applicationPackageName)
.replaceAll(“%APPLICATION%”, applicationClassName)
.replaceAll(“%APPLICATION_LIFE_CYCLE%”, lifeCyclePackageName + “.” + lifeCycleClassName)
.replaceAll(“%TINKER_FLAGS%”, “” + ca.flags())
.replaceAll(“%TINKER_LOADER_CLASS%”, “” + loaderClassName)
.replaceAll(“%TINKER_LOAD_VERIFY_FLAG%”, “” + ca.loadVerifyFlag());
JavaFileObject fileObject = processingEnv.getFiler().createSourceFile(applicationPackageName + “.” + applicationClassName);
processingEnv.getMessager().printMessage(Diagnostic.Kind.NOTE, "Creating " + fileObject.toUri());
Writer writer = fileObject.openWriter();
PrintWriter pw = new PrintWriter(writer);
pw.print(fileContent);
pw.flush();
writer.close();
}
}
代码比较简单,可以分三部分理解:
-
步骤1:首先找到被DefaultLifeCycle标识的Element(为类对象TypeElement),得到该对象的包名,类名等信息,然后通过该对象,拿到
@DefaultLifeCycle
对象,获取该注解中声明属性的值。 -
步骤2:读取一个模板文件,读取为字符串,将各个占位符通过步骤1中的值替代。
-
步骤3:通过JavaFileObject将替换完成的字符串写文件,其实就是本例中的Application对象。
我们看一眼模板文件:
package %PACKAGE%;
import com.tencent.tinker.loader.app.TinkerApplication;
/**
-
Generated application for tinker life cycle
*/
public class %APPLICATION% extends TinkerApplication {
public %APPLICATION%() {
super(%TINKER_FLAGS%, “%APPLICATION_LIFE_CYCLE%”, “%TINKER_LOADER_CLASS%”, %TINKER_LOAD_VERIFY_FLAG%);
}
}
对应我们的SimpleTinkerInApplicationLike
,
@DefaultLifeCycle(application = “.SimpleTinkerInApplication”,
flags = ShareConstants.TINKER_ENABLE_ALL,
loadVerifyFlag = false)
public class SimpleTinkerInApplicationLike extends ApplicationLike {}
主要就几个占位符:
-
包名,如果application属性值以点开始,则同包;否则则截取
-
类名,application属性值中的类名
-
%TINKER_FLAGS%对应flags
-
%APPLICATION_LIFE_CYCLE%,编写的ApplicationLike的全路径
-
“%TINKER_LOADER_CLASS%”,这个值我们没有设置,实际上对应
@DefaultLifeCycle
的loaderClass属性,默认值为com.tencent.tinker.loader.TinkerLoader
-
%TINKER_LOAD_VERIFY_FLAG%对应loadVerifyFlag
于是最终生成的代码为:
/**
-
Generated application for tinker life cycle
*/
public class SimpleTinkerInApplication extends TinkerApplication {
public SimpleTinkerInApplication() {
super(7, “com.zhy.tinkersimplein.SimpleTinkerInApplicationLike”, “com.tencent.tinker.loader.TinkerLoader”, false);
}
}
tinker这么做的目的,文档上是这么说的:
为了减少错误的出现,推荐使用Annotation生成Application类。
这样大致了解了Application是如何生成的。
接下来我们大致看一下tinker的原理。
四、原理
tinker贴了一张大致的原理图。
可以看出:
tinker将old.apk和new.apk做了diff,拿到patch.dex,然后将patch.dex与本机中apk的classes.dex做了合并,生成新的classes.dex,运行时通过反射将合并后的dex文件放置在加载的dexElements数组的前面。
运行时替代的原理,其实和Qzone的方案差不多,都是去反射修改dexElements。
两者的差异是:Qzone是直接将patch.dex插到数组的前面;而tinker是将patch.dex与app中的classes.dex合并后的全量dex插在数组的前面。
tinker这么做的目的还是因为Qzone方案中提到的CLASS_ISPREVERIFIED
的解决方案存在问题;而tinker相当于换个思路解决了该问题。
接下来我们就从代码中去验证该原理。
本片文章源码分析的两条线:
-
应用启动时,从默认目录加载合并后的classes.dex
-
patch下发后,合成classes.dex至目标目录
五、源码分析
(1)加载patch
加载的代码实际上在生成的Application中调用的,其父类为TinkerApplication,在其attachBaseContext中辗转会调用到loadTinker()方法,在该方法内部,反射调用了TinkerLoader的tryLoad方法。
@Override
public Intent tryLoad(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag) {
Intent resultIntent = new Intent();
long begin = SystemClock.elapsedRealtime();
tryLoadPatchFilesInternal(app, tinkerFlag, tinkerLoadVerifyFlag, resultIntent);
long cost = SystemClock.elapsedRealtime() - begin;
ShareIntentUtil.setIntentPatchCostTime(resultIntent, cost);
return resultIntent;
}
tryLoadPatchFilesInternal中会调用到loadTinkerJars
方法:
private void tryLoadPatchFilesInternal(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag, Intent resultIntent) {
// 省略大量安全性校验代码
if (isEnabledForDex) {
//tinker/patch.info/patch-641e634c/dex
boolean dexCheck = TinkerDexLoader.checkComplete(patchVersionDirectory, securityCheck, resultIntent);
if (!dexCheck) {
//file not found, do not load patch
Log.w(TAG, “tryLoadPatchFiles:dex check fail”);
return;
}
}
//now we can load patch jar
if (isEnabledForDex) {
boolean loadTinkerJars = TinkerDexLoader.loadTinkerJars(app, tinkerLoadVerifyFlag, patchVersionDirectory, resultIntent, isSystemOTA);
if (!loadTinkerJars) {
Log.w(TAG, “tryLoadPatchFiles:onPatchLoadDexesFail”);
return;
}
}
}
TinkerDexLoader.checkComplete主要是用于检查下发的meta文件中记录的dex信息(meta文件,可以查看生成patch的产物,在assets/dex-meta.txt),检查meta文件中记录的dex文件信息对应的dex文件是否存在,并把值存在TinkerDexLoader的静态变量dexList中。
TinkerDexLoader.loadTinkerJars传入四个参数,分别为application,tinkerLoadVerifyFlag(注解上声明的值,传入为false),patchVersionDirectory当前version的patch文件夹,intent,当前patch是否仅适用于art。
@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
public static boolean loadTinkerJars(Application application, boolean tinkerLoadVerifyFlag,
String directory, Intent intentResult, boolean isSystemOTA) {
PathClassLoader classLoader = (PathClassLoader) TinkerDexLoader.class.getClassLoader();
String dexPath = directory + “/” + DEX_PATH + “/”;
File optimizeDir = new File(directory + “/” + DEX_OPTIMIZE_PATH);
ArrayList legalFiles = new ArrayList<>();
final boolean isArtPlatForm = ShareTinkerInternals.isVmArt();
for (ShareDexDiffPatchInfo info : dexList) {
//for dalvik, ignore art support dex
if (isJustArtSupportDex(info)) {
continue;
}
String path = dexPath + info.realName;
File file = new File(path);
legalFiles.add(file);
}
// just for art
if (isSystemOTA) {
parallelOTAResult = true;
parallelOTAThrowable = null;
Log.w(TAG, “systemOTA, try parallel oat dexes!!!”);
TinkerParallelDexOptimizer.optimizeAll(
legalFiles, optimizeDir,
new TinkerParallelDexOptimizer.ResultCallback() {
}
);
SystemClassLoaderAdder.installDexes(application, classLoader, optimizeDir, legalFiles);
return true;
}
找出仅支持art的dex,且当前patch是否仅适用于art时,并行去loadDex。
关键是最后的installDexes:
@SuppressLint(“NewApi”)
public static void installDexes(Application application, PathClassLoader loader, File dexOptDir, List files)
throws Throwable {
if (!files.isEmpty()) {
ClassLoader classLoader = loader;
if (Build.VERSION.SDK_INT >= 24) {
classLoader = AndroidNClassLoader.inject(loader, application);
}
//because in dalvik, if inner class is not the same classloader with it wrapper class.
//it won’t fail at dex2opt
if (Build.VERSION.SDK_INT >= 23) {
V23.install(classLoader, files, dexOptDir);
} else if (Build.VERSION.SDK_INT >= 19) {
V19.install(classLoader, files, dexOptDir);
} else if (Build.VERSION.SDK_INT >= 14) {
V14.install(classLoader, files, dexOptDir);
} else {
V4.install(classLoader, files, dexOptDir);
}
//install done
sPatchDexCount = files.size();
Log.i(TAG, "after loaded classloader: " + classLoader + “, dex size:” + sPatchDexCount);
if (!checkDexInstall(classLoader)) {
//reset patch dex
SystemClassLoaderAdder.uninstallPatchDex(classLoader);
throw new TinkerRuntimeException(ShareConstants.CHECK_DEX_INSTALL_FAIL);
}
}
}
这里实际上就是根据不同的系统版本,去反射处理dexElements。
我们看一下V19的实现(主要我看了下本机只有个22的源码~):
private static final class V19 {
private static void install(ClassLoader loader, List additionalClassPathEntries,
File optimizedDirectory)
throws IllegalArgumentException, IllegalAccessException,
NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException {
Field pathListField = ShareReflectUtil.findField(loader, “pathList”);
Object dexPathList = pathListField.get(loader);
ArrayList suppressedExceptions = new ArrayList();
ShareReflectUtil.expandFieldArray(dexPathList, “dexElements”, makeDexElements(dexPathList,
new ArrayList(additionalClassPathEntries), optimizedDirectory,
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)

总结
可以看出,笔者的工作学习模式便是由以下 「六个要点」 组成:
❝ 多层次的工作/学习计划 + 番茄工作法 + 定额工作法 + 批处理 + 多任务并行 + 图层工作法❞
希望大家能将这些要点融入自己的工作学习当中,我相信一定会工作与学习地更富有成效。
下面是我学习用到的一些书籍学习导图,以及系统的学习资料。每一个知识点,都有对应的导图,学习的资料,视频,面试题目。
**如:我需要学习 **Flutter的知识。(大家可以参考我的学习方法)
- Flutter 的思维导图(无论学习什么,有学习路线都会事半功倍)
- Flutter进阶学习全套手册
- Flutter进阶学习全套视频
大概就上面这几个步骤,这样学习不仅高效,而且能系统的学习新的知识。
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!**
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
[外链图片转存中…(img-dHw0uVYI-1713151277533)]
[外链图片转存中…(img-C86CKgQa-1713151277533)]
[外链图片转存中…(img-mADGeVji-1713151277533)]
[外链图片转存中…(img-ynrnji1j-1713151277534)]
[外链图片转存中…(img-5enUR0TD-1713151277534)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)

总结
可以看出,笔者的工作学习模式便是由以下 「六个要点」 组成:
❝ 多层次的工作/学习计划 + 番茄工作法 + 定额工作法 + 批处理 + 多任务并行 + 图层工作法❞
希望大家能将这些要点融入自己的工作学习当中,我相信一定会工作与学习地更富有成效。
下面是我学习用到的一些书籍学习导图,以及系统的学习资料。每一个知识点,都有对应的导图,学习的资料,视频,面试题目。
**如:我需要学习 **Flutter的知识。(大家可以参考我的学习方法)
- Flutter 的思维导图(无论学习什么,有学习路线都会事半功倍)
[外链图片转存中…(img-5ign665n-1713151277534)]
- Flutter进阶学习全套手册
[外链图片转存中…(img-uoYs1Vkn-1713151277534)]
- Flutter进阶学习全套视频
[外链图片转存中…(img-POAaDlza-1713151277535)]
大概就上面这几个步骤,这样学习不仅高效,而且能系统的学习新的知识。
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!