CN113852983B - 一种获取基带日志的方法及装置 - Google Patents

Abstract

本申请提供一种获取基带日志的方法及装置，所述方法包括：接收配置文件，所述配置文件包括问题小区的标识和所述问题小区的邻区的标识；所述问题小区为在其中使用移动通信功能程序时有终端出现过执行错误的移动通信蜂窝小区；确定第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识是否一致，所述第一小区为所述终端当前所在的移动通信蜂窝小区；在确定所述终端未开始获取基带日志，且所述第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识一致的情况下，开始获取基带日志，所述基带日志用于记录所述终端进入所述问题小区或所述问题小区的邻区后，访问移动通信功能程序的运行过程。

Description

一种获取基带日志的方法及装置

技术领域

本申请涉及计算机存储领域，尤其涉及一种获取基带日志的方法及装置。

背景技术

为保证最终发布的软件产品符合用户的各项要求，在产品正式发布之前，开发者会选择一部分真实用户终端，对产品进行beta测试。服务器可以获取beta测试期间用户终端上传的基带日志，该基带日志可以记录终端在访问移动通信功能程序的运行过程及异常信息，开发者可以根据基带日志对软件产品做进一步的完善。

一般地，在beta测试期间，用户考虑到如果一直开启基带日志权限抓取日志，会给终端带来很大的性能消耗，因此，用户会自己选择基带日志权限的开启时机。例如，用户会在发现某一功能出现问题时，再开启基带日志权限，重新使用出现问题的功能，抓取基带日志。之后关闭抓取日志的权限，把抓取到的基带日志上传到服务器，等到下次又出现其他问题的时候再开启抓取权限。然而这样处理会导致服务器获取到的基带日志较少，beta测试的收效甚微。

由此，如何在减少终端性能损耗的同时获取到足够量的基带日志，成为了技术领域内重要的研究课题。

发明内容

本申请提供一种获取基带日志的方法及装置，用于在获取到足够量的问题日志的同时，减少终端性能损耗。

第一方面，本申请提供一种获取基带日志的方法，应用于终端，该方法包括：接收配置文件，该配置文件包括问题小区的标识和该问题小区的邻区的标识；该问题小区为在其中使用移动通信功能程序时有终端出现过执行错误的移动通信蜂窝小区；该问题小区的邻区为移动通信蜂窝小区中与该问题小区设置有小区切换关系的该问题小区的相邻小区；确定第一小区的标识与该问题小区的标识或该问题小区的邻区的标识是否一致，该第一小区为该终端当前所在的移动通信蜂窝小区；在确定该终端未开始获取基带日志，且该第一小区的标识与该问题小区的标识或该问题小区的邻区的标识一致的情况下，开始获取基带日志，该基带日志用于记录该终端进入该问题小区或该问题小区的邻区后，访问移动通信功能程序的运行过程。

在本申请实施例中，在接收上述配置文件之前，终端可以存储有数据内容为空的配置文件。在终端接收到上述配置文件后，接收到的配置文件替换终端存储的数据内容为空的配置文件，在确定配置文件不为空，配置文件中包括问题小区的标识的情况下，触发终端确定当前所在的第一小区是否为问题小区或问题小区的邻区，若是则开始获取基带日志。也就是说，上述配置文件用于指示终端在确定当前进入的第一小区为问题小区或问题小区的邻区时，开始获取基带日志。

在本申请实施例中，上述问题小区的标识和问题小区的邻区的标识由服务器根据一定的条件确定，具体说明可以参照本申请其他实施例的相关描述(例如下文第二方面的相关描述)，在此不再详述。对于终端而言，终端负责接收配置文件，并根据配置文件中包括的信息(例如问题小区的标识和问题小区的邻区的标识)执行本申请实施例提供的方法。可理解的，该配置文件中对于问题小区的标识和问题小区的邻区的标识可以不做区分，例如，配置文件中包括小区标识，小区标识中不区分是属于问题小区的标识还是属于问题小区的邻区的标识。或者，该配置文件中对于问题小区的标识和问题小区的邻区的标识也可以做相应的区分，例如，配置文件中包括用于存放问题小区的标识的文件夹A，用于存放问题小区的邻区的标识的文件夹B，也就是说存放在文件夹A中的小区的标识是属于问题小区的标识，存放在文件夹B的小区的标识是属于问题小区的邻区的标识，从而区分出哪些是问题小区的标识，哪些是问题小区的邻区的标识。可理解的，具体区分方法还可以为其他方式，本申请实施例对此不做限定。

在本申请实施例中，上述问题小区的邻区，包括问题小区的同频邻区和异频邻区。其中，下行频点相同的两邻区为同频邻区，下行频点不相同的两邻区为异频邻区。

可理解的，终端在当前小区出现的执行错误，可能是终端在当前小区的邻区切换到当前小区时导致的。示例性的，终端在A小区使用移动通信功能程序服务时出现异常问题，有可能是终端从A小区的邻区(例如B小区)切换到A小区时(或者也可以理解为终端在B小区且准备进入A小区时)，终端就已经在B小区开始执行可能在B小区会出现异常的一些功能，只是到进入A小区后终端才获取到执行失败的异常原因值。由此，配置文件中包括问题小区的邻区，当终端接入问题小区或问题小区的邻区后，都获取基带日志，从而可以获取到完整的基带日志，使得采用该基带日志分析异常问题能得到更高的准确性。

可理解的，在确定该终端未开始获取基带日志，且该第一小区的标识与该问题小区的标识或该问题小区的邻区的标识不一致的情况下，不获取基带日志。也就是说，终端在未进入问题小区和问题小区的邻区时，默认不自动获取基带日志。

一般地，在一些需要获取基带日志的场景中(例如beta测试)，终端会默认一直开启获取基带日志的功能权限，获取基带日志。但由于基带日志记录的是终端访问移动通信功能程序的运行过程，数据量或信息量较大，一直获取基带日志会给终端带来很大的性能损耗。用户为减少终端性能损耗一般选择手动实现获取基带日志。例如，用户默认关闭终端获取基带日志的功能权限，关闭终端获取基带日志的功能权限期间，终端一直不获取基带日志。只当用户发现某一功能出现问题时，用户再手动开启获取基带日志的功能权限，获取基带日志，并将基带日志发送给服务器(也可以理解为将日志内容上传给工程师，以便分析问题原因，完善终端相关功能)。但是这种方式，会使得终端获取到的基带日志的数据量较少，也会存在遗漏一些错误(例如遗漏一些用户无法感知的错误)的基带日志信息。

然而，采用本申请实施例提供的获取基带日志的方法，终端在进入问题小区或问题小区的邻区后才会自动开始获取基带日志，而不是一直获取，可以节省终端性能损耗。或者说，终端在进入问题小区或问题小区的邻区后便自动开始获取基带日志，而不是一直不获取，也不是需要用户手动获取，从而可以获取到足够量的基带日志。另外，也可以避免遗漏用户无法感知的基带日志的信息，使得基带日志在软件产品投入使用的进程中(例如beta测试期间)发挥到更高效的作用。

结合第一方面，在一种可能的实施方式中，该配置文件还包括目标异常原因值，该方法还包括：获取一项或多项异常原因值；该异常原因值用于表示该终端访问移动通信功能程序时出现执行错误的错误类型；在该开始获取基带日志之后，该方法还包括：确定该一项或多项异常原因值中是否包括与该目标异常原因值中的至少一项异常原因值一致的第一异常原因值；若是，向服务器发送该基带日志和该第一异常原因值。

在本申请实施例中，上述目标异常原因值为多数终端经常向服务器上报反馈的异常原因值。该目标异常原因值由服务器根据一定的条件确定，具体说明请参照本申请其他实施例的相关描述(例如下文第二方面中的相关描述)，在此不再详述。

在本申请实施例中，向服务器发送该基带日志和该第一异常原因值，从而服务器在接收到基带日志后可以知道该基带日志是与哪些异常原因值对应的日志信息，便于归类存储和处理。也可以告知工程师哪些基带日志是与哪些异常原因值相关的，提高数据处理效率。

采用本申请实施例提供的获取基带日志的方法，终端在获取基带日志的同时也在获取异常原因值，若获取到的基带日志为与上述第一异常原因值对应的基带日志，才会将基带日志上报给服务器。对于与上述第一异常原因值不对应的基带日志，则不将其上报给服务器。从而可以减少终端缓存基带日志的数据量，进一步节省终端性能损耗；也可以减少数据传输中服务器不关注的基带日志的数据量，缓解数据传输的压力；还可以保证向服务器发送的基带日志中包含真实有用的日志信息。

结合第一方面，在一种可能的实施方式中，该向服务器发送该基带日志和该第一异常原因值，具体包括：向服务器发送第一时间段内获取到的基带日志和该第一异常原因值，该第一时间段的起始时刻为开始获取该基带日志的起始时刻，该第一时间段的结束时刻为停止获取该基带日志的时刻。

在本申请实施例中，第一异常原因值可以包括一项或多项目标异常原因值中的异常原因值。

可理解的，若采用向服务器发送一项异常原因值与一段对应的基带日志(例如向服务器发送异常原因值300和异常原因值300出现的时刻前后5分钟内的基带日志)的方式发送基带日志，可能会出现不同的异常原因值和异常原因值对应的基带日志出现数据内容重复的基带日志数据。亦或者，向服务器发送部分基带日志和获取该基带日志期间获取到的多项异常原因值(例如向服务器发送开始获取基带日志到获取到异常原因值300的时刻后一段时间段内的基带日志L，以及获取该基带日志L期间获取到的全部异常原因值300、400、以及500)，则可能会存在无法获取到与最后一个异常原因值对应的完整的基带日志的问题。

而向服务器发送上述第一时间段内获取到的基带日志和第一异常原因值，一方面，获取基带日志期间获取到的基带日志以及异常原因值只会发送一次，可以避免发送重复数据内容所带来的数据冗余、数据传输压力、存储空间利用率等问题。也可以避免向服务器发送部分基带日志和获取该基带日志期间获取到的多项异常原因值，可能导致的无法获取到与最后一个异常原因值对应的完整的基带日志的问题。另外一方面，将可能与出现异常原因值相关的只要能获取到基带日志均发送给服务器，可以有效避免遗漏重要的导致出现执行错误的部分基带日志内容。

结合第一方面，在一种可能的实施方式中，该向服务器发送该基带日志和该第一异常原因值，具体包括：向服务器发送第二时间段内获取到的基带日志和第一异常原因值，该第二时间段的起始时刻为开始获取该基带日志的起始时刻，该第一时间段的结束时刻为获取到该第一异常原因值的第一时刻加上第一预设时长后的时刻。

可理解的，有时候某一目标功能程序出现程序执行错误，有可能是在使用该目标功能程序之前使用了某一潜在的功能程序导致的。从而将上述第二时间段内的获取到的基带日志发送给服务器，可以使得服务器获取到较完整的基带日志数据；同时，第一异常原因值出现的时刻第一预设时长之后获取到的基带日志不再发送给服务器，可以减少数据传输压力、存储空间占用等。

结合第一方面，在一种可能的实施方式中，该向服务器发送该基带日志和该第一异常原因值，具体包括：向服务器发送第三时间段内获取到的基带日志和第一异常原因值，该第三时间段的起始时刻为获取到该第一异常原因值的第一时刻减去第二预设时长后的时刻，该第三时间段的结束时刻为获取到该第一异常原因值的第一时刻加上第三预设时长后的时刻。

在本申请实施例中，上述第一异常原因值可以只包括一项异常原因值。例如，该第一异常原因值为300，则打包出现异常原因值300的时刻(例如a1时刻)之前第二预设时长到a1时刻之后第三预设时长内获取到的基带日志。又例如，第一异常原因值为400，则打包出现异常原因值400的时刻(例如a2时刻)之前第二预设时长到a2时刻之后第三预设时长内获取到的基带日志。也就是说，异常原因值可以与基带日志一一对应。

在另外一种实现方式中，也可以将第三时间段内获取到除了第一异常原因值(例如300)之外的其他异常原因值(例如400、500)作为附带异常原因值一起发送给服务器。也就是说，异常原因值300、第三时间段获取到的基带日志、以及该附带异常原因值(400、500)两两之间一一对应。

可理解的，与一项异常原因值相关的基带日志为，出现该异常原因值的时刻起前后一段时间内获取到的基带日志。从而可以将获取到第一异常原因值时上述第三时间段内获取到的基带日志发送给服务器。一方面，避免将与第一异常原因值相关性不大的基带日志发送给服务器，带来的数据传输压力；另外一方面，减少与导致出现第一异常原因值不相关的基带日志的数据量，发送给服务器的基带日志均为与导致出现第一异常原因值相关性较强的基带日志，也可有效减轻筛选分析基带日志的工作量。

结合第一方面，在一种可能的实施方式中，在该确定第一小区的标识与该问题小区的标识或该问题小区的邻区的标识是否一致之前，该方法还包括：确定该终端的当前电量是否大于或等于第一阈值；该确定第一小区的标识与该问题小区的标识或该问题小区的邻区的标识是否一致具体包括：在确定该终端的电量大于或等于该第一阈值的情况下，确定该第一小区的标识与该问题小区的标识或该问题小区的邻区的标识是否一致。

可理解的，综合考量终端当前电量，均衡功耗和性能，在终端电量满足条件的情况下，再执行确定动作(也即确定终端是否进入问题小区或问题小区的邻区的确定动作)，若终端电量不满足条件，则可以不执行确定动作，可以减少执行不必要的确定动作带来的性能消耗。

结合第一方面，在一种可能的实施方式中，在该开始获取基带日志之后，该方法还包括：在确定该第一小区标识与该问题小区的标识不一致，且与该问题小区的邻区的标识不一致的情况下，停止获取该基带日志。

在本申请实施例中，当终端开始获取基带日志后，可以周期性地确定终端是否离开了问题小区和问题小区的邻区；若是则停止获取基带日志。在保证获取到足够量的基带日志的同时，进一步降低终端性能损耗。

结合第一方面，在一种可能的实施方式中，在该开始获取基带日志之后，该方法还包括：在确定该第一小区标识与该问题小区的标识或该问题小区的邻区的标识一致的情况下，确定该终端的当前电量是否小于第一阈值；在确定该终端的当前电量小于第一阈值的情况下，停止获取该基带日志。

在本申请实施例中，在终端当前还未离开问题小区或问题小区的邻区的情况，当终端确定到当前电量小于第一阈值时，停止获取基带日志。

可理解的，综合考量终端当前电量，均衡功耗和性能，优化自动开始和停止获取基带日志的时机，可以在获取到足够量的基带日志的同时，进一步减少终端性能损耗，满足用户多元需求。也可以避免终端电量告急，造成的响应迟缓等问题。

结合第一方面，在一种可能的实施方式中，在该开始获取基带日志之后，该方法还包括：在确定该第一小区标识与该问题小区的标识或该问题小区的邻区的标识一致的情况下，确定该终端当前是否运行目标应用，该目标应用为性能消耗需求较高的应用程序；在确定该终端运行目标应用的情况下，停止获取该基带日志。

可理解的，综合考量终端当前是否正在运行性能消耗较大的应用程序等因素，更智能化地自动开启和关闭modemlog，从而减少终端运行开销，避免终端同时运行性能消耗要求较大的功能程序，造成的响应迟缓等问题。

结合第一方面，在一种可能的实施方式中，该终端包括显示屏，该配置文件还包括目标异常原因值，该方法还包括：确定该目标异常原因值是否包括预设异常原因值中的至少一项异常原因值；该预设异常原因值包括：通话类异常原因值中的与主叫业务相关的异常原因值，和数据业务类异常原因值，该主叫业务包括该终端向其他终端发起的通话请求，该数据业务类异常原因值包括该终端请求访问移动通信网络数据；该在确定该终端未开始获取基带日志，且该第一小区的标识与该问题小区的标识或该问题小区的邻区的标识一致的情况下，开始获取基带日志，具体包括：在确定该终端未开始获取基带日志，该第一小区的标识与该问题小区的标识或该问题小区的邻区的标识一致，以及该目标异常原因值包括该预设异常原因值中的至少一项异常原因值的情况下，在确定该显示屏处于亮屏状态后，开始获取基带日志。

在本申请实施例中，对于终端只有在亮屏后执行操作(例如主叫业务)才会导致的目标异常原因值，终端在确定显示屏处于亮屏状态后再开始获取基带日志，熄屏状态下则不获取基带日志。可理解的，对于用户而言，真正关注的大多是用户访问移动网络请求获取网络数据内容时出现的执行错误，所以对于数据类业务的异常原因值也可以在显示屏处于亮屏状态下再开始获取基带日志。从而一方面，可以不用获取熄屏状态的基带日志，在获取到足够量的基带日志的同时减少终端性能损耗；另外一方面，可以提高获取到的基带日志中有效基带日志的概率。

可理解的，本申请实施例所描述的获取基带日志也可以称为抓取基带日志，获取基带日志可以理解为开启抓取基带日志的功能权限。本文其他地方关于获取基带日志的描述均与此相同。

第二方面，本申请提供一种获取基带日志的方法，应用于服务器，该方法包括：接收终端群组中的至少一个终端发送的应用程序层日志；其中，一个应用程序层日志包括一项或多项异常原因值和第二小区的标识，该异常原因值用于表示终端访问通信功能程序出现执行错误的错误类型，该第二小区为终端发送包含该一项或多项异常原因值的应用程序层日志时所在的移动通信蜂窝小区；从该至少一个终端发送的应用程序层日志中包括的异常原因值中确定目标异常原因值和问题小区的标识，该目标异常原因值的上报次数满足第一预设条件，该上报次数为该服务器接收到的包括该目标异常原因值的应用程序层日志的数目，该问题小区包括与该目标异常原因值中的任一项异常原因值对应的该第二小区；根据邻区关系表确定该问题小区的邻区的标识；该邻区关系表用于记录小区的标识和小区的邻区的标识的关联关系；向该终端群组中的部分或全部终端发送配置文件，该配置文件包括该问题小区的标识、以及该问题小区的邻区的标识，该配置文件用于指示终端在确定终端当前所在的第一小区的标识与该问题小区的标识或该问题小区的邻区的标识一致的情况下，开始获取基带日志，该基带日志用于记录该终端进入该问题小区或该问题小区的邻区后，访问移动通信功能程序的运行过程。

在本申请实施例中，服务器中可以存储有终端群组的信息(例如终端1～终端n的终端ID)，该终端群组也可以理解为用户群组(例如beta测试的用户终端群组)。服务器可以与终端群组中的每个终端进行数据通信。可理解的，服务器与终端群组的关系可以是，服务器可以为终端群组中的每个终端提供软件运行支持或软件维护服务。可理解的，服务器与终端群组的关系还可以为其他关系；例如，服务器还可以是软件产品正式发布使用的后台服务器，终端群组为向服务器申请使用该软件产品的用户终端。本申请实施例对于服务器和终端群组的具体关系不做限定。

采用本申请实施例提供的方法，服务器向终端群组中的部分或全部终端发送配置文件，使得该部分或全部终端根据配置文件的指示，在确定第一小区的标识与问题小区的标识或问题小区的邻区的标识一致的情况下，开始获取基带日志。一方面，终端在进入问题小区或问题小区的邻区后再开始获取基带日志，而不是一直获取，可以减少终端性能损耗。另外一方面，终端群组中的部分或全部终端，在进入问题小区或问题小区的邻区后均开始获取基带日志，而不是一直不获取或需要用户手动获取，从而可以获取到足够量的基带日志。

结合第二方面，在一种可能的实施方式中，该向该终端群组中的部分或全部终端发送配置文件，具体包括：从该终端群组中，根据历史小区记录表确定进入过该问题小区或该问题小区的邻区的目标终端，该历史小区记录表用于记录小区的标识与进入过小区的终端的标识的关联关系；向该目标终端发送该配置文件。

可理解的，目标终端向服务器上报目标异常原因值，除了目标终端之外的其他终端没有向服务器上报目标异常原因值，可能是因为除了目标终端之外的其他终端运行出现执行错误的功能程序的概率不大，或者出现执行错误与个别终端的硬件资源相关或与个别用户的错误操作相关。从而可以只向进入过问题小区或问题小区的邻区的目标终端发送配置文件，不向除了目标终端之外的其他终端发送配置文件，避免由于除了目标终端之外的其他终端不运行出现执行错误的功能程序，或目标异常原因值与个别终端硬件资源相关或与个别用户的错误操作相关，在该除了目标终端之外的其他终端中不会出现异常原因值，但终端又会根据配置文件的指示获取基带日志，导致运行资源占用、存储空间占用等性能损耗问题。

结合第二方面，在一种可能的实施方式中，该配置文件还包括目标异常原因值，该方法还包括：接收基带日志和第一异常原因值，该第一异常原因值为该终端在获取该基带日志期间获取到的至少一项异常原因值，且该第一异常原因值与该目标异常原因值中的至少一项异常原因值一致。

可理解的，服务器关注的与目标异常原因中的至少一项异常原因值对应的基带日志为有效数据；而对于服务器不关注的，获取基带日志期间未出现异常原因值或出现的异常原因值与服务器所需的目标异常原因值不一致的日志信息则为无效数据。服务器接收上述基带日志均为与上述第一异常原因值对应的基带日志，也即服务器接收的基带日志均为有效数据，从而可以减少无效数据的数据传输带来的数据传输压力，在确保获取到足够量的基带日志的同时，进一步减少终端存储空间占用等性能消耗问题。

结合第二方面，在一种可能的实施方式中，该接收基带日志和第一异常原因值，具体包括：接收该终端发送的第一时间段内获取到的基带日志和该第一异常原因值，该第一时间段的起始时刻为开始获取该基带日志的起始时刻，该第一时间段的结束时刻为停止获取该基带日志的时刻。

可理解的，若服务器接收一项异常原因值与一段对应的基带日志(例如服务器接收异常原因值300和异常原因值300出现的时刻前后5分钟内的基带日志)，则可能会出现不同的异常原因值和异常原因值对应的基带日志出现数据内容重复的基带日志数据。亦或者，服务器接收部分基带日志和获取该基带日志期间获取到的多项异常原因值(例如服务器接收开始获取基带日志到获取到异常原因值300的时刻后一段时间段内的基带日志L及获取该基带日志L期间获取到的全部异常原因值300、400、以及500)，则可能会存在无法获取到与最后一个异常原因值对应的完整的基带日志的问题。

而采用本申请实施例提供的方法，服务器接收第一时间段内获取到的全部基带日志和第一异常原因值，也即服务器只会接收一次终端获取基带日志期间获取到的基带日志以及异常原因值，可以避免接收重复数据内容所带来的数据冗余、数据传输压力、存储空间利用率等问题。

结合第二方面，在一种可能的实施方式中，该接收基带日志和第一异常原因值，具体包括：接收该终端发送的第二时间段内获取到的基带日志和该第一异常原因值，该第二时间段的起始时刻为开始获取该基带日志的起始时刻，该第一时间段的结束时刻为获取到该第一异常原因值的第一时刻加上第一预设时长后的时刻。

可理解的，有时候某一目标功能程序出现程序执行错误，有可能是在使用该目标功能程序之前使用了某一潜在的功能程序导致的。从而服务器接收上述第二时间段内的基带日志，可以获取到较完整的基带日志数据；同时，服务器可以不接收第一异常原因值出现的时刻第一预设时长之后的基带日志，可以减少数据传输压力、存储空间占用等。

结合第二方面，在一种可能的实施方式中，该接收基带日志和第一异常原因值，具体包括：接收该终端发送的第三时间段内获取到的基带日志和该第一异常原因值，该第三时间段的起始时刻为获取到该第一异常原因值的第一时刻减去第二预设时长后的时刻，该第三时间段的结束时刻为获取到该第一异常原因值的第一时刻加上第三预设时长后的时刻。

可理解的，与一项异常原因值相关的基带日志为，出现该异常原因值的时刻起前后一段时间内获取到的基带日志。从而服务器接收上述第三时间段内的基带日志，一方面，可以避免将与第一异常原因值相关性不大的基带日志发送给服务器，带来的数据传输压力；另外一方面，减少与导致出现第一异常原因值不相关的基带日志的数据量，服务器接收的基带日志均为与导致出现第一异常原因值相关性较强的基带日志，可以有效减轻服务器或工程师筛选分析基带日志的工作量。

结合第二方面，在一种可能的实施方式中，该目标异常原因值的上报次数满足第一预设条件，具体包括：该目标异常原因值的上报次数大于或等于第二阈值。

可理解的，采用判断上报次数是否满足第二阈值的异常原因的方式确定目标异常原因，确定方法简单，可以减少程序运算的复杂度，以及减少数据统计带来的性能损耗。

结合第二方面，在一种可能的实施方式中，在该接收至少一个终端发送的应用程序层日志之后，该方法还包括：统计该至少一个终端发送的应用程序层日志中包括的异常原因值中每个异常原因值的上报次数，并将该上报次数由大到小排序，得到排序结果；该目标异常原因值的上报次数满足第一预设条件，具体包括：该目标异常原因值的上报次数在该排序结果中排名前M，该M为大于或等于1的正整数。

在本申请实施例中，上述统计该上报次数可以为，在将上述上报次数存储到数据库表或表格中时，按照由小到大排序插入的方式存储，由此得到由大到小排序的上报次数。

可理解的，采用统计上报次数由大到小排名前M的异常原因值的方式确定目标异常原因值，可以避免异常原因值均不大于某一预设阈值导致异常原因值为空的问题。

第三方面，本申请提供一种获取基带日志的方法，应用于服务器和终端，该方法包括：该服务器接收终端群组中的至少一个该终端发送的应用程序层日志；其中，一个应用程序层日志包括一项或多项异常原因值和第二小区的标识，该异常原因值用于表示终端访问通信功能程序出现执行错误的错误类型，该第二小区为终端发送包含该一项或多项异常原因值的应用程序层日志时所在的移动通信蜂窝小区；该服务器从该至少一个终端发送的应用程序层日志中包括的异常原因值中确定目标异常原因值，以及问题小区的标识，该目标异常原因值的上报次数满足第一预设条件，该上报次数为该服务器接收到的包括该目标异常原因值的应用程序层日志的数目，该问题小区包括与该目标异常原因值中的任一项异常原因值对应的该第二小区；该服务器根据邻区关系表确定该问题小区的邻区的标识；该邻区关系表用于记录小区的标识和小区的邻区的标识的关联关系；该服务器向该终端群组中的部分或全部该终端发送配置文件，该配置文件包括该问题小区的标识、以及该问题小区的邻区的标识；该终端接收该配置文件，并确定第一小区的标识与该问题小区的标识或该问题小区的邻区的标识是否一致，该第一小区为该终端当前所在的移动通信蜂窝小区；该终端在确定未开始获取基带日志，且该第一小区的标识与该问题小区的标识或该问题小区的邻区的标识一致的情况下，开始获取基带日志，该基带日志用于记录该终端进入该问题小区或该问题小区的邻区后，访问移动通信功能程序的运行过程。

采用本申请实施例提供的方法，终端群组中的部分或全部终端，在确定终端进入问题小区或问题小区的邻区的情况下，自动开始获取基带日志，而不是一直获取、一直不获取或需要用户手动获取。从而可以在获取到足够量的基带日志的同时，减少终端性能损耗。

关于终端群组、异常原因值、配置文件等名称的详细说明可以参照本申请其他实施例的相关描述(例如上述第一方面和第二方面)，在此不再详述。

结合第三方面，在一种可能的实施方式中，该方法还包括：该终端获取一项或多项异常原因值，并确定该一项或多项异常原因值中是否包括与该目标异常原因值中的至少一项异常原因值一致的第一异常原因值；若是则向服务器发送该基带日志以及该第一异常原因值；该服务器接收该终端发送的该基带日志以及该第一异常原因值。

可理解的，终端在获取基带日志的同时也在获取应用程序层日志(异常原因值)，若终端确定在获取基带日志期间再次出现了获取到目标异常原因值中的任一项异常原因值的情况下，才会将获取到的基带日志上传给服务器，从而保证服务器接收到的基带日志中包含真实有用的日志数据。

结合第三方面，在一种可能的实施方式中，该向服务器发送该基带日志以及该第一异常原因值，具体包括：向服务器发送第一时间段内获取到的基带日志和该第一异常原因值，该第一时间段的起始时刻为开始获取该基带日志的起始时刻，该第一时间段的结束时刻为停止获取该基带日志的时刻。

结合第三方面，在一种可能的实施方式中，该向服务器发送该基带日志以及该第一异常原因值，具体包括：向服务器发送第二时间段内获取到的基带日志和该第一异常原因值，该第二时间段的起始时刻为开始获取该基带日志的起始时刻，该第一时间段的结束时刻为获取到该第一异常原因值的第一时刻加上第一预设时长后的时刻。

结合第三方面，在一种可能的实施方式中，该向服务器发送该基带日志以及该第一异常原因值，具体包括：向服务器发送第三时间段内获取到的基带日志和该第一异常原因值，该第三时间段的起始时刻为获取到该第一异常原因值的第一时刻减去第二预设时长后的时刻，该第三时间段的结束时刻为获取到该第一异常原因值的第一时刻加上第三预设时长后的时刻。

结合第三方面，在一种可能的实施方式中，在该确定第一小区的标识与该问题小区的标识或该问题小区的邻区的标识是否一致之前，该方法还包括：确定该终端的当前电量是否大于或等于第一阈值；该确定第一小区的标识与该问题小区的标识或该问题小区的邻区的标识是否一致具体包括：在确定该终端的电量大于或等于该第一阈值的情况下，确定该第一小区的标识与该问题小区的标识或该问题小区的邻区的标识是否一致。

结合第三方面，在一种可能的实施方式中，在该开始获取基带日志之后，该方法还包括：在确定该第一小区标识与该问题小区的标识不一致，且与该问题小区的邻区的标识不一致的情况下，终端停止获取该基带日志。

结合第三方面，在一种可能的实施方式中，在该开始获取基带日志之后，该方法还包括：在确定该第一小区标识与该问题小区的标识或该问题小区的邻区的标识一致的情况下，确定该终端的当前电量是否小于第一阈值；在确定该终端的当前电量小于第一阈值的情况下，终端停止获取该基带日志。

结合第三方面，在一种可能的实施方式中，该终端包括显示屏，该配置文件还包括目标异常原因值，该方法还包括：确定该目标异常原因值是否包括预设异常原因值中的至少一项异常原因值；该预设异常原因值包括：通话类异常原因值中的与主叫业务相关的异常原因值，和数据业务类异常原因值，该主叫业务包括该终端向其他终端发起的通话请求，该数据业务类异常原因值包括该终端请求访问移动通信网络数据；该在确定该终端未开始获取基带日志，且该第一小区的标识与该问题小区的标识或该问题小区的邻区的标识一致的情况下，开始获取基带日志，具体包括：在确定该终端未开始获取基带日志，该第一小区的标识与该问题小区的标识或该问题小区的邻区的标识一致，以及该目标异常原因值包括该预设异常原因值中的至少一项异常原因值的情况下，在确定该显示屏处于亮屏状态后，开始获取基带日志。

关于上述第三方面中一些实施方式的有益效果的说明可以参照本申请其他实施例的相关描述(例如第一方面或第二方面的相关描述)，在此不再详述。

第四方面，一种获取基带日志的系统，包括终端和服务器，该终端用于执行本申请实施例中第一方面或第一方面的任一实现方式所示的方法，该服务器用于执行本申请实施例中第二方面或第二方面的任一实现方式所示的方法。

可以理解的，上述第四方面提供的获取基带日志的系统中的终端用于执行本申请实施例第一方面或第一方面的任一实现方式所示的方法，服务器用于执行本申请实施例中第二方面或第二方面的任一实现方式所示的方法。因此，其所能达到的有益效果可参考对应方法中的有益效果，此处不再赘述。

第五方面，本申请实施例提供一种电子设备，该电子设备包括：一个或多个处理器和存储器；该存储器与该一个或多个处理器耦合，该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令，该一个或多个处理器调用该计算机指令以使得该电子设备执行第一方面或第一方面的任意可能的实现方式中的方法，或执行第二方面或第二方面的任意可能的实现方式中的方法，或执行第三方面或第三方面的任意可能的实现方式中的方法。

第六方面，本申请实施例提供一种芯片系统，该芯片系统应用于电子设备，该芯片系统包括一个或多个处理器，该处理器用于调用计算机指令以使得该电子设备执行该第一方面或第一方面的任意可能的实现方式所示的方法，或执行第二方面或第二方面的任意可能的实现方式中的方法，或执行第三方面或第三方面的任意可能的实现方式中的方法。

第七方面，本申请实施例提供一种包含指令的计算机程序产品，当该计算机程序产品在电子设备上运行时，使得该电子设备执行该第一方面或第一方面的任意可能的实现方式所示的方法，或执行第二方面或第二方面的任意可能的实现方式中的方法，或执行第三方面或第三方面的任意可能的实现方式中的方法。

第八方面，本申请实施例提供一种计算机可读存储介质，包括指令，其特征在于，当该指令在电子设备上运行时，使得该电子设备执行该第一方面或第一方面的任意可能的实现方式所示的方法，或执行第二方面或第二方面的任意可能的实现方式中的方法，或执行第三方面或第三方面的任意可能的实现方式中的方法。

可以理解的，上述第五方面提供的电子设备、第六方面提供的芯片系统、第七方面提供的计算机程序产品和第八方面提供的计算机存储介质均用于执行本申请实施例第一方面或第一方面的任一实现方式所示的方法，或本申请实施例中第二方面或第二方面的任一实现方式所示的方法，或本申请实施例中第三方面或第三方面的任一实现方式所示的方法。因此，其所能达到的有益效果可参考对应方法中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的邻区关系示意图；

图2为本申请实施例提供的终端向服务器发送aplog的示意图；

图3为本申请实施例提供的当终端进入异常小区后开启抓取基带日志(modemlog)的功能权限的场景示意图；

图4为本申请实施例提供的一种获取modemlog的方法的系统架构图；

图5为本申请实施例提供一种获取modemlog的方法的流程示意图；

图6为本申请实施例提供又一种获取modemlog的方法的流程示意图；

图7为本申请实施例提供小区上报异常原因值的场景示意图；

图8为本申请实施例提供确定top异常原因值的示意图；

图9为本申请实施例提供的确定问题小区的示意图；

图10为本申请实施例提供的一种服务器向终端发送配置文件的示意图；

图11为本申请实施例提供的另外一种服务器向终端发送配置文件的示意图；

图12为本申请实施例提供的一种终端进入异常小区后开启抓取modemlog的功能权限的场景示意图；

图13为本申请实施例提供的一种打包t＝0～t2时间段内的modemlog的示意图；

图14为本申请实施例提供的打包t＝0～(t1+T)时间段内的modemlog的示意图；

图15为本申请实施例提供的打包(t1-T)～(t1+T)时间段内的modemlog的示意图；

图16为本申请实施例提供的一种终端离开异常小区后关闭抓取modemlog的功能权限的场景示意图；

图17为本申请实施例提供又一种获取modemlog的方法的流程示意图；

图18为本申请实施例提供又一种获取modemlog的方法的流程示意图；

图19为本申请实施例提供又一种获取modemlog的方法的流程示意图；

图20为本申请实施例提供一种根据异常原因值的类型确定modemlog开启策略的示意图；

图21～图22为本申请实施例提供又一种获取modemlog的方法的流程示意图；

图23为本申请实施例提供的终端200的结构示意图；

图24是本申请实施例的终端200的软件结构框图；

图25是本申请实施例的服务器300的硬件结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地描述。

本申请的说明书、权利要求书及附图中的术语“第一”和“第二”等仅用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备等，没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元等，或可选地还包括对于这些过程、方法、产品或设备等固有的其它步骤或单元。

在本文中提及的“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员可以显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上，“至少两个(项)”是指两个或三个及三个以上，“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”。

为了便于理解，下面先对本申请实施例涉及的相关术语及相关概念进行介绍。

(1)beta测试：

一般地，软件产品在发布之前会经过以下两个阶段的用户验收测试。一个阶段是alpha，是由开发团队中的测试人员或其他企业内部的测试人员模拟各类用户行为对软件产品进行的测试。另外一个阶段则是beta测试，是由部分真实用户(可理解为软件产品的交付方或软件产品的受众用户群体)在实际使用环境下对软件产品进行的测试，并定期或不定期把beta测试中遇到的问题日志上报给开发人员，以便于软件产品功能的改进和完善。

(2)小区、邻区：

在移动通信系统中，一个基站或基站的一部分(例如扇形天线)所覆盖的区域即为小区，在这个区域内终端可以通过无线信道可靠地与基站进行通信。具体的，基站可以理解为无线电收发装置或移动通信基站，是终端接入互联网的接口设备。在该基站的无线电覆盖区域(小区)中，基站可以通过移动通信交换中心与终端进行信息交互(例如需要使用移动网络的网络请求和交互，比如打电话、2g/3g/4g/5g上网等)。

一般地，无线电所覆盖的区域有重叠并设置有切换关系的两个小区，互为邻区(也可以理解为相邻小区)，一个小区可以有一个或多个相邻小区。邻区类型有同频邻区(下行频点相同的两邻区称为同频邻区)和异频邻区(下行频点不相同的两邻区称为异频邻区)。关于邻区类型，此处仅为示例，还可以为其他的邻区类型，本申请实施例对此不做限定。

示例性的，如图1所示，A小区的邻区包括B小区；B小区的邻区包括D小区；C小区的邻区包括D小区；D小区的邻区包括B小区和C小区。可理解的，为小区和该小区的邻区之间设置切换关系，使得终端在移动状态下可以在多个定义了邻区关系的小区之间进行业务的平滑交替，不会中断。

可理解的，终端的搜网程序可以搜索本机能够接入的众多小区中网络信号强度最好的目标小区。进而向基站发出请求建立终端与该目标小区的数据连接，以便目标小区为终端提供打电话、上网等服务。基站响应于该请求，若同意建立连接，则会将该目标小区和该目标小区的ID的邻区的ID信息发送给终端。若终端与该目标小区成功建立数据连接，则终端确定当前所在小区的ID即为该目标小区的ID。也就是说，终端侧包含有终端当前所在的目标小区的ID和该目标小区的邻区的ID等信息。

(3)应用程序层日志(application log，aplog)：

在本申请实施例中，应用程序层日志(aplog)用于记录终端应用层出现功能异常时的错误信息。示例性的，程序无响应或强行关闭，驱动程序等出现了启动问题等的一些记录。例如，应用使用问题(包括系统应用和第三方应用的使用问题)，无线网络问题(移动网络、wifi、个人热点、蓝牙、NFC等)，或电子设备稳定性、升级、性能等问题。

在本申请实施例中，由用户终端抓取aplog，并将抓取到的aplog发送到服务器，从而服务器可以分析终端在使用过程中遇到的问题(例如通信问题)，以便工程师科学合理地制定产品的完善和改进等工作内容。可理解的，该服务器是指与终端厂商对应的服务器。

示例性的，在终端群组对服务器为终端提供的移动网络的功能程序产品进行beta测试的测试场景中。服务器中存储有beta测试的终端群组的标识(ID)，如下表1所示服务器存储的终端群组的ID包括终端1至终端n(n为大于1的正整数)的ID。

终端群组
	终端1的ID
终端2的ID
	...
终端n的ID

表1

如图2所示，由上述表1中的终端1至终端n，抓取aplog，并向服务器上报(也可以理解为发送)抓取到的aplog。可理解的，若终端未抓取到aplog则可以不向服务器发送aplog。在本申请实施例中，一条aplog的数据内容至少包括异常原因值、终端出现异常原因值时所在的小区的标识(Identity document，ID)。可理解的，此处关于aplog包括的数据包容仅为示例，该aplog还可以包括其他数据内容(例如，aplog中还包括终端ID)，本申请实施例对此不做限定。

示例性的，服务器接收终端发送的aplog，并存储aplog。如下表2所示，可以在服务器中通过建立异常原因值和小区的ID的关联关系的方式，存储aplog的数据内容。该aplog表中异常原因值与终端出现该异常原因值时所在的小区的ID不是一一对应的关系，而是一对多的关系。示例性的，异常原因值300(一)与A小区和B小区(多)对应，B小区(一)与异常原因值300和400(多)对应。

可理解的，一个终端也可以同一时间同时上传多个异常原因值，例如表2中，异常原因值列中每一项(每一行)中可以包括一个或多个异常原因值，本申请实施例对此不做限定。

表2

不难理解的，异常原因值也可以理解为错误码。例如，错误码400表示用户端访问被拒绝。此处对错误码400表示用户端访问被拒绝的描述仅为示例，不同的厂商可以自定义错误码的具体涵义，本申请实施例对此不做限定。可理解的，终端侧出现的移动网络问题有可能与当前进入的通信小区有关联，由此aplog中可以包括终端出现异常原因时所在的小区的ID。

可理解的，此处关于服务器存储aplog的方式仅为示例，服务器还可以通过其他方式存储aplog(例如，通过创建异常原因值、小区的ID以及出现次数的关联关系的方式，出现次数是指异常原因值在对应的小区中出现的次数)，本申请实施例对此不做限定。

由于aplog的数据量较小(例如，aplog的大小为1兆)，终端一般默认开启抓取aplog的功能。且一般地，可以不向用户开放关闭抓取aplog的权限。或者，也可以向用户开放关闭抓取aplog的权限；因为向服务器上报本机的异常问题，可以让工程师帮助解决本机的异常问题，且终端抓取aplog所需性能消耗较少，所以一般大量用户不会关闭抓取aplog的功能。由此，服务器可以获取到大量终端的aplog。

(4)CHR大数据：

在本申请实施例中，服务器在接收到用户终端发送的aplog后，可以对用户终端出现的异常原因值进行数据统计，分析用户终端中大量出现的异常问题。

示例性的，在采用终端群组对服务器为终端提供的移动网络的功能程序产品进行beta测试的场景中，服务器在接收到终端发送的aplog后，统计aplog中与移动网络对应的异常原因值的上报次数，记为通讯历史记录(communication history record，CHR)大数据。例如，如下表3所示，若与移动网络对应的异常原因值包括300、400和600，则统计aplog中异常原因值300、400和600的上报次数。可理解的，该上报次数是指服务器接收到的某一异常原因值的上报次数，该某一异常原因值为终端群组中的一个或多个终端上报给服务器的。该上报次数也可以理解为上述aplog表中，某一异常原因值出现的次数。

异常原因值	上报次数
		300	10
400	9
		600	1
...	...

表3

(5)基带日志(modemlog)：

基带(baseband)包含于电子设备中的移动通信模块。负责完成移动通信过程中无线信号的解调、解扰、解扩和解码工作，并将最终解码完成的数字信号传递给上层处理系统进行处理。从而为电子设备提供通话、短消息、上网、以及UIM卡等功能。在本申请实施例中，基带的具体形态可以为芯片。

可理解的，基带所具备的功能(对移动无线信号的解调、解扰、解扩和解码等功能)与调制解调器(modem)的功能相近。也即，基带也可以理解为集成到电子设备中的用于移动通信无线传输的无线调制解调器。由此，基带日志可以称为调制解调日志，也即基带日志可以称为modemlog。可理解的，此处对于基带日志称为modemlog的描述仅为示例，不同厂商对基带日志有不同的指代名称，例如还可以用追踪日志(tracelog)指代该基带日志。

在本申请实施例中，modemlog用于记录电子设备中基带的运行过程及异常信息。可以为快速定位系统运行中出现的问题及开发过程中的程序调试问题提供详细信息。

示例性的，上述aplog中记录有出现异常的异常原因值，但该异常原因值只是一种抽象的错误类型，没有记录具体出现异常的详细信息。例如，异常原因值300表示通话掉线，但不能从异常原因值300中得出通话掉线的具体原因(例如，是通话中的某一方的信号问题，或者是通话中的某一方在通话过程中进行小区切换且切换失败等可能导致通话掉线的原因)。又例如，用户终端在使用某一应用时出现卡顿，并上报异常原因400，异常原因400表示网络慢或者是刷新异常，但不能从异常原因400中得出卡顿的具体原因(例如，是终端当前所在的小区信号弱导致的卡顿，或者是终端侧用户在使用移动网络时进行切换小区导致网络掉线而卡顿等)。而modemlog包括功能程序运行的详细信息，可以根据modemlog中的日志信息回溯问题现场，查找出现该异常原因值的具体原因。

可理解的，终端移动网络的软件程序除了应用程序本身的功能之外，还需要与其他电子设备(例如基站等)进行通信，功能复杂。从而导致终端的移动网络的软件程序的出现某一异常原因值的具体原因多种多样，情况复杂，由此需要获取modemlog，得到程序运行的详细信息，分析出现异常的具体原因。但是对于非移动网络的软件程序，例如拍照、录像等软件程序，只涉及到软件程序本身的功能，不涉及多端交互，网络响应等的问题，异常原因一般从aplog中就能确定到。且由于非移动网络的软件程序不涉及移动通信功能程序，非移动网络的软件程序运行时不会调用基带芯片的通信功能，一般不涉及modemlog。这也是上述CHR大数据中，以统计aplog中与移动网络对应的异常原因值的上报次数为例，说明如何统计CHR大数据的一个原因。

下面结合上述术语描述和几种其他获取基带日志的实现方式，对比说明本申请实施例中获取基带日志的方法的优势：

在一种获取基带日志的实现方式中，终端持续开启抓取基带日志(modemlog)的功能权限，一直抓取modemlog，并定期将抓取到的modemlog上报给服务器。从而服务器可以获取到大量的modemlog，以便于对出现异常的地方做问题回溯分析。但是这种方式中，由于modemlog包括终端功能程序运行的详细信息，一直抓取modemlog会给终端带来很小的性能损耗。

在另外一种获取基带日志的实现方式中，为减少终端抓取modemlog的性能损耗，用户选择自定义抓取modemlog的时机。示例性的，当用户感知到终端运行某一A功能出现某一异常问题X时，再开启抓取modemlog的功能；再次使用该A功能，当发现该异常问题X再次复现后，关闭抓取modemlog的功能，并将抓取到的modemlog上报给服务器。这种方式能减少终端性能损耗，但是一方面，会使得服务器接收到modemlog数据量很少，很可能不能准确地分析出问题所在。另外一方面，若终端出现用户无法感知的异常问题，则用户不会上传对应的modemlog，从而导致服务器获取到的modemlog不全面，无法全面分析终端出现的异常问题做出准确的改进措施。

又在另外一种获取基带日志的实现方式中，服务器可以通过维测工具(获取基带日志的工具)，不定时获取终端侧的modemlog。例如，服务器当前通过维测工具获取终端从当前时间起20分钟内的modemlog。这种方式中，由于服务器不能得知终端何时出现异常，很难获取到的有效数据(有效数据为出现异常原因值对应的modemlog)(下文关于有效数据的描述与此相同)。

而采用本申请实施例获取基带日志的方法，服务器根据统计的CHR大数据确定上报次数较多的(也可以理解为较高级别的)top异常原因值，与该top异常原因值对应的问题小区以及该问题小区的邻区。并将该问题小区的ID和该问题小区的邻区的ID发送给终端群组中的全部终端。终端在确定本机进入了该问题小区或邻区后，再自动开启终端抓取modemlog的功能权限，抓取modemlog。

在本申请的另外一些实施例中，服务器还会将上述top异常原因值与问题小区的ID和该问题小区的邻区的ID一并发送给终端群组中的全部终端。该top异常原因值用于，终端若确定在抓取modemlog期间，aplog中重新抓取到该top异常原因值中的任意一个异常原因值的情况下，则将抓取到的modemlog上传给服务器。

示例性的，如图3所示，为本申请实施例中获取基带日志的一个场景示意图。小区包括M小区、N小区以及K小区，N小区和K小区或M小区互为邻区，且K小区与M小区不互为邻区。其中，问题小区包括M小区，该问题小区的邻区包括N小区。如图3所示，当终端处于K小区的情况下，不开启modemlog。当终端由K小区移动到N小区后，由于N小区是问题小区的邻区，则终端开启modemlog。

由此，执行本申请实施例提供的方法可以有以下优势：

1)一方面，当终端进入了问题小区或问题小区的邻区后，再自动抓取modemlog，而不是一直开启modemlog，从而减少终端性能损耗。另外一方面，终端群组中的全部终端在进入问题小区或问题小区的邻区后都会自动抓取modemlog，从而可以获取到足够量的modemlog。由此，在减少每个终端性能损耗的同时，又能获取到足够量的modemlog。

2)终端在抓取modemlog的同时也在抓取aplog，若终端确定在抓取modemlog期间再次出现了top异常原因值的情况下，才会将抓取到的modemlog上传给服务器。从而保证服务器接收到的modemlog中包含真实有用的日志数据。

请参阅图4，图4为本申请实施例提供的一种获取基带日志的系统架构示意图。

如图4所示，该系统架构包括服务器和终端群组(终端1～终端n，在图4中以终端1～n示出，n为大于1的正整数)。服务器中可以存储有终端群组的信息(例如终端1～终端n的终端ID)，该终端群组也可以理解为用户群组。服务器可以与终端群组中的每个终端进行数据通信。可理解的，服务器与终端群组的关系可以是，服务器可以为终端群组中的每个终端提供软件运行支持或软件维护服务。

示例性的，服务器为beta测试中的后台服务器，终端群组为beta测试用户的终端群组。服务器可以为终端群组中的每个终端提供移动网络运行支持和移动网络维护服务，其中beta测试的目的是测试终端服务器为终端提供的移动网络软件程序是否存在问题。

在上述beta测试场景中，执行本申请实施例提供的获取modemlog的方法，具体由终端基于与服务器的通信连接，将终端侧移动网络软件程序使用过程中产生的aplog，发送给服务器。由服务器分析移动网络软件程序使用过程中用户终端大量出现的异常问题和对应的问题小区，并基于通信连接服务器将异常问题和问题小区的ID和问题小区的邻区的ID等信息下发给终端。使得终端可以确定本机是否进入问题小区或问题小区的邻区，自动开启或关闭抓取modemlog的功能权限，并将抓取到的modemlog基于通信连接上传到服务器，从而服务器可以回溯问题现场，对异常问题作进一步的详细分析，以便工程师制定对应的产品功能改进和完善方案。

可理解的，上述对beta测试场景中关于服务器和终端群组的描述仅为示例，本申请实施例的服务器和终端群组还可以应用于其他应用场景；例如，服务器还可以是软件产品正式发布使用的后台服务器，终端群组为向服务器申请使用该软件产品的用户终端。本申请实施例对于服务器和终端群组的具体应用场景不做限定。

在本申请实施例中，上述终端包括移动终端、平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑以及超级移动个人计算机(ultra-mobile personalcomputer，UMPC)等具备移动网络功能的电子设备。在本申请实施例中，上述服务器还可以为云服务器或云端等，本申请实施例对于该服务器的具体形态不做限定。本文关于终端和服务器的相关描述的说明均与此相同。

实施例1：

基于图4对本申请实施例关于系统架构中的服务器和终端群组的描述，进一步对本申请实施例提供的获取基带日志(modemlog)的方法做详细描述。如图5所示，本申请实施例提供的一种获取modemlog的方法包含步骤S501～S508。该方法包括阶段1～阶段3，其中阶段1(步骤S501～S503)介绍确定top异常原因值和对应的问题小区；阶段2(步骤S504～S505)，介绍终端何时开始抓取modemlog；阶段3(步骤S506～S508)介绍何时打包modemlog以及终端何时停止抓取modemlog。以下分别进行描述：

为便于描述，下文均以CHR大数据用于统计aplog中与移动网络对应的异常原因值的上报次数为例说明本申请实施例提供的方法。

阶段1：

S501，终端群组中的每个终端抓取aplog。

在本申请实施例中，aplog包括异常原因值和出现该异常原因值的终端所在的小区的ID。

S502，终端向服务器发送抓取到的aplog。

关于终端群组、aplog、以及终端群组中的每个终端抓取aplog，并向服务器发送aplog的说明请参照本申请其他实施例的相关描述(例如上述表1、表2、以及图2的相关描述)，在此不再详述。

可理解的，终端除了可以向服务器发送aplog数据之外，还可以向服务器发送出现异常原因值的终端所在的目标小区的该目标小区的邻区的ID信息。从而服务器可以获取到上报过异常原因值的目标小区和该目标小区的邻区的ID。

S503、服务器接收终端发送的aplog，根据aplog统计top异常原因值和对应的问题小区，并向终端发送配置文件。

服务器根据接收到的aplog数据，统计CHR大数据表，从而根据CHR大数据表，确定top异常原因值。

关于服务器根据接收到的aplog数据，统计CHR大数据表的说明请参照本申请其他实施例的相关描述，在此不再详述，例如上文与表3相关的描述。

示例性的，该top异常原因值可以是CHR大数据表中的上报次数大于或等于目标阈值(例如目标阈值为20)的异常原因值。或者，该top异常原因值也可以是CHR大数据表中按上报次数由大到小排序后，排名前M(M为正整数，例如M等于2)的异常原因值。再根据该top异常原因值和aplog数据确定上报过该top异常原因值的问题小区的ID。可理解的，该top异常原因值包括一个或多个异常原因值，在本申请实施例的关于top异常原因值的描述中，若top异常原因值包括一个目标异常原因值，则top异常原因值即为该目标异常原因值；若top异常原因值包括两个或两个以上的目标异常原因值，则该top异常原因值是指该两个或两个以上的目标异常原因值中的任意一个或多个异常原因值。

在本申请其他实施例中，该目标阈值也可以称为第二阈值。

在本申请实施例中，上述配置文件可以包括上述top异常原因值、问题小区的ID以及问题小区的邻区的ID。

可理解的，终端在当前小区抓取到的异常原因值可能是终端在当前小区的邻区切换到当前小区时导致的。示例性的，当终端在A小区时aplog抓取到异常原因值，有可能是终端从A小区的邻区(例如B小区)切换到A小区时(或者也可以理解为终端在B小区且准备进入A小区时)，终端就已经在B小区开始执行可能在B小区会出现异常的一些功能，只是到进入A小区后终端才抓取到执行失败的异常原因值。由此，配置文件中包括问题小区的邻区，当终端接入问题小区或问题小区的邻区后，都开启modemlog，从而获取到完整的modemlog，使得采用该modemlog分析异常问题能得到更高的准确性。

为便于描述，下文将以异常小区的ID统称问题小区的ID和问题小区的邻区的ID。

不难理解的，上述阶段1(步骤S501～S503)主要是由服务器根据终端群组中的终端发送的aplog，确定终端大量反馈出现问题的异常原因值，以及可能出现问题的异常小区的ID，从而生成配置文件，将该配置文件发送给终端群组中的每个终端。

阶段2：

S504，终端接收配置文件。

S505，终端根据配置文件，确定终端进入问题小区或问题小区的邻区后，自动开启抓取modemlog的功能权限，抓取modemlog。

不难理解的，上述阶段2(步骤S504～S505)主要是由终端根据配置文件中的异常小区的ID确定开始抓取modemlog的时机。也就是说，在阶段1中服务器确定上述配置文件以及将配置文件发送给终端，其中一个目的是通知终端可能存在问题的异常小区的ID，使得终端在阶段2中可以根据该配置文件包括的异常小区的ID确定开始抓取modemlog的时机。

在本申请实施例中，终端在开启抓取modemlog的功能权限后立即执行抓取modemlog。也即，开启抓取modemlog的功能功能或开启modemlog可以理解为开始抓取modemlog，关闭抓取modemlog的功能权限或关闭modemlog可以理解为停止抓取modemlog。本文关于开启或关闭抓取modemlog的功能权限的描述均与此相同。

阶段3：

S506，终端在确定再次出现top异常原因值的情况下，打包抓取到的modemlog。

可理解的，终端在抓取modemlog的同时，也在抓取aplog，从而可以根据抓取到的aplog数据中包括的异常原因值确定终端是否再次出现该top异常原因值。

在本申请实施例中，终端只在确定抓取modemlog的期间再次出现了top异常原因值的情况下，才会将抓取到的modemlog打包发送给服务器。而对于抓取modemlog的期间未出现了top异常原因值的modemlog则不打包(也可以理解为不缓存到终端)也不发送到服务器，从而使得服务器接收到与top异常原因值对应的有效数据。

S507，终端向服务器发送打包的modemlog。

S508，终端继续抓取modemlog，直到确定终端离开问题小区和问题小区的邻区后，自动停止抓取modemlog。

不难理解的，上述阶段3(步骤S506～S508)主要是由终端根据配置文件中top异常原因值确定抓取modemlog是否再次出现了top异常原因值，若是则将抓取到的modemlog发送给服务器。也就是说，在阶段1中服务器确定上述配置文件以及将配置文件发送给终端的另外一个目的则是，以便于终端确定抓取到的modemlog是否是服务器想要的与top异常原因值对应的modemlog，若是则发送给服务器，从而保证服务器接收到的modemlog为有效数据。

执行本申请实施例阶段1～阶段3所述的获取基带日志的方法，终端群组中的终端在进入异常小区后，自动开始抓取modemlog(也可以理解为终端在未进入异常小区不开启抓取modemlog的功能权限，或在终端离开异常小区后，自动停止抓取modemlog)。并在抓取modemlog期间再次出现top异常原因值的情况下，将抓取到的modemlog上传给服务器。而对于抓取modemlog期间，aplog中未抓取到出现top异常原因值中的任一个异常原因值的情况，不将抓取到的modemlog上传服务器。

由此，对于单个终端而言，不是一直开启抓取modemlog的功能权限，而是在进入异常小区后自动开启，节省终端性能消耗。终端群组中的全部终端在进入异常小区后均开启抓取modemlog的功能权限，从而可以获取到足够量的modemlog。且终端只将与top异常原因值对应的modemlog发送给服务器，服务器接收到的modemlog均为有效数据。

可理解的，本文所描述的抓取基带日志也可以称为获取基带日志，本文对于具体如何指称获取基带日志不做限定。本文关于抓取基带日志的描述均与此一致。

实施例2：

请参照图6，为便于理解本申请实施例提供的获取基带日志详细实现方式，下面对上述实施例1中阶段1～阶段3的步骤做进一步的详细描述。如图6所示，本申请提供的获取基带日志(modemlog)的方法包括以下步骤：

S601，终端群组中的任一个终端抓取aplog，并向服务器发送该aplog。

示例性的，复用图2，终端群组中的终端(终端1～终端n)，抓取aplog，并向服务器发送该aplog。该aplog包括异常原因值和上报该异常原因值的终端所在的小区的ID。

关于终端群组、aplog等名词的表意以及终端群组中的每个终端抓取aplog，并向服务器发送aplog等操作动作的相关描述请参照本申请其他实施例的相关描述(例如上述表1、表2、以及图2的相关描述)，在此不再详述。

S602，终端接收aplog，并根据aplog统计CHR大数据表，以及根据该CHR大数据表确定top异常原因值。

示例性的，A小区～F小区的邻区关系以及终端在A小区～F小区中上报的aplog如图7所示。其中，A小区与E小区、B小区互为邻区；B小区与A小区F小区互为邻区、C小区与D小区互为邻区；F小区与E小区、B小区、D小区互为邻区。其中，终端中未标明异常原因值(例如300、400或600)表明该终端在当前所在小区未出现异常原因值。而终端中标明异常原因值则表明该终端出现在当前所在小区中出现该异常原因值，且将该异常原因值和终端当前所在的小区的ID(也即aplog)上报给服务器。

示例性的，如图8所示，服务器在接收到aplog数据后，统计aplog数据表中与目标异常原因值(该目标异常原因值包括aplog数据中的每个异常原因值)对应的上报次数，从而得到CHR大数据表。关于统计CHR大数据表的详细说明可以参照本文其他实施例的相关描述(例如上述表3相关的描述)，在此不再详述。

在统计到CHR大数据表后，根据CHR大数据表确定top异常原因值。例如，该top异常原因值可以是CHR大数据表中的上报次数大于目标阈值(例如目标阈值为20)的异常原因值。或者，该top异常原因值也可以是CHR大数据表中按上报次数由大到小排序后，排名前M(M为正整数，例如M等于2)的异常原因值。比如，top异常原因值包括300和400。

S603，根据aplog和top异常原因值确定上报过该top异常原因值的问题小区的ID和该问题小区的邻区的ID。

示例性的，结合上述图7～图8，如图9所示，服务器在确定到top异常原因后，再根据该top异常原因和aplog数据表，确定上报过top异常原因值(300和400)的小区的ID。例如，上报过该top异常原因值的小区包括A小区、B小区和F小区，则问题小区包括A小区、B小区和F小区。再进一步确定该问题小区(A小区、B小区和F小区)的邻区，示例性的，例如，若设A小区～F小区的邻区关系如图7所示，则如下表4所示，用于记录该问题小区的ID和该问题小区的邻区的ID的表中，问题小区的ID和问题小区的邻区的ID包括A小区的ID、B小区的ID、F小区的ID、E小区的ID、以及D小区的ID。

问题小区的ID和该问题小区的邻区的ID
	A小区的ID
B小区的ID
	F小区的ID
E小区的ID
	D小区的ID
...

表4

为便于描述，下文将问题小区和该问题小区的邻区统称为异常小区。采用终端进入异常小区的描述指代终端进入问题小区或问题小区的邻区。采用目标小区为异常小区的描述指代目标小区为问题小区或问题小区的邻区。采用终端离开异常小区的描述指代终端离开问题小区或问题小区的邻区，进入既不是问题小区也不是问题小区的邻区的小区。

S604，服务器确定配置文件，并向终端群组中的全部或部分终端发送该配置文件。

在本申请实施例中，该配置文件包括上述步骤603中的问题小区的ID、该问题小区的邻区的ID，以及上述top异常原因值。

可选的，服务器可以向终端群组中的全部终端发送配置文件，从而使得多个终端执行本申请实施例提供的方法，保证服务器可以获取到足够量的modemlog。

示例性的，top异常原因值包括300和400，问题小区以及问题小区的邻区包括A小区、B小区、F小区、E小区、以及D小区。如图10所示，服务器向终端群组中的终端1～终端n发送配置文件，该配置文件包括top异常原因值包括300和400、A小区的ID、B小区的ID、F小区的ID、E小区的ID、以及D小区的ID。

可选的，服务器也可以只向终端群组中的部分终端发送配置文件。

示例性的，服务器只向终端群组中进入过上述问题小区或该问题小区的邻区的终端发送配置文件。在本申请实施例中，终端在进入小区后，会将终端的ID以及终端进入的小区的ID发送给服务器，也就是说服务器可以存储终端进入过的小区的ID。

例如，如下表5所示，服务器中可以存储有进入过A小区的终端的ID(可理解的，服务器可以为每个小区创建一个存储进入过该小区的终端的ID的记录表)，由此，服务器可以确定进入过问题小区以及该问题小区的邻区的终端的ID。例如，进入过上述A小区、B小区、F小区、E小区以及D小区的终端包括终端1、终端2、终端3、终端4、终端8以及终端10。则如图11所示，服务器只向该终端1、终端2、终端3、终端4、终端8以及终端10以及终端10(在图11中以终端1、2、3、4、8、10示出)发送上述配置文件。

进入过A小区的终端的ID
	终端1
终端2
	...

表5

S605，终端接收配置文件。

可理解的，对于终端而言，接收到的配置文件中包括小区的ID和一个或多个异常原因值。其中，该小区的ID即为异常小区的ID。该一个或多个异常原因值即为上述top异常原因值。

在本申请实施例中，终端在接收服务器发送的配置文件(第一配置文件)之前，在终端侧可以存储有配置文件(第二配置文件)，终端存储的第一配置文件包含的数据内容可以为空。当终端接收到服务器发送的第一配置文件，将第二配置文件替换之后，确定到第一配置文件不为空后，即开始执行步骤S606，判断终端目前是否满足自动开启抓取modemlog功能权限的条件。

S606，终端确定当前进入的小区的ID与配置文件中包括的异常小区的ID是否一致。

可理解的，终端通过与基站进行信息交互确定终端当前所在的小区的ID，为便于描述以下将终端当前进入的小区的ID称为当前小区的ID。在本申请其他实施例中，该当前小区也可称为第一小区。

在本申请实施例中，该异常小区的ID包括上述问题小区的ID和该问题小区的邻区的ID。当前小区的ID与异常小区的ID一致，可以有以下两种情况：1)当前小区的ID与问题小区的ID一致；2)当前小区的ID与该问题小区的邻区的ID一致。当前小区的ID与异常小区的ID不一致包括当前小区的ID既不与问题小区的ID一致，也不与该问题小区的邻区的ID一致。

可理解的，当确定当前小区的ID与异常小区的ID不一致时，则表明终端未进入问题小区或问题小区的邻区，则不开启抓取modemlog的功能权限。当确定当前小区的ID与异常小区的ID一致时，则表明终端进入了问题小区或问题小区的邻区，则自动开启抓取modemlog的功能权限，抓取modemlog。

S607，在确定当前小区的ID与异常小区的ID一致的情况下，开启抓取modemlog的功能权限，抓取modemlog。

在本申请实施例中，在确定当前小区的ID与异常小区的ID不一致的情况下，不开启抓取modemlog的功能权限；在确定当前小区的ID与异常小区的ID一致的情况下，开启抓取modemlog的功能权限，抓取modemlog。

示例性的，若设A小区～F小区的邻区关系以及终端在A小区～F小区中的异常原因值的上报情况如图7所示。则异常原因值包括300和400，则异常小区包括A小区、B小区、F小区、E小区、以及D小区。如图12所示，当终端当前小区为C小区的情况下，由于C小区不是异常小区，则终端不开启抓取modemlog的功能权限。当终端由C小区移动到D小区后，由于D小区是异常小区，则终端开启抓取modemlog的功能权限。

S608，终端根据抓取到的aplog，确定再次出现了配置文件中包括的top异常原因值中的一项或多项异常原因的情况下，打包modemlog；向服务器发送modemlog和该一项或多项异常原因值。

可理解的，终端在抓取modemlog的同时，也在抓取aplog，从而可以根据抓取到的aplog数据中包括的异常原因值确定终端是否再次出现该top异常原因值中的一项或多项异常原因值。示例性的，异常原因值包括300和400，当终端由非异常小区(C小区)移动到异常小区(D小区)后，开启抓取modemlog的功能权限，并同时抓取aplog，当aplog抓取到出现异常原因值300和/或400的情况下，打包modemlog。

在本申请实施例中，上述打包modemlog可以有以下几种方式：

1、打包终端进入异常小区开始抓取modemlog到离开异常小区停止抓取modemlog期间抓取到的全部modemlog。

示例性的，如图13所示，在t1时刻出现top异常原因值，终端t2时刻离开异常小区。

则在终端离开异常小区，停止抓取modemlog后，打包从t＝0时刻(也即开始抓取modemlog)起到t2时刻抓取到的modemlog。

在本申请其他实施例中，t＝0时刻到t2时刻的时间段也可以称为第一时间段。

2、打包终端进入异常小区开始抓取modemlog到出现异常原因值的时刻起第一预设时长内modemlog。

示例性的，如图14所示，在t1时刻出现top异常原因值，打包从t＝0时刻起到(t1+Q1)时刻的时间段内的modemlog。Q1即为第一预设时长，例如，Q1等于5分钟，也即打包t＝0时刻起到(t1+5)时刻的时间段内的modemlog。此处对于Q1等于5仅为示例，Q1还可以为其他大于5或小于5的适合的时长，本申请实施例对此不做限制。

可理解的，这种打包modemlog的方式中，当终端离开异常小区的时刻t2大于或等于(t1+T)时，终端可以按计划打包t＝0～(t1+T)时间段内的modemlog。若终端离开异常小区的时刻t2小于(t1+T)的情况下，终端则打包t＝0～t2时间段内的modemlog。

可理解的，打包t＝0～(t1+T)时间段内的modemlog是指，在(t1+T)时刻抓取完t＝0～(t1+T)时间段内的modemlog后，再开始执行打包modemlog。例如，终端可以设置延迟打包modemlog的延时时长，将延时时长设置为T即可实现在(t1+T)时刻开始执行打包t＝0～(t1+T)时间段内的modemlog。

在本申请其他实施例中，t＝0时刻到(t1+T)时刻的时间段也可以称为第二时间段。

3、打包出现top异常原因值的时刻前第二预设时长到出现top异常原因值的时刻后第三预设时长内的modemlog。

示例性的，如图15所示，在t1时刻出现top异常原因值，打包从(t1-Q2)～(t1+Q3)时间段内的modemlog。Q2即为第二预设时长，Q3第三预设时长，例如，Q2等于5分钟，Q3等于6分钟，则打包(t1-5)～(t1+6)时间段内的modemlog。此处对于Q2等于5，Q3等于6分钟仅为示例，Q2或Q3还可以为其他适合的时长，本申请实施例对此不做限制。可理解的，上述Q1、Q2以及Q3的值可以相等也可以不相等，本申请实施例对此不做限定。

可理解的，这种打包modemlog的方式中，当(t1-T)大于或等于0，且终端离开异常小区的时刻t2大于或等于(t1+T)时，终端可以按计划打包(t1-T)～(t1+T)时间段内的modemlog。若(t1-T)小于0、终端离开异常小区的时刻t2小于(t1+T)的情况下，终端则打包t＝0～t2时间段内的modemlog。

可理解的，打包t(t1-T)～(t1+T)时间段内的modemlog是指，在(t1+T)时刻抓取完(t1-T)～(t1+T)时间段内的modemlog后，再开始执行打包modemlog。可选的，终端可以设置延迟打包modemlog的延时时长，将延时时长设置为T即可实现在(t1+T)时刻开始执行打包t＝(t1-T)～(t1+T)时间段内的modemlog。

可选的，也可以用表的方式记录目标异常原因值、开始打包modemlog的时刻以及打包modemlog的总时长。示例性的，如下表6所示：

异常原因值	开始打包时间	modemlog时间段
			300	t1+T	t1-T～t1+T
400	t3+T	t3-T～t3+T
			600	t4+T	t4-T～t4+T
...	...	...

表6

在本申请其他实施例中，(t1-T)时刻到(t1+T)时刻的时间段也可以称为第三时间段。

可理解的，上述关于打包modemlog的方式仅为示例，还可以采用其他方式打包modemlog，例如终端周期性地打包modemlog等，本申请实施例对此不再限定。

在本申请实施例中，采用上述第一种方式打包modemlog(也即打包从t＝0时刻起到t2时刻抓取到的modemlog)，终端在打包modemlog之前，可以根据aplog确定在t＝0到t2内top异常原因值中出现的一个或多个异常原因值。示例性的，top异常原因值包括300、400、700、800等，在t＝0～t2时间段内，出现了300、400以及700。则将打包好的modemlog和出现的该300、400以及700等异常原因值一起发给服务器。由此，服务器接收到modemlog后可以知道该modemlog是与哪些异常原因值对应modemlog，以便于将modemlog归类存储和处理。

在本申请实施例中，采用上述第二种或第三种方式打包modemlog(也即打包从t＝0时刻起到(t1+T)时刻抓取到的modemlog，或者打包从(t1-T)到(t1+T)时间段内抓取到的modemlog)，终端在打包modemlog之前，也可以根据aplog确定在t＝0到(t1+T)时间段内top异常原因值中出现的一个或多个异常原因值。示例性的，在准备将异常原因值400的modemlog的开始打包时间和打包的modemlog所属时间段存储到表5时，先查看表5中记录的“modemlog的时间段”中是否存在第一modemlog时间段，使得异常原因值400的开始打包时间包含于该第一modemlog时间段内，则将该异常原因值添加到与该第一时间段对应的行记录中记录的异常原因值中。由此，一个modemlog时间段内的打包modemlog可以包括一项或多项异常原因值。服务器接收到modemlog后可以知道该modemlog是与哪些异常原因值对应modemlog，以便于将modemlog归类存储和处理。

在本申请其他实施例中，top异常原因值也可以称为目标异常原因值，该top异常原因值中的一项或多项异常原因，也可以称为第二异常原因值。

S609，服务器接收modemlog、与该modemlog对应的一项或多项异常原因值。

S610，终端继续抓取modemlog，直到离开异常小区。

可理解的，离开异常小区是指终端所在小区的ID与异常小区的ID不一致。

示例性的，如图16所示，终端由当前异常小区(D小区)，移动到非异常小区(C小区)后，则关闭抓取modemlog的功能权限。

由此，执行本申请实施例提供的方法，1)对于终端而言，当终端进入了问题小区或问题小区的邻区后，再自动抓取modemlog，而不是一直抓取modemlog，也不是一直不抓取，或者要用户主动开启modemlog功能权限后才能抓取，从而减少终端性能损耗的同时又能获取到足够量的modemlog。2)对于服务器而言，终端群组中的全部终端在进入问题小区或问题小区的邻区后都会自动抓取modemlog，终端抓取到modemlog后，将modemlog发送给服务器，从而服务器可以获取到足够量的modemlog。由此，在减少每个终端性能损耗的同时，又能获取到足够量的modemlog。3)终端在抓取modemlog的同时也在抓取aplog，若终端确定在抓取modemlog期间再次出现了top异常原因值的情况下，才会将抓取到的modemlog上传给服务器。从而保证服务器接收到的modemlog中包含真实有用的日志数据。

由上可知，执行本申请实施例提供的方法，当终端进入异常小区后自动抓取modemlog，终端离开异常小区后自动停止抓取modemlog，而不是一直抓取modemlog，从而可以减少终端性能损耗。且终端群组中的上述全部或部分终端进入异常小区后均自动抓取modemlog，从而可以获取到足够量的modemlog。

可选的，在另外一些实施例中，如图17所示，在上述步骤605(终端接收配置文件)之后，步骤606(终端确定当前进入的小区的ID是否与配置文件中包括的异常小区的ID一致)之前，本申请实施例提供的获取modemlog的方法还包括步骤S611：

确定终端当前电量是否大于或等于第一阈值；在确定终端当前电量大于或等于第一阈值的情况下，执行步骤606。在确定终端当前电量小于第一阈值的情况下，不执行步骤606，继续监测终端当前电量是否大于或等于第一阈值，直到终端当前电量大于或等于第一阈值后，执行步骤606。

示例性的，终端当前电量大于或等于第一阈值包括终端当前电量大于或等于50％。可理解的，此处对于终端当前电量大于或等于第一阈值包括终端当前电量大于或等于50％仅为示例，该第一阈值还可以为其他合适的取值，本申请实施例对此不做限定。下文关于第一阈值的描述均与此相同。

可选的，如图18所示，在另外一些实施例中，上述步骤S606-S607中，在确定当前小区的ID与异常小区的ID一致后，开启抓取modemlog的功能权限之前，本申请实施例提供的获取modemlog的方法还包括步骤612：

确定终端当前电量是否大于或等于第一阈值。在终端当前电量大于或等于第一阈值的情况下，开启抓取modemlog的功能权限。在确定终端当前电量小于第一阈值的情况下，不开启抓取modemlog的功能权限，直到再次同时满足当前小区的ID与异常小区的ID一致且终端当前电量大于或等于第一阈值的情况下下，开启抓取modemlog的功能权限。关于第一阈值的描述请参照本申请其他实施例的相关描述(例如步骤S610)，在此不再详述。

可理解的，综合考量终端当前电量，均衡功耗和性能，优化开启和关闭modemlog的时机，从而可以进一步减少终端性能损耗，满足用户多元需求。

可选的，在另外一些实施例中，如图19所示，在上述步骤S607中，在确定当前小区的ID与异常小区的ID一致(S6071)后，开启抓取modemlog的功能权限(S6072)之前，本申请实施例提供的获取modemlog的方法还包括步骤S613：

终端确定top异常原因值是否包括预设异常原因值。若是，则执行步骤S6072；若否，则执行步骤6073，也即在确定终端亮屏后，再开启抓取modemlog的功能权限。

示例性的，top异常原因值包括搜网类异常原因值1xx(可理解的，1xx中的1用于表示属于搜网类异常原因值，xx用于表示搜网类异常原因值的具体分类，x可以为任意数字)，通话类异常原因值2xx，数据业务类原因值3xx。其中，搜网类异常原因值1xx，包括终端在搜索附近信号较强的小区的信号时出现的异常、或者在切换小区时出现的异常等，终端在开启搜网权限(例如开启4g移动网)后，在终端熄屏或亮屏时都在执行搜网类的业务。通话类异常原因值2xx，包括被叫业务导致出现异常和主叫业务导致出现异常，被叫业务是除终端本机之外其他终端发起的来电，被叫业务中终端本机不能预测其他终端何时会发起来电，终端处于熄屏或亮屏状态下都有可能接收到被叫请求。而主叫业务则是终端本机向其他终端发起通话请求，终端只有在亮屏后，才能使用呼叫应用程序，向其他终端发起通话请求。数据业务类异常原因值3xx是指终端访问网络数据，例如终端请求访问浏览器的数据；用户一般在终端亮屏后才可以主动访问网络数据。

由此，如图20所示，可以根据异常原因值的类型确定开启抓取modemlog的功能权限的策略。

例如，对于通话类异常原因值2xx中的主叫业务异常原因值22x，以及数据业务类异常原因值3xx，在满足其他开启抓取modemlog的功能权限的条件(例如满足当前小区的ID与异常小区的ID一致的条件)的同时，且确定终端满足亮屏状态条件，才开启抓取modemlog的功能权限。对于搜网类异常原因值1xx，以及通话类异常原因值中的被叫业务类的异常原因值21x，在满足开启条件(比如满足当前小区的ID与异常小区的ID一致的条件)后，无论终端当前处于亮屏状态或熄屏状态，直接开启抓取modemlog的功能权限。

也就是说，上述预设异常原因值可以包括通话类异常原因值2xx中的主叫业务异常原因值22x、数据业务类异常原因值3xx。

在本申请实施例中，上述步骤S609(确定终端当前电量是否大于或等于第一阈值等)和步骤S610(终端确定top异常原因值是否包括预设异常原因值等)可以同时执行，也可以先后执行，本申请实施例对其先后执行顺序不做限定。优选的，上述步骤S609的优先级高于步骤S610，示例性的，在执行S609确定终端当前电量大于或等于第一阈值的情况下，再执行步骤S610；在执行S609确定终端当前电量小于第一阈值的情况下，可以不执行步骤S610。

可理解的，综合考量top异常原因值包括的异常原因值类型是否需要亮屏后开启，进一步均衡功耗和性能，更智能化地确定开启和关闭modemlog的时机，减少终端性能损耗。

可选的，在另外一些实施例中，在开启抓取modemlog的功能权限之后，本申请实施例提供的获取modemlog的方法还可以包括：确定终端当前电量是否大于或等于第一阈值，若否则关闭抓取modemlog的功能权限；若是则不关闭抓取modemlog的功能权限，持续抓取modemlog。

可选的，在另外一些实施例中，在开启抓取modemlog的功能权限之后，本申请实施例提供的获取modemlog的方法还可以包括：确定终端是否启动了一些性能消耗较高的应用(例如游戏类的应用)，若是则关闭抓取modemlog的功能权限，等到终端充电后或终端电量大于或等于第一阈值后在重新开启抓取modemlog的功能权限。

可理解的，综合考量终端当前是否正在运行性能消耗较大的应用程序等因素，更智能化地自动开启和关闭modemlog，从而减少终端运行开销，避免终端同时运行性能消耗要求较大的功能程序，造成的响应迟缓等问题。

实施例3：

结合以上对图4所示的系统架构图、上述实施例1以及实施例2的相关描述，在实际应用中，可以以图21-图22为例，进一步说明本申请实施例提供的方法。

如图21所示，本申请实施例提供的获取基带日志(modemlog)的方法包括以下步骤：

S2101，服务器根据终端群组中的终端发送的aplog，确定top异常原因值，以及与top异常原因值对应的问题小区的ID和该问题小区的邻区的ID。

步骤2101的详细说明请参照本申请其他实施例的相关描述，例如，上述实施例2步骤S601～S603的相关描述，在此不再详述。

S2102，服务器向终端群组中的全部终端推送配置文件，该配置文件包括top异常原因值和异常小区的ID。

在本申请实施例中，异常小区的ID包括上述问题小区的ID和该问题小区的邻区的ID。

关于配置文件、top异常原因值、异常小区的ID的相关描述请参照本申请其他实施例的相关描述，在此不再详述。

S2103，终端群组中的每一个终端接收配置文件。

下文将以终端指代终端群组中的每一个终端。

S2104，终端确定当前电量是否大于或等于第一阈值。

关于终端确定当前电量是否大于或等于第一阈值的说明请参照本申请其他实施例的相关描述(例如实施例2步骤S611)，在此不再详述。

S2105，终端确定当前所在小区的ID与配置文件中的异常小区的ID是否一致。

关于终端确定当前所在小区的ID与配置文件中的异常小区的ID是否一致的说明请参照本申请其他实施例的相关描述(例如实施例2步骤S608)，在此不再详述。

S2106，在确定终端当前电量大于或等于第一阈值，且终端确定当前所在小区的ID与配置文件中的异常小区的ID一致的情况下，终端确定top异常原因值是否包括预设异常原因值。

在本申请实施例中，在同时满足上述步骤S2104和S2105的条件的情况下，再执行步骤S2106。在本申请实施例中，基于需求，上述步骤S2104和S2105可以同时执行或先后执行，本申请实施例对其先后顺序不做限定。优选的，步骤S2104的执行优先级高于S2105，例如，在执行S2104确定，终端当前电量大于或等于第一阈值的情况下，再执行步骤S2105。在执行S2104确定，终端当前电量小于第一阈值的情况下，不执行步骤S2105，直到确定终端当前电量大于或等于第一阈值后再执行步骤S2105。

关于预设异常原因值、终端确定top异常原因值是否包括预设异常原因值的相关描述请参照本申请其他实施例的相关描述(例如实施例2中步骤S613)，在此不再详述。

S2107，在确定top异常原因值包括预设异常原因值的情况下，确定终端是否为亮屏状态。

S2108，在确定top异常原因值不包括预设异常原因值，或者，在确定top异常原因值包括预设异常原因值且终端处于亮屏状态的情况下，终端开启抓取modemlog的功能权限。

由此，终端在进入异常小区后，且终端电量大于或等于第一阈值，以及对于终端亮屏后运行程序才可以出现的top异常原因值在终端处于亮屏状态的情况下再开启modemlog，而不是一进入异常小区立即开启modemlog，进一步减少终端性能损耗，提高终端抓取到的modemlog为有效数据的概率。

在本申请实施例中，在终端开启modemlog后，如图22所示，本申请实施例提供的获取modemlog的方法还包括以下步骤：

S2201，在终端开启了抓取modemlog的功能权限后，终端开始抓取modemlog。

可理解的，在终端抓取modemlog的同时，也在抓取aplog。

S2202，终端根据aplog确定是否再次出现top异常原因值中的一项或多项异常原因值。

S2203，确定再次出现top异常原因值中的一项或多项异常原因值的情况下，打包modemlog。

关于打包modemlog的说明请参照本申请其他实施例的相关描述，例如实施例2步骤S608，在此不再详述。

S2204，终端向服务器发送打包的modemlog以及该一项或多项异常原因值；并在终端离开异常小区之前持续抓取modemlog，执行本申请实施例的步骤S2204～步骤S22。

S2205，终端确定当前电量是否大于或等于第一阈值，且终端是否未运行性能消耗较大的应用程序。

关于第一阈值以及步骤S2205的说明请参照本申请其他实施例的相关描述，例如实施例2的S609，在此不再详述。

S2206，终端是否离开异常小区。

可理解的，终端可以周期性地(例如每5000毫秒)确定当前小区是否为异常小区。示例性的，当终端确定当前小区的ID与配置文件中的异常小区的ID不一致的情况下，终端离开异常小区。

S2207，在终端确定当前电量大于或等于第一阈值，且终端未运行性能消耗较大的应用程序，以及终端未离开异常小区的情况下，终端持续开启抓取modemlog的功能权限。

S2208，在确定终端当前电量小于第一阈值，或，终端运行了性能消耗较大的应用程序，或，终端离开了异常小区的情况下，终端关闭抓取modemlog的功能权限。

S2209，删除终端侧缓存的modemlog。

可选的，在另外一种实现方式中，当终端侧采用如图12(打包t＝0～(t1+T)的modemlog)或图13(打包(t1-T)～(t1+T)的modemlog)打包modemlog的打包方式的情况下，如图22中的步骤S2210，终端也可以在将一份modemlog发送给服务器后删除这一份modemlog的缓存。

由上可知，终端在开始抓取modemlog后，确定终端当前是否满足持续抓取modemlog的条件，实现智能动态开启和关闭抓取modemlog的功能权限。保证能获取到足够量的modemlog的同时，进一步减少终端性能损耗。

可选的，在另外一些实施例中，上述配置文件中也可以不包括问题小区的邻区的ID。而是由终端在接收到配置文件后，由终端确定问题小区的邻区的ID。当终端进入该问题小区或该问题小区的ID后，终端开启抓取modemlog的功能权限。

可选的，在另外一些实施例中，上述配置文件中也可以不包括问题小区的邻区的ID。终端只在进入了问题小区的情况下，才开启抓取modemlog的功能权限。终端进入问题小区的邻区的情况下，不开启抓取modemlog的功能权限。本申请实施例对此不做限定。

可选的，在另外一些实施例中，上述步骤S2102中服务器也可以只向终端群组中的部分终端推送配置文件。例如只向终端群组中进入过异常小区的终端推送配置文件，具体可以参照实施例2中与图11相关的描述。又例如只向终端群组中向服务器上报过top异常原因值的终端推送配置文件。具体向终端群组中的哪些终端发送配置文件，本申请实施例不做限定。

可选的，在另外一些实施例中，上述步骤S2102中服务器也可以只向终端群组中的部分终端推送配置文件(例如只向终端群组中向服务器上报过top异常原因值的终端推送配置文件)，本申请实施例对此不做限定。

下面以上述终端为如图23所示的终端200为例对实施例进行具体说明。应该理解的是，终端200可以具有比图20中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图20中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

终端200可以包括：处理器210，外部存储器接口220，内部存储器221，通用串行总线(universal serial bus，USB)接口230，充电管理模块240，电源管理模块241，电池242，天线1，天线2，移动通信模块250，无线通信模块260，音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，传感器模块280，按键290，马达291，指示器292，摄像头293，显示屏294以及用户标识模块(subscriber identification module，SIM)卡接口295等。其中传感器模块280可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等。

可以理解的是，本发明实施例示意的结构并不构成对终端200的具体限定。在本申请另一些实施例中，终端200可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器210可以包括一个或多个处理单元，例如：处理器210可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，处理器210中可以设置存储器，用于存储指令和数据。在一些实施例中，处理器210中的存储器为高速缓冲存储器。该存储器可以保存处理器210刚用过或循环使用的指令或数据。如果处理器210需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器210的等待时间，因而提高了系统的效率。

在一些实施例中，处理器210可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

可理解的，终端200通过GPU，显示屏294，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏294和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器210可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

内部存储器221可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令，从而执行终端200的各种功能应用以及数据处理。内部存储器221可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储终端200使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器221可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

在本申请实施例中，终端在抓取到modemlog后，可以将modemlog缓存到内部存储器221中。在将modemlog发送给服务器后将缓存在内部存储器221中的modemlog数据删除。

电源管理模块241用于连接电池242，充电管理模块240与处理器210。电源管理模块241接收电池242和/或充电管理模块240的输入，为处理器210，内部存储器221，外部存储器，显示屏294，摄像头293，和无线通信模块260等供电。电源管理模块241还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块241也可以设置于处理器210中。在另一些实施例中，电源管理模块241和充电管理模块240也可以设置于同一个器件中。

在本申请实施例中，终端可以通过电源管理模块241确定终端当前的电量是否大于或等于第一阈值，关于第一阈值的描述请参照本申请其他实施例的相关描述，在此不再赘述。

终端200的无线通信功能可以通过天线1，天线2，移动通信模块250，无线通信模块260，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。终端200中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块250可以提供应用在终端200上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块250可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(lownoise amplifier，LNA)等。移动通信模块250可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块250还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块250的部分功能模块可以被设置于处理器210中。在一些实施例中，移动通信模块250的部分功能模块可以与处理器210的部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器270A，受话器270B等)输出声音信号，或通过显示屏294显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器210，与移动通信模块250或其他功能模块设置在同一个器件中。

无线通信模块260可以提供应用在终端200上的包括无线局域网(wireless localarea networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequencymodulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块260可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块260经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器210。无线通信模块260还可以从处理器210接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，终端200的天线1和移动通信模块250耦合，天线2和无线通信模块260耦合，使得终端200可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(code divisionmultiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(globalnavigation satellite system，GLONASS)，北斗卫星导航系统(beidou navigationsatellite system，BDS)，准天顶卫星系统(quasi-zenith satellite system，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

在本申请实施例中，在终端开启了抓取modemlog的功能权限后，当用户在终端使用移动网络功能时，终端运行基带处理器处理用户请求，并在基带处理器运行时可以生成modemlog。由此，处理器210在确定终端200进入异常小区后，开启抓取modemlog的功能权限后，可以抓取到modemlog。

在本申请实施例中，终端可以通过移动通信模块250与基站进行交互确定终端当前所在的移动通信蜂窝小区的标识(ID)，从而确定终端是否进入异常小区或离开异常小区，关于异常小区的描述请参照本申请其他实施例的相关详细描述，在此不再赘述。

显示屏294用于显示图像，视频等。显示屏294包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，终端200可以包括1个或N个显示屏194，N为大于1的正整数。

在本申请实施例中，可以由显示屏294中的有机发光二极管、柔性发光二极管等确定终端当前是否为亮屏状态。

终端200可以通过ISP，摄像头293，视频编解码器，GPU，显示屏294以及应用处理器等实现拍摄功能。

外部存储器接口220可以用于连接外部存储卡，例如Micro SD卡，实现扩展终端200的存储能力。外部存储卡通过外部存储器接口220与处理器210通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器221可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令，从而执行终端200的各种功能应用以及数据处理。内部存储器221可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用(比如人脸识别功能，指纹识别功能、移动支付功能等)等。存储数据区可存储终端200使用过程中所创建的数据(比如人脸信息模板数据，指纹信息模板等)等。此外，内部存储器221可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flashstorage，UFS)等。

终端200可以通过音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块270用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块270还可以用于对音频信号编码和解码。在一些实施例中，音频模块270可以设置于处理器210中，或将音频模块270的部分功能模块设置于处理器210中。

扬声器270A，也称“喇叭”，用于将音频电信号转换为声音信号。终端200可以通过扬声器270A收听音乐，或收听免提通话。

受话器270B，也称“听筒”，用于将音频电信号转换成声音信号。当终端200接听电话或语音信息时，可以通过将受话器270B靠近人耳接听语音。

麦克风270C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风270C发声，将声音信号输入到麦克风270C。终端200可以设置至少一个麦克风270C。在另一些实施例中，终端200可以设置两个麦克风270C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，终端200还可以设置三个，四个或更多麦克风270C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口270D用于连接有线耳机。耳机接口270D可以是USB接口230，也可以是3.5mm的开放移动终端平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。

本申请实施例中，终端200可以通过移动通信模块250和处理器210确定终端开启抓取modemlog功能权限的时机。例如，终端200可以通过移动通信模块250确定终端当前所在小区的ID，再由处理器在确定当前小区的ID是否与异常小区的ID一致，若是，则开启抓取modemlog的功能权限。

在终端开启了抓取modemlog的功能权限后，终端200可以通过传感器模块280中的各种传感器、按键290、摄像头293、耳机接口270D、麦克风270C等部件获取用户操作和相关数据请求。当用户操作和数据请求与移动通信相关的情况下，处理器210、移动通信模块250以及基带处理器可以响应用户操作，并在执行相应指令的过程中产生modemlog，产生的modemlog可以保存在内部存储器221中。

本申请的一些实施例中，各方法中的步骤可以由处理器210中的应用处理器单独完成，可以由移动通信模块250或基带处理器单独完成，也可以由处理器210、移动通信模块250或基带处理器共同协同完成，此处不作限定。

图24是本申请实施例的终端200的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将系统分为四层，从上至下分别为应用程序层，应用程序框架层，运行时(Runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图24所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序(也可以称为应用(application，App))。

本申请实施例中，该应用程序层还可以包括获取基带日志(modemlog)的模块，该获取modemlog的方法用于执行本申请实施例中的获取modemlog方法。

示例性的，在该应用程序层创建一个用于获取基带日志的进程，由该进程确定终端当前所在的第一小区的标识与问题小区的标识或该问题小区的邻区的标识是否一致，若是则自动开始抓取基带日志。关于第一小区的标识、问题小区的标识以及该问题的邻区的标识的相关描述请参照本申请其他实施例的详细描述，在此不再赘述。

在本申请的一些实施例中，该获取modemlog的模块、也可以位于该软件构架的其他层级中，例如应用程序框架层、系统库、内核层等，此处不作限定。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图24所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。电话管理器用于提供终端200的通信功能。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。

运行时(Runtime)包括核心库和虚拟机。Runtime负责系统的调度和管理。

核心库包含两部分：一部分是编程语言(例如，jave语言)需要调用的功能函数，另一部分是系统的核心库。

应用程序层和应用程序框架层可以运行在虚拟机中。虚拟机可以将应用程序层和应用程序框架层的编程文件(例如，jave文件)执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，二维图形引擎(例如：SGL)等。

内核层是硬件和软件之间的层。内核层可以包含显示驱动，摄像头驱动，音频驱动，传感器驱动，虚拟卡驱动等。

在本申请实施例中，服务器可以为终端群组中的每个终端提供移动网络通信功能程序运行支持和移动网络通信功能的维护服务。下面以服务器为如图25所示的服务器300为例对实施例进行具体说明。如图25所示，服务器300可以包括：至少一个处理器2501，例如CPU，至少一个通信接口2503，存储器2504，至少一个通信总线2502。其中，通信总线2502用于实现这些组件之间的连接通信。通信接口2503可选的可以包括标准的有线接口、无线接口(如WI-FI接口或蓝牙接口等)。存储器2504可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器2504可选的还可以是至少一个位于远离前述处理器2501的存储装置。如图25所示，作为一种计算机存储介质的存储器2504中可以包括操作系统、网络通信模块以及程序指令。

在图25所示的服务器中，处理器2501可以用于加载存储器2504中存储的程序指令，并具体执行本申请实施例提供的方法。

需要说明的是，具体执行过程可以参见上述实施例1～实施例3中的相关方法实施例的具体说明，在此不进行赘述。

上述实施例中所用，根据上下文，术语“当…时”可以被解释为意思是“如果…”或“在…后”或“响应于确定…”或“响应于检测到…”。类似地，根据上下文，短语“在确定…时”或“如果检测到(所陈述的条件或事件)”可以被解释为意思是“如果确定…”或“响应于确定…”或“在检测到(所陈述的条件或事件)时”或“响应于检测到(所陈述的条件或事件)”。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘)等。

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

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

Claims (20)

1.一种获取基带日志的方法，其特征在于，应用于终端，所述方法包括：

接收配置文件，所述配置文件包括问题小区的标识、所述问题小区的邻区的标识以及目标异常原因值；所述问题小区为在其中使用移动通信功能程序时有终端出现过执行错误的移动通信蜂窝小区；所述问题小区的邻区为移动通信蜂窝小区中与所述问题小区设置有小区切换关系的所述问题小区的相邻小区；

确定第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识是否一致，所述第一小区为所述终端当前所在的移动通信蜂窝小区；

在确定所述终端未开始获取基带日志，且所述第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识一致的情况下，开始获取基带日志，以及，获取一项或多项异常原因值，所述基带日志用于记录所述终端进入所述问题小区或所述问题小区的邻区后访问移动通信功能程序的运行过程，所述异常原因值用于表示所述终端访问移动通信功能程序时出现执行错误的错误类型；

确定所述一项或多项异常原因值中是否包括与所述目标异常原因值中的至少一项异常原因值一致的第一异常原因值；

若是，向服务器发送所述基带日志和所述第一异常原因值。

2.如权利要求1所述的方法，其特征在于，所述向服务器发送所述基带日志和所述第一异常原因值，具体包括：

向服务器发送第一时间段内获取到的基带日志和所述第一异常原因值，所述第一时间段的起始时刻为开始获取所述基带日志的起始时刻，所述第一时间段的结束时刻为停止获取所述基带日志的时刻。

3.如权利要求1所述的方法，其特征在于，所述向服务器发送所述基带日志和所述第一异常原因值，具体包括：

向服务器发送第二时间段内获取到的基带日志和所述第一异常原因值，所述第二时间段的起始时刻为开始获取所述基带日志的起始时刻，所述第二时间段的结束时刻为获取到所述第一异常原因值的第一时刻加上第一预设时长后的时刻。

4.如权利要求1所述的方法，其特征在于，所述向服务器发送所述基带日志和所述第一异常原因值，具体包括：

向服务器发送第三时间段内获取到的基带日志和所述第一异常原因值，所述第三时间段的起始时刻为获取到所述第一异常原因值的第一时刻减去第二预设时长后的时刻，所述第三时间段的结束时刻为获取到所述第一异常原因值的第一时刻加上第三预设时长后的时刻。

5.如权利要求1-4任一项所述的方法，其特征在于，在所述确定第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识是否一致之前，所述方法还包括：

确定所述终端的当前电量是否大于或等于第一阈值；

所述确定第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识是否一致具体包括：

在确定所述终端的电量大于或等于所述第一阈值的情况下，确定所述第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识是否一致。

6.如权利要求1-4任一项所述的方法，其特征在于，在所述开始获取基带日志之后，所述方法还包括：

在确定所述第一小区标识与所述问题小区的标识不一致，且与所述问题小区的邻区的标识不一致的情况下，停止获取所述基带日志。

7.如权利要求1-4任一项所述的方法，其特征在于，在所述开始获取基带日志之后，所述方法还包括：

在确定所述第一小区标识与所述问题小区的标识或所述问题小区的邻区的标识一致的情况下，确定所述终端的当前电量是否小于第一阈值；

在确定所述终端的当前电量小于第一阈值的情况下，停止获取所述基带日志。

8.如权利要求1-4任一项所述的方法，其特征在于，所述终端包括显示屏，所述配置文件还包括目标异常原因值，所述方法还包括：

确定所述目标异常原因值是否包括预设异常原因值中的至少一项异常原因值；所述预设异常原因值包括：通话类异常原因值中的与主叫业务相关的异常原因值，和数据业务类异常原因值，所述主叫业务包括所述终端向其他终端发起的通话请求，所述数据业务类异常原因值包括所述终端请求访问移动通信网络数据；

所述在确定所述终端未开始获取基带日志，且所述第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识一致的情况下，开始获取基带日志，具体包括：

在确定所述终端未开始获取基带日志，所述第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识一致，以及所述目标异常原因值包括所述预设异常原因值中的至少一项异常原因值的情况下，在确定所述显示屏处于亮屏状态后，开始获取基带日志。

9.一种获取基带日志的方法，其特征在于，应用于服务器，所述方法包括：

接收终端群组中的至少一个终端发送的应用程序层日志；其中，一个应用程序层日志包括一项或多项异常原因值和第二小区的标识，所述异常原因值用于表示终端访问通信功能程序出现执行错误的错误类型，所述第二小区为终端发送包含所述一项或多项异常原因值的应用程序层日志时所在的移动通信蜂窝小区；

从所述至少一个终端发送的应用程序层日志中包括的异常原因值中确定目标异常原因值和问题小区的标识，所述目标异常原因值的上报次数满足第一预设条件，所述上报次数为所述服务器接收到的包括所述目标异常原因值的应用程序层日志的数目，所述问题小区包括与所述目标异常原因值中的任一项异常原因值对应的所述第二小区；

根据邻区关系表确定所述问题小区的邻区的标识；所述邻区关系表用于记录小区的标识和小区的邻区的标识的关联关系；

向所述终端群组中的部分或全部终端发送配置文件，所述配置文件包括所述问题小区的标识、所述问题小区的邻区的标识、以及所述目标异常原因值，所述配置文件用于指示终端在确定终端当前所在的第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识一致的情况下，开始获取基带日志，所述基带日志用于记录所述终端进入所述问题小区或所述问题小区的邻区后访问移动通信功能程序的运行过程；

接收基带日志和第一异常原因值，所述第一异常原因值为所述终端在获取所述基带日志期间获取到的至少一项异常原因值，且所述第一异常原因值与所述目标异常原因值中的至少一项异常原因值一致。

10.如权利要求9所述的方法，其特征在于，所述向所述终端群组中的部分或全部终端发送配置文件，具体包括：

从所述终端群组中，根据历史小区记录表确定进入过所述问题小区或所述问题小区的邻区的目标终端，所述历史小区记录表用于记录小区的标识与进入过小区的终端的标识的关联关系；

向所述目标终端发送所述配置文件。

11.如权利要求9或10所述的方法，其特征在于，所述接收基带日志和第一异常原因值，具体包括：

接收所述终端发送的第一时间段内获取到的基带日志和所述第一异常原因值，所述第一时间段的起始时刻为开始获取所述基带日志的起始时刻，所述第一时间段的结束时刻为停止获取所述基带日志的时刻。

12.如权利要求9或10所述的方法，其特征在于，所述接收基带日志和第一异常原因值，具体包括：

接收所述终端发送的第二时间段内获取到的基带日志和所述第一异常原因值，所述第二时间段的起始时刻为开始获取所述基带日志的起始时刻，所述第二时间段的结束时刻为获取到所述第一异常原因值的第一时刻加上第一预设时长后的时刻。

13.如权利要求9或10所述的方法，其特征在于，所述接收基带日志和第一异常原因值，具体包括：

接收所述终端发送的第三时间段内获取到的基带日志和所述第一异常原因值，所述第三时间段的起始时刻为获取到所述第一异常原因值的第一时刻减去第二预设时长后的时刻，所述第三时间段的结束时刻为获取到所述第一异常原因值的第一时刻加上第三预设时长后的时刻。

14.如权利要求9或10任一项所述的方法，其特征在于，所述目标异常原因值的上报次数满足第一预设条件，具体包括：所述目标异常原因值的上报次数大于或等于第二阈值。

15.如权利要求9或10任一项所述的方法，其特征在于，在所述接收至少一个终端发送的应用程序层日志之后，所述方法还包括：

统计所述至少一个终端发送的应用程序层日志中包括的异常原因值中每个异常原因值的上报次数，并将所述上报次数由大到小排序，得到排序结果；

所述目标异常原因值的上报次数满足第一预设条件，具体包括：所述目标异常原因值的上报次数在所述排序结果中排名前M，所述M为大于或等于1的正整数。

16.一种获取基带日志的方法，其特征在于，应用于服务器和终端，所述方法包括：

所述服务器接收终端群组中的至少一个所述终端发送的应用程序层日志；其中，一个应用程序层日志包括一项或多项异常原因值和第二小区的标识，所述异常原因值用于表示终端访问通信功能程序出现执行错误的错误类型，所述第二小区为终端发送包含所述一项或多项异常原因值的应用程序层日志时所在的移动通信蜂窝小区；

所述服务器从所述至少一个终端发送的应用程序层日志中包括的异常原因值中确定目标异常原因值，以及问题小区的标识，所述目标异常原因值的上报次数满足第一预设条件，所述上报次数为所述服务器接收到的包括所述目标异常原因值的应用程序层日志的数目，所述问题小区包括与所述目标异常原因值中的任一项异常原因值对应的所述第二小区；

所述服务器根据邻区关系表确定所述问题小区的邻区的标识；所述邻区关系表用于记录小区的标识和小区的邻区的标识的关联关系；

所述服务器向所述终端群组中的部分或全部所述终端发送配置文件，所述配置文件包括所述问题小区的标识、所述问题小区的邻区的标、以及所述目标异常原因值；

所述终端接收所述配置文件，并确定第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识是否一致，所述第一小区为所述终端当前所在的移动通信蜂窝小区；

所述终端在确定未开始获取基带日志，且所述第一小区的标识与所述问题小区的标识或所述问题小区的邻区的标识一致的情况下，开始获取基带日志，以及获取一项或多项异常原因值，所述基带日志用于记录所述终端进入所述问题小区或所述问题小区的邻区后访问移动通信功能程序的运行过程，所述异常原因值用于表示所述终端访问移动通信功能程序时出现执行错误的错误类型；

确定所述一项或多项异常原因值中是否包括与所述目标异常原因值中的至少一项异常原因值一致的第一异常原因值；

若是则向服务器发送所述基带日志以及所述第一异常原因值；

所述服务器接收所述终端发送的所述基带日志以及所述第一异常原因值。

17.一种电子设备，其特征在于，所述电子设备包括：一个或多个处理器、存储器和显示屏；

所述存储器与所述一个或多个处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，所述一个或多个处理器调用所述计算机指令以使得所述电子设备执行如权利要求1-16任一项所述的方法。

18.一种芯片系统，所述芯片系统应用于电子设备，所述芯片系统包括一个或多个处理器，所述处理器用于调用计算机指令以使得所述电子设备执行如权利要求1-16中任一项所述的方法。

19.一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在电子设备上运行时，使得所述电子设备执行如权利要求1-6中任一项所述的方法。

20.一种计算机可读存储介质，包括指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1-16中任一项所述的方法。

Images