分析车载应用程序冷启动的方法及装置

技术领域

本申请涉及车载应用程序冷启动分析技术领域，尤其涉及一种分析车载应用程序冷启动的方法及装置。

背景技术

随着汽车智能化的深入推进，车辆上的车载应用程序数量不断增加，以满足车辆和用户的需求。这些车载应用程序可以在车辆的车载操作系统上运行，为用户提供各种各样的功能和体验。然而，开发人员在开发车载应用程序时面临一个挑战，即优化车载应用程序的冷启动过程的耗时。

冷启动是指在车辆启动时，车载应用程序从初始状态开始加载和运行的过程。在冷启动过程中，车载应用程序需要完成各种初始化操作，例如加载资源、建立连接、进行配置等。这些操作可能需要一定的时间，从而导致冷启动过程的耗时延长。为了优化车载应用程序的冷启动过程，开发人员需要了解具体的耗时情况，并制定相应的优化策略。然而，目前的方法无法准确地获取到车载应用程序在冷启动过程中的具体耗时情况。

发明内容

有鉴于此，本申请实施例提供了一种分析车载应用程序冷启动的方法及装置，以解决现有技术中在撤回语音指令时需要用户记得之前语音指令对应的初始状态信息才能撤回不符合自己真正需求的指令的技术问题。

本申请实施例的第一方面，提供了一种分析车载应用程序冷启动的方法，包括：当车载应用程序处于冷启动，通过车载应用程序中的第一代码段记录车载应用程序的启动时间和车载应用程序中各个方法的启动时间，以及通过车载应用程序中的第二代码段记录车载应用程序的结束时间和车载应用程序中各个方法的结束时间，第一代码段部署在车载应用程序的起始位置和各个方法的起始位置，第二代码段部署在车载应用程序的结束位置和各个方法的结束位置；通过运行在车载操作系统的预设脚本，获取车载应该程序的启动时间和各个方法的启动时间、以及车载应用程序的结束时间和各个方法的结束时间，并基于车载应该程序的启动时间、各个方法的启动时间、车载应用程序的结束时间和各个方法的结束时间，生成车载应用程的跟踪文件；对车载应用程的跟踪文件进行解析，以获取车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长；基于车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长，生成车载应用程序冷启动过程的耗时解析图。

本申请实施例的第二方面，提供了一种分析车载应用程序冷启动的装置，包括：记录模块，用于当车载应用程序处于冷启动，通过车载应用程序中的第一代码段记录车载应用程序的启动时间和车载应用程序中各个方法的启动时间，以及通过车载应用程序中的第二代码段记录车载应用程序的结束时间和车载应用程序中各个方法的结束时间，第一代码段部署在车载应用程序的起始位置和各个方法的起始位置，第二代码段部署在车载应用程序的结束位置和各个方法的结束位置；第一生成模块，用于通过运行在车载操作系统的预设脚本，获取车载应该程序的启动时间和各个方法的启动时间、以及车载应用程序的结束时间和各个方法的结束时间，并基于车载应该程序的启动时间、各个方法的启动时间、车载应用程序的结束时间和各个方法的结束时间，生成车载应用程的跟踪文件；解析模块，用于对车载应用程的跟踪文件进行解析，以获取车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长；第二生成模块，用于基于车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长，生成车载应用程序冷启动过程对应的耗时解析图。

本申请实施例的第三方面，提供了一种电子设备，包括存储器、处理器以及存储在所述存储器中并且可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面提供的方法的步骤。

本申请实施例的第四方面，提供了一种计可读存储介质，该可读存储介质存储有计算机程序，计算机程序被处理器执行时实现如上述第一方面提供的方法的步骤。

本申请实施例与现有技术相比存在的有益效果至少包括：本申请实施例通过当车载应用程序处于冷启动，通过在车载应用程序的第一代码段记录车载应用程序的启动时间和各个方法的启动时间，以及通过第二代码段记录车载应用程序的结束时间和各个方法的结束时间，这样可以准确地获取各个方法的执行时间和车载应用程序的执行时间。通过运行预设脚本，可以获取车载应该程序的启动时间和各个方法的启动时间、以及车载应用程序的结束时间和各个方法的结束时间，并基于车载应该程序的启动时间、各个方法的启动时间、车载应用程序的结束时间和各个方法的结束时间生成车载应用程序的跟踪文件，该跟踪文件记录了对车载应用程序执行过程的详细记录。对车载应用程序的跟踪文件进行解析，可以了解冷启动过程中各个方法的执行时间和车载应用程序的执行时间，并确定各个方法的执行时长和车载应用程序冷启动的总时长，然后基于各个方法的执行时长和车载应用程序冷启动的总时长可以生成车载应用程序冷启动过程的耗时解析图。这个图形化表示可以帮助开发人员直观地了解冷启动过程中各个方法的耗时情况，从而确定优化的重点和策略。

附图说明

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

图1是本申请实施例的一种分析车载应用程序冷启动的方法的流程图；

图2是本申请实施例的另一种分析车载应用程序冷启动的方法的流程图；

图3是本申请实施例的编译插桩插件插入代码段的示意图；

图4是本申请实施例的车载应用程序的冷启动过程的耗时解析图；

图5是本申请实施例的一种分析车载应用程序冷启动的装置的框图；

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

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

相关技术中，目前车辆的车载操作系统绝大多数是Android系统，而Android车载应用程序冷启动快慢直接决定了用户对车载操作系统流畅度第一直观体验，车载应用程序冷启动越快，用户越觉得车载操作系统越好，反之觉得车载操作系统卡顿，对此车载操作系统越不好的评价，从而影响汽车品牌。

Android车载应用程序冷启动是指车载操作系统在启动一个应用时，该应用未被创建进程，即车载操作系统中还未存在该进程，例如，以一个HelloWorld应用为例，用户点击车机桌面上的HelloWorld应用图标时，车载操作系统中未存在HelloWorld的进程，此时这个启动过程称之为冷启动过程。

目前，应用开发者往往对其开发的应用，冷启动耗时只有一个主观的体验感知，对具体的启动时间以及在这个启动过程中详细的耗时信息并不了解，从而无法优化冷启动过程，使其启动更快。

针对上述相关技术中面临的技术问题，本申请提供了一种分析车载应用程序冷启动的方法，通过该方法开发人员可以准确地获取车载应用程序冷启动过程的耗时情况，并基于此制定优化策略。通过该方法可以识别出耗时较长的方法，这样后续开发人员可以有针对性地进行优化，例如优化算法、减少资源加载时间或改进启动流程等。这样可以有效地提高车载应用程序的性能和用户体验，减少冷启动过程的耗时。

图1是本申请实施例的一种分析车载应用程序冷启动的方法的流程图，本申请实施例提供的方法可以由任意具备计算机处理能力的电子设备执行，例如安装在车端的车辆设备。

如图1所示，分析车载应用程序冷启动的方法包括步骤S110至步骤S140。

在步骤S110中，当车载应用程序处于冷启动，通过车载应用程序中的第一代码段记录车载应用程序的启动时间和车载应用程序中各个方法的启动时间，以及通过车载应用程序中的第二代码段记录车载应用程序的结束时间和车载应用程序中各个方法的结束时间，第一代码段部署在车载应用程序的起始位置和各个方法的起始位置，第二代码段部署在车载应用程序的结束位置和各个方法的结束位置。

在步骤S120中，通过运行在车载操作系统的预设脚本，获取车载应该程序的启动时间和各个方法的启动时间、以及车载应用程序的结束时间和各个方法的结束时间，并基于车载应该程序的启动时间、各个方法的启动时间、车载应用程序的结束时间和各个方法的结束时间，生成车载应用程的跟踪文件。

在步骤S130中，对车载应用程的跟踪文件进行解析，以获取车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长。

在步骤S140中，基于车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长，生成车载应用程序冷启动过程的耗时解析图。

该方法可以当车载应用程序处于冷启动，通过在车载应用程序的第一代码段记录车载应用程序的启动时间和各个方法的启动时间，以及通过第二代码段记录车载应用程序的结束时间和各个方法的结束时间，这样可以准确地获取各个方法的执行时间和车载应用程序的执行时间。通过运行预设脚本，可以获取车载应该程序的启动时间和各个方法的启动时间、以及车载应用程序的结束时间和各个方法的结束时间，并基于车载应该程序的启动时间、各个方法的启动时间、车载应用程序的结束时间和各个方法的结束时间生成车载应用程序的跟踪文件，该跟踪文件记录了对车载应用程序执行过程的详细记录。对车载应用程序的跟踪文件进行解析，可以了解冷启动过程中各个方法的执行时间和车载应用程序的执行时间，并确定各个方法的执行时长和车载应用程序冷启动的总时长，然后基于各个方法的执行时长和车载应用程序冷启动的总时长可以生成车载应用程序冷启动过程的耗时解析图。这个图形化表示可以帮助开发人员直观地了解冷启动过程中各个方法的耗时情况，从而确定优化的重点和策略。

在一些实施例中，车载应用程序处于冷启动状态指的是车辆启动或重新启动后，车载应用程序需要从初始状态开始加载和运行的过程。在冷启动期间，车载应用程序需要进行一系列初始化操作，以准备好提供功能和服务给用户使用。冷启动过程可以包括以下步骤：启动车载操作系统：当车辆启动时，车载操作系统开始启动。这包括加载操作系统内核、初始化系统资源和配置等操作。启动过程可能需要一定时间，具体耗时取决于车载操作系统的复杂性和硬件性能。载入应用程序：当车载操作系统启动完成，它会开始加载车载应用程序，并创建对应的进程，在创建进行之后，将应用程序的代码和资源从存储设备读取到内存中，并进行必要的解析和初始化。车载应用程序的大小和复杂性会对加载时间产生影响。初始化应用程序：在车载应用程序加载完成后，车载应用程序需要进行初始化操作。这可能包括建立与车辆系统的连接、加载配置文件、检查和更新数据等。初始化过程可以根据车载应用程序的功能和需求而有所不同。启动界面和功能：当车载应用程序完成初始化，它会开始启动界面和功能。这可能包括显示主界面、加载数据、连接外部设备等。车载应用程序的功能和界面数量会影响启动时间。在整个冷启动过程中，车载应用程序需要完成各种操作，包括资源加载、连接建立、配置读取、数据检查等。这些操作可能需要一定的时间，导致冷启动过程的耗时延长。因此，为了提高冷启动的性能和用户体验，开发人员需要优化这些耗时操作，并确保冷启动过程尽可能地快速完成。在本实施例中，上述车载操作系统可以是安卓系统(即Android系统)。

需要说明的是，冷启动只发生在车辆启动或重新启动时。在车辆的运行过程中，如果应用程序已经加载和运行，后续的启动将属于热启动，通常会比冷启动快速完成，因为不需要进行完整的初始化过程，而是从上次的状态继续运行。

在一些实施例中，通过车载应用程序中的第一代码段记录车载应用程序的启动时间和车载应用程序中各个方法的启动时间包括：当车载应用程序开始执行时，执行第一代码段，以获取车载操作系统的当前时间，并将车载操作系统的当前时间确定为车载应用程序的启动时间；当车载应用程序中各个方法开始执行时，执行第一代码段，以获取车载操作系统的当前时间，并将车载操作系统的当前时间确定为各个方法的启动时间；通过车载应用程序中的第二代码段记录车载应用程序中各个方法的结束时间包括：当车载应用程序结束执行时，执行第二代码段，以获取车载操作系统的当前时间，并将车载操作系统的当前时间确定为车载应用程序的结束时间；当车载应用程序中各个方法结束执行时，执行第二代码段，以获取车载操作系统的当前时间，并将车载操作系统的当前时间确定为各个方法的结束时间。

基于前述实施例，在车载应用程序处于冷启动中，为了获取各个方法的启动时间和结束时间、以及车载应用程序的启动时间和结束时间，可以使用第一代码段和第二代码段的方法。下面是对这些代码段的详细描述：第一代码段(Trace.beginSection)：当车载应用程序开始执行时，执行第一代码段来获取车载操作系统的当前时间，并将该时间确定为车载应用程序的启动时间，当车载应用程序中的各个方法开始执行时，执行第一代码段来获取车载操作系统的当前时间，并将该时间确定为各个方法的启动时间。该代码段通常可以被部署在车载应用程序的起始位置和各个方法的起始位置。第二代码段(Trace.endSection)：当车载应用程序开始执行时，执行第二代码段来获取车载操作系统的当前时间，并将该时间确定为车载应用程序的结束时间，当车载应用程序中的各个方法结束执行时，执行第二代码段来获取车载操作系统的当前时间，并将该时间确定为各个方法的结束时间。该代码段通常会被部署在车载应用程序的结束位置和各个方法的结束位置。例如，假设车载应用程序中包含多个类，每个类中包含至少一个方法。在这种情况下，开发人员可以选择在每个类中的至少一个方法的起始位置部署第一代码段(Trace.beginSection)，并在相应方法的结束位置部署第二代码段(Trace.endSection)。当方法开始执行时，第一代码段会记录车载操作系统的当前时间，并将其确定为方法的启动时间。这个时间戳可以用来表示方法的开始时间点。当方法结束执行时，第二代码段会记录车载操作系统的当前时间，并将其确定为方法的结束时间。这个时间戳可以用来表示方法的结束时间点。通过在各个方法的起始位置和结束位置部署这些代码段，开发人员可以获取每个方法的执行时间。这样可以获得车载应用程序中各个方法执行过程的时长，并进一步进行性能分析和优化。

在一些实施例中，通过运行在车载操作系统的预设脚本，获取车载应该程序的启动时间和各个方法的启动时间、以及车载应用程序的结束时间和各个方法的结束时间包括：当车载操作系统启动后，根据预设存储路径从车端本地获取预设脚本和配置文件；启动预设脚本，通过预设脚本根据配置文件，获取车载应该程序的启动时间和各个方法的启动时间、以及车载应用程序的结束时间和各个方法的结束时间。

基于前述实施例，上述预设脚本是一个事先编写好的脚本，用于根据配置文件获取车载应用程序的启动时间和结束时间、以及方法的启动时间和结束时间。配置文件包含了预设脚本和车载应用程序之间的设置和参数信息。例如，在车载操作系统启动之后，触发获取预设脚本和配置文本的操作，以将该预设脚本运行在车载操作系统。例如，根据预设存储路径从车端本地获取预设脚本和配置文件。这些文件事先存储在车辆的本地存储设备中，例如闪存或硬盘。当预设脚本和配置文件被获取，预设脚本可以根据配置文件中的设置，执行相应的操作来获取车载应用程序的启动时间和结束时间、以及各个方法的启动时间和结束时间。例如，预设脚本根据配置文件中的设置，执行一系列操作来获取车载应用程序的启动时间和结束时间、以及各个方法的启动时间和结束时间。在本实施例中，可以使用Perfetto性能工具来设置预设脚本和配置文件。Perfetto是一个开源的性能跟踪工具，可以用于收集和分析车载应用程序的性能数据和车载操作系统及车端的性能数据。通过设置Perfetto的预设脚本和配置文件，可以定制性能跟踪的行为，包括获取车载应用程序的启动时间和结束时间、以及各个方法的启动时间和结束时间。配置文件(例如，config.pbtx)可以根据Perfetto性能工具和车载应用程序的需求进行设置。它可以包含一些参数和选项，用于指定性能跟踪的目标、采样率、跟踪的方法等。配置文件可以与预设脚本进行配合，从而实现获取各个方法的启动时间和结束时间的功能。

在一些实施例中，车载应用程序中包含多个类，各个类中包含至少一个方法；基于车载应该程序的启动时间、各个方法的启动时间、车载应用程序的结束时间和各个方法的结束时间，生成车载应用程的跟踪文件包括：针对一个类，根据该类中至少一个方法的执行顺序和该类中至少一个方法的启动时间和结束时间，确定该类对应的记录条目；根据车载应该程序的启动时间和车载应用程序的结束时间，确定车载应该程序对应的记录条目；根据车载应该程序对应的记录条目、各个类对应的记录条目、以及预设格式，生成车载应用程的跟踪文件。

基于前述实施例，根据车载应该程序的启动时间和车载应用程序的结束时间，确定车载应该程序对应的记录条目。例如，该记录条目可以是一个数据结构，用于存储该车载应该程序的名称、启动时间、结束时间。

对于一个类，可以根据该类中至少一个方法的执行顺序和启动时间、结束时间来确定该类对应的记录条目。记录条目可以是一个数据结构，用于存储该类的相关信息，如类名、方法名、启动时间、结束时间、方法执行顺序等。根据确定的记录条目的结构，可以创建一个或多个记录条目，用于存储每个类的信息。每个记录条目对应一个类，并包含该类的相关信息。将所有类的记录条目组织起来，形成一个记录集合。这个集合可以是一个数据结构，如数组、列表或映射等，用于存储所有类的记录条目。根据预设的格式要求，定义跟踪文件的结构和内容。这个格式可以包括字段名称、数据类型、顺序等。预设格式用于规定记录条目在跟踪文件中的排列方式和数据表示方式。

根据车载应该程序对应的记录条目、各个类对应的记录条目、以及预设格式，生成车载应用程的跟踪文件。例如，按照预设格式的要求，将记录条目中的数据按照指定的顺序和格式写入跟踪文件中。生成的跟踪文件可以是文本文件、二进制文件或其他格式，用于存储车载应用程序的跟踪数据。这个文件可以包含多个记录条目，除车载应用程序的记录条目之前的每个记录条目对应一个类，并记录了该类的相关信息，如方法的执行顺序、启动时间和结束时间、方法执行顺序等。通过生成跟踪文件，开发人员可以获取车载应用程序的执行信息，包括各个类的方法执行顺序和时间信息。这对于性能分析、问题排查和优化非常有帮助。跟踪文件可以被进一步分析和可视化，以便开发人员更好地理解应用程序的行为和性能特征。

例如，车载应用程序为HelloWorld，基于上述方法通过Perfetto根据config.pbtx来生成Trace文件(即跟踪文件)，当用户在车端屏幕上点击HelloWorld对应的图标时，通过预先运行在车载操作系统Perfetto根据config.pbtx抓取的是HelloWorld冷启动过程中的耗时以及这个过程中相关方法的耗时，并基于生成HelloWorld冷启动过程中的耗时以及这个过程中相关方法的耗时生成trace.perfetto-trace文件(即Trace文件)，并将其保存在车端本地。

在一些实施例中，对车载应用程的跟踪文件进行解析，以获取车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长包括：获取预设格式对应的解析规则，并通过解析规则从车载应用程的跟踪文件中获取各个类中至少一个方法的启动时间和结束时间；通过解析规则从车载应用程的跟踪文件中获取车载应用的启动时间和车载应用的结束时间；根据各个类中至少一个方法的启动时间和结束时间，确定各个类中至少一个方法执行过程的时长，以及根据车载应用的启动时间和车载应用的结束时间，确定车载应用程序冷启动的总时长。

基于前述实施例，上述预设格式定义了跟踪文件的结构和内容，解析规则用于解析跟踪文件并提取所需的信息。解析规则可以是一组规则或算法，用于识别和提取跟踪文件中的各个字段和数据。根据预设格式的解析规则，对车载应用程序的跟踪文件进行解析。例如，解析过程涉及读取跟踪文件的内容，并根据解析规则提取各个字段和数据。根据解析规则，从跟踪文件中获取各个类中至少一个方法的启动时间和结束时间、以及获取车载应用的启动时间和车载应用的结束时间。这些时间信息通常是在记录条目中的特定字段或数据项中存储的，例如，根据各个类中至少一个方法的启动时间和结束时间，可以计算方法执行过程的时长。时长可以通过计算结束时间减去启动时间来获得。根据车载应用的启动时间和车载应用的结束时间，可以计算车载应用程序冷启动的总时长。时长可以通过计算结束时间减去启动时间来获得。通过以上步骤，可以计算方法执行过程的时长和车载应用程序冷启动的总时长。这些信息对于性能分析和优化非常有用，可以帮助开发人员了解方法的执行时间、识别性能瓶颈，并采取相应的优化措施。

需要说明的是，解析规则的设计和实现需要根据具体的预设格式和跟踪文件的结构来进行。不同的预设格式和跟踪文件可能需要不同的解析规则。因此，在实际应用中，开发人员需要根据具体情况进行解析规则的开发和调整，以确保正确地提取所需的信息。

在一些实施例中，基于车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长，生成车载应用程序冷启动过程对应的耗时解析图包括：确定各个类的位置分布情况和各个类中至少一个方法的位置分布情况；基于各个类的位置分布情况、各个类中至少一个方法的位置分布情况、各个类中至少一个方法执行过程的时长、以及所述车载应用程序冷启动的总时长，生成所述车载应用程序冷启动过程对应的耗时解析图。在本实施例中，确定各个类的位置分布情况和各个类中至少一个方法的位置分布情况具体可以包括从车载应用程序的配置文件中获取各个类之间的关系和各个类中至少一个方法之间的关系，然后根据车载应用程序中各个类之间的关系和各个类中至少一个方法之间的关系，确定各个类的位置分布情况和各个类中至少一个方法的位置分布情况。

基于前述实施例，分析车载应用程序中各个类之间的依赖关系和调用关系。这可以通过查看类之间的引用关系、继承关系、接口实现关系等来确定。根据类之间的关系，确定各个类在车载应用程序中的位置分布情况。这包括确定类所属的模块、包或命名空间等。类的位置分布情况可以帮助开发人员更好地理解应用程序的结构和组织方式。在每个类中，根据各个方法之间的调用关系，确定各个方法在类中的位置分布情况。这可以包括方法的调用顺序、调用关系图等。方法的位置分布情况可以帮助开发人员了解方法之间的调用流程和依赖关系。根据之前提到的方法执行过程的时长计算方法的耗时。这些时长可以与方法的位置分布情况结合起来，以形成耗时解析图的数据。基于各个类的位置分布情况、各个类中至少一个方法的位置分布情况、各个类中至少一个方法执行过程的时长以及车载应用程序冷启动的总时长，可以开始生成车载应用程序冷启动过程对应的耗时解析图。例如，在耗时解析图中，每个类或方法在图中占据一定的区域，通过区域的长度或颜色来表示耗时。

通过耗时解析图，开发人员可以直观地了解车载应用程序冷启动过程中各个类和方法的耗时情况，识别潜在的性能瓶颈和优化机会。这有助于开发人员针对性地进行性能优化，提高冷启动过程的效率。

下面以车载应用程序为HelloWorld为例，HelloWorld中包含多个类，例如，Application和MainActivity。Application中包含多个方法，例如，bindApplication、application_startup_cost、application_onGreate、applicationfunA、applicationfunB，MainActivity中包含多个方法，例如，MainActivity_onCreate、MainActivity_onResume、MainActivity_funA、MainActivity_funB。

参考图4，图4示出了HelloWorld冷启动过程对应的耗时解析图，该耗时解析图记载了HelloWorld中各个方法执行过程的时长和HelloWorld冷启动的总时长。在该耗时解析图中，从左到右的方向可以是各个方法的执行顺序。从上到下方向可以是各个方法之间的调用关系。开发人员可以从该耗时解析图中很容易看到HelloWorld冷启动总耗时为1890ms,其中bindApplication为系统给HelloWorld创建进程耗费了400ms时间，创建进程后，应用从Application.attachBaseContext到MainActivity.onWindowFocusChanged这段时间耗费了1400ms，其下边表明了这段时间内Application和MainActivity中加了自定义标记的方法耗时，可以看到HelloWorld冷启动过程中最耗时的方法是在MainActivity中的funB方法，其耗时为570ms，开发人员可以查看funB方法逻辑，这样可以有针对性的优化代码，加快应用冷启动。

通过上述耗时解析图，可以开发人员很清楚知道自己开发的车载应用程序在在车载操作系统上的真实启动耗时以及各方法的耗时情况，让开发人员可以快速定位代码问题，从而加快应用冷启动，使得用户对车载操作系统的感知更流畅，间接影响了汽车的品牌认可度。

图2是本申请实施例的另一种分析车载应用程序冷启动的方法的流程图。

如图2所示，在车载应用程序处于冷启动之前，上述分析车载应用程序冷启动的方法还包括步骤S210和步骤S220。

在步骤S210中，获取车载应用程序的配置文件，通过编译插桩插件识别配置文件，以从配置文件中获取车载应用程序的各个类中至少一个方法。

在步骤S220中，在各个类中至少一个方法的起始位置插入第一代码段，在各个类中至少一个方法的结束位置插入第二代码段，以及在车载应用程序的起始位置插入第一代码段，在车载应用程序的结束位置插入第二代码段。

该方法可以获取车载应用程序的配置文件，通过编译插桩插件识别配置文件，以从配置文件中获取车载应用程序的各个类中至少一个方法，并在各个类中至少一个方法的起始位置插入第一代码段，在各个类中至少一个方法的结束位置插入第二代码段，以及在车载应用程序的起始位置插入第一代码段，在车载应用程序的结束位置插入第二代码段，以此方式可以快速准确的在各个方法相应的位置和车载应用程序的相应位置插入对应代码段，以使得后续在车载应用程序处于冷启动时，可以通过不同的代码段记录各个方法启动时间和结束时间，以及记录车载应用程序的开启时间和结束时间。

以车载应用程序为HelloWorld，其应用包名为com.example.hellowrold(在安卓系统中，应用包名是唯一标识)，HelloWorld在其build.gradle(编译脚本)中配置该车载应用程序的编译插桩插件，配置好后，在HelloWorld的应用编译构建成HelloWorld.apk的过程中，编译插桩插件可以使用Hook系统的编译流程，自动为HelloWorld中的各个方法的起始位置插入第一代码段(例如，Trace.beginSection)，在各个方法的结束位置插入第二代码段(例如，Trace.endSection)，以及自动在“applicaton_startup_cost”的起始位置插入第一代码段(例如，Trace.beginSection)，标记车载应用程序的开始，在MainActivity.onWindowFocusChanged的结束位置插入第二代码段(例如，Trace.endSection)，标记车载应用程序的结束。

参考图3，HelloWorld源码编译成apk的过程分别是Java源码编译成Class字节码，Class字节码编译成Dex，在Class到Dex的过程中可以通过编译插桩插件将相关代码插入各个方法的对应位置。例如，通过Hook系统的transformClass task，并根据HelloWorld中的Manifest.xml配置文件找到各个类中至少一个方法的起始位置和结束位置，并在其中插入自定义标记的相关代码，例如，Trace.beginSection和Trace.endSection。

例如，通过编译插桩插件在HelloWorld中的Application与MainActivity的方法插入Trace.beginSection和Trace.endSection。具体地，通过Hook系统的transformClasstask，并根据HelloWorld中的Manifest.xml配置文件找到各个类，例如，Application与MainActivity。

在Application的attachBaseContext中插入自定义信息用于标记冷启动整个过程：

attachBaseContext(Contextbase){Trace.beginSection(application_startup_cost)；}

在MainActivity中的onWindowFocusChanged函数中插入结束标志voidonWindowFocusChanged(){Trace.endSection()；}

在Application、MainActivity中的各函数插入与函数名相关的Trace信息，在函数的开始处插入Trace.begin()，在函数结束处插入Trace.end()，以MainActivity中funA为例，如下：

void funA(){Trace.beginSection(MainActivity_funA)://中间部分为HelloWorld的业务代码……Trace.endSection()；}。

图5是本申请实施例的一种分析车载应用程序冷启动的装置的框图。

如图5所示，分析车载应用程序冷启动的装置500包括记录模块510、第一生成模块520、解析模块530和第二生成模块540。

具体地，记录模块510，用于当车载应用程序处于冷启动，通过车载应用程序中的第一代码段记录车载应用程序的启动时间和车载应用程序中各个方法的启动时间，以及通过车载应用程序中的第二代码段记录车载应用程序的结束时间和车载应用程序中各个方法的结束时间，第一代码段部署车载应用程序的起始位置和在各个方法的起始位置，第二代码段部署在车载应用程序的结束位置和各个方法的结束位置。

第一生成模块520，用于通过运行在车载操作系统的预设脚本，获取车载应该程序的启动时间和各个方法的启动时间、以及所述车载应用程序的结束时间和各个方法的结束时间，并基于所述车载应该程序的启动时间、各个方法的启动时间、所述车载应用程序的结束时间和各个方法的结束时间，生成所述车载应用程的跟踪文件。

解析模块530，用于对车载应用程的跟踪文件进行解析，以获取车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长。

第二生成模块540，用于基于车载应用程序中各个方法执行过程的时长和车载应用程序冷启动的总时长，生成车载应用程序冷启动过程的耗时解析图。

该分析车载应用程序冷启动的装置500可以当车载应用程序处于冷启动，通过在车载应用程序的第一代码段记录车载应用程序的启动时间和各个方法的启动时间，以及通过第二代码段记录车载应用程序的结束时间和各个方法的结束时间，这样可以准确地获取各个方法的执行时间和车载应用程序的执行时间。通过运行预设脚本，可以获取车载应该程序的启动时间和各个方法的启动时间、以及车载应用程序的结束时间和各个方法的结束时间，并基于车载应该程序的启动时间、各个方法的启动时间、车载应用程序的结束时间和各个方法的结束时间生成车载应用程序的跟踪文件，该跟踪文件记录了对车载应用程序执行过程的详细记录。对车载应用程序的跟踪文件进行解析，可以了解冷启动过程中各个方法的执行时间和车载应用程序的执行时间，并确定各个方法的执行时长和车载应用程序冷启动的总时长，然后基于各个方法的执行时长和车载应用程序冷启动的总时长可以生成车载应用程序冷启动过程的耗时解析图。这个图形化表示可以帮助开发人员直观地了解冷启动过程中各个方法的耗时情况，从而确定优化的重点和策略。

在一些实施例中，上述记录模块510被配置为：当车载应用程序开始执行时，执行第一代码段，以获取车载操作系统的当前时间，并将车载操作系统的当前时间确定为车载应用程序的启动时间；当车载应用程序中各个方法开始执行时，执行第一代码段，以获取车载操作系统的当前时间，并将车载操作系统的当前时间确定为各个方法的启动时间；当车载应用程序结束执行时，执行第二代码段，以获取车载操作系统的当前时间，并将车载操作系统的当前时间确定为车载应用程序的结束时间；当车载应用程序中各个方法结束执行时，执行第二代码段，以获取车载操作系统的当前时间，并将车载操作系统的当前时间确定为各个方法的结束时间。

在一些实施例中，上述第一生成模块520被配置为：当车载操作系统启动后，根据预设存储路径从车端本地获取预设脚本和配置文件；启动预设脚本，通过预设脚本根据配置文件，获取车载应该程序的启动时间和各个方法的启动时间、以及车载应用程序的结束时间和各个方法的结束时间。

在一些实施例中，车载应用程序中包含多个类，各个类中包含至少一个方法；上述第一生成模块520被配置为：针对一个类，根据该类中至少一个方法的执行顺序和该类中至少一个方法的启动时间和结束时间，确定该类对应的记录条目；根据车载应该程序的启动时间和车载应用程序的结束时间，确定车载应该程序对应的记录条目；根据车载应该程序对应的记录条目、各个类对应的记录条目、以及预设格式，生成车载应用程的跟踪文件。

在一些实施例中，上述解析模块530被配置为：获取预设格式对应的解析规则，并通过解析规则从车载应用程的跟踪文件中获取各个类中至少一个方法的启动时间和结束时间；通过解析规则从车载应用程的跟踪文件中获取车载应用的启动时间和车载应用的结束时间；根据各个类中至少一个方法的启动时间和结束时间，确定各个类中至少一个方法执行过程的时长，以及根据车载应用的启动时间和车载应用的结束时间，确定车载应用程序冷启动的总时长。

在一些实施例中，上述第二生成模块540被配置为：确定各个类的位置分布情况和各个类中至少一个方法的位置分布情况；基于各个类的位置分布情况、各个类中至少一个方法的位置分布情况、各个类中至少一个方法执行过程的时长、以及所述车载应用程序冷启动的总时长，生成所述车载应用程序冷启动过程对应的耗时解析图。

在一些实施例中，确定各个类的位置分布情况和各个类中至少一个方法的位置分布情况包括：从车载应用程序的配置文件中获取各个类之间的关系和各个类中至少一个方法之间的关系；根据车载应用程序中各个类之间的关系确定各个类的位置分布情况，以及根据各个类中至少一个方法之间的关系，确定各个类中至少一个方法的位置分布情况。

在一些实施例中，上述分析车载应用程序冷启动的装置500还用于：获取车载应用程序的配置文件，通过编译插桩插件识别配置文件，以从配置文件中获取车载应用程序的各个类中至少一个方法；在各个类中至少一个方法的起始位置插入第一代码段，以及在各个类中至少一个方法的结束位置插入第二代码段，以及在车载应用程序的起始位置插入所述第一代码段，在车载应用程序的结束位置插入所述第二代码段。

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

如图6所示，该实施例的电子设备600包括：处理器610、存储器620以及存储在该存储器620中并且可在处理器610上运行的计算机程序630。处理器610执行计算机程序630时实现上述各个方法实施例中的步骤。或者，处理器610执行计算机程序630时实现上述各装置实施例中各模块的功能。

电子设备600可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备600可以包括但不仅限于处理器610和存储器620。本领域技术人员可以理解，图6仅仅是电子设备600的示例，并不构成对电子设备600的限定，可以包括比图示更多或更少的部件，或者不同的部件。

处理器610可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

存储器620可以是电子设备600的内部存储单元，例如，电子设备600的硬盘或内存。存储器620也可以是电子设备600的外部存储设备，例如，电子设备600上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。存储器620还可以既包括电子设备600的内部存储单元也包括外部存储设备。存储器620用于存储计算机程序以及电子设备所需的其它程序和数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读存储介质(例如，计算机可读存储介质)中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random AccessMemory，RAM)、电载波信号、电信信号以及软件分发介质等。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。