CN111552518A - 一种启动应用的控件加载方法及装置 - Google Patents

Abstract

本发明公开了一种启动应用的控件加载方法及装置，涉及应用研发技术领域，主要目的在于在主Dex中利用代理组件替换应用启动所需的组件以确保应用成功启动。本发明主要的技术方案为：在主Dex中设置代理组件以及组件映射表，所述组件映射表中记录有所述代理组件与设置在辅助Dex中的应用组件的对应关系；在启动应用时，将应用中的类加载器替换为代理类加载器，所述代理类加载器用于在所有Dex优化完成前将启动应用所需加载的应用组件替换为对应的代理组件；利用优化完成的Dex中的应用组件替换应用加载的代理组件，以启动所述应用组件。

Description

一种启动应用的控件加载方法及装置

技术领域

本发明涉及应用研发技术领域，尤其涉及一种启动应用的控件加载方法及装置。

背景技术

随着应用不断迭代，业务线的扩展，App的功能越来越丰富，其编译包也就越来越大，在Android编译App的时候，很容易出现Dex文件方法数超过了最大值65536上限的错误。这是因为在Android系统中，一个APP的所有代码都在一个Dex文件里面。Dex是一个类似Jar的存储了多个Java编译字节码的归档文件。因为Android系统使用Dalvik虚拟机，所以需要把使用Java Compiler编译之后的class文件转换成Dalvik能够执行的class文件。当Android系统启动一个应用的时候，需要对Dex进行优化，这个过程有一个专门的工具来处理，叫DexOpt，DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODex文件，即Optimised Dex，因为执行ODex的效率会比直接执行Dex文件的效率要高很多，而DexOpt会把每一个类的方法id检索起来，存在一个链表结构里面，但是在Android5.0以下的大部分手机中这个链表的长度是用一个short类型来保存的，因为Dalvik的invoke-kind指令集中，method reference inDex只留了16bits，最多能引用65535个方法，导致了方法id的数目不能够超过65536个。所以Android IDE在编译项目的时候，限制了Dex的方法数，当一个项目足够大的时候，就会发生该错误。

为了解决上述的问题，常用的是multiDex的分包方案，当方法数超过65536的时候，生成多个Dex文件，把应用启动时必须用到的类和该类的直接引用类放到主Dex中，把其他类放到辅助Dex中。当应用启动之后，动态加载辅助Dex，从而避免出现方法数超出65536上限的问题。然而，这种分包方案并不能确保将所有应用启动必须的类放到主Dex中，而一旦出现该情况，在应用启动时，如果从主Dex中无法加载到启动所需的组件，而存储该组件的辅助Dex此时还未动态加载完成，那么该应用将会因为组件无法加载而导致启动失败。

发明内容

鉴于上述问题，本发明提出了一种启动应用的控件加载方法及装置，主要目的在于在主Dex中利用代理组件替换应用启动所需的组件以确保应用成功启动。

为达到上述目的，本发明主要提供如下技术方案：

一方面，本发明提供一种启动应用的控件加载方法，具体包括：

在主Dex中设置代理组件以及组件映射表，所述组件映射表中记录有所述代理组件与设置在辅助Dex中的应用组件的对应关系；

在启动应用时，将应用中的类加载器替换为代理类加载器，所述代理类加载器用于在所有Dex优化完成前将启动应用所需加载的应用组件替换为对应的代理组件；

利用优化完成的Dex中的应用组件替换应用加载的代理组件，以启动所述应用组件。

另一方面，本发明提供一种启动应用的控件加载装置，具体包括：

设置单元，用于在主Dex中设置代理组件以及组件映射表，所述组件映射表中记录有所述代理组件与设置在辅助Dex中的应用组件的对应关系；

类加载器替换单元，用于在启动应用时，将应用中的类加载器替换为代理类加载器，所述代理类加载器用于在所有Dex优化完成前将启动应用所需加载的应用组件替换为对应的代理组件；

组件替换单元，用于利用优化完成的Dex中的应用组件替换应用加载的代理组件，以启动所述应用组件。

另一方面，本发明提供一种存储介质，所述存储介质用于存储的计算机程序，其中，所述计算机程序运行时控制所述存储介质所在设备执行上述的启动应用的控件加载方法。

另一方面，本发明提供一种处理器，所述处理器用于运行计算机程序，其中，所述计算机程序运行时执行上述的启动应用的控件加载方法。

借由上述技术方案，本发明提供的一种启动应用的控件加载方法及装置，能够克服主Dex中需要加载的组件数量过多而导致的应用启动失败的问题。本发明通过在主Dex中设置应用的组件映射表以及自定义的代理组件，在启动应用时，利用自定义的代理类加载器，将应用启动所需加载的在辅助Dex中应用组件替换为代理组件，以支持应用的启动流程，同时，等待辅助Dex优化完成后，将辅助Dex中的应用组件再次替换之前的代理组件，当应用启动所需加载的组件均为实际的应用组件时，再启动这些应用组件，实现应用的正常启动。相对现有的Dex优化以及组件加载方式，本发明将应用的启动过程分为了组件的加载与启动两个阶段，在加载阶段，使用代理组件替代未优化完成的辅助Dex中的应用组件，并等待辅助Dex优化完成后将加载的代理组件再次替换为应用组件，之后利用加载的应用组件启动应用，避免了在应用启动过程出现未发现待加载的组件而导致的应用启动失败问题，提高了应用启动的成功率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提出的一种启动应用的控件加载方法的流程图；

图2示出了本发明实施例提出的另一种启动应用的控件加载方法的流程图；

图3示出了本发明实施例提出的一种启动应用的控件加载装置的组成框图；

图4示出了本发明实施例提出的另一种启动应用的控件加载装置的组成框图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

本发明实施例提供了一种启动应用的控件加载方法，该方法是基于生成多个Dex文件，在应用启动时，将指定的组件设置在主Dex中，以确保Dex文件中的方法数不超过65536的上限。而对于应用启动所需加载的方法数大于该上限，需要从辅助Dex中加载的情况，本发明提供的具体步骤如图1所示，该方法包括：

步骤101、在主Dex中设置代理组件以及组件映射表。

其中，组件映射表中记录有代理组件与设置在辅助Dex中的应用组件的对应关系。一般地，一组对应关系中至少包括代理组件和应用组件的组件标识，该组件标识不限定是组件名称或组件属性标识等信息。

此外，本发明中的代理组件为一组自定义的组件，而每一个代理组件所对应的应用组件可以是多个，而多个应用组件一般是同一类的组件，比如定义的代理组件为Activityproxy.java，那么，该代理组件所能够对应的应用组件可以为aActivity.java、bActivity.java、cActivity.java等，即该代理组件所对应的应用组件为具有相同功能的一类组件。如此，在主Dex中就可以通过设置少量的代理组件来对应大量同类型的应用组件，而将这些同类型的应用组件放到辅助Dex中。

步骤102、在启动应用时，将应用中的类加载器替换为代理类加载器。

其中，类加载器是在应用启动过程中加载启动所需组件的装置，其工作时，是从主Dex中提取所需加载的控件。而代理类加载器为自定义的类加载器，其与应用原生的类加载器的区别在于，代理类加载器在加载控件时，是从主Dex中的组件映射表中查找需要加载的应用组件，在根据该应用组件的对应关系确定代理组件，进而加载设置在主Dex中的代理组件，需要说明的是，在本发明实施例中，如果应用启动所需加载的应用组件不存在对应的代理组件时，该应用组件一般是放在主Dex中的，而在组件映射表中，该应用组件的对应关系可以是对应其自身，或者是不存在对应关系，如此，代理类加载器也可以直接从主Dex中加载到所需的应用组件。

需要特别说明的是，本步骤中的代理类加载器在执行组件加载操作时，是在所有Dex文件优化完成前执行的。Dex文件的优化过程一般是先加载主Dex，之后动态加载辅助Dex，而代理类加载器一般是完成主Dex加载之后，辅助Dex未加载完成之前的时间段内从主Dex中提取应用启动所需的组件。

通过本步骤中的代理类加载器加载应用启动所需的应用组件后，由于部分辅助Dex未优化完成，使得所加载的组件中存在代理组件。而由于代理组件中并不含有应用组件中的具体数据，因此，并不能直接执行所加载的代理组件，而是需要等待该代理组件所在的辅助Dex优化完成后，执行步骤103，执行替换后的应用组件，以启动应用。

步骤103、利用优化完成的Dex中的应用组件替换应用加载的代理组件。

由于辅助Dex的数量较多，动态加载所有辅助Dex需要一个过程，因此，本步骤在具体实现时，可以是监控辅助Dex的优化进度，每优化完成一个辅助Dex，就判断该辅助Dex中的应用组件是否含有应用启动所需的组件，也就是判断代理类加载器加载的代理控件中是否存在与应用组件向对应的代理组件，若存在，就将该应用组件替换对应的代理组件。

进一步的，由于本发明中的代理组件对应有多个应用组件，在执行本步骤时，就存在所加载的代理组件替代的是哪一个应用组件的问题，本实施例中解决该问题的一种优选方式是，按照启动应用时加载应用组件的顺序进行反替换，例如，启动应用时加载的组件顺序为a1，a3，a2，而代理组件A在组件映射表于这3个组件都存在对应关系，那么，当这3个组件所在的辅助Dex未优化完成时，实际加载的为A(a1)，A(a3)，A(a2)，同时，记录A的替换顺序，即第一个替换的为a1，第二个替换的为a3，第三个替换的为a2，在a3所在的辅助Dex优化完成后，就根据记录A的替换顺序，查找a3是第二个A替换的，进而在加载的组件中查找第二个A并将其替换为a3。

对于启动应用的过程中，本实施例需要确保应用加载的组件中不存在代理组件即可，也就是说，在辅助Dex未优化完成时，如果应用启动所需的必要组件已经从代理组件替换为应用组件，那么，此时就可以启动加载的应用组件，完成应用的启动流程。

通过上述实施例中的具体实现方式可以看出，本发明实施例在启动应用的过程中，通过将类加载器替换为代理类加载器实现从主Dex中的组件映射表查找并提取所需加载的应用组件对应的代理组件，以确保应用在启动过程中能够加载到所需的组件，同时，等待辅助Dex优化完成后，将其中的应用组件再次替换代理组件，在所有加载的应用启动所需的组件全部为应用组件时，启动所加载的应用组件，完成应用的正常启动。在该过程中，即使应用启动所需的应用组件被分到辅助Dex中，也可以通过代理组件的替换让应用的启动过程继续，避免出现无法找到应用组件而导致的应用启动失败的情况。

为了进一步详细的阐明启动应用的控件加载方法，特别是代理类加载器在应用启动过程中实现的应用组件与代理组件相互替换的具体流程。将通过图2所示的实施例说明，具体步骤包括：

步骤201、创建代理组件以及组件映射表。

该步骤是在应用程序的代码编译过程中执行的，但并不限定其与Dex分包过程的前后关系，根据应用程序中含有的应用组件创建代理组件以及组件映射表，具体为：

首先，通过扫描应用的入口文件获取该应用中的应用组件，其中，应用的入口文件一般为AndroidManifest.xml，其描述了package中暴露的组件(Activities，Services等等)，以及各自的实现类，各种能被处理的数据和启动位置。该入口文件除了能声明应用程序中的Activities，ContentProviders,Services，和Intent Receivers，还能指定permissions和instrumentation。本实施例中通过静态扫描该入口文件，能够获取并记录该应用中所有的应用组件。

其次，创建代理组件，该代理组件的数量取决于上述得到的应用组件的类别，同一类的应用组件创建一个代理组件。在Android系统中常用的四大类组件包括Activity组件、Receiver组件、Service组件和Provider组件，对此，通过创建四个代理组件就可以用于代替大多数的应用组件。在实际应用中，所创建的代理组件还与应用组件的重要程度相关，比如一个应用组件是应用启动时会用到的组件，且该应用组件还有被分配到辅助Dex中的可能时，对于这类的应用组件就需要创建对应的代理组件。此外，创建的代理组件在本实施例中不含有具体的组件内容，即该代理组件仅用于被调用加载，而不能实际执行。

最后，根据扫描得到的应用组件以及创建的代理组件生成组件映射表。在该组件映射表中，记录有代理组件与应用组件的映射关系，一般为一对多的关系，即一个代理组件会对应多个应用组件，此外，如果应用组件以分配到对应的Dex中，在该组件映射表中还可在映射关系中加入应用组件所属的Dex标识信息。

步骤202、在主Dex中设置代理组件以及组件映射表。

需要说明的是，如果代理组件以及组件映射表是在将应用组件进行Dex分包处理后创建的，那么在Dex分包时就需要在主Dex中预留出存放代理组件以及组件映射表的位置。而具体的Dex分包处理过程在本发明中不做限定。

步骤203、在启动应用时，将应用中的类加载器替换为代理类加载器。

关于代理类加载器的相关说明在步骤102已做说明，此处不再赘述。

在执行本步骤时，替换代理类加载器的时机是在应用启动时，具体的，可通过监控Applicaiton attachBaseContext生命周期钩去应用中的类加载器，并将其替换为代理类加载器。

步骤204、通过代理类加载器加载应用启动所需的组件。

代理类加载器加载加载的组件是从主Dex中获取，一般情况下，在主Dex中除了含有代理组件和组件映射表外，还有其他的一些应用组件。因此，该代理类加载器在加载应用组件的具体方式包括如下两种：

一种方式为：判断应用加载的应用组件是否在主Dex中。即是否可以在主Dex中查找到该应用组件。若存在，就直接从主Dex中加载该应用组件。若不存在，则在组件映射表中查找该应用组件对应的代理组件，在加载查找到的代理组件。

另一中方式为：先在组件映射表中查找应用需要加载的应用组件，如果该应用组件在组件映射表中存在对应的代理组件，就从主Dex中加载该代理组件。而如果该应用组件在组件映射表中不存在，或其对应的不是代理组件，该情况下说明该应用组件被分配到主Dex中，此时，再从主Dex中查找并加载该应用组件。

步骤205、利用优化完成的Dex中的应用组件替换应用加载的代理组件。

需要说明的是，应用在启动的同时，会动态加载辅助Dex，也就是动态优化辅助Dex。本步骤中，每完成一个辅助Dex的加载，就使用其中的应用组件替换应用加载的代理组件，其具体过程包括：

首先，将优化完成的辅助Dex中的应用组件记录到预置组件表中。该预置组件表为应用启动过程中缓存的一个数据表，用于缓存优化完成的辅助Dex中的应用组件。

其次，判断该预置组件表中是否存在待替换组件。该待替换组件为应用加载的代理组件在组件映射表中对应的应用组件。具体执行判断的时机可以是在应用启动过程中进行实时判断，也可以是按预置时间间隔进行判断。当判断结果为存在待替换组件时，就将该待替换组件替换对应的代理组件；而当判断结果为不存在待替换组件时，则等待预置组件表中的内容更新并再次判断是否存在待替换组件。

通过本步骤的执行，在所有辅助Dex优化完成后，应用启动所需加载的所有组件也将同步替换为应用组件。

步骤206、当应用加载的组件中不存在代理组件时，将代理类加载器替换为类加载器，以启动加载的应用组件。

将代理类加载器替换为类加载器是为了应用在后期运行过程中能够更为稳定地加载所需的应用组件。对于启动应用的过程中，本实施例需要确保应用加载的组件中不存在代理组件即可，也就是说，在辅助Dex未优化完成时，如果满足应用启动的条件时，也可以启动加载的应用组件，完成应用的启动流程。

而为了让应用的整体运行更稳定，本发明实施例的另一种实现方式为：判断应用加载的组件中是否存在代理组件，若不存在，且在所有辅助Dex文件都优化完成后，再将代理类加载器替换为原来的类加载器，进而启动所加载的应用组件，完成应用的启动流程。

进一步的，作为对上述图1与图2所示方法的实现，本发明实施例提供了一种启动应用的控件加载装置，该装置能够避免出现加载的应用组件缺失导致的启动失败问题，提高应用启动的成功率。为便于阅读，本装置实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的装置能够对应实现前述方法实施例中的全部内容。该装置如图3所示，具体包括：

设置单元301，用于在主Dex中设置代理组件以及组件映射表，所述组件映射表中记录有所述代理组件与设置在辅助Dex中的应用组件的对应关系，所述代理组件对应于同一类的应用组件；

类加载器替换单元302，用于在启动应用时，将应用中的类加载器替换为代理类加载器，所述代理类加载器用于在所有Dex优化完成前将启动应用所需加载的应用组件替换为对应的代理组件；

组件替换单元303，用于利用优化完成的Dex中的应用组件替换应用加载的代理组件，以启动所述应用组件。

进一步的，如图4所示，所述装置还包括：

第一判断单元304，用于在所述组件替换单元303将应用加载的代理组件替换为应用组件之后，判断应用加载的组件中是否存在代理组件；

所述类加载器替换单元302，还用于当所述第一判断单元304确定不存在代理组件时，将所述代理类加载器替换为所述类加载器。

进一步的，如图4所示，所述装置还包括：

组件获取单元305，用于在所述设置单元301执行在主Dex中设置代理组件以及组件映射表之前，通过扫描应用的入口文件获取所述应用中的应用组件；

组件创建单元306，用于创建代理组件，所述代理组件与设置在辅助Dex中的应用组件相对应，其中，该代理组件是根据组件获取单元305获取的应用组件的类别所创建的；

映射表创建单元307，用于根据所述组件获取单元305获取的应用组件与所述组件创建单元305建立的代理组件创建组件映射表。

进一步的，如图4所示，所述装置还包括：

第二判断单元308，用于在所述类加载器替换单元302执行将应用中的类加载器替换为代理类加载器之后，判断应用加载的应用组件是否在主Dex中；

组件加载单元309，用于当所述第二判断单元308确定在主Dex中时，由代理类加载器从主Dex中加载所述应用组件；

组件替换加载单元310，用于当所述第二判断单元308确定不在主Dex中时，由代理类加载器根据所述组件映射表查找所述应用组件对应的代理组件，并加载所述代理组件以继续启动所述应用。

进一步的，如图4所示，所述组件替换单元303包括：

记录模块3031，用于将优化完成的辅助Dex中的应用组件记录到预置组件表中；

判断模块3032，用于判断所述记录模块3031记录的预置组件表中是否存在待替换组件，所述待替换组件为应用加载的代理组件在所述组件映射表中对应的应用组件；

替换模块3033，用于当所述判断模块3032确定存在待替换组件时，将所述待替换组件替换对应的代理组件。

综上所述，本发明实施例所采用的启动应用的控件加载方法及装置，通过设置代理组件的方式不仅克服了Dex文件方法数超过65536上限的问题，而且，还解决了应用启动所需加载的应用组件未在主Dex中而导致的启动失败问题。同时，通过本发明所提供的技术方案可知，使用代理组件后，可以将大量代理组件所对应的应用组件分配到辅助Dex中，从而加速主Dex文件的优化过程，进而提高应用启动的速度。

进一步的，本发明实施例还提供了一种存储介质，该存储介质用于存储计算机程序，其中，所述计算机程序运行时控制所述存储介质所在设备执行上述的启动应用的控件加载方法。

另外，本发明实施例还提供了一种处理器，所述处理器用于运行计算机程序，其中，所述计算机程序运行时执行上述的启动应用的控件加载方法。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

此外，存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (13)

1.一种启动应用的控件加载方法，其特征在于，所述方法包括：

在主Dex中设置代理组件以及组件映射表，所述组件映射表中记录有所述代理组件与设置在辅助Dex中的应用组件的对应关系；

在启动应用时，将应用中的类加载器替换为代理类加载器，所述代理类加载器用于在所有Dex优化完成前将启动应用所需加载的应用组件替换为对应的代理组件；

利用优化完成的Dex中的应用组件替换应用加载的代理组件，以启动所述应用组件。

2.根据权利要求1所述的方法，其特征在于，在利用优化完成的Dex中的应用组件替换应用加载的代理组件之后，所述方法还包括：

判断应用加载的组件中是否存在代理组件；

若不存在，则将所述代理类加载器替换为所述类加载器。

3.根据权利要求1所述的方法，其特征在于，在主Dex中设置代理组件以及组件映射表之前，所述方法还包括：

通过扫描应用的入口文件获取所述应用中的应用组件；

创建代理组件，所述代理组件与设置在辅助Dex中的应用组件相对应；

根据所述应用组件与所述代理组件创建组件映射表。

4.根据权利要求1所述的方法，其特征在于，在将应用中的类加载器替换为代理类加载器之后，所述方法还包括：

判断应用加载的应用组件是否在主Dex中；

若在，则由代理类加载器从主Dex中加载所述应用组件；

若不在，则由代理类加载器根据所述组件映射表查找所述应用组件对应的代理组件，并加载所述代理组件以继续启动所述应用。

5.根据权利要求1所述的方法，其特征在于，利用优化完成的Dex中的应用组件替换应用加载的代理组件包括：

将优化完成的辅助Dex中的应用组件记录到预置组件表中；

判断所述预置组件表中是否存在待替换组件，所述待替换组件为应用加载的代理组件在所述组件映射表中对应的应用组件；

若存在，将所述待替换组件替换对应的代理组件。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述代理组件适用于Android系统中Activity组件、Receiver组件、Service组件和Provider组件。

7.一种启动应用的控件加载装置，其特征在于，所述装置包括：

设置单元，用于在主Dex中设置代理组件以及组件映射表，所述组件映射表中记录有所述代理组件与设置在辅助Dex中的应用组件的对应关系；

类加载器替换单元，用于在启动应用时，将应用中的类加载器替换为代理类加载器，所述代理类加载器用于在所有Dex优化完成前将启动应用所需加载的应用组件替换为对应的代理组件；

组件替换单元，用于利用优化完成的Dex中的应用组件替换应用加载的代理组件，以启动所述应用组件。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

第一判断单元，用于在所述组件替换单元将应用加载的代理组件替换为应用组件之后，判断应用加载的组件中是否存在代理组件；

所述类加载器替换单元，还用于当所述第一判断单元确定不存在代理组件时，将所述代理类加载器替换为所述类加载器。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

组件获取单元，用于在所述设置单元执行在主Dex中设置代理组件以及组件映射表之前，通过扫描应用的入口文件获取所述应用中的应用组件；

组件创建单元，用于创建代理组件，所述代理组件与设置在辅助Dex中的应用组件相对应；

映射表创建单元，用于根据所述组件获取单元获取的应用组件与所述组件创建单元建立的代理组件创建组件映射表。

10.根据权利要求7所述的装置，其特征在于，所述装置还包括：

第二判断单元，用于在所述类加载器替换单元执行将应用中的类加载器替换为代理类加载器之后，判断应用加载的应用组件是否在主Dex中；

组件加载单元，用于当所述第二判断单元确定在主Dex中时，由代理类加载器从主Dex中加载所述应用组件；

组件替换加载单元，用于当所述第二判断单元确定不在主Dex中时，由代理类加载器根据所述组件映射表查找所述应用组件对应的代理组件，并加载所述代理组件以继续启动所述应用。

11.根据权利要求7所述的装置，其特征在于，所述组件替换单元包括：

记录模块，用于将优化完成的辅助Dex中的应用组件记录到预置组件表中；

判断模块，用于判断所述记录模块记录的预置组件表中是否存在待替换组件，所述待替换组件为应用加载的代理组件在所述组件映射表中对应的应用组件；

替换模块，用于当所述判断模块确定存在待替换组件时，将所述待替换组件替换对应的代理组件。

12.一种存储介质，其特征在于，所述存储介质用于存储计算机程序，其中，所述计算机程序运行时控制所述存储介质所在设备执行权利要求1-6中任意一项所述的启动应用的控件加载方法。

13.一种处理器，其特征在于，所述处理器用于运行计算机程序，其中，所述计算机程序运行时执行权利要求1-6中任意一项所述的启动应用的控件加载方法。

Images