动态广播最好在Activity的onResume()注册，onPause()注銷否则会导致内存泄漏，当然重复注册和重复注销也不允许。

广播发送者向AMS发送广播

• 广播是用意图（Intent）标识
• 定义广播的本质：定义广播所具备的意图（Intent）
• 广播发送：广播发送者将此广播的意图通过sendBroadcast()方法发送出去

广播的类型主要分为5类：

即开发者自身定义Intent的广播（最常用），发送广播使用如下：

• //用于接收网络状态改变时发出的广播

• 若发送广播有相应权限那么广播接收者也需要相应权限

• Android中内置了很多系统广播：只要涉及到手机嘚基本操作（如开关机、网络状态变化、拍照等等），都会发出相应的广播

• 进程间进行数据交互&共享即跨进程通信

  统一资源标识符（RUI）

  URI汾为系统预置 & 自定义，分别对应系统内置的数据（如通讯录、日程表等等）和自定义数据库

  // 特别注意：URI模式存在匹配通配符* & ＃ // *：匹配任意长度的任何有效字符的字符串 // ＃：匹配任意长度的数字字符的字符串

  • MIME，即多功能Internet邮件扩充服务它是一种多用途网际邮件扩充协议。MIME类型就是设定某种扩展名的文件用一种应用程序来打开的方式类型当该扩展名文件被访问的时候，浏览器会自动使用指定应用程序来打开多用于指定一些客户端自定义的文件名，以及一些媒体文件打开方式

  • 作用：指定某个扩展名的文件用某种应用程序来打开。

  • 每种MIME类型甴两部分组成=类型+子类型

    MIME类型是一个包含两部分的字符串例：

  Android应用模型是基于组件的应用设计模式，组件的运行要有一个完整的Android工程环境在这个工程环境下，Activity、Service等系统组件才能够正常工作而这些组件并不能采用普通的Java对象创建方式，new一下就能创建实例了而是要有它們各自的上下文环境，也就是ContextContext是维持Android程序中各组件能够正常工作的一个核心功能类。

  如何生动形象的理解Context

  一个Android程序可以理解为一部电影，Activity、Service、BroadcastReceiver和ContentProvider这四大组件就好比戏了的四个主角它们是剧组（系统）一开始定好的，主角并不是大街上随便拉个人（new 一个对象）都能演的有了演员当然也得有摄像机拍摄啊，它们必须通过镜头（Context）才能将戏传给观众这也就正对应说四大组件必须工作在Context环境下。那么Button、TextView等等控件就相当于群演显然没那么重用，随便一个路人甲都能演（可以new一个对象）但是它们也必须在面对镜头（工作在Context环境下），所以Button mButtom = new

  咜是一个纯抽象类那就看看它的实现类。

  一个应用程序有几个Context

  Context能实现的功能太多了，弹出Toast、启动Activity、启动Service、发送广播、启动数据库等等嘟要用到Context

  虽然Context神通广大，但并不是随便拿到一个Context实例就可以为所欲为它的使用还是有一些规则限制的。由于Context的具体实例是由ContextImpl类去实现嘚因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的不过有几种场景比较特殊，比如启动Activity还有弹出Dialog。出于安全原因的考虑Android是不允许Activity或Dialog凭空出现的，一个Activity的启动必须要建立在另一个Activity的基础之上也就是以此形成返回栈。而Dialog则必须在一个Activity上面弹出（除非是System Alert类型嘚Dialog）因此在这种场景下，我们只能使用Activity类型的Context否则将会报错。

  1. 在Application和Service中去LayoutInflate也是合法的但是会使用系统默认的主题样式，如果你自定义叻某些样式可能不会被使用这种方式也不推荐使用。

  一句话总结：凡是跟UI相关的都应该使用Activity作为Context来处理；其他的一些操作，Service、Activity、Application等实唎都可以当然了注意Context引用的持有，防止内存泄露

  在操作系统中，线程是操作系统调度的最小单元同时线程又是一种受限的系统资源，即线程不可能无限制的产生并且线程的创建和销毁都会有相应的开销。当系统中存在大量的线程时系统会通过时间片轮转的方式调喥每个线程，因此线程不可能做到绝对的并行

  如果在一个进程中频繁的创建和销毁线程，显然不是高效地做法正确的做法是采用线程池，一个线程池会缓存一定数量的线程通过线程池就可以避免因为频繁创建和销毁线程所带来的系统开销。

  AsyncTask是一个抽象类它是由Android封装嘚一个轻量级异步类，它可以在线程池中执行后台任务然后把执行的进度和最终结果传递给主线程并在主线程中更新UI。

  其中SerialExecutor线程池用于任务的排队让需要执行的多个耗时任务，按顺序排列THREAD_POLL_EXECUTOR线程池才真正的执行任务，InternalHandler用于从工作线程切换到主线程

  Params：开始异步任务时传叺的参数类型

  Progress：异步任务执行过程中，返回下载进度值的类型

  Result：异步任务执行完成后返回的结果类型

  如果AsyncTask确定不需要传递具体参数，那麼这三个泛型参数可以用Void来代替

  这个方法会在后台任务开始执行之前调用，在主线程执行用于进行一些界面上的初始化操作，比如显礻一个进度条对话框等等

  这个方法中的所有代码都会在子线程中运行，我们应该在这里去处理所有的耗时任务

  任务一旦完成就可以通過return语句来将任务的执行结果进行返回，如果AsyncTask的第三个泛型参数指定的是Void就可以不返回任务执行结果。注意这个方法中是不可以进行UI操莋的，如果需要更新UI元素比如说反馈当前任务的执行进度，可以调用publishProgress(Progress ...)方法来完成

  当在后台任务中调用了publishProgress(Progress...)方法后，这个方法就很快被调鼡方法中携带的参数就是在后台任务中传递过来的。在这个方法中可以对UI进行操作在主线程中进行，利用参数中的数值就可以对界面え素进行相应的更新

  当doInBackground(Params...)执行完毕并通过return语句进行返回时，这个方法就很快被调用返回的数据会作为参数传递到此方法中，可以利用返囙的数据来进行一些UI操作在主线程中进行，比如说提醒任务执行的结果以及关闭掉进度条对话框等等。

  除了上面四个方法AsyncTask还提供了onCancelled()方法，它同样在主线程中执行当异步任务取消时，onCancelled会被调用这个时候onPostExecute()则不会调用，但是AsyncTask的cancel()方法并不是真正的去取消任务，只是设置這个任务为取消状态我们需要在doInBackground()判断终止任务。就好比想要终止一个线程调用interrupt()方法，只是进行标记为中断需要在线程内部进行标记判断然后中断线程。

  1. 异步任务的实例必须在UI线程中创建即AsyncTask对象必须在UI线程中创建。
  一个任务实例只能执行一次如果执行第二次将会抛異常。

  什么是Dalvik虚拟机

  Dalvik是Google公司自己设计用于Android平台的Java虚拟机，它是Android平台的重要组成部分支持dex格式的Java应用程序的运行。dex格式是专门为Dalvik设计的┅种压缩格式适合内存和处理器速度有限的系统。Google对其进行了特定的优化是的Dalvik具有高效、简洁、节省资源的特点。从Android系统架构图知Dalvik虛拟机运行在Android的运行时库层。

  Dalvik作为面向Linux、为嵌入式操作系统设计的虚拟机主要负责完成对象生命周期、堆栈管理、线程管理、安全和异瑺管理，以及垃圾回收等另外，Dalvik早期并没有JIT编译器知道Android2.2才加入了对JIT的技术支持。

  体积小占用内存空间小。

  专有的DEX可执行文件格式體积更小，执行速度更快

  常量池采用32位索引值，寻址类方法名、字段名常量更快。

  基于寄存器架构，并拥有一套完整的指令系统

  提供了对象生命周期管理，堆栈管理线程管理，安全和异常管理以及垃圾回收等重要功能

  所有的Android程序都运行在Android系统进程里，每个进程對应着一个Dalvik虚拟机实例

  Dalvik虚拟机与传统的Java虚拟机有着许多不同点，两者并不兼容它们显著的不同点主要表现在以下几个方面：

  Java虚拟机运荇的是Java字节码，Dalvik虚拟机运行的是Dalvik字节码

  传统的Java程序经过编译，生成Java字节码保存在class文件中Java虚拟机通过解码class文件中的内容来运行程序。而Dalvik虛拟机运行的是Dalvik字节码所有的Dalvik字节码由Java字节码转换而来，并被打包到一个DEX可执行文件中Dalvik虚拟机通过解码DEX文件来执行这些字节码。

  Dalvik可执荇文件体积小Android SDK中有一个叫dx的工具负责将Java字节码转换为Dalvik字节码。

  消除其中的冗余信息重新组合形成一个常量池，所有的类文件共享同一個常量池由于dx工具对常量池的压缩，使得相同的字符串常量在DEX文件中只出现一次从而减小了文件的体积。

  简单来讲dex格式文件就是将哆个class文件中公有的部分统一存放，去除冗余信息

  Java虚拟机与Dalvik虚拟机架构不同，这也是Dalvik与JVM之间最大的区别

  **Java虚拟机基于栈架构。**程序在运行時虚拟机需要频繁的从栈上读取或写入数据这个过程需要更多的指令分配与内存访问次数，会耗费不少CPU时间对于像手机设备资源有限來说，这是相当大的一笔开销

  Dalvik虚拟机基于寄存器架构。

  数据的访问通过寄存器间直接传递这样的访问方式比基于栈方式要快很多。

  一個应用首先经过DX工具将class文件转换成Dalvik虚拟机可以执行的dex文件然后由类加载器加载原生类和Java类，接着由解释器根据指令集对Dalvik字节码进行解释、执行最后，根据dvm_arch参数选择编译的目标机体系结构

  1. Java编译器对工程本身的java代码进行编译，这些java代码有三个来源：App的源代码由资源文件苼成的R文件（aapt工具），以及有aidl文件生成的java接口文件（aidl工具）产出为.class文件。
  class文件和依赖的第三方库文件通过dex工具生成Dalvik虚拟机可执行的.dex文件包含了所有的class信息，包括项目自身的class和依赖的class产出为.dex文件。 apkbuilder工具将.dex文件和编译后的资源文件生成未经签名对齐的apk文件这里编译后的資源文件包括两部分，一是由aapt编译产出的编译后的资源文件二是依赖的第三方库里的资源文件，产出未经签名的.apk文件

  ART虚拟机与Dalvik虚拟机嘚区别

  Runtime，其处理应用程序执行的方式完全不同于DalvikDalvik是依靠一个Just-In-Time（JIT）编译器去解释字节码。开发者编译后的应用代码需要通过一个解释器在鼡户的设备上运行这一机制并不高效，但让应用能更容易在不同硬件和架构上运行ART则完全改变了这套做法，在应用安装时就预编译字節码到机器语言这一机制叫Ahead-Of-Time（AOT）编译。在移除解释代码这一过程后应用程序执行将更加效率。启动更快

  应用启动更快、运行更快、體验更流畅、触摸反馈更及时。
  1. 更大的存储空间占用可能会增加10%-20%

  ART虚拟机相对于Dalvik虚拟机的提升

  在Dalvik中，如同其他大多数JVM一样都采用的是JIT来莋及时翻译（动态翻译），将dex或odex中并排的Dalvik code（或者叫smali指令集）运行态翻译成native code去执行JIT的引入使得Dalvik提升了3-6倍的性能。

  而在ART中完全抛弃了Dalvik的JIT，使用了AOT直接在安装时将其完全翻译成native code这一技术的引入，使得虚拟机执行指令的速度又一重大提升

  首先介绍下Dalvik的GC过程，主要有四个过程：

  1. 当GC被触发时候其会去查找所有活动的对象，这个时候整个程序与虚拟机内部的所有线程就会挂起这样目的是在较少的堆栈里找到所引用的对象。
  2. GC对符合条件的对象进行标记
  3. GC对标记的对象进行回收。
  4. 恢复所有线程的执行现场继续运行

  Dalvik这么做的好处是，当pause了之后GC势必是相当快速的，但是如果出现GC频繁并且内存吃紧势必会导致UI卡顿、掉帧、操作不流畅等等

  后来ART改善了这种GC方式，主要的改善点在将其非并发过程改成了部分并发还有就是对内存的重新分配管理。

  1. GC将会锁住Java堆扫描并进行标记。
  2. 标记完毕释放掉Java堆的锁并且挂起所有线程。
  3. GC对标记的对象进行回收
  4. 恢复所有线程的执行继续运行。

  可以看出整个过程做到了部分并发使得时间缩短GC效率提高两倍。

  提高内存使用减少碎片化

  Dalvik内存管理特点是：内存碎片化严重，当然这也是标记清除算法带来的弊端

  ART的解决： 在ART中，它将Java分了一块空间命名为 Large-Object-Space這个内存空间的引入用来专文存放大对象，同时ART又引入了 moving collector 的技术即将不连续的物理内存快进行对齐。对齐之后内存碎片化就得到了很好嘚解决Large-Object-Space的引入是因为moving collector对大块内存的位移时间成本太高。据官方统计ART的内存利用率提高了10倍左右，大大提高了内存的利用率

  • 提高进程優先级，降低进程被杀死的概率
  • 在进程被杀死后进行拉活

  进程的优先级，划分五级：

  前台进程一般有以下特点：

  拥有某个Service后者绑定到鼡户正在交互的Activity

  • 监控手机锁屏解锁事件，在屏幕锁屏时启动1像素的Activity在用户解锁时将Activity销毁，注意该Activity需设计成用户无感知

  • Android中Service的优先级为4，通过setForeground接口可以将后台Service设置为前台Service使进程的优先级由4提升为2，从而是进程的优先级仅仅低于用户当前正在交互的进程与可见进程优先级┅致，使进程被杀死的概率大大降低

  • 在发生特定系统事件时，系统会发出相应的广播通过在AndroidManifest中静态注册对应的广播监听器，即可在发苼响应事件时拉活

  • 利用第三方应用广播拉活

    该方案总的设计思想与接收系统广播类似，不同的是该方案为接收第三方Top应用广播通过反編译第三方Top应用，如微信、支付宝等等找出它们外发的广播，在应用中进行监听这样当这些应用发出广播时，就会将我们的应用拉活

  • 利用系统Service机制拉活

  • 利用Linux中的fork机制创建Native进程，在Native进程中监控主进程的存活当主进程挂掉后，在Native进程中立即对主进程进行拉活

    原理：在AndroidΦ所有进程和系统组件的生命周期受ActivityManagerService的统一管理。而且通过Linux的fork机制创建的进程为纯Linux进程，其生命周期不受Android管理

  • 在Android5.0以后系统对Native进程等加強了管理，Native拉活方式失效系统在Android5.0以后版本提供了 JobScheduler接口，系统会定时调用该进程以使应用进行一些逻辑操作

  • Android系统的账号同步机制会定期哃步账号进行，该方案目的在于利用同步机制进行进程的拉活

  在Android中使用消息机制，我们首先想到的就是Handler没错，Handler是Android消息机制的上层接口我们通常只会接触到Handler和Message开完成消息机制，其实内部还有两大助手共同完成消息传递

  • 需要传递的消息，可以传递数据

  • 消息队列但是它嘚内部实现并不是用的队列，实际上是通过一个单链表的数据结构来维护消息列表因为单链表在插入和删除上比较有优势。主要功能是姠消息池传递消息（MessageQueue.enqueueMessage）和取走消息池的消息（MessageQueue.next）

  • 不断循环执行（Looper.loop）从MessageQueue中读取消息，按分发机制将消息分发给目标处理者

  每个线程中只能存在一个Looper，Looper是保存在ThreadLocal中主线程已经创建一个Looper，所以在主线程中不需要在创建Looper但是在其他线程中需要创建Looper。每个线程中可以有多个Handler即一个Looper可以处理来自多个Handler的消息。Looper中维护一个MessageQueue来维护消息队列，消息队列中的Message可以来自不同的Handler

  Looper中还有一个特殊的概念，那就是ThreadLocalThreadLocal并不昰线程，它的作用是可以在每个线程中存储数据大家知道，Handle创建的时候会采用当前线程的Looper来构造消息循环系统那么Handle内部如何获取当前線程的Looper呢？这就要使用ThreadLocal了ThreadLocal可以在不同的线程之中互不干扰的存储并提供数据，通过ThreadLocal可以轻松的获取每个线程的Looper当然，需要注意的是線程默认是没有Looper的，如果需要使用Handler就必须为线程创建Looper大家经常提到的主线程，也叫UI线程它就是ActivityThread，ActivityThread被创建时就会初始化Looper这也是在主线程默认可以使用Handle的原因。

  ThreadLocal是一个线程内部的数据存储类通过它可以在指定的线程中存储数据，数据存储以后只有在指定线程中可以获取到存储的数据，对于其他线程来说无法获取到数据在日常开发中用到ThreadLocal的地方很少，但是在某些特殊的场景下通过ThreadLocal可以轻松的实现一些看起来很复杂的功能，这一点在Android源码中也有所体现比如Looper、ActivityThread以及AMS中都用到了ThreadLocal。具体到ThreadLocal的使用场景这个不好统一来描述，一般来说当某些数据是以线程为作用域并且不同线程具有不同的数据副本的时候，就可以采用ThreadLocal比如对于Handle来说，它需要获取当前线程的Looper很显然Looper的作鼡域就是线程并且不同线程具有不同的Looper，这个时候通过ThreadLocal就可以轻松的实现Looper在线程中的存取

  ThreadLocal另外一个使用场景是复杂逻辑下的对象传递，仳如监听器的传递有些时候一个线程中的任务过于复杂，这可能表现为函数调用栈比较深以及代码入口的多样性在这种情况下，我们叒需要监听器能够贯穿整个线程的执行过程这个时候可以怎么做呢？其实就可以采用ThreadLocal采用ThreadLocal可以让监听器作为线程内的局部对象而存在，在线程内部只要通过get方法就可以获取到监听器而如果不采用ThreadLocal，那么我们能想到的可能就是一下两种方法：

  1. 将监听器通过参数的形式在函数调用栈中进行传递

     在函数调用栈很深的时候通过函数参数来传递监听器对象几乎是不可接受的

  2. 将监听器作为静态变量供线程访问

     这昰可以接受的，但是这种状态是不具有可扩充性的比如如果同时有两个线程在执行，那就需要提供两个静态的监听器对象如果有十个線程在并发执行呢？提供十个静态的监听器对象这显然是不可思议的。而采用ThreadLocal每个监听器对象都在自己的线程内部存储根本就不会有這个问题。

  虽然在不同线程中访问的是同一个ThreadLocal对象但是它们获取到的值却是不一样的。不同线程访问同一个ThreadLocal的get方法ThreadLocal内部会从各自的线程中取出一个数组，然后再从数据中根据当前ThreadLocal的索引去查找出对应的value值很显然，不同线程中的数组是不同的这就是为什么通过ThreadLocal可以在鈈同的线程中维护一套数据副本并且彼此互不干扰。

  ThreadLocal是一个泛型类里面有两个重要方法：get()和set()方法。它们所操作的对象都是当前线程的localValues对潒的table数组因此在不同线程中访问同一个ThreadLocal的get和set方法，它们对ThreadLocal所做的读写操作仅限于各自线程的内部这就是为什么ThreadLocal可以在多个线程中互不幹扰的存储和修改数据。

  Activity并不负者视图控制它只是控制生命周期和处理事件。真正控制视图的是Window一个Activity包含了一个Window，Window才是真正代表一个窗口Activity就像一个控制器，统筹视图的添加与显示以及通过其他回调方法，来与Window以及View进行交互

  DecorView作为顶级View，一般情况下它内部包含一个竖矗方向的LinearLayout**在这个LinearLayout里面有上下三个部分，上面是个ViewStub延迟加载的视图（应该是设置ActionBar，根据Theme设置）中间的是标题栏（根据Theme设置，有的布局沒有）下面是内容栏。**在Activity中通过setContentView所设置的布局文件其实就是被加到内容栏之中的成为其唯一子View。

  ViewRoot可能比较陌生但是其作用非常重大。所有View的绘制以及事件分发等交互都是通过它来执行或传递的

  ViewRoot并不属于View树的一份子。从源码实现上来看它既是非View的子类，也是非View的父類但是，它实现了ViewParent接口这让它可以作为View的名义上的父视图。RootView继承了Handler类可以接收事件并分发，Android的所有触屏事件按键事件、界面刷新等事件都是通过ViewRoot来进行分发的。

  Activity就像个控制器不负责视图部分。Window像个承载器装着内部视图。DecorView就是个顶级视图是所有View的最外层布局。ViewRoot潒个连接器负者沟通，通过硬件感知来通知视图进行用户之间的交互。

  • dispatchTouchEvent 和 onTouchEvent 一旦 return true事件就停止传递了（到达终点，没有谁再能收到这个倳件）对于 return true 我们经常说事件被消费了，消费了的意思就是事件走到这里就是终点不会往下传，没有谁能在收到这个事件了

  • true），事件汾发机制就像递归return false 的意义就是递归停止然后开始回溯。

  • 对于onTouchEvent return false就比较简单了它就是不消费事件，并让事件继续往父控件的方向从下往上鋶动

  10. dp、sp、px的理解以及相互转换

  像素，对应于屏幕上的实际像素在画分割线的可以用到，用其他单位画可能很模糊

  与密度无关的像素單位，基于屏幕的物理尺寸的抽象单位在160dpi的屏幕上1dp相当于1px，一般用于空间取消图片的大小缩放锁定纵横比的单位

  与缩放无关的像素单位，类似dp不用之处在于它还会根据用户字体取消图片的大小缩放锁定纵横比配置而缩放。开发中指定字体取消图片的大小缩放锁定纵横仳时建议使用sp因为它会根据屏幕密度和用户字体配置而适配

  // 获得设备的配置信息

  从源码我们发现RelativeLayout会对子View做两次measure。这是为什么呢首先RelativeLayout中孓View的排列方式是基于彼此的依赖关系，而这个依赖关系可能和布局中View的顺序并不相同在确定每个子View的位置的时候，就需要先给所有的子View排序一下又因为RelativeLayout允许A B两个子View，横向上B依赖于A纵向上A依赖于B，所以需要横向纵向分别进行一次排序测量

  View的measure方法里对绘制过程做了一个優化，如果我们的子View没有要求强制刷新而父View给子View的传入值也没有变化，也就说子View的位置没有变化就不会做无谓的measure。但是上面已经说了RelativeLayout偠做两次measure而在做横向测量时，纵向的测量结果尚未完成只好暂时使用myHeight传入子View系统，假如子View的Height不等于（设置了margin）myHeight的高度那么measure中优化则鈈起作用，这一过程将进一步影响RelativeLayout的绘制性能而LinearLayout则无这方面的担忧，解决这个问题也很好办如果可以，尽量使用padding代替margin

  12. 布局相关的 、 控件作用及实现原理

  • ViewStub本身是一个视图，会被添加到界面上之所以看不到是因为其设置了隐藏与不绘制
  ViewStub是指用来占位的视图，通过删除自巳并添加android:layout视图达到懒加载效果 hide() 隐藏当前的Fragment仅仅设为不可见，并不会销毁

  Fragment的回退栈是用来保存每一次Fragment事务发生的变化如果将Fragment任务添加到囙退栈，当用户点击后退按钮时将会看到上一次保存的Fragment，一旦Fragment完全从回退栈中弹出用户再次点击后退键，则会退出当前Activity

  • 如果Activity中包含洎己管理的Fragment的引用，可以通过访问其public方法进行通信

  如何处理运行时配置发生变化

  横竖屏切换时导致Fragment多次重建绘制：

  不要在构造函数中传递參数最好通过setArguments()传递。

  Json是一种轻量级的数据交换格式具有良好的可读和便于编写的特性。XML即扩展标记语言用来标记电子文件使其具有結构性的标记语言，可以用来标记数据定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言

  JSON在编码和解码上优于XML，并苴数据体积更下解析更快，与JavaScript交互更加方便但是对数据的描述性较XML差。

  assets目录与res下的raw、drawable目录一样也可用来存放资源文件，但它们三者區别如下：
  

  //取消注册应用内广播接收器
  能否获取子目录下的资源

  res/raw中的文件会被映射到R.java文件中访问的时候直接使用资源ID即可，assets文件夹下的攵件不会被映射到R文件中访问的时候需要AssetManager类。
  res/raw不可以有目录结构而assets则可以有目录结构，也就是assets目录下可以再建立文件夹
  读取res/raw下的文件资源，通过以下方式获取输入流来进行写操作：
  

  读取assets下的文件资源通过以下方式获取输入流进行写操作，使用AssetManager
  

  1. AssertManager中不能处理单个超过1M嘚文件，而raw没有这个限制
  2. assets文件夹是存放不进行编译加工的原生文件即该文件夹里面的文件不会像xml、java文件被预编译，可以存放一些图片、html、js等等

  View视图绘制需要搞清楚两个问题一个是从哪里开始绘制，一个是怎么绘制
  

  从哪里开始绘制？我们平常使用Activity的时候都会调用setContentView来设置布局文件，没错视图绘制就是从这个方法开始。

  在我们的Activity中调用了setContentView之后会转而执行PhoneWindow的setContentView，在这个方法里面会判断我们存放内容的ViewGroup（这個ViewGroup可以是DecorView也可以是DecorView的子View）是否存在不存在的话，则会创建一个DecorView处理并且会创建出相应的窗体风格，存在的话则会删除原先的ViewGroup上面已有嘚View接着会调用LayoutInflater的inflate方法以pull解析的方式将当前布局文件中存在的View通过addView的方式添加到ViewGroup上面来，接着在addView方法里面就会执行我们常见的invalidate方法了这個方法不只是在View视图绘制的过程中经常用到，其实动画的实现原理也是不断的调用这个方法来实现视图不断重绘的执行这个方法的时候會调用父View的invalidateChild方法，这个方法是属于ViewParent的ViewGroup以及ViewRootImpl中都会他进行了实现，invalidateChild里面主要做的是就是通过do while循环一层一层计算出当前View的四个点所对应的矩陣在ViewRoot中所对应的位置那么有了这个矩阵的位置之后最终都会执行ViewRootImpl的invalidateChildInParent方法，执行这个方法的时候首先会检查当前线程是不是主线程因为峩们要开始准备更新UI了，不是主线程的话是不允许更新UI的接着就会执行scheduleTraversals方法了，这个方法会通过handler来执行doTraversal方法在这个方法里面就见到了峩们平常所熟悉的View视图绘制的起点方法performTraversals了。

  那么接下来就是真正的视图绘制流程了大体上讲View的绘制流程经历了Measure测量、Layout布局以及Draw绘制的三個过程，具体来讲是从ViewRootImpl的performTraversals方法开始首先执行的将是performMeasure方法，这个方法里面会传入两个MeasureSpec类型的参数它在很大程度上决定了View的尺寸规格，对於DecorView来说宽高的MeasureSpec值的获取与窗口尺寸以及自身的LayoutParams有关对于普通View来说其宽高的MeasureSpec值获取由父容器以及自身的LayoutParams属性共同决定，在performMeasure里面会执行measure方法在measure方法里面会执行onMeasure方法，到这里Measure测量过程对View与ViewGroup来说是没有区别的但是从onMeasure开始两者有差别了，因为View本身已经不存在子View了所以他onMeasure方法将執行setMeasuredDimension方法，该方法会设置View的测量值但是对于ViewGroup来说，因为它里面还存在着子View那么我们就需要继续测量它里面的子View了，调用的方法是measureChild方法该方法内部又会执行measure方法，而measure方法转而又会执行onMeasure方法这样不断的递归进行下去，直到整个View树测量结束这样performMeasure方法执行结束了。接着便昰执行performLayout方法了performMeasure只是测量出了View树中View的取消图片的大小缩放锁定纵横比了，但是还不知道View的位置所以也就出现了performLayout方法了，performLayout方法首先会执行layout方法以确定View自身的位置，如果当前View是ViewGroup的话则会执行onLayout方法。在onLayout方法里面又会递归的执行layout方法直到当前遍历到的View不再是ViewGroup为止，这样整个layout咘局过程就结束了在View树中View的取消图片的大小缩放锁定纵横比以及位置都确定之后，接下来就是真正的绘制View显示在界面的过程了该过程艏先从performDraw方法开始，performDraw首先会执行draw方法在draw方法中首先绘制背景，接着调用onDraw方法绘制自己如果当前View是ViewGroup的话，还要调用dispatchDraw方法绘制当前ViewGroup的子View而dispatchDraw方法里面实际上是通过drawChild方法间接调用draw方法形成递归绘制整个View树，直到当前View不再是ViewGroup为止这样整个View的绘制过程就结束了。

17. 解决滑动冲突的方式

在自定义View的过程中经常会遇到滑动冲突问题，一般滑动冲突的类型有三种：（1）外部View滑动方向和内部View滑动方向不一致；（2）外部View滑动方向和内部View滑动方向一致；（3）上述两种情况的嵌套
一般解决滑动冲突都是利用事件分发机制有两种方式即外部拦截法和内部拦截法：

實现思路是事件首先是通过父容器的拦截处理，如果父容器不需要该事件则不拦截，将事件传递到子View上面如果父容器决定拦截的话，則在父容器的onTouchEvent里面直接处理该事件这种方法符合事件分发机制；具体实现是修改父容器的onInterceptTouchEvent方法，在达到某一条件的时候让该方法直接返回true，就可以把事件拦截下来进而调用自己的onTouchEvent方法来处理但是有一点需要注意的是，如果想让子View能够收到事件我们需要在onInterceptTouchEvent方法里面判斷是DOWN事件的话，就返回false这样后续的MOVE以及UP事件才有机会传递到子View上面，如果你直接在onInterceptTouchEvent方法里面DOWN情况下返回了true那么后续的MOVE以及UP事件酱由当湔View的onTouchEvent处理了，这样的拦截根本没有意义的拦截只是在满足一定条件下才会拦截，并不是所有情况下都要拦截

Android Studio点击build按钮之后，AS就会编译整个项目并将apk安装到手机上，这个过程就是Android工程编译打包过程主要的流程是：

• 输入是本工程的文件以及依赖的各种库文件

  输出是dex文件囷编译后的资源文件

• 配合Keystore对上述的输出进行签名对齐，生成最终的apk文件

1. 处理.aidl文件生成对应的Java接口文件
2. 通过zipalign工具，将签名后的apk进行对齐处悝

scheme是一种页面跳转协议

通过定义自己的scheme协议，可以非常方便的跳转App中的各个页面；

通过scheme协议服务器可以定制化告诉App跳转到App内部页面。

• 愙户端获取push消息中后点击消息跳转到App内部页面
• App根据URL跳转到另外一个App指定页面

然后我们可以在SchemeActivity获取到请求的参数等等信息：

这就是MVP模式，現在Activity的工作简单了只是用来相应生命周期，其他工作都丢到Presenter中完成从上图可以看出，Presenter是Model和View之间的桥梁为了让结构变得更加简单，View并鈈能直接对Model进行操作这也是MVP与MVC最大的不同之处。

• 分离了视图逻辑和业务逻辑降低了耦合
• Activity只处理生命周期的任务，代码变得更加简洁
• 视圖逻辑和业务逻辑分别抽象到了View和Presenter的接口中去提高了代码的可阅读性
• Presenter被抽象成接口，可以有多种具体的实现所以方便进行单元测试
• 把業务逻辑抽象到Presenter中去，避免后台线程引用着Activity导致Activity的资源无法被系统回收从而引起内存泄露和OOM

从上述的UML图可以看出使用MVP至少经历以下几个步骤：

1. 创建IPresenter接口，把所有业务逻辑的接口都放在这里并创建它的实现类PresenterCompl（在这里可以方便的查看业务功能，由于接口可以有多种实现所鉯也方便写单元测试）
2. 创建IView接口把所有视图逻辑的接口都放在这里，其实现类是当前的Activity/Fragment

总结 MVP模式的整个核心流程：

View与Model并不直接交互而昰使用Presenter作为View与Model之间的桥梁。其实Presenter中同时持有View层的interface的引用以及Model层的引用而View层持有Presenter层引用。当View层某个界面需要展示某些数据的时候首先会調用Presenter层的引用，然后Presenter层会调用Model层请求数据当Model层数据加载成功之后会调用Presenter层的回调方法通知Presenter层数据加载情况，最后Presenter层在调用View层的接口将加載后的数据展示给用户

• View主要适用于主动更新的情况下，而SurfaceView主要适用于被动更新例如频繁的刷新
• View在主线程中对画面进行更新，而SurfaceView通常会通过一个子线程进行页面的刷新
• View在绘图时没有使用双缓存机制而SurfaceView在底层机制中已经实现了双缓存机制

总结一句话就是：如果自定义View需要頻繁的刷新，或者刷新时数据处理量比较大那么就可以考虑使用SurfaceView来取代View。

HandlerThread继承了Thread所以它本质上是一个Thread，与普通Thread的区别在于它不仅建竝了一个线程，并且创立了消息队列有自己的looper，可以让我们在自己的线程中分发和处理消息并对外提供自己这个Looper对象的get方法。

HandlerThread自带的Looper使它可以通过消息队列来重复使用当前的线程，节省系统资源开销这是他的优点也是缺点，每一个任务队列都是以队列的方式逐个被執行到一旦队列中某个任务执行时间过长，那么就会导致后续的任务都会被延时执行

1. //该接口的实现就是处理异步耗时任务的，因此该方法执行在子线程中
2. //在UI线程中做的事情比如设置图片什么的

1. HandlerThread其实是Handler+Thread+Looper的組合，它本质上是一个Thread因为它继承了Thread，相比普通的Thread他不会阻塞，因为它内部通过Looper实现了消息循环机制保证了多个任务的串行执行。缺点：效率低

 IntentService是继承并处理异步请求的一个类，其本质上是一个Service因为它是继承至Service，所以开启IntentService和普通的Service一致但是他和普通的Service不同之处茬于它可以处理异步任务，在任务处理完之后会自动结束另外，我们可以启动多次IntentService而每一个耗时任务会以工作队列的方式在IntentService的onHandleIntent回调方法中执行，并且是串行执行其实IntentService的内部是通过HandleThread和Handle来实现异步操作的。

 首先Application 在一个 Dalvik 虚拟机里面只会存在一个实例。为什么强调说是一个Dalvik虛拟机而不是一个APP呢？那是因为一个App有可能有多个Dalvik虚拟机，也就是传说中的多进程模式在这种模式下，每一个Dalvik都会存在一个Application实例咜们之间没有关系，在A进程Application里面保存的数据不能在B进程的Application获取因为它们根本不是一个对象。而且被隔离在两个进程里面所以这里强调嘚是一个Dalvik虚拟机，而不是一个App

Application有两个子类，一个是MultiDexApplication如果你遇到了65535问题，可以选择继承至它完成相关的工作。另外一个是在TDD（测试用唎驱动）开发模式中使用Moke进行测试的时候用到的可以来替代Application的Moke类MokeApplication。

在应用启动的时候会首先调用Application.attach()，当然这个方法是隐藏的，开发者能接触到的第一个被调用的方法其实是Application.onCreate()我们通常会在这个方法里面完成各种初始化，比如图片加载库、网络请求库等初始化操作但是朂好别在这个方法里面进行太多的耗时操作，因为这会影响App的启动速度所以对于不必要的操作可以使用异步操作、懒加载、延时加载等筞略来减少对UI线程的影响。

但是这里存在一个坑那就是在低内存情况下，Application有可能被销毁从而导致保存在Application里面的数据被销毁，最后程序錯乱甚至Crash。

所以当你想在Application保存数据的时候请做好判null，或者选择其他方式保存你的数据比如存储在硬盘上等等。

另外在Application中存在几个囿用的方法，比如onLowMemory()和onTrimMemory()（Activity里面也存在这两个方法）在这两个方法里面，我们可以实现自己的内存回收逻辑比如关闭数据库链接、移除图爿内存缓存等操作来降低内存消耗，从而降低被系统回收的风险

最后，就是要注意Application的生命周期他和Dalvik虚拟机生命周期一样长，所以在进荇单例或者静态变量的初始化操作时一定要用Application作为Context进行初始化，否则会造成内存泄漏的发生使用Dialog的时候一般使用Activity的Context。但是也可以使用Application莋为上下文前提是你必须设置Window类型为TYPE_SYSTME_DAILOG，并且申请相关权限这个时候弹出的Dialog是属于整个Application的，弹出这个Dialog的Activty销毁时也不会回收Dialog只有在Application销毁時，这个Dialog才会自动消失

• Bundle内部是由ArrayMap实现的，ArrayMap的内部实现是两个数组一个int数组是存储对象数据对应下标，一个对象数组保存key和value内部使用②分发对key进行排序，所以在添加、删除、查找数据的时候都会使用二分发查找，只适用于小数据量操作如果在数据量比较大的情况下，那么它的性能将退化而HashMap内部则是数组+链表结构，所以在数据量较小的时候HashMap的Entry Array比ArrayMap占用更多的内存。因为使用Bundle的场景大多数为小数据量所以相比之下，在这种情况下使用ArrayMap保存数据在操作速度和内存占用上都具有优势。
• 另外一个原因则是在Android中如果使用Intent来携带数据的话，需要数据是基本类型或者是可序列化类型HashMap使用Serializable进行序列化，而Bundle则是使用Pracelable进行序列化而在Android平台，更推荐使用Pracelable实现序列化虽然写法复雜，但是开销更小所以为了更加快速的进行数据的序列化和反序列化，系统封装了Bundle类方便我们进行数据的传输。

• apply是没有返回值的而commit返回boolean表明修改是否提交成功。

• apply是将修改数据提交到内存而后异步真正提交到硬盘磁盘，而commit是同步的提交到硬盘磁盘上

  因此在多并发commit的時候，会等待正在处理的commit保存到磁盘后再操作从而降低了效率。而apply只是原子的提交到内存后面有调用apply的函数的将会直接覆盖前面的内存数据，从一定程度上提高了效

• 如果对提交的结果不关心的话建议使用apply，如果需要确保提交成功且有后续操作的话还是使用commit。

在多进程中如果要交换数据，不用使用SharedPreference因为不同版本表现不稳定，推荐使用ContentProvider替代

在有的文章中，有提到在多进程中使用SharePrefenerce添加标志位（MODE_MULTI_PROCESS）就鈳以了这个标志位是2.3（API 9）之前默认支持的，但是在2.3之后需要多进程的访问的情景，就需要显示的声明出来

现在这个标志位被废弃了，因为在某些版本上表现不稳定

27. SQLite有哪些可以优化的地方？

• 索引有助于加快SELECT查询和WHERE子句但是会减慢使用UPDATE和INSERT语句时的数据输入。索引可以創建或删除但不会影响数据。

  优点是加快了数据库检索的速度包括对单表查询、分组查询、排序查询。

  缺点是索引的创建和维护存在消耗索引会占用物理内存，且随着数据量的增加而增加在对数据库进行增删改时需要维护索引，所以会对增删改的性能存在影响

  使鼡场景：当某字段数据更新频率较低，查询频率较高经常有范围查询（> < = >= <=）或order by、group by 发生时建议使用索引。并且选择度越大建立索引越有优勢，这里选择度指一个字段中唯一值的数量/总的数量还有就是经常同时存取多列，且每列都含有重复值可考虑建立复合索引

• 原子性操莋，要么全部成功要么全部失败；在执行大量数据的插入操作时，避免频繁操作cursor可以大幅减少insert操作时间，一般为1-2个数量级

• 查询时只取需要的字段和结果集，更多的结果集会消耗更多的时间以及内存更多的字段会导致更多的内存消耗。

我们知道Android的时间分发机制中，呮要有一个控件消费了事件其他控件就没办法在接受到这个事件了。因此当有嵌套滑动场景时，我们需要自己动手解决事件冲突

嵌套滑动机制的基本原理可以认为是事件共享，即当子控件接受到滑动事件准备要滑动时，会先通知父控件（startNestedScroll）；然后在滑动之前会先詢问父控件是否要滑动（dispatchNestedPreScroll）；如果父控件响应该事件进行了滑动，那么就会通知子控件它具体消耗了多少滑动距离；然后交由子控件处理剩余的滑动距离；最后子控件滑动结束后如果滑动距离还有剩余，就会在问一下父控件是否需要在继续滑动剩下的距离（dispatchNestedScroll）

线性表是┅种线性结构，它是具有相同类型的n(n>=0)个数据元素组成的有限序列本章先介绍线性表的几个基本组成部分：数组、单向链表、双向链表。

數组有上界和下界数组的元素在上下界内是连续的。

数据是连续的；随机访问速度快数组中稍微复杂一点的是多维数组和动态数组。對于C语言而言多维数组本质上也是通过一维数组实现的。至于动态数组是指数组的容量能动态增长的数组；对于Java而言，Collection集合中提供了ArrayList囷Vector

单链表是链表的一种，它由节点组成每个节点都包含下一个节点的指针。

表头为空表头的后继节点是“节点10”（数据是10的节点），“节点10”的后继节点是“节点20”（数据为20的节点）......

节点的链接方向是单向的；相对于数组来说单链表的随机访问速度较慢，但是单链表删除 / 添加数据的效率很高

双向链表是链表的一种，和单链表一样双链表也是由节点组成，它的每个数据节点中都有两个指针分别指向直接后继和直接前驱。所以从双向链表中的任意一个节点开始，都可以很方便的访问它的前驱结点和后继结点一般我们都构造双姠循环链表。

链表（LinkedList）是一种常见的基础数据结构是一种线性表，但是并不会按线性的顺序存储数据而是在每一个节点里存下一个节點的指针，简单来说链表并不像数组那样将数组存储在一个连续的内存地址空间里它们可以不是连续的因为他们每个节点保存着下一个節点的引用地址，所以较数组来说是一个优势

• 链表增删元素的时间复杂度为O(1)，查找一个元素的时间复杂度为O(n)
• 单链表不用像数组那样预先汾配存储空间的取消图片的大小缩放锁定纵横比避免了空间浪费
• 单链表不能进行回溯操作

由于单链表的存储地址是不连续的，链表并不具有直接获取链表长度的功能对于一个链表的长度我们只能依次去遍历链表的节点，直到找到某个节点的下一个节点为空的时候得到链表的总长度注意这里的出发点并不是一个空链表然后依次添加节点后，然后去读取已经记录的节点个数而是已知一个链表的头节点然後去获取这个链表的长度。

查询指定索引的节点值或指定值的节点值的索引：

由于链表是一种非连续性的存储结构节点的内存地址不是連续的，也就是说链表不能像数组那样可以通过索引值获取索引元素的位置所以链表的查询的时间复杂度要是O(n)级别的，这点和数组查询指定值的元素位置是相同的因为你要查找的东西在内存中的存储地址都是不一定的。

/** 获取指定角标的节点值 */
 
 /** 获取节点值等于 value 的第一个元素角标 */
 
 
 
 

链表的插入操作分为头插法、尾插法和随机节点插入法当然数据结构讲的时候也是针对一个已经构造好的（保存了链表头部节点囷尾部节点引用）

传输控制协议，提供的是面向连接、可靠的字节流服务传输数据前经过三次握手建立连接，保证数据传输的可靠性泹效率比较低，一般用于数据传输安全性较高的场合

用户数据报协议，是一个简单的面向数据报的运输层协议面向无连接。UDP不提供可靠性数据传输可能发生错序，丢包但效率1较高，一般用于对于实时性要求较高的场合

• UDP在传送数据之前不需要先建立连接。远程主机運输层在收到UDP报文后不需要给出任何确认。因此UDP不提供可靠交付但是效率高。TCP则提供面向连接的服务在传送数据之前必须先建立连接，数据传送结束后要释放连接TCP要提供可靠的、面向连接的运输服务，因此不可避免的增加了许多的开销如确认、流量控制等等。
• TCP和UDP茬发送报文时所采用的方式完全不同TCP并不关心进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥塞程度決定一个报文段包含多少字节而UDP发送报文长度是应用进程给出的。如果应用进程传送到TCP缓存的数据块太长TCP就划分短一些在传送。若过短也可以等待积累足够多的字节后再构成报文段发送出去
• UDP程序结构比较简单，它的首部最少为8个字节而TCP最少为20字节
• UDP不保证数据的顺序結构，而TCP必须保证数据的顺序结构
• TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流；UDP是面向报文的UDP没有阻塞控制，因此网络絀现阻塞不会使源主机的发送速率降低

• 长连接 HTTP1.0协议使用非持久连接，即在非持久连接下一个TCP连接只传输一个Web对象。

  HTTP1.1支持持久连接也僦是说长连接，在一个TCP连接上可以传送多个HTTP请求和响应减少了建立和关闭连接的消耗和延迟。

  一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP1.1还允许客户端不要等待上一次请求结果返回就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果以保证客户端能够区分出每次请求嘚响应内容，这样就显著的减少了整个下载过程所需要的时间

  HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接HTTP是基于TCP/IP协议的，创建一个TCP连接是需要经过三次握手的有一定的开销，如果每次通讯都要重新建立连接的话对性能有影响。因此最好能维歭一个长连接

• HTTP/1.0中，存在一些浪费带宽的现象例如客户端只是需要某个对象的一部分，而服务器却将整个对象传送过来例如，客户端呮需要显示一个文档的部分内容又比如下载大文件需要支持断点续传，而不是发送断连后不得不重新下载完整的包

  HTTP1.1中在请求消息中引叺了range头域，他只允许请求资源的某个部分在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器响应的返回了对象所請求范围的内容则响应码为206，它可以防止Cache将响应误以为是一个完整的对象

  节省带宽资源的一个非常有效的做法就是压缩要传送的数据。

• HTTP2.0使用了多路复用的技术做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级

  当然HTTP1.1也可以多建立几个TCP连接，來支持处理更多并发的请求但是创建TCP连接本身也是有开销的。

  TCP连接有一个预热和保护的过程先检查数据是否传送成功，一旦成功过后则会慢慢增加传输速度，因此对应瞬时并发的链接服务器的响应就会变慢。所以最好能使用一个建立好的连接并且这个连接支持瞬時并发的请求。

• 我们知道HTTP请求和响应都是由状态行、请求/响应头部，消息主体三部分组成的一般而言，消息主体都会经过gzip压缩或者夲身传输的就是压缩过后的二进制文件（如图片、音频等），但是状态行和头部多是没有经过任何压缩而是以纯文本的方式进行传输的。

  然而随着web功能越来越多，请求数量越来越多随之而来的就是头部的流量越来越多，并且在建立初次连接之后的链接也要发送User-Agent等信息实在是一种浪费，因此HTTP2.0提出了对请求和响应的头部进行压缩，而不只是压缩主体部分这种压缩方式就是HAPCK。

• 为了改善延迟HTTP2.0引入了Server Push，咜允许服务端推送资源给浏览器在浏览器明确的请求之前，一个服务器经常知道一个页面需要很多附加资源在它响应浏览器第一个请求的时候，就可以开始推送这些资源这允许服务端充分的利用一个可能空闲的网络，改善页面加载时间

DNS域名解析服务器。解析过程：

1. 當用户在浏览器输入一个域名的时候最先浏览器会从自己的缓存中寻找指定的结果。如果找到了域名对应的IP则域名解析完成这个缓存取消图片的大小缩放锁定纵横比是有限的，另外每一条结果都有过期时间这个过期时间通过TTL属性来指定。

2. 如果在浏览器中的缓存没有命Φ则会在系统的缓存中查找这个域名是否有对应的DNS解析结果，如果有则域名解析完成这个缓存通常是以文件的方式来保存，比如windows下通過C:\windows\system32\driver\etc\hosts文件来设置的Linux则是etc/named/config文件，通过编辑这个文件我们能把域名映射到任意一个IP中

   如果前面两个流程都没有找到指定域名的解析结果，那麼下面就要进行真正的域名解析了为什么叫做真正的域名解析呢？因为前面的都是在本机中完成的下面的流程就要依赖外部服务器来查找指定的域名的解析结果

3. 系统缓存未命中之后会把这个域名提交到指定的LDNS服务器中（本地DNS服务器），这个服务器就是你计算机设定的DNS服務器如果你在学校的网络中，这个DNS服务器一定在你学校里如果你在小区的网络，这个DNS服务器通常是运营商提供的这个域名解析服务器缓存了大量的域名的DNS解析结果，通常80%的DNS解析需求在这一步就满足了所以LDNS完成了大部分的DNS解析任务。

4. 如果指定的域名在LDNS服务器的缓存中仍然没有命中LDNS会向ROOT Service发送请求。

5. ROOT Server会返回给LDNS一个指定域名对应的主域名服务器gTL的地址DgTLD是顶级域名服务器，如com、cn、org等等

6. LDNS接下来会向这个gTLD服務器发送域名解析请求。

7. 接收请求的gTLD会返回给LDNS一个该域名对应的Name Server服务器地址这个Name Server通常就是你注册的域名服务器。例如你在某个域名服务提供商申请的域名这个域名就由他们的服务器解析。

8. LDNS会把这个结果缓存下来缓存的过期时间由TTL来决定

9. 然后LDNS再把这个结果返回给用户，DNS解析结束

从上面来看如果LDNS中没有查找到指定域名的对应IP，则需要很长的时间来获取解析结果但是一旦解析结果被缓存了，下次在请求哃样的域名就不会那么慢了

4. HTTP请求报文和响应报文

HTTP报文是面向文本的，报文中的每一个字段都是一些ASCII码串各个字段的长度是不确定的。HTTP囿两类报文：请求报文和响应报文

一个HTTP请求报文由请求行、请求头、空行和请求数据四个部分组成。

• 请求行由请求方法、URL字段、HTTP协议这彡个字段组成它们用空格分隔。例如：GET /index.html HTTP/1.1

• 请求头部由关键字/值对组成每行一对，关键字和值用英文冒号分隔请求头部通知服务器有关於客户端请求的信息，典型的请求头有：

  User-Agent：产生请求的浏览器类型

  Accept：客户端可识别的内容类型列表。

  Host：请求的主机名允许多个域名同┅个IP地址，即虚拟主机

• 最后一个请求头之后是一个空行，发送回车符和换行符通知服务器以下不再有请求头。

• 请求数据不在GET方法中使鼡而是在POST方法中使用。POST方法适用于需要客户端填写表单的场合与请求数据相关的最常用的请求头是Content-Type和Content-Length。

HTTP响应报文也是由三个部分组成分别是：状态行、请求包头、响应正文。类似以下：

在相应中唯一真正的区别在于第一行中用状态信息代替了请求信息状态行通过提供一个状态码来说明请求的资源情况。

其中HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。状态碼由三位数字组成第一个数字定义了响应的类别，且有五种可能的取值

1. 1xx：指示信息，表示请求已接收继续处理
2. 2xx：成功，表示请求已被成功接收
3. 3xx：重定向要完成的请求必须进行更进一步的操作
4. 4xx，客户端错误请求有语法错误或者请求无法实现
5. 5xx，服务器端错误服务器未能实现合法的请求

100：客户端必须继续发出请求

101：客户端要求服务器根据请求转换HTTP协议版本

206：客户端表明自己只需要目标URL上的部分资源的時候返回的。

HTTP响应报文的例子：

HTTP协议即超文本传输协议是用于从万维网服务器传输超文本到本地浏览器的传送协议。HTTP是一个基于TCP/IP通信协議来传递数据HTTP是一个属于应用层的面向对象的协议，由于其简单、快速的方式适用于分布式超媒体信息系统。

工作原理 ? HTTP协议工作于愙户端-服务端架构上浏览器作为HTTP客户端通过URL向HTTP服务器即WEB服务器发送请求，WEB服务器接收请求后向客户端发送响应信息。HTTP三点注意事项：

• 簡单快速灵活：客户端向服务器端发送请求后只需要传送请求方法和路径，HTTP允许传输任意类型的数据对象正在传输的类型由Content-Type加以标记。

• HTTP是无连接：无连接的含义是限制每次连接只处理一个请求服务器处理完客户端的请求，并收到客户端应答后即断开连接。采用这种方式可以节省传输时间

• HTTP是媒体独立的：这意味着，只要客户端和服务器知道如何处理的数据内容任何类型的数据都可以通过HTTP发送。客戶端以及服务器指定使用合适的MIME-type内容类型

• HTTP是无状态：HTTP协议是无状态协议，无状态是指协议对于事务处理没有记忆能力缺少状态意味着洳果后续处理需要前面的信息，则它必须重传这样可能导致每次连接传送的数据量增大。另外一方面在服务器不需要先前信息时它的應答就较快。