android开发网络,安卓网络开发

android软件开发拨号为什么要连网络

因为这个拨号功能消耗流量，不消耗话费。

不消耗话费的情况下，如果不连接网络，就无法拨号。

Android是由Google公司和开放手机联盟领导并开发的一种基于Linux的自由且开放源代码的操作系统，该平台由操作系统、中间件、用户界面和应用软件组成，主要使用于移动设备。Android的图案是一个全身绿色的机器人，其颜色采用了PMS 376C和RGB中十六进制的#A4C639来绘制

相关问答

Q1: Android之网络—第二篇（Https原理）

Android之网络—第一篇（Http原理）

Android之网络—第二篇（Https原理）

Android之网络—第三篇（解读OkHttp）

Android之网络—第四篇（解读Retrofit）

说的通俗一点就是身披安全衣的Http，本质还是http，只是在http外层嵌套了一个SSL/TLS的安全层，该层做了一些数据的加解密处理。

在讲解Https原理之前，先做点准备工作，因为会涉及到SSL/TLS连接建立、SSL/TLS加解密方面的知识。所以会整体从网络架构和比较重要的知识点回顾下网络知识。

在讲解什么是SSL/TLS之前，回顾下TCP/IP协议的分层概念。通常一个网络的传输中间会经过很多的传输节点，才最终达到服务器。期间过程会包含数据的拆分和拼装、IP的解析、数据的传输等等操作，但是网络传输是很不稳定的，如果这次网络请求在中间的某一节点失败了，难道还要重新再发送一遍么？答案是不应该这么做。

为了网络传输的统一规范，就设计了这么一套网络通信的规范，每一层都专注做一件事情，即使当前失败了，也在这层做处理就可以了，尽量避免重发。

简单解释下，每层的含义：

通过上图发现，数据是由上往下传递后，再由下往回传递。这是怎么回事呢？总结就是：在 TCP / IP　协议中数据先由上往下将数据装包，然后由下往上拆包。在装包的时候，每一层都会增加一些信息用于传输，这部分信息就叫报头，当上层的数据到达本层的时候，会将数据加上本层的报头打包在一起，继续往下传递。在拆包的时候，每一层将本层需要的报头读取后，就将剩下的数据往上传。

简要分析下传输过程：

这里简单总结下传输层的两种连接方式：TCP和UDP

三次握手：客户端主动打开连接，服务器被动打开连接。

四次挥手：客户端主动关闭，服务器被动关闭

说个概念性的东西就是，现代密码学分为对称加密和非对称加密，跟传统密码学不一样的地方就是，除了可以加密文字内容外，还可以用于各种二进制数据的加解密。

通信双方使用同一个密钥，使用加密算法配合上密钥来加密，解密时使用解密算法（加密过程的完全逆运算）配合密钥来进行解密。常用的经典算法：DES（56 位密钥，密钥太短而逐渐被弃用）、AES（128 位、192 位、256 位密钥，现在最流行）。

通信双方使用公钥和加密算法对数据进行加密得到密文；使用私钥和加密算法对数据进行解密得到原数据。常用的经典算法：RSA（可用于加密和签名）、DSA（仅用于签名，但速度更快）。

这个有什么用？其实这个就是后面Https加解密的原理。原理这么简单么？是的，就这么简单。但是要理解还得慢慢往下看。

A用自己的私钥通过加密算法得到的数据密文数据，这个数据就可以称为签过名。接收方B再用A提供的公钥通过加密算法就可以还原数据，从而就验证了数据的真实性。因为只有A一个人拥有自己的私钥。

到这里咱们就可以聊聊刚才中间人伪造数据是如何处理了。通过对称加密可以防止中间人偷窥数据，通过数字签名可以防止中间人篡改伪造数据。

但是完整版的签名信息需要将签名数据取Hash值，减少数据大小

好了，看完理解了上面的知识点，到这里我们可以慢慢分析Https是如何工作的了。

先来总结一句话：Https的本质就是在客户端和服务端之间用非对称加密协商出一套对称密钥，每次发送信息之前将内容加密，接收后解密，达到内容的加密传输。解释下，就是整个数据的传输过程是用对称加密的方式来传输的，只是密钥的生成是由客户端和服务端 在创建连接的时候 通过 非对称加密的方式 协商生成的。

那这里就会有一系列的问题啦：

Q：为什么不直接用非对称加密的方式直接加密呢？

A：因为非对称加密的计算过程是复杂的数学运算，太复杂了，很慢。

Q：哦哦，那既然使用对称加密的话，这个对称密钥是怎么来的？

A：在实际的场景中，服务端会对接N个客户端，这个对称密钥如果都使用同一个密钥来通信的话，肯定是不合理的，只要破解了其中一个，其他所有的都会被破解。所以整体的网络架构应该是使用不同加密方式用不同的密钥来进行数据传输的。模型如下图

Q：但是在网络场景中，对称加密的密钥是不能直接在网络上传输的。服务端和客户端是如何都知道的呢？

A：这个是服务端和客户端一起协商根据只有它俩知道的规则分别生成，就不用通过网络传输啦。

Q：如果保证它俩协商出来的密钥不被破解呢？

A：当然是使用非对称加密的方式啦。通过之前的加密知识，可以知道非对称加密是目前来说是绝对安全的。而且一个私钥可以有多个公钥，正好满足一个服务端对N个客户端的场景。模型如下图：

实际在协商通讯的过程中，这个公钥是服务端给客户端发送的。而且需要注意 这个公钥是用来协商生成对称密钥的，不是用来做数据的加密传输的 。

Q：哦哦，原来是这样，但是这样子还是有问题啊，客户端与服务端在协商生成密钥的过程中为了保证数据被偷窥和被篡改的风险，一般会要求有两套公钥和私钥分别做加解密和签名验证处理的，上面的模型只有一套公钥和私钥，没法规避数据被被篡改的风险呀。

A：能提出这个问题，说明之前的学习理解得很好。从上面的模型，可以保证在协商的过程中客户端A/B/C/D分别向服务器传输的数据是安全。但是服务器发送给客户端的数据是如何保证的呢？换句话说就是，客户端如何验证数据是服务端发送过来的，而不是被中间假冒掉包的数据。这不就是之前讲的数字签名的内容么？而实际情况中，就是通过CA证书来处理这个问题的。

Q：那这个CA证书是怎么验证的呢？

A：请看下面的CA证书的分析。

回归之前的分析，我们的问题点卡在了“服务器发送给客户端的数据是如何保证的呢”。对吧。实际上在协商通信的过程中，服务端会先给客户端下发证书信息，这个证书信息里面会包含非对称加密的公钥。但是考虑一个问题，如何保证这个公钥就是客户端要的公钥呢？或者说怎么保证这个证书就是真实的证书，而不是被篡改假冒的证书。只有验证了这一步，客户端才完全信赖服务端，才给服务器发消息，也才接受服务器的消息。这时候就只需要一套公钥和私钥客户端和服务端就可以通信了。

Q：那客户端如何验证服务端下发的证书和公钥是正确的呢？

A：先换个概念，将证书里面的公钥假设为一串数据。要验证这个数据，只需要提供这串数据的签名以及加密这段数据的签名的私钥对应的公钥就可以了，如下图框框所示。

Q：那这样子又有另外的一个问题产生了怎么去验证 这段数据的签名的私钥对应的公钥 了？

A：同样的，也是需要提供对应的签名和对应签名的私钥对应的公钥。

Q：但是这样子下去就会变成一个循环了，怎么办？

其实在这里还会有一个场景问题：第三方签发机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样的，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方签发机构的公钥进行解密。

A：是的，为处理这个问题，就需要讲一个根证书的东西。先举个例子：假设你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。同样的，Https请求验证时，会用到手机操作系统内置的根证书去验证这个证书的真伪的。

到这里就简要分析完了证书的验证过程。证书会包含很多信息，包括服务器公钥，服务器名字，服务器地区等等信息。这个是没法篡改的。其中对Https连接来说最重要的就是服务器的公钥。

之前学习完TCP的连接过程，现在我们开始来唠唠Https连接。什么是Https连接呢？准确来说就是SSL/TLS加解密层的连接。

大致的建立流程：

详细的建立流程：

客户端MAC secret，服务端MAC secret的主要作用：用来认证这个消息是正确的，完整的，解决对称加密方式没法验证消息的缺点。

至此完整的Https在TLS层连接过程分析完毕。

如果觉得我的文章对你有帮助，请随意赞赏。您的支持将鼓励我继续创作！

Q2: Android开发：网络请求延迟下使用loading，缓解尴尬~~~

1.在所需xml文件布局下添加以下内容

2.所需文件在drawable下生成anim_loading.xml文件

Q3: android开发中常用的网络连接方式有哪些

告诉你几个代码把，这些都是连接方式：

Activity.startActivities() 常用于在应用程序中间启动其他的Activity.

TextUtils.isEmpty() 简单的工具类,用于检测是否为空

Html.fromHtml() 用于生成一个Html,参数可以是一个字符串.个人认为它不是很快,所以我不怎么经常去用.（我说不经常用它是为了重点突出这句话：请多手动构建 Spannable 来替换 Html.fromHtml），但是它对渲染从 web 上获取的文字还是很不错的。

TextView.setError() 在验证用户输入的时候很棒

Build.VERSION_CODES 这个标明了当前的版本号,在处理兼容性问题的时候经常会用到.点进去可以看到各个版本的不同特性

Log.getStackTraceString() 方便的日志类工具,方法Log.v()、Log.d()、Log.i()、Log.w()和Log.e()都是将信息打印到LogCat中，有时候需要将出错的信息插入到数据库或一个自定义的日志文件中，那么这种情况就需要将出错的信息以字符串的形式返回来，也就是使用static String getStackTraceString(Throwable tr)方法的时候.

LayoutInflater.from() 顾名思义,用于Inflate一个layout,参数是layout的id.这个经常写Adapter的人会用的比较多.

ViewConfiguration.getScaledTouchSlop() 使用 ViewConfiguration 中提供的值以保证所有触摸的交互都是统一的。这个方法获取的值表示:用户的手滑动这个距离后,才判定为正在进行滑动.当然这个值也可以自己来决定.但是为了一致性,还是使用标准的值较好.

PhoneNumberUtils.convertKeypadLettersToDigits 顾名思义.将字母转换为数字,类似于T9输入法,

Context.getCacheDir() 获取缓存数据文件夹的路径,很简单但是知道的人不多,这个路径通常在SD卡上(这里的SD卡指的是广义上的SD卡,包括外部存储和内部存储)Adnroid/data/您的应用程序包名/cache/ 下面.测试的时候,可以去这里面看是否缓存成功.缓存在这里的好处是:不用自己再去手动创建文件夹,不用担心用户把自己创建的文件夹删掉,在应用程序卸载的时候,这里会被清空,使用第三方的清理工具的时候,这里也会被清空.

ArgbEvaluator 用于处理颜色的渐变。就像 Chris Banes 说的一样，这个类会进行很多自动装箱的操作，所以最好还是去掉它的逻辑自己去实现它。这个没用过,不明其所以然,回头再补充.

ContextThemeWrapper 方便在运行的时候修改主题.

Space space是Android 4.0中新增的一个控件，它实际上可以用来分隔不同的控件，其中形成一个空白的区域.这是一个轻量级的视图组件，它可以跳过Draw，对于需要占位符的任何场景来说都是很棒的。

ValueAnimator.reverse() 这个方法可以很顺利地取消正在运行的动画.我超喜欢.

DateUtils.formatDateTime() 用来进行区域格式化工作，输出格式化和本地化的时间或者日期。

AlarmManager.setInexactRepeating 通过闹铃分组的方式省电，即使你只调用了一个闹钟，这也是一个好的选择，（可以确保在使用完毕时自动调用 AlarmManager.cancel ()。原文说的比较抽象，这里详细说一下:setInexactRepeating指的是设置非准确闹钟，使用方法:alarmManager.setInexactRepeating(AlarmManager.RTC， startTime，intervalL， pendingIntent)，非准确闹钟只能保证大致的时间间隔，但是不一定准确，可能出现设置间隔为30分钟，但是实际上一次间隔20分钟，另一次间隔40分钟。它的最大的好处是可以合并闹钟事件，比如间隔设置每30分钟一次，不唤醒休眠，在休眠8小时后已经积累了16个闹钟事件，而在手机被唤醒的时候，非准时闹钟可以把16个事件合并为一个， 所以这么看来，非准时闹钟一般来说比较节约能源。

Formatter.formatFileSize() 一个区域化的文件大小格式化工具。通俗来说就是把大小转换为MB，G，KB之类的字符串。

ActionBar.hide()/.show() 顾名思义，隐藏和显示ActionBar，可以优雅地在全屏和带Actionbar之间转换。

Linkify.addLinks() 在Text上添加链接。很实用。

StaticLayout 在自定义 View 中渲染文字的时候很实用。

Activity.onBackPressed() 很方便的管理back键的方法，有时候需要自己控制返回键的事件的时候，可以重写一下。比如加入 “点两下back键退出” 功能。

GestureDetector 用来监听和相应对应的手势事件，比如点击，长按，慢滑动，快滑动，用起来很简单，比你自己实现要方便许多。

DrawFilter 可以让你在不调用onDrew方法的情况下，操作canvas，比了个如，你可以在创建自定义 View 的时候设置一个 DrawFilter，给父 View 里面的所有 View 设置反别名。

ActivityManager.getMemoryClass() 告诉你你的机器还有多少内存，在计算缓存大小的时候会比较有用.

ViewStub 它是一个初始化不做任何事情的 View，但是之后可以载入一个布局文件。在慢加载 View 中很适合做占位符。唯一的缺点就是不支持标签，所以如果你不太小心的话，可能会在视图结构中加入不需要的嵌套。

SystemClock.sleep() 这个方法在保证一定时间的 sleep 时很方便，通常我用来进行 debug 和模拟网络延时。

DisplayMetrics.density 这个方法你可以获取设备像素密度，大部分时候最好让系统来自动进行缩放资源之类的操作，但是有时候控制的效果会更好一些.(尤其是在自定义View的时候).

Q4: Android 网络基础之网络协议篇

学习一门技术或者看一篇文章最好的方式就是带着问题去学习，这样才能在过程中有茅塞顿开、灯火阑珊的感觉，记忆也会更深刻。

对于网络的分层，有的分为七层，有的分为四层，而我认为五层模型是最容易理解的网络模型。

如上图所示，从上往下依次为应用层、传输层、网络层、链接层、实体层。

越往上，就越靠近用户；越往下，则越靠近硬件。

大家都遵守的规则，就叫做"协议"（protocol）。

互联网的每一层，都定义了很多协议。这些协议的总称，就叫做"互联网协议"（Internet Protocol Suite），它们是互联网的核心。

我们从最下面一层开始分析，电脑要联网，第一件事要做什么？就是用电缆、光缆、双绞线等方式将电脑连接起来，这就是实体层。

实体层就是就是把电脑连接起来的物理手段。它主要规定了网络的一些电气特性，作用是负责传送 0 和 1 的电信号。

"链接层"在"实体层"的上方，确定了 0 和 1 的分组方式。（多少个电信号算一组？每个信号位有何意义？）

以太网规定，一组电信号构成一个数据包，叫做"帧"（Frame）。每一帧分成两个部分：标头（Head）和数据（Data）。

"标头"包含数据包的一些说明项，比如发送者、接受者、数据类型等等；"数据"则是数据包的具体内容。

"标头"的长度，固定为 18 字节。"数据"的长度，最短为 46 字节，最长为 1500 字节。因此，整个"帧"最短为 64 字节，最长为 1518 字节。如果数据很长，就必须分割成多个帧进行发送。

以太网规定，连入网络的所有设备，都必须具有"网卡"接口。数据包必须是从一块网卡，传送到另一块网卡。网卡的地址，就是数据包的发送地址和接收地址，这叫做 MAC 地址。

每块网卡出厂的时候，都有一个全世界独一无二的 MAC 地址，长度是 48 个二进制位，通常用 12 个十六进制数表示。

前 6 个十六进制数是厂商编号，后 6 个是该厂商的网卡流水号。有了 MAC 地址，就可以定位网卡和数据包的路径了。

以太网采用了一种很"原始"的方式，它不是把数据包准确送到接收方，而是向本网络内所有计算机发送，让每台计算机自己判断，是否为接收方。

同一个子网络的计算机都会收到这个包。它们读取这个包的"标头"，找到接收方的 MAC 地址，然后与自身的 MAC 地址相比较，如果两者相同，就接受这个包，做进一步处理，否则就丢弃这个包。这种发送方式就叫做"广播"（broadcasting）。

有了数据包的定义、网卡的 MAC 地址、广播的发送方式，"链接层"就可以在多台计算机之间传送数据了。

以太网协议，依靠 MAC 地址发送数据。这样做有一个重大的缺点。以太网采用广播方式发送数据包，如果两台计算机不在同一个子网络，广播是传不过去的。这种设计是合理的，否则互联网上每一台计算机都会收到所有包，那会引起灾难。

因此，必须找到一种方法，能够区分哪些 MAC 地址属于同一个子网络，哪些不是。如果是同一个子网络，就采用广播方式发送，否则就采用"路由"方式发送。（"路由"的意思，就是指如何向不同的子网络分发数据包）

“网络层”的作用是引进一套新的地址，使得我们能够区分不同的计算机是否属于同一个子网络。这套地址就叫做"网络地址"，简称"网址"。

"网络层"出现以后，每台计算机有了两种地址，一种是 MAC 地址，另一种是网络地址。网络地址帮助我们确定计算机所在的子网络，MAC 地址则将数据包送到该子网络中的目标网卡。因此，从逻辑上可以推断，必定是先处理网络地址，然后再处理 MAC 地址。

规定网络地址的协议，叫做 IP 协议。它所定义的地址，就被称为 IP 地址。习惯上，我们用分成四段的十进制数表示IP地址，从 0.0.0.0 一直到 255.255.255.255。

IP 地址的前一部分代表网络，后一部分代表主机。比如，IP 地址 172.16.254.1，这是一个 32 位的地址，假定它的网络部分是前 24 位（172.16.254），那么主机部分就是后 8 位（最后的那个1）。处于同一个子网络的电脑，它们 IP 地址的网络部分必定是相同的，也就是说 172.16.254.2 应该与 172.16.254.1 处在同一个子网络。

但是，问题在于单单从 IP 地址，我们无法判断网络部分。还是以 172.16.254.1 为例，它的网络部分，到底是前 24 位，还是前 16 位，甚至前 28 位，从 IP 地址上是看不出来的。

"子网掩码" ，就是表示子网络特征的一个参数。它在形式上等同于 IP 地址，也是一个 32 位二进制数字，它的网络部分全部为 1，主机部分全部为 0。比如，IP 地址 172.16.254.1，如果已知网络部分是前 24 位，主机部分是后 8 位，那么子网络掩码就是 11111111.11111111.11111111.00000000，写成十进制就是 255.255.255.0。

知道 "子网掩码" ，我们就能判断，任意两个 IP 地址是否处在同一个子网络。方法是将两个 IP 地址与子网掩码分别进 行 AND 运算（两个数位都为 1，运算结果为 1，否则为 0），然后比较结果是否相同，如果是的话，就表明它们在同一个子网络中，否则就不是。

因为 IP 数据包是放在以太网数据包里发送的，所以我们必须同时知道两个地址，一个是对方的 MAC 地址，另一个是对方的 IP 地址。通常情况下，对方的IP地址是已知的（后文会解释），但是我们不知道它的 MAC 地址。

所以，我们需要一种机制，能够从 IP 地址得到 MAC 地址。

这里又可以分成两种情况。第一种情况，如果两台主机不在同一个子网络，那么事实上没有办法得到对方的 MAC 地址，只能把数据包传送到两个子网络连接处的"网关"（gateway），让网关去处理。

第二种情况，如果两台主机在同一个子网络，那么我们可以用 ARP 协议，得到对方的 MAC 地址。ARP 协议也是发出一个数据包（包含在以太网数据包中），其中包含它所要查询主机的IP地址，在对方的 MAC 地址这一栏，填的是 FF:FF:FF:FF:FF:FF，表示这是一个"广播"地址。它所在子网络的每一台主机，都会收到这个数据包，从中取出 IP 地址，与自身的 IP 地址进行比较。如果两者相同，都做出回复，向对方报告自己的 MAC 地址，否则就丢弃这个包。

有了 ARP 协议之后，我们就可以得到同一个子网络内的主机 MAC 地址，可以把数据包发送到任意一台主机之上了。

"端口"（port） 表示这个数据包到底供哪个程序（进程）使用。

"传输层"的功能，就是建立"端口到端口"的通信。相比之下，"网络层"的功能是建立"主机到主机"的通信。只要确定主机和端口，我们就能实现程序之间的交流。

在数据包中加入端口信息，这就需要新的协议。最简单的实现叫做 UDP 协议，它的格式几乎就是在数据前面，加上端口号。

UDP 数据包，也是由"标头"和"数据"两部分组成。

"标头"部分主要定义了发出端口和接收端口，"数据"部分就是具体的内容。

UDP 数据包非常简单，"标头"部分一共只有8个字节，总长度不超过 65,535 字节，正好放进一个 IP 数据包。

UDP 协议的优点是比较简单，容易实现，但是缺点是可靠性较差，一旦数据包发出，无法知道对方是否收到。

为了解决这个问题，提高网络可靠性，TCP 协议就诞生了。这个协议非常复杂，但可以近似认为，它就是有确认机制的 UDP 协议，每发出一个数据包都要求确认。如果有一个数据包遗失，就收不到确认，发出方就知道有必要重发这个数据包了。

因此，TCP 协议能够确保数据不会遗失。它的缺点是过程复杂、实现困难、消耗较多的资源。

TCP 数据包和 UDP 数据包一样，都是内嵌在 IP 数据包的"数据"部分。TCP 数据包没有长度限制，理论上可以无限长，但是为了保证网络的效率，通常 TCP 数据包的长度不会超过IP数据包的长度，以确保单个 TCP 数据包不必再分割。

"应用层"的作用，就是规定应用程序的数据格式。

举例来说，TCP 协议可以为各种各样的程序传递数据，比如 Email、WWW、FTP 等等。那么，必须有不同协议规定电子邮件、网页、FTP 数据的格式，这些应用程序协议就构成了"应用层"。

[图片上传失败...(image-ebc671-1558268545157)]

至此，整个互联网的五层结构，自下而上全部讲完了。

文章已经读到末尾了，不知道最初的几个问题你都会了吗？如果不会的话？可以再针对不会的问题进行精读哦！答案都在文中，相信你肯定可以解决的！

Q5: Android 网络编程之Socket理解

TCP/IP（Transmission Control Protocol/Internet Protocol，传输控制协议/网际协议）是指能够在多个不同网络间实现信息传输的协议簇。TCP/IP协议不仅仅指的是 TCP 和 IP 两个协议，而是指一个由 FTP 、 SMTP 、TCP、 UDP 、IP等协议构成的协议簇， 只是因为在TCP/IP协议中TCP协议和IP协议最具代表性，所以被称为TCP/IP协议。

互联网进行通信时，需要相应的网络协议，TCP/IP 原本就是为使用互联网而开发制定的协议族。因此，互联网的协议就是 TCP/IP，TCP/IP 就是互联网的协议。所以不要简单认为TCP/IP协议就是我们的网络请求http拿点东西，它是一个统称。

socket 的诞生是为了应用程序能够更方便的将数据经由传输层来传输，所以它本质上就是对 TCP/IP 的运用进行了一层封装，然后应用程序直接调用 socket API 即可进行通信。那么它是如何工作的呢？它分为 2 个部分，服务端需要建立 socket 来监听指定的地址，然后等待客户端来连接。而客户端则需要建立 socket 并与服务端的 socket 地址进行连接。

有图可以看出Socket是应用层跟传输层的桥梁，应用层通过socket api提供的方法来让数据流转到传输层。