第一章浏览器架构
1、浏览器架构演进
·单进程架构：所有模块运行在同一个进程里，包含网络、插件、JavaScript运行环境等
·多进程架构：主进程、网络进程、渲染进程、GPU进程、插件进程
·面向服务架构：将原来的UI、数据库、文件、设备、网络等，作为一个独立的基础服务
2、比较分析
·单进程架构存在不稳定、不流畅、不安全的问题
·多进程架构解决单进程架构存在的缺点，但也有明显缺点。一是每开一个进程都不得不分配公共基础架构的副本，分配一定的内存空间，导致了内存占用非常大，这一点我们也可以通过任务管理器观察到。二则这也带来了架构的复杂性。并且各个模块之间耦合程度比较大，容易导致扩展性差。
·面向服务的架构将模块抽象为服务，提供接口，通过 IPC 进行通信，达到了松耦合、高可维护性以及高扩展性的效果。在资源有限的情况下，浏览器会灵活的整合服务到一个进程中，避免资源浪费。
第二章渲染过程
渲染进程-多线程工作流程
- 网络线程负责加载网页资源
2.JS引擎解析JS脚本并且执行
3.JS解析引擎空闲时，渲染线程立即工作
4.用户交互、定时器操作等产生回调函数放入任务队列中
5.事件线程进行事件循环，将队列里的任务取出交给JS引擎执行
第三章Chrome运行原理
1、处理输入
当用户开始在导航栏上面输入内容的时候，UI线程（UI thread）做的第一件事就是询问：“你输入的字符串是一些搜索的关键词（search query）还是一个URL地址呢？”
2、开始导航
当用户按下回车键的时候，UI线程会叫网络线程（network thread）初始化一个网络请求来获取站点的内容。这时候tab上会展示一个提示资源正在加载中的旋转圈圈，而且网络线程会进行一系列诸如DNS寻址以及为请求建立TLS连接的操作。这时如果网络线程收到服务器的HTTP 301重定向响应，它就会告知UI线程进行重定向然后它会再次发起一个新的网络请求。
3、读取响应
网络线程在收到HTTP响应的主体（payload）流（stream）时，在必要的情况下它会先检查一下流的前几个字节以确定响应主体的具体媒体类型（MIME Type）。响应主体的媒体类型一般可以通过HTTP头部的Content-Type来确定，不过Content-Type有时候会缺失或者是错误的，这种情况下浏览器就要进行MIME类型嗅探来确定响应类型了。MIME类型嗅探并不是一件容易的事情，你可以从Chrome的源代码的注释来了解不同浏览器是如何根据不同的Content-Type来判断出主体具体是属于哪个媒体类型的。
4、寻找一个渲染进程
在网络线程做完所有的检查后并且能够确定浏览器应该导航到该请求的站点，它就会告诉UI线程所有的数据都已经被准备好了。UI线程在收到网络线程的确认后会为这个网站寻找一个渲染进程（renderer process）来渲染界面。
5、提交导航
到这一步的时候，数据和渲染进程都已经准备好了，浏览器进程（browser process）会通过IPC告诉渲染进程去提交本次导航（commit navigation）。除此之外浏览器进程还会将刚刚接收到的响应数据流传递给对应的渲染进程让它继续接收到来的HTML数据。一旦浏览器进程收到渲染线程的回复说导航已经被提交了（commit），导航这个过程就结束了，文档的加载阶段（document loading phase）会正式开始。
第四章跨端容器
1、跨端容器-通用原理
·UI组件
·渲染引擎
·逻辑控制引擎
·通信桥梁
·底层API抹平表现差异
2、跨端容器-使用WebView优势
·一次开发，处处使用，学习成本低
·随时发布，即时更新，不用下载安装包
·移动设备性能不断提升，性能有保障
·通过JSBridge和原生系统交互，实现复杂功能
