ELF文件格式解析：嵌入式ARM固件的链接、加载与执行机制

1. ELF 文件规范与嵌入式系统二进制格式演进

Executable and Linking Format（ELF）是一种定义明确、高度可扩展的二进制文件格式规范，其核心目标是为不同阶段的软件生命周期——从源码编译、目标文件链接到最终程序加载执行——提供统一、可移植的数据组织框架。在嵌入式开发领域，尤其是基于 ARM 架构的微控制器系统中，ELF 并非一个抽象概念，而是贯穿整个工具链（编译器、汇编器、链接器、调试器、烧录器）的底层数据契约。理解 ELF 的结构与语义，是进行底层调试、内存布局优化、启动代码编写以及固件安全分析的先决条件。

ELF 的历史渊源可追溯至更早的 Common Object File Format（COFF）。COFF 最初由 UNIX System V Release 3 的 UNIX 系统实验室（USL）提出，旨在为 Unix 系统提供一种标准化的对象文件表示。微软随后在其 Windows NT 系统中采纳并扩展了 COFF，形成了 Portable Executable（PE）格式，这成为 Windows 平台可执行文件和动态链接库（DLL）的基础。而 USL 在 System V Release 4 中，对 COFF 进行了更为彻底的重构与增强，发布了 ELF 格式，并将其确立为应用程序二进制接口（Application Binary Interface, ABI）的核心组成部分。此后，Tool Interface Standard Committee（TISC）正式采纳 ELF v1.1 和 v1.2 作为跨 32 位 Intel 体系结构的操作系统间二进制可移植性的标准。随着 64 位计算的普及，原始的 TISC ELF v1.2 规范已显陈旧，因此 System V ABI 委员会对其进行了扩展，形成了当前广泛使用的 System V AMD64 ABI 补充规范，该规范被所有主流 Unix 及类 Unix 系统（包括 Linux）所遵循。

在嵌入式领域，ARM 架构自其诞生之初便选择了 ELF 作为其原生二进制格式。无论是 Cortex-M 系列的微控制器，还是 Cortex-A 系列的应用处理器，其整个软件生态——从 Keil MDK、IAR Embedded Workbench 到 GNU Arm Embedded Toolchain——均围绕 ELF 构建。ARM 官方发布的《ELF for the ARM Architecture》等文档，并非定义了一种全新的格式，而是对通用 ELF 规范在 ARM 指令集、内存模型和 ABI 约束下的具体化实现与补充说明。这意味着，一个合格的嵌入式工程师，其对 ELF 的理解不应停留在“Linux 下的可执行文件”这一层面，而必须深入到其如何精确地描述一段 ARM Thumb-2 指令在 ROM 中的存放位置、如何将 C 语言全局变量映射到 RAM 的特定区域、以及如何为异常向量表预留精确的内存空间等工程细节。

1.1 ELF 对象文件的三重分类

ELF 规范根据文件在软件构建与执行流程中所扮演的角色，将所有采用该格式的文件统称为“对象文件（Object File）”，并将其严格划分为三大类。这种分类并非随意，而是直接对应着链接器（linker）和加载器（loader）的不同工作模式，是理解嵌入式固件构建流程的关键。

1. 可重定位文件（Relocatable File）此类文件是编译和汇编过程的直接产物，典型的文件扩展名为.o（object）。它包含了未经地址绑定的机器代码（.text节）、已初始化的全局/静态数据（.data节）以及未初始化数据的占位符（.bss节）。其核心特征在于“可重定位”：文件中所有对符号（如函数名、变量名）的引用，以及所有需要绝对地址的指令（如跳转、取址），都以“重定位条目（relocation entry）”的形式记录在.rela.text或.rela.data等节中。这些条目告诉链接器：“当您将此段代码放置到最终的内存地址 X 处时，请将此处的地址值修改为 Y”。因此，.o文件本身无法直接执行，它必须与其他.o文件或静态库（本质上是一组.o文件的归档）一起，由链接器进行符号解析、地址分配和重定位操作，才能生成最终的可执行映像。在嵌入式开发中，每一个.c或.s源文件都会生成一个对应的.o文件，它们是构建固件的“砖块”。

2. 可执行文件（Executable File）这是链接器的最终输出，是能够被操作系统或裸机引导程序（bootloader）直接加载并运行的文件。在 Linux 系统中，/bin/bash就是一个典型的 ELF 可执行文件；在嵌入式领域，Keil MDK 生成的.axf文件、GCC 工具链生成的.elf文件，均属于此类。其关键特征是“地址已确定”：链接器已经为所有代码段和数据段分配了最终的虚拟地址（Virtual Address），所有重定位条目都已被应用，文件中不再包含任何待处理的地址修正信息。文件头部的e_entry字段明确指出了程序的入口点（Entry Point），即 CPU 复位后 PC 寄存器应被加载的地址。对于 ARM Cortex-M 微控制器，这个地址通常指向复位向量表中的第一个字，即Reset_Handler函数的起始地址。可执行文件内部通过“程序头表（Program Header Table）”来描述其如何被加载到内存中，该表定义了若干个“段（Segment）”，每个段对应一块连续的内存区域，例如只读代码段（PT_LOAD类型，PF_R|PF_X标志）和可读写数据段（PT_LOAD类型，PF_R|PF_W标志）。

3. 共享对象文件（Shared Object File）此类文件是动态链接机制的基础，在 Linux 下表现为.so文件，在 Windows 下则为.dll文件。在嵌入式领域，虽然裸机系统较少使用动态链接，但在基于 Linux 的嵌入式设备（如路由器、工业网关）中，.so文件极为常见。共享对象文件兼具可重定位文件和可执行文件的某些特性：它包含了可执行的代码和数据，但其代码段通常是“位置无关的（Position Independent Code, PIC）”，即其内部指令不依赖于固定的加载地址，而是通过相对寻址或全局偏移表（GOT）来访问数据和调用函数。这使得同一个.so文件可以被多个进程同时加载到各自不同的内存地址空间中，从而节省物理内存。链接器在生成可执行文件时，如果链接了共享库，它并不会将库的代码复制进去，而只是在可执行文件中记录下对这些库的依赖关系（.dynamic节），并在程序启动时，由动态链接器（ld-linux.so）负责将所需的.so文件加载到内存并完成最终的符号绑定。

此外，ELF 规范还定义了“核心转储文件（Core Dump File）”，它是在进程因严重错误（如段错误）而崩溃时，由操作系统生成的内存快照，用于事后调试。虽然在嵌入式开发中不常生成，但其格式同样遵循 ELF，体现了该规范的普适性。

2. ARM 架构下的 ELF 映像视图：链接、加载与执行

在 ARM 嵌入式系统中，一个.axf或.elf文件远不止是一堆二进制数据的简单集合。它承载着关于程序如何被构建、如何被加载、以及如何被最终执行的全部元信息。ARM 工具链（如armlink）引入了“映像（Image）”这一概念，用以精确描述一个嵌入式程序在不同阶段的内存布局视图。理解这些视图的差异，是解决诸如“为什么我的全局变量没有被初始化？”、“为什么中断向量表不工作？”等典型问题的根本。

2.1 链接器输入视图：输入节（Input Sections）

当链接器开始工作时，它的输入是多个.o文件。每个.o文件内部都包含若干个“输入节（Input Section）”，这些节是编译器和汇编器根据源代码语义自动划分的逻辑单元。例如：

• .text：存放编译生成的机器指令。
• .data：存放已初始化的全局和静态变量。
• .bss：存放未初始化或初始化为零的全局和静态变量（此节在文件中不占用空间，仅在内存中分配）。
• .rodata：存放只读数据，如字符串常量、const变量。

在 ARM 的上下文中，链接器还会识别一些具有特殊属性的输入节，这些属性决定了它们在最终映像中的行为：

• RO（Read-Only）：只读节，如.text和.rodata，通常被放置在 Flash/ROM 中。
• RW（Read-Write）：可读写节，如.data，其初始值存储在 Flash 中，但运行时必须被复制到 RAM 中。
• ZI（Zero-Initialized）：零初始化节，如.bss，其内容在运行前必须被清零，且在 Flash 中不占用空间。
• XO（Execute-Only）：仅执行节，这是 ARM 特有的安全特性，用于存放敏感代码（如加密密钥处理函数），该节在内存中不可读，只能执行，以防止代码被非法读取。

链接器的任务，就是将所有输入.o文件中的同类型输入节（如所有.text）收集起来，按照开发者指定的规则（通常通过一个分散加载文件scatter.ld或*.sct描述），组合成更大的逻辑单元——“输出节（Output Section）”。

2.2 链接器输出视图：输出节与域（Regions）

链接器的输出是一个单一的.axf文件，其内部结构由“输出节（Output Section）”和更高一级的“域（Region）”构成。一个输出节是同一属性（RO/RW/ZI/XO）的多个输入节的线性拼接体。例如，ER_IROM1是一个 RO 输出节，它可能包含了来自main.o的.text、uart.o的.text以及startup.o的.text等所有 RO 属性的输入节。

多个输出节又被组织进一个“域（Region）”中。一个域代表了物理上连续的一片存储器，例如一片 Flash（ER_IROM1）或一片 RAM（RW_IRAM1）。一个域内可以包含多个输出节，其默认顺序是 XO -> RO -> RW -> ZI。这个顺序至关重要，因为它直接决定了内存映射：

• ER_IROM1域：包含所有 RO 和 XO 输出节，被映射到 Flash 地址空间（如0x08000000）。
• RW_IRAM1域：包含所有 RW 和 ZI 输出节，被映射到 RAM 地址空间（如0x20000000）。

然而，这里存在一个关键的工程事实：RW 数据在 Flash 中有副本，但在 RAM 中需要一份运行时副本；ZI 数据在 Flash 中没有副本，但在 RAM 中需要一块被清零的区域。因此，一个完整的嵌入式程序映像，必然包含两个视图：

2.3 加载视图（Load View）与执行视图（Execution View）

这是 ARM ELF 映像最核心、也最容易被误解的概念。

• 加载视图（Load View）描述的是.axf文件被烧录到 Flash 后，其各个域在 Flash 存储器中的物理布局。在这个视图下，ER_IROM1域（包含 RO/XO 代码和 RW 数据的初始值）位于 Flash 的起始地址，而RW_IRAM1域（其内容在 Flash 中并不存在）则是一个“空洞”，或者说，其在 Flash 中的地址范围是未定义的。加载视图是静态的，它只存在于 Flash 芯片中。

• 执行视图（Execution View）描述的是程序在 CPU 上实际运行时，其各个域在系统内存（RAM）中的布局。在这个视图下，ER_IROM1域（RO/XO 代码）仍然位于 Flash 中，但RW_IRAM1域（RW/ZI 数据）则被映射到了 RAM 的指定地址。为了使程序能正确运行，一个至关重要的启动过程（通常由Reset_Handler函数的第一部分完成）必须被执行：

  1. 将ER_IROM1域中紧随 RO 代码之后的 RW 数据（即.data的初始值）从 Flash 复制（copy）到RW_IRAM1域在 RAM 中的对应位置。
  2. 将RW_IRAM1域中 ZI 区域（即.bss）的所有字节清零（zero-initialize）。

这个启动过程，就是连接器在生成.axf文件时，通过在.text节中插入特定的启动代码（__main）来实现的。因此，一个.axf文件的完整生命周期是：编译生成.o-> 链接生成.axf（含加载/执行视图信息）-> 烧录到 Flash（加载视图）-> 上电复位 -> 启动代码执行（copy & zero）-> 程序在 RAM 中运行（执行视图）。

3. ELF 文件结构深度解析：头部、节与段

ELF 文件的物理结构是一个精心设计的、分层的数据容器。其核心由三个关键部分组成：ELF 头部（ELF Header）、节头表（Section Header Table）和程序头表（Program Header Table）。理解这三者的关系与作用，是使用readelf、objdump等工具进行逆向分析和调试的基础。

3.1 ELF 头部（ELF Header）：文件的“身份证”

ELF 头部是整个文件的基石，它位于文件的绝对起始位置（offset 0），大小固定（32 位系统为 52 字节，64 位系统为 64 字节），且其格式是与机器无关的。它不包含任何实际的程序代码或数据，而是一个纯粹的元数据结构，用于告诉操作系统或工具链“这是一个什么样的文件”。

其核心字段及其在嵌入式开发中的意义如下：

• e_ident[EI_MAG0..3](Magic Number)：四个字节0x7F, 'E', 'L', 'F'。这是所有 ELF 文件的“魔数”，是任何解析工具识别 ELF 文件的第一步。在 WinHex 中打开一个.axf文件，你首先看到的就是这四个字节。

• e_ident[EI_CLASS](Class)：标识文件是 32 位（ELFCLASS32）还是 64 位（ELFCLASS64）。对于绝大多数 Cortex-M 微控制器，此值必为1。

• e_ident[EI_DATA](Data Encoding)：标识字节序，ELFDATA2LSB（小端）或ELFDATA2MSB（大端）。ARM Cortex-M 系列默认使用小端模式，因此此值为1。

• e_type(Type)：文件类型。ET_REL（1）表示可重定位文件（.o），ET_EXEC（2）表示可执行文件（.axf,.elf），ET_DYN（3）表示共享对象（.so）。

• e_machine(Machine)：目标机器架构。对于 ARM，其值为EM_ARM（40）。这是工具链判断是否能处理该文件的关键依据。

• e_entry(Entry Point)：程序入口点的虚拟地址。对于.axf文件，此值即为Reset_Handler的地址。对于.o文件，此值通常为0，因为其入口点尚未确定。

• e_phoff/e_shoff(Program/Section Header Offset)：这两个字段是理解 ELF 结构的关键。e_phoff给出程序头表在文件中的字节偏移；e_shoff给出节头表在文件中的字节偏移。只有 ELF 头部的位置是绝对固定的，其余所有内容的位置均由这两个偏移量决定。这意味着，一个.o文件可以没有程序头表（e_phoff = 0），而一个.axf文件可以没有节头表（e_shoff = 0），但这并不影响其作为可执行文件的功能。

• e_flags(Processor-Specific Flags)：ARM 特有的标志位。例如，EF_ARM_ABI_FLOAT_HARD表示该文件使用硬件浮点单元（FPU），EF_ARM_BE8表示该文件为 BE8 模式（大端指令，小端数据），这对于在特定 ARMv6 处理器上运行至关重要。

3.2 节（Sections）与节头表（Section Header Table）：链接时的“蓝图”

节是 ELF 文件中组织代码和数据的最小逻辑单元。节头表则是一个数组，其中的每一项（Elf32_Shdr结构）都是对一个节的详细描述，它告诉链接器：“这个节叫什么名字？它有多大？它在文件的哪个位置？它应该被加载到内存的哪个地址？它有什么样的权限（可读/可写/可执行）？”

一个典型的.axf文件节头表中，你会看到以下关键节：

关键洞察：节（Sections）是为“链接”而生的概念。链接器通过读取节头表，将所有.o文件中的.text节合并，将所有.data节合并，从而构建出最终的可执行映像。因此，节头表对于链接器是必需的，但对于最终的加载和执行过程，却是可选的。一个极度精简的、用于生产环境的固件.bin文件，就完全剥离了.symtab、.strtab和所有.debug_*节，只保留了.text和.data的原始字节流。

3.3 段（Segments）与程序头表（Program Header Table）：加载时的“说明书”

如果说节是为链接器准备的“蓝图”，那么段就是为操作系统或引导加载程序准备的“说明书”。程序头表是一个结构数组，其中的每一项（Elf32_Phdr结构）描述了一个“段（Segment）”，它告诉加载器：“请将文件中从偏移p_offset开始、长度为p_filesz的这段数据，加载到内存地址p_vaddr处，并赋予它p_flags所指定的权限（可读/可写/可执行）”。

一个典型的.axf文件程序头表中，你会看到两个主要的PT_LOAD段：

关键洞察：段（Segments）是为“加载”而生的概念。一个.o文件不需要程序头表，因为它不被直接加载；而一个.axf文件必须有程序头表，否则加载器无法知道如何将其内容安置到内存中。程序头表定义了内存映射，而节头表定义了符号信息。一个文件可以同时拥有两者（如带调试信息的.axf），也可以只拥有其一（如 stripped 的.elf只有程序头表，.o只有节头表）。

4. 嵌入式开发中的关键文件格式：AXF、BIN 与 HEX

在嵌入式开发的日常工作中，工程师会频繁接触.axf、.bin和.hex这三种文件格式。它们并非互斥，而是同一份 ELF 映像在不同场景下的不同表现形式，其选择直接关系到开发效率、调试能力和生产部署的安全性。

4.1 AXF 文件：全功能的调试映像

.axf（ARM eXecutable Format）是 Keil MDK 工具链生成的、符合 ELF 规范的可执行文件。它是功能最完备的格式，是调试阶段的“黄金标准”。

一个.axf文件的内部结构，是前述所有 ELF 概念的完美体现：

• ELF 头部：定义了其为ET_EXEC类型，e_machine = EM_ARM，e_entry指向Reset_Handler。
• 程序头表：定义了 RO 和 RW 两个PT_LOAD段，指导调试器如何将代码和数据加载到目标板的 Flash 和 RAM 中。
• 节头表：包含了.text,.data,.bss,.rodata等所有标准节，以及.symtab,.strtab和大量.debug_*节。
• 调试信息：DWARF 格式的调试信息占据了.axf文件体积的绝大部分。当你在 Keil 中设置断点、查看变量、单步执行时，调试器正是通过解析这些.debug_*节，将机器指令精准地映射回你的 C 源代码行。

因此，.axf文件是开发和调试阶段不可或缺的。但它绝不是最终烧录到芯片上的文件，因为其中包含了大量对最终产品毫无意义的调试元数据，不仅增大了文件体积，更带来了潜在的安全风险（攻击者可以通过分析.axf获取固件的完整符号信息）。

4.2 BIN 文件：最纯粹的机器码

.bin文件是.axf文件的“精华萃取物”。它通过剥离所有非执行内容，只保留了程序在内存中运行所必需的原始字节流。

生成.bin文件的过程，本质上是一个“提取”操作：

1. 定位 RO 段：根据.axf的程序头表，找到第一个PT_LOAD段的p_vaddr（如0x08000000）和p_filesz（如0x1000）。
2. 提取数据：从.axf文件中，将p_offset偏移处开始的p_filesz字节数，按顺序提取出来。
3. 定位 RW 段：找到第二个PT_LOAD段的p_vaddr（如0x20000000）和p_filesz（如0x200），提取其数据。
4. 拼接：将 RO 段数据和 RW 段数据按其在内存中的地址顺序拼接。由于.bin文件本身不包含地址信息，因此在烧录时，用户必须手动指定 RO 段的起始地址（如0x08000000）和 RW 段的起始地址（如0x20000000）。

.bin文件的优点是极致的简洁和高效。它体积最小，烧录速度最快，且不包含任何调试符号，安全性高。它是生产环境中最常用的固件格式。其缺点是失去了所有调试能力，一旦烧录，就无法再通过 JTAG/SWD 进行源码级调试。

4.3 HEX 文件：带地址信息的 ASCII 文本

Intel HEX（.hex）文件是一种由纯 ASCII 字符组成的文本格式，最初由 Intel 公司为 EPROM 编程器设计。它在嵌入式领域依然被广泛支持，尤其是在一些较老的或资源受限的烧录工具中。

一个.hex文件由多行记录（Record）组成，每行以冒号:开头，其格式为:CCAAAARR[DD...]ZZ：

• CC：数据字节数（十六进制）。
• AAAA：数据在内存中的起始地址（十六进制）。
• RR：记录类型（00=数据记录，01=文件结束）。
• [DD...]：实际的十六进制数据字节。
• ZZ：校验和（所有字节之和的补码）。

.hex文件的最大优势在于其自描述性。每一行都明确指出了“这些数据应该被放在内存的哪个地址”。因此，烧录器无需用户额外指定地址，它只需逐行解析，将DD...中的数据写入AAAA指定的地址即可。这使得.hex文件在自动化生产线上非常可靠。

然而，其缺点也很明显：文件体积比.bin大得多（因为是 ASCII 编码，一个字节用两个字符表示），且解析速度慢于二进制格式。在现代嵌入式开发中，.hex文件正逐渐被.bin和更先进的.elf直接烧录所取代，但在兼容性要求高的场景下，它依然是一个重要的备选方案。

5. 符号表与字符串表：链接与调试的基石

在 ELF 文件的众多结构中，符号表（.symtab）和字符串表（.strtab）是连接高级语言（C/C++）与底层机器世界（地址、寄存器）的桥梁。它们是链接器进行符号解析和重定位、调试器进行源码级调试的唯一依据。

5.1 符号表（Symbol Table）

符号表是一个结构体数组，每个元素（Elf32_Sym）描述了一个“符号（Symbol）”，即一个在源代码中定义或引用的实体，如函数名、全局变量名、静态变量名等。其核心字段如下：

• st_name：这是一个索引值，指向字符串表（.strtab）中的一个位置。字符串表中存储着该符号的 ASCII 名称，如"main"、"UART_Init"、"g_counter"。
• st_value：这是符号的“值”，其含义取决于符号的类型和所在文件的类型。
  • 在.o（可重定位）文件中，对于已定义的函数或变量，st_value是该符号在其所在节（如.text）内的节内偏移量。例如，main函数在.text节的第 100 个字节处，则st_value = 100。
  • 在.axf（可执行）文件中，st_value是该符号的最终虚拟地址。例如，main函数被链接到0x08000100，则st_value = 0x08000100。
• st_size：符号的大小（字节数）。对于函数，这是其机器码的长度；对于数组，这是其总字节数。
• st_info：一个复合字段，通过宏ELF32_ST_BIND和ELF32_ST_TYPE提取其绑定（Binding）和类型（Type）。
  • Binding：STB_LOCAL（局部符号，如static函数）、STB_GLOBAL（全局符号，如extern函数）、STB_WEAK（弱符号，可被强符号覆盖）。
  • Type：STT_FUNC（函数）、STT_OBJECT（数据对象，如变量）、STT_SECTION（节本身，用于重定位）、STT_FILE（源文件名）。

一个典型的符号表条目，通过readelf -s命令输出如下：

Num: Value Size Type Bind Vis Ndx Name 1: 00000000 0 FILE LOCAL DEFAULT ABS startup.s 2: 00000000 20 OBJECT LOCAL DEFAULT 3 g_stack_top 3: 00000014 40 FUNC GLOBAL DEFAULT 1 Reset_Handler 4: 00000040 100 FUNC GLOBAL DEFAULT 1 main

这清晰地展示了Reset_Handler和main函数的地址、大小和类型。

5.2 字符串表（String Table）

字符串表（.strtab）是一个简单的、以\0（空字符）结尾的 ASCII 字符串序列。它本身不包含任何结构，只是一个巨大的“字符串池”。符号表中的st_name字段，就是一个指向这个池中某个位置的偏移量。

例如，假设.strtab的内容是：

\0startup.s\0g_stack_top\0Reset_Handler\0main\0

那么，st_name值为0的符号，其名称是空字符串（\0）；st_name值为10的符号（startup.s占 10 个字符+1 个\0），其名称是g_stack_top；依此类推。

这种分离设计（符号表存索引，字符串表存内容）是为了节省空间。如果符号表直接存储字符串，那么每个符号条目都需要一个可变长的字符串字段，这会使符号表的结构变得复杂且难以随机访问。而通过索引，符号表可以保持为一个固定大小的结构体数组，访问效率极高。

5.3 实际工程意义

理解符号表和字符串表，对于解决实际问题至关重要：

• 链接错误：当你遇到undefined reference to 'printf'错误时，readelf -s可以让你确认printf符号是否存在于你的.o文件中（STB_GLOBAL类型），以及它是否在链接库中被定义。
• 内存分析：readelf -S（节头表）和readelf -s（符号表）结合使用，可以精确计算出.text、.data、.bss各自的大小，从而评估你的固件对 Flash 和 RAM 的占用情况。
• 反向工程：在没有源代码的情况下，通过分析.axf文件的符号表，你可以获知固件中所有公开的函数和变量名，这是固件安全审计的第一步。
• 启动代码编写：Reset_Handler的地址必须与符号表中st_value的值完全一致，否则 CPU 复位后将跳转到错误的地址，导致系统崩溃。

6. 总结：从理论到实践的嵌入式 ELF 工程

ELF 文件格式，对于嵌入式工程师而言，既是一套严谨的理论规范，更是一门必须掌握的实践技艺。本文的论述，始终围绕一个核心工程目标展开：让工程师能够基于对 ELF 的深刻理解，去诊断、优化和构建可靠的嵌入式系统。

从规范演进看，ELF 并非凭空而来，它是 COFF 的继承者，是 Unix 系统工程智慧的结晶。在 ARM 生态中，它被无缝集成，成为从armcc编译器到armlink链接器，再到ulink调试器这一整条工具链的共同语言。忽视这一点，就如同试图在不了解 TCP/IP 协议的情况下开发网络应用。

从映像视图看，“加载视图”与