应用程序的处理方法、装置和电子设备与流程

1.本公开涉及互联网技术领域，尤其涉及一种应用程序的处理方法、装置和电子设备。


背景技术：

2.在安卓系统上的软件应用开发、运行以及升级过程中，随着业务的不断拓展和更新，开发人员可编写业务对应的新增代码，且对业务对应的新增代码进行优化。
3.但是，随着业务对应的新增代码的合入，应用程序的目标路径(如启动路径)可能出现劣化现象，严重时甚至导致开发人员的优化工作全部白费。因此，防止应用程序劣化的处理方法至关重要。
4.目前，现有的防止应用程序劣化的处理方法包括如下两种：
5.一、在发版之前，线下比对应用程序的合入版本和未合入版本，测试这两个版本中是否有指标出现劣化。然而，这种方法由于在发版之前，即使合入版本出现劣化，也无法及时拦截，只能依赖后续版本的修复。
6.二、在发版之后，线上观察用程序的合入版本，确定该版本中是否有指标出现劣化。在合入版本出现劣化后，定位劣化位置并分析劣化原因。然而，这种方法的处理效率低，且定位后的修复周期长。


技术实现要素：

7.为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种应用程序的处理方法、装置和电子设备。
8.第一方面，本公开提供了一种应用程序的处理方法，包括：
9.接收应用程序的合入代码；
10.确定合入代码中的修改部分中的代码是否涉及应用程序的目标路径；
11.确定修改部分中的代码是否存在耗时操作；
12.在修改部分中的代码涉及目标路径且存在耗时操作时，输出分析结果，分析结果包括合入代码中包括涉及目标路径且存在耗时操作的目标代码以及对应代码的目标位置。
13.通过第一方面提供的方法，在应用程序的合入代码提交后，对合入代码中的改动部分进行检测分析，一是分析改动部分中的代码是否涉及目标路径；二是分析改动部分中的代码是否存在耗时操作。在改动部分中的代码涉及目标路径且存在耗时操作的情况下，可向代码评审人员通知分析结果，分析结果中包括合入代码中包括涉及目标路径且存在耗时操作的目标代码以及目标代码的位置，使得代码评审人员可与开发人员进行代码评审，以便在代码评审成功后对合入代码进行合入仓库操作，或者，使得代码评审人员可对合入代码进行阻止合入仓库操作。由此，能够更早的发现合入代码是否会导致应用程序在目标路径劣化，以便有充足的时间去修复合入代码，提升了应用程序防劣化的处理效率，缩短了应用程序的修复周期。在一种可能的设计中，确定修改部分中的代码是否存在耗时操作，包
括：若确定修改部分中的代码涉及目标路径后，则确定修改部分中的涉及目标路径的代码是否存在耗时操作。
14.在一种可能的设计中，确定合入代码中的修改部分中的代码是否涉及应用程序的目标路径，包括：获取目标文件，目标文件中记录有应用程序的全部代码中的涉及目标路径的全部函数；基于目标文件，确定修改部分中的代码是否涉及目标路径。
15.在一种可能的设计中，基于目标文件，确定修改部分中的代码是否涉及目标路径，包括：在修改部分中的代码包含在目标文件记录的函数中时，确定修改部分中的代码涉及目标路径；在修改部分中的代码不包含在目标文件记录的函数中时，确定修改部分中的代码不涉及目标路径。
16.在一种可能的设计中，获取目标文件，包括：获取第一文件，并基于第一文件确定应用程序的全部代码中的在目标路径中被调用的第一函数集合；获取第二文件，并基于第二文件确定应用程序的全部代码中的在目标路径的根函数中被调用的第二函数集合；将第一函数集合和第二函数集合的并集确定为目标文件。
17.在一种可能的设计中，该方法还包括：确定第一文件。确定第一文件，包括：在应用程序的编译阶段中，配置目标路径的起始函数和终止函数；对应用程序的全部代码进行插桩处理；基于插桩处理，在应用程序的运行阶段中，将起始函数和终止函数之间的被调用的函数记录在第一文件中；保存第一文件。
18.在一种可能的设计中，该方法还包括：确定第二文件。确定第二文件，包括：确定目标路径的根函数；将应用程序的全部代码编译成第一字节码；对第一字节码进行静态分析，获取根函数直接和间接调用的子函数，并将根函数及子函数记录在第二文件中；保存第二文件。
19.在一种可能的设计中，确定修改部分中的代码是否存在耗时操作，包括：在应用程序的编译阶段中，将修改部分编译成第二字节码；针对第二字节码中对应的每个函数而言，确定每个函数的类型是否在预设列表的类型范围内，预设列表中记录有耗时函数的类型；在第二字节码中对应的一个函数的类型在预设列表的类型范围内时，确定一个函数对应于修改部分中的代码存在耗时操作；在第二字节码中对应的一个函数类型不在预设列表的类型范围内时，确定一个函数对应于修改部分中的代码不存在耗时操作。
20.在一种可能的设计中，在第二字节码中对应的一个函数存在调用了的外部函数，且第二字节码中对应的全部函数不包括一个函数调用了的外部函数时，该方法还包括：确定一个函数调用了的外部函数的类型是否在预设列表的类型范围内；在一个函数调用了的外部函数在预设列表的类型范围内时，确定一个函数存在耗时操作；在一个函数调用了的外部函数不在预设列表的类型范围内时，确定一个函数不存在耗时操作。
21.在一种可能的设计中，当确定第二字节码中对应的一个函数存在耗时操作且涉及目标路径时，将一个函数确定为目标代码，将一个函数的位置确定为目标代码的位置，并将目标代码及目标代码的位置保存至分析结果中。
22.在一种可能的设计中，预设列表中的耗时函数的类型包括：加锁函数、json解析函数、读写i/o函数以及系统耗时函数。
23.在一种可能的设计中，目标路径为应用程序的启动路径中的主进程的主线程。
24.第二方面，本公开提供了一种应用程序的处理装置，包括：
25.接收模块，用于接收应用程序的合入代码；
26.确定模块，用于确定合入代码中的修改部分中的代码是否涉及应用程序的目标路径；
27.确定模块，还用于确定修改部分中的代码是否存在耗时操作；
28.输出模块，用于在修改部分中的代码涉及目标路径且存在耗时操作时，输出分析结果，分析结果包括合入代码中包括涉及目标路径且存在耗时操作的目标代码以及目标代码的位置。
29.在一种可能的设计中，确定模块，具体用于在确定修改部分中的代码涉及目标路径后，确定修改部分中的涉及目标路径的代码是否存在耗时操作。
30.在一种可能的设计中，确定模块，具体用于获取目标文件，目标文件中记录有应用程序的全部代码中的涉及目标路径的全部函数；基于目标文件，确定修改部分中的代码是否涉及目标路径。
31.在一种可能的设计中，确定模块，用于在修改部分中的代码包含在目标文件记录的函数中时，确定修改部分中的代码涉及目标路径；在修改部分中的代码不包含在目标文件记录的函数中时，确定修改部分中的代码不涉及目标路径。
32.在一种可能的设计中，确定模块，用于获取第一文件，并基于第一文件确定应用程序的全部代码中的在目标路径中被调用的第一函数集合；获取第二文件，并基于第二文件确定应用程序的全部代码中的在目标路径的根函数中被调用的第二函数集合；将第一函数集合和第二函数集合的并集确定为目标文件。
33.在一种可能的设计中，确定模块，还用于确定第一文件。确定模块，具体用于在应用程序的编译阶段中，配置目标路径的起始函数和终止函数；对应用程序的全部代码进行插桩处理；基于插桩处理，在应用程序的运行阶段中，将起始函数和终止函数之间的被调用的函数记录在第一文件中；保存第一文件。
34.在一种可能的设计中，确定模块，还用于确定第二文件。确定模块，具体用于确定目标路径的根函数；将应用程序的全部代码编译成第一字节码；对第一字节码进行静态分析，获取根函数直接和间接调用的子函数，并将根函数及子函数记录在第二文件中；保存第二文件。
35.在一种可能的设计中，确定模块，还具体用于在应用程序的编译阶段中，将修改部分编译成第二字节码；针对第二字节码中对应的每个函数而言，确定每个函数的类型是否在预设列表的类型范围内，预设列表中记录有耗时函数的类型；在第二字节码中对应的一个函数的类型在预设列表的类型范围内时，确定一个函数对应于修改部分中的代码存在耗时操作；在第二字节码中对应的一个函数类型不在预设列表的类型范围内时，确定一个函数对应于修改部分中的代码不存在耗时操作。
36.在一种可能的设计中，确定模块，还用于在第二字节码中对应的一个函数存在调用了的外部函数，且第二字节码中对应的全部函数不包括一个函数调用了的外部函数时，确定一个函数调用了的外部函数的类型是否在预设列表的类型范围内；在一个函数调用了的外部函数在预设列表的类型范围内时，确定一个函数存在耗时操作；在一个函数调用了的外部函数不在预设列表的类型范围内时，确定一个函数不存在耗时操作。
37.在一种可能的设计中，当确定第二字节码中对应的一个函数存在耗时操作且涉及
目标路径时，将一个函数确定为目标代码，将一个函数的位置确定为目标代码的位置，并将目标代码及目标代码的位置保存至分析结果中。
38.在一种可能的设计中，预设列表中的耗时函数的类型包括：有锁函数、json解析函数、读写i/o函数以及系统耗时函数。
39.在一种可能的设计中，目标路径为应用程序的启动路径中的主进程的主线程。
40.上述第二方面以及上述第二方面的各可能的设计中所提供的应用程序的处理装置，其有益效果可以参见上述第一方面和第一方面的各可能的实施方式所带来的有益效果，在此不再赘述。
41.第三方面，本公开提供了一种电子设备，包括：存储器和处理器；存储器用于存储程序指令；处理器用于调用存储器中的程序指令使得电子设备执行第一方面及第一方面任一种可能的设计中的应用程序的处理方法。
42.第四方面，本公开提供了一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行第一方面及第一方面任一种可能的设计中的应用程序的处理方法。
43.第五方面，本公开提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行第一方面及第一方面任一种可能的设计中的应用程序的处理方法。
附图说明
44.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
45.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
46.图1为本公开实施例提供的应用程序的处理方法的流程示意图；
47.图2为本公开实施例提供的应用程序的处理方法的流程示意图；
48.图3为本公开实施例提供的应用程序的处理方法的流程示意图；
49.图4为本公开实施例提供的应用程序的处理方法的工作流程图；
50.图5为本公开实施例提供的应用程序的处理装置的工作流程图；
51.图6为本公开实施例提供的应用程序的处理方法的流程示意图；
52.图7为本公开实施例提供的应用程序的处理装置的结构示意图。
具体实施方式
53.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
54.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
55.示例性地，本公开提供一种应用程序的处理方法、装置、设备、计算机存储介质以
及计算机程序产品，通过在应用程序的合入代码提交后，对合入代码中的改动部分进行检测分析，一是分析改动部分中的代码是否涉及目标路径；二是分析改动部分中的代码是否存在耗时操作。由此，向代码评审(code review)人员通知分析结果，以便代码评审人员基于分析结果确定出对合入代码进行后续操作。在改动部分中的代码涉及目标路径且存在耗时操作的情况下，可向代码评审人员通知分析结果，分析结果中包括合入代码中包括涉及目标路径且存在耗时操作的目标代码以及目标代码的位置，使得代码评审人员可与开发人员进行代码评审，以便在代码评审成功后对合入代码进行合入仓库操作，或者，使得代码评审人员可对合入代码进行阻止合入仓库操作。由此，能够更早地发现合入代码是否会导致应用程序在目标路径劣化，以便有充足的时间去修复合入代码，提升了应用程序防劣化的处理效率，缩短了应用程序的修复周期。
56.其中，本公开的应用程序的处理方法由代码管理平台来执行。代码管理平台可以为服务器、终端设备或终端设备中的应用程序(application，app)、网页、公众号等等，本公开对代码管理平台的具体类型不作任何限制。
57.基于前述描述，本公开以实施例将以代码管理平台为例，结合附图和应用场景，对本公开提供的应用程序的处理方法进行详细阐述。
58.请参阅图1，图1为本公开实施例提供的应用程序的处理方法的流程示意图。如图1所示，本公开提供的应用程序的处理方法可以包括：
59.s101、接收应用程序的合入代码。
60.代码管理平台从开发人员接收到应用程序的合入代码。其中，合入代码中可以包括业务对应的代码。在业务为应用程序已具有的业务时，合入代码中可以包括业务对应的新增代码；在业务为应用程序新增的业务时，合入代码中包括新增中业务对应的代码。
61.除了业务对应的代码之外，合入代码还可以包括：应用程序的其他代码。并且，本公开对应用程序的类型和合入代码的具体表示方式不做限定。
62.另外，除了合入代码之外，代码管理平台还可接收到一标识，用于表示开发人员想要将合入代码合入至应用程序中，以便代码管理平台对合入代码进行检测。并且，本公开对该标识的具体表示方式不做限定。
63.s102、确定合入代码中的修改部分中的代码是否涉及应用程序的目标路径。
64.在对合入代码提交后，代码管理平台可检测合入代码中的修改部分是否涉及应用程序的目标路径，以避免应用程序的目标路径出现劣化现象。
65.其中，在修改部分中的代码不涉及目标路径时，代码管理平台可通知给代码评审人员对合入代码进行合入仓库操作。
66.其中，目标路径可以为应用程序实现如一个或多个业务、一个或多个场景、一个或多个功能等所对应的阶段。本公开对目标路径的具体实现方式不做限定。
67.在一些实施例中，目标路径为应用程序的启动路径中的主进程的主线程。其中，启动路径为应用程序从开始启动到显示预设初始页面的时间段。具体地，启动路径设置为从应用程序开始启动到应用程序显示主页面时，对应地，主进程的主线程用于实现从应用程序开始启动到应用程序显示主页面。在启动路径设置为应用程序从开始启动到显示第一个页面(如引流页面)时，对应地，主进程的主线程用于实现应用程序从开始启动到显示第一个页面。
68.s103、确定修改部分中的代码是否存在耗时操作。
69.在应用程序的合入代码提交后，代码管理平台可检测修改部分中的代码是否存在耗时操作。其中，本公开对代码管理平台确定修改部分中的代码是否存在耗时操作的方式不做限定。
70.其中，在修改部分中的代码不存在耗时操作时，代码管理平台可通知给代码评审人员对合入代码进行合入仓库操作。
71.需要说明的是，步骤s102和步骤s103的执行顺序不分先后。
72.步骤s102可先于步骤s103执行，即在修改部分涉及目标路径之后，再确定修改部分中的涉及目标路径的代码是否存在耗时操作。从而，代码管理平台只需分析修改部分中的涉及目标路径的代码是否存在耗时操作，无需分析修改部分中的全部代码，减少了工作量，提高了工作效率。
73.步骤s103也可先于步骤s102执行，即在修改部分中的代码存在耗时操作之后，再确定修改部分中的存在耗时操作的代码是否涉及目标路径。从而，代码管理平台只需分析修改部分中的存在耗时操作的代码是否涉及目标路径，无需分析修改部分中的全部代码，减少了工作量，提高了工作效率。
74.步骤s102也可与步骤s103同步执行，即同步确定修改部分中存在耗时操作的代码1，以及修改部分中涉及目标路径的代码2，再确定前述代码1与前述代码2是否存在交集。从而，节省了确定时长，提高了工作效率。
75.另外，代码管理平台执行步骤s102或步骤s103之前，需要确定合入代码中存在修改部分。
76.s104、在修改部分中的代码涉及目标路径且存在耗时操作时，输出分析结果，分析结果包括合入代码中包括涉及目标路径且存在耗时操作的目标代码以及目标代码的位置。
77.基于步骤s102和步骤s103的描述，代码管理平台可确定修改部分是否涉及目标路径，以及修改部分中的代码是否存在耗时操作，使得代码管理平台可向代码评审人员通知修改部分中代码是否涉及目标路径且存在耗时操作。
78.从而，在修改部分中代码涉及目标路径且存在耗时操作时，代码管理平台可输出分析结果，以便基于分析结果向代码评审人员通知合入代码中包括涉及目标路径且存在耗时操作的目标代码以及目标代码的位置。
79.其中，本公开对分析结果的具体表示方式不做限定。例如，分析结果中包括存在标识和位置标识，存在标识用于表示合入代码中包括涉及目标路径且存在耗时操作的代码，位置标识用于标识对应代码的位置。前述提及的标识可采用数字、字母、字符等形式进行表示。
80.本公开提供的应用程序的处理方法，通过在应用程序的合入代码提交后，对合入代码中的改动部分进行检测分析，一是分析改动部分中的代码是否涉及目标路径；二是分析改动部分中的代码是否存在耗时操作。在改动部分中的代码涉及目标路径且存在耗时操作的情况下，可向代码评审人员通知分析结果，分析结果中包括合入代码中包括涉及目标路径且存在耗时操作的目标代码以及目标代码的位置，使得代码评审人员可与开发人员进行代码评审，以便在代码评审成功后对合入代码进行合入仓库操作，或者，使得代码评审人员可对合入代码进行阻止合入仓库操作。由此，能够更早的发现合入代码是否会导致应用
程序在目标路径劣化，以便有充足的时间去修复合入代码，提升了应用程序防劣化的处理效率，缩短了应用程序的修复周期。
81.基于图1实施例的描述，步骤s102中，代码管理平台采用了动态分析与静态分析结合的方式获取应用程序的全部代码中的涉及目标路径对应的耗时函数。
82.在一些实施例中，代码管理平台可获取目标文件。其中，目标文件中记录有应用程序的全部代码中的涉及应用程序的目标路径的全部函数。本公开对目标文件的具体实现方式不做限定。且本公开提及的函数也可理解为方法或函数方法。
83.另外，目标文件可存储在代码管理平台中，也可以存储在服务器中，也可存储在代码管理平台和服务器中，以充分考虑到代码管理平台可的存储空间，本公开对此不做限定。为了便于说明，本公开采用代码管理平台存储目标文件为例进行示意。
84.由于代码管理平台基于目标文件可确定应用程序的全部代码中的涉及目标路径的全部函数，且修改部分中的代码可为指令代码，或，函数中的调用代码。因此，代码管理平台可分析修改部分中的代码是否包含在目标文件记录的函数中，来确定修改部分中的代码是否涉及目标路径。
85.在修改部分中的代码包含在目标文件记录的函数中时，代码管理平台可确定修改部分中的代码涉及目标路径。
86.在修改部分中的代码不包含在目标文件记录的函数中时，代码管理平台可确定修改部分中的代码不涉及目标路径。此时，代码管理平台可通知给代码评审人员对合入代码进行合入仓库操作。
87.在一个具体实施例中，假设目标路径为启动路径，基于图1和上述实施例的描述，结合图2，介绍代码管理平台采用图1实施例的应用程序的处理方法的一种可行方式。
88.如图2所示，代码管理平台可执行如下步骤：
89.步骤01、开发者提交合入请求(merge request，mr)代码至代码管理平台，对应于图1中的步骤101。其中，mr代码即为应用程序的合入代码。
90.步骤02、代码管理平台进入检测流程后，从服务器获取目标文件，并基于目标文件判断mr代码中的修改部分中的代码是否涉及启动路径，对应于图1中的步骤102。
91.步骤03、代码管理平台在mr代码中的修改部分中的代码涉及启动路径时，判断修改部分中的代码是否存在耗时操作，对应于图1中的步骤103。
92.步骤04、代码管理平台在修改部分中的代码存在耗时操作时，输出分析结果，对应于图1中的步骤103。
93.从而，代码管理平台可进入到评审阶段，并向代码评审人员通知分析结果，使得代码评审人员基于分析结果判断mr代码是否能够通过。在mr代码通过后，代码管理平台可进入到入库流程，以便将mr代码存入到仓库中。
94.另外，代码管理平台在的修改部分中的代码不涉及启动路径，或者，修改部分中的代码不存在耗时操作时，可进入到入库流程。
95.本公开中，代码管理平台可采用多种方式获取目标文件。其中，目标文件可划分为第一文件和第二文件，第一文件和第二文件中均记录有应用程序的全部代码中的涉及目标路径的全部函数，且第一文件和第二文件是从不同角度来确定应用程序的全部代码中的涉及目标路径的全部函数的。
96.下面，结合图3，在目标文件存储在代码管理平台的本地存储模块中的情况下，介绍代码管理平台获取目标文件的具体实现方式。
97.请参阅图3，图3为本公开实施例提供的应用程序的处理方法的流程示意图。如图3所示，本公开提供的应用程序的处理方法可以包括：
98.s201、获取第一文件，并基于第一文件确定应用程序的全部代码中的在目标路径中被调用的第一函数集合。
99.本公开中，第一文件是从在目标路径中是否被调用的角度来记录应用程序的全部代码中的函数的。因此，代码管理平台可从代码管理平台的本地存储模块中获取第一文件，并基于第一文件确定应用程序的全部代码中的在目标路径中被调用的第一函数集合。
100.其中，本公开对第一文件的确定方式不做限定。在一些实施例中，如图4所示，第一文件的确定步骤可以包括：
101.步骤11、在应用程序的编译阶段中，配置目标路径的起始函数和终止函数。
102.其中，起始函数用于目标路径的启动，终止函数用于目标路径的终止。本公开对目标路径、起始函数和终止函数的具体实现方法不做限定。
103.步骤12、对应用程序的全部代码进行插桩处理。
104.其中，本公开对插桩处理的具体实现方式不做限定。在一些实施例中，在应用程序的编译期，对应用程序的全部代码中的全部函数的“出口”和“入口”插入“桩函数”。
105.步骤13、基于插桩处理，在应用程序的运行阶段中，将起始函数和终止函数之间的被调用的函数记录在第一文件中。
106.其中，代码管理平台可自动启动应用程序，以便收集应用程序的全部代码中的被调用的函数。例如，目标路径为应用程序的主程序的主线程，则应用程序的全部代码中的被调用的函数为主进程的主线程所启动的函数。
107.在应用程序的运行阶段中，如果一个函数在目标路径中被调用，则“桩函数”便可记录下来该函数。在目标路径截止后，“桩函数”便停止记录。即，终止函数首次执行后，便停止收集目标路径中合入代码中的被调用的函数。从而，代码管理平台可将已记录下来的全部函数保存在第一文件中。
108.步骤14、保存第一文件。具体的，第一文件可以先保存至本地，再发送至服务器。
109.从而，代码管理平台可实现了应用程序的全部代码中的涉及目标路径所对应的第一函数集合的动态采集。
110.需要说明的是，图4实施例中第一文件的确定步骤可除了由代码管理平台执行之外，也可由其他的执行平台来执行，本公开对此不做限定。
111.s202、获取第二文件，并基于第二文件确定应用程序的全部代码中的在目标路径的根函数中被调用的第二函数集合。
112.本公开中，第二文件是从在目标路径的根函数中是否被调用的角度来记录应用程序的全部代码中的函数的。因此，代码管理平台可从代码管理平台的本地存储模块中获取第二文件，并基于第二文件确定代码管理平台中的在目标路径的根函数中被调用的第二函数集合。
113.其中，本公开对第二文件的确定方式不做限定。在一些实施例中，如图5所示，第二文件的确定步骤可以包括：
114.步骤21、确定目标路径的根函数。
115.其中，本公开对目标路径的根函数的具体实现方式不做限定。例如，在目标路径为启动路径时，目标路径的根函数可配置为android四大组件(活动(activity)、服务(service)、内容提供者(content provider)、广播接收器(broadcast receiver))及应用启动的相关声明周期函数。另外，目标路径的根函数可预先配置在代码管理平台中，此处无需进行重复配置。
116.步骤22、将应用程序的全部代码编译成第一字节码。
117.步骤23、对第一字节码进行静态分析，获取根函数直接和间接调用的子函数，并将根函数及子函数记录在第二文件中。
118.代码管理平台可采用字节码静态分析方法，确定第一字节码中对应的函数所调用的路径，并采用如优化后的maindexlist的可达性算法，分析根函数的直接调用和间接调用的子函数，来确定所有链路函数(即根函数和子函数)。从而，代码管理平台可将收集到的所有链路函数记录到第二文件中。
119.步骤24、保存第二文件。具体的，第二文件可以先保存至本地，再发送至服务器。
120.从而，代码管理平台可实现了应用程序的全部代码中的在目标路径的根函数中被调用的第二函数集合的静态采集。
121.需要说明的是，图5实施例中第二文件的确定步骤除了由代码管理平台执行之外，还可由其他的执行平台来执行，本公开对此不做限定。
122.s203、将第一函数集合和第二函数集合的并集确定为目标文件。
123.由于第一函数集合和第二函数集合各自可能会漏掉目标路径中的一些函数。例如，第一函数集合无法覆盖所有if-else代码分支，第二函数集合无法覆盖非直接方法调用的情况(如action、事件等调用方式)。因此，代码管理平台可取第一函数集合和第二函数集合的并集作为目标文件，尽可能全地覆盖目标路径。
124.综上，代码管理平台可从代码管理平台的本地存储模块中获取到目标文件。
125.需要说明的是，除了上述实现方式之外，代码管理平台也可从服务器获取到目标文件，或者也可从服务器中分别获取第一文件和第二文件，本公开不限于上述实现方式。
126.基于上述图3-图5实施例的描述，代码管理平台可尽可能全地收集基于动静结合策略得到的目标文件，以便能够尽可能完整地分析目标路径所涉及的函数，从而基于目标文件最大范围地确定合入代码中的修改部分是否涉及目标路径。
127.本公开中，代码管理平台可采用多种实现方式来步骤s104中的确定修改部分中的代码是否存在耗时操作。
128.下面，结合图6，介绍代码管理平台确定修改部分中的代码是否存在耗时操作的一种可行的实现方式。
129.请参阅图6，图6为本公开实施例提供的应用程序的处理方法的流程示意图。如图6所示，本公开提供的应用程序的处理方法可以包括：
130.s301、在应用程序的编译阶段中，将修改部分编译成第二字节码。
131.由于代码管理平台能够执行字节码。因此，在应用程序的编译阶段中，代码管理平台可将修改部分编译成第二字节码，以便代码管理平台通过静态分析字节码来判断字节码对应的函数所对应于的修改部分中的代码是否存在耗时操作。
132.例如，修改部分中的代码采用java源码，则代码管理平台可将java源码编译转换为代码管理平台可执行的第二字节码，以便通过静态分析字节码对应的指令来判断对应的函数是否耗时。
133.s302、针对第二字节码中对应的每个函数而言，确定每个函数的类型是否在预设列表的类型范围内，预设列表中记录有耗时函数的类型。
134.由于预设列表中记录有耗时函数的类型。因此，针对第二字节码中对应的一个函数而言，在目标路径的运行阶段中，代码管理平台可确定一个函数类型是否在预设列表的类型范围内，来确定该函数对应于修改部分中的代码是否存在耗时操作。
135.其中，预设列表可预先配置在代码管理平台中，也可由开发人员输入到代码管理平台中，本公开对此不做限定。
136.并且，本公开对预设列表和耗时函数的具体实现方式不做限定。
137.在一些实施例中，预设列表中的耗时函数的类型可以包括但不限于：有锁函数、json解析函数、读写i/o函数以及系统耗时函数(如应用的函数fun1调用android sdk中一个耗时函数afun1，则函数fun1属于耗时函数)。另外，预设列表中的耗时函数的类型也可包括循环函数。
138.在第二字节码中对应的一个函数的类型在预设列表的类型范围内时，代码管理平台可执行步骤s3031；在第二字节码中对应的一个函数的类型不在预设列表的类型范围内时，代码管理平台可执行步骤s3032。
139.s3031、确定第二字节码中对应的一个函数对应于修改部分中的代码存在耗时操作。
140.代码管理平台在第二字节码中对应的一个函数的类型在预设列表的类型范围内时，可确定该函数对应于修改部分中的代码存在耗时操作。
141.s3032、确定第二字节码中对应的一个函数对应于修改部分中的代码不存在耗时操作。
142.代码管理平台在第二字节码中对应的一个函数的类型不在预设列表的类型范围内时，可确定该函数对应于修改部分中的代码不存在耗时操作。
143.综上，代码管理平台可基于第二字节码中对应的全部函数，来确定出修改部分中的代码是否存在耗时操作。
144.从而，耗时静态分析出修改部分中的代码是否存在耗时操作。
145.另外，基于上述描述，代码管理平台可秉承“函数耗时具有传递性”的原则，来确定修改部分中的代码是否存在耗时操作。
146.另外，由于修改部分中的代码可能会调用已存在应用程序之前版本的函数，且修改部分中的代码并不包括被调用的函数的代码。因此，第二字节码中对应的全部函数可能不会包含被调用的函数。
147.从而，针对第二字节码中对应的一个函数而言，在该函数存在调用了的外部函数，且第二字节码中对应的全部函数不包括该函数调用了的外部函数时，代码管理平台可确定该函数调用了的外部第二函数的类型是否在预设列表的类型范围内，来判断该函数是否存在耗时操作。由此，有利于全面地确定修改部分中的代码中的耗时函数。
148.在该函数调用了的外部函数在预设列表的类型范围内时，代码管理平台可确定该
函数对应于修改部分中的代码存在耗时操作。
149.在该函数调用了的外部函数不在预设列表的类型范围内时，代码管理平台可确定该函数对应于修改部分中的代码不存在耗时操作。
150.在另一些实施例中，修改部分中的代码本身为函数(称为第一函数)，且第一函数调用了第二函数。即第二函数为第一函数的子函数，第一函数为第二函数的父函数。从而，代码管理平台也可通过确定第二函数的类型是否在预设列表的类型范围内，来确定第一函数是否存在耗时操作。
151.从而，在第二函数在预设列表的类型范围内时，代码管理平台可确定第一函数存在耗时操作。在第二函数不在预设列表的类型范围内时，代码管理平台可确定第一函数不存在耗时操作。
152.例如，假设三个函数的调用关系是函数fun1-》函数fun2-》函数fun3，即函数fun1调用了函数fun2，函数fun2调用了函数fun3。在函数fun1和函数fun2均不属于耗时函数的类型的情况下，若函数fun3属于耗时函数的类型，则代码管理平台可确定函数fun1、函数fun2和函数fun3均属于耗时函数，三个函数对应于修改部分中的代码均存在耗时操作。
153.综上，在确定第二字节码中对应的一个函数存在耗时操作且涉及目标路径时，代码管理平台可将该函数确定为目标代码，将该函数的位置确定为目标代码的位置，并将目标代码及目标代码的位置保存至分析结果中。
154.示例性地，本公开提供一种应用程序的处理装置。
155.请参阅图7，图7为本公开实施例提供的应用程序的处理装置的结构示意图。本公开的应用程序的处理装置可设置在代码管理平台中，可实现上述图1-图6实施例的应用程序的处理方法对应于代码管理平台的操作。
156.如图7所示，本公开提供的应用程序的处理装置100可以包括：接收模块101、确定模块102和输出模块103。
157.接收模块101，用于接收应用程序的合入代码；
158.确定模块102，用于确定合入代码中的修改部分中的代码是否涉及应用程序的目标路径；
159.确定模块102，还用于确定修改部分中的代码是否存在耗时操作；
160.输出模块103，用于在修改部分中的代码涉及目标路径且存在耗时操作时，输出分析结果，分析结果包括合入代码中包括涉及目标路径且存在耗时操作的目标代码以及目标代码的位置。
161.在一种可能的设计中，确定模块102，具体用于在确定修改部分中的代码涉及目标路径后，确定修改部分中的涉及目标路径的代码是否存在耗时操作。
162.在一些实施例中，确定模块102，具体用于获取目标文件，目标文件中记录有应用程序的全部代码中的涉及目标路径的全部函数；基于目标文件，确定修改部分中的代码是否涉及目标路径。
163.在一些实施例中，确定模块102，用于在修改部分中的代码包含在目标文件记录的函数中时，确定修改部分中的代码涉及目标路径；在修改部分中的代码不包含在目标文件记录的函数中时，确定修改部分中的代码不涉及目标路径。
164.在一些实施例中，确定模块102，用于获取第一文件，并基于第一文件确定应用程
序的全部代码中的在目标路径中被调用的第一函数集合；获取第二文件，并基于第二文件确定应用程序的全部代码中的在目标路径的根函数中被调用的第二函数集合；将第一函数集合和第二函数集合的并集确定为目标文件。
165.在一些实施例中，确定模块102，还用于确定第一文件。确定模块102，具体用于在应用程序的编译阶段中，配置目标路径的起始函数和终止函数；对应用程序的全部代码进行插桩处理；基于插桩处理，在应用程序的运行阶段中，将起始函数和终止函数之间的被调用的函数记录在第一文件中；保存第一文件。
166.在一些实施例中，确定模块102，还用于确定第二文件。确定模块102，具体用于确定配置目标路径的根函数；将应用程序的全部代码编译成第一字节码；对第一字节码进行静态分析，获取根函数直接和间接调用的子函数，并将根函数及子函数记录在第二文件中；保存第二文件。
167.在一些实施例中，确定模块102，还具体用于在应用程序的编译阶段中，将修改部分编译成第二字节码；针对第二字节码中对应的每个函数而言，在目标路径的运行阶段中，确定每个函数的类型是否在预设列表的类型范围内，预设列表中记录有耗时函数的类型；在第二字节码中对应的一个函数的类型在预设列表的类型范围内时，确定一个函数对应于修改部分中的代码存在耗时操作；在第二字节码中对应的一个函数类型不在预设列表的类型范围内时，确定一个函数对应于修改部分中的代码不存在耗时操作。
168.在一些实施例中，确定模块102，还用于在第二字节码中对应的一个函数存在调用了的外部函数，且第二字节码中对应的全部函数不包括一个函数调用了的外部函数时，确定一个函数调用了的外部函数的类型是否在预设列表的类型范围内；在一个函数调用了的外部函数在预设列表的类型范围内时，确定一个函数存在耗时操作；在一个函数调用了的外部函数不在预设列表的类型范围内时，确定一个函数不存在耗时操作。
169.在一种可能的设计中，当确定第二字节码中对应的一个函数存在耗时操作且涉及目标路径时，将一个函数确定为目标代码，将一个函数的位置确定为目标代码的位置，并将目标代码及目标代码的位置保存至分析结果中。
170.在一些实施例中，预设列表中的耗时函数的类型包括：有锁函数、json解析函数、读写i/o函数以及系统耗时函数。
171.在一些实施例中，目标路径为应用程序的启动路径中的主进程的主线程。
172.本公开提供的应用程序的处理装置，可执行上述方法实施例，其具体实现原理和技术效果，可参见上述方法实施例，本公开此处不再赘述。
173.示例性地，本公开提供一种电子设备，包括：一个或多个处理器；存储器；以及一个或多个计算机程序；其中一个或多个计算机程序被存储在存储器中；一个或多个处理器在执行一个或多个计算机程序时，使得电子设备实现前文实施例的应用程序的处理方法。
174.示例性地，本公开提供一种芯片系统，芯片系统应用于包括存储器和传感器的电子设备；芯片系统包括：处理器；当处理器执行前文实施例的应用程序的处理方法。
175.示例性地，本公开提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器使得电子设备执行时实现前文实施例的应用程序的处理方法。
176.示例性地，本公开提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行前文实施例的应用程序的处理方法。
177.在上述实施例中，全部或部分功能可以通过软件、硬件、或者软件加硬件的组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本公开实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如，固态硬盘(solid state disk，ssd))等。
178.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
179.以上仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。