iOS 12上应用内下载SKStoreViewController突然导致了大范围的闪退。这其实本质是苹果的StoreKit开发人员犯了一个很简单的错误导致的；
[TOC]
一、前言
SKStoreViewController在iOS 11上是正常没啥问题的，但到了iOS 12突然导致了大范围的闪退。这其实本质是苹果的StoreKit开发人员犯了一个很简单的错误导致的；
二、问题描述
从iOS 12 beta5开始我们线上逐渐多了如下堆栈的crash，到iOS 12.1发布这个问题一直依旧存在，且越来越厉害，成为我们线上top 3的crash之一；
0 StoreKit 0x000000023bedcd68 ___60-[SKStoreProductViewController _requestRemoteViewController]_block_invoke.349 + 348
1 libdispatch.dylib 0x00000002279036c8 __dispatch_call_block_and_release + 24
2 libdispatch.dylib 0x0000000227904484 __dispatch_client_callout + 16
3 libdispatch.dylib 0x00000002278b09ec __dispatch_main_queue_callback_4CF$VARIANT$mp + 1068
4 CoreFoundation 0x0000000227e5a1bc ___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
5 CoreFoundation 0x0000000227e55084 ___CFRunLoopRun + 1964
6 CoreFoundation 0x0000000227e545b8 CFRunLoopRunSpecific + 428
7 GraphicsServices 0x000000022a0c8584 GSEventRunModal + 96
8 UIKitCore 0x0000000254e4cbc8 UIApplicationMain + 204
9 mttlite 0x00000001023f8508 main (main.mm:36)
10 libdyld.dylib 0x0000000227914b94 _start + 4
SEGV_ACCERR
本着是beta系统bug的原因，一开始先提了bug单给苹果，没想到苹果就回复了:
Thank you for contacting us. It has not been determined how or when the issue will be resolved.
The original report on this issue, Bug ID 43234120, is still under investigation. We will notify you when it is closed.
但是苹果光是回复单身体上一直不行动，没办法，问题在正式版本发布后越来越多，我们只能自己去寻找规避的办法了；
三、分析问题
这个堆栈的主因应该是使用SKStoreProductViewController做应用内下载导致的，所以快速的解决办法是把这个功能给干掉；但这不是我们开发人员应该采取的措施，所以还是研究下为什么crash，然后再看如何规避吧；
分析crash文件
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x0000000000000368
Crashed Thread: 0
Thread 0 Crashed:
0 StoreKit 0x000000023bedcd68 ___60-[SKStoreProductViewController _requestRemoteViewController]_block_invoke.349 + 348
1 libdispatch.dylib 0x00000002279036c8 __dispatch_call_block_and_release + 24
2 libdispatch.dylib 0x0000000227904484 __dispatch_client_callout + 16
3 libdispatch.dylib 0x00000002278b09ec __dispatch_main_queue_callback_4CF$VARIANT$mp + 1068
4 CoreFoundation 0x0000000227e5a1bc ___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
+ 12
5 CoreFoundation 0x0000000227e55084 ___CFRunLoopRun + 1964
6 CoreFoundation 0x0000000227e545b8 CFRunLoopRunSpecific + 428
7 GraphicsServices 0x000000022a0c8584 GSEventRunModal + 96
8 UIKitCore 0x0000000254e4cbc8 UIApplicationMain + 204
9 mttlite 0x00000001023f8508 main (main.mm:36)
10 libdyld.dylib 0x0000000227914b94 _start + 4
所有的crash的地址都是0x368，没有例外。看到这个固定的地址，是不是马上能联想到什么了吗？（可能有人按照经验就能猜到会是weak->xxx类问题）
无论如何，先找到堆栈代码，开始调试；挂在348那个偏移指令上，如下图：
请在这里填写图片描述
很明显这里在从x21+x8地址处，进行取内存操作，然后复制给x0；即执行如下伪代码,而实际苹果要做的是取出其某个成员变量（_UIAsyncInvocation的实例）
x0 = * (x21+x8) ;
此时x21是SKStoreViewController实例,x8是一个固定的偏移量0x0368；因此可以认为这里是在进行SKStoreViewController的成员变量访问；
也就是说当进行到这里时x21变为0了，所以导致实际执行的伪代码如下
x0 = * (0+0x0368)
非法内存访问
我们都知道arm64加载后，虚拟地址的前4G地址都是不可访问的，那这里尝试访问0x0368的内存地址并想取值，肯定会被系统给拒绝而非法内存访问了；
所以x21即这个SKStoreViewController实例肯定是在执行的时候突然变为nil了，那什么会变为nil呢？
答案是苹果肯定这里是采取了weakSelf->xxx的访问方式了；weak修饰的SKStoreViewController实例在XPC通信过程中被提前释放了，从而导致了最终这个crash；
好的，只有猜测是不够的；这里我要祭出FBRetainCycleDetector了。如何判定是weakSelf呢？那只要block没有捕获self，那肯定这个self就是weakSelf了，使用FBRetainCycleDetector的查找一下这个block的变量捕获列表（[FBObjectiveCBlock allRetainedObjects]这个接口），果不其然，这个block没有捕获任何变量。没有SKStoreViewController实例，那就基本就坐实了，还不确定的话，可以看下[SKStoreViewController retain]到底在此期间执行了没有，答案也是没有；
所以这个问题就基本清楚了，是StoreKit的这个block使用了如下伪代码导致的问题:
__weak typeof(self) weak_self = self;
dispatch_async(xxxx,^{
weak_self->memberA; //this dereference will crash if weak_self becomes nil.
});
于是我们很快的跟苹果回复了这里有这个问题，希望他们尽快修复一下；
请在这里填写图片描述
四、解决问题
问题原因已经找到了，那解决办法就更简单了；
既然知道是SKStoreViewController实例释放过早导致的weak解引用访问成员变量出现非法内存访问而crash，那就尽量多持有这个SKStoreViewController实例就好了。
然后新版本带上了这个修复，果然一个crash都没有了；
网友评论