1.探索chrome二进制大小的源码变迁和剪裁chromium的一些思路
2.UE5打开PDF文件显示并保存文件
探索chrome二进制大小的变迁和剪裁chromium的一些思路
研究chromium源码的价值不仅在于学习，还在于商业应用，说明但随着版本升级，源码cef的说明大小从MB增长至MB，对注重安装包大小的源码开发者来说，寻求减小chromium内核尺寸是说明django源码解读一个挑战。本文通过对比历史版本，源码探究chrome二进制文件的说明变化，为裁剪chromium提供策略。源码
首先，说明对比不同版本chrome的源码Windows 位安装包，发现从MB增长到MB，说明我们挑选了变化显著的源码包进行详细分析（红色箭头标出）。解压后，说明逐版本对比安装包内的源码文件大小变化，以及各文件占总大小的百分比变化。
chrome.dll的体积持续增长，占总大小的比例也不断提升，但其他模块总体趋势向小型化发展。jediscluster源码解析在chrome.dll模块分析中，发现至版本，chrome_child.dll的合并抑制了体积增长；至版本，notification_helper.exe等模块的合并导致显著增长。这说明模块合并对整体体积控制有积极作用，但同时也增加了去除特定功能的难度。
特别指出，3D模块的增长显著，删除支持3D相关的codeblocks源码编译文件可减小MB。snapshot技术优化带来体积减少，部分隐藏在chrome.dll中。资源相关的文件体积明显减小，如icudtl.dat，可通过裁剪减少到几十KB。
关于裁剪思路，虽然chromium编译中间产物有3w多个obj文件，但我们通过分析Top 文件，发现v8和third_party模块的golang map源码体积较大。通过一级目录聚合，可以看出v8和third_party\blink的体积不容忽视。进一步细分，blink的core和bindings模块对二进制贡献较大，而v8的优化则需更细致的处理。
特别值得关注的是，perfetto的trace_processor模块和pdfium、libjxl、dawn、gps c 源码webrtc等第三方库对体积影响较大。考虑使用V8的V8Lite模式和裁剪jit、wasm模块，能有效减少V8体积。然而，这些基于编译中间产物的分析可能与最终dll大小存在偏差，一般能减小-%的体积。
总的来说，理解chromium源码和运行方式有助于优化，对开发者来说，这是一次从不同角度深入了解chromium的机会。欢迎交流和学习。
UE5打开PDF文件显示并保存文件
UE5通过pdfium库实现了PDF文件的显示和保存功能，为用户提供便利。它的操作流程直观且支持选择中文文件夹，通过FPDF_LoadDocument、FPDF_GetPageCount等函数加载PDF文档，获取页面数量和尺寸。例如，FPDF_GetPageWidth和FPDF_GetPageHeight用于获取页面宽度和高度，FPDFBitmap_FillRect则用于填充位图。开发者可以参考其源代码深入了解具体用法。值得注意的是，当处理大型PDF文件时，建议采用多线程技术，以避免在项目中出现卡顿现象。PDF文件的SDK获取地址可供查阅。下面是UE5实现PDF文件操作的示例代码片段：
UE5借助pdfium库实现了PDF文件的显示和保存功能。它允许用户选取中文文件夹中的PDF文档，核心操作函数包括FPDF_LoadDocument来加载文档，FPDF_GetPageCount获取总页数，FPDF_GetPageHeight和FPDF_GetPageWidth则分别获取页面的高和宽。例如，通过FPDFBitmap_FillRect可以填充位图，而FPDF_RenderPageBitmap用于页面渲染。在处理大型PDF时，建议采用多线程技术以防止项目运行卡顿。PDF相关的SDK获取地址供您参考。
