分类目录归档:iOS/macOS

Qt 通过自定义 URL Scheme 给已经运行的应用传参(Windows&macOS)

在传统的应用程序设计中,我们可以看到很多通过浏览器唤起本地应用的案例,比如百度网盘、迅雷等工具,他们在浏览器访问一个非 http/https 协议开头的地址时,会自动打开其自己的应用程序并传递一定的参数。该功能的实现方式网络上有很多示例,在 Windows 和 macOS 不同平台下他们分别需要如下设置:

继续阅读

使用 CMake + Git Submodule 方式管理项目三方库

在项目开发过程中,避免不了要使用一些开源的三方库,我参加过的一些团队有不同的管理三方库的方式。不同的方式都各有优缺点,我们先列举一下碰到过的管理方式,说一些他们的优缺点,最后再来讨论我们今天介绍的管理方式弥补了哪些缺点。

统一管理三方库

一些团队是直接将三方库编译好放到 CI 机器上,在本地开发或者 CI 出项目的 Release 包时去做依赖拷贝。这样做有以下几点好处:

  1. 三方库不需要每次都重新编译,需要时拷贝,包括符号调试文件也可以一并维护。
  2. 大家公用一份三方库,确保三方库的出处都是一样的。

但是这样管理也有一些不足。

  1. 如果不同的项目需要依赖不同版本、不同分支的三方库,则统一的管理无法满足需求
  2. 三方库的版本管理迭代会保留诸多历史文件,一旦历史版本被清理则很难追溯历史缺陷的符号调试文件

上传三方库文件到 Git 中

编译好直接上传到项目的仓库中,这种方式有一些好处,比如:

  1. 工程下载下来不需要多余配置,启动 IDE 直接编译不废话。
  2. 自己想依赖什么版本就什么版本,不受限于其他项目

当然缺点显而易见:

  1. 静态库文件编译后非常大,上传到 Git 仓库中仓库会异常庞大,特别是三方库二进制文件的更新。
  2. 这种形式很容易出现源码和三方库文件不匹配的情况,这个项目编译好的复制到其他项目直接用,管理混乱。
  3. 跨平台项目要上传不同平台的三方库二进制文件到工程中

使用 CMake + Git Submodule 形式管理

通过以上的描述,我们已经很容易能看清楚不同的管理方式的优劣了。本文推荐的方法可以弥补一些上面方式的不足,但可能也因不同团队而异。推荐的方式大概分以下步骤。

  1. 将你需要依赖的三方库设置为 Git Submodule,每个项目可以依赖不同版本的三方库,不需要上传二进制文件。
  2. 脚本利用 CMake 自动编译三方库工程,不同平台可以使用 CMake 自动编译,不需要单独维护个别版本。
  3. CI 出 Release 时自动编译三方库并保留匹配版本的调试符号文件,和本地源码原始匹配不易混乱。

我们以一个 libyuv 三方库举例。首先将项目添加为 Git Submodule

git submodule add https://chromium.googlesource.com/libyuv/libyuv third_party/libyuv

添加完成后,我们写一个自动编译三方库的脚本,Windows 平台下使用批处理、macOS 下使用 Shell 脚本。

# Windows: Generate visual studio solution
cmake -H. -Boutput -G"Visual Studio 15 2017"
# Build release library
cmake --build output --config Release --target yuv
# Build debug library
cmake --build output --config Debug --target yuv
# macOS: Generate makefile
cmake -H. -DCMAKE_MACOSX_RPATH=OFF -DCMAKE_BUILD_TYPE=Release -Boutput -G"Unix Makefiles"
# Static library
cmake --build output --target yuv

这样在不同平台我们就可以自动编译三方库二进制文件了,本地开发时只需要将 Submodules 更新下来,头文件和库文件路径都修改为三方库文件的路径。CI 出 Release 包时也是先将 Submodules 更新下来编译后再编译项目主体。

Qt for iOS 应用使用自定义动态库 Framework

本文内容适合当你想使用 Qt 调用 xcode 开发的动态库 framework 做 iOS 应用的场景,文中涉及到原始动态库 framework 文件的配置,以及 Qt 如何引入和打包动态库 framework 到自身程序中的方法。

动态库 framework 的配置

默认 xcode 创建的 framework 都已经是动态库形式了,所以这里不多介绍,请确保你的 Build Settings 中以下设置是无误的,特别是 Dynamic Library Install Name Base,它决定了动态库能否被应用成功搜索到。

对于 @rpath 的说明,请看这里:https://www.cnblogs.com/csuftzzk/p/mac_run_path.html

Qt 项目配置引入 framework

Qt 引入 framework 只需要给 LIBS 追加 framework 的路径和要链接的文件就可以了,配置如下,请注意使用 framework 参数是 -F 和 -framework(注意大小写)

LIBS += -F$$PWD/../../build/Products/Release
LIBS += -framework my_dylib.framework

这样引入还是不行的,因为 iOS 应用部署上去以后动态库的 framework 文件是不会跟随打包进去的,所以你还需要做一件事情就是把 framework 打包到你的应用中,配置如下:

MY_DYLIB_FRAMEWORK.files = $$PWD/../../build/Products/Release-iphoneos/my_dylib.framework
MY_DYLIB_FRAMEWORK.path = /Frameworks
QMAKE_BUNDLE_DATA += MY_DYLIB_FRAMEWORK

分别指定了 framework 文件的路径和要被打包进去的目标路径,这里是将 $$PWD/../../build/Products/Release-iphoneos/my_dylib.framework 这个 framework 打包到了应用的 /Framework 目录下。最终你看到的应用目录结构是这样的

├── Default-568h@2x.png
├── Frameworks
│   └── my_dylib.framework
│       ├── Info.plist
│       ├── ReadMe.txt
│       ├── _CodeSignature
│       │   └── CodeResources
│       └── my_dylib
├── Info.plist
├── LaunchScreen.nib
├── PkgInfo
├── _CodeSignature
│   └── CodeResources
└── cross-platform-demo

可以看到,mu_dylib.framework 文件已经在我们应用的 /Framework 目录下了,这样文件就被打包进去了,而且当你使用 Qt 编译程序的时候,在 Build Shadow 目录下会看到生成对应的 xcodeproj 文件,可以直接使用 xcode 打开,使用 xcode 打开项目后可以看到项目的 Build Phases 下面多了一条 Copy file to bundle 的项目:

但是当你尝试在 iOS 或者模拟机中运行这个应用时你会发现又有新的错误了,如下所示:

dyld: Library not loaded: @rpath/my_dylib.framework/my_dylib
  Referenced from: /var/containers/Bundle/Application/D0143CDE-FFFE-4343-BFD9-D70DA66C831F/cross-platform-demo.app/cross-platform-demo
  Reason: image not found
program received signal 6, thread:15362b

我明明已经把文件复制进去了,为什么还是会提示,还记得上面我们提到的 Dynamic Library Install Name Base 吗?这是动态库 framework 设置的,根据上面文章的资料,我们要在调用该模块的应用中设置 rpath 的搜索范围,让其能找到我们的动态库文件。Qt 项目中添加如下配置:

# 添加应用的 runpath 路径,因为 my_dylib 动态库 Framework 设置的 install path 为 rpath,所以应用使用时需要单独设置
QMAKE_LFLAGS += -Wl,-rpath,@loader_path/Frameworks

如此设置后,在 Qt 中就可以成功编译程序并运行在模拟器或真机上了,如果还有任何疑问欢迎留言我们一起讨论。