零碎总结-1

ZipFile 考虑内部存储方式，一个文件对应一个压缩实体，那么就要考虑每个实体之间如何分割，要么用固定的标志符，但是必须保证不能有冲突较为麻烦，使用Central Directory，由多个File header组成，每个File header都保存一个文件实体的偏移，文件最后由End of central directory结束。由于包含信息较少，可控，解决了文件分隔的问题。
当然也能够完成，在不用解压缩文件的基础上，访问压缩文件的名字。

v1方案中：常用的有meta-info 加入文件，或者在zip文件的末尾，zip comment中加入信息。
在读取的时候要通过反射获取到sourceDir之类的。从而获取到对应的文件。

在美团提供的新一代打包方案中，解决v2签名的问题。

1. 找到一个不触发校验的区域。----zip entry ---签名区---central Directory---End of Central Directory
2. 签名区有自己的格式，假定通过central Directory的边界可以找到找到签名区中协议上可以扩充的字段 :一组ID-Value ID-value (TLV格式 8字节的长度标示＋4字节的ID＋它的负载组成) android在获取的时候已经去除了头尾占用的内存
   ByteBuffer pairs = sliceFromTo(apkSigningBlock, 8, apkSigningBlock.capacity() - 24);
   保留了基本内容
   如：8字节表示长度 先读取获取len，然后读取4字节，匹配标志，匹配成功读取，
3. 确定扩充id-value的方案
   4.读取id-value

https://tech.meituan.com/2017/01/13/android-apk-v2-signature-scheme.html

参考：https://www.jianshu.com/p/da1de87ecb8e 记录一下：
对于 android.content.pm.ApplicationInfo类，Android开发者应该都不陌生，通过这个类我们可以获取应用的如下常用属性，这些属性通常来自于AndroidManifest中。

backupAgentName 备份的类
className 应用程序类
processName 进程名
dataDir 数据所在目录
sourceDir 应用apk所在目录
publicSourceDir 应用apk所在目录
nativeLibraryDir 本地lib库目录(c/c++库)
enabled 是否启用应用所有组件，默认true
flags 应用关联标志
targetSdkVersion 最小SDK版本
descriptionRes 应用描述资源
theme 主题资源

如：

        //getApplicationInfo().dataDir--->/data/data/me.febsky.debug
        Log.d("Q_M", "getApplicationInfo().dataDir--->" + getApplicationInfo().dataDir);
        //getApplicationInfo().publicSourceDir--->/data/app/me.febsky.debug-1/base.apk
        Log.d("Q_M", "getApplicationInfo().publicSourceDir--->" + getApplicationInfo().publicSourceDir);
        //getApplicationInfo().sourceDir--->/data/app/me.febsky.debug-1/base.apk  获取当前应用的Apk的存放目录代码：
        Log.d("Q_M", "getApplicationInfo().sourceDir--->" + getApplicationInfo().sourceDir);

V- Layout

dns被劫持首要考虑的是httpdns方案，那么httpdns的android实现时什么样的？ 大概考虑到采用http来承接，发送到服务端，服务端再做解析，那么服务端如何解析保证准确度呢？

https://blog.csdn.net/u012455213/article/details/78281026?utm_source=blogxgwz9

android hook native 代码：

DNS异常：
Dns实现中通过getHostByName等函数获取ip地址，这一块出现异常会有提示，那么可以转而使用其他方案，或者如果使用okhttp的时候自定义Dns解析器，云服务通常会遇到cname问题，那么cname对应到具体请求的体现是什么样子呢？
DNS查找的网络过程，通过ISP接入网络，在发起dns会先查找浏览器缓存，本地配置文件/etc/localhost 或者本地网络缓存，一般来说会向ISPDns服务器发起请求，但是也有自己配置了dns名称，如8.8.8.8。
ISPDns拿到请求后，检查缓存中有没有这个地址（小的运营商对dns进行劫持），有则直接返回，此时返回的ip地址，会标记成非权威服务器应答。
如果没有命中缓存，ISPDns从配置文件读取13个根域名服务器地址，然后向其中一台发起请求。跟服务器获取请求后，知道是com. 这个顶级域名下的，查询到baidu.com这个域，查找后返回，baidu目前有4台baidu.com顶级域名服务器。
通过nslookup可以查看到。

指令：nslookup www.baidu.com

Non-authoritative answer:
www.baidu.com   canonical name = www.a.shifen.com.
Name:   www.a.shifen.com
Address: 61.135.169.125
Name:   www.a.shifen.com
Address: 61.135.169.121

1. Non-authoritative answer表示命中了ISP缓存
2. canonical name 即为CNAME----www.a.shifen.com.

image.png
可以看到在查找www.baidu.com 域名的过程中，isp-dns会查找到baidu-dns地址，并发起请求，发起请求后返回

重定向交给HttpURLConnection完成，调用它的setInstanceFollowRedirects(true)或者设置为false，根据conn.getResonseCode() 递归实现。

附带基础知识：
A记录是解析域名到IP，CNAME是解析域名到另外一个域名
如：
域名 www.xx.com → 111.111.111.111
主机名 DD → 222.222.222.222

CNAME记录，也叫别名记录，相当于给A记录中的域名起个小名儿，比如www.xx.com的小名儿就叫www.yy.com好了，然后CNAME记录也和A记录一样，是一种指向关系

上述域名总结来自于文章：https://blog.csdn.net/h106140873/article/details/80818665

排查网络慢的问题，1.代码查询。 2.抓包通过wireshark之类的抓包，查看整个网络流程，在请求发送过程中具体慢在哪个地方。

需要了解的知识点：
https://www.jianshu.com/p/d985ec694077
https://www.jianshu.com/p/026c34a4fc41

image.png