liuslevis / gybootingprotection Goto Github PK

View Code? Open in Web Editor NEW

989.0 27.0 150.0 507 KB

A tool for detecting and repairting continuous launch crash of iOS App

License: MIT License

Objective-C 97.12% Ruby 2.88%

gybootingprotection's Introduction

GYBootingProtection

A tool for detecting and repairting continuous launch crash of iOS App

说明

引入项目

将 src 目录下所有文件拖拽到你的 Xcode 项目
在 AppDelegate+GYBootingProtection.m 的 onBeforeBootingProtection 方法中添加检测前需要执行的代码，比如设置crash上报：

- (void)onBeforeBootingProtection {
  [GYBootingProtection setLogger:^(NSString *msg) {
      // setup logger
      NSLog(@"%@", msg);
  }];
  
  [GYBootingProtection setReportBlock:^(NSInteger crashCounts) {
      // setup crash report
  }];
}

在 onBootingProtection 方法中添加修复逻辑，比如删除文件：

- (void)onBootingProtection {
	// 检查 JSPatch 更新
	...
	// 删除 Documents Library Caches 目录下所有文件
	[GYBootingProtection deleteAllFilesUnderDocumentsLibraryCaches];
	...
}

如需执行异步的修复逻辑，在 onBootingProtectionWithCompletion: 方法添加修复逻辑，并在完成修复后调用 completion ：

- (void)onBootingProtectionWithCompletion:(BoolCompletionBlock)completion {
	[self onBootingProtection];
	// 异步修复
	[self asyncRepairWithCompletion:^(void) {
    	// 正常启动流程
		if (completion) completion();
	}];
}

测试与使用

首先制造连续闪退场景：

启动后 5 秒内，双击 Home 通过上划手势 kill 掉 App，重复多次。（也可以在代码里人为制造crash）

当连续闪退超过 5 次时，会提示用户修复：

用户轻触修复，App 重置初始状态，连续闪退问题解决：

gybootingprotection's People

Contributors

Stargazers

Watchers

Forkers

jinjian1991 crazypoo csmdjcml suxinde2009 lanfairy seem-sky evilino sheepy1 vincentsit applejian mainstayz jankytay shiguol jeffrey-huang linknoweasy austgl poetryfar runningyoung lazyclutch ruanjunhao gongziyuan dennishappy xushao1990 helenmeng tudoudong liushaoxing321 ceekay1991 jet-snag yantao608 lishichao windtersharp monkeyfriend123 ffmryan 0bin cadelaren shuaiwang007 peixl blavtes sukeyang dokay carabina davieds rachoo qxw xianglongliu iceboy926 xuehuaze gengjf liufeigit zwcshy bzy0527 allen-king is00hcw lyandy wangshiyu13 gstudy gx952743985 xubojoy kerasking wanglei554623567 jkjiangnan fantexi023 coderzzz jakciehoo qiubaiying lewis180777 devenlu xtxwy mrdml ioscommonlibrary ztkevin majiakun111 freddiezhao yuyangdexue helloyokoy iskf kukumalucn zhencang readopensourcecode wb145230 fjh658 darling0825 tanghaitao mrpotatosun zdrjson yanketianxia uicontrol shicuf difoi yangdongzheng wwpeter steven0610 rickli coderxl lleihai123 heqiang-ios wangdoubleyan z624821876 devzw tamerlx

gybootingprotection's Issues

applicationDidBecomeActive问题

替换didFinishLaunchingWithOptions能检查出crash，但是applicationDidBecomeActive还是会正常执行，如果applicationDidBecomeActive中有代码crash了，那么永远看不到这个alert提示

如果项目是使用纯代码构建 UI 的话，一般需要在-application:didFinishLaunchingWithOptions:方法中初始化window和rootViewController，用 swizzling 替换了该方法来处理 crash 是可以的，但如果要给用户一个提示框之后再处理的话就不好用UIAlertViewController了，[self.window.rootViewController presentViewController:alertController animated:YES completion:nil]的时候self.window.rootViewController还是nil。针对这种情况最好能在文档中给出说明呢。

整体思路很棒，多谢分享🙏

降低误报机率与API优化建议

原文：《连续启动 crash 自修复技术实现与原理解析》

思路很好，很轻量级。有个实现上可以优化下，可以降低50%以上误报机率，监听用户手动划掉APP这个事件，其中一些特定场景，是可以获取的。另外对API设计的建议。

优化：降低50%以上误报机率

用户主动kill掉APP分为两种情况：

App在前台时用户手动划掉APP的时候
APP在后台时划掉APP

第一种场景更为常见，可以通过监听UIApplicationWillTerminateNotification来捕获该动作，捕获后恢复计数。第二种情况，无法监听到。但也足以降低50%以上的误报机率。

对API设计的几点优化意见

1. 机制状态应当用枚举来做为API透出

该机制当前所处的状态，比如：NeedFix 、isFixing，建议用枚举来做为API透出。比如：

typedef NS_ENUM(NSInteger, BootingProtectionStatus) {
   BootingProtectionStatusNormal,  /**<  APP 启动正常 */
   BootingProtectionStatusNormalChecking,  /**< 正在检测是否会在特定时间内是否会 Crash，注意：检测状态下“连续启动崩溃计数”个数小于或等于上限值 */
   BootingProtectionStatusNeedFix, /**< APP 出现连续启动 Crash，需要采取修复措施 */
   BootingProtectionStatusFixing,   /**< APP 出现连续启动 Crash，正在修复中... */
};

2. 关键数值应当做为初始化参数供用户设置

/*!
* 当前启动Crash的状态
*/
@property (nonatomic, assign, readonly) ABSBootingProtectionStatus bootingProtectionStatus;

/*!
* 达到需要执行上报操作的“连续启动崩溃计数”个数。
*/
@property (nonatomic, assign, readonly) NSUInteger continuousCrashOnLaunchNeedToReport;

/*!
* 达到需要执行修复操作的“连续启动崩溃计数”个数。
*/
@property (nonatomic, assign, readonly) NSUInteger continuousCrashOnLaunchNeedToFix;

/*!
* APP 启动后经过多少秒，可以将“连续启动崩溃计数”清零
*/
@property (nonatomic, assign, readonly) NSTimeInterval crashOnLaunchTimeIntervalThreshold;

3. 修复、上报逻辑应当支持用户异步操作

reportBlock 上报逻辑，
repairtBlock 修复逻辑

typedef void (^BoolCompletionHandler)(BOOL succeeded, NSError *error);
typedef void (^RepairBlock)(ABSBoolCompletionHandler completionHandler);

用户执行 BoolCompletionHandler 后即可知道是否执行完毕，并且支持异步操作。

异步操作带来的问题，可以通过前面提到的枚举API来实时监测状态，来决定各种其他操作。

原文：《连续启动 crash 自修复技术实现与原理解析》

下面是测试的代码

delete Library Directory maybe cause NSUserDefault damage

引入GYBootingProtection 后导致支付宝 wap支付不能调起

RT
经考察，发现支付宝的sdk 也对AppDelegate swizzle了。
有解决办法吗？

StoryBoard构建window问题

/** 
 * 对于代码构建 UI 的项目一般在 didFinishLaunch 方法中初始化 window，
 * 想在 swizzling 方法中 present alertController 需要自己先初始化 window 并提供一个 rootViewController
 */
- (void)presentAlertViewController:(UIAlertController *)alertController {
    if (![self hasStoryboardInfo]) {
        self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
        self.window.rootViewController = [[UIViewController alloc] init];
    }
    [self.window makeKeyAndVisible];
    [self.window.rootViewController presentViewController:alertController animated:YES completion:nil];
}

使用storyboard构建的window，在presentAlertViewController的时候 [self.window makeKeyAndVisible]就把window展示出来了，导致rootViewController被初始化，业务代码就被执行了，而且，如果是使用storyboard构建的window，我们无法掌控这个window什么时候被初始化，建议使用者手动初始化window