一种子应用加载方法及装置与流程

本申请涉及应用程序维护领域，尤其涉及一种子应用加载方法及装置。

背景技术：

一个应用程序通常由多个子应用组成，所述子应用可以是通过跨平台移动应用开发框架(reactnative，rn)开发而成。通常这些子应用对应实现不同的业务功能，例如一款聊天应用程序中包含学习数学、乘车、购物等子应用，这些子应用由rn开发。用户在使用这些子应用时，需要通过向应用程序对应的服务器发送加载请求，获取资源数据，才可以对子应用进行加载，并展示出相应的用户界面。

根据子应用的类型不同，不同的子应用可以有多种不同的资源数据加载方式，例如，某些子应用会优先从子应用对应的本地缓存中获得资源数据，如果本地缓存中不存在相应的资源数据，再从子应用对应的服务器数据库中获得资源数据；或者某些子应用会每次都是从对应的服务器数据库中获得资源数据。一般，子应用采用何种加载方式都是由开发人员在子应用的设计阶段根据子应用的所要实现的功能设定的。

但是，随着子应用的更新或功能调整，以及用户使用子应用的习惯不同，很可能会导致子应用的资源数据加载方式，不符合用户实际使用习惯的情况。例如，如果该子应用的默认资源数据加载方式为优先从本地缓存获得资源数据，但由于用户使用习惯原因，需要经常更新该子应用的资源数据需，那么如果仍按照先从本地缓存中获得资源数据，在未获取到所需的资源数据是再向服务器数据库获取资源数据方式，就会增加子应用加载的耗时。

技术实现要素：

本申请提供了一种子应用加载方法及装置，以解决子应用的默认加载方式与子应用的实际使用情况不匹配的问题。

第一方面，本申请提供了一种子应用加载方法，应用于开发端，所述方法包括：

获取应用程序中各子应用的默认加载方式，所述默认加载方式为所述子应用在开发时所规定的加载方式；

确定待修改子应用，所述待修改子应用为默认加载方式与所述待修改子应用的资源数据更新频率不匹配的子应用；

确定所述待修改子应用的唯一标识和对应的目标加载方式，所述目标加载方式为与所述待修改子应用的资源数据更新频率相匹配的加载方式；

向所述应用程序的服务器发送修改指令，所述修改指令用于指示所述服务器修改所述待修改子应用的加载方式，得到与所述待修改子应用的资源数据更新频率匹配的目标加载方式，其中，所述修改指令包含所述待修改子应用的唯一标识和对应的目标加载方式。

在本发明实施例第一方面一种可能的实现方式中，所述确定待修改子应用的方法包括：

依次判断每一所述子应用在预设测算时间范围内的资源数据更新频率；

确定第一类子应用和第二类子应用，所述第一类子应用为资源数据更新频率大于预设频率阈值的子应用，所述第二类子应用为资源数据更新频率小于或者等于所述预设频率阈值的子应用；

确定待修改子应用，所述待修改子应用为采用第二类默认加载方式的所述第一类子应用，以及采用第一类默认加载方式的所述第二类子应用，其中，所述第一类默认加载方式为优先从所述服务器的数据库中获取资源数据，所述第二类默认加载方式为优先从所述服务器的本地缓存中获取资源数据，再从所述服务器的数据库中获取资源数据。

在本发明实施例第一方面一种可能的实现方式中，所述确定待修改子应用的唯一标识和对应的目标加载方式包括：

如果所述待修改子应用为采用第二类默认加载方式的所述第一类子应用，则所述待修改子应用的目标加载方式为所述第一类默认加载方式；

如果所述待修改子应用为采用第一类默认加载方式的所述第二类子应用，则所述待修改子应用的目标加载方式为所述第二类默认加载方式。

第二方面，本申请提供了一种子应用加载方法，应用于服务器，所述方法包括：

接收应用程序的开发端发送的修改指令，所述修改指令用于指示所述服务器修改所述待修改子应用的加载方式，得到与所述待修改子应用的资源数据更新频率匹配的目标加载方式，其中，所述修改指令包括所述应用程序中待修改子应用的唯一标识和对应的目标加载方式，所述待修改子应用为默认加载方式与所述待修改子应用的资源数据更新频率不匹配的子应用，所述目标加载方式为与所述待修改子应用的资源数据更新频率相匹配的加载方式；

在所述服务器的数据库中确定目标基础单元，所述基础单元为由所述应用程序的子应用的唯一标识和对应默认加载方式组成的数据对，所述目标基础单元为具有与所述待修改子应用的唯一标识相同的唯一标识的所述基础单元；

将每一所述目标基础单元中的默认加载方式修改为与所述子应用的资源数据更新频率匹配的所述目标加载方式，得到修改后数据库，所述修改后数据库用于为客户端提供与所述子应用对应的修改后的加载方式。

在本发明实施例第二方面一种可能的实现方式中，所述方法还包括：

接收所述客户端发送的资源加载方式获取请求；

按照所述资源加载方式获取请求，从所述数据库中获取所述应用程序中全部所述子应用的当前加载方式，得到资源加载方式信息，其中，如果所述子应用为所述待修改子应用，则所述子应用的当前加载方式为所述子应用的目标加载方式，如果所述子应用不是所述待修改子应用，则所述子应用的当前加载方式为所述子应用的默认加载方式；

向所述客户端发送所述资源加载方式信息，所述资源加载方式信息用于所述客户端确定当前所使用子应用的加载方式；

接收所述客户端发送的资源数据获取请求，所述资源数据获取请求与所述当前所使用子应用的加载方式相匹配；

向所述客户端发送资源数据。

第三方面，本申请提供了一种子应用加载方法，应用于客户端，所述方法包括：

向应用程序的服务器发送资源加载方式获取请求；

接收所述服务器发送的资源加载方式信息，所述资源加载方式信息包括所述应用程序中全部所述子应用的当前加载方式，其中，如果所述子应用为所述待修改子应用，则所述子应用的当前加载方式为所述子应用的目标加载方式，如果所述子应用不是所述待修改子应用，则所述子应用的当前加载方式为所述子应用的默认加载方式；

获取当前所使用子应用的唯一标识；

从所述资源加载方式信息中确定与所述当前所使用子应用的唯一标识相同的唯一标识所对应的当前加载方式，得到所述当前所使用子应用的加载方式；

按照所述当前所使用子应用的加载方式向所述服务器发送资源数据获取请求；

接收所述服务器发送的资源数据以加载所述当前所使用子应用。

第四方面，本申请提供了一种子应用加载装置，应用于开发端，所述装置包括：

默认加载方式获取模块，用于获取应用程序中各子应用的默认加载方式，所述默认加载方式为所述子应用在开发时所规定的加载方式；

待修改子应用确定模块，用于确定待修改子应用，所述待修改子应用为默认加载方式与所述待修改子应用的资源数据更新频率不匹配的子应用；

目标信息确定模块，用于确定所述待修改子应用的唯一标识和对应的目标加载方式，所述目标加载方式为与所述待修改子应用的资源数据更新频率相匹配的加载方式；

修改指令发送模块，用于向所述应用程序的服务器发送修改指令，所述修改指令用于指示所述服务器修改所述待修改子应用的加载方式，得到与所述子应用的资源数据更新频率匹配的目标加载方式，其中，所述修改指令包含所述待修改子应用的唯一标识和对应的目标加载方式。

在本发明实施例第四方面一种可能的实现方式中，所述待修改子应用确定模块包括：

判断模块，用于判断每一所述子应用在预设测算时间范围内的资源数据更新频率；

子应用类别确定模块，用于确定第一类子应用和第二类子应用，所述第一类子应用为资源数据更新频率大于预设频率阈值的子应用，所述第二类子应用为资源数据更新频率小于或者等于所述预设频率阈值的子应用；

确定模块，用于确定待修改子应用，所述待修改子应用为采用第二类默认加载方式的所述第一类子应用，以及采用第一类默认加载方式的所述第二类子应用，其中，所述第一类默认加载方式为优先从所述服务器的数据库中获取资源数据，所述第二类默认加载方式为优先从所述服务器的本地缓存中获取资源数据，再从所述服务器的数据库中获取资源数据。

在本发明实施例第四方面一种可能的实现方式中，所述目标信息确定模块包括：

第一确定模块，用于如果所述待修改子应用为采用第二类默认加载方式的所述第一类子应用，则所述待修改子应用的目标加载方式为所述第一类默认加载方式；

第二确定模块，用于如果所述待修改子应用为采用第一类默认加载方式的所述第二类子应用，则所述待修改子应用的目标加载方式为所述第二类默认加载方式。

第五方面，本申请提供了一种子应用加载装置，应用于服务器，所述装置包括：

修改指令接收模块，用于接收应用程序的开发端发送的修改指令，所述修改指令用于指示所述服务器修改所述待修改子应用的加载方式，得到与所述子应用的资源数据更新频率匹配的目标加载方式，其中，所述修改指令包括所述应用程序中待修改子应用的唯一标识和对应的目标加载方式，所述待修改子应用为默认加载方式与所述待修改子应用的资源数据更新频率不匹配的子应用，所述目标加载方式为与所述待修改子应用的资源数据更新频率相匹配的加载方式；

目标基础单元确定模块，用于在所述服务器的数据库中确定目标基础单元，所述基础单元为由所述应用程序的子应用的唯一标识和对应默认加载方式组成的数据对，所述目标基础单元为具有与所述待修改子应用的唯一标识相同的唯一标识的所述基础单元；

修改模块，用于将每一所述目标基础单元中的默认加载方式修改为与所述子应用的资源数据更新频率匹配的所述目标加载方式，得到修改后数据库，所述修改后数据库用于为客户端提供与所述待修改子应用对应的修改后的加载方式。

在本发明实施例第五方面一种可能的实现方式中，所述装置还包括：

第一请求接收模块，用于接收所述客户端发送的资源加载方式获取请求；

资源加载方式信息获取模块，用于按照所述资源加载方式获取请求，从所述数据库中获取所述应用程序中全部所述子应用的当前加载方式，得到资源加载方式信息，其中，如果所述子应用为所述待修改子应用，则所述子应用的当前加载方式为所述子应用的目标加载方式，如果所述子应用不是所述待修改子应用，则所述子应用的当前加载方式为所述子应用的默认加载方式；

信息发送模块，用于向所述客户端发送所述资源加载方式信息，所述资源加载方式信息用于所述客户端确定当前所使用子应用的加载方式；

第二请求接收模块，用于接收所述客户端发送的资源数据获取请求，所述资源数据获取请求与所述当前所使用子应用的加载方式相匹配；

资源数据发送模块，用于向所述客户端发送资源数据。

第六方面，本申请提供了一种子应用加载装置，应用于客户端，所述装置包括：

第一请求发送模块，用于向应用程序的服务器发送资源加载方式获取请求；

信息接收模块，用于接收所述服务器发送的资源加载方式信息，所述资源加载方式信息包括所述应用程序中全部所述子应用的当前加载方式，其中，如果所述子应用为所述待修改子应用，则所述子应用的当前加载方式为所述子应用的目标加载方式，如果所述子应用不是所述待修改子应用，则所述子应用的当前加载方式为所述子应用的默认加载方式；

唯一标识获取模块，用于获取当前所使用子应用的唯一标识；

加载方式确定模块，用于从所述资源加载方式信息中确定与所述当前所使用子应用的唯一标识相同的唯一标识所对应的当前加载方式，得到所述当前所使用子应用的加载方式；

第二请求发送模块，用于按照所述当前所使用子应用的加载方式向所述服务器发送资源数据获取请求；

资源数据接收模块，用于接收所述服务器发送的资源数据以加载所述当前所使用子应用。

第七方面，本申请提供了一种电子设备，应用于开发端，所述电子设备包括：

处理器，以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行任一所述的子应用加载方法。

第八方面，本申请提供了一种计算机可读存储介质，应用于开发端，其上存储有计算机程序，所述计算机程序被处理器执行时实现任一所述的子应用加载方法。

第九方面，本申请提供了一种电子设备，应用于服务器，所述电子设备包括：

处理器，以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行任一所述的子应用加载方法。

第十方面，本申请提供了一种计算机可读存储介质，应用于服务器，其上存储有计算机程序，所述计算机程序被处理器执行时实现任一所述的子应用加载方法。

第十一方面，本申请提供了一种电子设备，应用于客户端，所述电子设备包括：

处理器，以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行所述的子应用加载方法。

第十二方面，本申请提供了一种计算机可读存储介质，应用于客户端，其上存储有计算机程序，所述计算机程序被处理器执行时实现所述的子应用加载方法。

由以上技术可知，本申请实施例提供了一种子应用加载方法及装置，首先由开发人员在开发端将各个子应用的默认加载方式修改为与实际使用环境相匹配的加载方式，然后将各个子应用与相应的加载方式组成数据对并存储于服务器的数据库中。用户使用客户端时，可以从服务器的数据库中获得各个子应用的当前加载方式，并确定当前所使用的子应用与所述子应用的资源数据更新频率匹配的加载方式，并以此加载方式从服务器中获取资源数据。可见，本申请所提供的子应用加载方法，可以根据各个子应用的实际应用环境设定更加匹配的加载方式，以供用户使用，从而提高加载的效率和质量。

附图说明

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

图1为本申请实施例提供的一种应用在开发端的子应用加载方法的流程图；

图2为本申请实施例提供的一种应用在服务器的子应用加载方法的流程图；

图3为本申请实施例提供的一种应用在客户端的子应用加载方法的流程图；

图4为本申请实施例提供的一种确定待修改子应用的方法的流程图；

图5为本申请实施例提供的子应用加载装置实施例一的结构示意图；

图6为本申请实施例提供的子应用加载装置实施例二的结构示意图；

图7为本申请实施例提供的子应用加载装置实施例三的结构示意图；

图8为本申请实施例提供的子应用加载装置实施例四的结构示意图；

图9为本申请实施例提供的子应用加载装置实施例五的结构示意图；

图10为本申请实施例提供的子应用加载装置实施例六的结构示意图；

图11为本发明实施例提供的电子设备的硬件结构示意图；

图12为本发明实施例提供的电子设备的硬件结构示意图；

图13为本发明实施例提供的电子设备的硬件结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本申请实施例提供的一种应用在开发端的子应用加载方法的流程图，图2为本申请实施例提供的一种应用在服务器的子应用加载方法的流程图，图3为本申请实施例提供的一种应用在客户端的子应用加载方法的流程图，所述方法包括：

s1、获取应用程序中各子应用的默认加载方式，所述默认加载方式为所述子应用在开发时所规定的加载方式。

通常开发人员在初始设计应用程序的各个子应用时，会为各个子应用规定一个加载方式，即为默认加载方式，在开发人员不对子应用的加载方式做出修改的情况下，子应用的加载方式将一直采用默认加载方式。例如，应用程序a包括子应用a、子应用b和子应用c。其中，子应用a的默认加载方式为优先从本地缓存内获取资源数据，子应用b的默认加载方式为优先从服务器的数据库获取资源数据，子应用c的默认加载方式为优先从本地的缓存内获取资源数据。需要注意的是，子应用的默认加载方式可以采用多种方式，不仅限于本申请所提供给的默认加载方式，本实施例仅给出一种示例。

s2、确定待修改子应用，所述待修改子应用为默认加载方式与所述待修改子应用的资源数据更新频率不匹配的子应用。

由于子应用在实际使用过程中会出现不同的使用环境，因此，默认加载方式未必能够满足这些实际使用环境，其中，最为典型的使用环境即为子应用的资源数据更新频率，如果一个子应用处于开发初期，或者初始设计存在较多问题，或者所面对的受众的需求更新迭代较快，那么相应的该子应用需要不断地做出更新，即该子应用的资源数据需要较快地更新，此时，该子应用的资源数据更新频率就比较高；相反的，如果一个子应用已经开发使用较长时间，子应用的各项功能已经稳定，或者所面对地受众地需求变化较少，或者规律性提出，那么相应地该子应用的需求就会较少做出更新，即该子应用的资源数据更新频率就比较低。

通常，服务器的本地缓存中存储的资源数据来自于服务器的数据库，相当于一种历史记录数据，时效性比较差，但是从服务器的本地缓存中可以直接获取资源数据，无需借助额外的传输介质，速度较快；而服务器的数据库内存储的资源数据均为开发人员写入的最新数据，因此具有较好的时效性，但是，若要访问服务器的数据库需要通过网络，因此，网络的质量和安全性会严重影响从服务器的数据库获取资源数据的质量和效率。可见，资源数据的加载方式与资源数据的更新频率密切相关，而默认加载方式通常会忽略这种相关性，因此，需要对不适当的默认加载方式进行修改。

如图4所示，为本申请实施例提供的一种确定待修改子应用的方法的流程图，所述方法包括：

s201、判断每一所述子应用在预设测算时间范围内的资源数据更新频率；

s202、确定第一类子应用和第二类子应用，所述第一类子应用为资源数据更新频率大于预设频率阈值的子应用，所述第二类子应用为资源数据更新频率小于或者等于所述预设频率阈值的子应用；

s203、确定待修改子应用，所述待修改子应用为采用第二类默认加载方式的所述第一类子应用，以及采用第一类默认加载方式的所述第二类子应用，其中，所述第一类默认加载方式为优先从所述服务器的数据库中获取资源数据，所述第二类默认加载方式为优先从所述服务器的本地缓存中获取资源数据，再从所述服务器的数据库中获取资源数据。

判断每一个子应用在预设测算时间范围内的资源数据更新频率，例如预设测算时间范围为30天，子应用a的资源数据更新了3次，则子应用a的更新频率为3次/30天；子应用b的资源数据更新了1次，则子应用b的更新频率为1次/30天；子应用c的资源数据更新了1次，则子应用c的更新频率为1次/30天。如果预设频率阈值为2次/30天，则子应用a为第一类子应用，而自应用b和c为第二类自应用。由上文中给出的示例可知，子应用a和c采用第二类默认加载方式，子应用b采用第一类默认加载方式。由以上分析可知，子应用a和子应用b的默认加载方式与实际的资源数据更新频率并不相匹配，因此，子应用a和子应用b应被确定为待修改子应用。

s3、确定所述待修改子应用的唯一标识和对应的目标加载方式，所述目标加载方式为与所述待修改子应用的资源数据更新频率相匹配的加载方式。

在确定了待修改子应用之后，需要对待修改子应用的默认加载方式进行修改。

具体地，如果所述待修改子应用为采用第二类默认加载方式的所述第一类子应用，则所述待修改子应用的目标加载方式为所述第一类默认加载方式；如果所述待修改子应用为采用第一类默认加载方式的所述第二类子应用，则所述待修改子应用的目标加载方式为所述第二类默认加载方式。

即令资源数据更新频率较高的子应用采用第一类默认加载方式，令资源数据更新频率较低的子应用采用第二类默认加载方式。

s4、向所述应用程序的服务器发送修改指令，以使所述服务器修改所述待修改子应用的加载方式，得到目标加载方式，其中，所述修改指令包含所述待修改子应用的唯一标识和对应的目标加载方式。

在确定了各个待修改子应用的目标加载方式之后，需要向应用程序的服务器发送修改指令，以使服务器对待修改子应用的加载方式进行修改，当服务器内存储了全部子应用的加载方式之后，就可以供用户使用与子应用相匹配的加载方式加载资源数据。

通常，修改指令中会包含待修改子应用的唯一标识，该唯一标识用于代表该待修改子应用，且唯一标识与待修改子应用之间具有一一对应的关系，唯一标识可以为数字、字符、特殊符号等。同时，修改指令中还会包含待修改子应用的目标加载方式，通常，也可以利用数字、字符、特殊符号等来代表不同的加载方式，例如1-优先加载本地资源。

s5、接收应用程序的开发端发送的修改指令，所述修改指令包括所述应用程序中待修改子应用的唯一标识和对应的目标加载方式，所述待修改子应用为默认加载方式与所述待修改子应用的资源数据更新频率不匹配的子应用，所述目标加载方式为与所述待修改子应用的资源数据更新频率相匹配的加载方式。

s6、在所述服务器的数据库中确定目标基础单元，所述基础单元为由所述应用程序的子应用的唯一标识和对应默认加载方式组成的数据对，所述目标基础单元为具有与所述待修改子应用的唯一标识相同的唯一标识的所述基础单元。

通常，服务器的数据库中存储有若干基础单元，用于表示子应用的唯一标识和默认加载方式之间的对应关系，通过该基础单元，可以快速确定某一子应用的加载方式。当子应用的默认加载方式需要改变时，只需要改变相应的基础单元中的默认加载方式即可。

s7、依次将每一所述目标基础单元中的默认加载方式修改为对应的所述目标加载方式，得到修改后数据库，以供客户端请求加载方式使用。

将全部需要修改的目标基础单元进行修改，即可完成对数据库的修改，这样修改后的数据库可以为用户提供准确的子应用的当前加载方式。

s8、向应用程序的服务器发送资源加载方式获取请求。

用户在进入应用程序之后，通常会首先向服务器发送资源加载方式获取请求，以获取到全部子应用的加载方式，这样，无论用户接下来使用哪一个子应用，都可以快速确定该子应用对应的资源加载方式。

s9、接收所述客户端发送的资源加载方式获取请求。

s10、按照所述资源加载方式获取请求，从所述数据库中获取所述应用程序中全部所述子应用的当前加载方式，得到资源加载方式信息，其中，如果所述子应用为所述待修改子应用，则所述子应用的当前加载方式为所述子应用的目标加载方式，如果所述子应用不是所述待修改子应用，则所述子应用的当前加载方式为所述子应用的默认加载方式。

服务器在接收到客户端发送的资源加载方式获取请求之后，从数据库中获取该应用程序中全部子应用的当前加载方式，将这些子应用的当前加载方式汇总，可以得到资源加载方式信息。其中，子应用的当前加载方式由上文提供的步骤得到，此处将不再赘述。

s11、向所述客户端发送所述资源加载方式信息，以使所述客户端确定当前所使用子应用的加载方式。

s12、接收所述服务器发送的资源加载方式信息，所述资源加载方式信息包括所述应用程序中全部所述子应用的当前加载方式，其中，如果所述子应用为所述待修改子应用，则所述子应用的当前加载方式为所述子应用的目标加载方式，如果所述子应用不是所述待修改子应用，则所述子应用的当前加载方式为所述子应用的默认加载方式。

客户端接收到服务器发送的资源加载方式信息之后，可以获知应用程序中全部子应用的当前加载方式。

s13、获取当前所使用子应用的唯一标识。

此时，获取当前所使用子应用的唯一标识，作为后续确定加载方式的判断基础。例如，当前所使用子应用为子应用a，唯一标识为a。

s14、从所述资源加载方式信息中确定与所述当前所使用子应用的唯一标识相同的唯一标识所对应的当前加载方式，得到所述当前所使用子应用的加载方式。

由上文可知，对子应用a的默认加载方式进行了修改，此时，子应用a的当前加载方式为第一类默认加载方式，如果规定第一类默认加载方式的数字代码为2，则可以确定唯一标识为a的当前加载方式为2。

s15、按照所述当前所使用子应用的加载方式向所述服务器发送资源数据获取请求。

由上文可知，当前所使用子应用a的加载方式为2，即优先从服务器的数据库获取资源数据，那么客户端就需要按照这个加载方式，对应到服务器的数据库中获取资源数据，即需要向服务器的数据库发送资源数据获取请求。

s16、接收所述客户端发送的资源数据获取请求，所述资源数据获取请求与所述当前所使用子应用的加载方式相匹配。

服务器在接收到客户端发送的资源数据获取请求之后，需要根据资源数据获取请求收集相应的资源数据，接上例，服务器需要根据资源数据获取请求优先从数据库中收集资源数据。

s17、向所述客户端发送资源数据。

s18、接收所述服务器发送的资源数据以加载所述当前所使用子应用。

由上述技术方案可知，本申请所提供的子应用加载方法，可以根据各个子应用的实际应用环境设定更加匹配的加载方式，以供用户使用，从而提高加载的效率和质量。

图5为本申请实施例提供的子应用加载装置实施例一的结构示意图，所述装置包括：默认加载方式获取模块1，用于获取应用程序中各子应用的默认加载方式，所述默认加载方式为所述子应用在开发时所规定的加载方式；待修改子应用确定模块2，用于确定待修改子应用，所述待修改子应用为默认加载方式与所述待修改子应用的资源数据更新频率不匹配的子应用；目标信息确定模块3，用于确定所述待修改子应用的唯一标识和对应的目标加载方式，所述目标加载方式为与所述待修改子应用的资源数据更新频率相匹配的加载方式；修改指令发送模块4，用于向所述应用程序的服务器发送修改指令，所述修改指令用于指示所述服务器修改所述待修改子应用的加载方式，得到与所述待修改子应用的资源数据更新频率匹配的目标加载方式，其中，所述修改指令包含所述待修改子应用的唯一标识和对应的目标加载方式。

图6为本申请实施例提供的子应用加载装置实施例二的结构示意图，所述待修改子应用确定模块2包括：判断模块21，用于判断每一所述子应用在预设测算时间范围内的资源数据更新频率；子应用类别确定模块22，用于确定第一类子应用和第二类子应用，所述第一类子应用为资源数据更新频率大于预设频率阈值的子应用，所述第二类子应用为资源数据更新频率小于或者等于所述预设频率阈值的子应用；确定模块23，用于确定待修改子应用，所述待修改子应用为采用第二类默认加载方式的所述第一类子应用，以及采用第一类默认加载方式的所述第二类子应用，其中，所述第一类默认加载方式为优先从所述服务器的数据库中获取资源数据，所述第二类默认加载方式为优先从所述服务器的本地缓存中获取资源数据，再从所述服务器的数据库中获取资源数据。

图7为本申请实施例提供的子应用加载装置实施例三的结构示意图，所述目标信息确定模块3包括：第一确定模块31，用于如果所述待修改子应用为采用第二类默认加载方式的所述第一类子应用，则所述待修改子应用的目标加载方式为所述第一类默认加载方式；第二确定模块32，用于如果所述待修改子应用为采用第一类默认加载方式的所述第二类子应用，则所述待修改子应用的目标加载方式为所述第二类默认加载方式。

图8为本申请实施例提供的子应用加载装置实施例四的结构示意图，所述装置包括：修改指令接收模块5，用于接收应用程序的开发端发送的修改指令，所述修改指令用于指示所述服务器修改所述待修改子应用的加载方式，得到与所述子应用的资源数据更新频率匹配的目标加载方式，其中，所述修改指令包括所述应用程序中待修改子应用的唯一标识和对应的目标加载方式，所述待修改子应用为默认加载方式与所述待修改子应用的资源数据更新频率不匹配的子应用，所述目标加载方式为与所述待修改子应用的资源数据更新频率相匹配的加载方式；目标基础单元确定模块6，用于在所述服务器的数据库中确定目标基础单元，所述基础单元为由所述应用程序的子应用的唯一标识和对应默认加载方式组成的数据对，所述目标基础单元为具有与所述待修改子应用的唯一标识相同的唯一标识的所述基础单元；修改模块7，用于将每一所述目标基础单元中的默认加载方式修改为与所述子应用的资源数据更新频率匹配的所述目标加载方式，得到修改后数据库，所述修改后数据库用于为客户端提供与所述子应用对应的修改后的加载方式。

图9为本申请实施例提供的子应用加载装置实施例五的结构示意图，所述装置还包括：第一请求接收模块8，用于接收所述客户端发送的资源加载方式获取请求；资源加载方式信息获取模块9，用于按照所述资源加载方式获取请求，从所述数据库中获取所述应用程序中全部所述子应用的当前加载方式，得到资源加载方式信息，其中，如果所述子应用为所述待修改子应用，则所述子应用的当前加载方式为所述子应用的目标加载方式，如果所述子应用不是所述待修改子应用，则所述子应用的当前加载方式为所述子应用的默认加载方式；信息发送模块10，用于向所述客户端发送所述资源加载方式信息，所述资源加载方式信息用于所述客户端确定当前所使用子应用的加载方式；第二请求接收模块11，用于接收所述客户端发送的资源数据获取请求，所述资源数据获取请求与所述当前所使用子应用的加载方式相匹配；资源数据发送模块12，用于向所述客户端发送资源数据。

图10为本申请实施例提供的子应用加载装置实施例六的结构示意图，所述装置包括：第一请求发送模块13，用于向应用程序的服务器发送资源加载方式获取请求；信息接收模块14，用于接收所述服务器发送的资源加载方式信息，所述资源加载方式信息包括所述应用程序中全部所述子应用的当前加载方式，其中，如果所述子应用为所述待修改子应用，则所述子应用的当前加载方式为所述子应用的目标加载方式，如果所述子应用不是所述待修改子应用，则所述子应用的当前加载方式为所述子应用的默认加载方式；唯一标识获取模块15，用于获取当前所使用子应用的唯一标识；加载方式确定模块16，用于从所述资源加载方式信息中确定与所述当前所使用子应用的唯一标识相同的唯一标识所对应的当前加载方式，得到所述当前所使用子应用的加载方式；第二请求发送模块17，用于按照所述当前所使用子应用的加载方式向所述服务器发送资源数据获取请求；资源数据接收模块18，用于接收所述服务器发送的资源数据以加载所述当前所使用子应用。

图11为本发明实施例提供的电子设备的硬件结构示意图，应用于开发端，该电子设备包括：存储器101和处理器102；

存储器101，用于存储计算机程序；

处理器102，用于执行存储器存储的计算机程序，以实现上述实施例中的房屋数据展示方法。具体可以参见前述方法实施例中的相关描述。

可选地，存储器101既可以是独立的，也可以跟处理器102集成在一起。

当所述存储器101是独立于处理器102之外的器件时，所述电子设备还可以包括：

总线103，用于连接所述存储器101和处理器102。

图12为本发明实施例提供的电子设备的硬件结构示意图，应用于服务器，该电子设备包括：存储器104和处理器105；

存储器104，用于存储计算机程序；

处理器105，用于执行存储器存储的计算机程序，以实现上述实施例中的子应用加载方法。具体可以参见前述方法实施例中的相关描述。

可选地，存储器104既可以是独立的，也可以跟处理器105集成在一起。

当所述存储器104是独立于处理器105之外的器件时，所述电子设备还可以包括：

总线106，用于连接所述存储器104和处理器105。

图13为本发明实施例提供的电子设备的硬件结构示意图，应用于客户端，该电子设备包括：存储器107和处理器108；

存储器107，用于存储计算机程序；

处理器108，用于执行存储器存储的计算机程序，以实现上述实施例中的子应用加载方法。具体可以参见前述方法实施例中的相关描述。

可选地，存储器107既可以是独立的，也可以跟处理器108集成在一起。

当所述存储器107是独立于处理器108之外的器件时，所述电子设备还可以包括：

总线109，用于连接所述存储器107和处理器108。

本发明实施例提供的电子设备可用于执行上述实施例中任一所示的子应用加载方法，其实现方式和技术效果类似，本发明实施例此处不再赘述。

本发明实施例还提供一种可读存储介质，可读存储介质中存储有计算机程序，当消息发送的装置的至少一个处理器执行该计算机程序时，消息发送的装置执行上述实施例任一所述的子应用加载方法。

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

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