CN116662270A - 文件解析方法及相关装置 - Google Patents

Abstract

本申请实施例提供了文件解析方法及相关装置，其中，该方法包括：创建第一进程以及至少两个第二进程；从上述第一进程获取待解析文件的文件路径，并分配给上述至少两个第二进程，上述至少两个第二进程对应不同的文件路径；基于上述文件路径获取上述至少两个第二进程中每个第二进程对应的上述待解析文件；通过上述第二进程解析对应的上述待解析文件。通过本申请，电子设备可以在开机阶段对待解析文件进行有效解析，并且，本申请可以减少电子设备解析待解析文件花费的时长，从而减少电子设备的开机时长。

Description

文件解析方法及相关装置

技术领域

本申请涉及计算机技术领域，尤其涉及文件解析方法及相关装置。

背景技术

安卓(Android)是一种基于Linux内核、开放源代码的操作系统，在手机、平板电脑等电子设备中应用广泛。

在电子设备的开机阶段，电子设备会启动init进程。其中，上述init进程需要加载大量后缀名为rc的文件(可以简称为rc文件)，然后对rc文件进行解析。rc文件中记录了启动系统服务的步骤和时机，当所有rc文件被解析完成后，将生成对应的service类和action类。电子设备在合适的时机按需启动service、然后执行正确的action，即可完成开机。

发明内容

本申请实施例提供了一种文件解析方法及相关装置，通过本申请，电子设备可以在开机阶段对待解析文件进行有效解析，并且，本申请可以减少电子设备解析待解析文件花费的时长，从而减少电子设备的开机时长。

第一方面，本申请实施例提供了一种文件解析方法，包括：

创建第一进程以及至少两个第二进程；

从上述第一进程获取待解析文件的文件路径，并分配给上述至少两个第二进程，上述至少两个第二进程对应不同的文件路径；

基于上述文件路径获取上述至少两个第二进程中每个第二进程对应的上述待解析文件；

通过上述第二进程解析对应的上述待解析文件。

本申请实施例中，上述文件解析方法可以由电子设备执行。其中，上述电子设备可以是任意一种可执行本申请方法实施例所公开的技术方案的电子设备。可选地，上述电子设备可以是任意能够运行安卓系统的设备，比如可以是手机、平板电脑、可穿戴智能设备等。应理解，本申请方法实施例还可以通过处理器执行计算机程序代码的方式实现。

本申请实施例中，电子设备创建第一进程和至少两个第二进程，其中，至少两个第二进程可以理解为两个第二进程或两个以上第二进程。电子设备可以分别创建上述第一进程和上述至少两个第二进程，可以先创建上述第一进程，在上述第一进程中创建上述至少两个第二进程，本申请对此不作限定。

可以理解的是，不同的进程是相互独立的，在进程运行过程中，每个进程各自有不同的地址空间。本申请实施例中，进程之间的数据交互(例如发送、接收等)应该理解为是基于进程间交互实现的，例如管道、信号量、消息队列、共享内存以及套接字等方式，具体可参阅后文图7和图8的相关描述。其中，进程之间的数据交互例如可以是上述第一进程与第二进程之间的数据交互，以及后续第二进程与第三进程之间的数据交互等。

本申请实施例中，上述待解析文件可以理解为待解析的rc文件，其中，rc文件可以理解为后缀名为rc的文件。

示例性地，上述第一进程可以理解为后文实施例中的分配器进程，上述第二进程可以理解为后文实施例中的解析器进程。本申请实施例中，上述第一进程用于维护电子设备待解析rc文件的文件路径，示例性地，上述第一进程可以创建待解析文件列表，用于记录待解析rc文件的文件路径。

本申请实施例中，电子设备从上述第一进程中获取待解析文件的文件路径，并分配给上述至少两个第二进程，可以理解的是，可选地，电子设备可以创建M个第二进程，将获取的待解析文件的文件路径分配给上述M个第二进程中至少两个第二进程，其中，上述M为大于或等于2的数。

本申请实施例中，电子设备给至少两个第二进程分配待解析文件的文件路径，每个第二进程对应不同的文件路径。其中，每个第二进程对应不同的文件路径，可以理解为，不同的第二进程可以得到不同的待解析文件的文件路径。因此，电子设备通过上述第二进程解析对应的上述待解析文件，可以理解为，每个第二进程根据不同的文件路径获取到不同的待解析文件，对不同的待解析文件进行解析。

可以理解的是，在电子设备通过上述至少两个第二进程对待解析文件进行解析的过程中，不同的待解析文件中的内容是不同的，不同的第二进程对各自对应的待解析文件进行解析需要的时长是不同的。因此，在某些第二进程完成对应的待解析文件解析后，电子设备可以继续从第一进程中获取待解析文件的文件路径，并分配给上述第二进程。

因此，本申请实施例中，从上述第一进程获取待解析文件的文件路径，并分配给上述至少两个第二进程，可以理解为电子设备给上述至少两个第二进程中每个第二进程分配待解析文件的文件路径，也可以理解为电子设备给上述至少两个第二进程中空闲的第二进程分配待解析文件的文件路径。

还应理解，在某些特殊情况下，电子设备无法完全利用全部第二进程，甚至只能利用其中一个第二进程。示例性地，在文件解析的最后阶段，待解析文件的数量小于上述第二进程的数量，比如还剩下3个甚至1个待解析文件，而第二进程的数量为6。在上述特殊情况下，电子设备通过上述至少两个第二进程中部分第二进程解析对应的待解析文件。可以理解的是，上述情况仅仅是特例，在解析的整个过程中，电子设备在大部分时间内是基于至少两个第二进程对待解析文件进行解析的。

可以理解的是，电子设备在启动阶段需要解析的rc文件数量较多。示例性地，电子设备A在启动阶段需要解析的rc文件有248个，电子设备B在启动阶段需要解析的rc文件有264个。相比于其他方案中，电子设备通过单进程对待解析文件进行解析，本申请通过上述至少两个第二进程对待解析文件进程并行解析，可以缩短电子设备在开机阶段解析rc文件花费的时长，从而缩短电子设备开机时长。

结合第一方面，在一种可能的实现方式中，上述通过上述第二进程解析对应的上述待解析文件，包括：

在上述待解析文件中的块section为import语句的情况下，通过上述第二进程将上述import语句中的文件路径作为新的待解析文件的文件路径发送给上述第一进程。

可以理解的是，本申请实施例中，待解析文件的基本组成单位为块(section)，section关键字可以是on，可以称为on语句或on section；也可以是service，可以称为service语句或service section；也可以是import，可以称为import语句或importsection。

本申请实施例中，电子设备利用每个第二进程解析对应的待解析文件的解析过程是相同的。在对待解析文件进行解析时，电子设备先判断待解析文件中的section类型，在上述待解析文件中的section为import语句的情况下，电子设备根据import语句引入新的待解析文件的文件路径。

可以理解的是，import语句中包括一个rc文件的文件路径，电子设备在解析待解析文件A的过程中解析到import语句，可以理解为该import语句中的文件路径对应的文件也需要解析，可以认为是新的待解析文件。

基于本申请实施例中的第一进程和第二进程，本申请中，电子设备在通过第二进程解析对应的待解析文件的过程中遇到import语句时，将import语句中的文件路径作为新的待解析文件的文件路径发送给上述第一进程。

或者，上述过程可以理解为电子设备通过上述第二进程将import语句中的文件路径发送给上述第一进程，上述第一进程将接收到的文件路径作为新的待解析文件的文件路径。后续，电子设备可以从第一进程中获取上述新的待解析文件的文件路径，并分配给上述至少两个第二进程进行解析。

可以理解的是，待解析文件中包括的import语句可能有多个，因此，解析某个待解析文件可能引入多个文件路径，从而引入多个新的待解析文件。

本实施例中，电子设备将import语句引入的文件路径发送给第一进程，以便分配给上述至少两个第二进程中的第二进程进行解析。由此，由某个第二进程解析待解析文件引入的文件A可以由其他第二进程进行解析，可以提高解析待解析文件的效率。

结合第一方面，在一种可能的实现方式中，上述通过第二进程解析对应的上述待解析文件，包括：

在上述待解析文件中的section为on语句的情况下，通过上述第二进程创建上述on语句对应的action类对象；

在上述待解析文件中的section为service语句的情况下，通过上述第二进程创建上述service语句对应的service类对象；

将上述action类对象或上述service类对象作为上述第二进程的本地数据进行存储。

本实施例中，上述第二进程的本地数据可以理解为只能被上述第二进程访问的数据。其他进程将不能访问到上述第二进程的本地数据，例如其他第二进程、上述第一进程以及后续的第三进程等。

结合第一方面，在一种可能的实现方式中，上述方法还包括：

创建第三进程；

在上述待解析文件解析完毕后，通过上述第二进程将上述action类对象和/或上述service类对象发送给上述第三进程；

通过上述第三进程将上述action类对象和/或上述service类对象作为全局数据进行存储。

本实施例中，电子设备创建第三进程，上述第三进程可以理解为后文实施例中的归纳器进程。电子设备可以单独创建上述第三进程，也可以在上述第一进程中创建上述第三进程，本申请对此不作限定。

可以理解的是，待解析文件中包括的section可能有多个，因此，解析某个待解析文件可能得到多个action类对象，或者得到多个service类对象，或者得到多个action类对象和多个service类对象。

本实施例中，电子设备在解析待解析文件的过程中，将得到的action类对象、或者service类对象，或者action类对象和上述service类对象先作为本地数据存储在上述第二进程的存储空间；然后，在该待解析文件解析完毕后，通过上述第二进程将上述类对象发送给上述第三进程。

上述第三进程将接收到的类对象作为全局数据进行存储，其中，上述全局数据可以理解为所有进程均可以访问的数据，其他进程可以通过进程间通信的方式访问到上述全局数据。后续，电子设备可以根据上述action类对象和/或上述service类对象启动service，执行相应的action。

可以理解的是，本申请实施例中，电子设备在解析某个待解析文件时，将上述待解析文件解析完成之后才向上述第三进程发送解析结果，可以减低数据冲突的风险、避免数据混乱，还可以减少第二进程向第三进程发送数据存储请求的数量，节约资源。

结合第一方面，在一种可能的实现方式中，上述方法还包括：

在上述至少两个第二进程全部为空闲状态的情况下，终止上述第一进程，上述至少两个第二进程以及第三进程。

本实施例中，第二进程为空闲状态可以理解为第二进程中没有待解析文件进行解析的状态。电子设备终止上述第一进程、上述至少两个第二进程以及上述第三进程可以通过发送终止指令实现。

结合第一方面，在一种可能的实现方式中，上述待解析文件为后缀名为rc的文件。

可以理解的是，上述待解析文件为后缀名为rc的文件，因此，上述待解析文件也可以称为待解析rc文件。

电子设备对rc文件进行解析，由于rc文件中记录了启动系统服务的步骤和时机，当所有rc文件被解析完成后，电子设备可以启动service以及执行action。因此，本申请实施例中，上述待解析文件的解析结果可以用于启动系统服务。示例性地，上述系统服务可以是服务管理、媒体服务、surfaceflinger以及Zygote等服务。

结合第一方面，在一种可能的实现方式中，上述文件路径包括上述待解析文件的存储路径、文件名以及后缀名。

本实施例中，待解析文件的文件路径包括上述待解析文件的存储路径、文件名以及后缀名。其中，待解析文件的后缀名为.rc。基于上述文件路径，电子设备可以获取到待解析文件进行解析。可以理解的是，上述存储路径可以是相对路径，也可以是绝对路径，具体可以根据import语句的设定为准。

第二方面，本申请实施例提供了一种文件解析装置，包括：

创建单元，用于创建第一进程以及至少两个第二进程；

获取单元，用于从上述第一进程获取待解析文件的文件路径；

分配单元，用于将上述文件路径分配给上述至少两个第二进程，上述至少两个第二进程对应不同的文件路径；

上述获取单元，还用于基于上述文件路径获取上述至少两个第二进程中每个第二进程对应的上述待解析文件；

解析单元，用于通过上述第二进程解析对应的上述待解析文件。

本申请实施例中，上述创建单元，上述获取单元，上述分配单元以及上述解析单元执行的步骤可以由处理器实现。

第三方面，本申请实施例提供一种电子设备，所述电子设备包括处理器、存储器；所述存储器与所述处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，所述处理器调用所述计算机指令，以使第一方面或第一方面的任意可能的实现方式中的方法被执行。

第四方面，本申请实施例提供一种芯片，包括逻辑电路和接口，所述逻辑电路和接口耦合；所述接口用于输入和/或输出代码指令，所述逻辑电路用于执行所述代码指令，以使第一方面或第一方面的任意可能的实现方式中的方法被执行。

第五方面，本申请实施例公开了一种计算机程序产品，上述计算机程序产品包括程序指令，上述程序指令当被处理器执行时，使第一方面或第一方面的任意可能的实现方式中的方法被执行。

第六方面，本申请实施例提供一种计算机可读存储介质，上述计算机可读存储介质中存储有计算机程序，当上述计算机程序在处理器上运行时，使第一方面或第一方面的任意可能的实现方式中的方法被执行。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种安卓系统层次架构框图；

图2是本申请实施例提供的一种安卓系统的启动流程的示意图；

图3是本申请实施例提供的一种section格式的示意图；

图4是本申请实施例提供的一种rc文件的加载流程的示意图；

图5是本申请实施例提供的一种系统架构图；

图6是本申请实施例提供的一种其他分案与本方案解析rc文件的对比图；

图7是本申请实施例提供的一种基于管道实现进程间通信的示例图；

图8是本申请实施例提供的一种基于共享内存实现进程间通信的示意图；

图9是本申请实施例提供的一种分配器进程执行的方法的流程示意图；

图10是本申请实施例提供的一种解析器进程执行的方法的流程示意图；

图11是本申请实施例提供的一种归纳器进程执行的方法的流程示意图；

图12是本申请实施例提供的一种电子设备100的结构示意图。

具体实施方式

本申请以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式，除非其上下文中明确地有相反指示。还应当理解，本申请中使用的术语“和/或”是指并包含一个或多个所列出项目的任何或所有可能组合。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

安卓(Android)是一种基于Linux内核、开放源代码的操作系统，在手机、平板电脑等电子设备中应用广泛。

示例性地，请参阅图1，图1是本申请实施例提供的一种安卓系统层次架构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，可以将Android系统分为四层，包括应用程序层，应用程序框架层，系统运行库层以及内核层。对上述各个层的描述如下：

首先，应用程序层可以包括一系列应用程序包。示例性地，应用程序层的应用程序包可以包括相机、图库、日历、通话、地图、导航、浏览器、音乐、视频以及短信息等应用程序。

其次，应用程序框架层可以为应用程序层中的应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层可以包括一些预先定义的函数。

示例性地，上述应用程序框架层可以包括活动管理器(activity manager)、窗口管理器(window manager)、内容提供器(content provider)、视图系统(view system)、电话管理器(telephony manager)、资源管理器(resource manager)以及通知管理器(notification manager)等。其中：

活动管理器可以用于管理各个应用程序生命周期以及通常的导航回退功能。

窗口管理器可以用于管理窗口程序。示例性地，窗口管理器可以获取电子设备100的显示屏大小，锁定屏幕，截取屏幕以及判断是否有状态栏等。

内容提供器可以用来存放和获取数据，并使这些数据可以被应用程序访问，使得不同的应用程序之间可以存取或分享数据。示例性地，上述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签以及电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供电子设备100的通信功能，例如通话状态的管理(包括接通电话，挂断电话等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。示例性地，通知管理器可以被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

再者、系统运行库层可以包括系统库和安卓运行时(Android runtime)。其中：

安卓运行时包括核心库和虚拟机。安卓运行时负责安卓系统的调度和管理。其中，核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以理解为应用程序框架的支撑，是连接应用程序框架层与内核层的重要纽带。系统层可以包括多个功能模块，例如可以包括表面管理器(surface manager)，媒体库(media libraries)，三维图形处理库(例如OpenGL ES)，二维图形引擎(例如：SGL)等。其中：

表面管理器可以用于对显示子系统进行管理，比如在电子设备100执行多个应用程序的情况下，负责管理显示与存取操作间的互动。表面管理器还可以用于为多个应用程序提供了2D和3D图层的融合。

媒体库可以支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如可以是MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成以及图层处理等。

2D图形引擎可以理解为2D绘图的绘图引擎。

最后，内核层可以理解为硬件和软件之间的抽象层。内核层可以包括安全性、内存管理、进程管理、电源管理、网路协议管理以及驱动管理等系统服务。示例性地，内核层可以包括显示驱动，摄像头驱动，音频驱动以及传感器驱动等。

如图1所示的架构框图，从上至下分别是应用程序层，应用程序框架层，系统运行库层，以及内核层。而安卓系统的启动流程可以理解为是自下而上的，示例性地可以包括三个阶段：

第1阶段、引导启动内核。

第2阶段、启动Linux内核。

第3阶段、启动安卓系统。

为便于理解，示例性地，请参阅图2，图2是本申请实施例提供的一种安卓系统的启动流程的示意图。

可以理解的是，电子设备中的硬件可以包括中央处理器(central processingunit，CPU)、内存(memory)、存储器、显卡、显示器以及键盘鼠标等其他输入输出设备。电子设备中的软件存储在存储器上，例如安卓操作系统或者上述应用程序层中的软件等，程序执行时需要将程序从存储器上读取到内存中，然后加载到CPU中运行。

如图2所示，安卓系统的启动流程可以包括：

201：启动电源启动系统。

示例性地，按下电子设备的电源键后，触发加载并执行预定义代码，以启动引导加载程序(bootloader)。其中，加载预定义代码也可以理解为以固化在存储器上的预定义位置为起始执行代码，上述预定义代码可以称为boot_rom。

202：启动引导程序。

本步骤中，通过bootloader引导Linux内核(kernel)的启动。其中，bootloader可以理解为安卓操作系统开始运行之前运行的一段程序，主要用于引导内核启动，设置安卓系统的启动参数。

203：启动Linux内核。

经过bootloader的引导，本步骤对Linux内核进行加载，以初始化各种软硬件环境、加载驱动程序以及根据上述启动参数启动安卓操作系统等。

可以理解的是，在内存管理单元和缓存被初始化后，可以使用虚拟内存并启动用户空间进程。因此，在Linux内核加载的最后阶段，会启动执行文件系统中的用户空间进程，即init进程。

204：启动init进程。

本步骤中，基于init进程，主要创建和挂载系统启动所需的目录文件、开启属性服务以及解析init.rc文件等。其中，init.rc文件可以理解为由安卓初始化语言编写的脚本文件，记录了启动系统服务的步骤和时机。

本申请实施例中，rc文件可以理解为安卓系统启动过程中后缀名为rc的文件。

示例性地，上述init.rc文件可以理解为rc文件，init.rc文件由init进程进行解析。基于init进程对init.rc文件的解析，将进一步对其他rc文件进行解析，当所有rc文件被解析完毕后，系统服务启动完成，安卓系统也随之运行起来。其中，上述系统服务包括服务管理(service manager)、媒体服务(media server)、surfaceflinger以及Zygote等服务。

可以理解的是，rc文件的基本组成单位为块(section)，一个section可以包含多行。其中，section包括3种类型，分别由on、service、import关键字进行区分。

为便于理解，示例性地，请参阅图3，图3是本申请实施例提供的一种section格式的示意图。

如图3所示，一个section示例性地可以包括5行，第一行的关键字可以是on(可以称为on section)，也可以是service(可以称为service section)，也可以是import(可以称为import section)。

对于on section，电子设备将调用parse_action函数创建action类对象。

对于service section，电子设备将调用parse_service函数创建service类对象。

对于import section，电子设备将根据import引入其他rc文件，在解析完init.rc文件后对引入的其他rc文件进行解析。

示例性地，import section的格式可以描述为：import<rc文件的文件路径>。rc文件中可以包括多个import section，可以引入多个其他rc文件。

本申请实施例中，文件路径包括文件的文件名称以及获取该文件的路径，其中，该路径可以是相对路径，也可以是绝对路径。本申请实施例中，import中的文件路径为rc文件的文件路径，示例性地，rc文件的文件路径可以是/AAAA/BB/CCCC/DD.rc。其中，/AAAA/BB/CCCC表示rc文件的相对路径，DD表示rc文件的名称，rc表示rc文件的后缀名。

对于安卓系统启动过程中rc文件的加载流程，示例性地，请参阅图4，图4是本申请实施例提供的一种rc文件的加载流程的示意图。如图4所示的流程包括以下步骤：

401：将init.rc文件加入待解析文件列表中。

可以理解的是，init.rc文件由是init进程解析的第一个rc文件，其他rc文件是基于init.rc文件中的import section引入的。因此，rc文件的解析流程中，首先将init.rc文件加入待解析文件列表对init.rc文件进行解析。

402：从待解析文件列表中选取一个rc文件。

可以理解的是，在初始阶段，待解析文件列表中仅包括init.rc文件，那么本步骤中选取的rc文件为init.rc文件。在init.rc文件解析完成后，本步骤中选取的rc文件可以是其他rc文件。

403：确定该rc文件中section的类型。

如前文的描述可以知道，rc文件中可包括多个section，不同类型的section有不同的处理方式。本步骤中，确定该rc文件中的section的类型可以适用每个section，即该rc文件中的每个section都可以采用步骤403-步骤408进行解析。

在section为on section的情况下，执行步骤404：构造并创建action类对象。然后执行步骤405：将action类对象加入action对象列表。

在section为service section的情况下，执行步骤406：构造并创建service类对象。然后，执行步骤407：将service类对象加入service对象列表。

在section为import section的情况下，执行步骤408：将import语句中的文件路径加入待解析文件列表。

如前文的描述可以知道，import section中包括rc文件的文件路径，在section为import section的情况下，电子设备将import section指示的文件路径加入待解析文件列表，以便后续对指示的rc文件进行解析。

在步骤405之后，或在步骤407之后，或步骤408之后，执行步骤409：判断待解析文件列表是否为空。

在步骤409的判断结果为是的情况下，可以认为完成所有待解析rc文件的解析，即执行步骤410：确定完成rc文件解析。

在步骤409的判断结果为否的情况下，重新执行步骤402，可以理解的是，在重新执行步骤402时，从待解析文件列表中确定一个其他rc文件进行解析。

可以理解的是，电子设备在开机阶段，一般有几百个rc文件需要解析，解析一个rc文件需要的时长平均需要几十毫秒。因此，在开机阶段采用如图4所示的方式对rc文件进行解析，耗时长。

基于上述问题，本申请实施例提供了一种文件解析方法及相关装置，本申请通过创建多个线程对待解析rc文件进行并行解析，相比与上述图4所示的串行解析方法，本申请可以缩短电子设备在开机阶段解析rc文件花费的时长，从而缩短电子设备开机时长。

本申请实施例提供的文件解析方法可以由电子设备执行，上述电子设备可以是任意一种可执行本申请方法实施例所公开的技术方案的电子设备。可选的，上述电子设备可以是任意能够运行安卓系统的设备，比如可以是手机、平板电脑、可穿戴智能设备等。应理解，本申请方法实施例还可以通过处理器执行计算机程序代码的方式实现。

本申请实施例中，电子设备创建分配器进程、n个解析器进程以及归纳器进程，基于上述进程实现上述文件解析方法。其中，上述n为大于或等于2的整数。为便于理解本申请提出的方法，接下来首先介绍分配器进程、n个解析器进程以及归纳器进程组成的系统，然后分别对分配器进程、解析器进程以及归纳器进程的执行流程进行介绍。

示例性地，请参阅图5，图5是本申请实施例提供的一种系统架构图。

如图1所示的系统包括分配器进程、n个解析器进程(例如图5所示的解析器进程1、解析器进程2、解析器进程3以及解析器进程n等)以及归纳器进程。其中，本申请实施例中，n为大于或等于2的整数。对于上述分配器进程、上述解析器进程以及上述归纳器进程的描述如下：

1、分配器进程用于维护全局(global)的待解析rc文件列表，以及给解析器进程分配待解析rc文件进行解析。

2、解析器进程用于对待解析rc文件进行解析。本申请实施例中，上述解析器进程应该理解为上述n个解析器进程中的任一个解析器进程。

本申请实施例中，解析器进程在本地维护局部(local)的action对象列表和service对象列表，当解析完某个rc文件(比如rc文件A)时，解析器进程将本地action对象列表和/或本地service对象列表交由归纳器进程归档；将import section引入的新的待解析rc文件的文件路径发送给分配器，由分配器对该新的待解析rc文件进行分配。

3、归纳器进程用于维护全局的action对象列表和service对象列表。

本申请实施例中，一个进程将数据发送给另外一个进程可以称为推(push)数据，推数据之前发送的请求可以称为push请求。类似地，一个进程从另一个进程获取数据可以称为拉(pull)数据，拉数据之前的请求可以称为pull请求。

示例性地，解析器进程将新的待解析rc文件的文件路径发送给分配器可以理解为解析器进程将该新的待解析rc文件的文件路径推(push)给分配器进程，因此，解析器进程实现上述过程调用的请求可以称为push请求。解析器进程从分配器进程获取待解析rc文件的文件路径可以理解为解析器进程从分配器进程拉(pull)该待解析rc文件的文件路径，因此，解析器进程实现上述过程调用的请求可以称为pull请求。

又示例性地，解析器进程将本地action对象列表和本地service对象列表发送给归纳器进程进行归档，可以理解为，解析器进程将本地action对象列表和本地service对象列表push给归纳器进程，因此，解析器进程实现上述过程调用的请求可以称为push请求。

本申请通过上述分配器、n个解析器进程以及分配器之间的配合对rc文件进行解析，可以有效地减少解析rc文件的时长。示例性地，请参阅图6，图6是本申请实施例提供的一种其他分案与本方案解析rc文件的对比图。

如图6中的(a)可以理解为采用其他方案就进行rc文件解析的过程，电子设备在时刻t₁启动init进程，在时刻t₂开始基于如图4所示的方法解析rc文件，在时刻t₃时完成rc文件解析。其中，时刻t₂至时刻t₃之间的时间间隔可以理解为其他方案进行rc文件解析所需要的时长，可以简称时长T₁。

如图6中的(b)可以理解为采用本方案就进行rc文件解析的过程，电子设备在时刻t₄启动init进程，在时刻t₅开始基于如图5所示的进程解析rc文件，在时刻t₆时完成rc文件解析。其中，时刻t₅至时刻t₆之间的时间间隔可以理解为本方案进行rc文件解析所需要的时长，可以简称时长T₂。

可以理解的是，如图6中的时刻t₁和时刻t₄为启动init进程的时刻，可以理解为前文不步骤204。对比如图6中的(a)和如图6中的(b)可以得到，时长T₂小于时长T₁，即电子设备采用本方案的方法对rc文件进行解析将花费更少的时间。

通过如图5所示的系统可以理解，本申请实施例涉及不同进程之间的通信，即进程间通信(inter-process communication，IPC)。因此，在详细介绍本申请实施例提供的方法之前，首先介绍进程间通信。

进程(process)可以理解为一段程序的执行过程，是系统资源分配的基本单位。进程可以理解为实体，每个进程在电子设备中都有自己独立的地址空间，一般地，电子设备会为每个启动的进程分配地址空间，建立数据表来维护代码段、堆栈段和数据段。

进程间通信可以理解为不同进程之间的数据交换。可以理解的是，正是由于每个进程在运行过程中是独立的，即每个进程各自有不同的地址空间，一个进程中的变量在另一个进程中无法访问到，所以才需要进程间通信进行数据传输，资源共享以及进程控制等。示例性地，本申请实施例中，进程间通信可以通过管道、信号量、消息队列、共享内存(shared memory)以及套接字(socket)等方式实现。

接下来示例性地对利用管道和利用共享内存实现进程间通信进行介绍。

1、管道

示例性地，管道可以理解为一个进程连接到另一个进程的数据流，一个数据流可以理解为一个管道。利用管道进行进程间通信可以理解为借助操作系统在内核区创建一块缓冲区，由需要通信的进程分别写入、读出数据。

为便于理解，示例性地，请参阅图7，图7是本申请实施例提供的一种基于管道实现进程间通信的示例图。

如图7所示，管道包括读端和写端，数据从管道的写端流入管道，从读端流出。进程A和进程B为两个不同的进程，进程A对管道进行写操作，进程B向管道进行读操作，从而把进程A的输出和进程B的输入连接在一起，实现进程A与进程B之间的通信。

管道本质上可以理解为文件，因此，用管道实现进程间的通信，实际上是通过文件来实现进程间的通信。管道可以包括无名管道(或者可以称为匿名管道)和有名管道(或者可以称为命名管道)。其中，无名管道用于父进程和子进程间的通信，有名管道用于运行在同一系统中的任意两个进程间的通信。

对于无名管道，示例性地，父进程可以调用pipe函数创建管道文件(为便于理解可以称为管道文件A)，并且得到分别指向管道文件的读端和写端的文件描述符(filedescriptor，fd)。父进程可以调用fork创建子进程，由于子进程会继承父进程代码，因此，子进程也包括两个文件描述符指向上述管道文件A。

父进程关闭管道文件A的读端，子进程关闭管道文件A的写端。那么父进程可以向管道文件A中写入数据，子进程可以将管道文件A中的数据读出，这样就实现了进程(上述父进程和上述子进程)间通信。

对于有名管道，存在与有名管道相关联的路径名，使得能够访问该路径的进程实现通信。示例性地，可以先创建一个管道文件，一个进程以读或者写的方式来打开该管道文件，另一个进程不需要创建管道文件，而是以写或者读的方式来打开该管道文件，即可实现进程(任意两个进程)间通信。

2、共享内存

示例性地，利用共享内存进行进程间通信可以理解为两个或者多个进程共享物理内存的同一块区域(或者可以称为段)。多个进程可以将同一个物理内存连接到它们自己的地址空间中，使得上述多个进程都可以访问同一个物理内存，即访问共享内存中的地址。

为便于理解，示例性地，请参阅图8，图8是本申请实施例提供的一种基于共享内存实现进程间通信的示意图。

可以理解的是，每个进程都有属于自己的进程控制块(process control block，PCB)和逻辑地址空间(addr space)，例如图8所示，进程A有进程A的PCB，进程B有进程B的PCB；进程A有进程A的逻辑地址空间，进程B有进程B的逻辑空间地址。并且，每个进程都有一个与之对应的页表，例如图8所示，进程A有页表A，进程B有页表B。其中，PCB可以理解为存放进程的管理和控制信息的数据结构。页表用于将进程的逻辑地址(也可以理解为虚拟地址)与物理地址进行映射。

如图8所示，进程A和进程B为两个不同的进程，页表A用于进程A的逻辑地址与物理地址之间的映射，页表B用于进程B的逻辑地址与物理地址之间的映射。在两个不同进程的逻辑地址通过页表映射到物理空间的同一区域，它们所共同指向的这块区域可以理解为共享内存，如图8中带有灰色填充的部分。

基于上述进程间通信的介绍，接下来对本申请实施例中分配器、解析器以及归纳器执行的流程进行详细介绍。

需要说明的是，本申请实施例中，进程之间的数据交互是基于进程间通信实现的。本申请是为了便于描述和理解将进程间通信描述为进程间的数据通信，例如数据发送或数据接收。应理解，进程间的数据通信在本质上应该理解为进程间通信，是基于函数调用实现的，而不应该理解为设备之间的数据发送或数据接收等。

因此，后文实施例中，分配器进程、解析器进程以及归纳器进程之间的通信同样适用前文介绍的进程间通信，例如可以采用图7所示的管道方式以及图8所示的共享内存方式实现，后续将不再赘述。示例性地，解析器进程向分配器进程发送push请求和pull请求可以理解为进程间通信。

需要说明的是，本申请实施例中，步骤之前的编号应该理解为步骤的标识，一方面便于回引对方案进行描述，另一方面增加可读性便于读者理解方案，而不应该理解为步骤执行的先后顺序的限定。

首先，介绍本申请实施例提供的分配器进程的执行流程。

示例性地，请参阅图9，图9是本申请实施例提供的一种分配器进程执行的方法的流程示意图。如图9所示，分配器的执行流程包括：

901：创建n个解析器进程。

可以理解的是，由于进程是独立的，每个进程占用CPU中的一个核，因此，在CPU的核的数量为n+2的情况下，可以创建n个解析器进程，其余两个核可以分别用于运行分配器进程和归纳器进程。

本申请实施例中，解析器进程和归纳器进程可以理解为由分配器进程创建。或者，可以理解为某个进程创建好解析器进程和归纳器进程后，在后续用于实现本申请实施例中的分配器的功能。

可以理解的是，本申请实施例中的分配器进程、解析器进程以及归纳器进程是基于进程的功能进行命名的，以便于读者理解，它们本质上是不同的进程。

902：创建归纳器进程。

本申请实施例中，不限定创建解析器和创建归纳器的先后顺序，也就是说，本申请不限定上述步骤901和步骤902的执行顺序，也可以先执行步骤902，再执行步骤901。

903：初始化全局待解析rc文件列表。

可以理解的是，由于不同的进程是相互独立的，某个进程内部的数据可以理解为本地数据，本地数据只能由该进程访问，其他进程无法访问。可以被多个进程访问的数据可以理解为全局数据。

因此，本申请实施例中，上述全局待解析rc文件列表可以理解为解析器进程和分配器进程访问的待解析rc文件列表。上述待解析rc文件列表用于记录待解析rc文件的文件路径。示例性地，上述全局待解析rc文件列表可以包括两个待解析rc文件的文件信息，例如rc文件1为/AAA/BBBB/CC.rc、rc文件2为/DDD/EE/FFFFF/KK.rc。其中，rc文件1的存储路径为/AAA/BBBB，rc文件1的名称为CC；rc文件1的存储路径为/DDD/EE/FFFFF，rc文件2的名称为KK。

904：判断是否接收到解析器进程发送的请求。

在步骤904的判断结果为否的情况下，分配器进程重新执行步骤904，即再次判断是否接收到解析器进程发送的请求。

本申请实施例中，在创建完成解析器进程后，解析器进程将周期性向分配器进程发送pull请求，以获取待解析rc文件进行解析。另外，解析器进程在待解析rc文件中解析到import语句时，将向分配器进程发送push请求，然后将import语句引入的新的待解析rc文件的文件路径发送给分配器进程。因此，分配器进程将判断是否接收到解析器进程发送的请求，并且在接收到请求的情况下，根据请求类型进行后续处理。

在接收到的请求为push请求的情况下，分配器进程执行步骤905：将解析器进程发送的文件路径加入全局待解析rc文件列表。

本步骤中，分配器进程接收到解析器进程发送的push请求的情况下，接收解析器进程发送的文件路径，该文件路径为解析器进程在解析某个rc文件时，该rc文件中的import语句引入的新的待解析rc文件的文件路径。

步骤905之后，执行步骤904，即再次判断是否接收到解析器进程发送的请求。

在接收到的请求为pull请求的情况下，分配器进程执行步骤906：判断全局待解析rc文件列表是否为空。

可以理解的是，在创建完成解析器进程后，解析器进程将周期性向分配器进程发送pull请求，以获取待解析rc文件进行解析。因此，在分配器进程接收到解析器进程发送的pull请求的情况下，判断全局待解析rc文件列表是否为空。

在步骤904的判断结果为否的情况下，分配器进程执行步骤907：从全局待解析rc文件列表中出队一个待解析rc文件的文件路径，将该文件路径发送给解析器进程。

可以理解的是，全局待解析rc文件列表用于记录待解析rc文件的文件路径，因此，全局待解析rc文件列表中的一个文件路径就可以理解为对应一个待解析rc文件。分配器进程从全局待解析rc文件列表中出队一个待解析rc文件的文件路径，把该文件路径发送给某个解析器进程后，该文件路径将不再分配给其他解析器进程。

步骤907之后，分配器进程执行步骤904，即再次判断是否接收到解析器进程发送的请求。

在步骤904的判断结果为是的情况下，执行步骤908：判断n个解析器是否全部为空闲状态。

可以理解的是，在全局待解析rc文件列表为空的情况下，可以认为当前没有待解析rc文件。此时可能是解析器进程还在对rc文件进行解析，暂时没有import语句引入新的rc文件；也可能是全部rc文件已经解析完成，解析器进程已经全部空闲。因此，在全局待解析rc文件列表为空的情况下，分配器进程判断n个解析器是否全部为空闲状态。

示例性地，分配器进程从全局待解析rc文件列表中出队文件路径时，可以按照时间先后顺序，先进先出或者先进后出的原则进行出队，本申请实施例对此不作限定。

在步骤908的判断结果为否的情况下，分配器进程重新执行步骤904，即再次判断是否接收到解析器进程发送的请求。

在步骤908的判断结果为是的情况下，分配器进程执行步骤909：确定rc文件解析完成。

在步骤909之后，分配器进程执行步骤910：向解析器进程和分配器进程发送终止指令。

911：终止分配器进程。

可以理解的是，在解析器进程已经全部空闲的情况下，可以认为全部rc文件已经解析完成，因此，分配器进程向解析器进程(上述n个解析器进程)和分配器进程发送终止指令，以终止解析器进程和分配器进程，然后终止分配器进程。

接下来，介绍本申请实施例提供的解析器进程的执行流程。

示例性地，请参阅图10，图10是本申请实施例提供的一种解析器进程执行的方法的流程示意图。可以理解的是，本申请实施例中的解析器进程有多个，如图10所示的流程可以适用任一个解析器进程。如图10所示，解析器的执行流程包括：

1001：向分配器进程发送pull请求。

本申请实施例中，在创建好解析器进程后，解析器进程周期性地向分配器进程发送pull请求，以获取待解析rc文件进行解析。示例性地，在解析器进程没有解析任务时，解析器进程可以每间隔100毫秒向分配器进程发送pull请求。

可以理解的是，本申请实施例中的解析器进程的数量大于或等于2，因此，分配器进程可以接收到多个解析器进程发送的pull请求，可选地，分配器进程可以按照时间优先原则，先接收到哪个解析器进程的pull请求就先给哪个解析器进程分配解析任务。

在某些特殊情况下，分配器进程同时接收到多个解析器进程的pull请求的情况下，可以根据实际情况进行任务分配，比如可以随机分配，也可以先给创建时间早的解析器进程分配任务，本申请对此不作限定。

1002：判断是否接收到分配器进程发送的文件路径。

本步骤可以与前文图9所示的步骤907对应，分配器进程在全局待解析rc文件列表不为空的情况下，从全局待解析文件列表中出队一个待解析rc文件的文件路径，将该文件路径发送给解析器进程，相应地，本步骤中，解析器进程判断是否接收到分配器进程发送的文件路径。

在步骤1002的判断结果为否的情况下，解析器进程执行步骤1003：判断是否接收到分配器发送的终止指令。

本步骤可以与前文图9所示的步骤910对应，分配器进程在确定n个解析器进程全部为空闲状态的情况下，向解析器进程发送终止指令，相应地，解析器进程接收分配器发送的终止指令。

在步骤1003的判断结果为否的情况下，解析器进程执行步骤1001，即再次向分配器进程发送pull请求。

在步骤1003的判断结果为否的情况下，解析器进程执行步骤1004：终止解析器进程。

在步骤1002的判断结果为是的情况下，解析器进程执行步骤1005：初始化本地action对象列表。

1006：初始化本地service对象列表。

本实施例中，解析器进程维护本地action对象列表和本地service对象列表，如前文步骤903的相关描述，只有创建本地action对象列表和本地service对象列表的解析器进程才能访问本地action对象列表和本地service对象列表。

本实施例中，上述本地action对象列表用于存储rc文件中根据action section得到的action对象的数据，上述本地service对象列表用于存储rc文件中根据servicesection得到的service对象的数据。

可以理解的是，本申请不限定本地action对象列表和本地service对象列表的创建顺序，也就是说，可以先执行步骤1005，再执行步骤1006；也可以先执行步骤1006，再执行步骤1005。

1007：根据该文件路径获取待解析rc文件。

可以理解的是，解析器进程从分配器进程接收到该文件路径后，可以根据该文件路径获取待解析rc文件，然后对该待解析rc文件进行解析。对rc文件的解析过程可以包括步骤1008-步骤1015。

1008：确定该待解析rc文件中section的类型。

根据前文图3对rc文件的介绍可以理解，rc文件以section为单位。对待解析rc文件进行解析时，不同类型的section对应不同的解析方式。

在section为on section的情况下，解析器进程执行步骤1009：构造并创建action类对象。然后，执行步骤1010：将action类对象加入本地action对象列表。

在section为service section的情况下，解析器进程执行步骤1011：构造并创建service类对象。然后，执行步骤1012：将service类对象加入本地service对象列表。

在section为import section的情况下，解析器进程执行步骤1013：向分配器进程发送push请求。然后执行步骤1014：向分配器进程发送新的待解析rc文件的文件路径。

可以理解的是，一个rc文件中可以包括多个section，解析器进程对每个section的解析都可以是上述步骤1008-步骤1014对应的流程。同样地，一个rc文件中可以包括多个import section，因此，解析器进程解析完一个rc文件可以向分配器进程发送多个新的待解析的rc文件。

本申请实施例中，解析器进程在解析某个rc文件时，该rc文件中的import语句中的文件路径可以理解为新的待解析rc文件的文件路径。

在步骤1010之后，或者，在步骤1012之后，或者，在步骤1014之后，解析器进程执行步骤1015：判断该待解析rc文件是否解析完毕。

可以理解的是，在该待解析rc文件中全部section被解析完毕的情况下，可以认为该待解析rc文件是否解析完毕。

在步骤1015的判断结果为否的情况下，解析器进程执行步骤1008，即再次确定该rc文件中section的类型，可以理解的是，步骤1015之后再执行步骤1018时的section应该理解为与之前的步骤1008中不同的section。

在步骤1015的判断结果为是的情况下，解析器进程执行步骤1016：向归纳器进程发送push请求。

1017：将本地action对象列表和本地service对象列表发送给归纳器进程。

步骤1017之后，解析器进程执行步骤1001，即再次向分配器进程发送pull请求，以获取到下一个待解析rc文件进行解析。

最后，介绍本申请实施例中的归纳器进程的执行流程。

示例性地，请参阅图11，图11是本申请实施例提供的一种归纳器进程执行的方法的流程示意图。如图11所示，归纳器进程的执行流程包括：

1101：初始化全局action对象列表。

1102：初始化全局service对象列表。

本实施例中，归纳器进程维护全局action对象列表和全局service对象列表，如前文步骤903和步骤1006的相关描述，全局action对象列表和全局service对象列表可以被所有进程访问。

可以理解的是，本申请不限定全局action对象列表和全局service对象列表的创建顺序，也就是说，可以先执行步骤1101，再执行步骤1102；也可以先执行步骤1102，再执行步骤1101。

1103：判断是否接收到解析器进程发送的push请求。

本步骤可以与前文图10所示的步骤1016对应，解析器进程在解析完某个待解析rc文件后，向归纳器进程发送push请求。相应地，归纳器进程接收该push请求。

在步骤1103的判断结果为是的情况下，归纳器进程执行步骤1106：将解析器进程发送的action对象加入全局action对象列表，以及，将解析器进程发送的service对象加入全局service对象列表。

步骤1106之后，归纳器进程执行步骤1103，即再次判断是否接收到解析器进程发送的push请求。

在步骤1103的判断结果为否的情况下，归纳器进程执行步骤1104：判断是否接收到分配器发送的终止指令。

本步骤可以与前文图9所示的步骤910对应，分配器进程在确定rc文件解析完成的情况下，向解析器进程和归纳器进程发送终止指令。相应地，归纳器进程接收分配器发送的终止指令。

在步骤1104的判断结果为否的情况下，归纳器进程执行步骤1103，即再次判断是否接收到解析器进程发送的push请求。

在步骤1104的判断结果为是的情况下，归纳器进程执行步骤1105：终止分配器进程。

可以理解的是，本申请实施例中，不同的进程同时运行不同的CPU核心上，是相互独立的。当不同的解析器进程同时向归纳器进程发送数据时，一方面可能会导致数据冲突，另一方面将导致归纳器进程接收到的数据混乱。

本申请实施例中，解析器进程在解析某个待解析rc文件的过程中，可能会解析到多个action section和多个service section，本申请先将创建的action对象和service对象作为本地数据存储起来，比如存储在该解析器进程的内存空间上。然后，在上述待解析rc文件解析完成后再统一将action对象和service对象发送给归纳器进程，可以降低数据冲突风险，以及避免数据混乱。将上述action对象和上述service对象作全局数据进行存储，使得所有进程都能够访问到上述action对象和上述service对象，进行后续的系统服务启动。

综上所述，其他方案(例如图4所示的方案)采用单进程对rc文件进行解析，所有rc文件只能按串行处理方式，依次被加载解析。对于多核CPU来说，采用上述串行处理方式解析rc文件的耗时长，效率低。

本申请提出的文件解析方法通过多个进程实现rc文件的并行解析，充分利用CPU硬件处理性能，大大提升了解析rc文件的效率，从而提高Android系统的启动速度，减少电子设备的开机时长。

以上详细介绍了本申请实施例提供的方法，接下来对本申请实施例涉及的电子设备进行介绍。

请参阅图12，图12是本申请实施例提供的一种电子设备100的结构示意图。

电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，传感器模块180，按键190，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中，传感器模块180可以包括压力传感器180A，指纹传感器180B，触摸传感器180C等。

可理解地，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图12所示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图12所示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或USB接口等。

I2C接口是一种双向同步串行总线，包括一根串行数据线(serial data line，SDA)和一根串行时钟线(derail clock line，SCL)。在一些实施例中，处理器110可以包含多组I2C总线。处理器110可以通过不同的I2C总线接口分别耦合触摸传感器180C，充电器，闪光灯，摄像头193等。例如：处理器110可以通过I2C接口耦合触摸传感器180C，使处理器110与触摸传感器180C通过I2C总线接口通信，实现电子设备100的触摸功能。

I2S接口可以用于音频通信。在一些实施例中，处理器110可以包含多组I2S总线。处理器110可以通过I2S总线与音频模块170耦合，实现处理器110与音频模块170之间的通信。在一些实施例中，音频模块170可以通过I2S接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。

PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过PCM总线接口耦合。在一些实施例中，音频模块170也可以通过PCM接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。所述I2S接口和所述PCM接口都可以用于音频通信。

UART接口是一种通用串行数据总线，用于异步通信。该总线可以为双向通信总线。它将要传输的数据在串行通信与并行通信之间转换。在一些实施例中，UART接口通常被用于连接处理器110与无线通信模块160。例如：处理器110通过UART接口与无线通信模块160中的蓝牙模块通信，实现蓝牙功能。在一些实施例中，音频模块170可以通过UART接口向无线通信模块160传递音频信号，实现通过蓝牙耳机播放音乐的功能。

MIPI接口可以被用于连接处理器110与显示屏194，摄像头193等外围器件。MIPI接口包括摄像头串行接口(camera serial interface，CSI)，显示屏串行接口(displayserial interface，DSI)等。在一些实施例中，处理器110和摄像头193通过CSI接口通信，实现电子设备100的拍摄功能。处理器110和显示屏194通过DSI接口通信，实现电子设备100的显示功能。

GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。在一些实施例中，GPIO接口可以用于连接处理器110与摄像头193，显示屏194，无线通信模块160，音频模块170，传感器模块180等。GPIO接口还可以被配置为I2C接口，I2S接口，UART接口，MIPI接口等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。

可理解地，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。

在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在另一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图片或视频。

在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(codedivision multiple access，CDMA)，宽带码分多址(wideband code division multipleaccess，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidounavigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellitesystem，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图片，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图片或视频播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备100可以设置至少一个麦克风170C。在另一些实施例中，电子设备100可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备100还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。电子设备100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，电子设备100根据压力传感器180A检测所述触摸操作强度。电子设备100也可以根据压力传感器180A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。

指纹传感器180B用于采集指纹。电子设备100可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。

触摸传感器180C，也称“触控面板”。触摸传感器180C可以设置于显示屏194，由触摸传感器180C与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180C用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180C也可以设置于电子设备100的表面，与显示屏194所处的位置不同。

按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。

SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和电子设备100的接触和分离。电子设备100可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口195可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口195可以同时插入多张卡。所述多张卡的类型可以相同，也可以不同。SIM卡接口195也可以兼容不同类型的SIM卡。SIM卡接口195也可以兼容外部存储卡。电子设备100通过SIM卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，电子设备100采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在电子设备100中，不能和电子设备100分离。

在一些实施例中，处理器110可以调用内部存储器121存储的计算机指令，实现本申请实施例中的文件解析方法。

示例性地，在一些实施例中，处理器110可以调用内部存储器121存储的计算机指令，创建上述分配器进程，上述n个解析器进程以及上述归纳器进程，基于上述分配器进程实现前文图9所示的方法，基于上述解析器进程实现前文图10所示的方法以及基于上述分配器进程实现上述图11所示的方法。

示例性地，在一些实施例中，处理器110可以调用内部存储器121存储的计算机指令，对待解析rc文件进行解析，在待解析rc文件中的section为on section的情况下，创建对应的action类对象；在待解析rc文件中的section为service section的情况下，创建对应的service类对象；在待解析rc文件中的section为import section的情况下，将importsection中的文件路径作为新的待解析的rc文件。

可以理解的是，电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构等。本申请实施例中，电子设备100可以采用如图1所示的分层架构，即电子设备100的分层架构可以包括4层：应用程序层，应用程序框架层，系统运行库层以及内核层。

复用图1，在一些实施例中，图1所示的系统运行库层和内核层之间还可以包括文件解析模块，上述文件解析模块用于实现本申请实施例提供的文件解析方法。

示例性地，上述文件解析模块可以用于创建分配器进程、n个解析器进程以及归纳器进程。其中，分配器进程用于实现图9所示的方法，n个解析器进程中的额任一解析器进程用于实现图10所示的方法，归纳器进程用于实现图11所示的方法。

可选地，上述文件解析模块还可以包括在其他层，比如系统运行库层中，本申请对此不作限定。

本申请还提供一种芯片，该芯片包括逻辑电路和接口，该逻辑电路用于实现上述方法中电子设备的执行的操作和/或处理。

本申请还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机代码，当计算机代码在计算机上运行时，使得计算机执行上述实施例的方法。

本申请还提供一种计算机程序产品，该计算机程序产品包括计算机代码或计算机程序，当该计算机代码或计算机程序在计算机上运行时，使得上述实施例中的方法被执行。

上述实施例中所用，根据上下文，术语“当…时”可以被解释为意思是“如果…”或“在…后”或“响应于确定…”或“响应于检测到…”。类似地，根据上下文，短语“在确定…时”或“如果检测到(所陈述的条件或事件)”可以被解释为意思是“如果确定…”或“响应于确定…”或“在检测到(所陈述的条件或事件)时”或“响应于检测到(所陈述的条件或事件)”。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。上述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行上述计算机程序指令时，全部或部分地产生按照本申请实施例上述的流程或功能。上述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。上述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，上述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。上述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。上述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘)等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以上述权利要求的保护范围为准。

Claims (10)

1.一种文件解析方法，其特征在于，所述方法包括：

创建第一进程以及至少两个第二进程；

从所述第一进程获取待解析文件的文件路径，并分配给所述至少两个第二进程，所述至少两个第二进程对应不同的文件路径；

基于所述文件路径获取所述至少两个第二进程中每个第二进程对应的所述待解析文件；

通过所述第二进程解析对应的所述待解析文件。

2.根据权利要求1所述的方法，其特征在于，所述通过所述第二进程解析对应的所述待解析文件，包括：

在所述待解析文件中的块section为import语句的情况下，通过所述第二进程将所述import语句中的文件路径作为新的待解析文件的文件路径发送给所述第一进程。

3.根据权利要求1所述的方法，其特征在于，所述通过第二进程解析对应的所述待解析文件，包括：

在所述待解析文件中的section为on语句的情况下，通过所述第二进程创建所述on语句对应的action类对象；

在所述待解析文件中的section为service语句的情况下，通过所述第二进程创建所述service语句对应的service类对象；

将所述action类对象或所述service类对象作为所述第二进程的本地数据进行存储。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

创建第三进程；

在所述待解析文件解析完毕后，通过所述第二进程将所述action类对象和/或所述service类对象发送给所述第三进程；

通过所述第三进程将所述action类对象和/或所述service类对象作为全局数据进行存储。

5.根据权利要求1-4中任一项所述的方法，其特征在于，所述方法还包括：

在所述至少两个第二进程全部为空闲状态的情况下，终止所述第一进程，所述至少两个第二进程以及第三进程。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述待解析文件为后缀名为rc的文件。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述文件路径包括所述待解析文件的存储路径、文件名以及后缀名。

8.一种电子设备，其特征在于，包括处理器、存储器，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，使得如权利要求1-7中任一项所述的方法被执行。

9.一种芯片，其特征在于，其特征在于，包括逻辑电路和接口，所述逻辑电路和接口耦合；所述接口用于输入和/或输出代码指令，所述逻辑电路用于执行所述代码指令，以使权利要求1-7中任一项所述的方法被执行。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令被处理器执行时，使得如权利要求1-7中任一项所述的方法被执行。