dispatch thunk of Alamofire.MultipartFormData.append(_: Foundation.Data, withName: Swift.String, fileName: Swift.String?, mimeType: Swift.String?) -> ()", referenced from:

先说工程结构
工程A有一个静态framework target a，通过cocoapods以源码方式集成了封装Alamofire，封装Alamofire的一些能力。

 workspace A
              |____ a (源码)
              |____Alamofire （源码）

构建输出静态framework a。

工程B有一个App Target，通过cocoapods以源码方式集成封装Alamofire，以静态库方式集成了 a。

 workspace B
             ｜___App
                      |____ a (静态库)
                      |____ Alamofire （源码）
 ```

 在同一电脑，用同一个Xcode，设置了相同的swift version，结果App构建失败，找不到Alamofire里的符号。

经过一番观察，发现 "dispatch thunk of Alamofire.MultipartFormData.append(...)"是 Swift 编译器为带有默认参数、可变签名或需要方法桥接的函数生成的“thunk”符号。也就是说静态库a引用了这些由 Alamofire 生成的编译器私有符号，但最终链接器没有在任何被链接的库/框架中找到对应实现。

 检查工程配置，首先排除Alamofire 的实现没有被链接到最终可执行文件（常见：静态库a引用但 App 没把 Alamofire 链接上）。

那么，最有可能的情况就是：工程B的Alamofire 与 工程A  使用不同的 Swift 编译环境/选项，导致 thunk 的名称/生成方式不一致，最终没有可匹配的符号。虽然Alamofire代码一摸一样，但是编译后的符号修饰方式不一样。

示意例子，例如同样是方法 test，
工程A中被修饰为 _$s12Alamofire4testtKF
工程B中被修饰为 $s12Alamofire4test_tKj

有了排查方向，经过对比工程A和工程B的配置，最终发现cocoapods自动生成target Alamofire的配置有些许不一致 

Build Libraries for Distribution 这个配置不一样，一个是YES，一个是NO。
又经实验，发现如果依赖Alamofire的target的 Build Libraries for Distribution 配置为YES，那么cocoapods自动生成的Alamofire对应的配置也是YES。

最后，只要将Alamofire对应Build Libraries for Distribution设置为NO（保持一致）就解决了Undefined symbols问题。

根据签发机构类型，TLS证书签发可以划分为两种：

• 公信CA（Certificate Authority）签发的证书（如DigiCert、Let’s Encrypt、Sectigo等）
• 企业内部私有CA签发的证书。

公信CA签发与企业内部私有CA签发，两者的区别是公信力不同。一般情况下，互联网环境不应信任企业内部私有CA签发的证书。

下面主要详细说明最常见的公信CA签发域名验证（DV）、组织验证（OV）、扩展验证（EV）证书的过程，以及全网最流行的免费证书Let’s Encrypt为例的自动化流程。

公信CA签发证书的通用流程（DV/OV/EV）

1. 生成CSR（Certificate Signing Request，证书签名请求）

   • 在你的服务器上首先生成一对密钥：私钥（private key）和公钥（public key）。
   • 使用私钥生成CSR文件，CSR里包含了：
     • 域名（Common Name 或 SAN 列表）
     • 组织信息（OV/EV证书需要）
     • 公钥
     • 国家、省份、城市、公司名称等（OV/EV需要）
   • 常用命令（OpenSSL）：

     openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr

2. 选择CA并提交申请

   • 登录CA官网（或通过ACME协议自动化），选择证书类型（DV/OV/EV）、有效期。
   • 上传CSR（或者有些CA让你直接在网页填写信息后帮你生成）。

3. 域名控制权验证（DCV，Domain Control Validation）
   这是所有公信证书都必须完成的步骤，证明你确实控制这个域名。常见三种方式：

   • HTTP验证（最常见）：CA给你一段随机token，你需要在域名下 .well-known/acme-challenge/ 路径放一个特定文件
     示例：http://yourdomain.com/.well-known/acme-challenge/xxxxxx
   • DNS验证：CA给你一段TXT记录，你需要在域名DNS管理面板添加 _acme-challenge.yourdomain.com TXT "xxxxxx"
   • Email验证（较少用）：给域名whois邮箱或管理员邮箱（如admin@、webmaster@）发邮件，点链接确认

   DV证书只做这一步；OV/EV还要额外验证组织合法性。

4. （OV/EV专属）组织信息验证

   • 核实公司工商注册信息（通过第三方数据库如Dun & Bradstreet）
   • 核实营业执照、法人身份
   • 电话回访确认申请人身份和授权
   • 验证域名管理权归属公司（whois + 额外证明文件）

5. CA签发证书

   • CA用自己的中间证书或根证书的私钥，对你的公钥+域名+有效期等信息进行签名，生成证书文件（.crt 或 .pem）
   • 同时会下发CA链证书（中间证书 bundle,参考下面附录）

6. 下载并安装证书

   • 你把证书、公钥、私钥安装到Web服务器（Nginx/Apache/IIS等）
   • 重启服务，以使证书生效

最常见的自动化签发：Let’s Encrypt（ACME协议）

Let’s Encrypt是目前全球使用量最大的免费CA，90天有效期，完全自动化。

常用客户端：Certbot、acme.sh、win-acme、lego 等。以acme.sh为例的全自动流程：

# 1. 安装acme.sh
curl https://get.acme.sh | sh

# 2. 切换到Let’s Encrypt（默认就是）
acme.sh --set-default-ca --server letsencrypt

# 3. 签发证书（两种主流验证方式任选其一）

# 方法A：HTTP验证（需要80端口开放）
acme.sh --issue -d example.com -d www.example.com --webroot /var/www/html

# 方法B：DNS验证（推荐，停机也可续期）
acme.sh --issue -d example.com --dns dns_cf   # 以Cloudflare为例，会自动调用API添加TXT记录

# 4. 安装证书到Nginx/Apache
acme.sh --install-cert -d example.com \
--key-file /etc/nginx/ssl/example.key \
--fullchain-file /etc/nginx/ssl/example.cer \
--reloadcmd "nginx -s reload"

整个过程几秒到几十秒完成，无需人工干预，每60天自动续期。

证书签发后链路示意

用户浏览器 ←HTTPS→ 你的服务器（证书+私钥）
           ↑
        验证链：
你的证书 → CA中间证书 → 根证书（已预装在操作系统/浏览器中）

总结对比表

附录：CA链证书

简单来说：CA链证书就是“中间证书”，它是连接你的网站证书和浏览器信任的根证书之间的“桥梁”。如果没有正确安装链证书，用户访问你的HTTPS网站时就会报错（最常见的是“NET::ERR_CERT_AUTHORITY_INVALID”或“证书不受信任”）。

为什么需要链证书？（信任链原理）

为什么公信CA（包括Let’s Encrypt、DigiCert、GlobalSign等）坚决不直接用根证书私钥（Root Private Key）去签发终端用户证书？原因非常明确，一共就这几条，但每一条都是致命的：

所以现代公信CA为了安全，绝不直接用根证书私钥去签发终端用户证书，而是采用分层结构：

根证书（Root CA）
    └── 中间证书1（Intermediate CA）   ← CA用根私钥签发
            └── 中间证书2（Intermediate CA）   ← 用中间1签发
                    └── 你的网站证书（Leaf Certificate） ← 用中间2签发

• 根证书：预装在操作系统和浏览器里（DigiCert、GlobalSign、Let’s Encrypt的根叫ISRG Root X1等），数量很少，私钥离线保存在保险柜里，几乎永不使用。
• 中间证书：CA用根私钥签发的证书，中间证书的私钥才真正用来签发你的网站证书。
• 你的网站证书（叶子证书）：只包含你的域名和公钥。

浏览器验证证书时会沿着这条链一层层往上验证，直到找到自己信任的根证书为止。

实际拿到的证书文件通常有这几种

1. 你的网站证书（也叫leaf证书、end-entity证书）
   文件名通常是：yourdomain.crt、yourdomain.pem、certificate.crt

2. 链证书 / 中间证书（最重要的就是这个）
   可能有1~3个中间证书串在一起，常见文件名：

   • chain.crt、ca-bundle.crt、intermediate.crt、fullchain.pem

3. 根证书（一般不需要你提供）
   浏览器自己有，不需要放在服务器上。

如何撤销中间证书

中间证书（Intermediate CA）一旦被发现有安全问题、被滥用、私钥泄露、CA违规等，必须立即撤销。

谁有权力、谁来执行撤销？

实际撤销的技术方式（都必须同时做）

1. CRL（Certificate Revocation List，证书吊销列表）

   • 根CA或上一级中间CA用自己的私钥签名一个列表，里面列出被撤销的证书序列号
   • 文件通常放在 http://crl.exampleca.com/xxx.crl
   • 缺点：体积大，浏览器很少真正下载检查（基本被淘汰）

2. OCSP（Online Certificate Status Protocol，在线证书状态协议）

   • 实时查询：浏览器问 OCSP Responder：“序列号为12345的证书还好吗？”
   • 回应：Good / Revoked / Unknown
   • 现在是主流，所有正规CA都必须提供OCSP服务

3. OCSP Must-Staple（强制 stapling）

   • 证书签发时就加上一个扩展，要求服务器必须在TLS握手中附带OCSP响应
   • Let’s Encrypt、DigiCert 等主流CA默认都开启
   • 一旦中间证书被撤销，所有使用该中间证书签发的网站都会立刻变红锁（几小时内）

1. 基础参数校验（最基本的一道防线）

• 用户名/手机号/邮箱：非空、格式正则、长度限制、防注入（预编译语句或ORM自动处理）
• 密码：非空、长度（通常8-32位）、不能包含用户名等
• 验证码（图片/短信/邮箱）：非空、长度固定、是否过期（通常60-300秒）
• 请求必传字段完整性（deviceId、timestamp、sign等）

2. 账号状态校验

• 账号是否存在
• 账号是否被禁用/冻结/注销
• 账号是否需要强制修改密码（首次登录、密码过期）
• 账号是否被加入黑名单

3. 密码相关安全校验

• 密码明文传输 → 必须强制HTTPS
• 密码加密传输（前端通常用RSA或SM2加密，后端私钥解密）
• 后端密码存储：bcrypt、scrypt、Argon2（加盐，绝不用MD5/SHA1明盐）
• 密码输错次数限制（单账号5-10次后锁定30分钟~永久，需要人工解封）
• 密码复杂度策略（可选：大小写+数字+特殊字符）

4. 验证码多重校验（防止暴力破解）

• 图片验证码：防自动化脚本
• 短信/邮箱验证码：限流（同一手机号/IP/设备1分钟1条，1小时5条，24小时10条）
• 验证码有效期 + 只能使用一次
• 验证码输错次数限制（3-5次后需要重新获取）

5. 登录风控与异常检测（核心防爆破、防薅羊毛）

• 同一账号短时间内多次登录失败次数超限 → 锁定
• 同一IP短时间内大量不同账号登录失败 → IP封禁
• 同一设备（deviceId/deviceFingerprint）短时大量账号尝试 → 设备封禁
• 异地登录检测（根据IP归属地，与历史登录地对比，差距>1000km触发二次验证）
• 短时间内大规模登录请求 → 触发全局限流或人工介入
• 用户代理（User-Agent）异常或频繁切换
• 无头浏览器、模拟器、爬虫特征检测

6. 会话安全策略

• 登录成功后颁发token（推荐无状态JWT，或服务端Session+Redis）
• JWT需设置合理过期时间（accessToken 15min ~ 2h，refreshToken 7 ~ 30天）
• 支持单点登录（同账号新登录踢掉旧设备）
• 支持多端互踢配置（Web端登录踢掉App等）
• 敏感操作二次验证（修改密码、支付等需重新输入密码或验证码）

7. 常见辅助安全措施

• 登录接口全局限流（令牌桶/漏桶算法，如QPS>500触发降级）
• 关键日志记录安全审计日志（登录IP、设备、时间、结果等）
• 登录成功后下发设备绑定关系（可用于后续风控）
• 支持可信设备管理（记住设备30天免二次验证）
• 密码传输前端可使用RSA/SM2非对称加密，或使用SRP协议（密码永不离客户端）

8. 特殊场景校验

• 第三方登录（微信、QQ、Apple）：校验state防CSRF，校验code是否已被使用
• 无密码登录（短信登录）：必须绑定手机号 + 短信验证码 + 设备风控
• 扫码登录：防钓鱼站点、心跳保活、状态机严格校验

推荐的实战分层校验伪代码结构（Java/SpringBoot示例）

@PostMapping("/login")
public Result login(@RequestBody LoginDTO dto) {
    // 1. 基础参数校验
    validateParams(dto);

    // 2. 验证码校验
    captchaService.check(dto.getCaptchaId(), dto.getCode());

    // 3. 风控预检（IP、设备、全球限流）
    riskControl.preCheck(dto);

    // 4. 账号状态与密码校验
    User user = userService.checkAccountAndPassword(dto);

    // 5. 登录风控后置（异地、异常检测）
    riskControl.afterLogin(user, request);

    // 6. 生成token并记录登录日志
    String token = jwtUtil.createToken(user);
    loginLogService.asyncSave(user, request, true);

    return Result.ok(token);
}

总结：现代后端登录模块已远不止“用户名+密码正确就放行”，而是一整套“参数→验证码→风控→账号状态→密码→二次验证→会话管理→日志”的立体防御体系。缺任何一层都可能被拖库、撞库、短信轰炸、羊毛党攻破。

如果你的项目体量较大，强烈建议引入专业的风控系统（如阿里云滑块验证码、网易易盾、同盾、ThreatBook等）或自研设备指纹+行为分析能力。

一般使用了hugo主题的话，默认是集成了mermaid图。
若不使用hugo主题，那么就需要自己手动集成了。
步骤如下：

创建 layouts/_markup/render-codeblock-mermaid.html

负责开启一个mermaid图的html区块，内容如下：

<pre class="mermaid">
    {{- .Inner | safeHTML }}
  </pre>
  {{ .Page.Store.Set "hasMermaid" true }}

修改 layouts/_default/baseof.html

如果没有该文件就创建一个。默认情况下，所有html页面的主体结构和内容由这个文件渲染。和mermaid图相关的内容如下:

<!DOCTYPE html>
<html lang="zh-CN">

<body>
   ......
   ......
   ......

   <!-- 必须放到最后在 （.Content 之下），因为这渲染钩子直到执行 .Content 之后才会被处理），否则.Page.Store.Get "hasMermaid"永远为false -->
       {{ if .Page.Store.Get "hasMermaid" }}
    <!-- 只有文章里写了 mermaid 才加载下面这些资源，节省性能 -->
        <script type="module">
            import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.esm.min.mjs';
            mermaid.initialize({ startOnLoad: true });
        </script>
    {{ end }}
</body>
</html>

添加一个mermaid图看看效果

在网站的任意一个markdown文件里添加样例，看下效果

```mermaid
flowchart LR
%% 左右布局（TD=上下，LR=左右，TB=上下，BT=下上）
    Start[开始] --> Stop[结束]
    A[矩形节点] --> B(圆角矩形)
    C{菱形判断} -->|是| D[操作1]
    C -->|否| E[操作2]

前向安全（Forward Secrecy，简称 PFS）是 TLS（以及其他加密协议）中一个非常重要的安全属性，简单来说：
“即使攻击者将来拿到了服务器的长期私钥（即证书私钥），也无法解密之前已经完成的所有 TLS 会话”
这就是前向安全的核心意义：过去的通信记录永远是安全的，即使私钥彻底泄露。

前向安全在TLS 1.3中强制开启的，安全性由椭圆曲线离散对数问题（ECDLP）保障

ECDH（椭圆曲线 Diffie-Hellman）最核心的数学原理

一句话就能说清楚：“乘法可以随便做，除法几乎做不出来”

我们用最常用、最直观的曲线 X25519 / Curve25519 来解释（TLS 1.3 里 90% 以上用的就是它）。

1. 公共参数（全世界都一样）

• 选定一个安全的椭圆曲线：y² = x³ + 486662x² + x（模 2²⁵⁵-19）
• 选定一个基点（base point）G，一个固定的点，坐标是已知的：
  G = (9, 447…)（具体数字不重要，只要大家用同一个就行）

2. 双方各自生成临时私钥（就是随机数）

• 爱丽丝（Alice，客户端）随机选一个 256 bit 的整数作为私钥：
  a = 随机数（比如 3f1a…c2，绝对保密！）
• 鲍勃（Bob，服务器）也随机选一个 256 bit 的整数：
  b = 随机数（比如 7d2b…e9，绝对保密！）

3. 计算并公开“公钥”（其实就是把私钥乘以基点 G）

• 爱丽丝算出自己的临时公钥：
  A = a × G
• 鲍勃算出自己的临时公钥：
  B = b × G

这一步叫标量乘法（scalar multiplication），很快就能算。

4. 双方互换公钥（在网络上明文发送，没关系！）

爱丽丝把 A 发给鲍勃
鲍勃把 B 发给爱丽丝

5. 双方各自再做一次标量乘法，得到共享秘密 Z

• 爱丽丝算：Z = a × B
• 鲍勃算： Z = b × A

奇迹发生了：
a × B = a × (b × G) = (a × b) × G
b × A = b × (a × G) = (b × a) × G

因为乘法交换律，a×b = b×a，所以两个 Z 完全相等！

这就是共享秘密 Z（32 字节），网络上从来没有传输过 Z，攻击者只看到 A 和 B。

6. 为什么攻击者算不出 Z？（数学陷阱）

攻击者看到：

• G（公开）
• A = a × G（公开）
• B = b × G（公开）

他想求 Z = a × b × G
→ 必须先从 A 求出 a，或者从 B 求出 b
→ 这就是椭圆曲线离散对数问题（ECDLP）

目前人类最好的算法要花大约 2¹²⁸ 次运算才能破解 X25519（相当于 300 亿亿亿年），完全不可能。

这就是“乘法容易，除法几乎做不出来”的本质。

超级简化的数字比喻（虽然现实不是素数乘法，但帮助理解）

把椭圆曲线上的“点加”想象成普通乘法：

• G = 5（基点）
• 爱丽丝私钥 a = 7
• 鲍勃私钥 b = 13

爱丽丝发：A = 5⁷ = 78125
鲍勃发：B = 5¹³ = 1220703125

爱丽丝算：78125¹³ = 4038967834731580443708050254247865495926816947758197784423828125
鲍勃算：1220703125⁷ = 4038967834731580443708050254247865495926816947758197784423828125

攻击者看到 78125 和 1220703125，想求出 7 或 13 ，也不容易。
椭圆曲线只是把“指数”换成了“点加”，但数学难度被做得更高。

总结：ECDH 全过程一句话

1. 大家约定一个起点 G
2. 各自用自己的私钥（随机数）把 G “乘”很多次得到公钥，公开交换
3. 再把对方的公钥乘上自己的私钥，得到同一个共享秘密 Z
4. 因为离散对数难题，谁也反推不出对方的私钥 → Z 永远安全

这就是 TLS 1.3 里每一次握手都能实现完美前向安全的数学根基。

一般有两种解决办法：

一、如果这个framework不需要对外发布，那么将Build Setting里的Build Library For Distrubution 设置为NO，则可以继续使用桥接头文件(bridging-header)。

二、使用module map文件替换桥接头文件(bridging-header)，具体操作如下：

1、在framework工程里创建一个头文件，如Test.h
在Build Setting里设置User Header Search Paths，如$(SRCROOT)/$(PRODUCT_NAME)。设置的路径需要能找到Test.h文件

2、在Test.h文件里引入需要引用的Objective-C头文件

#import <MyLib/MyLib.h>

3、创建一个module map文件,module.modulemap，内容如下

module  TestModule (名字自定义)  {
    header "Test.h"
    export *
}

4、在Swift文件里，使用import指令，然后就可以调用Objective-C的方法了

import  TestModule

同时使用public 和 @objc标记

要给Objective-C暴露swift编写的api，则需要使用public 和 @objc标记

@objc public class MySwiftClass: NSObject {
    @objc public func doSomething() {
        print("Doing something in Swift")
    }
}

生成 Objective-C 兼容头文件

Swift Framework 的 Build Settings 中：

• Defines Module 设置为 YES。
• Install Generated Header 设置为 YES。
  这会生成一个 FrameworkName-Swift.h 头文件，包含 Swift 代码的 Objective-C 接口。

在 Objective-C 项目中导入导入 Swift Framework 的头文件

#import <FrameworkName/FrameworkName-Swift.h>

MySwiftClass *swiftObject = [[MySwiftClass alloc] init];
[swiftObject doSomething];

本文成文环境：

• macOS 26
• Xcode 26 以及 iOS SDK
• Android Studio MeerKat Feature Drop 以及 Android SDK、NDK
• JDK 17
• Gradle 8.11.1

Kotlin Multiplatfrom 通过Cinterop工具调用C/C++方法，也可以通过JNI规范调用C/C++方法。

本质上，都是调用C方法，C++方法需要通过extern "C"修饰为C方法。

本文将介绍Kotlin/Native在Android和iOS环境，如何调用C/C++方法。

Android Studio

推荐使用 Android Studio 开发Kotlin/Native （Kotlin更像是一款Android开发语言）

Gradle

Android Studio的御用构建工具（相比其构建工具，复杂且难用）

CMake

一个事实上的C/C++构建标准工具，在Android和iOS环境调用各自平台的工具链构建C/C++。

创建 Kotlin Multiplatfrom 工程

如果Android Studio没有 Kotlin Multiplatfrom 工程模版，则需要先安装 Kotlin Multiplatfrom插件。
安装完成后，使用 Kotlin Multiplatfrom 工程模版创建一个工程（创建过程中，需要选择iOS的包管理方式，选择cocoapods）

镜像

因为环大陆的网络墙问题，可能需要配置下镜像仓库

1、找到工程根目录下的settings.gradle.kts,添加下镜像仓库（下面配置的是阿里云的maven仓库）

// settings.gradle.kts

pluginManagement {
    repositories {
        maven{ setUrl("https://maven.aliyun.com/repository/public") }
        maven{ setUrl("https://maven.aliyun.com/repository/central") }
        maven{ setUrl("https://maven.aliyun.com/repository/gradle-plugin") }
...
...
...
    }
}

dependencyResolutionManagement {
    repositories {
        maven{ setUrl("https://maven.aliyun.com/repository/public") }
        maven{ setUrl("https://maven.aliyun.com/repository/central") }
        maven{ setUrl("https://maven.aliyun.com/repository/gradle-plugin") }
...
...
...
    }
}

2、找到根目录下gradle/wrapper/gradle-wrapper.properties，替换为distributionUrl

#gradle/wrapper/gradle-wrapper.properties

#distributionUrl=https\://services.gradle.org/distributions/gradle-8.11.1-bin.zip
distributionUrl=https\://mirrors.cloud.tencent.com/gradle/gradle-8.11.1-all.zip

bin是二进制工具，all包含二进制和源码，gradle工具构建时可能会下载源码。

修改shared模块

默认情况下，创建的工程会有一个shared模块
展开后，可以看到src目录下有androidMain、commonMain、iosMain

使用Android Studio在shared模块中添加C/C++（鼠标右键选中shared模块，Add C/C++ to Module），这样就添加了Android Native相关代码,目录如下:

shared
        |_src
                |_commonMain (通用方法)
                    |_kotlin
                        |_com.example.kmpapptest(包名)
                            |_Platform.kt
                |_androidMain (android平台相关的方法)
                    |_kotlin
                        |_com.example.kmpapptest(包名)
                            |_Platform.android.kt
                |_iosMain (ios平台相关的方法)
                    |_kotlin
                        |_com.example.kmpapptest(包名)
                            |_Platform.ios.kt
                |_main (C/C++方法)
                    |_cpp
                        |_CMakeLists.txt (Android so构建配置)
                        |_main.cpp

因为我们使用的Android Studio的Add C/C++ to Module菜单创建的C/C++目录，所以在shared模块的build.gradle.kts里会自动添加Android平台的JNI构建任务

android {
    ...
    defaultConfig {
        ...
        externalNativeBuild {
            cmake {
                cppFlags += ""
            }
        }
        ...
    }
    ...
    externalNativeBuild {
        cmake {
            path = file("src/main/cpp/CMakeLists.txt")
            version = "3.22.1"
        }
    }
    ...
}

expect/actual

kotlin关键字 expect用来声明方法，actul标记实现方法。

我们在commonMain 中的Platform.kt声明(expect)一个 get_native_message()方法

// shared/src/commonMain/kotlin/com/example/kmpapptest/Platform.kt

package com.example.kmpapptest

expect fun get_native_message(): string 

在androidMain和iOSmain各自实现(actual)这个get_native_message方法

// shared/src/androidMain/kotlin/com/example/kmpapptest/Platform.kt

package com.example.kmpapptest

actual fun get_native_message(): String{
    return AndroidNativeLib.stringFromJNI()
}

class AndroidNativeLib {
    companion object {
        external fun stringFromJNI() : String
        init {
            System.loadLibrary("android-native-lib")
        }
    }
}

// shared/src/iosMain/kotlin/com/example/kmpapptest/Platform.kt

package com.example.kmpapptest
import kotlinx.cinterop.toKString

@kotlinx.cinterop.ExperimentalForeignApi
actual fun get_native_message(): String{
    return iosNativeLib.get_message()?.toKString().toString()
}

Kotlin通过JNI在Android环境调用C/C++方法

再来回顾下 AndroidNativeLib的stringFromJNI方法

package com.example.kmpapptest

class AndroidNativeLib {
    companion object {
        external fun stringFromJNI() : String
        init {
            System.loadLibrary("android-native-lib")
        }
    }
}

在C/C++侧，对应的方法名为Java_com_example_kmpapptest_AndroidNativeLib_00024Companion_stringFromJNI

kotlin方法名和C/C++方法的对应规则:
1、Java_包名_类名_方法名
2、Java_包名_方法名
3、Java_包名_类名_00024Companion_方法名
"00024Companion" 是 "$Companion" 的转译字符串

在shared//src/main/cpp/main.cpp中添加对应方法

//shared/src/main/cpp/main.cpp

#include <jni.h>

extern "C" JNIEXPORT jstring JNICALL
Java_com_example_kmpapptest_NativeLib_00024Companion_stringFromJNI(JNIEnv * env , jobject thiz) {
    return env->NewStringUTF("test_kotlin_call_android_native");
}

修改shared/src/main/cpp/CMakeLists.txt

...
project("android-native-lib") # 这里的名字要和AndroidNativeLib类加载的lib库名对应
...

到这里，可以运行 androidApp看下效果

Kotlin通过Cinterop在iOS环境调用C/C++方法

在shared/main/创建cinterop/CMakeLists.txt,cinterop/ios_cmake.sh，cinterop/ios.cpp,cinterop/ios.h，cinterop/ios.def

shared
        |_src
                |_main (C/C++方法)
                    |_cinterop
                        |_CMakeLists.txt (ios lib 构建配置)
                        |_ios_cmake.sh (cmake构建具体命令)
                        |_ios.h (方法声明)
                        |_ios.cpp (方法实现)
                        |_ios.def (暴露给kotlin的方法定义文件)

方法声明和实现

//shared/src/main/cinterop/ios.h

#ifndef TEST_SHARED_IOS_H
#define TEST_SHARED_IOS_H

#if defined(__cplusplus)
extern "C" {
#endif

const char *get_message(void);

#if defined(__cplusplus)
}
#endif

#endif //TEST_SHARED_IOS_H

//shared/src/main/cinterop/ios.cpp

#include "ios.h"

extern "C"  const char *get_message(void)
{
    return "cinterop_test_kotlin_call_ios_native";
}

CMakeLists.txt 和 ios_cmake.sh

编辑shared/src/main/cinterop/CMakeLists.txt

# shared/src/main/cinterop/CMakeLists.txt

# Sets the minimum CMake version required for this project.
cmake_minimum_required(VERSION 3.22.1)

# 编译模块名 产物为libnative-lib
project("native-lib")

# 设置系统环境
set(CMAKE_SYSTEM_NAME iOS)
# 设置cpu arch
set(CMAKE_OSX_ARCHITECTURES arm64 x86_64)

# 指定头文件目录
include_directories(${CMAKE_SOURCE_DIR})

# 收集所有 源文件
file(GLOB SOURCES
        ${CMAKE_SOURCE_DIR}/*.cpp
)

add_library(${CMAKE_PROJECT_NAME} STATIC
        # List C/C++ source files with relative paths to this CMakeLists.txt.
        ${SOURCES})

编辑shared/src/main/cinterop/ios_cmake.sh

# 产物输出目录 (外面传入参数)
build_output_dir=$1

# 根据CMakeLists.txt生产构建配置信息，如makefile
cmake . -B $build_output_dir

cd $build_output_dir
#执行构建
cmake --build .

可以手动执行ios_cmake.sh看下效果，执行后记得清理输出物

cd ios_cmake.sh目录
./ios_cmake.sh  ./buildout

.def文件

暴露给kotlin的方法定义文件
内容如下：

# shared/src/main/cinterop/ios.def

# 暴露给kotlin的包名
package = iosNativeLib

# 暴露给kotlin的头文件，kotlin侧可以看到里面的方法名
# 这里的路径是相对于.def文件的路径
headers = ios.h

# 构建过程中，链接库的搜索目录
# 这里的路径是相对于projectdir（gradle的这个设定是不是bug？）
# 也可以使用绝对路径，从工程管理角度不建议用绝对路径
libraryPaths = build/cmake

# 需要链接的库文件，这里需要链接上面的iOS nativle lib
# 查找libraryPaths目录下的库文件
staticLibraries = libnative-lib.a

修改Gradle脚本

上面已经完成了ios native lib的构建，以及native lib需要暴露的方法配置，现需要使用Gradle脚本将这些工作串起来。

// shared/build.gradle.kts

fun org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget.addCInterop_sharedCC() {
    val main by compilations.getting // target name : main or test
    val iosNativeLib by main.cinterops.creating {
        // .def 定位文件
        defFile("src/main/cinterop/ios.def") 
        // kotlin侧需要搜索的头文件目录
        includeDirs("src/main/cinterop")
    }
}

kotlin {
    ...

    iosX64() {
        addCInterop_sharedCC()
    }
    iosArm64()  {
        addCInterop_sharedCC()
    }
    iosSimulatorArm64() {
        addCInterop_sharedCC()
    }
    ...
}

...
// 创建ios_buildCmake任务
val ios_buildCmake by tasks.registering(Exec::class) {
    val ios_cmakebuildDir = File(projectDir ,"build/cmake")
    val ios_cmakeSourceDir = File(projectDir,"src/main/cinterop")
    description = "Build native C/C++ with CMake"
    workingDir = ios_cmakeSourceDir
    commandLine = listOf("sh", "ios_cmake.sh" , ios_cmakebuildDir.absolutePath)
}
# 设置cinterop的ios构建任务依赖ios_buildCmake任务
tasks.matching { it.name.startsWith("cinterop") && it.name.contains("Ios") }.all {
    dependsOn(ios_buildCmake)
}

至此，可以执行iOSApp看看效果

总结

在无法摆脱C/C++生态的情况下，使用Kotlin Multiplatfrom实现跨平台，维护成本比较高，不如直接使用C/C++。

还有一种原因是http协议导致的，切换到ssh协议成功率会更高。需要注意，使用ssh协议，需要有github账号，并配置好ssh 公钥信息。

使用ssh协议更新成功后，还要记得再将本地的cocoapods git仓库设置为http协议.

cd ~/.cocoapods/repos/cocoapods

// ssh
git remote set-url origin https://github.com/CocoaPods/Specs.git

// http
git remote set-url origin git@github.com:CocoaPods/Specs.git

最后，首次初始化cocoapods repo仓库，也可以使用ssh协议

cd 一个临时文件夹
// 克隆到tmpRepo文件夹
git clone  git@github.com:CocoaPods/Specs.git tmpRepo

// 添加repo
pod repo add trunk /xxx/yyy/tmpRepo

// 修改远程地址
cd ~/.cocoapods/repos/cocoapods
git remote set-url origin https://github.com/CocoaPods/Specs.git

otool和install_name_tool

# 显示依赖库列表
otool -L  <mach-o文件路径>

# 添加新的依赖库路径
install_name_tool  -add_rpath  <rpath>   <mach-o文件路径>

# 删除依赖库路径
install_name_tool -delete_rpath  <rpath>  <mach-o文件路径>

# 替换依赖库路径
install_name_tool -change  <old_rpath>  <new_rpath>   <mach-o文件路径>

yololib 和ios App

对于iOS App，install_name_tool的-add_rpath、 -delete_rpath总是执行失败，需要借助yololib工具添加依赖

# 删除iOS App 的依赖
install_name_tool -change 需要删除的依赖   替换的空依赖 #变相实现删除

# 排序iOS App 的依赖
# 不断执行 install_name_tool -change  ，实现排序