背景
本次需求新增了一个美颜的小功用，经过调研，运用了 github 上一个开源的代码，由于代码都是开源的，导入项目中的办法为，脚本打包为framework，再导入项目中。本来是一次愉快的开发、提测、上线进程，没想到坏消息突然就来了，QA 反应 iOS13.5版别无法打开 APP，P0级问题来啦，Bug挖掘机开端上线
案发现场
借到QA的设备之后，在 xcode15.0环境，真机运转iOS13.5，build正常，窃喜了一下，必定是 QA 的操作有问题！ 没想到打脸来的很快，run起来立刻溃散，APP展现了一下启动图，瞬间就平息了，溃散堆栈如下
#1 0x0000000 in __libcpp_operator_new<unsigned long>
定位问题
稳定复现的问题都是小问题，先查看报错，问题出在了新导入的 sdk，老代码没问题。可是诡异的是，代码出在了系统的 c++代码上，代码中未发现问题，能够确认是正常流程。
猜想
溃散的原因难道是 init 办法的某些函数在 iOS13上不兼容？
经过宏界说的办法把代码包起来。发现仍是溃散，没有处理
网上查资料
经过查找栈顶的溃散信息，发现刚好有歪果仁在 github 上反应
依据issues 上的信息能够清晰三点
- 确认问题出在 Xcode15.0对 c++的兼容
- 能够经过调整 link 信息处理这个问题，添加-Wl,-ld_classic
- xcode15.1处理了这个问题
第一次测验处理
按照文档的提示，测验在编译环境上添加做修正，在 other link flag 信息上添加-Wl,-ld_classic。 编译一下，正常，run 起来，仍是溃散！，果然没有那么简略，继续研究。
第2次测验处理
既然问题出现在了 xcode15.0上，测验去晋级/降级Xcode是不是能处理这个问题呢？于是开端漫长的 Xcode 晋级旅程
一万年之后，Xcode晋级完成，刻不容缓的开端编译，见证奇观的时间到了！！！
结果，仍是溃散了……
报错信息如下：
#1 0x0000000109ed345c in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::basic_string[abi:ue170006]<0>(char const*) ()
第三次测验处理
好消息：原来的报错不在了 坏消息：换了一个更麻烦的
好的收拾心境再出发，问题既然现已定位，反常原因是 xcode15.0对 c++的兼容出了问题，现在我的环境是正常了，现在溃散还在，那么必定有内鬼啊！！！
再整理一遍流程
xcode打包–上传–下载–xcode运转
上传、下载这两个环节不会有问题，本地 xcode 环境也现已更新，那么问题必然出现在打包上啊。
sdk 是之前经过 xcode15.0打出来的，xcode15.0对 c++有兼容性问题（重要的话说三遍），那么sdk 必然是这个内鬼！！！
见证奇观的时间？
从头打包上传 sdk，壳工程 clean，运转。
发现本地索引出现反常，提示 framework 找不到。毛毛雨啦~~
终究收尾
问题出在工程的索引上，老的版别号现已不在了，需求从头索引。
1、General 中，换掉 framework。
2、Build sttting 中去掉老的 searchPath
编译之后正常，问题处理
反思
第一次测验失利的原因，是因为framework打包的时候就出了问题，能够说，打出来的framework不可用，无论运转环境怎么调整，都会出现问题。
第2次失利的原因，也是如此，编译环境对了，可是framework有问题，也会报错
弯路
处理问题的中心仍是在 xcode15.0上，没有把握住问题的中心，期间屡次走了弯路
1、期间也测验换个低版别的 xcode去打一个 sdk，可是三方库在低版别的 xcode 上脚本运转失利，迟迟无法打包。
2、测验换了个集成 sdk 的办法
之前是运用 sdk 作为一个子库房单独输出的办法，调整成了 framework 直接拖入入需求运用的子库房里，可是这种办法加载之后，需求在子组件的描绘文件中进行标识，不同的组件化办法对应不同的处理方案，运用自己的办法就行
s.vendored_frameworks = 'Frameworks/x.framework', 'Frameworks/xx.framework'
结果仍是不行，甚至高版别的手机也无法编译了
3、测验切换流水线的打包环境，从15.0降级为14.5系统，结果流水线编译报错了。。。
