iOS摸鱼周报第四十四期-六虎

本期概要

论题：Apple 将推出 Tap to Pay 功用

Tips：处理 iOS 15 上 APP 不可思议地退出登录

面试模块：Dealloc 运用注意事项及解析

优异博客：ARM64 汇编入门及运用

学习材料：Github: How to Cook

开发东西：文件查找运用：EasyFind

本期论题

@zhangferry：Apple 将在 iPhone 上推出 Tap to Pay 功用，即能够经过简略的操作行为 — 轻触，完成在商户端的付款进程。该功用经过 NFC 完成，十分安全，支撑 Apple Pay、非接触式信用卡、借记卡以及其他数字钱包，这意味着 iPhone 将具有相似 POS 的功用，客户能够直接在商户的 iPhone 上刷信用卡进行消费。该功用仅 iPhone XS 及之后的机型支撑。

Stripe 将成为第一个在 iPhone 上向其商业客户提供 Tap to Pay 的付出渠道。其他付出渠道和运用程序将在今年晚些时分推出。

Apple empowers businesses to accept contactless payments through Tap to Pay on iPhone

开发Tips

收拾修改：FBY展菲

处理 iOS 15 上 APP 不可思议地退出登录

复现问题

在 iOS 15 正式版推出后，咱们开端收到用户的反馈：在翻开咱们的App (Cookpad) 时，用户不可思议地被强制退出帐号并返回到登录页。十分令人惊讶的是，咱们在测验 iOS 15 beta 版的时分并没有发现这个问题。

咱们没有视频，也没有具体的步骤来重现这个问题，所以我尽力测验以各种方法发动运用程序，希望能亲手重现它。我试着重新安装运用程序，我试着在有网络连接和没有网络连接的情况下发动，我试着强制退出，经过 30 分钟的尽力，我抛弃了，我开端回复用户说我没找到具体问题。

直到我再次解锁手机，没有做任何操作，就发动了 Cookpad，我发现 APP 就像咱们的用户所反馈的那样，直接退出到了登录界面！

在那之后，我无法精确的复现该问题，但好像与暂停运用手机一段时刻后再次运用它有关。

缩小问题规模

我忧虑从 Xcode 重新安装运用程序或许会影响问题的复现，所以我首要查看代码并企图缩小问题的规模。依据咱们的完成，我想出了三个置疑的原因。

1、UserDefaults 中的数据被铲除。
2、一个意外的 API 调用返回 HTTP 401 并触发退出登录。
3、Keychain 抛出了一个错误。

我能够扫除前两个置疑的原因，这要归功于我在自己重现该问题后观察到的一些奇妙行为。

登录界面没有要求我挑选地区 —— 这表明 UserDefaults 中的数据没有问题，由于咱们的 “已显示地区挑选 “偏好设置依然生效。
主用户界面没有显示，即使是短暂的也没有 —— 这表明没有测验进行网络恳求，所以 API 是问题原因或许还为时过早。

这就把Keychain留给了咱们，指引我进入下一个问题。是什么产生了改动以及为什么它如此难以复现？

寻找根本原因

我的调试界面很有用，但它缺少了一些有助于回答一切问题的重要信息：时刻。

我知道在 AppDelegate.application(_:didFinishLaunchingWithOptions:) 之前，“受保护的数据” 是不可用的，但它依然没有意义，由于为了重现这个问题，我正在履行以下操作：

1、发动运用程序 2、简略运用 3、强制退出运用 4、确认我的设备并将其放置约 30 分钟 5、解锁设备 6、再次发动运用

每当我在第 6 步中再次发动运用程序时，我 100% 确认设备已解锁，因而我坚信我应该能够从 AppDelegate.init() 中的 Keychain 读取数据。

直到我看了一切这些步骤的时刻，工作才开端变得有点意义。

再次细心查看时刻戳：

main.swift — 11:38:47
AppDelegate.init() — 11:38:47
AppDelegate.application(_:didFinishLaunchingWithOptions:) — 12:03:04
ViewController.viewDidAppear(_:) — 12:03:04

在我真正解锁手机并点击运用图标之前的 25 分钟，运用程序本身就现已发动了！

现在，我实践上从未想过有这么大的延迟，实践上是 @_saagarjha 主张我查看时刻戳，之后，他指给我看这条推特。

推特翻译：风趣的 iOS 15 优化。Duet 现在企图先下手为强地 “预热” 第三方运用程序，在你点击一个运用程序图标前几分钟，经过 dyld 和预主静态初始化器运行它们。然后，该运用程序被暂停，随后的 “发动” 好像更快。

现在一切都说得通了。咱们最初没有测验到它，由于咱们很或许没有给 iOS 15 beta 版足够的时刻来 “学习” 咱们的运用习惯，所以这个问题只在现实生活的场景中再现，即设备以为我很快就要发动运用程序。我依然不知道这种猜测是怎么构成的，但我只想把它归结为 “Siri 智能”，然后就到此为止了。

定论

从 iOS 15 开端，体系或许决议在用户实践测验翻开你的运用程序之前对其进行 “预热”，这或许会增加受保护的数据在你以为应该无法运用的时分的被拜访概率。

经过等候 application(_:didFinishLaunchingWithOptions:) 托付回调来防止App 受此影响，假如能够的话，留心 UIApplication.isProtectedDataAvailable（或对应托付的回调/告诉）并相应处理。

咱们依然发现了极少数的非丧命问题，在 application(_:didFinishLaunchingWithOptions:) 中特点 isProtectedDataAvailable 值为 false，咱们现在除了推迟从钥匙串读取数据之外，没有其它好办法，由于它是体系原因导致，不值得进行进一步研究。

参阅：处理 iOS 15 上 APP 不可思议地退出登录 – Swift社区

面试解析

收拾修改：Hello World

Dealloc 运用注意事项及解析

关于 Dealloc 的相关面试题以及运用，周报里现已有所提及。例如三十八期：dealloc 在哪个线程履行和四十二期：OOM 管理 FBAllocationTracker 完成原理，能够结合今天的运用注意事项一同学习。

防止在 dealloc 中运用特点拜访

在很多材猜中，都明确指出，应该尽量防止在 dealloc 中经过特点拜访，而是用成员变量替代。

在初始化办法和 dealloc 办法中，总是应该直接经过实例变量来读写数据。- 《Effective Objective-C 2.0》第七条

Always use accessor methods. Except in initializer methods and dealloc. – WWDC 2012 Session 413 – Migrating to Modern Objective-C

The only places you shouldn’t use accessor methods to set an instance variable are in initializer methods and dealloc. – Practical Memory Management

除了能够提升拜访效率，也能够防止产生 crash。有文章介绍 crash 的原因是：析构进程中，类结构不再完整，当运用 accessor 时，实践是向当时实例发送消息，此时或许会存在 crash。

笔者对这儿也不是很了解，依据 debug 剖析析构进程实践是优先调用了实例覆写的 dealloc 后，才依次处理 superclass 的 dealloc、 cxx_destruct 、Associated、Weak Reference、Side Table等结构的，最后履行 free，所以不应该产生结构损坏导致的 crash，希望有了解的同学指导一下

笔者个人的了解是：Apple 做这种要求的原因是不想让子类影响父类的结构和析构进程。例如以下代码，子类经过覆写了 Associated办法，会影响到父类的 dealloc 进程。

@interface HWObject : NSObject
@property(nonatomic) NSString* info;
@end
@implementation HWObject
- (void)dealloc {
    self.info = nil;
}
- (void)setInfo:(NSString *)info {
    if (info)
    {
        _info = info;
        NSLog(@"%@",[NSString stringWithString:info]);
    }
}
@end
@interface HWSubObject : HWObject
@property (nonatomic) NSString* debugInfo;
@end
@implementation HWSubObject
- (void)setInfo:(NSString *)info {
    NSLog(@"%@",[NSString stringWithString:self.debugInfo]);
}
- (void)dealloc {
    _debugInfo = nil;
}
- (instancetype)init {
    if (self = [super init]) {
        _debugInfo = @"This is SubClass";
    }
    return self;
}
@end

造成 crash 的原因是 HWSubObject:dealloc() 中开释了变量 debugInfo，然后调用 HWObject:dealloc() ，该函数运用 Associated 设置 info ，由于子类覆写了 setInfo，所以履行子类 setInfo。该函数内运用了现已被开释的变量 debugInfo。正如上面说的，子类经过重写 Associated，最终影响到了父类的析构进程。

dealloc 是什么时分开释变量的

其实在 dealloc 中无需开发处理成员变量，当体系调用 dealloc时会主动调用析构函数（.cxx_destruct）开释变量，参阅源码调用链：[NSObject dealloc] => _objc_rootDealloc => rootDealloc => object_dispose => objc_destructInstance => object_cxxDestruct => object_cxxDestructFromClass

static void object_cxxDestructFromClass(id obj, Class cls)
{
    // 遍历 self & superclass
        // SEL_cxx_destruct 是在 map_images 时在 Sel_init 中赋值的， 其实便是 .cxx_destruct 函数
        dtor = (void(*)(id))
            lookupMethodInClassAndLoadCache(cls, SEL_cxx_destruct);
            // 履行
            (*dtor)(obj);
        }
    }
}

沿着 superClass 链经过 lookupMethodInClassAndLoadCache 去查询 SEL_cxx_destruct函数，查找到调用。SEL_cxx_destruct 是 objc 在初始化调用 map_images 时，在 Sel_init 中赋值的，值便是 .cxx_destruct。

而 cxx_destruct 便是用于开释变量的，当类中新增了变量后，会主动插入该函数，这儿能够经过 LLDB watchpoint 监听实例的特点值改变，然后查看仓库信息验证。

防止在 dealloc 中运用 __weak

- (void)dealloc {
    __weak typeof(self) weakSelf = self;
}

当在 dealloc中运用了 __weak 后会直接 crash，报错信息为：Cannot form weak reference to instance (0x2813c4d90) of class xxx. It is possible that this object was over-released, or is in the process of deallocation. 报错原因是 runtime 在存储弱引用计数进程中判别了当时目标是否正在析构中，假如正在析构则抛出异常

中心源码如下：

id  weak_register_no_lock(weak_table_t *weak_table, id referent_id,   id *referrer_id, WeakRegisterDeallocatingOptions deallocatingOptions) {
    // ... 省掉
        if (deallocating) {
            if (deallocatingOptions == CrashIfDeallocating) {
                _objc_fatal("Cannot form weak reference to instance (%p) of " "class %s. It is possible that this object was " "over-released, or is in the process of deallocation.", (void*)referent, object_getClassName((id)referent));
            } 
    // ... 省掉
}

防止在 dealloc 中运用 GCD

例如一个经常在子线程中运用的类，内部需求运用 NSTimer 定时器，定时器由于需求加到 NSRunloop 中，为了简略，这儿加到了主线程，而定时器有一个特殊性：定时器的开释和创建必须在同一个线程，所以开释也需求在主线程，示例代码如下（以上代码仅作为示例代码，并非实践开发运用）：

- (void)dealloc {
		[self invalidateTimer];
}
- (void)fireTimer {
    __weak typeof(self) weakSelf = self;
    dispatch_async(dispatch_get_main_queue(), ^{
        if (!weakSelf.timer) {
            weakSelf.timer = [NSTimer scheduledTimerWithTimeInterval:1.0 repeats:YES block:^(NSTimer * _Nonnull timer) {
                NSLog(@"TestDeallocModel timer:%p", timer);
            }];
            [[NSRunLoop currentRunLoop] addTimer:weakSelf.timer forMode:NSRunLoopCommonModes];
        }
    });
}
- (void)invalidateTimer {
    dispatch_async(dispatch_get_main_queue(), ^{
        //  crash 方位
        if (self.timer) {
            NSLog(@"TestDeallocModel invalidateTimer:%p model:%p", self->_timer, self);
            [self.timer invalidate];
            self.timer = nil;
        }
    });
}
- (vodi)main {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        HWSubObject *obj = [[HWSubObject alloc] init];
        [obj fireTimer];
    });
}

代码会在invalidateTimer::if (self.timer) 处产生 crash，报错为 EXC_BAD_ACCESS。原因很简略，由于 dealloc最终会调用 free()开释内存空间，然后 GCD再拜访到 self 时现已是野指针，所以报错。

能够运用 performSelector替代 GCD完成，确保线程操作先于 dealloc 完成。

总结：面试中关于内存管理和 dealloc 相关的考察应该不会很复杂，主张熟读一次源码，了解 dealloc 的调用时机以及整个开释流程，然后了解注意事项，根本能够一次性处理 dealloc 的相关面试题。

为什么不能在init和dealloc函数中运用accessor办法
ARC下，Dealloc还需求注意什么？
Practical Memory Management

优异博客

收拾修改：皮拉夫大王在此

本期优异博客的主题为：ARM64 汇编入门及运用。汇编代码关于咱们大多数开发者来说是既了解又生疏的领域，在日常开发进程中咱们经常会遇到汇编，所以很了解。可是咱们遇到汇编后，大多数人或许并不了解汇编代码做了什么，也不知道能使用汇编代码处理什么问题而常常挑选忽略，因而汇编代码又是生疏的。本期博客我搜集了 3 套汇编系列教程，跟咱们一道进入 ARM64 的汇编国际。

阅览学习后我将取得什么？

完整阅览三套学习教程后，咱们能够阅览一些逻辑简略的汇编代码，更重要的是多了一种针对疑问 bug 的排查手段。

需求基础吗？

我对汇编掌握的并不多，在阅览和学期进程期间发现那些需求考虑和了解的内容，作者们都介绍的很好。

1、[C in ASM(ARM64)] — 来自知乎：知兵

@皮拉夫大王：引荐先阅览此系列文章。作者从语法视点解释源码与汇编的联络，例如数组相关的汇编代码是什么样子？结构体相关的汇编代码又是什么样子。阅览后咱们能够对栈有必定的了解，并且能够阅览不太复杂的汇编代码，并能结合指令集说明将一些人工源码翻译成汇编代码。

2、iOS汇编入门教程 — 来自：Soulghost

@皮拉夫大王：页师傅出品经典教程。相对前一系列文章来说，更多地从 iOS 开发者的视点去看到和运用汇编，例如怎么使用汇编代码剖析 NSClassFromString 的完成。文章全体的深度也有所加深，假如读者有必定的汇编基础，能够从该系列文章开端阅览。

3、深化iOS体系底层系列文章目录 — 来自：欧阳大哥2013

@皮拉夫大王：十分全面且深化的底层相关文章集合。有了前两篇文章的衬托，能够阅览该系列文章做下拓宽。另外作者还在深化iOS体系底层之crash处理办法文章中一步步带领咱们使用汇编代码排查野指针问题。作为初学者咱们能够快速感受到收益。

学习材料

收拾修改：Mimosa

程序员煮饭攻略

地址：github.com/Anduin2017/…

一个由社区驱动和保护的煮饭攻略。在这儿你能够学习到各色菜式是怎么制作的，以及一些厨房的运用常识和常识。比较有意思的是，该仓库里的菜谱大都对制作进程中的细节和用量描绘精确，比方菜谱中有 不允许运用不精准描绘的词汇，例如：适量、少数、中量、恰当。 等十分严厉精确的要求，对简直每个菜谱都做到了简练精确，十分有意思，也十分欢迎咱们贡献它~

东西引荐

收拾修改：CoderStar

EasyFind

地址：easyfind.en.softonic.com/mac

软件状态：免费

软件介绍：

小而强壮的文件查找运用，媲美 windows 下的 Everything。

关于咱们

iOS 摸鱼周报，主要分享开发进程中遇到的经验教训、优质的博客、高质量的学习材料、有用的开发东西等。周报仓库在这儿：github.com/zhangferry/… ，假如你有好的的内容引荐能够经过 issue 的方法进行提交。另外也能够申请成为咱们的常驻修改，一同保护这份周报。另可关注公众号：iOS生长之路，后台点击进群交流，联络咱们，获取更多内容。

往期引荐

iOS摸鱼周报第四十三期

iOS摸鱼周报第四十二期

iOS摸鱼周报第四十一期

iOS摸鱼周报第四十期

iOS摸鱼周报 第四十四期