一、Android Profiler
1、CPU profiler（优化CPU性能）
Call chart
橙色表示系统 API 的函数，绿色表示应用自有函数，蓝色表示第三方 API（包括 Java 语言 API）的函数
水平表示调用时间，垂直表示调用者
Flame Chart(火焰图)
相同调用堆栈聚合在一块，耗时最多的放上面
Top Down自上而下（类似与火焰图）
Bottom Up自下而上
2、Memory profiler
堆转储heap dump：记录某一时间点的内存使用情况
红点按钮：用于记录一段时间内内存分配情况
使用方式：启动app，使用一段时间观察内存使用情况，进行heap dump查看有没有异常（同一对象重复出现，对象占用内存过大）场景如：切换横竖屏，反复进行页面跳转
二、Leakcanary
只关注activity，使用LeakCanary.install(this)；
关注fragment，在onDestroy加入RefWatcher；
不能检测Service的内存泄露
三、性能优化基础知识
1、卡顿优化
应用层绘制，系统层渲染，android系统需要在16ms内完成绘制，就不会出现卡顿
RelativeLayout会测量两次（不推荐），LinerLayout测量一次
卡顿优化工具：Profile GPU Rendering、Debug GPU overDraw过度绘制检测
2、耗电优化
Battery Historian耗电分析工具
3、app包大小优化
资源优化、代码优化、代码混淆
4、内存优化
内存泄露：持有Activity引用，如单例中、Handler中、内部类中，资源未关闭、使用webview
内存优化：引用类型（强弱软虚）、内存复用（线程池、对象池）、使用合适的数据结构、图片内存优化
四、图片处理
Bitmap优化：对图片进行尺寸压缩、质量压缩，使用二级缓存
图片常用格式：VectorDrawable/WebP/PNG/JPG
LruCache原理：LinkedHashMap(hashmap+双向链表)访问最多的移动到表尾，访问最少的从表头移除
在双向链表里进行重排序
三级缓存：内存、磁盘、网络，一般下拉刷新时获取数据，或者定时获取
AOP编程：如有多个登录请求操作，把这种操作封装起来，在一处实现复杂逻辑编写，其他位置只需简单调用即可。AOP实现分静态实现和动态实现（反射不推荐），静态实现常见方式APT（ButterKnife）、AspectJ
网络编程：tcp/ip五层协议包括应用层（HTTP、HTTPS、SOAP）、传输层（TCP、UDP）、网络层（IP）、数据链路层（以太网、WiFi）、物理层（光缆、电缆、双绞线、无线电波）
TCP三次握手：
1、服务器先创建传输控制块，先进入LISTEN监听状态，监听客户端的请求；
2、客户端创建传输控制块，然后向服务器发送请求报文，此时报文信息为Seq=x，此时进入SYN-SENT同步已发送状态；（第一次握手）
3、服务器收到请求报文后，发出确认报文，报文信息为ACK=x+1，Seq=y,此时服务器进入SYN-RCVD同步收到状态；（第二次握手）
4、客户端收到确认报文，向服务器发出确认报文，报文信息为ACK=y+1,Seq=x+1,此时客户端进入ESTABLISHED已建立连接状态；（第三次握手）
5、服务端收到确认报文进入ESTABLISHED状态，双方建立连接成功。
第三次握手原因：
第一次客户端发送请求报文时，在传输时滞留时间过长，服务器没有收到就没有发出确认报文。客户端会又一次发送请求报文，此时服务器收到并确认，与客户端建立了连接。
此时第一次的报文到达了服务端，服务端确认并发送确认报文，又会建立一次连接，造成资源浪费。
而三次握手，在第三次握手时，客户端收到确认后，就不会再发出错误的确认报文了，也就不会继续建立连接了。
TCP四次挥手：
1、客户端发出释放报文，停止发送数据，释放报文信息为FIN=1，Seq=x+2,ACK=y+1,此时客户端进入FIN-WAIT-1终止等待1状态；（第一次挥手）
2、服务端收到释放报文，发出确认报文（包含数据），确认报文信息为ACK=x+3,服务端进入CLOSE-WAIT关闭等待状态；（第二次挥手）
3、客户端收到确认报文后，此时客户端进入FIN-WAIT-2终止等待2状态，等待服务端发出释放报文；
4、服务端将最后的数据发送完毕后，向客户端发送释放报文，此时服务端进入LAST-ACK最后确认状态，等待客户端确认；（第三次挥手）
5、客户端收到释放报文后，发出再次确认报文，客户端进入TIME-WAIT时间等待状态，经过2∗∗MSL最长报文段寿命后，撤销TCB传输控制块，才进入close状态；（第四次挥手）
6、服务端收到确认报文，立即进入close状态，撤销TCB传输控制块，结束连接
为什么会有2∗MSL时间段？
（1）服务端在这时已经发送完释放和确认报文了，客户端在第四次挥手时发送再次确认报文，此报文有可能丢失，服务端没有收到再次确认，服务端觉得没有收到反馈，又发了一遍释放和确认报文，客户端就可以在2∗MSL时间段内收到服务端的第二次报文，然后发送再次确认报文，并重启2*MSL计时器。
（2）防止类似出现第三次握手的同样情况，客户端在第四次挥手时发送再次确认报文，在传输时滞留。
为什么是四次挥手呢？
服务端数据和释放报文可以分开发送，就多了一次挥手。
未完待续（glide、android启动流程、android启动模式、handler、集合框架）
（RecycleView、fragment、屏幕适配、内容提供者、广播）
（retrofit）
