1.webpack 4 源码主流程分析（十一）：文件的源码生成
2.FFmpeg源码分析: AVStream码流
3.UE5在编辑器本地化上的Editor.ini文件源码解读分析
4.Echarts-ZRender源码分析（一）
5.v51.04 鸿蒙内核源码分析(ELF格式) | 应用程序入口并非main | 百篇博客分析OpenHarmony源码
6.Android Adb 源码分析(一)

webpack 4 源码主流程分析（十一）：文件的生成

       本文深入分析了 Webpack 4 中文件生成的具体流程。在资源写入文件阶段，文件通过一系列优化和处理，分析最终返回到 Compiler.js 的源码 compile 方法，其中 Compiler 的文件属性 _lastCompilationFileDependencies 和 _lastCompilationContextDependencies 被赋予了 fileDependencies 和 contextDependencies。紧随其后的分析底指标源码无未来是创建目标文件夹的过程，该操作通过 outputPath 属性配置，源码结合 mkdirp 函数完成。文件

       在创建目标文件并写入阶段，分析通过 asyncLib.forEachLimit 方法并行处理每个文件资源，源码实现路径拼接、文件源码转换为 buffer，分析最后写入真实路径的源码文件。对于不同类型的文件 source 实例，如 CachedSource、分析ConcatSource 和 ReplaceSource，其处理逻辑各不相同，但最终目标都是获取替换后的字符串并合并返回 resultStr。所有文件创建写入完成后，执行回调，触发Compiler.afterEmit:hooks，进一步设置 stats 并打印构建信息。

       至此，构建流程全部结束。通过本文的分析，我们可以更直观地了解 Webpack 4 中文件生成的具体实现细节，为深入理解 Webpack 的工作原理和优化提供理论支持。本章小结，下章将解析打包后的文件，敬请期待。

FFmpeg源码分析: AVStream码流

       在AVCodecContext结构体中，AVStream数组存储着所有视频、音频和字幕流的信息。每个码流包含时间基、时长、索引数组、编解码器参数、dts和元数据。索引数组用于保存帧数据包的offset、size、timestamp和flag，方便进行seek定位。

       让我们通过ffprobe查看mp4文件的跟庄布林线源码码流信息。该文件包含5个码流，是双音轨双字幕文件。第一个是video，编码为h，帧率为.fps，分辨率为x，像素格式为yuvp。第二个和第三个都是audio，编码为aac，采样率为，立体声，语言分别为印地语和英语。第四个和第五个都是subtitle，语言为英语，编码器为mov_text和mov_text。

       调试实时数据显示，stream数组包含以下信息：codec_type（媒体类型）、codec_id、bit_rate、profile、level、width、height、sample_rate、channels等编解码器参数。

       我们关注AVCodecContext的编解码器参数，例如codec_type、codec_id、bit_rate、profile、level、width、height、sample_rate和channels。具体参数如下：codec_type - 视频/音频/字幕；codec_id - 编码器ID；bit_rate - 位率；profile - 编码器配置文件；level - 编码器级别；width - 宽度；height - 高度；sample_rate - 采样率；channels - 音道数。

       AVStream内部的nb_index_entries（索引数组长度）和index_entries（索引数组）记录着offset、size、timestamp、flags和min_distance信息。在seek操作中，通过二分查找timestamp数组来定位指定时间戳对应的帧。seek模式有previous、传奇3d 源码next、nearest，通常使用previous模式向前查找。

       时间基time_base在ffmpeg中用于计算时间戳。在rational.h中，AVRational结构体定义为一个有理数，用于时间计算。要将时间戳转换为真实时间，只需将num分子除以den分母。

UE5在编辑器本地化上的Editor.ini文件源码解读分析

       在UE5的开发流程中，本地化为游戏触及全球玩家提供了关键支持。Editor.ini文件作为本地化流程的核心组件，负责定义从源代码到最终本地化资源的完整路径。注释详尽，为开发者提供深入理解，便于管理并控制本地化工作。

       一、通用设置在[CommonSettings]部分，定义了本地化流程的基础，包括支持的文化和本地化文件存放位置。此配置确保流程覆盖所需文化，精准控制文件布局。

       文本收集流程分为多个步骤，从源码到编辑器资产，再到项目元数据，全面覆盖所需文本。

       （1）从源码收集步骤使用GatherTextFromSource命令，精准设定搜索路径、排除规则和文件类型，确保收集相关文件。

       （2）从资产收集步骤聚焦于编辑器内的UMAP和UASSET文件，提取编辑器内容，包括地图和其他资源，确保全面覆盖。

       （3）从元数据收集步骤专注于项目设置和配置，预加载模块和路径设定实现精细控制，确保内容范围精准。

       本地化文件生成流程包括清单、档案、导入PO文件、生成本地化资源、导出到PO文件和生成报告等步骤，autojs引流脚本源码形成完整的工作流。

       （1）清单生成使用GenerateGatherManifest命令，创建包含待翻译文本的清单。

       （2）档案文件存储翻译文本，GenerateGatherArchive命令实现，并清除过时的空条目。

       （3）InternationalizationExport命令导入翻译人员提供的PO文件。

       （4）生成.locres文件，UE5运行时使用的本地化资源格式，通过GenerateTextLocalizationResource命令实现。

       （5）导出到PO文件步骤为后续的翻译或审核工作提供便利。

       （6）生成报告审计和质量保证，包括词数统计和文本冲突，维护高质量本地化至关重要。

       Editor.ini文件在UE5的本地化工作流中扮演核心角色，从源头到最终资源，提供清晰路径，确保开发流程国际化，提升效率和翻译质量。

Echarts-ZRender源码分析（一）

       Echarts的底层图形绘制引擎ZRender，是一个独立的2D图形绘制引擎，支持Canvas/SVG（5.0后不再支持VML）。它具备图形绘制、管理（包括CRUD操作和组管理）、图形动画和事件管理（在Canvas中实现DOM事件）、响应式帧渲染以及可选渲染器功能。

       ZRender的架构遵循MVC模式，分为视图层、控制层和数据层。视图层负责图形渲染，控制层处理用户交互，数据层负责数据模型的管理和存储。此外，还包含辅助功能模块，如图形和Group的管理，其中图形特指2D矢量图形。

       源码文件结构清晰，入口文件zrender.ts中定义了全局方法，如初始化、删除等操作，ZRender类则负责核心功能的实现。通过实例化代码展示，nft交易网站源码可以看到如何绘制一个px的圆形并绑定动画，ZRender会处理绘制流程，并将动画添加到管理器中生成帧，开始动画绘制。

       后续章节将深入解析元素对象、事件管理器、动画管理器和渲染器的源码。作者雷庭，北京优锘科技前端架构师，有年前端开发和架构经验，专注于可视化前端开发，有兴趣交流的朋友可通过微信ltlt联系他。

v. 鸿蒙内核源码分析(ELF格式) | 应用程序入口并非main | 百篇博客分析OpenHarmony源码

       鸿蒙内核源码分析(ELF格式篇) | 应用程序入口并非main

       深入解析ELF格式与鸿蒙源码的关系，探寻应用程序入口的奥秘。本文将带你从一段简单的C代码开始，跟踪其编译成ELF格式后的神秘结构，揭秘ELF的组成与内部运作机制。

       以E:\harmony\docker\case_code_目录下的main.c文件为例，通过编译生成ELF文件，运行后使用readelf -h命令查看应用程序头部信息。了解ELF文件的全貌，从ELF头信息、段信息、段区映射关系、区表等多方面深入探讨。

       ELF格式文件由四大部分组成：头信息、段信息、段区映射关系和区表。头信息包含关键元数据，如文件类型、字节顺序、文件大小等；段信息描述了可执行代码和数据段的属性和位置；段区映射关系展示了段与区的关联；区表则存储了每个区的详细信息。

       通过readelf -l命令，可以观察到段信息及其在程序中的作用，如初始化数组、动态链接、栈区等。在运行时，不同段以特定方式映射到内存中，实现代码的加载和执行。

       在深入分析后，发现应用程序的真正入口并非通常理解的main函数，而是一个名为_start的特殊函数。这揭示了鸿蒙内核在启动时的执行流程，以及如何在ELF格式中组织和加载代码。

       本文以ELF格式为切入点，带你全面理解鸿蒙内核源码的组织结构与运行机制。通过百万汉字注解，带你精读内核源码，深入挖掘其地基。在Gitee仓(gitee.com/weharmony/ker...)同步注解，共同探索鸿蒙研究站(weharmonyos)的奥秘。

Android Adb 源码分析(一)

       面对Android项目的调试困境，我们的团队在项目临近量产阶段，将userdebug版本切换为了user版本，并对selinux权限进行了调整。然而，这一转变却带来了大量的bug，日志文件在/data/logs/目录下，因为权限问题无法正常pull出来，导致问题定位变得异常困难。面对这一挑战，我们尝试了两种解决方案。

       首先，我们尝试修改data目录的权限，使之成为system用户，以期绕过权限限制，然而数据目录下的logs文件仍保留了root权限，因此获取日志依然需要root权限，这并未解决问题。随后，我们找到了一个相对安全的解决办法——通过adb命令的后门机制，将获取root权限的命令修改为adb aaa.bbb.ccc.root。这一做法在一定程度上增加了后门的隐蔽性，避免了被窃取，同时对日常开发的影响也降至最低。

       在解决这一问题的过程中，我们对Android ADB的相关知识有了更深入的理解。ADB是Android系统中用于调试的工具，它主要由三部分构成：adb client、adb service和adb daemon。其中，adb client运行于主机端，提供了命令接口；adb service作为一个后台进程，位于主机端；adb daemon则是运行于设备端（实际机器或模拟器）的守护进程。这三个组件共同构成了ADB工具的完整框架，且它们的代码主要来源于system/core/adb目录，用户可以在此目录下找到adb及adbd的源代码。

       为了实现解决方案二，我们对adb的代码进行了修改，并通过Android SDK进行编译。具体步骤包括在Windows环境下编译生成adb.exe，以及在设备端编译adbd服务。需要注意的是，在进行编译前，需要先建立Android的编译环境。经过对ADB各部分关系及源代码结构的梳理，我们对ADB有了更深入的理解。

       在后续的开发过程中，我们将继续深入研究ADB代码，尤其是关于如何实现root权限的功能。如果大家觉得我们的分享有价值，欢迎关注我们的微信公众号“嵌入式Linux”，一起探索更多关于Android调试的技巧与知识。

.py是什么类型的文件

       以下是详细的解释：

一、Python文件的标识

       .py文件是Python编程语言的源代码文件。Python是一种解释型、交互式、面向对象的编程语言，广泛应用于数据分析、网络编程、网站开发等领域。.py文件包含了Python代码，这些代码可以是脚本形式直接运行，也可以被当作模块或库被其他Python程序引用。

二、Python文件的构成

       .py文件的内容通常包括Python语句、函数定义、类定义以及模块定义等。开发者通过这些元素来编写复杂的程序。此外，它们可以包含注释和文档字符串，这些对于理解代码逻辑和程序功能非常有帮助。

三、Python文件的执行

       要执行一个.py文件，可以直接通过Python解释器运行。解释器会逐行读取并执行文件中的代码。此外，如果文件中有特定的入口点，也可以通过命令行参数直接运行这个文件。对于大型项目，通常会使用像PyInstaller这样的工具将多个.py文件打包成一个可执行文件。这样，用户无需安装Python环境即可运行程序。

       总之，.py文件是Python编程语言的源代码文件，包含了开发者编写的各种代码元素。这些文件是Python开发的基础，也是进行Python编程不可或缺的一部分。

torchvision应用与源码分析

       torchvision是PyTorch库中的一部分，用于计算机视觉任务，它包含了一系列的预训练模型和数据集。

       一：torchvision应用

       在计算机视觉领域，torchvision提供了方便的API，用于加载和处理图像数据，训练模型和进行预测。它通常与PyTorch深度学习框架结合使用，为用户提供了一个完整的框架来开发和部署计算机视觉应用。

       二：torchvision源码分析

       1. setup.py分析

       setup.py是Python包的配置文件，用于描述包的元数据和安装步骤。在torchvision中，setup.py文件被用来编译和安装包的依赖库。

       1.1 导入依赖的模块

       1.2 从配置文件中获取当前torchvision的版本信息

       1.3 获取依赖的torch版本信息

       1.4 获取编译扩展信息，然后传递给setup函数，启动编译

       1.5 重点：get_extensions分析

       在torchvision的setup.py文件中，get_extensions函数是核心部分，它负责编译torchvision自身的源码以及一些第三方库，如jpeg和codec等。

       1.5.1 获取ccsrc下面的cpp源码

       1.5.2 获取环境变量中配置的编译选项

       1.5.3 判断是AMD的HIP还是nVidia的CUDA，来获取到最终的cuda文件

       1.5.4：依据环境上是否支持cuda来确定编译扩展

       1.5.5 添加扩展

       至此，torchvision就将整个版本包编译出来了，会调用torch的cpp和cuda编译扩展（即：通过gcc+nvcc来编译ccsrc下面的源码，而不用torchvision自行再来设置各种编译环境信息了）。

       整个编译核心流程总结如下：

       2. torchvision新增算子流程

       以torchvision.ops.DeformConv2d为例

       2.1 基础用法与模型结构

       通过Netron工具打开模型结构，可以看到torchvision的deform_conv2d是单独的IR定义的算子

       2.2 python侧实现分析

       deform_conv2d定义在Python侧，实际上做了参数初始化后，将转交给了C++侧对应的接口

       2.3 C++侧分析：torch.ops.torchvision.deform_conv2d

       2.3.1 接口定义

       2.3.2 接口实现

       关键在于这两个接口的注册

       算子的具体实现和如何向pytorch完成注册呢？

       该算子有C++和CUDA实现方式，C++方式可以在纯CPU版本中运行，cuda实现则依赖于GPU和CUDA

       2.3.2.1 C++实现

       2.3.2.2 CUDA实现

       这种方式实现的算子，trace出来的模型中，为单个算子

       总结：自定义算子向torch集成分为两步

       三：基于torchvision新增一个算子

       实现一个算子：my_add = 2*x + y

       3.1 环境准备

Android-Fragment源码分析

       Fragment是Android系统为了提高应用性能和降低资源消耗而引入的一种更轻量级的组件，它允许开发者在同一个Activity中加载多个UI组件，实现页面的切换与回退。Fragment可以看作是Activity的一个子部分，它有自己的生命周期和内容视图。

       在实际应用中，Fragment可以用于构建动态、可复用的UI组件，例如聊天应用中，左右两边的布局（联系人列表和聊天框）可以分别通过Fragment来实现，通过动态地更换Fragment，达到页面的切换效果，而无需整个页面的刷新或重新加载。

       在实现上，v4.Fragment与app.Fragment主要区别在于兼容性。app.Fragment主要面向Android 3.0及以上版本，而v4.Fragment（即支持包Fragment）则旨在提供向下兼容性，支持Android 1.6及更高版本。使用v4.Fragment时，需要继承FragmentActivity并使用getSupportFragmentManager()方法获取FragmentManager对象。尽管从API层面看，两者差异不大，但官方倾向于推荐使用v4.Fragment，以确保更好的兼容性和性能优化。

       下面的示例展示了如何使用v4.Fragment实现页面的加载与切换。通过创建Fragment和FragmentActivity，我们可以加载特定的Fragment，并在不同Fragment间进行切换。

       在FragmentDemo的布局文件中，定义了Fragment容器。

       在Fragment代码中，定义了具体的业务逻辑和视图渲染，如初始化界面数据、响应用户事件等。

       在Activity代码中，通过FragmentManager的beginTransaction方法，加载指定的Fragment实例，并在需要时切换到不同Fragment，实现页面的动态更新。

       从官方的建议来看，v4.Fragment已经成为推荐的使用方式，因为它在兼容性、性能和功能方面都更优于app.Fragment。随着Android系统的迭代，使用v4.Fragment能确保应用在不同版本的Android设备上均能获得良好的运行效果。

       在Fragment的生命周期管理中，Fragment与Activity的生命周期紧密关联。通过FragmentManager的操作，如commit、replace等，可以将Fragment加入到Activity的堆栈中，实现页面的加载与切换。当用户需要返回时，系统会自动将当前Fragment从堆栈中移除，从而实现页面的回退。

       深入Fragment源码分析，我们可以了解其如何在底层实现这些功能。Fragment的初始化、加载、切换等过程涉及到多个关键类和方法，如FragmentManager、FragmentTransaction、BackStackRecord等。通过这些组件的协作，Fragment能够实现与Activity的生命周期同步，确保用户界面的流畅性和高效性。

       在实际开发中，使用Fragment可以显著提高应用的响应速度和用户体验。通过动态加载和切换不同的Fragment，开发者可以构建出更加灵活、高效的应用架构，同时减少资源的消耗，提高应用的性能。