libnetwork.dylib _nw_endpoint_flow_copy_path, libnetwork.dylib + 131156崩溃优化

一. 问题背景

libnetwork.dylib _nw_endpoint_flow_copy_path崩溃，是由于iOS 在14.5、14.6系统内部bug导致的，而外部诱因是因为GCDAsyncSocket里面的Api使用，刚好触发了系统内部的Bug导致的崩溃。

具体详见苹果论坛关于该问题的讨论:https://developer.apple.com/forums/thread/679095?page=2

二. 优化分析

因为该问题是iOS系统内部在14.5、14.6系统bug,而外部诱因是因为GCDAsyncSocket里面的Api使用，刚好触发了系统内部的Bug导致的崩溃。

• 因此需要排查下项目里面哪些地方使用到了GCDAsyncSocket，看下是否可以替换为其他库来实现相关的功能。不过这里因为使用到GCDAsyncSocket的大部分为第三方库，比如个推，因此想让第三方去修改，基本不大可能。

• 从bugly日志统计到的libnetwork.dylib _nw_endpoint_flow_copy_path崩溃日志来看，结合神策埋点数据，发现该崩溃大约有60%以上是发生在被动启动的时候，因此这里我们可以针对App的被动启动来进行优化。

iOS启动优化之被动启动

• 因为我们项目里面是个推的SDK,使用到了GCDAsyncSocket,所以我们添加如下判断:如果启动类型为被动启动，且当前手机系统为14.5和14.6系统，那就不去初始化个推的SDK,而是等到用户真正的进入前台再去注册个推SDK,同时也添加了降级的开关，如果出现上线出现异常，可以降级回来,依然走注册逻辑。
  
  image.png

• 我们可以看到被动启动优化后，在优化后的版本崩溃占比已经降到0.69%,而最新版本，还没出现。

备注: 中间有个崩溃占比低是因为该版本只上线两天，因为第三方库崩溃原因快速上线了新版本。

而libnetwork.dylib + 131156，libnetwork.dylib + 133008等
的崩溃，因为堆栈中也有个推SDK相关Api的调用，而且系统都是14.5,14.6的系统，因此相同的优化，也使得该问题的崩溃率下降很多。