青训营笔记|客户端容器

一、浏览器架构

浏览器架构演进

1.单进程架构：所有模块运行在同一个进程里，包括网络、插件、JavaScript运行环境等
2.多进程架构：主进程、网络进程、渲染进程、GPU进程、插件进程
3.面向服务架构：将原来得UI、数据库、文件、设备、网络等，作为一个独立得基础服务

浏览器架构对比

浏览器架构-多进程分工

问题1:为什么会有单进程架构？

	单进程架构是一种计算机系统的设计方式，它在单个进程内运行所有的应用程序和服务，而不是将它们分配到多个进程中。这种设计方式具有以下优点：
	资源利用率高：单进程架构可以最大化利用计算机系统的资源，因为所有应用程序和服务都共享同一个进程。这样可以避免不同进程之间的资源竞争和浪费。
    简化管理和维护：单进程架构简化了系统的管理和维护，因为只需要管理一个进程，而不需要考虑多个进程之间的通信和同步问题。
    提高系统稳定性：单进程架构可以提高系统的稳定性，因为不同应用程序和服务之间的错误不会相互干扰。如果一个应用程序或服务崩溃，其他应用程序和服务不会受到影响。
    更高的安全性：单进程架构可以提高系统的安全性，因为不同应用程序和服务之间的通信和交互都是在同一个进程内完成的。这样可以避免因为进程间通信导致的安全漏洞。
总之，单进程架构在资源利用率、管理和维护、系统稳定性以及安全性等方面都具有优势。但是，它也存在一些缺点，比如不适用于大规模复杂的系统，因为单个进程可能无法处理太多的应用程序和服务。

问题2:面向服务架构是否会替代多进程架构

	面向服务架构（Service-Oriented Architecture，SOA）和多进程架构是两种不同的架构设计方式，它们都有其独特的优缺点和应用场景。
	SOA强调通过将不同的功能模块封装成服务，使得应用程序可以通过网络进行跨系统的通信和交互，从而实现系统间的集成和协同。SOA的优点是可以促进系统的松耦合和可维护性，同时也能够支持分布式部署和灵活的服务组合，使得系统更具弹性和可扩展性。
	多进程架构则是一种传统的架构设计方式，它将不同的应用程序和服务分配到不同的进程中运行，以实现不同模块之间的隔离和独立性。多进程架构的优点是可以通过进程间通信实现不同模块之间的协同，同时也能够利用操作系统的多进程支持，使得系统更具可靠性和稳定性。
	因此，SOA和多进程架构并不是互相排斥的关系，它们可以根据不同的应用场景和需求相互结合和补充。在一些大型分布式系统中，可以采用SOA来实现跨系统的集成和协同，同时也可以使用多进程架构来实现模块内的隔离和独立性。而在一些小型应用中，可能只需要采用多进程架构或者SOA的某些特性来实现系统的设计和实现。因此，SOA不一定会替代多进程架构，它们可以相互结合和选择。

二、渲染进程

常见浏览器内核

渲染进程-多线程架构

内部是多线程实现，主要负责页面渲染，脚本执行，事件处理，网络请求等

渲染进程-多线程工作流程

1.网络线程负责加载网页资源
2.JS引擎解析JS脚本并且执行
3.JS解析引擎空闲时，渲染线程立即工作
4.用户交互、定时器操作等产生回调函数放入任务队列中
5.事件线程进行事件循环，将队列里得任务取出交给JS引擎进行执行

三、Chrome运行原理

Chrome运行原理-输入处理

1.用户输入内容后，UI线程会判断输入的是一个URL地址还是一个query查询条件
2.如果是URL，直接请求站点资源
3.如果是query，将输入发送给引擎

Chrome运行原理-读取响应

1.网络线程接收到HTTP响应后，先检查响应头的媒体类型 (MIME Type）
2.如果响应主体是一个HTML文件，浏览器将内容交给渲染进程处理
3.如果拿到的是其他类型文件，比如Zipexe等，则交给下载管理器处理

Chrome运行原理-寻找渲染进程

1.网络线程做完所有检查后，会告知主进程数据已准备完毕，主进程确认后为这个站点寻找一个渲染进程
2.主进程通过IPC消息告知渲染进程去处理本次导航
3.渲染进程开始接收数据并告知主进程自己已开始处理，导航结束，进入文档加载阶段

渲染进程-资源加载

收到主进程的消息后，开始加载HTMML文档
除此之外，还需要加载子资源，比如一些图片，CSS样式文件以及JavaScript脚本

渲染进程-构建渲染树

构建DOM树，将HTML文本转化成浏览器能够理解的结构
构建CSSOM树，浏览器同样不认识CSS，需要将CSS代码转化为可理解的CSSOM
构建渲染树，渲染树是DOM树和CSSOM树的结合

渲染进程-页面布局

根据渲染树计算每个节点的位置和大小
在浏览器页面区域绘制元素边框
遍历渲染树，将元素以盒模型的形式写入文档流

渲染进程-页面绘制

构建图层:为特定的节点生成专用图层
绘制图层:一个图层分成很多绘制指令，然后将这些指令按顺序组成一个绘制列表，交给合成线程
合成线程接收指令生成图块
栅格线程将图块进行栅格化
展示在屏幕上

首屏优化

压缩、分包、删除无用代码
静态资源分离
JS脚本非阻塞加载
缓存策略
SSR
预置loading、骨架屏

渲染优化

GPU加速
减少回流、重绘
离屏渲染
懒加载

JS优化

防止内存泄漏
循环尽早break
合理使用闭包
减少Dom访问
防抖、节流
Web Workers

四、跨端容器

为什么要跨端

	跨端的目的是为了让应用程序能够覆盖更广泛的用户群体，从而增加应用程序的受众。
	跨端还可以提高开发效率和降低开发成本。如果只开发单一平台的应用程序，则需要为每个不同的平台编写不同的代码。这不仅费时费力，而且成本高昂。跨端技术可以让开发人员使用一种语言、一组工具和一套代码库来开发应用程序，从而减少开发时间和成本。
	此外，跨端技术还可以增强应用程序的可靠性和可维护性。使用跨端技术可以确保应用程序在不同平台上的表现和功能都是一致的，减少了因为平台差异导致的问题。

有哪些跨端方案

webview、小程序、RN/WeeX、Lynx、Flutter等

跨端容器-WebView

Webview，即网页视图，用于加载网页Url，并展示其内容的控件
可以内嵌在移动端App内，实现前端混合开发，大多数混合框架都是基于Webview的二次开发，比如lonic、Cordova

跨端容器-常用的WebView分类

跨端容器-使用WebView优势

一次开发，处处使用，学习成本低
随时发布，即时更新，不用下载安装包
移动设备性能不断提升，性能有保障
通过]SBridge和原生系统交互，实现复杂功能

跨端容器-WebView使用原生能力

Javascript 调用Native
	API注入: Native获取Javascript环境上下文，对其挂载的对象或者方法进行拦截
	使用Webview URL Scheme 跳转拦截
 	IOS上 window.webkit.messageHandler 直接通信
Native 调用Javascript
	直接通过webview 暴露的 API 执行JS代码
	IOS webview.stringByEvaluatingJavaScriptFromString
	Android webview.evaluateJavascript

跨端容器-WebView<->Native 通信

JS环境中提供通信的JSBridge
Native 端提供 SDK 响应JSBridge 发出的调用
前端和客户端分别实现对应功能模块

跨端容器-小程序

微信、支付宝、百度小程序、小米直达号
渲染层-webview
双线程，多webview架构
数据通信，Native转发

跨端容器-React Native/WeeX

原生组件渲染、React/Vue框架、virtual dom、JSBridge

跨端容器-Lynx

Vue、jS Core / V8、JSBinding、native Ul / Skia

跨端容器-Flutter

wideget、dart wm、skia图形库

跨端容器-通用原理

UI组件、染引擎、逻辑控制引擎、通信桥梁、底层API抹平表现差异

方案对比

问题一:同样是基于webview渲染，为什么小程序体验Lwebview流畅

小程序在体验上可能比一般的Webview流畅的原因可能有以下几个：

    原生化的设计：小程序采用原生化的设计，比起普通Webview页面，它更加轻量级，且加载速度更快。此外，小程序的交互、滑动、动画等细节设计也更加贴合用户习惯，能够提升用户的体验感。

    优化的渲染机制：小程序采用了自己的渲染机制，能够有效地避免一些Webview中的性能瓶颈。例如，小程序可以预加载页面，提高页面打开速度；同时，它也能够更加灵活地控制页面的渲染，从而保证流畅度。

	应用场景的限制：小程序的应用场景相对于普通Webview而言比较有限，其提供的功能和交互方式都是经过设计和优化的，相比较于浏览器中的Web页面，它能够更加针对特定的场景，从而提供更好的使用体验。

	总之，小程序相较于普通Webview页面，因其原生化的设计、优化的渲染机制和应用场景的限制，能够提供更加流畅的用户体验。

问题二:未来的跨端方案会是什么

跨端方案的发展趋势可能是以多端统一为主，即通过一套代码，能够在不同的平台（如Web、iOS、Android、小程序等）上进行部署和运行。

青训营笔记 | 客户端容器

青训营笔记|客户端容器

一、浏览器架构

二、渲染进程

三、Chrome运行原理

四、跨端容器

总结