【RN】:iOS第三方库依赖冲突问题

缘起

大概是2022年4月的某天，jeverson 坠入一个新坑。React-Naitve 技术栈中。队友说JJ 我遇到一个问题，说libWeChatSDK.a 冲突了: JJ 定精一看，原来是react-native-wechat-lib 和 友盟 社会化分享组件冲突了。再有大池子，某语音平台，被苹果扫描到支付SDK, 困扰好多年，据说尝试了多种方法无果，一连被Apple 审核拒绝了N多次了后，找到了我。本人掐指一段，绝对是分享库中，包含支付代码。后来替换了私有仓库的libWeChatSDK.a 果断过审了。

本来故事发生到这里，基本上可以算说，简单粗暴的解决了，但是随之后来业务迭代需要使用。分享，登录 和 支付。需要两个库都兼容，然后惊奇的发现，微信的静态库更新了。团队也不希望执行那些shell 应用了。OK 那就干脆造个库吧。

造个库

为了彻底解决这个可能冲突的问题，那就干脆点吧。新库就彻底不去本地依赖这个react-native-wechat-lib.a静态库了。OK，上podSpec,上一下改造之后的

require "json"

package = JSON.parse(File.read(File.join(__dir__, "package.json")))
folly_compiler_flags = '-DFOLLY_NO_CONFIG -DFOLLY_MOBILE=1 -DFOLLY_USE_LIBCPP=1 -Wno-comma -Wno-shorten-64-to-32'

Pod::Spec.new do |s|
  s.name         = "react-native-wmm-wechat"
  s.version      = package["version"]
  s.summary      = package["description"]
  s.homepage     = package["homepage"]
  s.license      = package["license"]
  s.authors      = package["author"]

  s.platforms    = { :ios => "11.0" }
  s.source       = { :git => "https://github.com/JeversonJee/react-native-wmm-wechat.git", :tag => "#{s.version}" }

  s.source_files = "ios/**/*.{h,m,mm}"

  s.dependency "React-Core"
#  s.dependency "WechatOpenSDK", "1.9.9"
  s.dependency "UMShare/Social/WeChat"
  s.dependency "SDWebImage", "~>5.14.2"

  # Don't install the dependencies when we run `pod install` in the old architecture.
  if ENV['RCT_NEW_ARCH_ENABLED'] == '1' then
    s.compiler_flags = folly_compiler_flags + " -DRCT_NEW_ARCH_ENABLED=1"
    s.pod_target_xcconfig    = {
        "HEADER_SEARCH_PATHS" => "\"$(PODS_ROOT)/boost\"",
        "OTHER_CPLUSPLUSFLAGS" => "-DFOLLY_NO_CONFIG -DFOLLY_MOBILE=1 -DFOLLY_USE_LIBCPP=1",
        "CLANG_CXX_LANGUAGE_STANDARD" => "c++17"
    }
    s.dependency "React-Codegen"
    s.dependency "RCT-Folly"
    s.dependency "RCTRequired"
    s.dependency "RCTTypeSafety"
    s.dependency "ReactCommon/turbomodule/core"
  end
end

说明

本地去编译静态库的这种，方式会面临微信社会化sdk更新某些方法不能调用的问题，并且这种库作者维护程度并不是很高，故可以采用s.dependcy 的方式比较安全。目前社会化分享是支持cocoapods集成的。此处作者认为，友盟维护程度极高，所以比较可靠。当然后面也是被一阵框框打脸

react-native 造库脚手架

可以采用社区版本的，create-react-native-library 来创建，关于库如何建造可以参考RN:iOS Native 和 ReactNative 通信 文章。虽然这边文章要在前文所述的文章之前，但是因为时间的缘故，这文章还是耽搁了。

万事具备了？

当我嘎嘎乱造完，友盟以来的wechatlib.a 也是不包含最新的payRequest 对象的，就是上述被打脸的事实。

吐槽归吐槽，作为一个不误正业的iOSer 这都是些小场面。友盟 早期就遇到这种问题的上传送门 简而言之就是从微信公众平台下载最新的社会化组件，替换pods 仓库的wechatlib.a 还有，*.h 的头文件

反思

• 本来想另造新库之际，反思了一下接口该如何设计；算了为了兼容前端调用，对于方法名我还是一顿嘎嘎CV
• 所以同理我也去整了一下Android 方面的实现，所以这些成本都花的值吗？
• 所以这真的为了只改了些实现和依赖造个库值得吗，直接pull request 不就行了吗？
• 所以patch 解决的方式没有我优雅吗，为了懒得去pull request 花这个成本？
• 所以之前shell 替换的Application 不优雅吗，所以如果Windows 那种执行shell 比较麻烦的，需要装个软件的。难道再替换成gulp 吗？

或许今年我找到了答案，解决问题之后我反思了一下，关于原生库的这题，我觉得随着原生小伙伴的增加，我们开始造私有库，所以这些还是比较值，毕竟很迅速。关于频率很高的库我们造成私有库，偶尔的直接path ， shell application。老大也整了vscode 插件，所以，最快最小成本的解决方式是最适合的，减少麻烦那就造一下高频率使用的库。

logs

• start 2022
• 2023.05,27 first edit.