安卓面试之网络技术

1.网络框架对比和源码分析

• Volley
  • 特点
    • 基于httpURLconnection
    • 封装url图片加载框架，支持图片加载
    • 有缓存
    • ACtivity结束时取消在此activity中调用的所有网络请求
  • 场景
    • 适合传输量小，数据请求频繁的场景
    • 不能进行大量数据操作，如上传下载，因为volley的请求和响应都是放到byte[]中
• okhttp
  • 特点
    • 基于NIO和Okio,请求处理速度更快
    • IO是阻塞式，NIO是非阻塞式，okio是基于二者的更高效的数据流库
    • IO面向流，NIO面向缓冲区
  • 场景
    • IO适合于链接数量不大，但是每个链接需要发送和接收的数据量很大，长时间的连续处理
    • NIO适合同时存在海量的链接，但是每个链接单词发送数据量比较小，如聊天服务器
• Retrofit
  • 特点
    • 基于okhttp
    • 通过注解配置请求
    • 性能最好，处理最快
    • 易于其他框架RXJava联合使用
  • 场景
    • 项目中有RXJava的时候

2.自己去设计网络请求框架，怎么做？

https://github.com/sucese/android-open-framework-analysis/blob/master/doc/Android%E5%BC%80%E6%BA%90%E6%A1%86%E6%9E%B6%E6%BA%90%E7%A0%81%E9%89%B4%E8%B5%8F%EF%BC%9AOkhttp.md

实现步骤：请求，拦截，连接，缓存

• 一 请求与响应流程
  • 1.1 请求的封装
  • 1.2 请求的发送
  • 1.3 请求的调度
• 二 拦截器
  • 2.1 RetryAndFollowUpInterceptor
  • 2.2 BridgeInterceptor
  • 2.3 CacheInterceptor
  • 2.4 ConnectInterceptor
  • 2.5 CallServerInterceptor
• 三 连接机制
  • 3.1 建立连接
  • 3.2 连接池
• 四 缓存机制
  • 4.1 缓存策略
  • 4.2 缓存管理

OkHttpClient okHttpClient = new OkHttpClient.Builder()
        .build();
Request request = new Request.Builder()
        .url(url)
        .build();
okHttpClient.newCall(request).enqueue(new Callback() {
    @Override
    public void onFailure(Call call, IOException e) {
    }

    @Override
    public void onResponse(Call call, Response response) throws IOException {

    }
});

1.首先创建了一个okhttpclient的实例；

2.如果想要发起http请求，那么就要创建request对象。可以发现 OkHttpClient相当于是个上下文或者说是大管家，它接到我们给的任务以后，将具体的工作分发到各个子系统中去完成

3.调用okhttpclient的newcall方法来创建一个call对象，调用其excute()方法或者enqueue方法

Okhttp的子系统层级结构图如下所示：

• OkHttpClient：通信的客户端，用来统一管理发起请求与解析响应。
• Call：Call是一个接口，它是HTTP请求的抽象描述，具体实现类是RealCall，它由CallFactory创建。
• Request：请求，封装请求的具体信息，例如：url、header等。
• RequestBody：请求体，用来提交流、表单等请求信息。
• Response：HTTP请求的响应，获取响应信息，例如：响应header等。
• ResponseBody：HTTP请求的响应体，被读取一次以后就会关闭，所以我们重复调用responseBody.string()获取请求结果是会报错的。
• Interceptor：Interceptor是请求拦截器，负责拦截并处理请求，它将网络请求、缓存、透明压缩等功能都统一起来，每个功能都是一个Interceptor，所有的Interceptor最 终连接成一个Interceptor.Chain。典型的责任链模式实现。
• StreamAllocation：用来控制Connections与Streas的资源分配与释放。
• RouteSelector：选择路线与自动重连。
• RouteDatabase：记录连接失败的Route黑名单。

请求与响应流程

1.请求的封装

2.缓存策略

HTTP的缓存机制也是依赖于请求和响应header里的参数类实现的，最终响应式从缓存中去，还是从服务端重新拉取，HTTP的缓存机制的流程如下所示

HTTP的缓存可以分为两种：

• 强制缓存：需要服务端参与判断是否继续使用缓存，当客户端第一次请求数据是，服务端返回了缓存的过期时间（Expires与Cache-Control），没有过期就可以继续使用缓存，否则则不适用，无需再向服务端询问。
• 对比缓存：需要服务端参与判断是否继续使用缓存，当客户端第一次请求数据时，服务端会将缓存标识（Last-Modified/If-Modified-Since与Etag/If-None-Match）与数据一起返回给客户端，客户端将两者都备份到缓存中 ，再次请求数据时，客户端将上次备份的缓存 标识发送给服务端，服务端根据缓存标识进行判断，如果返回304，则表示通知客户端可以继续使用缓存。

强制缓存优先于对比缓存。

上面提到强制缓存使用的的两个标识：

• Expires：Expires的值为服务端返回的到期时间，即下一次请求时，请求时间小于服务端返回的到期时间，直接使用缓存数据。到期时间是服务端生成的，客户端和服务端的时间可能有误差。
• Cache-Control：Expires有个时间校验的问题，所有HTTP1.1采用Cache-Control替代Expires

3.网络请求缓存处理，okhttp如何处理网络缓存

• 读取候选缓存
• 创建缓存策略
• 根据策略，不使用网络没有缓存的直接报错，返回504，有返回的直接返回
• 没有返回的话，继续执行下一个拦截器
• 接收到网络结果，如果响应码为304，则使用缓存，返回缓存结果
• 读取网络结果
• 对数据进行缓存
• 返回网络读取结果

4.从网络上加载一个10M的图片，说一下注意事项

https://www.shangmayuan.com/a/6de2a5e2faea41e5901242c4.html

咱们首先得到目标View所需的大小，而后得到图片的大小，最后经过计算屏幕与图片的缩放比，按照缩放比来解析位图。缓存具体步骤以下：

1. 将BitmapFactory.Options的inJustDecodeBounds参数设为true并加载图片
2. 从BitmapFactory.Options中取出图片的原始宽高信息，他们对应于outWidth和outHeight参数
3. 根据采样率的规律并结合目标View的所需大小计算出采样率inSampleSize
4. 将BitmapFactory.Options的inJustDecodeBounds参数设为false,而后从新加载图片

****options.inJustDecodeBounds********：****若是给它赋值true，那么它就不会解析图片。使用它的目的是为了得到图片的一些信息，如图片高度和宽度，而后进行下一步工做，也就是计算缩放比。将options.inJustDecodeBounds设置为false，将会加载图片对象

*options.inSampleSize* ****：****给图片赋予缩放比，当它的值大于1的时候，它就会按照缩放比返回一个小图片用来节省内存。

在Android中使用ARGB来展现颜色的，通常状况下使用的是ARGB_8888，每一个像素的大小约为4byte。若是对质量不作太大要求，可使用ARGB_4444或者RGB_565，他们都是2个字节的。

****若是图片涉及到放大功能，则也须要注意如下事项：****内存

*1.图片分块加载：*

*2.使用LruCache*

*3.手势处理*

5.TCP的3次握手和4次挥手

http://www.youkmi.cn/2019/12/10/ji-suan-ji-wang-luo-xiang-guan/

重要标志位：

ACK:TCP协议规定，只有ACK=1时有效

SYN：在建立连接时用来同步序号，当SYN=1而ACK=0时，表明这是一个连接请求报文，若对方同意连接，则SYN=1，ACK=1。SYN=1表示这是一个连接报文或者发送报文

FIN：即用完的意思，用来释放一个连接，当FIN=1时，表明报文段的发送方数据已经发送完毕

Seq：为自身序列

三次握手

SYN=1,seq=client_isn:首先是建立连接，客户端发送连接请求报文，然后客户端进入SYN_SEND状态，等待服务器的确认。

SYN=1，seq=server_isn,ACK=client_isn+1：服务器端收到客户端的SYN报文，需要对这个报文端进行确认，设置为其序列号＋1，同时自己还要发送SYN请求，因此SYN=1，seq=Y,服务器端将（syn+ack）一并发送给客户端，服务器进入SYN_RECV状态

SYN=0,seq=client+1,ACK=server_isn+1,然后向服务器端发送报文段，客户端和服务端都进入ESTABLISHED状态，完成三次握手。

四次挥手

为什么连接的时候是三次握手，而关闭的时候是四次握手

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

为什么TIME——WAIT状态需要经过2MSL才能返回close状态

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

6.TCP与UDP的区别

• 链路层：负责封装和解封装IP报文，发送和接收ARP报文
• 网络层：负责路由以及把分组报文发送给目标网络
• 传输层：负责对报文进行分组，并以TCP或者UDP协议格式进行封装报文
• 应用层：负责提供应用程序，如HTTP，FTP，DNS等

UDP

用户数据报协议，在传输层，有以下特点

• 面向无连接，只是增加或者删去报文头就转发了，不会有其他操作
• 支持一对多，多对多，多对一功能
• UDP是面向报文的
• 不可靠性
• 头部开销小，传输数据报文时是很高效的，只有8字节，比TCP的二十个字节少很多

TCP

建立一个TCP的过程就需要三次握手和四次挥手

• 面向连接：发送数据前必须建立连接
• 仅支持点对点传输
• 面向字节流
• 可靠性
• 能提供拥塞控制，缓解拥塞

对比

7.TCP与UDP的应用

https://www.cnblogs.com/liangyc/p/11628208.html

• TCP应用场景：
  效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
• UDP应用场景：
  效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

8.HTTP协议

https://juejin.cn/post/6844903591883309063

1.简介

• 超文本传输协议
• 基于TCP/IP通信协议来传递数据
• 在应用层，如果基于TLS或SSL协议，那就是https
• http默认端口号为80，https为443

2.http协议工作流程

• 用户在浏览器输入访问网页的url
• 根据url的域名，通过DNS解析出目标网页的ip地址
• 客户端通过tcp/ip协议来和服务器建立连接（三次握手）
• 建立连接后，发送一个请求给服务器，格式为：同意资源标识符、协议版本号，请求修饰符
• 服务器接收到请求后，会返回响应状态码

9.http1.0、http1.1、http2.0的区别

https://juejin.cn/post/6844903489596833800

影响一个http网络请求的因素主要有两个：带宽和延迟（浏览器阻塞、DNS查询、建立连接）

HTTP1.0&HTTP1.1

• 缓存处理：
  • 在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，
  • HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
• 带宽优化及网络连接的使用：
  • 1.1 支持 range， 返回码206，只允许请求部分资源（ Partial Content）
• 错误通知的管理
  • 在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除
• Host头处理
• 长连接

http&https

• HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费
• HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
• HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443

SPDY：HTTP1.X的优化

• 降低延迟：多路复用
• 请求优先级
• header压缩
• 基于https的加密传输协议

HTTP2.0：SPDY的升级版

​ 区别：

• http2.0支持http传输，但是spdy强制使用https
• 2.0采用的是HPACK压缩算法，而spdy采用的是DEFLATE

HTTP2.0和HTTP1.X相比的新特性

• 新的二进制格式
• 多路复用
• header压缩
• 服务端推送

10. http报文结构

请求报文

请求行:
    方法:
        GET 获取资源
        POST 向服务器端发送数据，传输实体主体
        PUT 传输文件
        HEAD 获取报文首部
        DELETE 删除文件
        OPTIONS 询问支持的方法
        TRACE 追踪路径
    协议/版本号
    URL
    
请求头:
    通用首部(General Header)
    请求首部(Request Header)
    响应首部(Response Header)
    实体首部(Entity Header Fields)
    
请求体

响应报文

状态行：
    协议版本
    状态码：
    	1xx: 服务器接收客户端请求，客户端可以继续发送请求
		2xx: 服务器接收客户端请求并进行处理
		3xx: 服务器要求客户端重定向：要求用户进一步细化请求
		4xx: 客户端请求非法：客户错误
		5xx: 服务器未能正常处理客户端的请求而出现意外：服务器发生错误  
    状态码描述：      

11.HTTP与HTTPS的区别及如何实现

• 对称加密：没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了
• 非对称加密：私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得
• 对称加密+非对称加密(HTTPS采用这种方式)：使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。就比如说你抢到了一个保险柜，但是没有保险柜的钥匙也不能打开保险柜。那我们就将对称加密与非对称加密结合起来，充分利用两者各自的优势，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制

http与https的区别

• HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO，谷歌、百度优先索引HTTPS网页;
• HTTPS需要用到SSL证书，而HTTP不用;
• HTTPS标准端口443，HTTP标准端口80;
• HTTPS基于传输层，HTTP基于应用层;
• HTTPS在浏览器显示绿色安全锁，HTTP没有显示;

12.如何验证证书的合法性

• 客户端发送信息，带上支持的 SSL 或者 TLS 版本（不同浏览器支持程* * 度不同）。
• 服务器返回确认使用的加密通信协议版本以及加密随机数和 CA 证书。
• 浏览器验证证书（存在双向验证和单项验证） -> OCSP 或者 CRL * 结合自带truststore。
• 检查 CA 证书的根证书颁发机构是否受浏览器信任。
• 检查 CA 证书中的证书吊销列表，检查证书是否被吊销。
• 检查 CA 证书是否在有效期内。
• 检查部署 CA 证书的网站域名与证书颁发的域名是否一致。
• 浏览器核对该网站是否存在于欺诈网站数据库中。

13.https中哪里使用了对称加密，哪里用了非对称加密，对加密算法（RSA）是否了解

https://www.cnblogs.com/xishuai/p/https-ca.html

1. 浏览器发起往服务器的 443 端口发起请求，请求携带了浏览器支持的加密算法和哈希算法
2. 服务器收到请求，选择浏览器支持的加密算法和哈希算法
3. 服务器下将数字证书返回给浏览器，这里的数字证书可以是向某个可靠机构申请的，也可以是自制的
4. 浏览器进入数字证书认证环节，这一部分是浏览器内置的 TSL 完成的
5. 浏览器将加密的 R 传送给服务器。
6. 服务器用自己的私钥解密得到 R。
7. 服务器以 R 为密钥使用了对称加密算法加密网页内容并传输给浏览器
8. 浏览器以 R 为密钥使用之前约定好的解密算法获取网页内容

14.谈谈你对websocket的理解

WebSocket 是类似 Socket 的 TCP 长连接的通讯模式， 一旦 WebSocket 连接建立后，后续数据都以帧序列的形式传输。在客户端断开 WebSocket 连接或Server 端断掉连接前，不需要客户端和服务端重新发起连接请求。WebSocket 是双向通信协议， 模拟 Socket 协议， 可以双向发送或接受信息。HTTP 是单向的。WebSocket 是需要握手进行建立连接的

15.websocket与socket的区别

• 为了解决 Web 端即时通讯的需求就出现了 WebSocket，允许服务器端主动通知
• 网络中的 Socket 并不是什么协议，而是为了使用 TCP，UDP 而抽象出来的一层 API，它是位于应用层和传输层之间的一个抽象层。Socket 是对 TCP/IP 的封装
• Socket 是传输控制层的接口。用户可以通过 Socket 来操作底层 TCP/IP 协议族通信。
• WebSocket 是一个完整应用层协议
• Socket 更灵活，WebSocket 更易用
• 两者都能做即时通讯

16.谈谈你对安卓签名的理解

• Android 使用标准的 Java 工具 Keytool & Jarsigner 来生成数字证书，并给应用包签名
• 使用zipalign优化程序
• 调试模式和发布模式
• 通过命令来对apk签名
• 使用ADT Export Wizard进行签名

17.为什么要加签名机制

为什么要签名

• 发送者的身份认证：
• 保证信息传输的完整性：
• 防止交易中的抵赖发生：

给 apk 签名可以带来以下好处

• 应用程序升级：
• 应用程序模块化：
• 代码或者数据共享：

签名的说明

• 所有的应用程序都必须有数字证书：
• Android 程序包使用的数字证书可以是自签名的：
• 使用一个合适的私钥生成的数字证书来给程序签名：
• 数字证书都是有有效期的

18.App是如何沙箱化，为什么要这么做？

• 在Android系统中，应用（通常）都在一个独立的沙箱中运行，即每一个Android应用程序都在它自己的进程中运行，都拥有一个独立的Dalvik虚拟机实例。Dalvik经过优化，允许在有限的内存中同时高效地运行多个虚拟机的实例，并且每一个Dalvik应用作为一个独立的Linux进程执行。Android这种基于Linux的进程“沙箱”机制，是整个安全设计的基础之一

• Android应用程序的“沙箱”机制：

  互相不具备信任关系的应用程序相互隔离，独自运行，访问是禁止的： 通过共享UID（SharedUserID）,应用程序在同一个进程运行，共享数据

19.cookie与session的作用和原理

• Session 是在服务端保存的一个数据结构， 用来跟踪用户的状态， 这个数据可以保存在集群、数据库、文件中
• Cookie 是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session 的一种方式

Cookie

HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

Cookie 主要用于以下三个方面：

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

Session

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。

二者的区别

• 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
• 存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
• 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
• 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
  对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。

二者的区别

• 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
• 存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
• 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
• 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
• 存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。