Android春招面试题Shopee
-
数据库的事务?
-
事务就是对数据库操作的序列,是一个不可分割的工作单位,这个序列中的操作或者全部执行,或者全部不执行;
-
特性:原子性/持久性/一致性/隔离性
-
原子性:或者全部执行或者全部不执行,如转账时要么同时成功要么同时失败;
-
一致性:是指事务开始之前和事务结束之后,不能破坏关系数据的完整性和业务逻辑的一致性;如转账时保证钱的总数是不变的;
-
持久性:当提交后,对数据库的改变是通就行的,不会被回滚;
-
隔离性:多个事务并发执行时,相互之间无影响;
-
如在多用户,多并发的情况下,多个事务对用一个数据进行访问时,只能看到这个数据在上一个事务修改前的状态或者修改后的状态,不会看到中间状态的数据;
-
-
-
-
事务之间相互影响的种类
-
脏读
-
不可重复读
-
幻读
-
丢失更新
-
-
url到网页渲染出来经历了哪些步骤?
-
根据请求的url交给DNS域名解析,找到真实的IP,向服务器发起请求;
-
服务器交给后台处理完后返回数据,浏览器接收数据(HTML/CSS/JS/图像等);
-
浏览器对数据进行解析,建立起相应的内部结构;
-
载入解析到的资源文件,渲染页面,完成;
-
-
网络中的滑动窗口和拥塞控制
-
滑动窗口:实现对TCP传输速率的控制,本质上就是流量控制,也是保证可靠传输的方法之一;
-
拥塞控制是指网络资源大于可用资源;目前的解决方法:
-
慢启动
-
拥塞避免
-
快重传
-
快恢复
-
-
-
Https为什么安全,TLS
-
HTTPS就是在HTTP与TCP中间加多了一层加密层TLS/SSL;HTTP将数据给到加密层,数据加密后,再给到TCP进行传输;
-
SSL是个加密套件,为了解决传输内容会被查看和修改;TLS是SSL的标准版
-
-
乐观锁和悲观锁
-
乐观锁:总是假设每次去拿数据的时候都认别的线程不会修改,不会上锁,在更新时候去判断,社用于多读的应用类型,可提高吞吐量;如数据库的write_condition就是乐观锁;
-
悲观锁:每次拿数据的时候都会上锁,共享资源每次只给一个线程使用,其他线程阻塞,用完后再把资源让给其他线程;
-
-
HashMap的插入操作?如果多次扩容之后如何解决内存资源的浪费?
-
HashMap的底层原理?
-
往HashMap中put元素时,根据key的hash值得到Entry元素在数组中的位置,然后把这个Entry元素放在相应的位置( 即下标),如果这个位置上有其他元素就在同一个位置的Entry元素以链表的形式存放,新加入的放在链表头;
-
之所以这么设计是因为数据存储是连续的,占用内存严重,但是随机查找会快,因此寻址简单而插入删除困难,而链表
-
从HashMap中get元素时先计算key的hashcode,找到数组中对应位置,然后通过key的equals方法在对应位置的链表中找到需要的Entry元素,所以HashMap的数据结构是数组和链表的组合,此外HashMap中的key和value都允许为null,key为null的键值对都放在头结点的链表中;
-
-
HashMap默认的初始化长度为多少?扩容?
-
JDK中默认长度为16(Android SDK中为4) , 并且默认长度和扩容后的长度都必须是2的幂;
-
-
-
view中的onDraw的步骤
-
对视图的背景进行绘制
-
会根据layout过程确认的视图位置来设置背景的绘制区域;
-
调用Drawable的draw方法来完成背景的绘制工作;
-
-
对视图的内容进行绘制
-
对当前视图的子视图进行绘制;
-
对试图的滚动条进行绘制
-
-
TCP三次握手的过程?为什么要三次握手?tcp为什么可靠?
-
tcp连接握手是用于传输通信双方的数据原点的序列号,同时tcp是全双工的一个双向通信,为了可靠传输,始终都需要同步信号.出事双方的序号是随机的.刚开始通信双方都产生一个初始的随机序列号ISN;
-
三次握手的过程:
-
第一次握手:建立连接时,客户端发送syn(同步序列编号)包到服务器,并进入SYN_SEND状态,等待服务器确认;
-
第二次握手:服务器收到syn包,必须确认客户端的SYN,命名为ACK,同时自己也发送一个SYN包,即SYN+ACK包,此时服务器进入SYN_RECV状态;
-
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK,发送完毕后,客户端和服务器进入ESTABLISHED状态,完成三次握手;
-
-
为什么两次不行?
-
为了数据传输,TCP协议的通信双方都必须维护一个序列号,三次握手的过程即通信双方互相告知序列号起始值的过程;没有第三步的同步信号,不知道双方是否达成一致的状态
-
-
tcp采用了确认应答机制,即发送数据之后必须收到确认消息,才算一次有效的传输;
-