数据处理方法、装置、设备、存储介质及计算机程序产品与流程

1.本公开涉及计算机应用技术领域，尤其涉及web前端应用的数据处理技术领域。


背景技术：

2.针对mvvm(model-view-view model，模型-视图-视图模型)框架下的web前端应用，可以通过采用数据驱动的方法，将视图变化的细节进行隐藏，让开发者只需专注在数据变化相关的处理中，而不需要关心视图变化更新的细节。
3.相关技术中，对于web前端应用的代码数据，可以应用匹配框架的特定状态管理工具进行全局数据状态分析以及管理，以获取数据状态发生变化的数据，对应用发生的问题进行追踪定位，并对应用的数据从模型至视图变化过程进行正确性分析。


技术实现要素：

4.本公开提供了一种用于数据处理方法、装置、设备、存储介质及计算机程序产品。
5.根据本公开的一方面，提供了一种数据处理方法，包括：
6.确定待处理的目标数据，并确定所述目标数据的数据源；在所述目标数据与所述数据源之间进行插桩处理，以获取所述目标数据访问所述数据源过程中的全局数据；确定并输出所述全局数据中各数据之间的依赖关系。
7.根据本公开的另一方面，提供了一种数据处理装置，包括：
8.确定单元，用于确定待处理的目标数据，并确定所述目标数据的数据源；处理单元，用于在所述目标数据与所述数据源之间进行插桩处理，以获取所述目标数据访问所述数据源过程中的全局数据；输出单元，用于确定并输出所述全局数据中各数据之间的依赖关系。
9.根据本公开的又一方面，提供一种电子设备，包括：
10.至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，
11.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述涉及的方法。
12.根据本公开的又一方面，提供一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行上述涉及的方法。
13.根据本公开的又一方面，提供一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现上述涉及的方法。
14.通过本公开在目标数据与数据源之间进行插桩处理，进而能够获取到目标数据访问数据源过程中的全局数据，故可以提供一种效率更高的数据处理设备。
15.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
16.附图用于更好地理解本方案，不构成对本公开的限定。其中：
17.图1是根据本公开一示例性实施方式中示出的一种数据处理方法流程图；
18.图2示出了本公开一示例性实施方式中示出的全局数据生产消费关系示意图；
19.图3示出了根据本公开一示例性实施方式中示出的在生产者和消费者之间进行插桩的示意图；
20.图4是根据本公开一示例性实施方式中示出的一种数据处理方法流程图；
21.图5是根据本公开提供的一种数据处理装置的框图；
22.图6示出了可以用来实施本公开的实施例的示例电子设备600的示意性框图。
具体实施方式
23.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
24.本公开提供的数据处理方法，应用于对web前端应用的数据进行分析处理的场景中。例如可以应用于基于mvvm框架的现代web前端应用的数据分析处理中。
25.相关技术中，可以使用前端程序分析工具，对web前端应用的全局数据进行分析。目前各种对web前端应用全局数据进行分析的分析工具，程序分析能力主要集中在某一具体状态管理方案中，提供针对特定方案的数据变更追踪能力。此种数据变更追踪能力主要从单一数据状态的变化本身入手，通过动态运行方式对数据运行过程中涉及的数据变化关系进行分析，以用于程序的问题定位以及程序正确性分析。然而，此种方案仅关注数据变更的追踪，针对数据之间的依赖和消费特性的分析比较匮乏，尤其对于数据订阅、数据依赖关系相关的部分，缺乏分析能力，并不能完整解决业务中所遇到的问题，进而影响研发效率。换言之，相关技术中对全局数据的数据状态进行管理的方案中，仅支持数据变更的追踪，不涉及数据间的依赖关系分析，也不会涉及数据被哪些视图元素消费。并且，相关技术中数据状态管理的输出结果为线性结构的日志，不能体现组件之间输出结果之间的关联关系，即不能体现日志之间的交互关系，组件操作的串联关系等。
26.有鉴于此，本公开提供一种数据处理方法，在该方法中，通过插桩处理方式，获取具有消费特性的数据访问该数据的数据源过程中涉及的全局数据，并确定该全局数据中各数据之间的依赖关系进行输出，以实现对全局数据中各数据之间的依赖和消费特性进行分析。
27.图1是根据本公开一示例性实施方式中示出的一种数据处理方法流程图。参阅图1所示，该数据处理方法包括如下步骤s101至步骤s103。
28.在步骤s101中，确定待处理的目标数据，并确定目标数据的数据源。
29.在步骤s102中，在目标数据与数据源之间进行插桩处理，以获取目标数据访问数据源过程中的全局数据。
30.在步骤s103中，确定并输出全局数据中各数据之间的依赖关系。
31.本公开中涉及的数据可以是生产者消费者模式中的全局数据。其中，生产者消费
者模式中的数据包括生产者和消费者。全局数据的生产者只有一个，但通常会存在多个消费者。即，一个生产者可以对应多个消费者，但是一个消费者只能对应一个生产者。每个生产者以及每个消费者对应一个地址，占一个网络节点，属于预定性数据。图2示出了根据本公开一示例性实施方式中示出的全局数据生产消费关系示意图。参阅图2所示，生产者的数据，可以被消费者1和消费者2消费。本公开涉及的待处理的目标数据可以是生产者消费者模式中的消费者，例如可以是视图元素等具有消费特性的数据。该待处理的目标数据也可以称为是消费者。本公开中，目标数据的数据源可以生产者消费者模式中的生产者。
32.本公开中，在目标数据与数据源之间进行插桩处理可以理解为是在全局数据的源代码中加入插桩代码。通过该插桩代码可以获取到目标数据对数据源访问过程中的全局数据，进而可以获取全局数据之间具有数据依赖关系的内容信息。
33.本公开一示例性实施方式中，可以在数据源(生产者)和待处理目标数据(消费者)之间插入代理。图3示出了根据本公开一示例性实施方式中示出的在生产者和消费者之间进行插桩的示意图。参阅图3所示，在数据与消费者1和消费者2之间插入代理，其中，对于数据源的数据，消费者需要通过代理进行访问和修改，并保存至访问库中。其中，消费者不能直接接触到数据源中的真实数据，而是通过代理进行访问。
34.本公开中，通过代理获取任何消费者对数据的访问，可以获取目标数据访问数据源过程中的全局数据。本公开中，每当有消费者访问数据时，计算出当前消费者的所属组件路径、组件名称、当前数据的数据内容等信息，进而确定数据间的依赖关系。
35.本公开中，确定了全局数据中各数据之间的依赖关系，可以输出全局数据中各数据之间的依赖关系，以实现对数据间依赖关系的监测，体现各数据之间的关联关系。例如，本公开中可以将全局数据中各数据之间的依赖关系存储于数据访问库中。
36.本公开提供的数据处理方法，通过在待处理的目标数据与数据源之间进行插桩处理，可以通过该插桩获取目标数据访问数据源过程中的全局数据，并可以获取到全局数据中各数据之间具有依赖关系的内容信息，输出全局数据中各数据之间的依赖关系，可以实现对全局数据之间的依赖关系进行分析。
37.本公开中，通过在数据源的源代码中加入的插桩代码进行全局数据获取时，可以获取数据的声明、数据的更新、数据到组件的订阅方式等，以使获取到的全局数据的依赖关系，可以覆盖较为全面的全局数据的数据状态。
38.图4是根据本公开一示例性实施方式中示出的一种数据处理方法流程图。参阅图4所示，该数据处理方法包括如下步骤s201至步骤s203。
39.在步骤s201中，获取数据声明api(application programming interface,应用程序接口)返回的数据结构，以获取目标数据访问数据源的全局数据声明信息。
40.在步骤s202中，获取调用数据订阅api进行数据订阅的订阅信息，以获取目标数据访问数据源的全局数据订阅信息。
41.在步骤s203中，获取调用数据更新api进行数据更新的更新信息，以获取目标数据访问数据源的全局数据更新信息。
42.可以理解的是，本公开并不限定步骤s201、步骤s202以及步骤s203的执行先后顺序，能够获取到数据的声明、数据的更新、数据到组件的订阅方式等即可。
43.相关技术中，应用于不同的前端mvvm的视图层框架提供的api，虽然形式不同，但
在数据声明、更新、订阅的维度上，api提供的功能是相同的。例如，redux(react)框架中的createstore、recoil(react)框架中的atom、以及mobx(react/vue)框架中的class@observable，提供的功能都是数据声明api的功能。redux(react)框架中的dispatchaction、recoil(react)框架中的userecoilstate/getter、以及mobx(react/vue)框架中的property accessor，提供的功能都是数据更新api的功能。redux(react)框架中的useselector、recoil(react)框架中的userecoilstate/setter、以及mobx(react/vue)框架中的property setter，提供的功能都是数据订阅api的功能。故，本公开中，通过插桩方式获取数据声明api、数据更新api以及数据订阅api，可以获取到应用于不同前端mvvm框架的应用在运行时的相关信息，并覆盖较为全面的全局数据的数据状态。
44.一示例性实施方式中，本公开以redux框架为例对获取全局数据并确定全局数据之间的依赖关系进行说明。
45.本公开中，在需要获取全局数据声明的相关信息的情况下，基于上述实施例涉及的插桩方案，获取框架的数据声明api最终返回的数据结构。redux框架下，通过插桩的方式获取createstore返回的store对象，该对象持有web前端应用的全局数据，因此可以在插桩的代理中获取到所有全局数据的声明信息。
46.本公开中，在需要获取组件中对数据的订阅关系的情况下，基于上述实施例涉及的插桩方案，劫持组件中对数据订阅api的相关调用。redux框架下，在进行useselector调用时，通过插桩的方式，在代理的访问库中获取到selector函数对对象属性的访问信息，进而能够建立起全局数据状态和订阅状态组件之间的联系，并且能够清晰的确定组件内部具体访问的对象属性。
47.本公开中，在需要获取到数据的更新关系的情况下，基于上述实施例涉及的插桩方案，通过插桩的方式对更新api进行劫持。redux框架下，组件更新的全局数据都是通过调用dispatchaction方法派发action来更新全局数据的，故，通过插桩获取dispatchaction的调用，就能获取到任何组件对全局数据的改动，进而可以根据调用前后全局数据的变化，确定哪些组件触发了何种数据的更新，进而将整个过程中数据更新状态，清晰的记录下来。
48.本公开中通过插桩方式，对数据声明api、数据更新api以及数据订阅api进行劫持，进而可以构造应用运行期间完整的数据与组件之间的依赖关系，清晰的描述组件的更新过程，能够帮助开发者了解项目并进行技术决策。
49.本公开中涉及的数据依赖关系包括以下至少一项：数据状态、数据状态变化信息、以及数据与组件之间的订阅关系。
50.本公开中，基于插桩方式获取全局数据时，从代理中获取消费者对数据的访问，每当有消费者访问数据时，计算出当前消费者的所属组件路径、组件标识、当前数据的数据内容等信息。保存获取到的组件路径、组件标识以及数据内容等。进一步的，本公开中可以对比各次消费者访问数据对应的组件路径、组件标识、数据内容等信息，确定发生变化更新的内容，存储该变化更新的内容，以及产生该变化更新内容的原因，进而可以确定数据状态，数据状态发生的变化更新，以及数据组件间的订阅关系。
51.本公开中，在确定数据之间的依赖关系时，可以确定获取到的全局数据中各数据所属组件的组件标识，并确定该组件标识相关联的数据依赖关系，组装组件标识所关联的数据依赖关系，能够将各组件的数据状态进行串联，得出数据之间的依赖关系。
52.本公开中对组件标识所关联的数据依赖关系进行组装，实现对数据状态进行记录，并记录发生数据状态变化的原因，相对传统技术中线性结构日志方式的数据状态分析结果，可以明确组件之间输出结果之间的关联关系，更有利于对全局数据的数据状态进行订阅分析。
53.进一步的，本公开中基于输出的数据间的数据依赖关系，开发者可以利用全局数据订阅分析，方便的了解到全局数据被哪些组件消费，得到不同组件的依赖关系，针对具有相同依赖关系的组件可以进行封装，该封装的组件可以被复用。
54.本公开中，可以确定具有相同数据依赖关系的组件，封装该相同的数据依赖关系，相同的依赖关系包括以下至少一项：相同的组件路径、相同的组件标识、以及相同的数据内容。本公开中对相同数据依赖关系进行封装，能够便于开发者复用该封装的数据依赖关系，进行代码重构，提升代码复用度。
55.进一步的，本公开中基于输出的数据间的数据依赖关系，开发者可以利用全局数据订阅分析，基于记录的组件标识，以及组件标识之间的传播链路，确定相对稳定的传播链路对应的组件标识，作为可缓存的数据。
56.本公开中，可以确定具备缓存性的组件标识，基于该组件标识确定存在组件依赖的数据。其中，存在组件依赖的数据可以是组件路径相同的数据，也可以理解为是数据进行传播过程中，涉及到的传播链路相同的数据。
57.本公开中，对于存在组件依赖的数据，可以缓存该存在组件依赖的数据对应的组件标识，进而可以在后续再进行性能优化时，可以直接利用该缓存的组件标识，确定对应的组件路径，提升组件性能优化。换言之，通过本公开可以进行缓存快速定位到组件依赖的数据是否具备可缓存性，以及可缓存数据的传播链路，从而通过增加缓存的手段提升性能。
58.进一步的，本公开中基于输出的数据间的数据依赖关系，输出数据被组件订阅的订阅关系分布图。该订阅关系分布图表征数据与组件之间的订阅关系，构造了应用运行期间完整的数据-组件依赖关系图，能够清晰的描述组件的更新过程。故，通过本公开提供的订阅关系分布图可以确定对象属性以及对象之间的嵌套层次，基于嵌套层次可以判别模块划分是否准确，进而进行代码可维护性评判。
59.例如，通过数据被组件订阅的订阅关系分布图，开发者可以进一步观测到数据订阅的深度，进而分析当前模块的划分是否合理。比如，订阅关系分布图中涉及了在全局数据的评论区中进行了全局数据模型的编写。由于评论区只能订阅，不能进行划分，故开发者针对此种情况可以给出评论区进行模块划分不合理的结论。
60.基于相同的构思，本公开实施例还提供一种数据处理装置。
61.可以理解的是，本公开实施例提供的数据处理装置为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。结合本公开实施例中所公开的各示例的单元及算法步骤，本公开实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同的方法来实现所描述的功能，但是这种实现不应认为超出本公开实施例的技术方案的范围。
62.作为示例性的实施方式，图5是根据本公开提供的一种数据处理装置的框图。参阅图5所示，本公开提供的数据处理装置500包括确定单元501、处理单元502和输出单元503。
63.确定单元501，用于确定待处理的目标数据，并确定目标数据的数据源；处理单元502，用于在目标数据与数据源之间进行插桩处理，以获取目标数据访问数据源过程中的全局数据；输出单元503，用于确定并输出全局数据中各数据之间的依赖关系。
64.其中，处理单元502用于：获取数据声明应用程序接口返回的数据结构，以获取目标数据访问数据源的全局数据声明信息；获取调用数据订阅应用程序接口进行数据订阅的订阅信息，以获取目标数据访问数据源的全局数据订阅信息；获取调用数据更新应用程序接口进行数据更新的更新信息，以获取目标数据访问数据源的全局数据更新信息。
65.其中，输出单元503用于：确定全局数据中各数据所属组件的组件标识；确定与组件标识相关联的数据依赖关系，数据依赖关系包括以下至少一项：数据状态、数据状态变化信息、以及数据与组件之间的订阅关系；
66.组装组件标识所关联的数据依赖关系。
67.本公开一示例性实施方式中，输出单元503还用于：确定相同的数据依赖关系，相同的依赖关系包括以下至少一项：相同的组件路径、相同的组件标识、以及相同的数据内容；封装相同的数据依赖关系。
68.本公开一示例性实施方式中，输出单元503还用于：基于组件标识，确定存在组件依赖的数据，组件依赖的数据包括数据所属的组件路径相同；缓存存在组件依赖的数据对应的组件标识。
69.本公开一示例性实施方式中，输出单元503还用于：输出订阅关系分布图，订阅关系分布图用于表征数据与组件之间的订阅关系。
70.关于本公开上述涉及的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
71.本公开的技术方案中，所涉及的用户个人信息的获取，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。
72.根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
73.图6示出了可以用来实施本公开的实施例的示例电子设备600的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
74.如图6所示，设备600包括计算单元601，其可以根据存储在只读存储器(rom)602中的计算机程序或者从存储单元608加载到随机访问存储器(ram)603中的计算机程序，来执行各种适当的动作和处理。在ram603中，还可存储设备600操作所需的各种程序和数据。计算单元601、rom 602以及ram 603通过总线604彼此相连。输入/输出(i/o)接口605也连接至总线604。
75.设备600中的多个部件连接至i/o接口605，包括：输入单元606，例如键盘、鼠标等；输出单元607，例如各种类型的显示器、扬声器等；存储单元608，例如磁盘、光盘等；以及通信单元609，例如网卡、调制解调器、无线通信收发机等。通信单元609允许设备600通过诸如
因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
76.计算单元601可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元601的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元601执行上文所描述的各个方法和处理，例如数据处理方法。例如，在一些实施例中，数据处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元608。在一些实施例中，计算机程序的部分或者全部可以经由rom 602和/或通信单元609而被载入和/或安装到设备600上。当计算机程序加载到ram 603并由计算单元601执行时，可以执行上文描述的数据处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元601可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行数据处理方法。
77.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
78.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
79.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
80.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
81.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据
服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
82.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。
83.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
84.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。