1.vue/compiler-dom源码分析学习--day4: 字符串化hoist节点
2.react源码解析（二）时间管理大师fiber
3.Gitea源码分析（一）
4.UE 八叉树Octree2源码分析
5.Linux内核源码解析---cgroup实现之整体架构与初始化
6.非线性优化（三）：g2o源代码
vue/compiler-dom源码分析学习--day4: 字符串化hoist节点
vue/compiler-dom源码解析继续：深入理解字符串化hoist节点
前言：在处理内置指令后，节点节点我们今日关注的管理管理是@vue/compiler-dom包中的字符串化hoist节点操作。这部分代码在baseCompile方法中找到调用入口，源码且hoistStatic选项默认为true，软件尽管没有直接传入参数。节点节点
在vue/compiler-sfc/__tests__/compileTemplate.spec.ts的管理管理vb post源码测试用例中，我们发现参数来源。源码接着，软件我们追踪到hoistStatic.ts和`walk`函数，节点节点这是管理管理实现静态提升（static hoisting）的关键，用于优化性能，源码避免在render function中重复生成和比较不会变化的软件静态节点。
静态提升允许将不变的节点节点元素和文本节点抽离到render函数外，提高渲染效率。管理管理例如，源码一个只包含动态部分的，其静态部分会被提升，渲染时会直接使用字符串拼接，而不是每次都重新创建。
现在，我们来看下stringifyStatic方法。该方法在确定节点会被提升到哪个阶段后执行，确保只处理适合的普通元素和文本节点。在transforms/stringifyStatic.ts中，代码负责识别可stringify的子节点，比如v-slot组件是不支持的，但可以hoist。
在`analyzeNode`方法中，逐层递归检查节点，确保所有子节点满足stringify条件。文本节点则有特殊的处理方式，其他情况下，如遇到table元素，可能存在浏览器兼容性问题，导致不能使用innerHTML。
总结`stringifyCurrentChunk`方法，它将识别到的静态块转换为字符串调用节点，替换原始hoist元素。整个过程旨在优化性能，通过字符串化hoist节点，减少不必要的DOM创建和比较。
尽管代码逻辑相对直观，但众多小方法间的跳转可能影响阅读。核心是找到可stringify的最大静态块，并进行替换。关于内置指令和style的处理，也有相应的php博客源码下载优化策略，如transformStyle处理静态style为bind类型。
react源码解析（二）时间管理大师fiber
React的渲染和对比流程在面对大规模节点时，会消耗大量资源，影响用户体验。为了改进这一情况，React引入了Fiber机制，成为时间管理大师，平衡了浏览器任务和用户交互的响应速度。 Fiber的中文翻译为纤程，是一种内部更新机制，支持不同优先级的任务管理，具备中断与恢复功能。每个任务对应于React Element的Fiber节点。Fiber允许在每一帧绘制时间（约.7ms）内，合理分配计算资源，优化性能。 相比于React，React引入了Scheduler调度器。当浏览器空闲时，Scheduler会决定是否执行任务。Fiber数据结构具备时间分片和暂停特性，更新流程从递归转变为可中断的循环，通过shouldYield判断剩余时间，灵活调整更新节奏。 Scheduler的关键实现是requestIdleCallback API，它用于高效地处理碎片化时间，提高用户体验。尽管部分浏览器已支持该API，React仍提供了requestIdleCallback polyfill，以确保跨浏览器兼容性。 在Fiber结构中，每个节点包含返回指针（而非直接的父级指针），这个设计使得子节点完成工作后能返回给父级节点。这种机制促进了任务的高效执行。 Fiber的遍历遵循深度优先原则，类似王朝继承制度，确保每一帧内合理分配资源。通过实现深度优先遍历算法，可以构建Fiber树结构，用于渲染和更新DOM元素。 为了深入了解Fiber，可以使用本地环境调试源码。通过创建React项目并配置调试环境，可以观察Fiber节点的结构和行为。了解Fiber的遍历流程和结构后，可以继续实现一个简单的游戏官网源码下载Fiber实例，这有助于理解React渲染机制的核心。 Fiber架构是React的核心，通过时间管理机制优化了性能，使React能够在大规模渲染时保持流畅。了解Fiber的交互流程和遍历机制，有助于深入理解React渲染流程。未来，将详细分析优先级机制、断点续传和任务收集等关键功能，揭示React是如何高效地对比和更新DOM树的。 更多深入学习资源和讨论可参考以下链接： 《React技术揭秘》 《完全理解React Fiber》 《浅谈 React Fiber》 《React Fiber 源码解析》 《走进 React Fiber 的世界》Gitea源码分析（一）
Gitea是一个基于Go编写的Git代码托管工具，源自于gogs项目，具有良好的后端框架和前端集成。
前端框架采用Fomantic UI和Vue，路由控制器框架在年4月从macaron切换到chi，形成了gitea项目的结构基础。
在调用接口时，gitea引入了'User'，'Repo'，'Org'等内容，简化了接口调用，便于管理。'ctx.User'和'ctx.Repo'内容动态变化，需要用户登录和进入仓库时赋值。
在'routers'下，'handler'相关文件分为'get'和'post'两类，前者涉及前端渲染，后者负责执行操作。
'get'请求通过'templates'中的文件渲染到前端，通过'ctx.Data["name"]'传递需要渲染的数据，获取URL参数使用'c.Query'。
'post'请求接收前端数据，通常通过'form'传值，从'context'生成，可以使用'form.xxx'直接调用，添加内容则需在'form'结构体中定义。
渲染生成网页使用'ctx.Html(,tplName)'，根据'context'内容做条件判断。
权限管理功能实现中，数字越大权限越高，便于后续对比。'UnitType'包含多项，如仓库页面导航栏显示。检查权限时，对比AccessModeRead和模块权限，大于则认为具有读权限。浏览器app源码
gitea默认运行于单一服务器，伸缩性有限。若需分布式改造，需解决大规模并发访问、存储库分片和数据库支撑等问题。通过ELB负载均衡分散到多个节点，数据库使用集群方案，但存储库分片面临巨大挑战，现有技术难以实现。
官方文档提供了其他开源库的介绍，包括配置文件、容器方式下的轻量仓库与CI使用方案等。深入研究可发现Gitea的配置、路由控制框架chi、权限管理实现及分布式架构改造思路。
UE 八叉树Octree2源码分析
UE中八叉树Octree2源码分析，本文旨在深入理解UE八叉树的具体实现。八叉树概念广泛熟悉，但初次接触UE实现时仍需思考。UE八叉树简化应用，多数直接使用方便。本文针对UE4.至UE5.1版本八叉树源码进行详细解析。
UE八叉树主要结构包括：TreeNodes、ParentLinks、TreeElements、FreeList、RootNodeContext和MinLeafExtent。TreeNodes存储节点信息，每个FNode记录当前节点元素数量及子节点Index；ParentLinks记录节点父节点ID；TreeElements存储元素数据；FreeList记录空闲FNode下标；RootNodeContext和MinLeafExtent与八叉树构造相关，用于确定节点半径。
UE八叉树构造过程依赖AddElement方法，实现在AddElementInternal中。首先判断节点是否为叶子节点。若无子节点且元素数量超过预设阈值，或节点半径小于MinLeafExtent，则创建子节点。否则，直接将元素加入当前节点。若需创建子节点，清空当前节点元素，分配八个子节点，递归处理非叶节点情况。
RemoveElement方法根据ElementId移除元素。首先在TreeElements中移除元素，然后从节点向上遍历，检查元素数量过少的安卓项目源码讲解节点，进行塌缩重构，将子节点元素移入当前节点。
UE八叉树查询接口包括FindElement、FindElementsWithBoundsTest等，核心目的是遍历节点和子节点以满足查询条件。UE八叉树用于高效空间数据处理，通过Octree2类声明实现。例如，PrecomputedLightVolume类定义ElementType和OctreeSemantics，便于特定应用使用。
UE八叉树内存管理关键在于TreeElement数组，使用TInlineAllocator或FDefaultAllocator需考虑应用场景。空间数据结构如四叉树、八叉树等在空间划分算法中具有重要应用，优化碰撞检测及实现复杂场景。
Linux内核源码解析---cgroup实现之整体架构与初始化
cgroup在年由Google工程师开发，于年被融入Linux 2.6.内核。它旨在管理不同进程组，监控一组进程的行为和资源分配，是Docker和Kubernetes的基石，同时也被高版本内核中的LXC技术所使用。本文基于最早融入内核中的代码进行深入分析。
理解cgroup的核心，首先需要掌握其内部的常用术语，如子系统、层级、cgroupfs_root、cgroup、css_set、cgroup_subsys_state、cg_cgroup_link等。子系统负责控制不同进程的行为，例如CPU子系统可以控制一组进程在CPU上执行的时间占比。层级在内核中表示为cgroupfs_root，一个层级控制一批进程，层级内部绑定一个或多个子系统，每个进程只能在一个层级中存在，但一个进程可以被多个层级管理。cgroup以树形结构组织，每一棵树对应一个层级，层级内部可以关联一个或多个子系统。
每个层级内部包含的节点代表一个cgroup，进程结构体内部包含一个css_set，用于找到控制该进程的所有cgroup，多个进程可以共用一个css_set。cgroup_subsys_state用于保存一系列子系统，数组中的每一个元素都是cgroup_subsys_state。cg_cgroup_link收集不同层级的cgroup和css_set，通过该结构可以找到与之关联的进程。
了解了这些概念后，可以进一步探索cgroup内部用于结构转换的函数，如task_subsys_state、find_existing_css_set等，这些函数帮助理解cgroup的内部运作。此外，cgroup_init_early和cgroup_init函数是初始化cgroup的关键步骤，它们负责初始化rootnode和子系统的数组，为cgroup的使用做准备。
最后，需要明确Linux内一切皆文件，cgroup基于VFS实现。内核启动时进行初始化，以确保系统能够正确管理进程资源。cgroup的初始化过程分为早期初始化和常规初始化，其中早期初始化用于准备cpuset和CPU子系统，确保它们在系统运行时能够正常工作。通过这些步骤，我们可以深入理解cgroup如何在Linux内核中实现资源管理和进程控制。
非线性优化（三）：g2o源代码
新年伊始，让我们探讨一下g2o（通用图优化）在SLAM（Simultaneous Localization and Mapping）中的后端优化库应用。在《十四讲》中，我们对g2o有了初步的了解，并总结了其在SLAM中的使用情况。与ceres相比，g2o的文档较为简略，主要依赖于两篇论文进行参考。本文将深入探讨g2o的源代码，特别是核心文件夹中的部分，以揭示这个在SLAM领域广为人知的后端优化库的内在机理。
首先，让我们通过一张类关系图来直观理解g2o的架构。整个g2o系统分为三层：HyperGraph、OptimizableGraph、以及SparseOptimizer。HyperGraph作为最高层，提供了一个高度抽象的框架，其内部通过内类的方式实现了Vertex和Edge的结构。Vertex和Edge相互关联，Vertex存储与节点相关联的边的集合，而Edge则记录了与之链接的节点信息。HyperGraph提供了基本的节点和边的操作，如获取、设置等，同时也包含了更复杂的功能，如节点和边的合并、删除等。
OptimizableGraph继承自HyperGraph，进一步丰富了Vertex和Edge的实现，为图优化提供了更具体的接口。OptimizableGraph引入了海塞矩阵和b向量的概念，以及与之相关的操作，如获取海塞矩阵元素、设置参数位置等。此外，它还支持通过栈操作（pop、push）来管理节点信息。
在OptimizableGraph之上，SparseOptimizer作为优化操作的对象，实现了优化的接口，并提供了初始化、辅助函数以及优化的核心函数。SparseOptimizer通过内部类实现了Vertex和Edge的实例化，为具体的优化算法提供了操作图的接口。
在实现细节方面，BaseVertex和BaseEdge类继承了OptimizableGraph中的相应类，实现了节点和边的基本功能。BaseVertex类负责记录节点的海塞矩阵、b向量和估计值，并提供了数值求导的备份和恢复功能。BaseEdge类则负责处理测量信息和信息矩阵的计算，包括计算误差、构造二次形式等。此外，不同类型的边（BaseUnaryEdge、BaseBinaryEdge、BaseMultiEdge）通过继承BaseEdge类，实现了不同链接节点数量的边的特殊操作。
鲁棒核函数的实现是g2o优化框架中一个关键部分，它在处理非线性优化问题时提供了鲁棒性，确保了优化过程的稳定性。g2o通过RobustKernel虚基类提供了设置和获取核函数参数的接口，并在具体实现中使用了简化版本的计算公式，以保证信息矩阵的正定性。
最后，OptimizationAlgorithm类定义了优化器的一系列接口，如初始化、计算边际值和求解等。g2o的优化算法包括GN、LM和dog-leg，它们分别实现了不同的求解策略，而具体的矩阵求解任务则通过Solver类及其派生类（如BlockSolver）完成。BlockSolver类提供了一个通用框架，允许用户自定义线性求解器，如直接求解、迭代求解等。
综上所述，g2o通过层次化的类结构，提供了从抽象到具体、从基础到进阶的图优化解决方案，其设计旨在高效、鲁棒地解决SLAM中的后端优化问题。深入理解g2o的源代码，对于开发者和研究者来说，不仅能够提高优化算法的实现效率，还能深刻理解SLAM系统中的优化机制。
Kswapd 源码解析
kswapd是Linux内核中的一个内存回收线程，主要用于内存不足时回收内存。初始化函数为kswapd_init，内核为每个节点分配一个kswapd进程。每个节点的pg_data_t结构体中维护四个成员变量，用于管理kswapd线程。
在初始化后，每个节点的kswapd线程进入睡眠状态。唤醒时机主要在被动唤醒和主动唤醒两种场景：被动唤醒是内存分配进程唤醒并完成异步内存回收后，对节点内存环境进行平衡度检查，若平衡则线程短暂休眠ms后主动唤醒。主动唤醒是内存回收策略调用kswapd，对节点进行异步内存回收，让节点达到平衡状态。
内存回收包括快速和直接两种方式，但系统周期性调用kswapd线程平衡不满足要求的节点，因为有些任务内存分配不允许阻塞或激活I/O访问，回收内存相当于亡羊补牢，系统利用空闲时间进行内存回收是必要的。
kswapd线程通过module_init(kswapd_init)创建，一般处于睡眠状态等待被唤醒，当系统内存紧张时，会唤醒kswapd线程，调整不平衡节点至平衡状态。
kswapd函数包含alloc_order、reclaim_order和classzone_idx三个变量，用于控制线程执行流程。kswapd_try_to_sleep函数判断是否睡眠并让出CPU控制权，同时是线程唤醒的入口。balance_pgdat函数是实际内存回收操作，涉及内存分配失败后唤醒kswapd线程，调用此函数对指定节点进行异步内存回收。
kswapd_shrink_node函数通过shrink_node对低于sc->reclaim_idx的非平衡zone区域进行回收。
总结kswapd执行流程，其生命周期与Linux操作系统相似，平时处于睡眠状态让出CPU控制权。在内存紧张时被唤醒，有被动唤醒和周期性主动唤醒两种时机。被动唤醒发生在内存分配任务获取不到内存时，表明系统内存环境紧张，主动唤醒则是内存回收策略的执行。线程周期性唤醒在被动唤醒后的短暂时间内，原因在于系统内存环境紧张，需要在这段时间内进行内存回收。
XGBoost源码解读
前言
XGBoost是一代神器，其推理逻辑独树一帜，与Glove等相似，皆以思考出发，推导出理想结果。高斯正是这种思维的典范，XGBoost的代码实现也异常精妙，本文尝试将两者相结合，供您参考。
高斯的做法
优化目标设定，以均值为目标函数的导数为零。利用线性假设推导目标函数，进而优化以误差平方项为出发点。
进一步，高斯将误差目标公式推广到参数求解中，实现优化。
Glove的做法
通过log-bilinear models, LBL启发，寻找满足概率约束的目标表达式，并推导出指数函数，从而实现类似LSA的因子分解。
引入优化权重函数，最终实现最大似然估计。
XGBoost的做法
引入Stagewise限制，目标为找到最优的叶子节点，以最佳方式拆分，优化损失。
通过泰勒展开，结合叶子节点权重假设，推导出目标公式。
基于贪心算法，实现树的生长。
代码解读
从命令行入口开始，核心代码框架包括数据加载、初始化、循环训练与模型保存。训练过程包括计算样本预测结果、一阶和二阶梯度计算以及Boost操作。
DoBoost实现GBLine和GBTree两种方式，提供GradientBooster核心函数，如DoBoost、PredictLeaf、PredictBatch等。
默认采用GBTree，对于线性部分，效果难与非线性分类器相比。
代码基本框架集成了DMLC的注册使用机制，插件式管理实现更新机制。
实现精准和近似算法，主要关注ColMaker更新实现。在GBTree的DoBoost中，生成并发新树，更新ColMaker和TreePruner。
ColMaker实现包括Builder与EnumerateSplit，最终依赖于TreeEvaluator的SplitEvaluator。
SplitEvaluator实现树的分拆，对应论文中的相关函数，包括Gain计算、权重计算、单个叶子节点Gain计算与最终损失变化。
本文仅作为案例介绍，XGBoost在近似计算、GPU计算与分布式计算方面也极具亮点。
小结
本文通过对比分析高斯、Glove与XGBoost的优化策略，展示了研究与工程结合的实践，强调在追求性能的同时，不能忽视效果的重要性。
