2024年安卓最新带你了解腾讯开源的多渠道打包技术 VasDolly源码解析(2)，小米面试java

最新推荐文章于 2024-07-11 15:08:02 发布

2401_84556604

最新推荐文章于 2024-07-11 15:08:02 发布

阅读量288

点赞数 5

文章标签： android 面试学习

本文链接：https://blog.csdn.net/2401_84556604/article/details/138950035

版权

最后

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司19年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

【算法合集】

【延伸Android必备知识点】

【Android部分高级架构视频学习资源】

**Android精讲视频领取学习后更加是如虎添翼！**进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

在看源码之前，我们也可以使用二进制编辑器打开打包好的Apk，看末尾的几个字节，如图：

这里写图片描述

咱们逆着看：

首先读取8个字节，对应一个特殊字符串“ltlovezh”
往前两个字节为02 00，对应渠道信息长度，实际值为2.
再往前读取2个字节为63 31，对照ASCII表，即可知为c1

这样我们就读取除了渠道信息为：c1。

这么看代码也不复杂，最后看一眼代码吧：

代码中通过ChannelReaderUtil.getChannel获取渠道信息：

public static String getChannel(Context context) {

if (mChannelCache == null) {

String channel = getChannelByV2(context);

if (channel == null) {

channel = getChannelByV1(context);

}

mChannelCache = channel;

}

return mChannelCache;

}

我们只看v1，根据调用流程，最终会到：

V1SchemeUtil.readChannel方法：

public static String readChannel(File file) throws Exception {

RandomAccessFile raf = null;

try {

raf = new RandomAccessFile(file, “r”);

long index = raf.length();

byte[] buffer = new byte[ChannelConstants.V1_MAGIC.length];

index -= ChannelConstants.V1_MAGIC.length;

raf.seek(index);

raf.readFully(buffer);

// whether magic bytes matched

if (isV1MagicMatch(buffer)) {

index -= ChannelConstants.SHORT_LENGTH;

raf.seek(index);

// read channel length field

int length = readShort(raf);

if (length > 0) {

index -= length;

raf.seek(index);

// read channel bytes

byte[] bytesComment = new byte[length];

raf.readFully(bytesComment);

return new String(bytesComment, ChannelConstants.CONTENT_CHARSET);

} else {

throw new Exception(“zip channel info not found”);

}

} else {

throw new Exception(“zip v1 magic not found”);

}

} finally {

if (raf != null) {

raf.close();

}

使用了RandomAccessFile，可以很方便的使用seek指定到具体的字节处。注意第一次seek的目标是length - magic.length，即对应我们的读取魔数，读取到比对是否相同。

如果相同，再往前读取SHORT_LENGTH = 2个字节，读取为short类型，即为渠道信息所占据的字节数。

再往前对去对应的长度，转化为String，即为渠道信息，与我们前面的分析一模一样。

ok，读取始终是简单的。

后面还要看如何写入以及如何自动化。

3.2 写入v1渠道信息

写入渠道信息，先思考下，有个apk，需要写入渠道信息，需要几步：

找到合适的写入位置
写入渠道信息、写入长度、写入魔数

好像唯一的难点就是找到合适的位置。

但是找到这个合适的位置，又涉及到zip文件的格式内容了。

大致讲解下：

zip的末尾有一个数据库，这个数据块我们叫做EOCD块，分为4个部分：

4字节，固定值0x06054b50
16个字节，不在乎其细节
2个字节，注释长度
N个字节，注释内容

知道这个规律后，我们就可以通过匹配1中固定值来确定对应区域，然后seek到注释处。

可能99.99%的apk默认是不包含注释内容的，所以直接往前seek 22个字节，读取4个字节做下匹配即可。

但是如果已经包含了注释内容，就比较难办了。很多时候，我们会正向从头开始按协议读取zip文件格式，直至到达目标区域。

不过VasDolly的做法是，从文件末尾seek 22 ~ 文件size - 22，逐一匹配。

我们简单看下代码：

public static void writeChannel(File file, String channel) throws Exception {

byte[] comment = channel.getBytes(ChannelConstants.CONTENT_CHARSET);

Pair<ByteBuffer, Long> eocdAndOffsetInFile = getEocd(file);

if (eocdAndOffsetInFile.getFirst().remaining() == ZipUtils.ZIP_EOCD_REC_MIN_SIZE) {

System.out.println(“file : " + file.getAbsolutePath() + " , has no comment”);

RandomAccessFile raf = new RandomAccessFile(file, “rw”);

//1.locate comment length field

raf.seek(file.length() - ChannelConstants.SHORT_LENGTH);

//2.write zip comment length (content field length + length field length + magic field length)

writeShort(comment.length + ChannelConstants.SHORT_LENGTH + ChannelConstants.V1_MAGIC.length, raf);

//3.write content

raf.write(comment);

//4.write content length

writeShort(comment.length, raf);

//5. write magic bytes

raf.write(ChannelConstants.V1_MAGIC);

raf.close();

} else {

System.out.println(“file : " + file.getAbsolutePath() + " , has comment”);

if (containV1Magic(file)) {

try {

String existChannel = readChannel(file);

if (existChannel != null){

file.delete();

throw new ChannelExistException("file : " + file.getAbsolutePath() + " has a channel : " + existChannel + “, only ignore”);

}

}catch (Exception e){

e.printStackTrace();

}

int existCommentLength = ZipUtils.getUnsignedInt16(eocdAndOffsetInFile.getFirst(), ZipUtils.ZIP_EOCD_REC_MIN_SIZE - ChannelConstants.SHORT_LENGTH);

int newCommentLength = existCommentLength + comment.length + ChannelConstants.SHORT_LENGTH + ChannelConstants.V1_MAGIC.length;

RandomAccessFile raf = new RandomAccessFile(file, “rw”);

//1.locate comment length field

raf.seek(eocdAndOffsetInFile.getSecond() + ZipUtils.ZIP_EOCD_REC_MIN_SIZE - ChannelConstants.SHORT_LENGTH);

//2.write zip comment length (existCommentLength + content field length + length field length + magic field length)

writeShort(newCommentLength, raf);

//3.locate where channel should begin

raf.seek(eocdAndOffsetInFile.getSecond() + ZipUtils.ZIP_EOCD_REC_MIN_SIZE + existCommentLength);

//4.write content

raf.write(comment);

//5.write content length

writeShort(comment.length, raf);

//6.write magic bytes

raf.write(ChannelConstants.V1_MAGIC);

raf.close();

}

getEocd(file)的的返回值是Pair<ByteBuffer, Long>，多数情况下first为EOCD块起始位置到结束后的内容；second为EOCD块起始位置。

if为apk本身无comment的情况，这种方式属于大多数情况，从文件末尾，移动2字节，该2字节为注释长度，然后组装注释内容，重新计算注释长度，重新写入注释长度，再写入注释内容，最后写入MAGIC魔数。

else即为本身存在comment的情况，首先读取原有注释长度，然后根据渠道等信息计算出先的注释长度，写入。

3.3 gradle自动化

最后我们看下，是如何做到输入./gradle channelRelease就实现所有渠道包的生成呢。

这里主要就是解析gradle plugin了，如果你还没有自定义过plugin，非常值得参考。

代码主要在VasDolly/plugin这个module.

入口代码为ApkChannelPackagePlugin的apply方法。

主要代码：

project.afterEvaluate {

project.android.applicationVariants.all { variant ->

def variantOutput = variant.outputs.first();

def dirName = variant.dirName;

def variantName = variant.name.capitalize();

Task channelTask = project.task(“channel${variantName}”, type: ApkChannelPackageTask) {

mVariant = variant;

mChannelExtension = mChannelConfigurationExtension;

mOutputDir = new File(mChannelConfigurationExtension.baseOutputDir, dirName)

mChannelList = mChanneInfolList

dependsOn variant.assemble

}

为每个variantName添加了一个task，并且依赖于variant.assemble。

也就是说，当我们执行./gradlew channelRelease时，会先执行assemble，然后对产物apk做后续操作。

重点看这个Task，ApkChannelPackageTask。

执行代码为：

@TaskAction

public void channel() {

//1.check all params

checkParameter();

//2.check signingConfig , determine channel package mode

checkSigningConfig()

//3.generate channel apk

generateChannelApk();

}

注释也比较清晰，首先channelFile、baseOutputDir等相关参数。接下来校验signingConfig中v2SigningEnabled与v1SigningEnabled，确定使用V1还是V2 mode，我们上文中将v2SigningEnabled设置为了false，所以这里为V1_MODE。

最后就是生成渠道apk了：

void generateV1ChannelApk() {

// 省略了一些代码

mChannelList.each { channel ->

String apkChannelName = getChannelApkName(channel)

println “generateV1ChannelApk , channel = ${channel} , apkChannelName = ${apkChannelName}”

File destFile = new File(mOutputDir, apkChannelName)

copyTo(mBaseApk, destFile)

V1SchemeUtil.writeChannel(destFile, channel)

if (!mChannelExtension.isFastMode){

//1. verify channel info

if (V1SchemeUtil.verifyChannel(destFile, channel)) {

println(“generateV1ChannelApk , ${destFile} add channel success”)

} else {

throw new GradleException(“generateV1ChannelApk , ${destFile} add channel failure”)

}

//2. verify v1 signature

if (VerifyApk.verifyV1Signature(destFile)) {

println “generateV1ChannelApk , after add channel , apk ${destFile} v1 verify success”

} else {

throw new GradleException(“generateV1ChannelApk , after add channel , apk ${destFile} v1 verify failure”)

}

println(“------ ${project.name}:$ {name} generate v1 channel apk , end ------”)

}

很简单，遍历channelList，然后调用V1SchemeUtil.writeChannel，该方法即我们上文解析过的方法。

如果fastMode设置为false，还会读取出渠道再做一次强校验；以及会通过apksig做对签名进行校验。

ok，到这里我们就完全剖析了基于V1的快速签名的全过程。

接下来我们看基于v2的快速签名方案。

四、基于V2的快速签名方案

关于V2签名的产生原因，原理以及安装时的校验过程可以参考 VasDolly实现原理。

我这里就抛开细节，尽可能让大家能明白整个过程，v2签名的原理可以简单理解为：

我们的apk其实是个zip，我们可以理解为3块：块1+块2+块3
签名让我们的apk变成了4部分：块1+签名块+块2+块3

在这个签名块的某个区域，允许我们写一些key-value对，我们就将渠道信息写在这个地方。

这里有一个问题，v2不是说是对整个apk进行校验吗？为什么还能够让我们在apk中插入这样的信息呢？

因为在校验过程中，对于签名块是不校验的（细节上由于我们插入了签名块，某些偏移量会变化，但是在校验前，Android系统会先重置偏移量），而我们的渠道信息刚好写在这个签名块中。

好了，细节一会看代码。

4.1 读取渠道信息

写入渠道信息，根据我们上述的分析，流程应该大致如下：

找到签名块
找到签名块中的key-value的地方
读取出所有的key-value，找到我们特定的key对应的渠道信息

这里我们不按照整个代码流程走了，太长了，一会看几段关键代码。

4.1.1 如何找到签名块

我们的apk现在格式是这样的：

块1+签名块+块2+块3

其中块3称之为EOCD，现在必须要展示下其内部的数据结构了：

这里写图片描述

图片来自：参考

在V1的相关代码中，我们已经可以定位到EOCD的位置了，然后往下16个字节即可拿到Offset of start of central directory即为块2开始的位置，也为签名块末尾的位置。

块2 再往前，就可以获取到我们的签名块了。

我们先看一段代码，定位到块2 的开始位置。

V2SchemeUtil

public static ByteBuffer getApkSigningBlock(File channelFile) throws ApkSignatureSchemeV2Verifier.SignatureNotFoundException, IOException {

RandomAccessFile apk = new RandomAccessFile(channelFile, “r”);

//1.find the EOCD

Pair<ByteBuffer, Long> eocdAndOffsetInFile = ApkSignatureSchemeV2Verifier.getEocd(apk);

ByteBuffer eocd = eocdAndOffsetInFile.getFirst();

long eocdOffset = eocdAndOffsetInFile.getSecond();

if (ZipUtils.isZip64EndOfCentralDirectoryLocatorPresent(apk, eocdOffset)) {

throw new ApkSignatureSchemeV2Verifier.SignatureNotFoundException(“ZIP64 APK not supported”);

}

//2.find the APK Signing Block. The block immediately precedes the Central Directory.

long centralDirOffset = ApkSignatureSchemeV2Verifier.getCentralDirOffset(eocd, eocdOffset);//通过eocd找到中央目录的偏移量

//3. find the apk V2 signature block

Pair<ByteBuffer, Long> apkSignatureBlock =

ApkSignatureSchemeV2Verifier.findApkSigningBlock(apk, centralDirOffset);//找到V2签名块的内容和偏移量

return apkSignatureBlock.getFirst();

}

首先发现EOCD块，这个前面我们已经分析了。

然后寻找到签名块的位置，上面我们已经分析了只要往下移动16字节即可到达签名块末尾，那么看下ApkSignatureSchemeV2Verifier.getCentralDirOffset代码，最终调用：

public static long getZipEocdCentralDirectoryOffset(ByteBuffer zipEndOfCentralDirectory) {

assertByteOrderLittleEndian(zipEndOfCentralDirectory);

return getUnsignedInt32(

zipEndOfCentralDirectory,

zipEndOfCentralDirectory.position() + 16);

}

到这里我们已经可以到达签名块末尾了。

我们继续看findApkSigningBlock找到V2签名块的内容和偏移量：

public static Pair<ByteBuffer, Long> findApkSigningBlock(

RandomAccessFile apk, long centralDirOffset)

throws IOException, SignatureNotFoundException {

ByteBuffer footer = ByteBuffer.allocate(24);

footer.order(ByteOrder.LITTLE_ENDIAN);

apk.seek(centralDirOffset - footer.capacity());

apk.readFully(footer.array(), footer.arrayOffset(), footer.capacity());

if ((footer.getLong(8) != APK_SIG_BLOCK_MAGIC_LO)

|| (footer.getLong(16) != APK_SIG_BLOCK_MAGIC_HI)) {

throw new SignatureNotFoundException(

“No APK Signing Block before ZIP Central Directory”);

}

// Read and compare size fields

long apkSigBlockSizeInFooter = footer.getLong(0);

int totalSize = (int) (apkSigBlockSizeInFooter + 8);

long apkSigBlockOffset = centralDirOffset - totalSize;

ByteBuffer apkSigBlock = ByteBuffer.allocate(totalSize);

apkSigBlock.order(ByteOrder.LITTLE_ENDIAN);

apk.seek(apkSigBlockOffset);

apk.readFully(apkSigBlock.array(), apkSigBlock.arrayOffset(), apkSigBlock.capacity());

return Pair.create(apkSigBlock, apkSigBlockOffset);

}

这里我们需要介绍下签名块相关信息了：

这里写图片描述

图片来自：参考

中间的不包含此8字节，值得是该ID-VALUE的size值不包含此8字节。

首先往前读取24个字节，即读取了签名块大小64bits+魔数128bits；然后会魔数信息与实际的魔数对比。

接下来读取8个字节为apkSigBlockSizeInFooter，即签名块大小。

然后+8加上上图顶部的8个字节。

最后将整个签名块读取到ByteBuffer中返回。

此时我们已经有了签名块的所有数据了。

接下来我们要读取这个签名块中所有的key-value对！

V2SchemeUtil

public static Map<Integer, ByteBuffer> getAllIdValue(ByteBuffer apkSchemeBlock) {

ApkSignatureSchemeV2Verifier.checkByteOrderLittleEndian(apkSchemeBlock);

ByteBuffer pairs = ApkSignatureSchemeV2Verifier.sliceFromTo(apkSchemeBlock, 8, apkSchemeBlock.capacity() - 24);

Map<Integer, ByteBuffer> idValues = new LinkedHashMap<Integer, ByteBuffer>(); // keep order

int entryCount = 0;

while (pairs.hasRemaining()) {

entryCount++;

long lenLong = pairs.getLong();

int len = (int) lenLong;

int nextEntryPos = pairs.position() + len;

int id = pairs.getInt();

idValues.put(id, ApkSignatureSchemeV2Verifier.getByteBuffer(pairs, len - 4));//4 is length of id

if (id == ApkSignatureSchemeV2Verifier.APK_SIGNATURE_SCHEME_V2_BLOCK_ID) {

System.out.println("find V2 signature block Id : " + ApkSignatureSchemeV2Verifier.APK_SIGNATURE_SCHEME_V2_BLOCK_ID);

}

pairs.position(nextEntryPos);

}

return idValues;

}

首先读取8到capacity() - 24中的内容，即所有的id-value集合。

然后进入while循环，读取一个个key-value存入idValues，我们看下循环体内：

pairs.getLong，读取8个字节，即此id-value块的size
然后pairs.getInt，读取4个字节，即可得到id
size - 4 中包含的内容即为value

如此循环，得到所有的idValues。

有了所有的idValues，然后根据特定的id，即可获取我们的渠道信息了。

即：

ChannelReader

public static String getChannel(File channelFile) {

System.out.println("try to read channel info from apk : " + channelFile.getAbsolutePath());

return IdValueReader.getStringValueById(channelFile, ChannelConstants.CHANNEL_BLOCK_ID);

}

这样我们就走通了读取的逻辑。

我替大家总结下：

根据zip的格式，先定位到EOCD的开始位置
然后根据EOCD中的内容定位到签名块末尾
然后根据签名块中的数据格式，逐一读取出id-values
我们的渠道信息与一个特点的id映射，读取出即可

4.2 写入渠道信息

先思考下，现在要正视的是，目前到我们这里已经是v2签名打出的包了。那么我们应该找到签名块中的id-values部分，把我们的渠道信息插入进去。

大致的方式可以为：

文末

很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从那里入手去学习，对此我整理了一些资料，需要的可以免费分享给大家

这里笔者分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

【视频教程】

天道酬勤，只要你想，大厂offer并不是遥不可及！希望本篇文章能为你带来帮助，如果有问题，请在评论区留言。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

lConstants.CHANNEL_BLOCK_ID);

}

这样我们就走通了读取的逻辑。

我替大家总结下：

根据zip的格式，先定位到EOCD的开始位置
然后根据EOCD中的内容定位到签名块末尾
然后根据签名块中的数据格式，逐一读取出id-values
我们的渠道信息与一个特点的id映射，读取出即可

4.2 写入渠道信息

先思考下，现在要正视的是，目前到我们这里已经是v2签名打出的包了。那么我们应该找到签名块中的id-values部分，把我们的渠道信息插入进去。

大致的方式可以为：

文末

[外链图片转存中…(img-YOI7EbhW-1715825918834)]

[外链图片转存中…(img-d2wFAtfU-1715825918834)]

【视频教程】

[外链图片转存中…(img-iMB7cbsq-1715825918835)]

天道酬勤，只要你想，大厂offer并不是遥不可及！希望本篇文章能为你带来帮助，如果有问题，请在评论区留言。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

2401_84556604

关注

5
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
2024年安卓最新带你了解腾讯开源的多渠道打包技术 VasDolly源码解析(2)，小米面试java

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含，由于篇幅有限，这里以图片的形式给大家展示一部分。还有。
复制链接

扫一扫