首先这篇文章核心知识的话主要是关于 flutter 的，非FE的
为什么是这样讷？熟悉我的小伙伴都知道一点，就是博主我的话主要是的技术栈是 FE ，但是结合当下的背景来看的话我正在学习和深入研究 Flutter ，所以现在的对比就是进行的是 Flutter 的核心知识讲解吧
Flutter 生态拓展
Flutter UI与布局
核心组件：Text/Image/Button/ListView/Card 等基础组件是需要进行深入理解和掌握的讷
布局组件：Row/Column/Stack/Expanded/Flex 等布局组件，以及适配实现MediaQuery的实现，LayoutBuilder 响应式布局的实现吧
主题和样式：ThemeData TextStyle/BoxDecoration Asset 等
Flutter 状态管理
基础状态：就是在组件内部的 setState 实现管理状态
跨组件状态
provider
Riverpod
Bloc/Cubit 复杂业务的状态管理
全局状态：也就是将我们的一些状态提到全局进行管理的实现吧
Flutter 路由和导航管理
基础路由管理实现：Navigator.push/pop
命名路由管理：MaterialApp 的routes实现配置路由表实现路由管理，Navigator.pushNamed 实现路由的跳转
路由传参：跳转的时候实现传递参数，接受参数以及路由拦截的功能实现吧
Flutter 原生交互
MethodChannel 实现和原生的交互实现
EventChannel 原生向Flutter发送持续事件，进行交互
PlatFormView 也就是进行的是Flutter 中实现嵌入 webView
Flutter 性能优化
渲染优化：避免不必要的重建（用
const组件、memoized缓存）、减少布局嵌套内存优化：图片缓存（用
cached_network_image）、避免内存泄漏（比如取消未完成的 Future）包体积优化：删除未使用资源、开启代码混淆、拆分 ABIs（只保留必要架构）
Flutter 工程化与工具链
依赖管理：pubspec.yaml 的使用、版本约束、私有包
打包发布：Android（生成 APK/AAB）、iOS（打包 IPA）、应用商店上架流程
测试：单元测试（test 包）、Widget 测试（测试 UI 组件）、集成测试（flutter_driver）
Flutter 扩展能力
动画：隐式动画（AnimatedContainer 等）、显式动画（AnimationController）、Hero 动画（页面间元素过渡）
文件操作：除了 shared_preferences（轻量），还有
path_provider（获取文件路径）+dart:io（读写文件，比如存大文本、图片）第三方 SDK 集成：支付（微信 / 支付宝）、推送（极光 / 个推）、地图（高德 / 百度）等
Flutter VS FE 渲染流程
Flutter 渲染流程
Flutter 的渲染原理可以概括为 “自绘 UI 引擎”，区别于传统原生开发（依赖系统自带 UI 组件），它从底层实现了一套独立的渲染流水线，核心目标是 “跨平台 UI 一致性” 和 “高性能渲染”。
Flutter 核心的渲染原理
核心的渲染流程的话分为：构建（build）--> 布局（Layout）--> 绘制（Paint）--> 合成（Compositing）四个阶段吧，这个过程中主要是依赖于三棵树的协同工作实现吧
widget 树
在Flutter中所有的页面都是基于 widget 来实现开发的讷，是一个用于描述UI的配置树，不可变的（因为每次状态发生变化的时候，都会重新构建widget吧）
Container Text ListView 都是 widget，核心负责的责任是管理UI界面是如何的，其他的不参与管理讷
Element 树
widget 树的实例化产物吧，可变的产物吧，负责的是管理组件的声明周期吧（创建，销毁、更新）
每一个 widget 都是对应的是一个 Element，StatelessElement --> 无状态的 widget，StatefulElement --> 有状态的Widget，Element 实现的是进行缓存这些 widget 吧，避免不必要的重建
RenderObject 树
真正负责渲染计算的树，包含布局，绘制的核心逻辑吧
每一个Element 会关联一个 RenderObject （RenderBox处理盒模型布局，RenderText处理文本绘制，RenderObject存储组件的尺寸、位置等信息吧）
Flutter 四阶段渲染流水线
构建Build，生成widget树
触发时机：setState 父组件重建、依赖变化等
过程：从根widget开始，递归的构建子widget，生成新的widget树，由于 widget 是轻量的，仅仅存储配置即可，重建成本很低很低吧
布局Layout：计算RenderObject的位置和大小
触发时机：widget树的变化引起布局相关属性的变化吧
过程
从根 RenderObject 开始，通过 约束传递向下传递父组件的尺寸限制吧
子组件根据约束计算自身尺寸，通过尺寸反馈向上汇报父组件，父组件根据此确定子组件位置
典型的布局算法：盒模型、弹性布局
绘制Paint：将RenderObject 绘制到画布
触发时机：布局完成，或者绘制相关的数据变化
过程
每个 RenderObject 通过 paint 方法，将自身的内容绘制到 Layer 层上
绘制采用的的是 自底向上 的顺序，子组件先绘制，父组件后绘制进行实现吧
合成Compositing：合成图层并提交到CPU
触发时机：绘制完成，或图层属性改变
过程：
Flutter 将所有的 layer 合并到 Scene 场景，通过 skia 引擎将 scene 转换为 GPU 可识别的指令即可吧
GPU 负责最终的渲染（如图层混合、硬件加速），并将结果显示在屏幕上
Flutter 渲染引擎特点
独立渲染引擎：不依赖系统 UI 组件，直接调用 GPU，避免了原生开发中 “UI 组件→系统渲染” 的中间损耗。
增量渲染：仅重建 / 重绘变化的部分（通过 Element 树缓存和 RenderObject 的 “脏标记” 机制），减少冗余计算。
硬件加速：借助 Skia 引擎，将绘制操作转换为 GPU 指令，充分利用显卡性能（尤其是动画、滚动等场景）。
跨平台一致性：从 Widget 到渲染结果全流程可控，避免了不同系统原生组件的样式差异。
FE 渲染原理
前端渲染依赖浏览器内核（如 Chrome 的 Blink），核心是 “解析 HTML/CSS/JS，生成像素并展示”，不同浏览器渲染细节有差异，但整体流程一致。
核心渲染链路：五阶段流水线 + 三棵树
（1）HTML 解析 → DOM 树
浏览器解析 HTML 字符串，生成DOM 树（Document Object Model），每个节点对应 HTML 元素（如
<div>、<p>），描述页面的结构和内容。
（2）CSS 解析 → CSSOM 树
解析 CSS 样式（内联、嵌入、外部），生成CSSOM 树（CSS Object Model），描述每个 DOM 节点的样式规则（如颜色、尺寸、布局方式）。
（3）布局（Layout/Reflow）→ 渲染树（Render Tree）
合并 DOM 树和 CSSOM 树，生成渲染树（仅包含可见元素，如排除
display: none的节点）。计算每个节点的几何信息：位置（x/y 坐标）、尺寸（宽高），称为 “回流”（Reflow），是性能消耗较高的步骤（布局变化会触发回流）。
（4）绘制（Paint/Repaint）→ 图层合成
按渲染树顺序，将节点绘制到图层（Layer）上（如绘制文字、背景、边框），称为 “重绘”（Repaint）。
浏览器会自动分层（如
position: fixed、opacity < 1的元素会单独成层），减少重绘范围。
（5）合成（Composite）→ 屏幕展示
浏览器的合成线程将所有图层合并，处理图层变换（如旋转、缩放），最终提交给 GPU 渲染到屏幕。
关键特性
依赖浏览器引擎：渲染逻辑由浏览器实现，不同浏览器（Chrome/Safari/Edge）可能有差异（需做兼容性处理）。
性能瓶颈：回流（布局）和重绘成本高，频繁操作 DOM（如修改宽高、位置）会导致性能问题（需通过
requestAnimationFrame、CSS 硬件加速等优化）。Web 标准驱动：遵循 HTML/CSS 规范，支持丰富的 Web 特性（如响应式布局、CSS 动画、DOM 事件）。