CN112905255A - 信息处理方法、装置及电子设备 - Google Patents

Abstract

本申请实施例公开了信息处理方法、装置及电子设备，所述方法包括：启动应用程序时，获取应用程序关联的通用加载脚本；在利用所述通用加载脚本加载执行多个加载任务时，记录所述加载任务对应的加载信息；在调用所述加载任务对应的加载对象时，记录所述任务加载对象的调用信息；根据所述加载信息和调用信息，确定目标任务加载对象；修改所述通用加载脚本中对应所述目标任务加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。通过本申请实施例，能够更方便、合理地优化加载对象的加载逻辑。

Description

信息处理方法、装置及电子设备

技术领域

本申请涉及信息处理技术领域，特别是涉及信息处理方法、装置及电子设备。

背景技术

随着移动端应用程序功能的不断强大，在运行过程中通常需要加载很多对象，其中包括具体的功能模块中所需用到的类库类，例如，具体可以包括用于对应用程序进行初始化配置的类库，网络库，图片库，weex(使用Web开发体验来开发高性能原生应用的框架)SDK(Software Development Kit，软件开发工具包)等基础库，等等。这些类库通常需要先进行加载，然后才能被具体的功能模块(或称业务方)使用。

例如，应用程序中的某页面需要使用weex技术，则在展示该页面之前需要首先加载weex SDK库，这样才能够保证该页面的正常渲染。而如果在接收到具体的页面访问请求后再对weex SDK库进行加载，则给用户带来的感受会是，在点击访问某页面之后，需要等待一段时间，该页面才会展示出来。

又如，某页面需要在H5与Native之间进行很多的交互，则可以使用WindVane技术，对于使用了WindVane技术的页面，在页面被访问之前，也需要预先加载WindVane的相关类库，以避免影响页面展示的流畅度。另外，还有一些提供弹窗功能的类库，如果不预先加载，则可能会影响弹窗功能的实现，提供性能监控功能的类库，如果不预先加载，则可能会影响对终端设备性能监控的实现，等等。

为了提高具体业务运行时的流畅度，避免在应用启动之后，在运行具体业务过程中出现卡顿等现象，通常可以在应用启动的过程中就对这些类库进行加载，尤其是一些三方库和底层中间件等。但是，一个应用中需要使用的类库数量可能会比较多，可能在70+的级别，这就使得应用程序的启动耗时被拉长。从用户体验角度而言，从在桌面等处点击某应用的图标开始，到该应用启动完成进入到可以交互的状态，这期间可能需要经历2-3秒的启动过程，对于一些自身性能比较有限的移动终端设备，这个时间可能会更长，甚至可能到6-7秒。这种耗时主要就是由于对各种类库进行加载所带来的。

为了缩短应用启动过程的耗时，可以将部分类库放到应用启动完成后再进行加载。但是，一方面，现有技术中的类库加载逻辑都是以硬编码的方式写在应用的代码中，如果要将部分类库放到应用启动后再进行加载，则需要修改应用的类库启动逻辑，而这将会严重依赖于应用的版本发布。另一方面，具体将哪些类库放到应用启动完成后再加载，依赖于人工对业务的理解以及判断，修改后的启动逻辑可能不是对每个用户都适用，以至于仍然可能会造成业务运行过程中的卡顿等现象。例如，某个类库被放到应用启动完成8S左右加载，但是，由于应用完成启动之后已经进入到可交互状态，因此，可能存在某用户在应用启动后5S甚至更早时便访问了需要用到该类库的业务，此时，就需要在收到用户的访问请求后再进行该类库的加载，这无疑会造成用户的等待。

因此，如何更方便、合理地优化加载对象的加载逻辑，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了信息处理方法、装置及电子设备，能够更方便、合理地优化加载对象的加载逻辑。

本申请提供了如下方案：

一种信息处理方法，包括：

启动应用程序时，获取应用程序关联的通用加载脚本；

在利用所述通用加载脚本执行多个加载任务时，记录所述加载任务对应的加载信息；

在调用所述加载任务对应的加载对象时，记录所述加载对象的调用信息；

根据所述加载信息和调用信息，确定目标加载对象；

修改所述通用加载脚本中对应所述目标加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。

一种数据处理方法，包括：

对多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息进行采集，以利用所采集到的信息对时间预测模型进行训练；

将训练完成的时间预测模型投放到客户端，以通过记录单个用户在使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息，以及所述时间预测模型，对所述用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测，所预测的结果用于确定可延迟到应用程序启动完成后加载的加载对象，并生成针对所述单个用户的专用加载脚本。

一种信息处理方法，包括：

启动应用程序时，获取应用程序关联的加载脚本，所述加载脚本中包括多个加载对象的加载规则信息；

利用所述加载脚本执行对所述多个加载对象的加载任务。

一种信息处理方法，包括：

接收到由目标用户发起的启动应用程序任务后，获取应用程序关联的针对所述目标用户的专用加载脚本，所述专用加载脚本中包括：根据所述目标用户在历史使用所述应用程序过程中获得的对多个加载对的加载信息以及调用信息，生成的多个加载对象的加载规则信息；

利用所述专用加载脚本执行对所述多个加载对象的加载任务。

一种信息处理装置，包括：

通用加载脚本获取单元，用于启动应用程序时，获取应用程序关联的通用加载脚本；

加载信息记录单元，用于在利用所述通用加载脚本执行多个加载任务时，记录所述加载任务对应的加载信息；

调用信息记录单元，用于在调用所述加载任务对应的加载对象时，记录所述加载对象的调用信息；

目标加载对象确定单元，用于根据所述加载信息和调用信息，确定目标加载对象；

专用加载脚本生成单元，用于修改所述通用加载脚本中对应所述目标加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。

一种数据处理装置，包括：

信息采集单元，用于对多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息进行采集，以利用所采集到的信息对时间预测模型进行训练；

模型投放单元，用于将训练完成的时间预测模型投放到客户端，以通过记录单个用户在使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息，以及所述时间预测模型，对所述用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测，所预测的结果用于确定可延迟到应用程序启动完成后加载的加载对象，并生成针对所述单个用户的专用加载脚本。

一种信息处理装置，包括：

加载脚本获取单元，用于启动应用程序时，获取应用程序关联的加载脚本，所述加载脚本中包括多个加载对象的加载规则信息；

加载任务执行单元，用于利用所述加载脚本执行对所述多个加载对象的加载任务。

一种信息处理装置，包括：

专用加载脚本获取单元，用于接收到由目标用户发起的启动应用程序任务后，获取应用程序关联的针对所述目标用户的专用加载脚本，所述专用加载脚本中包括：根据所述目标用户在历史使用所述应用程序过程中获得的对多个加载对的加载信息以及调用信息，生成的多个加载对象的加载规则信息；

加载任务执行单元，用于利用所述专用加载脚本执行对所述多个加载对象的加载任务。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

启动应用程序时，获取应用程序关联的通用加载脚本；

在利用所述通用加载脚本执行多个加载任务时，记录所述加载任务对应的加载信息；

在调用所述加载任务对应的加载对象时，记录所述加载对象的调用信息；

根据所述加载信息和调用信息，确定目标加载对象；

修改所述通用加载脚本中对应所述目标加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

对多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息进行采集，以利用所采集到的信息对时间预测模型进行训练；

将训练完成的时间预测模型投放到客户端，以通过记录单个用户在使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息，以及所述时间预测模型，对所述用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测，所预测的结果用于确定可延迟到应用程序启动完成后加载的加载对象，并生成针对所述单个用户的专用加载脚本。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

启动应用程序时，获取应用程序关联的加载脚本，所述加载脚本中包括多个加载对象的加载规则信息；

利用所述加载脚本执行对所述多个加载对象的加载任务。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收到由目标用户发起的启动应用程序任务后，获取应用程序关联的针对所述目标用户的专用加载脚本，所述专用加载脚本中包括：根据所述目标用户在历史使用所述应用程序过程中获得的对多个加载对的加载信息以及调用信息，生成的多个加载对象的加载规则信息；

利用所述专用加载脚本执行对所述多个加载对象的加载任务。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，首先可以通过脚本的方式来实现加载对象的加载逻辑控制，使得对加载对象加载逻辑的修改不再依赖于应用程序的版本更新。另外，在此基础上，还可以通过采集具体用户在使用应用程序过程中，对加载对象进行加载时的加载信息以及对加载对象进行调用时的调用信息作为用户特征，来确定就该用户而言，可以进行加载规则修改的目标加载对象。然后，可以通过对脚本的调整，将上述符合条件的目标加载对象的加载规则进行修改，以此生成针对具体用户的专用加载脚本。也就是说，具体加载对象的加载规则，是根据用户实际体现出的特征来进行的，因此可以实现更合理的优化。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的第一系统架构的示意图；

图2是本申请实施例提供的第二系统架构的示意图；

图3是本申请实施例提供的第一方法的流程图；

图4是本申请实施例提供的第二方法的流程图；

图5是本申请实施例提供的第三方法的流程图；

图6是本申请实施例提供的第四方法的流程图；

图7是本申请实施例提供的第一装置的示意图；

图8是本申请实施例提供的第二装置的示意图；

图9是本申请实施例提供的第三装置的示意图；

图10是本申请实施例提供的第四装置的示意图；

图11是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，首先，为了能够更方便的对加载对象的加载逻辑进行修改，而不需要依赖应用程序的版本发布，可以将加载对象的加载逻辑抽象为脚本，而不再以硬编码的方式写在应用程序的代码中。这样，在可以利用脚本实现对加载对象的加载处理。这种脚本相对于应用程序的代码而言可以是独立存在的，这样，如果需要对加载对象的加载规则进行修改，例如，改变一些加载对象的加载时机等，只需要对脚本进行修改即可，而不需要修改应用程序的代码，也不需要应用程序发布新的版本。

另外，这种利用脚本进行加载对象加载的方式，还可以实现针对不同用户的个性化编排，生成针对不同用户的专用加载脚本。并且，在生成专用加载脚本时，还可以根据用户在具体使用应用程序过程中体现出来的特征进行生成。也就是说，对于不同的用户而言，在使用同一应用程序过程中，可能会具有一些不同的习惯，这些习惯就可以包括：在使用应用程序内具体的业务/功能时的顺序。例如，某用户A在使用某商品对象信息服务系统的应用程序时，习惯于通过搜索框输入具体的关键词，进入到搜索结果页面进行浏览，然后再在该页面中选择具体商品对象进行详情浏览；而用户B在使用上述应用程序时，则习惯于浏览首页中的“猜你喜欢”等版块的内容，对其中感兴趣的商品对象进行点击查看详情信息；另一用户C则习惯于先到“签到”页面进行签到，等等。不同的业务/功能对应的页面可能需要使用不同的加载对象(例如，类库等)，因此，对于不同用户而言，其浏览习惯的不同，会导致不同的加载对象首次被调用的时间可能会不同，并且可能会体现出一些规律性的特征。例如，基于某用户对应用程序的使用习惯，使得某加载对象首次被调用的时间总是比较晚，等等。因此，基于上述特征，可以对脚本中的加载对象的加载规则进行调整，例如，将上述总是比较晚被调用的加载对象延迟到应用程序启动完成之后再进行加载。

通过这种方式，由于具体的加载脚本是根据用户的使用特征而生成的专用的脚本，因此，可以实现针对具体用户的个性化加载，更符合用户的使用需求，在体现出个性化的同时，可以避免由于加载逻辑调整不合理导致的应用程序正式运行期间出现的不够流畅等问题。在可选的方式下，由于具体生成专用加载脚本的过程中，可以将一些加载对象延迟到应用程序启动完成之后再进行加载，因此，使得需要在应用程序启动完成之前加载的加载对象数量减少，因此，可以减少应用程序的启动耗时。

具体实现时，从系统架构角度而言，本申请实施例主要可以涉及到具体应用程序的客户端，另外，在一些实现方式下，还可以涉及到服务端。其中，应用程序的客户端通常会关联有加载框架代码，所谓的加载框架代码是在应用程序客户端中预先实现的，当用户通过点击图标等方式启动一个应用程序时，该加载框架会自动被启动，在应用程序启动完成之前，便可以执行具体的加载对象加载逻辑。在本申请实施例中，在具体的应用程序版本发布之前，可以对应用程序的加载框架代码进行修改，使其不再从应用程序的代码中读取具体的加载对象加载逻辑，而是首先读取应用程序关联的加载脚本，然后利用该加载脚本进行加载对象的加载。其中，在初始状态下，该加载脚本可以是由服务端提供的通用加载脚本，其中可以包括多个加载对象的加载规则信息，包括加载时机、顺序等。

另外，在本申请实施例中，为了获取具体用户在使用应用程序过程中的特征信息，还可以对具体加载对象的加载信息进行记录，另外，在具体应用程序启动完成后，与用户进行具体交互的过程中，还可以加载对象的调用信息进行记录，这些信息都可以用来确定用户特征，例如，具体可以用加载对象的加载时间到加载对象首次调用时间之间的时间间隔来表示，等等。

在一种实现方式下，如图1所示，加载框架还可以将采集到的上述用户特征信息提交到服务端，服务端可以在收集到大量用户在多次使用应用程序过程中体现出的特征信息之后，进行时间预测模型的训练。该模型主要用于，在已知一个用户在某次使用应用程序过程中，从某加载对象加载到首次调用该加载对象的时间间隔后，对该用户下次再使用该应用程序时，从该加载对象加载到首次调用该加载对象的时间间隔进行预测。

之后，如图2所示，在模型训练完成后，服务端可以将具体的模型下发到具体用户的客户端，这样，客户端中采集到具体用户关联的在上述时间间隔方面的特征信息后，可以输入到该时间预测模型中(为了提高效率，该模型可以在客户端关联的端计算平台中运行)，对该用户下次使用应用程序时，从某加载对象加载到首次调用该加载对象的时间间隔进行预测，根据预测结果，来确定该加载对象是否可以延迟到应用程序启动完成之后再进行加载。

在完成预测之后，则可以对通用加载脚本中的加载对象加载规则信息进行修改，生成针对当前用户的专用加载脚本(其中，对脚本进行调整的逻辑也可以在加载框架代码中实现)。该专用加载脚本可以保存在客户端本地，后续再启动该应用程序时，可以从本地读取该专用加载脚本，利用该专用加载脚本进行加载对象加载。当然，在实际应用中，具体在对加载对象加载规则进行调整时，还可以考虑终端设备的性能特征，例如，对于一些性能比较差的终端设备，可以将更多的加载对象延迟到应用程序启动完成之后再加载，而对于性能比较高的终端设备，则被延迟的数量可以比较少，等等。

下面对本申请实施例提供的具体技术方案进行详细介绍。

实施例一

首先，该实施例一从前文所述的客户端的加载框架的角度，提供了一种信息处理方法，参见图3，包括：

S301：启动应用程序时，获取应用程序关联的通用加载脚本。

其中，在初始状态下，由于尚未获得具体用户在加载对象使用时间方面的特征，也即，尚未生成针对具体用户的专用加载脚本，因此，可以提供多用户共用的通用加载脚本，该通用加载脚本可以保存在服务端，或者，也可以打包在客户端的安装包中，使得客户端本地也可以保存该通用加载脚本。在这种状态下，加载框架可以从服务端或客户端本地读取具体的通用加载脚本，然后，利用该通用加载脚本执行对具体加载对象的加载。总之，具体实现时，可以在尚未生成针对所述当前用户的专用加载脚本的情况下，从服务端下载所述应用程序关联的通用加载脚本，而在后续生成了针对当前用户的专用加载脚本之后，则可以直接利用该当前用户对应的专用加载脚本来执行具体的加载任务。

其中，通用加载脚本中主要可以包括多个加载对象的加载时机信息，例如，所述加载时机信息具体可以包括在所述应用程序启动完成前加载，当然，还可能包括部分能够在应用程序启动完成之后再进行加载的加载对象。

在具体生成上述通用加载脚本时，根据具体加载对象的不同，可以有不同的生成方式。例如，如果具体的加载对象是应用程序关联的功能模块中所需引用的类库，则可以将应用程序关联的多个类库按照依赖关系进行编排，另外还可以按照有向无环图结构构建好，之后，再将原来需要硬编码的类库加载逻辑抽象成类库加载脚本。其中，具体的脚本中，可以将一些必要的类库放在应用程序启动前进行加载，其他的类库则放在应用程序启动完成之后的IDLE阶段(闲时)加载。

而另一种应用场景下，具体的加载对象除了可以是类库，还可以包括应用程序关联的一些轻应用。其中，所谓的轻应用具体可以是指通过所述应用程序进行用户的导入与激活后提供相应服务的应用，对于这种轻应用而言，在用户具体使用之前，也可以提前进行加载，以提升用户使用轻应用时的响应速度。在这种情况下，具体的加载脚本中也可以包括对多个轻应用的加载规则信息，包括轻应用的加载时机、顺序等。当然，由于不同的轻应用之间通常是相互独立的，彼此之间通常不存在依赖关系，因此，在具体确定加载时机、顺序时，可以通过预先获得多个用户对各种轻应用的历史使用行为信息等来确定。例如，某应用程序关联的轻应用包括A、B、C、D等等，而该应用程序的用户在使用该应用程序的过程中，大部分用户都会先使用到轻应用B，其次是D，而轻应用A、C则很少被用到，或者比较晚才会被用到。则在具体的通用加载脚本中，可以将轻应用B、D在应用程序启动完成之前进行加载，而A、C则在应用程序启动完成之后再进行加载，等等。

当然，在上述通用的脚本中，相对于后续针对具体用户生成的专用加载脚本而言，在应用程序启动前进行加载的加载对象数量是相对比较多的。这样做的目的是，在用户特征未知的情况下，为了能够满足大多数用户的需求，可以将更多的加载对象都放在应用程序启动完成之前来进行加载，优先满足避免应用程序运行过程出现卡顿等现象的条件。

例如，在通用加载脚本中，在应用程序启动完成之前需要加载的加载对象主要可以包括两类。一类是占用主线程，需要卡住的一直串行执行的加载对象，并且其他加载对象通常需要依赖于这些加载对象，因此，这些加载对象可以优先加载；比如，与应用程序初始化的配置(包括应用程序的版本名字等基础信息)相关的加载对象，网络库，等等。第二类是一些可以并行执行的互相之间不依赖的加载对象，比如网络库的设置，图片库，weex SDK等基础库。而其他的加载对象，例如，店铺搜索、促销活动等页面中需要用到的加载对象，由于与首页不相关，大部分用户会比较晚用到，因此，可以在应用程序启动之后闲时加载。

S302：在利用所述通用加载脚本执行多个加载任务时，记录所述加载任务对应的加载信息。

在获得具体的通用加载脚本后，在应用程序启动完成之前就可以利用该通用加载脚本对多个加载对象进行加载，当然，还有一些加载对象可以在应用程序启动之后加载，一般情况下，可以在应用程序启动完成后一段时间内(例如，10S等)完成加载，以避免对用户的使用造成过多的影响。

在本申请实施例中，为了统计具体用户在使用加载对象方面的特征，还可以在加载加载对象时，对加载对象的加载信息进行记录。具体实现时，具体的加载信息可以有多种，例如，在一种具体的实现方式下，具体可以是指加载时间信息。也即，可以在启动所述应用程序的过程中，利用所述通用加载脚本对所述应用程序关联的多个加载对象进行加载，并对所述加载对象的加载时间信息进行记录。在这种情况下，具体在获得加载信息时，可以在具体的脚本中加入埋点代码，使得具体的加载对象被加载时可以进行埋点，以此获得加载对象的加载时间信息。

S303：在调用所述加载任务对应的加载对象时，记录所述加载对象的调用信息；

在应用程序完成启动之后，也即应用程序的首页进入可交互的状态，用户可以通过点击、滑动等方式访问具体的页面内容。而在这种交互过程中，具体的加载对象就可能会被调用，相应的，可以记录具体加载对象被调用时的调用信息。例如，在用户访问某个页面时，该页面中用到了Weex技术，则该页面就需要使用WeexSDK的相关类库，等等。当然，多个页面可能都用到了相同的加载对象，在本申请的可选实施例中，可以对某加载对象首次被调用的时间进行记录。也即，在一种具体的实施方式下，具体对加载对象被调用时的调用信息进行记录可以是指，在所述应用程序启动完成后，对所述加载对象的首次调用时间信息进行记录。

具体的，为了达到上述目的，在一种实现方式下，可以使用AOP(Aspect OrientedProgramming，面向切面编程)技术在每个加载对象第一次被使用的地方进行插桩埋点，以此记录在一次访问过程中，加载对象首次被使用的时间信息。其中，所谓的AOP技术，是可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。之所以使用该技术进行埋点，是因为，为了实现埋点，需要在应用程序代码中写入埋点代码，但是，具体的应用程序可能包括非常多的功能模块，而这些功能模块的源代码通常由多个不同的业务方来实现，因此，比较难以获得全部的源代码。另外，还有一些功能中可能使用的是第三方封装好的库，无法实现对这种库的源代码的修改。因此，针对这种情况，考虑到在对应用程序进行打包时，需要将源代码转成class字节码，因此，可以在打包过程中获得转换得到的字节码，然后，利用AOP技术，将需要埋点的代码加到字节码中，以此实现埋点代码的写入。当然，对于一些比较小型的应用程序，在可获得全部的源代码的情况下，也可以采用普通的方式实现埋点代码的写入。

S304：根据所述加载信息和调用信息，确定目标加载对象；。

通过前述步骤S302以及S303，可以获得当前用户在使用具体应用程序过程中，加载对象的加载信息，以及调用信息，利用该信息可以确定出需要进行加载规则调整的目标加载对象。当然，加载对象的数量通常是由多个，因此，具体获得多个加载对象的加载信息，以及多个加载对象分别在被调用时的调用信息。这样，对于每个被调用的加载对象，都可以确定出加载信息以及调用信息。

其中，如前文所述，在一种具体的实现方式下，加载信息可以包括加载时间信息，调用信息则可以包括首次被调用时的调用时间信息，等等。此时，在根据所述加载信息和调用信息，确定目标加载对象时，具体可以确定出加载对象从加载到首次被调用之间的时间间隔信息。该信息便可以作为用户在使用加载对象方面的特征，用来确定就该用户而言，可延迟到应用程序启动完成后加载的加载对象，这种加载对象便可以成为本申请实施例中的目标加载对象。当然，在其他的实施方式中，还可以通过其他方式确定目标加载对象。

其中，具体在确定可延迟到应用程序启动完成后加载的加载对象时，可以有多种具体的实现方式。例如，在一种方式下，可以利用同一用户在多次使用同一应用程序过程中，对同一加载对象的使用方面所体现出的特征，来确定该加载对象是否可以延迟到应用程序启动完成之后加载。也即，可以通过所述用户在多次使用所述应用程序过程中获得的所述时间间隔信息进行统计，如果同一加载对象对应的所述时间间隔信息总是(也即，概率高于某阈值，如80％)大于某时间阈值(例如，10S)，则可以确定该加载对象可延迟到应用程序启动完成后加载。

当然，在具体实现时，如果单纯依据同一个用户在多次使用应用程序过程中对加载对象使用方面所体现出的特征来生成个性化脚本，则可能会出现数据稀疏的问题，可能需要比较长的时间沉淀下来的数据，才能够发现用户的特征，并生成针对具体用户的个性化脚本。

为此，在本申请实施例所提供的另一种实现方案中，还可以通过对大量用户在使用应用程序过程中，在使用加载对象方面所体现出的特征，进行时间预测模型的训练。这样，针对具体某个用户而言，可以获得预先训练得到的时间预测模型，并以该用户在一次访问过程中采集到的所述加载对象对应的所述时间间隔信息为所述时间预测模型的输入信息，则可以实现对下次启动所述应用程序的过程中，所述加载对象从加载到首次被调用之间的时间间隔信息进行预测。然后，如果预测出的所述时间间隔信息大于时间阈值，则可以确定对应的加载对象可延迟到应用程序启动完成后加载。

其中，具体实现时，所述时间预测模型具体可以包括动态规划算法模型，可以利用多个用户在多次使用应用程序过程中从加载对象加载到首次被调用的时间间隔信息的特征，对所述动态规划算法模型进行训练获得的。所谓的动态规划算法是通过拆分问题，定义问题状态和状态之间的关系，使得问题能够以递推(或者说分治)的方式去解决，也即，将待求解的问题分解为若干个子问题(阶段)，按顺序求解子阶段，前一子问题的解，为后一子问题的求解提供了有用的信息。在本申请实施例中，就是指，在所获得的训练样本中，某用户在一次使用应用程序过程中，从某加载对象A加载到该加载对象首次被调用的时间间隔是10S，而该用户下次使用应用程序过程中，从某加载对象A加载到该加载对象首次被调用的时间间隔仍然是10S甚至更长；同时也存在其他更多的用户在对该加载对象A的使用上也体现出了类似的特征，则关于该加载对象A的上述情况便可以通过时间预测模型体现出来，后续便可以用该模型对具体用户的特征进行预测，进而可以根据预测结果确定具体的加载对象是否可以延迟到应用程序启动完成之后再进行加载。

具体实现时，关于上述通过算法模型进行预测的方式，在模型训练过程中，客户端采集到的关于具体用户对具体加载对象的使用特征信息可以上传到服务端，由服务端采集多个用户对应的特征信息，进行模型训练。在模型训练完成之后，可以投放到具体的客户端。客户端中可以预先实现端计算平台，以便在客户端本地通过具体的算法模型，以及采集到的与具体用户相关的在加载对象使用方面的特征信息，对下次使用应用程序时的具体加载对象从加载到首次被调用的时间间隔进行预测。

S305：修改所述通用加载脚本中对应所述目标加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。

确定出目标加载对象之后，可以修改该目标加载对象在通用加载脚本中的加载规则信息，例如，将将所述目标加载对象的加载时机信息修改为应用程序启动完成之后加载，等等。进而，在完成对目标加载对象的加载规则的修改后，则可以生成针对当前用户的专用加载脚本。

需要说明的是，在具体在生成针对当前用户的专用加载脚本时，除了考虑具体就用户而言，从加载对象加载到首次调用加载对象之间的时间间隔这一特征之外，还可以考虑用户的终端设备的性能因素。也就是说，由于终端设备的性能因素也是影响应用程序启动耗时的一个重要影响因素，因此，在具体生成专用加载脚本的过程中，可以结合关联的终端设备的性能特征信息，来修改所述通用加载脚本中对应所述目标加载对象的加载规则，例如，具体可以包括：确定可延迟到应用程序启动完成后加载的加载对象的数量，等等。具体如，某用户A和用户B在具体对某些加载对象的使用方面体现出的特征是一致的，各自都有20个加载对象从加载到首次使用的时间间隔比较长，符合延迟到应用程序启动完成之后再加载的条件。但是，用户A关联的终端设备性能比较好，可以在比较少的耗时情况下加载更多的加载对象，用户B关联的终端设备性能比较差，如果加载同样多的加载对象，需要更多的耗时。在这种情况下，可以将用户B关联的上述符合条件的20个加载对象都延迟到应用程序启动完成之后再加载；而对于用户A，则可以仅将上述20个加载对象中的一部分延迟到应用程序启动完成之后加载，等等。或者，在另一种实现方式下，对于关联了不同终端设备性能的用户而言，具体算法模型中使用的判断阈值也可以有所不同，通过这种阈值的设定，来控制延迟到应用程序启动完成之后加载的数量。

另外需要说明的是，在具体生成针对具体用户的专用加载脚本的过程中，由于可能涉及到对加载对象加载时机的调整，而不同的加载对象之间可能还具有一些依赖关系，例如，某类库加载之前需要首先加载另一类库，等等。因此，如果确定出需要对某个加载对象的加载时机进行调整，则可以将依赖于该加载对象的其他加载对象的加载时机也一并调整到该加载对象加载完成之后，避免加载时出错。

总之，通过本申请实施例，首先可以通过脚本的方式来实现加载对象的加载逻辑控制，使得对加载对象加载逻辑的修改不再依赖于应用程序的版本更新。另外，在此基础上，还可以通过采集具体用户在使用应用程序过程中，对加载对象进行加载时的加载信息以及对加载对象进行调用时的调用信息作为用户特征，来确定就该用户而言，可以进行加载规则修改的目标加载对象。然后，可以通过对脚本的调整，将上述符合条件的目标加载对象的加载规则进行修改，以此生成针对具体用户的专用加载脚本。也就是说，具体加载对象的加载规则，是根据用户实际体现出的特征来进行的，因此可以实现更合理的优化。

需要说明的是，本申请实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下(例如，用户明确同意，对用户切实通知，等)，在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。

实施例二

如实施例一中所述，在需要通过时间预测模型对用户行为进行预测的情况下，可以预先由服务端对具体的时间预测模型进行训练，并投放到具体用户的客户端，在客户端中完成具体的预测。具体的，该实施例二就是从服务端的角度，提供了一种数据处理方法，参见图4，该方法具体可以包括：

S401：对多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息进行采集，以利用所采集到的信息对时间预测模型进行训练；

S402：将训练完成的时间预测模型投放到客户端，以通过记录单个用户在使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息，以及所述时间预测模型，对所述用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测，所预测的结果用于确定可延迟到应用程序启动完成后加载的加载对象，并生成针对所述单个用户的专用加载脚本。

具体实现时，还可以对所述多个用户对应的终端设备的性能信息进行采集，在训练所述时间预测模型时引入所述终端设备的性能因素，在利用所述时间预测模型对单个用户进行所述预测时，引入所述单个用户关联的终端设备的性能因素，进而可以根据预测结果，确定可延迟到应用程序启动完成后加载的加载对象的数量。

实施例三

在前述实施例一中，主要是针对首先获得通用加载脚本，再通过采集用户使用具体应用程序过程中体现出的特征信息，对通用加载脚本进行修改，生成针对具体用户的专用加载脚本，后续则可以使用专用加载脚本，实现对具体用户使用对应应用程序过程中的加载对象的加载。通过这种方式可以实现对加载对象加载逻辑的修改，而不依赖于应用程序的新版本发布，并且还可以实现基于不同用户的加载逻辑个性化。

而在实际应用中，通过加载脚本的方式来执行对应用程序关联的加载对象的加载本身，也可以作为一个独立的方案来存在。在这种方式下，具体的加载脚本可以是为多个用户所通用的，并且可以保存在服务端。在相关的技术人员等需要对具体加载对象的加载逻辑进行修改时，直接对服务端的该加载脚本进行修改即可，客户端的加载框架在后续启动应用程序时，则会读取到新的加载脚本，实现使用修改后的加载逻辑实现对加载对象的加载，而不依赖于应用程序的新版本发布。

因此，在该实施例三中，提供了一种信息处理方法，参见图5，该方法具体可以包括：

S501：启动应用程序时，获取应用程序关联的加载脚本，所述加载脚本中包括多个加载对象的加载规则信息；

具体实现时，可以从服务端下载所述应用程序关联的为多个用户所共用的通用加载脚本。其中，所述加载脚本中的所述加载规则信息包括：所述加载对象的加载时机信息。在所述服务端的加载脚本发生更新后，则可以从所述服务端下载更新后的加载脚本。

S502：利用所述加载脚本执行对所述多个加载对象的加载任务。

实施例四

在该实施例四中，提供了一种信息处理方法。在该方法中，主要对通过用户关联的专用加载脚本进行加载对象控制的方案进行单独保护。具体的，参见图6，该方法具体可以包括：

S601：接收到由目标用户发起的启动应用程序任务后，获取应用程序关联的针对所述目标用户的专用加载脚本，所述专用加载脚本中包括：根据所述目标用户在历史使用所述应用程序过程中获得的对多个加载对的加载信息以及调用信息，生成的多个加载对象的加载规则信息；

S602：利用所述专用加载脚本执行对所述多个加载对象的加载任务。

关于上述实施例二至实施例四中的未详述部分，可以参见前述实施例一中的记载，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种信息处理装置，参见图7，该装置可以包括：

通用加载脚本获取单元701，用于启动应用程序时，获取应用程序关联的通用加载脚本；

加载信息记录单元702，用于在利用所述通用加载脚本执行多个加载任务时，记录所述加载任务对应的加载信息；

调用信息记录单元703，用于在调用所述加载任务对应的加载对象时，记录所述加载对象的调用信息；

目标加载对象确定单元704，用于根据所述加载信息和调用信息，确定目标加载对象；

专用加载脚本生成单元705，用于修改所述通用加载脚本中对应所述目标加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。

其中，所述通用加载脚本中包括多个加载对象的加载时机信息。具体的，所述加载时机信息包括在所述应用程序启动完成前加载。

其中，所述通用加载脚本获取单元具体可以用于：

在尚未生成针对所述当前用户的专用加载脚本的情况下，从服务端下载所述应用程序关联的通用加载脚本。

其中，所述加载对象包括所述应用程序关联的功能模块中所需引用的类库；此时，所述通用加载脚本是根据多个类库之间的依赖关系以及有向无环图结构进行排序后生成的。

或者，所述加载对象包括所述应用程序关联的轻应用，所述轻应用包括：通过所述应用程序进行用户的导入与激活后提供相应服务的应用。

具体实现时，所述加载信息记录单元具体可以用于：

在启动所述应用程序的过程中，利用所述通用加载脚本对所述应用程序关联的多个加载对象进行加载，并对所述加载对象的加载时间信息进行记录；

所述调用信息记录单元具体可以用于：

在所述应用程序启动完成后，对所述加载对象的首次调用时间信息进行记录；

相应的，所述目标加载对象确定单元具体可以用于：

根据所述加载时间信息和首次调用时间信息之间的时间间隔信息，确定可延迟到应用程序启动完成后加载的加载对象为所述目标加载对象。

具体的，所述调用信息记录单元具体可以用于：通过面向切面编程AOP技术在所述加载对象首次被调用的位置进行埋点，根据埋点信息获得所述首调用时间信息。

所述目标加载对象确定单元具体可以用于：通过所述用户在多次使用所述应用程序过程中获得的所述时间间隔信息进行统计，如果同一加载对象对应的所述时间间隔信息大于时间阈值的概率高于阈值，则确定该加载对象为可延迟到应用程序启动完成后加载的目标加载对象。

或者，目标加载对象确定单元具体可以用于：获得预先训练得到的时间预测模型，并以所述加载对象对应的所述时间间隔信息为所述时间预测模型的输入信息，对所述当前用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测；如果预测出的所述时间间隔信息大于时间阈值，则确定对应的加载对象为可延迟到应用程序启动完成后加载的目标加载对象。

其中，所述时间预测模型包括动态规划算法模型，是利用多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息的特征，对所述动态规划算法模型进行训练获得的。

所述专用记载脚本生成单元具体可以用于：将所述目标加载对象的加载时机信息修改为应用程序启动完成之后加载。

另外，所述专用记载脚本生成单元具体还可以用于：结合关联的终端设备的性能特征信息，修改所述通用加载脚本中对应所述目标加载对象的加载规则。

与实施例二相对应，本申请实施例还提供了一种数据处理装置，参见图8，该装置具体可以包括：

信息采集单元801，用于对多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息进行采集，以利用所采集到的信息对时间预测模型进行训练；

模型投放单元802，用于将训练完成的时间预测模型投放到客户端，以通过记录单个用户在使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息，以及所述时间预测模型，对所述用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测，所预测的结果用于确定可延迟到应用程序启动完成后加载的加载对象，并生成针对所述单个用户的专用加载脚本。

具体实现时，该装置还可以包括：

终端信息采集单元，用于对所述多个用户对应的终端设备的性能信息进行采集；

第一引入单元，用于在训练所述时间预测模型时引入所述终端设备的性能因素；

第二引入单元，用于在利用所述时间预测模型对单个用户进行所述预测时，引入所述单个用户关联的终端设备的性能因素；

数量信息确定单元，用于根据预测结果，确定可延迟到应用程序启动完成后加载的加载对象的数量。

与实施例三相对应，本申请实施例还提供了一种信息处理装置，参见图9，该装置具体可以包括：

加载脚本获取单元901，用于启动应用程序时，获取应用程序关联的加载脚本，所述加载脚本中包括多个加载对象的加载规则信息；

加载任务执行单元902，用于利用所述加载脚本执行对所述多个加载对象的加载任务。

其中，所述加载脚本获取单元具体可以用于：

从服务端下载所述应用程序关联的为多个用户所共用的通用加载脚本。

其中，所述加载脚本中的所述加载规则信息包括：所述加载对象的加载时机信息。

另外，所述加载脚本获取单元具体可以用于：

在所述服务端的加载脚本发生更新后，从所述服务端下载更新后的加载脚本。

与实施例四相对应，本申请实施例还提供了一种信息处理装置，参见图10，该装置具体可以包括：

专用加载脚本获取单元1001，用于接收到由目标用户发起的启动应用程序任务后，获取应用程序关联的针对所述目标用户的专用加载脚本，所述专用加载脚本中包括：根据所述目标用户在历史使用所述应用程序过程中获得的对多个加载对的加载信息以及调用信息，生成的多个加载对象的加载规则信息；

加载任务执行单元1002，用于利用所述专用加载脚本执行对所述多个加载对象的加载任务。

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

启动应用程序时，获取应用程序关联的通用加载脚本；

在利用所述通用加载脚本加载执行多个加载任务时，记录所述加载任务对应的加载信息；

在调用所述加载任务对应的加载对象时，记录所述任务加载对象的调用信息；

根据所述加载信息和调用信息，确定目标任务加载对象；

修改所述通用加载脚本中对应所述目标任务加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

对多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息进行采集，以利用所采集到的信息对时间预测模型进行训练；

将训练完成的时间预测模型投放到客户端，以通过记录单个用户在使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息，以及所述时间预测模型，对所述用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测，所预测的结果用于确定可延迟到应用程序启动完成后加载的加载对象，并生成针对所述单个用户的专用加载脚本。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

启动应用程序时，获取应用程序关联的加载脚本，所述加载脚本中包括多个加载对象的加载规则信息；

利用所述加载脚本执行对所述多个加载对象的加载任务。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收到由目标用户发起的启动应用程序任务后，获取应用程序关联的针对所述目标用户的专用加载脚本，所述专用加载脚本中包括：根据所述目标用户在历史使用所述应用程序过程中获得的对多个加载对的加载信息以及调用信息，生成的多个加载对象的加载规则信息；

利用所述专用加载脚本执行对所述多个加载对象的加载任务。

其中，图11示例性的展示出了电子设备的架构，例如，设备1100可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。

参照图11，设备1100可以包括以下一个或多个组件：处理组件1102，存储器1104，电源组件1106，多媒体组件1108，音频组件1110，输入/输出(I/O)的接口1112，传感器组件1114，以及通信组件1116。

处理组件1102通常控制设备1100的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件1102可以包括一个或多个处理器1120来执行指令，以完成本公开技术方案提供的方法的全部或部分步骤。此外，处理组件1102可以包括一个或多个模块，便于处理组件1102和其他组件之间的交互。例如，处理部件1102可以包括多媒体模块，以方便多媒体组件1108和处理组件1102之间的交互。

存储器1104被配置为存储各种类型的数据以支持在设备1100的操作。这些数据的示例包括用于在设备1100上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1104可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1106为设备1100的各种组件提供电力。电源组件1106可以包括电源管理系统，一个或多个电源，及其他与为设备1100生成、管理和分配电力相关联的组件。

多媒体组件1108包括在设备1100和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1108包括一个前置摄像头和/或后置摄像头。当设备1100处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1110被配置为输出和/或输入音频信号。例如，音频组件1110包括一个麦克风(MIC)，当设备1100处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1104或经由通信组件1116发送。在一些实施例中，音频组件1110还包括一个扬声器，用于输出音频信号。

I/O接口1112为处理组件1102和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件1114包括一个或多个传感器，用于为设备1100提供各个方面的状态评估。例如，传感器组件1114可以检测到设备1100的打开/关闭状态，组件的相对定位，例如所述组件为设备1100的显示器和小键盘，传感器组件1114还可以检测设备1100或设备1100一个组件的位置改变，用户与设备1100接触的存在或不存在，设备1100方位或加速/减速和设备1100的温度变化。传感器组件1114可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1114还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1114还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1116被配置为便于设备1100和其他设备之间有线或无线方式的通信。设备1100可以接入基于通信标准的无线网络，如WiFi，或2G、3G、4G/LTE、5G等移动通信网络。在一个示例性实施例中，通信部件1116经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信部件1116还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，设备1100可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1104，上述指令可由设备1100的处理器1120执行以完成本公开技术方案提供的方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的信息处理方法、装置及电子设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (28)

1.一种信息处理方法，其特征在于，包括：

启动应用程序时，获取应用程序关联的通用加载脚本；

在利用所述通用加载脚本执行多个加载任务时，记录所述加载任务对应的加载信息；

在调用所述加载任务对应的加载对象时，记录所述加载对象的调用信息；

根据所述加载信息和调用信息，确定目标加载对象；

修改所述通用加载脚本中对应所述目标加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。

2.根据权利要求1所述的方法，其特征在于，

所述通用加载脚本中包括多个加载对象的加载时机信息。

3.根据权利要求2所述的方法，其特征在于，

所述加载时机信息包括在所述应用程序启动完成前加载。

4.根据权利要求1所述的方法，其特征在于，

所述获取应用程序关联的通用加载脚本，包括：

在尚未生成针对所述当前用户的专用加载脚本的情况下，从服务端下载所述应用程序关联的通用加载脚本。

5.根据权利要求4所述的方法，其特征在于，

所述加载对象包括所述应用程序关联的功能模块中所需引用的类库；

所述通用加载脚本是根据多个类库之间的依赖关系以及有向无环图结构进行排序后生成的。

6.根据权利要求4所述的方法，其特征在于，

所述加载对象包括所述应用程序关联的轻应用，所述轻应用包括：通过所述应用程序进行用户的导入与激活后提供相应服务的应用。

7.根据权利要求1所述的方法，其特征在于，

所述在利用所述通用加载脚本执行多个加载任务时，记录所述加载任务对应的加载信息，包括：

在启动所述应用程序的过程中，利用所述通用加载脚本对所述应用程序关联的多个加载对象进行加载，并对所述加载对象的加载时间信息进行记录；

所述在调用所述加载任务对应的加载对象时，记录所述加载对象的调用信息，包括：

在所述应用程序启动完成后，对所述加载对象的首次调用时间信息进行记录；

所述根据所述加载信息和调用信息，确定目标加载对象，包括：

根据所述加载时间信息和首次调用时间信息之间的时间间隔信息，确定可延迟到应用程序启动完成后加载的加载对象为所述目标加载对象。

8.根据权利要求7所述的方法，其特征在于，

所述对所述加载对象的首次调用时间信息进行记录，包括：

通过面向切面编程AOP技术在所述加载对象首次被调用的位置进行埋点，根据埋点信息获得所述首调用时间信息。

9.根据权利要求7所述的方法，其特征在于，

所述确定可延迟到应用程序启动完成后加载的加载对象，包括：

通过所述用户在多次使用所述应用程序过程中获得的所述时间间隔信息进行统计，如果同一加载对象对应的所述时间间隔信息大于时间阈值的概率高于阈值，则确定该加载对象为可延迟到应用程序启动完成后加载的目标加载对象。

10.根据权利要求7所述的方法，其特征在于，

所述确定可延迟到应用程序启动完成后加载的加载对象，包括：

获得预先训练得到的时间预测模型，并以所述加载对象对应的所述时间间隔信息为所述时间预测模型的输入信息，对所述当前用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测；

如果预测出的所述时间间隔信息大于时间阈值，则确定对应的加载对象为可延迟到应用程序启动完成后加载的目标加载对象。

11.根据权利要求10所述的方法，其特征在于，

所述时间预测模型包括动态规划算法模型，是利用多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息的特征，对所述动态规划算法模型进行训练获得的。

12.根据权利要求7所述的方法，其特征在于，

所述修改所述通用加载脚本中对应所述目标加载对象的加载规则信息，包括：

将所述目标加载对象的加载时机信息修改为应用程序启动完成之后加载。

13.根据权利要求1至12任一项所述的方法，其特征在于，还包括：

结合关联的终端设备的性能特征信息，修改所述通用加载脚本中对应所述目标加载对象的加载规则。

14.一种数据处理方法，其特征在于，包括：

对多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息进行采集，以利用所采集到的信息对时间预测模型进行训练；

将训练完成的时间预测模型投放到客户端，以通过记录单个用户在使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息，以及所述时间预测模型，对所述用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测，所预测的结果用于确定可延迟到应用程序启动完成后加载的加载对象，并生成针对所述单个用户的专用加载脚本。

15.根据权利要求14所述的方法，其特征在于，还包括：

对所述多个用户对应的终端设备的性能信息进行采集；

在训练所述时间预测模型时引入所述终端设备的性能因素；

在利用所述时间预测模型对单个用户进行所述预测时，引入所述单个用户关联的终端设备的性能因素；

根据预测结果，确定可延迟到应用程序启动完成后加载的加载对象的数量。

16.一种信息处理方法，其特征在于，包括：

启动应用程序时，获取应用程序关联的加载脚本，所述加载脚本中包括多个加载对象的加载规则信息；

利用所述加载脚本执行对所述多个加载对象的加载任务。

17.根据权利要求16所述的方法，其特征在于，

所述获取应用程序关联的加载脚本，包括：

从服务端下载所述应用程序关联的为多个用户所共用的通用加载脚本。

18.根据权利要求17所述的方法，其特征在于，

所述加载脚本中的所述加载规则信息包括：所述加载对象的加载时机信息。

19.根据权利要求17所述的方法，其特征在于，

所述获取应用程序关联的加载脚本，包括：

在所述服务端的加载脚本发生更新后，从所述服务端下载更新后的加载脚本。

20.一种信息处理方法，其特征在于，包括：

接收到由目标用户发起的启动应用程序任务后，获取应用程序关联的针对所述目标用户的专用加载脚本，所述专用加载脚本中包括：根据所述目标用户在历史使用所述应用程序过程中获得的对多个加载对的加载信息以及调用信息，生成的多个加载对象的加载规则信息；

利用所述专用加载脚本执行对所述多个加载对象的加载任务。

21.一种信息处理装置，其特征在于，包括：

通用加载脚本获取单元，用于启动应用程序时，获取应用程序关联的通用加载脚本；

加载信息记录单元，用于在利用所述通用加载脚本执行多个加载任务时，记录所述加载任务对应的加载信息；

调用信息记录单元，用于在调用所述加载任务对应的加载对象时，记录所述加载对象的调用信息；

目标加载对象确定单元，用于根据所述加载信息和调用信息，确定目标加载对象；

专用加载脚本生成单元，用于修改所述通用加载脚本中对应所述目标加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。

22.一种数据处理装置，其特征在于，包括：

信息采集单元，用于对多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息进行采集，以利用所采集到的信息对时间预测模型进行训练；

模型投放单元，用于将训练完成的时间预测模型投放到客户端，以通过记录单个用户在使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息，以及所述时间预测模型，对所述用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测，所预测的结果用于确定可延迟到应用程序启动完成后加载的加载对象，并生成针对所述单个用户的专用加载脚本。

23.一种信息处理装置，其特征在于，包括：

加载脚本获取单元，用于启动应用程序时，获取应用程序关联的加载脚本，所述加载脚本中包括多个加载对象的加载规则信息；

加载任务执行单元，用于利用所述加载脚本执行对所述多个加载对象的加载任务。

24.一种信息处理装置，其特征在于，包括：

专用加载脚本获取单元，用于接收到由目标用户发起的启动应用程序任务后，获取应用程序关联的针对所述目标用户的专用加载脚本，所述专用加载脚本中包括：根据所述目标用户在历史使用所述应用程序过程中获得的对多个加载对的加载信息以及调用信息，生成的多个加载对象的加载规则信息；

加载任务执行单元，用于利用所述专用加载脚本执行对所述多个加载对象的加载任务。

25.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

启动应用程序时，获取应用程序关联的通用加载脚本；

在利用所述通用加载脚本执行多个加载任务时，记录所述加载任务对应的加载信息；

在调用所述加载任务对应的加载对象时，记录所述加载对象的调用信息；

根据所述加载信息和调用信息，确定目标加载对象；

修改所述通用加载脚本中对应所述目标加载对象的加载规则信息，获得针对当前用户的专用加载脚本，用于所述当前用户对所述应用程序的下次启动。

26.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

对多个用户在多次使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息进行采集，以利用所采集到的信息对时间预测模型进行训练；

将训练完成的时间预测模型投放到客户端，以通过记录单个用户在使用应用程序过程中从加载对象加载到首次调用所述加载对象的时间间隔信息，以及所述时间预测模型，对所述用户下次使用所述应用程序的过程中，所述加载对象从加载到首次被调用的时间间隔信息进行预测，所预测的结果用于确定可延迟到应用程序启动完成后加载的加载对象，并生成针对所述单个用户的专用加载脚本。

27.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

启动应用程序时，获取应用程序关联的加载脚本，所述加载脚本中包括多个加载对象的加载规则信息；

利用所述加载脚本执行对所述多个加载对象的加载任务。

28.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收到由目标用户发起的启动应用程序任务后，获取应用程序关联的针对所述目标用户的专用加载脚本，所述专用加载脚本中包括：根据所述目标用户在历史使用所述应用程序过程中获得的对多个加载对的加载信息以及调用信息，生成的多个加载对象的加载规则信息；

利用所述专用加载脚本执行对所述多个加载对象的加载任务。

Images