CN112612534A - 应用启动方法、设备以及存储介质 - Google Patents

Abstract

本申请公开了一种应用启动方法、设备以及存储介质，应用启动方法包括：接收应用程序的启动指令；判断应用程序的当前用户协议是否处于同意状态；若用户协议处于同意状态的情况下，对应用程序对应的第三方库进行初始化；在初始化完成之后，显示应用程序的界面。上述方案，能够在应用程序启动过程中提高对用户隐私的保护。

Description

应用启动方法、设备以及存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种应用启动、设备以及存储介质。

背景技术

应用程序中可能会集成很多第三方库来实现非主要业务功能。有的第三方库在应用程序启动时，会进行初始化，以便在程序运行期间能够更方便调用，其中，对第三方库的初始化一般会请求网络，并上传设备信息。一般地，常见技术方案中往往是用户点击桌面图标之后，就立即执行对第三方库的初始化操作，这种方式存在的缺点包括，在还不确定用户是否签订用户协议的情况下，就已经将包括设备信息在内的用户隐私信息上传网络，造成用户隐私的泄露。

发明内容

本申请至少提供一种应用启动方法、设备以及存储介质。

本申请第一方面提供了一种应用启动方法，包括：接收应用程序的启动指令；判断应用程序的当前用户协议是否处于同意状态；若用户协议处于同意状态的情况下，对应用程序对应的第三方库进行初始化；在初始化完成之后，显示应用程序的界面。

本申请第二方面提供了一种应用启动装置，包括：指令接收模块，用于接收应用程序的启动指令；判断模块，用于判断应用程序的当前用户协议是否处于同意状态；初始化模块，用于若用户协议处于同意状态的情况下，对应用程序对应的第三方库进行初始化；显示模块，用于在初始化完成之后，显示应用程序的界面。

本申请第三方面提供了一种电子设备，包括存储器和处理器，处理器用于执行存储器中存储的程序指令，以实现上述应用启动方法。

本申请第四方面提供了一种计算机可读存储介质，其上存储有程序指令，程序指令被处理器执行时实现上述应用启动方法。

上述方案，通过判断当应用程序的当前用户协议处于同意状态时，才会对应用程序对应的第三方库进行初始化，使得在当前用户协议不处于同意状态的情况下时，第三方库不会开始初始化，即不会存在将设备信息上传至网络的风险，从而在一定程度上提高了对用户隐私的保护。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本申请的实施例，并与说明书一起用于说明本申请的技术方案。

图1是本申请应用启动方法一实施例的一流程示意图；

图2是本申请应用启动方法一实施例的另一流程示意图；

图3是本申请应用启动装置一实施例的结构示意图；

图4是本申请电子设备一实施例的结构示意图；

图5是本申请计算机可读存储介质一实施例的结构示意图。

具体实施方式

下面结合说明书附图，对本申请实施例的方案进行详细说明。

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、接口、技术之类的具体细节，以便透彻理解本申请。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。此外，本文中的“多”表示两个或者多于两个。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

请参阅图1，图1是本申请应用启动方法一实施例的一流程示意图。具体而言，可以包括如下步骤：

步骤S11：接收应用程序的启动指令。

其中，启动指令包括多种，例如，包括点击应用图标的指令、在其他程序中点击应用程序对应的链接等。其他程序例如应用市场、软件管家、百度、谷歌等。接收应用程序的启动指令除了上述方式之外，还可以是接收用户语音指令，例如“小爱同学，上午好呀，请打开百度”，通过获取语音中的关键词来启动对应的应用程序，例如，在该条语音中，关键词包括“打开”、“百度”。将获取到的关键词与预设关键词进行匹配，以获取关键词对应的预设操作。继上例，关键词“打开”对应的操作为启动操作，关键词“百度”对应的是百度App这个对象。当然，关键词“百度”对应百度App，可以不是预先通过手动输入，市面上应用程序的种类与数量极多，并且出新的速度很快，很难将每个应用程序名称都建立对应的关键词，可以通过判断关键词的词性将获取到的关键词与终端内所有的应用程序名称进行匹配，例如，关键词的词性为名词时，则将该关键词与终端中现有的应用程序名称进行匹配，从而根据另一关键词“打开”确定接收到了对该应用程序的启动指令。当然，本公开实施例仅是不完全列举，对应用程序的启动方式并不仅限于此。

步骤S12：判断应用程序的当前用户协议是否处于同意状态。

关于当前用户协议对应的状态可以包括处于同意状态、不处于同意状态且不处于拒绝状态、处于拒绝状态。显然，当接收到同意用户协议指令之后，则处于同意状态，若接收到拒绝用户协议指令之后，则为处于拒绝状态，若未接收到同意用户协议指令以及拒绝用户协议指令，则不处于同意状态且不处于拒绝状态。其中，各个状态可以用对应状态信息表示，判断应用程序的用户协议是否处于同意状态，则可具体为判断表示同意状态的状态信息是否存在即可。

在一些实施例中，应用程序在第一次使用启动时，会显示用户协议需要用户选择同意用户协议或者拒绝用户协议，若接收到同意用户协议指令之后，则可继续启动应用程序，若接收到拒绝用户协议指令之后，则直接退出应用程序，在下次接收到该应用程序的启动指令之后，会继续显示用户协议，等待接收同意用户协议指令或拒绝用户协议指令。

步骤S13：若用户协议处于同意状态的情况下，对应用程序对应的第三方库进行初始化。

其中，第三方库是指在项目开发中，会使用到一些第三方已经实现好的功能或工具来帮助项目快速开发。例如，埋点、地图、直播等等。若检测到存在属于同意状态的状态信息，则认定用户协议处于同意状态，继而可以对应用程序对应的第三方库进行初始化。其中，应用程序对应的第三方库包括通过ContentProvider方法初始化第三方库以及通过Application方法初始化第三方库。本公开实施例中，若用户协议处于同意状态的情况下，先执行应用程序的ContentProvider的onCreate方法，一些第三方库开始初始化，接着执行Application的onCreate方法，另一些第三方库开始初始化。其中，可以选择在ContentProvider的onCreate方法执行结束之后，即这部分第三方库初始化完成之后才执行Application的onCreate方法，使得另一些第三方库开始初始化，当然，还可选择前者执行到某个预设时刻之后，就开始执行后者。例如，当ContentProvider的onCreate方法执行将一些第三方库初始化百分之七十之后，开始执行Application的onCreate方法以对另一些第三方库进行初始化。

步骤S14：在初始化完成之后，显示应用程序的界面。

其中，初始化完成指的是第三方库初始化成功，若初始化失败，则不会显示应用程序的界面。当然，在另一些实施例中，若第三方库初始化失败，仍显示应用程序的界面，同时在界面中弹出，初始化失败的提示框，与第三方库实现的功能没有联系的其他功能模块仍然可以继续响应用户指令，与第三方库实现的功能具有联系的功能模块则不会响应用户指令，并在此同时异步对初始化失败的原因进行分析，得出解决方案之后对初始化失败的第三方库重新开始初始化，若初始化成功，则与第三方库实现的功能具有联系的功能模块可继续响应用户指令。

上述方案，通过判断当应用程序的当前用户协议处于同意状态时，才会对应用程序对应的第三方库进行初始化，使得在当前用户协议不处于同意状态的情况下时，第三方库不会开始初始化，即不会存在将包括设备信息在内的用户隐私信息上传至网络的风险，从而在一定程度上提高了对用户隐私的保护。

在一些实施例中，判断应用程序的当前用户协议是否处于同意状态的方式包括判断预存状态信息是否为同意状态。具体地，读取当前用户协议的预存状态信息，并检测预存状态信息是否为同意状态。其中，预存状态信息是在应用程序本次启动之前生成的。例如在应用程序上次启动时根据用户输入的对用户协议的同意状态信息，将预存状态信息确定为同意状态，以供应用程序本次启动并进行判断时使用。可以理解的是，在应用程序本次启动过程中，也可对预设状态信息进行更新，以供下次启动并进行判断时使用。

在一些实施例中，更新预存状态信息的方式可包括：若检测到预存状态信息不处于同意状态，则接收用户输入的对用户协议同意或拒绝的操作结果，并将预存状态信息更新为操作结果。例如，接收针对用户协议的同意指令之后，则意味着接收到用户输入的对用户协议同意的操作结果，然后将预存状态信息更新为同意状态。若操作结果为拒绝状态，将预存状态更新为处于拒绝状态。等下次接收到应用程序的启动指令后，若预存状态为拒绝状态，则认为应用程序的当前用户协议不处于同意状态。当然，在一些实施例中，若接收到用户输入的对用户协议拒绝的操作结果，则不会将预存状态信息更新为该操作结果，而是将预存状态更新为不处于同意状态且不处于拒绝状态；也即，此时预存状态信息为待处理状态，需要接受用户的对应操作后才会有对应的同意或者拒绝状态。其中，预存状态信息会持续保存一段时间，若应用程序被卸载或更新之后，预存状态信息则重置，即重置为不处于同意状态且不处于拒绝状态。也可以在用户卸载或更新应用程序后，一直保留预存状态为同意状态的信息，仅将预存状态为拒绝状态时的信息重置为待处理状态。当然，在其他实施例中，也可间隔预设时间就将预存状态信息重置为待处理状态，例如，间隔1个月或2个月等等，关于预存状态信息的重置时间此处不做具体规定。因此，当关闭应用程序一段时间之后再次启动该应用程序，因为预存状态信息为同意状态，则对第三方库进行初始化，然后开启应用程序界面，通过将预存状态信息为同意状态持续保存一段时间，能够简化后续启动应用的过程，不会每次启动应用程序时都重新生成同意状态信息，每次启动应用程序都要执行至少两次步骤S12。

在一些实施例中，若当前用户协议不处于同意状态，则接收用户输入的对用户协议同意或拒绝的操作结果，并再次执行判断应用程序的当前用户协议是否处于同意状态的步骤。即，再次执行步骤S12。即在当前用户协议不处于同意状态下，不会对第三方库进行任何的初始化操作，以免未经用户同意直接将包括设备信息在内的用户隐私信息上传网络，造成用户隐私的泄露。其中，若当前用户协议处于拒绝状态，则退出应用程序。可选地，只有在执行接收应用程序的启动指令且已执行一次步骤S12之后，下一次继续执行步骤S12时，若当前用户协议处于拒绝状态，才退出应用程序。即，给予用户一次对用户协议同意或拒绝的操作机会。当然，无论何时，若当前用户协议处于拒绝状态，则不会对第三方库进行任何的初始化，以免未经用户同意而将用户的信息上传至网络造成用户隐私的泄露。

一些公开实施例中，若判断结果为用户协议不处于同意状态，则启动子进程。其中，在子进程中，显示用户协议界面，并响应于用户对用户协议界面的输入信息，生成当前用户协议的同意状态信息或拒绝状态信息，再次执行判断应用程序的当前用户协议是否处于同意状态的步骤。当子进程生成当前用户协议的同意状态信息之后，将预存状态信息更新为同意状态。原进程通过进程间通信即可检测到子进程生成的同意状态信息，并确定应用程序的用户协议处于同意状态，然后执行对应用程序对应的第三方库进行初始化的操作。或，在子进程生成当前用户协议的拒绝状态信息之后，则将预存状态信息更新为拒绝状态。其中，在原进程检测到子进程生成的拒绝状态信息之后，子进程删除对应的拒绝状态信息，原进程也删除检测到的拒绝状态信息，防止下次执行判断操作时出现误判断。其中，原进程若检测到子进程生成拒绝状态信息之后，退出应用程序。可选地，在子进程生成拒绝状态信息之后，子进程直接关闭当前页面，退出子进程。当然，通过在判断为当前用户协议不处于同意状态的情况下，启动子进程显示用户协议界面，相当于在一定程度上加快了接收应用程序的启动指令与应用程序显示界面的时间，减少了用户等待时间。当然，在启动子进程时，并未对第三方库进行任何的初始化。

其中，相邻两个执行判断应用程序的用户协议是否处于同意状态的步骤之间间隔预设时间。例如，每相隔20ms执行一次判断过程。当然，间隔时间可以是在上一次判断过程执行完毕之后开始计算，也可以是相邻两个判断过程的开始进行计算。当间隔时间为0时，则表明连续进行判断，即本次判断结束未检测到同意状态信息或拒绝状态信息时，立即开始下一次的判断过程。因此，相邻两个执行判断应用程序的用户协议是否处于同意状态的步骤之间的间隔时间，本公开实施例不做具体规定。

考虑到为避免出现在启动应用程序时，用户没有同意或拒绝用户协议下，仍存在同意状态信息或拒绝状态信息，本公开实施例提出以下技术方案：若判断结果为当前用户协议不处于同意状态，则对预存状态信息进行重置为待处理状态。其中，重置的时间可以是下一次执行判断应用程序的当前用户协议是否处于同意状态之前的任何时间，因此，关于对同意状态信息或拒绝状态信息的重置，本公开实施例不做具体规定。通过在一次判断之后且二次执行判断应用程序的用户协议是否处于同意状态的操作之前，对同意状态信息或拒绝状态信息进行重置，以防止在未接收到用户协议的同意指令之前，就开始对第三方库进行初始化，或者在未接收到用户协议的拒绝指令之前，就直接退出应用程序的误操作。

考虑到一般项目结构比较复杂，若对项目结构改变过大，则可能会导致后期不好维护，因此，本公开实施例提出以下技术方案：判断应用程序的用户协议是否处于同意状态至初始化之间的步骤，通过在所述应用程序的预设启动方法中增加预设代码来实现。其中，预设启动方法是在启动应用程序时最先调用的方法，可以理解为在应用程序启动过程中默认需要调用的方法。即，本公开实施例所提出的方案是在不改变现有代码结构的基础上，仅增加少量代码即可完成判断应用程序的用户协议是否处于同意状态至初始化之前的步骤。其中，预设启动方法包括attachBaseContext方法。

考虑到子进程在启动之后仍会执行attachBaseContext方法，若不执行attachBaseContext方法不能区分当前进程是子进程还是原进程，那么可能会导致重复启动子进程，重复打开协议界面，甚至出现死循环。为避免该问题的发生，本公开实施例提出以下技术方案：在attachBaseContext方法中增加以下步骤：接收应用程序的启动指令之后，判断当前进程是否为子进程，若是，则显示协议界面，且不再执行判断应用程序的用户协议是否处于同意状态及其后续步骤。若判断结果为不是，则执行判断应用程序的用户协议是否处于同意状态及其后续操作。其中，判断当前进程是否为子进程的方式包括判断当前进行的包名是否是预设的子进程的包名。通过在attachBaseContext方法中增加上述步骤，使得在子进程中不会重复执行判断应用程序的用户协议是否处于同意状态及其后续步骤，避免出现死循环。

考虑到开启子进程与生成同意状态信息或拒绝状态信息之间会存在一定的时间间隔，若原进程在开启子进程之后立即执行判断应用程序的用户协议是否处于同意状态的操作，可能会出现空操作。因此，为了更好地利用执行判断之前的时间，本公开实施例提出以下解决方案：若当前判断结果为用户协议不处于同意状态，则预加载应用程序对应的界面。其中，应用程序对应的界面可以是应用程序的首页面。其中，预加载应用程序对应的界面的方式包括将加载界面对应的类加载到内存中，以便在第三方库初始化完成之后就直接在内存中调用，提高了界面的启动速度。当然，在此期间，不会启动第三方库，即不会对第三方库进行任何的初始化。

同时参见图2，图2是本申请应用启动方法一实施例的另一流程示意图。为清楚描述本公开实施例所提出的方案，以如下方案进行举例：

步骤S11：接收应用程序的启动指令。

步骤S121：判断预存状态信息是否为同意状态。

当然，因为当前进行在接收应用程序的启动指令后会调用attachBaseContext方法，而attachBaseContext方法中会首先判断当前进程的名称，若当前进程为子进程则直接执行步骤S1222及其后续操作，不会继续执行步骤S121。

其中，若步骤S121的判断结果为是，则相继执行步骤S131：执行应用程序的ContentProvider的onCreate方法，一些第三方库开始初始化，以及步骤S132：应用程序的Application的onCreate方法，一些第三方库开始初始化，初始化完成之后，执行步骤S14：初始化完成之后，显示应用程序界面。

若步骤S121的判断结果为否，则执行步骤S122：启动子进程。通过进程间通信A，子进程中调动attachBaseContext方法，以执行步骤S1221：判断当前进程是否为子进程。若当前进程不是子进程，则继续执行步骤S121。若当前进程是子进程，则继续执行步骤S1222，即显示协议界面。

步骤S1222执行之后，执行步骤S1223：判断用户是否同意用户协议。判断方式包括判断接收到的确定指令为同意用户协议指令还是拒绝用户协议指令。若接收到的同意用户协议指令则意味着接收到了用户输入的对用户协议同意的操作结果，同理，若接收到的是拒绝用户协议指令则意味着接收到了用户输入的对用户协议拒绝的操作结果。

若步骤S1223的判断结果为是，则相继执行步骤S1224：生成同意状态信息以及步骤S1225：更新预存状态信息为同意状态，步骤S1227：关闭当前页面。

若步骤S1223的判断结果为否，则执行步骤S1226：生成拒绝状态信息。此时，子进程结束，关闭当前页面。

其中，若步骤S121的判断结果为否，执行步骤S122：启动子进程之后，原进程继续执行步骤S123：预加载应用程序对应的界面。

之后，执行步骤S124：判断同意状态信息是否存在。步骤S124中，判断同意状态信息是否存在的方式包括通过进程间通信A判断子进程的步骤S1224中是否生成了同意状态信息。具体地，通过判断预设位置是否出现了同意状态信息，本例中，同意状态信息为同意状态文件。

若步骤S124的判断结果为是，则相继执行步骤S131、步骤S132以及步骤S14。当然，在一些实施例中，需要删除本次应用程序中生成的同意状态信息。

若步骤S124的判断结果为否，则执行步骤S125：判断拒绝状态信息是否存在。其中，判断拒绝状态信息是否存在的方式包括通过进程间通信A判断。具体地，通过判断预设位置是否出现了拒绝状态信息，本例中，拒绝状态信息为拒绝状态文件。若步骤S125的判断结果为是，则执行步骤S126：退出应用程序，并执行删除拒绝状态信息的操作。若步骤S125的判断结果为否，则间隔预设时间之后，继续执行步骤S124。

上述方案，通过判断当应用程序的当前用户协议处于同意状态时，才会对应用程序对应的第三方库进行初始化，使得在当前用户协议不处于同意状态的情况下时，第三方库不会开始初始化，即不会存在将包括设备信息在内的用户隐私信息上传至网络的风险，从而在一定程度上提高了对用户隐私的保护。

其中，应用启动方法的执行主体可以是应用启动装置，例如，应用启动方法可以由终端设备或服务器或其它处理设备执行，其中，终端设备可以为安防系统中的监控设备、网络硬盘录像机、用户设备(User Equipment，UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字处理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中，该应用启动方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

请参阅图3，图3是本申请应用启动装置一实施例的结构示意图。应用启动装置30包括指令接收模块31，用于接收应用程序的启动指令；判断模块32，用于判断应用程序的当前用户协议是否处于同意状态；初始化模块33，用于若用户协议处于同意状态的情况下，对应用程序对应的第三方库进行初始化；显示模块34，用于在初始化完成之后，显示应用程序的界面。

上述方案，通过判断当应用程序的当前用户协议处于同意状态时，才会对应用程序对应的第三方库进行初始化，使得在当前用户协议不处于同意状态的情况下时，第三方库不会开始初始化，即不会存在将设备信息上传至网络的风险，从而在一定程度上提高了对用户隐私的保护。

其中，各个模块的功能可参见应用启动方法实施例所述，此处不再赘述。

请参阅图4，图4是本申请电子设备一实施例的结构示意图。电子设备40包括存储器41和处理器42，处理器42用于执行存储器41中存储的程序指令，以实现上述任一应用启动方法实施例中的步骤。在一个具体的实施场景中，电子设备40可以包括但不限于：微型计算机、服务器，此外，电子设备40还可以包括笔记本电脑、平板电脑等移动设备，在此不做限定。

具体而言，处理器42用于控制其自身以及存储器41以实现上述任一应用启动方法实施例中的步骤。处理器42还可以称为CPU(Central Processing Unit，中央处理单元)。处理器42可能是一种集成电路芯片，具有信号的处理能力。处理器42还可以是通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application SpecificIntegrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器42可以由集成电路芯片共同实现。

上述方案，通过判断当应用程序的用户协议处于同意状态时，才会对应用程序对应的第三方库进行初始化，使得在用户协议不处于同意状态的情况下时，第三方库不会开始初始化，即不会存在将包括设备信息在内的用户隐私信息上传至网络的风险，从而在一定程度上提高了对用户隐私的保护。

请参阅图5，图5是本申请计算机可读存储介质一实施例的结构示意图。计算机可读存储介质50存储有能够被处理器运行的程序指令51，程序指令51用于实现上述任一应用启动方法实施例中的步骤。

上述方案，通过判断当应用程序的当前用户协议处于同意状态时，才会对应用程序对应的第三方库进行初始化，使得在当前用户协议不处于同意状态的情况下时，第三方库不会开始初始化，即不会存在将包括设备信息在内的用户隐私信息上传至网络的风险，从而在一定程度上提高了对用户隐私的保护。

在一些实施例中，本公开实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。

上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考，为了简洁，本文不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (10)

1.一种应用启动方法，其特征在于，包括：

接收应用程序的启动指令；

判断所述应用程序的当前用户协议是否处于同意状态；

若所述用户协议处于同意状态的情况下，对所述应用程序对应的第三方库进行初始化；

在所述初始化完成之后，显示所述应用程序的界面。

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

若所述当前用户协议不处于同意状态，则接收用户输入的对所述用户协议同意或拒绝的操作结果，并再次执行所述判断所述应用程序的当前用户协议是否处于同意状态的步骤。

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

若所述用户协议处于拒绝状态，则退出所述应用程序。

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

若判断结果为所述用户协议不处于同意状态，则启动子进程；

在所述子进程中，显示用户协议界面，并响应于用户对所述用户协议界面的输入信息，生成当前所述用户协议的同意状态信息或拒绝状态信息；

再次执行判断所述应用程序的当前用户协议是否处于同意状态的步骤。

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

若判断结果为所述用户协议不处于同意状态，则预加载所述应用程序对应的界面。

6.根据权利要求1所述的方法，其特征在于，所述判断所述应用程序的当前用户协议是否处于同意状态，包括：

读取所述当前用户协议的预存状态信息，并检测所述预存状态信息是否为同意状态；其中，所述预存状态信息是在所述应用程序本次启动之前生成的。

7.根据权利要求6所述的方法，其特征在于，若检测到所述预存状态信息不处于同意状态，则接收用户输入的对所述用户协议同意或拒绝的操作结果并将所述预存状态信息更新为所述操作结果。

8.根据权利要求1所述的方法，其特征在于，所述判断所述应用程序的用户协议是否处于同意状态至所述初始化之间的步骤，通过在所述应用程序的预设启动方法中增加预设代码来实现，其中，所述预设启动方法是在启动所述应用程序时最先调用的方法。

9.一种电子设备，其特征在于，包括存储器和处理器，所述处理器用于执行所述存储器中存储的程序指令，以实现权利要求1至8任一项所述的方法。

10.一种计算机可读存储介质，其上存储有程序指令，其特征在于，所述程序指令被处理器执行时实现权利要求1至8任一项所述的方法。

Images