iOS 引用 C/C++ 项目：交叉编译与 Objective-C++

于 2019-08-30 16:23:54 发布
阅读量3.2k 收藏 4
点赞数
分类专栏： Objective-C
原文链接：https://blog.rinc.xyz/posts/170606-objcxx/
版权

转自:https://blog.rinc.xyz/posts/170606-objcxx/

最近终于有幸参与公司的 iOS 项目，其中有个 C/C++ 写的库需要调用；

之前对 Android JNI/NDK 调用 C/C++ 还算熟悉，但 iOS 混编 C/C++ 却是初次接触，各种被虐..

上个周末基本都在解决库的编译问题，爱人 Amble 也耐心帮我查资料、作分析，感动之余，决定把中途遇到的问题记录下来。

静态库 or 动态库？

iOS 不支持调用第三方动态库(.dylib)，应该是出于安全考虑，比如各种越狱工具就大量使用动态库；

一开始在这里耽误很久，.dylib 库编译没问题，但是 Xcode 项目引用后一直报 ‘library not load’、’symbols not found for architexture’ 之类的错误..

C++ 头文件去掉动态链接代码

C++ 动态库接口对应的头文件，需要将 __declspec(dllexport) 、__stdcall 等关键字去掉；

CMake 脚本改为动态链接

add_library(${PROJECT_NAME}) SHARED ${SOURCE_FILES})

这里 SHARED 改为 STATIC 即可。

交叉编译

Mac 上直接跑 CMake 编译出来的是 X86 架构的，iOS 上无法运行，需要一个调用 xcodebuild 的 CMake 脚本做交叉编译；

Google Code 上的这个 iOS-CMake 项目年久失修，需要自己做一些改动。

修改 Xcode 路径

exec_program(/usr/bin/xcode-select ARGS -print-path OUTPUT_VARIABLE CMAKE_XCODE_DEVELOPER_DIR)
set (XCODE_POST_43_ROOT "${CMAKE_XCODE_DEVELOPER_DIR}/Platforms/${IOS_PLATFORM_LOCATION}/Developer")

这里自动检测安装路径并设置，不需要写死，也不需要编译时指定编译选项；

编译器设置和检查

CMakeForceCompiler 已经过时，直接指定编译器为 Clang 就好：

set (CMAKE_C_COMPILER /usr/bin/clang clang)
set (CMAKE_CXX_COMPILER /usr/bin/clang++ clang)

后面需要跳过编译器检查，否则编译会报错中断：

set (CMAKE_CXX_COMPILER_WORKS TRUE)
set (CMAKE_C_COMPILER_WORKS TRUE)

修改 Architecture

if (IOS_PLATFORM STREQUAL "OS")
    set (IOS_ARCH "armv7;armv7s;arm64")
elseif (IOS_PLATFORM STREQUAL "SIMULATOR")
    set (IOS_ARCH "i386;x86_64")
elseif (IOS_PLATFORM STREQUAL "WATCHOS")
    set (IOS_ARCH "armv7k")
endif ()

这里可以根据实际情况做取舍，比如最新 iOS 11 就宣布不支持非 64 位架构，真机和模拟器可以分别只保留 arm64、x86_64；

另外，还新增了 WatchOS 的支持。

禁用 CMake 可执行编译选项

一般 C/C++ 项目每个模块下面都会添加包含 main() 的测试代码，需要在 CMakeLists.txt 文件中注释掉 #add_executable 相关代码，否则后面编译会报以下错误：

target specifies product type ‘com.apple.product-type.tool’, but there’s no such product type for the ‘iphoneos’ platform

调用 CMake 创建并编译 Xcode 项目

CMake 添加 -DCMAKE_TOOLCHAIN_FILE 选项指定 iOS 交叉编译脚本，-GXcode 选项指定生成项目类型为 Xcode：

cmake -DCMAKE_TOOLCHAIN_FILE=./ios.cmake -DIOS_PLATFORM=SIM -H. -Bbuild.sim -GXcode
cmake --build build.sim/ --config Release

上面是模拟器的库编译，真机类似。

使用 xcodebuild 自动编译项目

后面发现，如果存在库的依赖关系，即 CMakeLists.txt 中设置了 target_link_libraries，上面生成的 Xcode 工程并不会自动添加库依赖，需要自己手动设在 Build Phases 的 Link Binary with Libraries 中设置；

设置完后，只要不增删 C/C++ 代码，就不用重新生成 Xcode 项目，可以通过 xcodebuild 自动编译：

xcodebuild clean
xcodebuild -target xxx

这个工具在自动打包时经常用到。

符号表相关编译设置

我们知道，符号表(symbols) 包含 C/C++ 程序中的变量和函数信息，虽然可方便调试，但是会显著增加包大小；

Xcode 的 Build Settings 包含一些符号表相关设置，这里介绍两个常用的、和 Clang 编译选项有关的：

  • Generate Debug Symbols: 开启后，编译每个源文件时会自动带上编译选项 -g 和 -gmodules，生成完整的调试信息，如果 C/C++ 层代码 crash 后会自动跳转到源代码行数；关闭后，crash 时会直接跳到汇编代码；一般建议至少调试阶段应该开启；

  • Debug Info Level: 如果设置为 Line Tables Only，会自动带上编译选项 -gline-tables-only，调试信息就只会包含函数名、文件名、行号，不包含变量；

也可以先不管这些设置，最后直接通过 strip -x -S old.a -o new.a 命令去掉符号表信息；

更多内容可参考：

库的合并与检查

macOS 自带的 lipo 命令可用于将真机和模拟器的库文件合并：

lipo -create "lib/ios/libXXX.a" "lib/sim/libXXX.a" -output "lib/generic/libXXX.a"

最后，再介绍两个有用的命令行工具：

  • file xxx.a：可以查看库文件的架构信息；

  • lipo -info xxx.a：也可以查看库文件的架构信息；

  • nm -a xxx.a：可以查看库的符号表信息；

详细编译脚本参考这里。

Objective-C 混编 C/C++

C++ 头文件编译问题

C++ 工程的 .h 文件直接拷进 Xcode 是可能编译不过的，如果在头文件使用了 C++ 语法的话；

因为 Xcode 默认当做 C 头文件编译，解决方式有两个：

  1. 扩展名改为 .hpp 或 .hxx，让编译器知道这是 C++ 头文件；

  2. 在使用 C++ 语法的代码块前后分别添加 #ifdef __cplusplus 和 #endif 宏；

除了上面的问题，如果头文件定义了 const 常量，并且被多次 include 的话，Xcode 编译会报 ‘duplicate symbol’ 的异常；

原因是被认为重复定义，解决方式是在前面添加 static 关键字。

Objective-C 和 C/C++ 数据类型转换

主要是 NSString/NSData、std::string 、char* 这三者之前的相互转换，这里我定义了一些宏方便调用：

#define STDStr2Int(str) std::atoi(str.c_str())
#define STDStr2Float(str) std::atof(str.c_str())
#define STDStr2Long(str) std::atol(str.c_str())
#define STDStr2LongLong(str) std::atoll(str.c_str())
#define NSStr2CharP(nsStr) (char*)[nsStr cStringUsingEncoding:NSUTF8StringEncoding]
#define NSStr2STDStr(nsStr) std::string([nsStr cStringUsingEncoding:NSUTF8StringEncoding])
#define STDStr2NSStr(stdStr) [NSString stringWithCString:stdStr.c_str() encoding:NSUTF8StringEncoding]
#define STDStr2NSData(stdStr) [NSData dataWithBytes:stdStr.data() length:stdStr.size()]]
#define charP2NSStr(charP) [NSString stringWithCString:charP encoding:NSUTF8StringEncoding]
#define charP2NSData(charP) [[NSData alloc] initWithBytes:charP length:strlen(charP)]
#define charV2STDStr(charV) std::string(charV.begin(), charV.end())
#define NSStr2NSData(nsStr) [nsStr dataUsingEncoding:NSUTF8StringEncoding]
#define NSData2NSStr(nsData) [[NSString alloc] initWithData:nsData encoding:NSUTF8StringEncoding]

还有一点要注意，对于包含汉字等宽字节的 NSString，如果要传字节长度到 C/C++ 层，不能直接调 [nsString length]，因为它返回的是字符数而不是字节数；

可以先将 NSString* 转为 char*，然后调用 C/C++ 的 std::strlen() 得到字节数:

char *charP = NSString2CharP(nsStr);
int charLength = std::strlen(charP);

内存管理

我们知道，Objective-C 的 init 和 dealloc 方法分别对应 C++ 的构造函数和析构函数，混编时他们的对象内存也是各自管理的；

Objective-C 中如果创建了全局 C/C++ 对象，需要在 dealloc 方法中释放;

同样，如果 C++ 创建了 Objective-C 对象，也需要在析构函数中释放；

二进制数据传递问题

通常 Android/iOS 调用底层 C/C++ 库最多的场景就是图像和音视频处理了，这就涉及到二进制数据的传递；

具体到我参与的项目，传递的数据是一个 std::map<std::string,std::string> 类型参数；

一开始看到 std::string 很自然联想到 Objective-C 中对应的 NSString，所以做了个“画蛇添足”的转换：先把 NSData 转换为 NSString，再将 NSString 转为 std::string；

为什么要先转换为 NSString 呢？因为一开始打算在 Objective-C++ 的 wrapper 类屏蔽掉 C++ 的类型，外部调用全部传入 Objective-C 的类型；

但既然要转为 NSString 就涉及到 encoding 的问题，但很快发现无论 NSUTF8StringEncoding 还是 NSASCIIStringEncoding 都有问题；

最后改为直接 NSData 和 std::string 之间转换，而且考虑到上面提到的内存管理问题，避免 EXC_BAD_ACCESS，每次传递时都做下数据拷贝：

template<typename T>
inline T MALLOC(long length) {
    return reinterpret_cast<T>(std::malloc(length * sizeof(T)));
}

template<typename T>
inline T COPY(T src, long length) {
    T data = MALLOC<T>(length);
    std::memcpy(data, src, length);
    return data;
}

inline std::string copySTDStrFromNSData(NSData* data) {
    long size = [data length];
    Byte* bytes = COPY<Byte*>((Byte*)[data bytes], size);
    std::string str(reinterpret_cast<char const*>(bytes), size);
    return str;
}

inline NSData* copyNSDataFromSTDStr(std::string str) {
    long size = str.length();
    Byte* bytes = COPY<Byte*>((Byte*)str.c_str(), size);
    NSData *data = [NSData dataWithBytes:bytes length:size];
    return data;
}

注意 std::string 构造函数要带上 length 参数，否则二进制数据很可能被截断。

C/C++ 回调 Objective-C

Objective-C 中的 C 回调函数是无法直接访问类的成员和方法的，甚至会报 ‘exc_bad_access’ 错误；

那么如何解决这个问题呢？

熟悉 JNI 的都知道，它的每个 JNI 函数第一个参数都是 JNIEnv*，是访问 JVM 相关接口的桥梁；

同样，这里我们也可以在回调函数中增加 Objective-C 对象的指针参数，用来间接访问类成员和方法；

但是，这个 Objective-C 对象指针在 C/C++ 环境下是无法直接使用的，还得借助一个双方都能识别的桥梁 — void*；

而 Objective-C 对象指针和 void* 的相互转换，则需要依赖 Bridged Cast：

  • __bridge 可用于类型互转，但是不改变对象的所有权(ownership);

  • __bridge_retained 用于将 Objective-C 对象指针转换为 C/C++ 对象指针，同时获得所有权；

  • __beidge_transfer 用户将 C/C++ 对象指针转换为 Objective-C 对象指针，同时放弃所有权；

其实系统的 Core Foundation 很多地方 也使用到这种类型转换。

最后看个 C++ 调用 Objective-C 的示例：

首先定义接口函数指针类型:

typedef void (*Callback)(void* obj, int x);

Objective-C 类的回调函数中，通过 __bridge_transfer 将 void* 还原为对象指针：

void funcObjc(void* obj, int x) {
    [(__bridge_transfer Objc*)obj doInObjc:x];
}

@implementation Objc

-(id)init {
    if (self = [super init]) {
        self.callback = funcObjc;
    }
    return self;
}

-(void)doInObjc:(int)x {
    NSLog(@"doInObjc: %d", x);
}

@end

C++ 构造函数接收 Objective-C 传过来的 void* 和函数指针，用于执行该回调函数：

Cxx::Cxx(void* objc, Callback callback) {
    this->objc = objc;
    this->callback = callback;
}

void Cxx::doInCxx(int x) {
    std::cout << "doInCxx: " << x << std::endl;
    this->callback(this->objc, x);
}

最终调用时，将 Objective-C 对象通过 __bridge_retained 转为 void* 传给 C++ 对象:

Objc* objc = [[Objc alloc]init];
void* vp = (__bridge_retained void*)objc;
Cxx* cxx = new Cxx(vp, objc.callback);
cxx->doInCxx(9);

也可以将上面的 __bridge_transfer 和 __bridge_retained 全部改为 __bridge。

[完整代码]

 

yunshouhu
关注
  • 0
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值