一种代码文件处理方法、装置、设备及介质与流程

1.本技术涉及计算机技术领域，尤其涉及一种代码文件处理方法、装置、设备及介质。


背景技术：

2.随着计算机技术的不断发展，逐渐出现了多种代码开发平台和运行平台，但代码开发平台开发出的代码文件包可能在运行平台上无法直接运行，这时，则需要对代码文件包进行打包。react native是目前应用最为广泛的跨平台技术框架之一，开发者只需编写一套javascript代码就可以同时在安卓、苹果等平台上运行相应的应用程序。有的用户编写的代码文件包并不是javascript代码，此时需要通过相应的打包工具，将该代码文件包打包为react native环境能够运行的javascript代码。打包过程中需要将编写的代码文件包拆分为多个代码文件，并对这多个代码文件进行标识，基于代码文件的标识才能找到对应的代码文件，打包生成react native能够运行的代码文件包。
3.目前，一般采用代码文件的绝对路径来标识代码文件，然而在相同路径下可能存在多个代码文件，仅通过绝对路径无法准确地确定出对应的代码文件，进而影响打包的准确性。


技术实现要素：

4.本技术实施例提供一种代码文件处理方法、装置、设备及介质，用于提高打包的准确性。
5.第一方面，本技术实施例提供一种代码文件处理方法，包括：
6.获取第一代码文件包，其中，所述第一代码文件包包括各个代码文件，所述第一代码文件用于实现相应的业务；
7.分别确定所述各个代码文件各自的标识，其中，若代码文件为第一类型，则基于代码文件的路径，确定代码文件的标识，若代码文件为第二类型，基于代码文件的哈希表示，确定代码文件的标识，其中，所述哈希表示是采用预设的哈希算法对代码文件的内容进行计算得到的，所述第一类型是指所述业务发生变化时无需更改的代码文件，所述第二类型是指所述业务发生变化时需要更改的代码文件；
8.基于所述各个代码文件，以及所述各个代码文件各自对应的标识，生成第二代码文件包。
9.本技术实施例中，针对业务发生变化时需要更改的代码文件，通过哈希表示确定代码文件的标识，哈希表示是采用预设的哈希算法对代码文件的内容进行计算得到的，不同业务的代码文件的哈希表示是不同的，可以避免在相同路径下存在多个代码文件时，根据路径无法准确地确定出对应的代码文件的问题。针对业务发生变化时无需更改的代码文件，可以采用路径确定代码文件的标识，可以避免打包工具的版本变化引起的哈希表示不一致的问题。因此，本技术实施例根据第一代码文件包中各个代码文件所属的类型不同，采
用不同的方式确定代码文件的标识，能够准确地确定出不同类型的代码文件的标识，进而基于标识准确找到对应的各个代码文件，生成第二代码文件包的准确性会更高，从而提高打包的准确性。
10.在一种可能的实施例中，分别确定所述各个代码文件各自的标识，包括：
11.确定所述第一代码文件包的索引表，其中，所述索引表包括所述各个代码文件中每个代码文件的对应关系，所述对应关系为代码文件的路径、代码文件的哈希表示、以及代码文件的标识三者之间的关联关系；
12.基于所述索引表，分别确定所述各个代码文件各自的标识。
13.本技术实例中，索引表包括各个代码文件的路径、代码文件的哈希表示、以及代码文件的标识三者之间的关联关系，基于索引表，可以通过路径确定代码文件的标识，也可以通过哈希表示确定代码文件的标识，确定代码文件的标识的方式更加灵活。
14.在一种可能的实施例中，所述索引表包括第一索引分表和第二索引分表，所述第一索引分表包括所述第一类型的代码文件的路径、所述第一类型的代码文件的哈希表示、以及所述第一类型的代码文件的标识之间的关联关系，所述第二索引分表包括所述第二类型的代码文件的路径、所述第二类型的代码文件的哈希表示、以及所述第二类型的代码文件的标识之间的关联关系；
15.基于所述索引表，分别确定所述各个代码文件各自的标识，包括：
16.若所述各个代码文件中的任一代码文件为所述第一类型，则基于所述任一代码文件的路径，从所述第一索引分表中，确定所述路径对应的标识；
17.若所述各个代码文件中的任一代码文件为所述第二类型，则基于所述任一代码文件的哈希表示，从所述第二索引分表中，确定所述哈希表示对应的标识。
18.本技术实例中，索引表包括两个索引分表，若代码文件为第一类型，从第一索引分表中，确定该代码文件的路径对应的标识，若代码文件为第二类型，从第二索引分表中，确定该代码文件的哈希表示对应的标识，从对应的索引表中检索代码文件的标识，可以减少检索的数据量，提高处理效率。
19.在一种可能的实施例中，确定所述第一代码文件包的索引表，包括：
20.基于所述第一代码文件包中的各个代码文件之间的依赖关系，获得依赖图；
21.遍历所述依赖图中的各个代码文件，直到遍历完所述依赖图中的各个代码文件，获得索引表，其中每次遍历包括以下过程：
22.若所述索引表中未记录当前遍历的代码文件的标识，则生成所述当前遍历的代码文件的路径、所述当前遍历的代码文件的哈希表示、以及所述当前遍历的代码文件的标识，并将所述当前遍历的代码文件的路径、所述当前遍历的代码文件的哈希表示、以及所述当前遍历的代码文件的标识之间的关联关系写入所述索引表；
23.若所述索引表已记录当前遍历的代码文件的标识，则遍历所述依赖图中的下一个代码文件。
24.本技术实例中，若索引表中未记录当前遍历的代码文件的标识，将当前遍历的代码文件的路径、哈希表示、以及标识之间的关联关系写入索引表，若索引表已记录当前遍历的代码文件的标识，则遍历依赖图中的下一个代码文件，可以避免将重复的关联关系写入索引表中，相对减少写入索引表的数据量。
25.在一种可能的实施例中，所述遍历所述依赖图中的各个代码文件，包括：
26.按照所述依赖图中的各个代码文件，在所述依赖图中出现的从先到后的顺序，依次遍历；
27.生成所述当前遍历的代码文件的标识，包括：
28.基于所述当前遍历的代码文件所属的类型标识，以及所述当前遍历的代码文件在所述依赖图中的出现序号，生成所述当前遍历的代码文件的标识。
29.本技术实例中，基于当前遍历的代码文件所属的类型标识，以及当前遍历的代码文件在依赖图中的出现序号，生成标识，这种生成标识的方式可以方便区分当前遍历的代码文件所属的类型，且生成的标识的长度较短，可以减少后续基于标识生成的文件包的大小。
30.在一种可能的实施例中，所述第一代码文件包包括第一代码文件子包，所述第一代码文件子包包括所述第一类型的代码文件；
31.基于所述第一代码文件包中各个代码文件之间的依赖关系，获得依赖图，包括：
32.基于所述第一代码文件子包，确定所述第一代码文件子包中的各个代码文件之间的依赖关系，获得第一依赖子图；
33.基于所述第一代码文件包，确定所述第一代码文件包中的各个代码文件之间的依赖关系，获得第二依赖子图；
34.基于所述第一依赖子图，确定所述第一索引分表；
35.基于所述第二依赖子图，以及所述第一索引分表，确定所述第二索引分表。
36.本技术实例中，第一索引分表是基于第一代码文件子包的第一依赖子图确定的，由于第一代码文件子包包括业务发生变化时无需更改的代码文件，因此，本技术实例中确定的第一索引分表涉及的代码文件是固定的，后续业务发生变化时，无需重复确定第一索引分表，可以直接使用第一索引分表，进一步提高处理效率。
37.在一种可能的实施例中，根据所述第二依赖子图，以及所述第一索引分表，确定第二索引分表，包括：
38.遍历所述第二依赖子图中的各个代码文件，直到遍历完所述第二依赖子图中的各个代码文件，获得第二索引分表，其中每次遍历包括以下过程：
39.若所述第一索引分表没有记录当前遍历的代码文件的标识，则生成所述当前遍历的代码文件的路径、所述当前遍历的代码文件的哈希表示、以及所述当前遍历的代码文件的标识，并将所述当前遍历的代码文件的路径、所述当前遍历的代码文件的哈希表示、以及所述当前遍历的代码文件的标识之间的关联关系写入第二索引分表；
40.若所述第一索引分表已记录当前遍历的代码文件的路径，则遍历所述第二依赖子图中的下一个代码文件。
41.第二方面，提供一种代码文件处理装置，所述装置包括：
42.获取模块，用于获取第一代码文件包，其中，所述第一代码文件包包括各个代码文件，所述第一代码文件用于实现相应的业务；
43.确定模块，用于分别确定所述各个代码文件各自的标识，其中，若代码文件为第一类型，则基于代码文件在所述第一代码文件包中的路径，确定代码文件的标识，若代码文件为第二类型，基于代码文件的哈希表示，确定代码文件的标识，其中，所述哈希表示是采用
预设的哈希算法对代码文件的内容进行计算得到的，所述第一类型是指所述业务发生变化时无需更改的代码文件，所述第二类型是指所述业务发生变化时需要更改的代码文件；
44.生成模块，用于基于所述各个代码文件，以及所述各个代码文件各自对应的标识，生成第二代码文件包。
45.在一种可能的实施例中，所述确定模具体用于：
46.确定所述第一代码文件包的索引表，其中，所述索引表包括所述各个代码文件中每个代码文件的对应关系，所述对应关系为代码文件的路径、代码文件的哈希表示、以及代码文件的标识三者之间的关联关系；
47.基于所述索引表，分别确定所述各个代码文件各自的标识。
48.在一种可能的实施例中，所述索引表包括第一索引分表和第二索引分表，所述第一索引分表包括所述第一类型的代码文件的路径、所述第一类型的代码文件的哈希表示、以及所述第一类型的代码文件的标识之间的关联关系，所述第二索引分表包括所述第二类型的代码文件的路径、所述第二类型的代码文件的哈希表示、以及所述第二类型的代码文件的标识之间的关联关系；所述确定模块具体用于：
49.若所述各个代码文件中的任一代码文件为所述第一类型，则基于所述任一代码文件的路径，从所述第一索引分表中，确定所述路径对应的标识；
50.若所述各个代码文件中的任一代码文件为所述第二类型，则基于所述任一代码文件的哈希表示，从所述第二索引分表中，确定所述哈希表示对应的标识。
51.在一种可能的实施例中，所述确定模块具体用于：
52.基于所述第一代码文件包中的各个代码文件之间的依赖关系，获得依赖图；
53.遍历所述依赖图中的各个代码文件，直到遍历完所述依赖图中的各个代码文件，获得索引表，其中每次遍历包括以下过程：
54.若所述索引表中未记录当前遍历的代码文件的标识，则生成所述当前遍历的代码文件的路径、所述当前遍历的代码文件的哈希表示、以及所述当前遍历的代码文件的标识，并将所述当前遍历的代码文件的路径、所述当前遍历的代码文件的哈希表示、以及所述当前遍历的代码文件的标识之间的关联关系写入所述索引表；
55.若所述索引表已记录当前遍历的代码文件的标识，则遍历所述依赖图中的下一个代码文件。
56.在一种可能的实施例中，所述装置包括遍历模块，所述遍历模块用于：
57.按照所述依赖图中的各个代码文件，在所述依赖图中出现的从先到后的顺序，依次遍历；
58.所述生成模块具体用于：
59.基于所述当前遍历的代码文件所属的类型标识，以及所述当前遍历的代码文件在所述依赖图中的出现序号，生成所述当前遍历的代码文件的标识。
60.在一种可能的实施例中，所述第一代码文件包包括第一代码文件子包，所述第一代码文件子包包括所述第一类型的代码文件；所述确定模块具体用于：
61.基于所述第一代码文件子包，确定所述第一代码文件子包中的各个代码文件之间的依赖关系，获得第一依赖子图；
62.基于所述第一代码文件包，确定所述第一代码文件包中的各个代码文件之间的依
赖关系，获得第二依赖子图；
63.基于所述第一依赖子图，确定所述第一索引分表；
64.基于所述第二依赖子图，以及所述第一索引分表，确定所述第二索引分表。
65.在一种可能的实施例中，所述确定模块具体用于：
66.遍历所述第二依赖子图中的各个代码文件，直到遍历完所述第二依赖子图中的各个代码文件，获得第二索引分表，其中每次遍历包括以下过程：
67.若所述第一索引分表没有记录当前遍历的代码文件的标识，则生成所述当前遍历的代码文件的路径、所述当前遍历的代码文件的哈希表示、以及所述当前遍历的代码文件的标识，并将所述当前遍历的代码文件的路径、所述当前遍历的代码文件的哈希表示、以及所述当前遍历的代码文件的标识之间的关联关系写入第二索引分表；
68.若所述第一索引分表已记录当前遍历的代码文件的路径，则遍历所述第二依赖子图中的下一个代码文件。
69.第三方面，提供一种代码文件处理设备，包括：
70.至少一个处理器，以及
71.与所述至少一个处理器通信连接的存储器；
72.其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令实现如第一方面中任一项所述的方法。
73.第四方面，一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如第一方面中任一项所述的方法。
附图说明
74.图1为本技术实施例提供的一种代码文件处理方法的应用场景图；
75.图2为本技术实施例提供的一种代码文件处理方法的流程图；
76.图3为本技术实施例提供的一种代码文件处理装置的结构图；
77.图4为本技术实施例提供的一种代码文件处理设备的结构图。
具体实施方式
78.为了更好的理解本技术实施例提供的技术方案，下面将结合说明书附图以及具体的实施方式进行详细的说明。
79.为了解决打包过程中准确性较低的问题，本技术实施例提供一种代码文件处理方法，该方法可以由代码文件处理设备执行，为了简化描述，下文中将代码文件处理设备简称为处理设备。处理设备可以通过终端或服务器实现，终端例如个人计算机、手机、或嵌入式设备等，服务器例如实体服务或虚拟服务器等。
80.下面对该代码文件处理方法的应用场景示意图进行说明。
81.请参照图1，为本技术实施例提供的代码文件处理方法的应用场景示意图，该应用场景包括：待处理的代码文件包110和处理设备120，图1中是以处理设备120为个人计算机为例，本技术对此不作限定。
82.处理设备120获取待处理的代码文件包110之后，获得代码文件包110中的各个代
码文件，并分别确定各个代码文件各自对应的标识，最后基于各个代码文件，以及各个代码文件各自对应的标识，生成第二代码文件包。其中，确定各个代码文件的标识的过程将在下文中进行介绍。
83.基于图1论述的应用场景，下面以图1中处理设备执行代码文件处理方法为例进行介绍。请参照图2，为本技术实施例提供的一种代码文件处理方法的流程示意图，该流程示意图包括：
84.s210，获取第一代码文件包。
85.第一代码文件包用于实现相应的业务，可以是任意需要打包的代码文件。第一代码文件包包括各个代码文件，代码文件指的是存放程序代码的文件。代码文件的类型包括第一类型和第二类型。第一类型代码是指业务发生变化时无需更改的代码文件，即第一类型的代码文件是多种业务均可直接复用的，例如网络资源上共享的第三方依赖代码，是无需更改的。第二类型代码是指业务发生变化时需要更改的代码文件，即第二类型的代码文件随着业务不同而需要做出调整，例如根据指定业务需求编写的业务代码。
86.第一代码文件包包括第一代码文件子包，第一代码文件子包包括第一类型的代码文件，第一代码文件子包为平台运行所必须的的代码文件所形成的包，例如为基于react native环境运行必须的代码文件所形成的包，第一代码文件子包也可以称为基础包。第一代码文件包也可以称为全量包。
87.当用户想要对第一代码文件包进行打包时，可以输入针对第一代码文件包的打包命令。处理设备接收针对第一代码文件包的打包命令，获取第一代码文件包，基于第一代码文件包中的各个代码文件之间的依赖关系，获得依赖图，并基于第一代码文件包的依赖图，从第一代码文件包中依次获取各个代码文件。
88.具体的，处理设备响应于第一代码文件包的打包命令，获取第一代码文件包中的第一代码文件，第一代码文件为第一代码文件包的入口文件，入口文件指访问第一代码文件包时第一个访问的文件，处理设备可以读取该入口文件，从而获取第一代码文件包中的其他代码文件。
89.基于第一代码文件与其他代码文件之间的依赖关系，获得第一代码文件包的依赖图，以及按照依赖图中各个代码文件出现的先后顺序，从第一代码文件包中依次获取各个代码文件，其中，其他代码文件是指第一代码文件包中除了第一代码文件之外的代码文件。
90.例如，处理设备根据第一代码文件，确定第一代码文件依赖的第二代码文件，根据第二代码文件，确定第二代码文件依赖的第三代码文件，通过递归遍历，获得第一代码文件包中各个代码文件之间的依赖关系，从而形成依赖图。处理设备在获得依赖图之后，先获取第一代码文件，再获取第二代码文件，接着第三代码文件，以此类推，依次获取第一代码文件包的各个代码文件。
91.s220，分别确定各个代码文件各自的标识。
92.处理设备在获得第一代码文件包之后，可以基于第一代码文件包的索引表可以分别确定各个代码文件各自的标识。其中，索引表包括各个代码文件中每个代码文件的对应关系，对应关系为代码文件的路径、代码文件的哈希表示、以及代码文件的标识三者之间的关联关系。代码文件的路径可以是绝对路径或相对路径。绝对路径为该代码文件在处理设备中的存储路径。相对路径为该代码文件在第一代码文件包中的路径。代码文件的哈希表
示是指采用预设的哈希算法对该代码文件的内容进行哈希计算得到的，例如，哈希表示可以为任意长度的字符串，预设的哈希算法例如信息
‑
摘要算法5(message
‑
digest algorithm5，md5)、安全哈希算法(secure hash algorithm，sha)等。代码文件的标识用于唯一标识该代码文件。
93.其中涉及到如何获得第一代码文件包的索引表，下面进行具体介绍：
94.处理设备按照依赖图中的各个代码文件，在依赖图中出现的从先到后的顺序，依次遍历，直到遍历完依赖图中的各个代码文件，获得索引表。其中每次遍历包括以下过程：
95.若索引表中没有记录当前遍历的代码文件的标识，则处理设备可以通过相应的命令，生成当前遍历的代码文件的路径，还可以采用预设的哈希算法对当前遍历的代码文件的内容进行计算，生成当前遍历的代码文件的哈希表示。
96.作为一种示例，可以将当前遍历的代码文件的路径或哈希表示作为当前遍历的代码文件的标识。或者，考虑到路径或哈希表示的字符串可能过长，直接将路径或哈希表示作为当前遍历的代码文件的标识，可能导致后续处理中生成的代码文件包过大。因此，本技术实施例中，处理设备还可以生成长度较短的标识，作为当前遍历的代码文件的标识。生成标识的方式有多种，下面进行示例介绍：
97.第一种，处理设备可以基于当前遍历的代码文件在依赖图中的出现序号，生成当前遍历的代码文件的标识，使标识的长度尽可能短。
98.例如，当前遍历的代码文件是依赖图中的第一代码文件时，第一代码文件的标识为“1”，当前遍历的代码文件是依赖图中的第一代码文件依赖的第二代码文件时，第二代码文件的标识为“2”。
99.第二种，处理设备可以基于当前遍历的代码文件所属的类型标识，以及当前遍历的代码文件在第一依赖子图中的出现序号，生成当前遍历的代码文件的标识，使得标识长度较短的同时，可以通过该标识区分当前遍历的代码文件所属的类型。
100.例如，第一类型的代码文件的标识为“base1”、“base2”等，第二类型的代码文件的标识为“business1”、“business2”等。
101.作为一种实施例，针对第二类型的代码文件，处理设备还可以基于当前遍历的代码文件的业务标识，以及当前遍历的代码文件在第一依赖子图中的出现序号，生成当前遍历的代码文件的标识，以便根据该代码文件的标识确定该代码文件的业务内容。
102.例如，若第一代码文件为第二类型中的发现业务，则第一代码文件的标识为“discover1”，若第二代码文件为第二类型中的支付业务，则第二代码文件的标识为“pay2”。
103.进一步，处理设备在获得当前遍历的代码文件的路径、当前遍历的代码文件的哈希表示、以及当前遍历的代码文件的标识之后，将三者之间的关联关系写入索引表。若索引表已记录当前遍历的代码文件的标识，则遍历下一个代码文件。
104.考虑到代码文件包对应的索引表中包含的信息较多，可能会影响后续查找索引表的效率，为此，在本技术实施例中索引表可以包括第一索引分表和第二索引分表，处理设备分别基于第一索引分表和第二索引分表，打包第一文件代码包。其中，第一索引分表包括第一类型的代码文件的路径、第一类型的代码文件的哈希表示、以及第一类型的代码文件的标识与之间的关联关系，第二索引分表包括第二类型的代码文件的路径、第二类型的代码
文件的哈希表示、以及第二类型的代码文件的标识与之间的关联关系。
105.其中涉及到处理设备如何确定第一索引分表，下面进行介绍：
106.处理设备基于第一代码文件子包，确定第一代码文件子包中的各个代码文件之间的依赖关系，获得第一依赖子图。其中，获得第一依赖子图的具体方式请参照前文论述的获得依赖图的内容，此处不再赘述。处理设备根据第一依赖子图，确定第一索引分表。其中，确定第一索引分表的方式请参照前文论述的确定索引表的内容，此处不再赘述。
107.处理设备在确定第一索引分表之后，可以基于第一代码文件包，确定第一代码文件包中的各个代码文件之间的依赖关系，获得第二依赖子图。其中，获得第二依赖子图的具体方式请参照前文论述的获得依赖图的内容，此处不再赘述。以及根据第二依赖子图，以及第一索引分表，确定第二索引分表。下面对第二索引分表的确定方式进行介绍：
108.处理设备按照第二依赖子图中的各个代码文件，在第二依赖子图中出现的从先到后的顺序，依次遍历，直到遍历完第二依赖子图中的各个代码文件，获得第二索引表。其中，每次遍历包括以下过程：
109.若第一索引分表没有记录当前遍历的代码文件的标识，则生成当前遍历的代码文件的路径、当前遍历的代码文件的哈希表示、以及当前遍历的代码文件的标识，并将当前遍历的代码文件的路径、哈希表示、以及标识之间的关联关系写入第二索引分表。
110.若第一索引分表已记录当前遍历的代码文件的路径，则遍历第二依赖子图中的下一个代码文件。
111.本技术实施例中分别确定第一索引分表和第二索引分表，这样后续业务发生变化时只需要更新第二索引分表，相对减少处理设备的处理量。
112.处理设备在获得第一索引分表和第二索引分表之后，可以分别确定第一代码文件包的各个代码文件各自所属的类型。若代码文件属于指定文件夹，则确定该代码文件为第一类型，若代码文件不属于指定文件夹，则确定该代码文件为第二类型，并根据代码文件所属的类型，确定该代码文件的标识。
113.由于代码文件所属的类型不同，处理设备确定标识的方式也不同，下面分别进行介绍：
114.一，代码文件为第一类型。
115.考虑到第一类型的代码文件为业务变化时无需更改的代码文件，第一类型的代码文件的在第一代码文件包中的路径是固定的。因此，本技术实施例中，针对属于第一类型的代码文件，处理设备基于代码文件在第一代码文件包中的路径，从第一索引分表中，确定该路径对应的标识。其中，路径的生成方式请参照前文论述的内容，此处不再赘述。
116.二，代码文件为第二类型。
117.考虑到第二类型的代码文件为业务变化时需要更改的代码文件，不同业务的代码文件不同，但命名可能相同，则不同业务的代码文件在第一代码文件包中的路径可能是相同。因此，本技术实施例中，若第一代码文件包的各个代码文件中的任一代码文件为第二类型，则基于任一代码文件的哈希表示，从第二索引分表中，确定哈希表示对应的标识。其中，哈希表示的生成方式请参照前文论述的内容，此处不再赘述。
118.s230，基于各个代码文件，以及各个代码文件各自对应的标识，生成第二代码文件包。
119.处理设备获得了各个代码文件的标识之后，可以基于各个代码文件，以及各个代码文件各自对应的标识，生成第二代码文件包。第二代码文件包为运行平台可以运行的代码文件包，第二代码文件包例如为react native环境可以运行的文件包，具体例如javascript包。
120.具体的，处理设备根据各个代码文件，以及各个代码文件各自对应的标识，获得第三代码文件包，第三代码文件包中每一行代码的内容包括：当前代码文件的标识、当前代码文件的内容、以及当前代码文件依赖的下一个代码文件的标识。例如，第三代码文件包中第一行代码内容为“第一代码文件的标识 第一代码文件的内容 第一代码文件依赖的第二代码文件的标识”。处理设备基于第三代码文件包中标识出现的顺序，对各个代码文件进行拼装，获得第二代码文件包。
121.作为一种实施例，处理设备通过metro打包工具提供的应用程序接口(application programming interface，api)来实现代码文件处理方法，具体应用的是create moduleid factory和post process modules filter这两个api。由于metro打包工具和react native是一个公司出品的，metro打包工具的可靠性好，打包速度快，持续更新，支持react native各个版本。因此，本技术实施例充分利用了官方推荐的打包工具的特性，拥有良好的向上兼容性。
122.基于同一发明构思，本技术实施例提供一种代码文件处理装置，请参照图3，该装置相当于设置在前文论述的处理设备120中，该装置包括：
123.获取模块301，用于获取第一代码文件包，其中，第一代码文件包包括各个代码文件，第一代码文件用于实现相应的业务；
124.确定模块302，用于分别确定各个代码文件各自的标识，其中，若代码文件为第一类型，则基于代码文件在第一代码文件包中的路径，确定代码文件的标识，若代码文件为第二类型，基于代码文件的哈希表示，确定代码文件的标识，其中，哈希表示是采用预设的哈希算法对代码文件的内容进行计算得到的，第一类型是指业务发生变化时无需更改的代码文件，第二类型是指业务发生变化时需要更改的代码文件；
125.生成模块303，用于基于各个代码文件，以及各个代码文件各自对应的标识，生成第二代码文件包。
126.在一种可能的实施例中，确定模块302具体用于：
127.确定第一代码文件包的索引表，其中，索引表包括各个代码文件中每个代码文件的对应关系，对应关系为代码文件的路径、代码文件的哈希表示、以及代码文件的标识三者之间的关联关系；
128.基于索引表，分别确定各个代码文件各自的标识。
129.在一种可能的实施例中，索引表包括第一索引分表和第二索引分表，第一索引分表包括第一类型的代码文件的路径、第一类型的代码文件的哈希表示、以及第一类型的代码文件的标识之间的关联关系，第二索引分表包括第二类型的代码文件的路径、第二类型的代码文件的哈希表示、以及第二类型的代码文件的标识之间的关联关系；确定模块302具体用于：
130.若各个代码文件中的任一代码文件为第一类型，则基于任一代码文件的路径，从第一索引分表中，确定路径对应的标识；
131.若各个代码文件中的任一代码文件为第二类型，则基于任一代码文件的哈希表示，从第二索引分表中，确定哈希表示对应的标识。
132.在一种可能的实施例中，确定模块302具体用于：
133.基于第一代码文件包中的各个代码文件之间的依赖关系，获得依赖图；
134.遍历依赖图中的各个代码文件，直到遍历完依赖图中的各个代码文件，获得索引表，其中每次遍历包括以下过程：
135.若索引表中未记录当前遍历的代码文件的标识，则生成当前遍历的代码文件的路径、当前遍历的代码文件的哈希表示、以及当前遍历的代码文件的标识，并将当前遍历的代码文件的路径、当前遍历的代码文件的哈希表示、以及当前遍历的代码文件的标识之间的关联关系写入索引表；
136.若索引表已记录当前遍历的代码文件的标识，则遍历依赖图中的下一个代码文件。
137.在一种可能的实施例中，该装置包括遍历模块304，遍历模块304用于：
138.按照依赖图中的各个代码文件，在依赖图中出现的从先到后的顺序，依次遍历；
139.生成模块303具体用于：
140.基于当前遍历的代码文件所属的类型标识，以及当前遍历的代码文件在依赖图中的出现序号，生成当前遍历的代码文件的标识。
141.在一种可能的实施例中，第一代码文件包包括第一代码文件子包，第一代码文件子包包括第一类型的代码文件；确定模块具体用于：
142.基于第一代码文件子包，确定第一代码文件子包中的各个代码文件之间的依赖关系，获得第一依赖子图；
143.基于第一代码文件包，确定第一代码文件包中的各个代码文件之间的依赖关系，获得第二依赖子图；
144.基于第一依赖子图，确定第一索引分表；
145.基于第二依赖子图，以及第一索引分表，确定第二索引分表。
146.在一种可能的实施例中，确定模块302具体用于：
147.遍历第二依赖子图中的各个代码文件，直到遍历完第二依赖子图中的各个代码文件，获得第二索引分表，其中每次遍历包括以下过程：
148.若第一索引分表没有记录当前遍历的代码文件的标识，则生成当前遍历的代码文件的路径、当前遍历的代码文件的哈希表示、以及当前遍历的代码文件的标识，并将当前遍历的代码文件的路径、当前遍历的代码文件的哈希表示、以及当前遍历的代码文件的标识之间的关联关系写入第二索引分表；
149.若第一索引分表已记录当前遍历的代码文件的路径，则遍历第二依赖子图中的下一个代码文件。
150.基于同一发明构思，本技术实施例提供一种代码文件处理设备，该设备相当于前文论述的处理设备120，请参照图4，该设备包括：
151.至少一个处理器401，以及
152.与至少一个处理器401通信连接的存储器402；
153.其中，存储器402存储有可被至少一个处理器401执行的指令，至少一个处理器401
通过执行存储器402存储的指令实现如前文论述的数据处理方法。
154.处理器401可以是一个中央处理单元(central processing unit，cpu)，或者为数字处理单元、或为图像处理器等中的一种或多种组合。存储器402可以是易失性存储器(volatile memory)，例如随机存取存储器(random
‑
access memory，ram)；存储器402也可以是非易失性存储器(non
‑
volatile memory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，hdd)或固态硬盘(solid
‑
state drive，ssd)、或者存储器402是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器402可以是上述存储器的组合。
155.作为一种实施例，图4中的处理器401可以实现前文论述的代码文件处理方法，处理器401还可以实现前文图3论述的代码文件处理装置的功能。
156.基于同一发明构思，本技术实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，当计算机指令在计算机上运行时，使得计算机执行如前文论述的代码文件处理方法。
157.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
158.本技术是参照根据本技术的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
159.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
160.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
161.显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。