joywayer
|
5b38456c66
|
3.B:vendor opencore-amr + AMRCodec Swift wrapper,打通 AMR↔WAV 编解码
为支撑 H5 的 prepareaudio / mediaTypeAudio 录音上传 + 远端语音播放
(docs/H5-Native-Contract.md §3.1 [4][5] + §3.2 [9])接入 AMR-NB
编解码能力。AMR-NB 是跨端(iOS / Android / 旧版本客户端)契约硬约束,
不可换 AAC / Opus。
## 接入路径
直接 vendor daoqi msext 现成的 fat .a(已上线多年),不打 xcframework /
不重编源码:
- Vendor/OpenCoreAMR/v0.1.x/libopencore-amrnb.a:daoqi 同款 5-slice fat
库(含 2026-06-20 lipo -segalign 8 修过的对齐版本)
- Vendor/OpenCoreAMR/v0.1.x/{interf_dec,interf_enc}.h:amrnb 公开头
- Vendor/OpenCoreAMR/README.md:来源、版本、修复历史、为何不打 xcframework
- ylgamehall/Source/Audio/AMRFileCodec/{amrFileCodec.h,amrFileCodec.mm}:
daoqi 同款 wrapper(文件级 WAV↔AMR 处理)
- ylgamehall/Source/Audio/AMRCodec.swift:Swift 薄 wrapper(wavToAmr /
amrToWav 两个纯函数 + AMRCodec.Error)
理由见 Vendor/OpenCoreAMR/README.md「为何不打 xcframework / 不重编源码」
一节,本质是 opencore-amr 整个 iOS 生态没有"现代主流"分发形态,社区无
官方 SPM / xcframework 维护,强行打反而引入新风险。
## 关键技术点:extern "C" 修复 ObjC++ name mangling
amrFileCodec.h 在原项目里没有 extern "C" 包裹函数声明,daoqi 能跑是
因为调用方 VoiceConverter.mm 也是 ObjC++,双方按相同 C++ name mangling
链接能对上。
新外壳从 Swift 通过 bridging-header 调用,Swift 按 C 函数解析,期望符号
_EncodeWAVEFileToAMRFile / _DecodeWAVEFileToWAVEFile(C 链接);但
.mm 编译时默认 C++ name mangling,符号变成 __Z25Encode...,导致链接器
报 Undefined symbol。
修复:在 amrFileCodec.h 的函数声明外加 #ifdef __cplusplus / extern "C"
包裹。这是标准 C/C++ 头文件兼容写法,对 daoqi 老路径无影响(ObjC++
调用方仍能链接 C-linkage 函数)。
## .gitignore:白名单 Vendor 下的 .a
发现历史遗留问题:原 .gitignore *.a 通配规则把 libWeChatSDK.a 也排除
了,意味着别人 clone 此仓库后链接失败。本次顺带修复:
!Vendor/**/*.a
让 Vendor 下的 .a 显式纳入跟踪。本提交同时把 libWeChatSDK.a(历史
缺失)+ libopencore-amrnb.a(本次新增)一并加入 git 跟踪。
## 工程改动
pbxproj 改动由用户在 Xcode UI 完成(4 项 Build Settings:Add .a 到
Frameworks group / Header Search Paths +2 / Library Search Paths +1;
EXCLUDED_ARCHS arm64-simulator 因真机调试场景暂未配,需要时再加)。
## 验证
BuildProject 通过,0 错误,符号链接正确。XcodeRefreshCodeIssuesInFile
对 AMRCodec.swift 0 诊断。
|
2026-06-24 01:20:30 +08:00 |
|
 joywayerandClaude Opus 4.7
|
05f1396645
|
微信 SDK 降级 2.0.5 → 1.8.2(与 daoqi msext 同款,避开 UL 强制)
H5 调 accreditlogin 后 sendAuthReq success=false,根因:微信 OpenSDK
2.0.x 强制 Universal Link,传空串被 SDK 拒绝;daoqi msext 用 1.8.x 不强制
UL,多年稳定上线。沿用 1.8.2 避免无谓的 UL 运维负担(HTTPS 域名 + AASA +
微信开放平台审核 30min-1d)。
文件改动:
- 新增 Vendor/WechatSDK/v1.8.2/{WXApi,WXApiObject,WechatAuthSDK}.h +
libWeChatSDK.a(16MB,fat: i386+armv7+armv7s+x86_64+arm64,从 daoqi
msext/Class/SDKExport/ 直接拷贝)
- 删除 Vendor/WechatSDK/WechatOpenSDK-NoPay.xcframework(2.0.5)
- 新增 ylgamehall/ylgamehall-Bridging-Header.h(1.x .a 无 Swift module,
必须通过 Bridging Header 导入 WXApi.h / WXApiObject.h)
代码侧(5 个 Swift 文件):
- WeChatSDK.swift:register() 改为 1.x 单参数 WXApi.registerApp(appID),
去掉 universalLink 参数;handleOpenURL 不变(1.x/2.x 同款)
- WeChatManager.swift:去掉 #if canImport(WechatOpenSDK) 守卫(Bridging
Header 直接导入,符号编译期必在);authorize sendAuthReq 改 1.x BOOL
返回(无 completion);shareLink/shareImage 改 WXApi.sendReq(req)
(1.x BOOL 返回,无 completion);getVersion → getApiVersion
- AccreditLoginHandler / WechatShare:同样去掉 canImport 守卫和 stub 分支
- BackGameDataHandler:更新注释说明 1.x WXApi delegate 由 sendAuthReq
逐次传入,WeChatManager singleton 持有不需要清理(1.x 早期 setDelegate:
API 已废弃)
文档:
- Vendor/WechatSDK/README.md 重写,说明 1.8.2 决策原因 + 文件结构 +
Xcode 接入 5 步 + M Mac simulator 已知限制
- docs/SDK-Integration-Guide.md §A.1 同步重写
⚠️ **本 commit 后 BuildProject 会失败**,需要用户在 Xcode UI 完成 5 步:
1. 删 Frameworks 里旧 WechatOpenSDK-NoPay.xcframework 引用
2. Add Vendor/WechatSDK/v1.8.2/libWeChatSDK.a(Do Not Embed)
3. Add 4 个系统库:libz.tbd / libsqlite3.tbd / Security.framework /
CFNetwork.framework(Do Not Embed)
4. Build Settings → Header Search Paths += $(PROJECT_DIR)/Vendor/WechatSDK/v1.8.2
5. Build Settings → Objective-C Bridging Header = ylgamehall/ylgamehall-Bridging-Header.h
详细操作步骤见 Vendor/WechatSDK/README.md「Xcode 接入步骤」。
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
2026-06-23 08:27:40 +08:00 |
|