防止ios应用程序崩溃的方法与流程

1.本说明书一个或多个实施例涉及ios应用程序技术领域，尤其涉及一种防止ios应用程序崩溃的方法。


背景技术：

2.当前社会环境中，随着智能手机的迅速普及，手机app也被人们越来越多的使用。app一旦上线发布，开发者就对其束手无策，与之而来的崩溃、闪退也防不胜防，对用户使用app的体验产生了极大的负面影响。如何防止崩溃的发生成为了众多移动互联网公司面临的技术难题。


技术实现要素：

3.本说明书一个或多个实施例描述了一种防止ios应用程序崩溃的方法。
4.本发明提供了一种防止ios应用程序崩溃的方法，包括：
5.s100、在ios应用程序启动后，启动运行崩溃防护代码；
6.s200、在所述ios应用程序运行时，所述崩溃防护代码采用键值观察者事件通知机制对所述ios应用程序在消息转发阶段的运行过程是否发生崩溃异常进行监听，若监听到发生崩溃异常，则所述崩溃防护代码对所述运行过程对应的崩溃代码段进行代码重写以实现对所述ios应用程序的修复，并将所述崩溃代码段上传至云端服务器；
7.s300、通过所述云端服务器对接收到的各个所述崩溃代码段进行可视化分析，以使所述ios应用程序的开发人员根据分析结果对所述崩溃代码段进行线下修复，并根据修复后的代码对所述ios应用程序进行版本更新。
8.本说明书实施例提供的防止ios应用程序崩溃的方法，在ios应用程序启动时开始启动崩溃防护代码，崩溃防护代码采用键值观察者事件通知机制对消息转发阶段进行崩溃异常进行监听，在出现崩溃异常时对崩溃代码段进行重写，并将崩溃代码段上传至云端服务器，以便工作人员进行分析并修复，从而提供更好的版本以对出现崩溃异常的版本进行更新。也就是说，当发生崩溃异常时崩溃防护代码进行崩溃防护，从而避免ios应用程序的运行出现崩溃或闪退的情况发生，而且这个过程用户是无感的，不会影响到用户的正常使用。同时由于将崩溃代码段进行上传至云端服务器进行分析统计，对ios应用程序的后续迭代优化提供了有力的数据支撑。由于只有在崩溃异常时才进行代码重写操作，对ios应用程序的运行无性能和内存等系统资源的占用。
附图说明
9.为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本说明书的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
10.图1是本发明一个实施例中防止ios应用程序崩溃的方法的流程示意图。
具体实施方式
11.下面结合附图，对本说明书提供的方案进行描述。
12.本发明提供一种防止ios应用程序崩溃的方法，如图1所示，该方法包括如下步骤s100～s300：
13.s100、在ios应用程序启动后，启动运行崩溃防护代码；
14.其中，崩溃防护代码的作用是对ios应用程序的运行进行崩溃防护。只要启动ios应用程序，就启动崩溃防护代码。
15.在具体实施时，可以将崩溃防护代码为采用sdk集成为一个插件，其中sdk的含义是软件开发工具包，通过软件开发工具包将崩溃防护代码集成为一个插件，这样可以将崩溃防护代码以插件的形式插入不同的ios应用程序中，实现对多种不同ios应用程序的崩溃防护。另外，可以进一步采用面向切面编程的方式植入所述ios应用程序的app代码中，即采用面向切面编程的方式将上述插件植入所述ios应用程序的app代码中。面向切面编程的方式即aop方式，这种方式不会对系统底层的源代码做修改，而常规的植入方式需要修改底层的源代码，因此采用aop方式对app代码的侵入极小，不会造成性能损耗。
16.s200、在所述ios应用程序运行时，所述崩溃防护代码采用键值观察者事件通知机制对所述ios应用程序在消息转发阶段的运行过程是否发生崩溃异常进行监听，若监听到发生崩溃异常，则所述崩溃防护代码对所述运行过程对应的崩溃代码段进行代码重写以实现对所述ios应用程序的修复，并将所述崩溃代码段上传至云端服务器；
17.当ios应用程序在运行时，若消息发送阶段发生错误，没有实现消息的正确发送，就会进入到消息转发阶段。而崩溃防护代码正是在消息转发阶段发挥其崩溃防护作用。
18.其中，键值观察者事件通知机制，即kvo(全称为key
‑
value
‑
observer)事件通知机制。键值观察者事件通知机制是ios系统提供的一套事件通知机制，允许对象监听另一个对象特定属性的改变，并在改变时接收到事件。例如，观察者a监听被观察者b的某个属性，当b的属性发生更改时，a就会收到通知，执行相应的方法。
19.其中，对崩溃代码段进行重写，实际上是用对应的一段新的代码去替代原来的崩溃代码的过程，重写过程是由崩溃防护代码执行的，通过重写的方式实现对崩溃代码的修复。
20.在实际中，消息转发阶段可以包括三个子阶段：方法解析子阶段(即resolveinstancemethod对应的子阶段)、快速转发子阶段(即forwardingtargetforselector对应的子阶段)、慢速转发子阶段(即methodsignatureforselector对应的子阶段)。在具体实施时可以针对这三个子阶段实现崩溃防护。也就是说，s200可以具体包括：
21.s210、所述崩溃防护代码在所述消息转发阶段的方法解析子阶段中，判断是否调用了第一对象方法或者第一类方法，所述第一对象方法为所述ios应用程序的当前运行过程所对应的对象方法，所述第一类方法为所述ios应用程序的当前运行过程所对应的类方法；
22.若是，则进入所述方法解析子阶段的下一个子阶段进行崩溃异常监听；
23.否则，所述方法解析子阶段出现崩溃异常，将当前运行过程对应的app代码段作为所述崩溃代码段，并对所述崩溃代码段进行重写处理。
24.可理解的是，上述过程通过键值观察者事件通知机制对方法解析子阶段进行崩溃监听，即通过键值观察者事件通知机制判断方法解析子阶段是否调用了第一对象方法或者第一类方法。而第一对象方法或第一类方法是ios应用程序当前的运行过程所执行的功能所对应的对象方法或类方法，例如，ios应用程序当前执行的是登录功能，则第一对象方法或第一类方法是能够实现登录功能的对象方法或类方法。
25.可理解的是，如果在方法解析子阶段调用了第一类方法或第一对象方法，说明方法解析子阶段的执行过程是成功的，可以进入下一个子阶段，从而进入下一个子阶段进行崩溃异常监听。而如果在方法解析子阶段没有调用第一对象方法或第一类方法，说明方法解析子阶段是失败的，有可能因为这一子阶段的执行失败而发生崩溃，所以此时认为方法解析子阶段出现了崩溃异常，从而对当前对应的崩溃代码段进行重写操作。
26.在具体实施时，当需要进入所述方法解析子阶段的下一个子阶段进行崩溃异常监听时，所述s200具体还可以包括：
27.s220、所述崩溃防护代码在所述快速转发子阶段中，判断在预设对象列表中是否能够查找到响应所述第一对象方法或所述第一类方法的子对象；
28.若是，则进入所述快速转发子阶段的下一个子阶段进行崩溃异常监听；
29.否则，所述快速转发子阶段出现崩溃异常，将当前运行过程对应的app代码段作为所述崩溃代码段，并对所述崩溃代码段进行重写处理。
30.可理解的是，在预设对象列表中包括多个子对象，不同的子对象能够响应不同的对象方法或者类方法。
31.可理解的是，上述过程通过键值观察者事件通知机制对快速转发子阶段进行崩溃监听，即通过键值观察者事件通知机制判断快速转发子阶段是否能够查找到响应所述第一对象方法或所述第一类方法的子对象进行监听。可理解的是，为了实现ios应用程序当前运行过程所对应的功能，需要调用第一类方法或第一对象方法，由于在方法解析子阶段没有调用第一类方法或第一对象方法，因此需要找到能够响应第一类方法或第一对象方法的子对象，才能实现ios应用程序当前运行过程所对应的功能。
32.可理解的是，如果能够找到响应第一类方法或第一对象方法的子对象，这样快速转发子阶段便可以通过该子对象实现该子阶段的功能，进而进入下一个子阶段进行崩溃异常监听。而如果在快速转发子阶段没有找到该子对象，则说明快速转发子阶段是失败的，有可能因为这一子阶段的执行失败而发生崩溃，所以此时认为快速转发子阶段出现了崩溃异常，从而对当前对应的崩溃代码段进行重写操作。
33.在具体实施时，当需要进入所述快速转发子阶段的下一个子阶段进行崩溃异常监听时，所述s200具体还可以包括：
34.s230、所述崩溃防护代码在所述慢速转发子阶段中，将所述预设对象列表切换为对应的关联对象列表，并判断在所述关联对象列表中是否能够查找到响应所述第一对象方法或所述第一类方法的关联子对象；
35.若是，则所述消息转发阶段的运行过程未出现崩溃异常；
36.否则，所述慢速转发子阶段出现崩溃异常，将当前运行过程对应的app代码段作为
所述崩溃代码段，并对所述崩溃代码段进行重写处理。
37.可理解的是，在关联对象列表中包括多个关联子对象，这些关联子对象能够响应不同的对象方法或类方法。预设对象列表和关联对象列表是关联的。
38.可理解的是，上述过程通过键值观察者事件通知机制对慢速转发子阶段进行崩溃监听，即通过键值观察者事件通知机制判断快速转发子阶段是否能够查找到响应所述第一对象方法或所述第一类方法的关联子对象进行监听。由于在快速转发子阶段中，在预设对象列表中没有找到能够响应上述第一类方法或第一对象方法的子对象，因此在关联对象列表查找能够响应所述第一对象方法或所述第一类方法的关联子对象，在查找之前需要将预设对象列表切换为对应的关联对象列表，只有找到能够响应所述第一对象方法或所述第一类方法的关联子对象，才能实现ios应用程序当前运行过程所对应的功能。
39.可理解的是，如果能够找到响应第一类方法或第一对象方法的关联子对象，这样慢速转发子阶段便可以通过该关联子对象实现该子阶段的功能，至此所述消息转发阶段的整个运行过程均未出现崩溃异常。而如果在慢速转发子阶段没有找到该关联子对象，则说明慢速转发子阶段是失败的，有可能因为这一子阶段的执行失败而发生崩溃，所以此时认为慢速转发子阶段出现了崩溃异常，从而对当前对应的崩溃代码段进行重写操作。
40.通过上述三个步骤实现对消息转发阶段的三个子阶段进行崩溃异常监听并在出现崩溃异常时进行重写进行代码修复。由于在上述过程中会把崩溃代码段发送给云端服务器，这样云端服务器可以执行s300。
41.s300、通过所述云端服务器对接收到的各个所述崩溃代码段进行可视化分析，以使所述ios应用程序的开发人员根据分析结果对所述崩溃代码段进行线下修复，并根据修复后的代码对所述ios应用程序进行版本更新。
42.在具体实施时，当云端服务器会接收到很多崩溃代码段，而云端服务器会对这些崩溃代码段进行可视化分析，以供人员进行了解。具体分析可以是对接收到的相同崩溃代码段的次数进行累加，进而根据累加接收次数对不同的崩溃代码段进行排序，这样工作人员可以从累加接收次数最高到最低的顺序依次进行线下修复。如果一个崩溃代码段的累加接收次数越多，说明这个崩溃代码段对用户使用的影响越大，所以先对累加接收次数最多的崩溃代码段进行修复，然后对累加接收次数次多的崩溃代码段进行修复，直到所有的崩溃代码段修复完成。当所有的崩溃代码段修复完成，便可以根据所修复的代码段形成一个新的版本，将这个新的版本上线以对之前版本的ios应用程序进行更新，从而实现对之前版本的ios应用程序的全面修复。
43.也就是说，s300中进行可视化分析的过程可以包括：通过所述云端服务器对同一所述崩溃代码段的接收次数进行累加，并对不同所述崩溃代码段按照累加接收次数从高至低的顺序进行排序，以使所述开发人员根据排序依次对各个所述崩溃代码段进行线下修复。
44.其中，上述进行重写可以采用runtime实现对崩溃代码段的优化替代，静默阻止崩溃，保证应用程序的正常运行。
45.举例来说，当用户启动ios应用程序时，崩溃防护代码开始启动，崩溃防护代码对ios应用程序在消息转阶段是否发生崩溃异常进行监听，在发生监听异常时，进行代码重写以实现修复，在修复完成后用户可以继续使用ios应用程序，而这个过程耗时极短，用户不
会感知到。而且将崩溃代码段上传至云端服务器，云端服务器对崩溃代码段进行统计分析，这样开发人员根据分析结果进行修复，做到异常根源修复，一劳永逸，进而得到对之前版本的ios应用程序进行版本更新，从而彻底解决崩溃问题。当没有发生崩溃异常时，用户正常使用ios应用程序。
46.本发明提供的防止ios应用程序崩溃的方法，在ios应用程序启动时开始启动崩溃防护代码，崩溃防护代码采用键值观察者事件通知机制对消息转发阶段进行崩溃异常进行监听，在出现崩溃异常时对崩溃代码段进行重写，并将崩溃代码段上传至云端服务器，以便工作人员进行分析并修复，从而提供更好的版本以对出现崩溃异常的版本进行更新。也就是说，当发生崩溃异常时崩溃防护代码进行崩溃防护，从而避免ios应用程序的运行出现崩溃或闪退的情况发生，而且这个过程用户是无感的，不会影响到用户的正常使用。同时由于将崩溃代码段进行上传至云端服务器进行分析统计，对ios应用程序的后续迭代优化提供了有力的数据支撑。由于只有在崩溃异常时才进行代码重写操作，对ios应用程序的运行无性能和内存等系统资源的占用。
47.在具体实施时，除了由于代码段问题引起崩溃之外，还可能是因为缓存数据过多因此占用内存过多而不能正常运行而导致的崩溃问题。针对这一问题造成的崩溃问题，本发明还可以包括如下步骤：
48.s400、所述ios应用程序所在智能设备的操作系统的框架层获取ios应用程序的标识信息和在安装过程中所述ios应用程序的安装压缩包解压后的文件目录；
49.其中，操作系统的框架包括应用层、框架层和内核三层。这里通过框架层对应用程序的标识信息和目录信息进行记录。
50.可理解的是，ios应用程序的安装压缩包通常是操作系统能够识别出的采用固定格式的数据压缩包，以一定的后缀名结尾。ios应用程序在安装时，操作系统会对安装压缩包进行解压，生成文件夹结构。而操作系统的框架层就会记录解压后的文件目录。而且，框架层还会记录ios应用程序的标识信息，标识信息为ios应用程序的唯一标识信息。框架层将获取的文件目录和标识信息保存在本地。
51.s500、在所述ios应用程序首次启动运行时，所述ios应用程序调用所述框架层的新建文件接口，通过所述新建文件接口将运行过程所产生的缓存文件的文件信息传递给所述框架层；所述操作系统的文件系统根据所述框架层接收到的文件信息，在所述文件目录下生成对应的文件或文件夹以使所述ios应用程序将所述缓存文件存储至生成的所述文件或所述文件夹中，并生成信息关联表，所述信息关联表用于存储所述文件信息与对应的文件或文件夹之间的映射关系；
52.其中，所述文件信息包括文件名称、路径和后缀名。
53.也就是说，在ios应用程序首次启动时，ios应用程序通过调用新建文件接口，进而通过该接口将运行过程所产生的缓存文件对应的文件名称、路径和后缀名等文件信息传递给框架层，以便于文件系统依据这些信息生成新的文件和文件夹，用来存储缓存文件，同时生成信息关联表，用来存储文件信息与文件、文件夹的对应关系。
54.可理解的是，只在ios应用程序首次启动运行时生成新的文件和文件夹，以及创建一个信息关联表即可。其中，生成的新的文件和文件夹用来存储应用程序在运行过程中所产生的缓存文件，这里的缓存文件包括应用程序的崩溃日志、用户在应用程序上查看过的
图片和视频、下载过的音视频和图片、用户的截图、用户访问过的实时性要求较高的内容。
55.也就是说，当框架层接收到文件信息之后，文件系统会根据这些文件信息生成文件和文件夹，生成的文件和文件夹位于上述文件目录下，具体位置要根据缓存文件的不同内容而定，通过生成的文件和文件夹对缓存文件进行存储和分类。同时还要生成信息关联表，用来存储所有缓存文件的文件信息与文件、文件夹的对应关系。
56.可理解的是，信息关联表中可以存储一个ios应用程序中缓存文件的文件信息与文件、文件夹的映射关系，也可以存储多个ios应用程序中缓存文件的文件信息与文件、文件夹的映射关系，通过标识信息可以对不同ios应用程序对应的映射关系进行区分。
57.在ios应用程序非首次运行时，如果在文件目录下已经存在存储同类型缓存文件的文件和文件夹，只需要将运行过程产生的缓存文件存储至文件和文件夹中即可，不需要再生成新的文件和文件夹，为了对同类型不同时间段生成的缓存数据进行区分，可以对文件和文件夹的名称用日期加以区分。而如果在在非首次运行时，在文件目录下不存在相同类型缓存文件的文件和文件夹，则还需要生成对应的文件和文件夹，同时在信息关联表中添加新的对应关系。
58.s600、所述ios应用程序在对一个缓存文件进行删除处理时，调用所述框架层的api接口，并将删除请求通过所述api接口传递给所述框架层；所述框架层根据所述删除请求中的文件信息，在所述信息关联表中查找到待处理文件或待处理文件夹的路径，根据所述路径在所述文件目录下查找到对应的待处理文件或待处理文件夹，对所述待处理文件或待处理文件夹进行删除，并对所述信息关联表进行更新。
59.可见，在对缓存文件进行删除时通过信息关联表在文件目录下找到待处理文件或待处理文件夹，从而对待处理文件或待处理文件夹进行删除，同时还要对信息关联表进行更新。
60.在具体实施时，为了保证信息关联表和文件目录下文件和文件夹的对应关系，本发明提供的方法还可以包括：
61.s700、在所述操作系统每次启动时，所述框架层对所述信息关联表进行读取，对所述文件目录下的文件和文件夹进行扫描，判断扫描后得到的信息与从所述信息关联表中读取到的信息是否一致，若不一致，则根据扫描后得到的信息对所述信息关联表进行修正。
62.即，在操作系统每一次启动时都会对信息关联表和缓存文件进行一致性对比，在不一致时根据缓存文件对信息关联表进行修正，从而保证信息关联表的真实正确。例如，在对缓存文件进行删除处理后，对信息关联表的更新出现错误而没有正确更新的话，缓存文件和信息关联表会出现不一致的情况发生，因此在操作系统启动时依据缓存文件对信息关联表进行纠正，从而解决这一问题。
63.可理解的是，上述过程是逐个对缓存文件进行删除的情况，在这个过程中误删的可能性比较小，但是在批量删除时有可能存在误删的情况发生，为了减少该情况的发生，本发明提供的方法还可以包括：
64.s800、所述框架层在接收到所述ios应用程序对批量缓存文件的删除请求时，根据所述删除请求中的文件信息，在所述信息关联表中查找到对应的待处理文件或待处理文件夹的路径，根据所述路径在所述文件目录下查找到对应的待处理文件或待处理文件夹，根据所述待处理文件或待处理文件夹的属性信息将所述待处理文件或待处理文件夹分类为
第一类缓存数据和第二类缓存数据，将所述第一类缓存数据删除，展示选择界面，所述选择界面上展示有第二类缓存数据，响应于用户在所述选择界面上的选择操作，对第二类缓存数据进行选择性删除，并根据删除的数据对所述信息关联表进行更新。
65.在根据信息关联表在文件目录下找到待处理文件或待处理文件夹之后，需要对其进行分类，分为第一类缓存数据和第二类缓存数据，第一类缓存数据可以直接删除，而第二类缓存数据需要选择性删除，具体展示一个选择界面，用户可以在选择界面上进行选择操作，进而根据用户的选择进行删除。在完成删除操作之后，对信息关联表进行更新。
66.在具体实施时，具体根据缓存文件的属性信息进行分类。属性信息可以包括预设标志，若缓存文件为用户自主下载的文件则所述预设标志为1，否则所述预设标志为0。也就是说，每一个缓存文件都具有一个预设标志，用来表示该缓存文件是否为用户自主下载的内容。这样s800中的分类过程可以包括：判断所述预设标志是否为1，若是则所述待处理文件或待处理文件夹为第二类缓存数据，否则为第一类缓存数据。由于用户自主下载的内容可能比较重要，误删的话造成的影响比较大，因此针对第二类缓存数据要供用户进行选择性删除，在一定程度上可以减少误删的情况发生。
67.可见，在安装压缩包解压后的文件目录下生成新的文件和文件夹，用来存储缓存数据，同时还生成信息关联表，用来记录文件信息与文件、文件夹之间的映射关系，在ios应用程序对缓存文件进行删除处理时，框架层会根据信息关联表在文件目录下找到对应的文件、文件夹，进而对其进行删除处理，同时还对信息关联表中的信息进行更新，从而保证信息关联表与文件、文件夹的一致性。通过这种方式可以精准的找到缓存文件，进而对其删除，及时清理，减少发生误删的可能性，从而解决缓存文件过多造成的崩溃问题。而且不限于ios应用程序的升级等因素，非常灵活。
68.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
69.本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、挂件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。
70.以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。