Android实习生 —— 开发必须知道的事

96
博儿丶
2017.04.10 11:43* 字数 2679

目录

文章未完成

一、OSI模型

1、OSI模型基础知识速览
OSI模型
2、五层协议的体系结构
五层协议

二、Android架构图

Android的系统架构采用了分层架构的思想,如图1所示。从上层到底层共包括四层,分别是应用程序程序层应用框架层系统库和Android运行时Linux内核层

安卓架构图.png

1、应用程序层

该层提供一些核心应用程序包,例如电子邮件、短信、日历、地图、浏览器和联系人管理等。同时,开发者可以利用Java语言设计和编写属于自己的应用程序,而这些程序与那些核心应用程序彼此平等、友好共处。

2、应用程序框架层

这一层是编写Google发布的核心应用时所使用的Android应用开发的基础API框架,开发人员大部分情况是在和她打交道,这样便简化了程序开发的结构设计,但是必须要遵守其框架的开发原则。应用程序框架层包括活动管理器、窗口管理器、内容提供者、视图系统、包管理器、电话管理器、资源管理器、位置管理器、通知管理器和XMPP服务十个部分。

3、 系统运行库(C/C++库以及Android运行库)层

当使用Android应用框架时,Android系统会通过一些C/C++库来支持我们使用的各个组件,使其更好的为我们服务。系统库包括九个子系统,分别是图层管理、媒体库、SQLite、OpenGLEState、FreeType、WebKit、SGL、SSL和libc。
Android运行时包括核心库和Dalvik虚拟机,前者既兼容了大多数Java语言所需要调用的功能函数,又包括了Android的核心库,比如android.os、android.net、android.media等等。后者是一种基于寄存器的java虚拟机,Dalvik虚拟机主要是完成对生命周期的管理、堆栈的管理、线程的管理、安全和异常的管理以及垃圾回收等重要功能。
关于Dalvik VM (DVM) 与Java VM (JVM)的区别,请点击查看

4、Linux内核层

Android核心系统服务依赖于Linux2.6内核,如安全性、内存管理、进程管理、网络协议栈和驱动模型。Linux内核也是作为硬件与软件栈的抽象层。驱动:显示驱动、摄像头驱动、键盘驱动、WiFi驱动、Audio驱动、flash内存驱动、Binder(IPC)驱动、电源管理等。


三、TCP协议

1、三次握手(建立连接)
  • TCP(Transmission Control Protocol) 传输控制协议。TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接:

  • TCP报文段首部格式:

    TCP报文段

    (1)序号:Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。
    (2)确认号ack期待收到对方下一个报文段的第一个数据字节的序号
    (3)标志位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下:
    (A)URG:紧急指针(urgent pointer)有效。
    (B)确认ACK:确认序号有效。占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效。
    (C)PSH:接收方应该尽快将这个报文交给应用层。
    (D)RST:重置连接。
    (E)同步SYN:发起一个新连接。连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。
    ** (F)FIN:释放一个连接。**

若同意连接,则在响应报文段中使得SYN=1,ACK=1。
因此,SYN=1表示这是一个连接请求,或连接接受报文。
终止FIN:用来释放一个连接。
FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接
  • 过程

    • 第一次握手:请求连接时,客户端发送SYN=1,ACK=0(连接请求报文段)、自己的seq序号x到服务器,并进入SYN_SEND状态,等待服务器确认;

    • 第二次握手:服务器收到请求,发送SYN=1,ACK=1(连接响应报文段)、自己的seq序号y、确认号ack=x+1,到客户端表示连接接受,此时服务器进入SYN_RECV状态;

    • 第三次握手:客户端收到后检查ack是否正确,即第一次发送的seq(x)+1,以及确认ACK是否为1,若正确再次回应服务器端一个确认ACK=1、确认号ack=y+1和seq(x)+1确认数据段。客户端和服务器进入ESTABLISHED状态

    • 完成三次握手,主机A与主机B开始传送数据。


      三次握手
  • 重点分析
    还要再发送一次确认是为了,防止已失效的连接请求报文段突然又传到了B,因而产生错误。

    已失效的报文段:正常情况下:A发出连接请求,但因为丢失了,故而不能收到B的确认。于是A重新发出请求,然后收到确认,建立连接,数据传输完毕后,释放连接,A发了2个,一个丢掉,一个到达,没有“已失效的报文段”。

    但是,某种情况下,A的第一个在某个节点滞留了,延误到达,本来这是一个早已失效的报文段,但是在A发送第二个,并且得到B的回应,建立了连接以后,这个报文段竟然到达了,于是B就认为,A又发送了一个新的请求,于是发送确认报文段,同意建立连接,假若没有三次的握手,那么这个连接就建立起来了(有一个请求和一个回应),此时,A收到B的确认,但A知道自己并没有发送建立连接的请求,因为不会理睬B的这个确认,于是呢,A也不会发送任何数据,而B呢却以为新的连接建立了起来,一直等待A发送数据给自己,此时B的资源就被白白浪费了。但是采用三次握手的话,A就不发送确认,那么B由于收不到确认,也就知道并没有要求建立连接。

2、四次握手(释放连接)
  • 终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接

  • 步骤
    (1)第一次挥手:客户端A发送一个FIN、自己的seq序号u用来关闭客户A到服务器B的数据传送。Client进入FIN_WAIT_1状态。
    (2)第二次挥手:服务器B收到这个FIN,它发回一个ACK=1、ack=u+1、自己的序号seq=v,Server进入CLOSE_WAIT状态。
    (3)第三次挥手:Server发送一个FIN、自己的序号seq=w,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
    (4)第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发给Server一个ACK=1、ack=w+1、自己的序号seq=u+1,Server进入CLOSED状态,完成四次挥手。

    四次握手

3、总结
  • 为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?
    这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后,它可以把ACK和SYN(ACK起应答作用,而SYN起同步作用)放在一个报文里来发送。但关闭连接时,ACK却没有和FIN一起发送,原因是因为tcp是全双工模式,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的.

  • 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?
    ①、为了保证A发送的最后一个ACK报文段能够到达B。即最后这个确认报文段很有可能丢失,那么B会超时重传,然后A再一次确认,同时启动2MSL计时器,如此下去。如果没有等待时间,发送完确认报文段就立即释放连接的话,B就无法重传了(连接已被释放,任何数据都不能出传了),因而也就收不到确认,就无法按照步骤进入CLOSE状态,即必须收到确认才能close。

    ②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL,那些在这个连接持续的时间内,产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点,但是呢,经过2MSL这些无效报文段就肯定可以发送到目的地,不会滞留在网络中。这样的话,在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。
    可以看出:B结束TCP连接的时间比A早一点,因为B收到确认就断开连接了,而A还得等待2MSL.

四、JVM内存结构和内存管理


整理作者:汪博
少壮不努力,老大徒悲伤。
本文为Android学习规划打造,如有不好的地方请多多指教。

Android复习
Web note ad 1