Сбой iOS 11 из-за ошибки bundleProxy != nil при использовании UNUserNotificationCenter

Я не уверен, что это сработает для всех, однако я понял это для своего варианта использования. Я создал структуру, которую использовало приложение для iOS. Этот фреймворк использовал UNUserNotificationCenter для настройки предупреждений. По какой-то причине кажется, что «пакет» неправильно инициализируется, когда этот код используется внутри фреймворка. Иногда это работает, иногда нет. Этот bundleProxy, судя по всему, является своего рода прокси, на который опирается фреймворк уведомлений. Поскольку код выполняется внутри фреймворка, возможно, этот пакет не найден во время выполнения, и система возвращает nil. У меня была эта проблема в целом при попытке загрузить ресурсы из Framework, где расположение пакета неверно.

В любом случае, решение для меня состояло в том, чтобы сохранить ссылку на [UNUserNotificationCenter currentNotificationCenter] в делегате приложения при запуске, а затем передать ее любому методу, который хотел ее использовать. К тому времени, когда приложение завершит запуск, этот proxy, кажется, загружается правильно, если вызывающий код является самим двоичным файлом приложения. Кажется, это исправило это для меня.

Почему [UNUserNotificationCenter currentNotificationCenter] иногда дает сбой?

Согласно трассировке стека сбоя, bundleIdentifier равен нулю в частном методе инициализации UNUserNotificationCenter, и возникает исключение. Я не знаю почему.

К сожалению, метод вызывается в контексте dispatch_once, поэтому мы не можем легко воспроизвести этот сбой. Во-первых, я попытался использовать метод NSBundle: NSBundle.mainBundle.bundleIdentifier, но это не удалось. Я предполагаю, что система не использовала этот метод для получения bundleIdentifier, поэтому я попытался использовать частный метод инициализации UNUserNotificationCenter initWithBundleIdentifier:(String), он работал и пытался передать nil этому методу, что вызывало сбой в 100% случаев!!!! Таким образом, мы можем использовать этот метод при загрузке файла и возвращать nil, если bundleIdentifier==nil, надеюсь, это вам поможет.

---------------- код ------------------

    /* UNUserNotificationCenter + Hack */
@implementation UNUserNotificationCenter (Hack)

+ (void)load {
    static dispatch_once_t _onceToken;
    dispatch_once(&_onceToken, ^{
        [self safeHook];
    });
}

+ (void)safeHook {

    /*hook UNUserNotificationCenter's systemMethod initWithBundleIdentifier:*/
    /* private method mix，hope no runtime check ????*/
    NSString * orig_initWithBundleSelectorName = [NSString stringWithFormat:@"%@%@%@",@"initWi",@"thBundleId",@"entifier:"];

    SEL orig_initWithBundleSelector = NSSelectorFromString(orig_initWithBundleSelectorName);

    if (![self instancesRespondToSelector:orig_initWithBundleSelector]) {
        return;
    }

    SEL alt_initWithBundleSelector = @selector(ht_initWithBundleIdentifier:);
    Method origMethod = class_getInstanceMethod(self, orig_initWithBundleSelector);
    Method altMethod = class_getInstanceMethod(self, @selector(ht_initWithBundleIdentifier:));

    class_addMethod(self,
                    orig_initWithBundleSelector,
                    class_getMethodImplementation(self, orig_initWithBundleSelector),
                    method_getTypeEncoding(origMethod));
    class_addMethod(self,
                    alt_initWithBundleSelector,
                    class_getMethodImplementation(self, alt_initWithBundleSelector),
                    method_getTypeEncoding(altMethod));

    method_exchangeImplementations(origMethod, altMethod);
}

- (instancetype)ht_initWithBundleIdentifier:(id)identifier {

    if (nil==identifier||NSNull.null==identifier) {
        return nil;
    }
    /* you can test, if give nil to this method ,100% crash!!!!*/
    /* [self ht_initWithBundleIdentifier:nil] 100% crash!!!!*/
    return [self ht_initWithBundleIdentifier:identifier];
}

@end

OneSignal тоже столкнулся с этим. Их исправление состояло в том, чтобы проверить имя текущего процесса и, если оно содержит IBDesignable, вернуться раньше. Это сработало и для меня.

проблема GitHub

Исправить фиксацию

Для тех, кто здесь для использования PacketTunnelProvider NetworkExtension, это может произойти, если вы вызовете его из stopTunnelWithReason. Вместо этого получите currentNotificationCenter раньше и сохраните его.