Swift on Android：跨平台探索的新维度 – 深入介绍与入门指南

引言

在移动应用开发领域，iOS 平台通常与 Swift 语言紧密相连，而 Android 平台则以 Kotlin 和 Java 为主导。开发者们常常面临一个挑战：如何在不同平台之间共享代码，减少重复工作，同时又保持原生应用的性能和用户体验？跨平台开发框架如 React Native、Flutter 等提供了 UI 层的共享方案，但它们并非总是适用于所有场景，尤其是在需要极致性能或深度平台集成的核心业务逻辑部分。

长期以来，Swift 以其现代化的特性、卓越的性能和安全性赢得了 iOS 开发者的喜爱。随着 Swift 语言的开源，一个令人兴奋的可能性浮现了：能否将 Swift 的强大能力带到非 Apple 平台，特别是 Android？

本文将带你深入探索 Swift 在 Android 平台上的世界。我们将从为什么会有人考虑在 Android 上使用 Swift 开始，然后详细介绍其背后的技术原理，探讨其适用的场景，并提供一份详细的入门实践指南，帮助你迈出第一步。请注意，这并非意味着 Swift 将取代 Kotlin 或 Java 成为 Android 开发的主流语言，而是一种在特定需求下实现跨平台代码共享的强大补充方案。

第一部分：为何探索 Swift 在 Android 上的可能性？

Swift 最初由 Apple 为 iOS、macOS、watchOS 和 tvOS 开发，并于 2015 年底宣布开源。这一举动是 Swift 走向更广阔天地的关键。开源意味着 Swift 不再局限于 Apple 的生态系统，理论上可以在任何支持其运行时和编译器的平台上运行。

那么，为什么开发者会考虑在 Android 上使用 Swift 呢？主要原因包括：

代码共享与复用： 对于已经拥有大量 Swift 核心逻辑代码的 iOS 应用，或者希望为未来的 iOS 和 Android 应用构建一套共享业务逻辑层的团队来说，在 Android 上运行 Swift 代码是实现最大化代码复用的直接途径。这减少了用 Kotlin 或 Java 重写相同逻辑的工作量，降低了潜在的 bug 和维护成本。
Swift 语言的优势： Swift 提供了许多现代编程语言的特性，如内存安全（通过 ARC – 自动引用计数）、类型推断、强大的枚举和模式匹配、函数式编程支持、以及简洁清晰的语法。这些特性使得编写高性能、安全且易于维护的代码成为可能。
性能需求： 对于计算密集型任务、复杂的算法处理或对性能要求极高的模块（例如音视频处理、游戏引擎的一部分、加密解密等），原生代码往往是首选。虽然 Kotlin 和 Java 在大多数情况下性能良好，但 Swift 作为一种编译型语言，在某些场景下可以直接编译为高效的机器码，并能更好地控制内存布局，可能提供更接近 C/C++ 的性能。将这部分核心逻辑用 Swift 编写，并在 iOS 和 Android 上共享，是一种有效的性能优化策略。
统一技术栈（部分）： 即使 UI 层仍然是原生（Compose/Views for Android, SwiftUI/UIKit for iOS），如果核心业务逻辑、数据模型、网络通信层等都可以用 Swift 编写并在两个平台上共享，那么整个项目的技术栈在非 UI 部分可以得到一定程度的统一，便于团队成员的协作和知识共享。
技术探索与学习： 对于对新技术充满好奇的开发者来说，探索如何在非原生平台上运行自己熟悉的语言本身就是一种有价值的学习体验，有助于理解跨平台开发的底层原理。

需要强调的是，Swift 在 Android 上的应用目前主要集中在共享非 UI 的业务逻辑和高性能计算模块。用 Swift 构建完整的 Android 应用，特别是涉及复杂的原生 UI 和 Android Framework API 的部分，目前是极具挑战甚至不可行的。

第二部分：Swift 在 Android 上的技术原理

Swift 如何能够在 Android 设备上运行呢？这主要依赖于以下几个关键技术和组件：

开源 Swift Toolchain： Apple 开源了 Swift 语言本身以及其配套的编译器（基于 LLVM）和标准库。Swift.org 网站提供了用于不同操作系统（包括 Linux）和架构的 Swift 构建版本。 Android 设备通常使用 ARM 或 x86 架构，Swift 社区和贡献者已经为这些架构提供了交叉编译支持。这意味着可以使用特定版本的 Swift 编译器，将 Swift 代码编译成针对 Android 目标平台的机器码。
Android NDK (Native Development Kit)： Android NDK 是一套允许开发者将 C、C++ 或其他能够编译为原生代码的语言集成到 Android 应用中的工具。它提供了必要的头文件、库和工具链，用于构建可以在 Android 运行时 (ART) 之上运行的原生库 (.so 文件)。Swift 编译后的代码需要打包成一个或多个 .so 库，然后通过 NDK 的机制集成到 Android 应用中。
JNI (Java Native Interface)： 这是连接 Java/Kotlin 代码与原生代码（包括 Swift 编译出的代码）的桥梁。JNI 是一套编程接口，允许 Java 代码调用原生方法，也允许原生代码调用 Java 方法。要在 Android 应用中调用 Swift 函数，需要通过 JNI 定义相应的接口。Swift 代码本身不能直接实现 JNI 接口，通常的做法是：
- 编写 Swift 代码实现核心逻辑。
- 编写一个 C/C++ 包装层（或使用 Swift 对 C 的互操作性），暴露一个 C 风格的 API。
- 在 Java/Kotlin 代码中声明 native 方法，这些方法的名称遵循 JNI 的命名规则，以便与 C/C++ 包装层中的函数匹配。
- 原生包装层（C/C++）通过 JNI 调用 Swift 暴露的 C 风格 API。
(简化的 JNI 工作原理图，Swift 代码通过 C/C++ 包装层接入)
Swift Core Libraries & Runtime： 除了 Swift 代码本身，编译后的 .so 文件还需要依赖 Swift 的运行时库和标准库。这些库也需要被编译到 Android 目标平台，并随 .so 文件一起打包到 Android 应用中。这会增加应用的包体大小，因为包含了额外的运行时环境。

总结技术路径：

开发者使用特定版本的 Swift Toolchain，将 Swift 源代码编译为 Android 目标架构（ARM64, x86_64等）的原生库 (.so 文件)。为了让 Android 应用（Java/Kotlin）能够调用这些 Swift 函数，需要通过 JNI 构建一座桥梁。通常，Swift 代码通过 C API 暴露功能，然后 C/C++ 代码实现 JNI 接口来调用这些 C API，最终 Java/Kotlin 代码通过 native 方法调用 C/C++ 实现的 JNI 函数。

第三部分：Swift 在 Android 上的用例与适用场景

正如前文所述，Swift 在 Android 上并非“全能选手”，其价值主要体现在特定的用例和场景中：

共享核心业务逻辑库： 这是最常见也是最有价值的用例。例如，一个复杂的金融计算引擎、一个加密解密模块、一个数据同步和冲突解决算法、一个复杂的解析器或格式化器、跨平台的数据模型层和验证逻辑等。这些模块通常不涉及 UI，且对逻辑一致性和性能有较高要求。使用 Swift 编写一套并在 iOS 和 Android 上共享，可以极大地提高开发效率和代码质量。
高性能计算模块： 对于需要进行大量计算的场景，如图像处理滤镜、音频信号处理、机器学习模型的推理（虽然很多库有跨平台支持，但自定义算法可能需要原生实现）、物理模拟等，Swift 的原生性能优势可以得到发挥。
特定领域的库： 某些领域可能已经存在用 Swift 编写的高质量、高性能的库（例如一些低层级的网络库、序列化库等）。如果这些库已经被移植或可以轻松地移植到 Android 平台，那么在 Android 项目中直接使用它们可能比用 Kotlin/Java 重写更高效。
代码库迁移过渡： 对于正在从 iOS 主导转向双平台发展的公司，如果拥有庞大的 Swift 代码库，可以逐步将核心模块在 Android 上启用 Swift 支持，而不是一次性全部重写。
作为原生替代方案： 在某些需要原生性能且 C/C++ 开发门槛较高或团队更熟悉 Swift 的场景下，Swift 可以作为一个相对更现代、更安全的原生语言选项。

不适用或应避免的场景：

Android UI 开发： Swift 不能直接用于编写 Android 的界面（Views 或 Jetpack Compose）。Android 的 UI 框架是基于 Kotlin/Java 的，需要使用相应的语言进行开发。
直接访问 Android Framework API： Swift 代码本身无法直接调用 Android SDK 中的 API（如管理 Activity 生命周期、访问 SharedPreferences、调用相机 API 等）。所有与 Android 系统服务的交互都必须通过 JNI 桥接，并在 Java/Kotlin 代码中实现。构建和维护这些桥接层是复杂的。
构建完整的简单应用： 如果一个应用逻辑简单，完全可以用 Kotlin 或 Java 高效实现，引入 Swift 会显著增加项目的复杂性（构建系统、依赖管理、JNI 桥接），并且会增加应用包体大小，收益远小于成本。
依赖大量的 Java/Kotlin 生态库： 如果你的核心逻辑需要大量依赖现有的 Android 生态中的 Java 或 Kotlin 库（如流行的网络库 OkHttp、JSON 解析库 Gson/Moshi、协程库等），直接在 Swift 中使用它们是不可能的。你需要通过 JNI 将这些库的功能封装在 Java/Kotlin 层，再暴露给 Swift 调用，这会增加巨大的桥接工作量。

第四部分：Swift on Android 入门实践指南

要在 Android 上运行 Swift 代码，你需要进行一系列的设置和配置。整个过程比标准的 Android 或 iOS 开发流程要复杂得多，因为它涉及到了跨工具链、跨语言的集成。以下是一个详细的入门步骤，假设你在一个 Linux 环境下进行（这是最推荐和最成熟的环境，macOS 理论上也可以，但配置更复杂；Windows 需要 WSL）。

准备工作：

操作系统： 推荐使用 Ubuntu 或其他 Linux 发行版。
Android 开发环境：
- 安装 Android Studio。
- 安装 Android SDK。
- 重点： 安装 Android NDK。你可以通过 Android Studio 的 SDK Manager 下载安装特定版本的 NDK。记下 NDK 的安装路径。
Swift Toolchain for Android： 这是最关键的步骤。你需要获取一个专门为 Android 目标平台构建的 Swift Toolchain。
- 访问 Swift-Android 社区或相关项目的 GitHub 页面（例如：https://github.com/swift-android/swift 或类似项目）。
- 按照其指南下载预编译好的 Swift Toolchain for Android（通常是一个 .tar.gz 文件）。确保选择与你的目标 Android 架构（arm64, x86_64）兼容的版本。
- 解压下载的 Toolchain 到一个你指定的目录（例如：/opt/swift-android）。

设置环境变量：

为了让系统能够找到 Swift 编译器和相关工具，你需要配置一些环境变量。在你的 ~/.bashrc 或 ~/.zshrc 文件中添加如下内容（路径根据你的实际安装位置修改）：

“`bash

NDK Path (replace with your NDK path)

export ANDROID_NDK_HOME=/path/to/your/android-sdk/ndk/your_ndk_version
export PATH=$PATH:$ANDROID_NDK_HOME

Swift for Android Toolchain Path (replace with your toolchain path)

export SWIFT_ANDROID_TOOLCHAIN=/opt/swift-android
export PATH=$SWIFT_ANDROID_TOOLCHAIN/usr/bin:$PATH

Set target triple (choose your target architecture)

For 64-bit ARM (most modern devices):

export SWIFT_TARGET=”aarch64-unknown-linux-android”

For 64-bit x86 (emulators/some devices):

export SWIFT_TARGET=”x86_64-unknown-linux-android”

For 32-bit ARM:

export SWIFT_TARGET=”armv7-unknown-linux-androideabi”

For 32-bit x86:

export SWIFT_TARGET=”i686-unknown-linux-android”

Minimum API level (choose your minimum supported Android API level)

export MIN_API_LEVEL=21 # Or higher, e.g., 24, 29 etc.

Set SYSROOT

export SYSROOT=”$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/sysroot”
“`

保存文件后，运行 source ~/.bashrc 或 source ~/.zshrc 使环境变量生效。

验证安装：

打开新的终端窗口，运行以下命令检查 Swift 编译器是否可用并指向正确的 Android 目标：

bash swift --version swift -target $SWIFT_TARGET -print-target-info

你应该能看到 Swift 版本信息，并且目标信息中包含 $SWIFT_TARGET 和相关的 NDK 路径。

创建 Swift 库项目：

我们将创建一个简单的 Swift 库，包含一个函数，然后将其编译为 .so 文件。

创建项目目录：
bash mkdir MySwiftLibrary && cd MySwiftLibrary
创建 Package.swift 文件： 使用 Swift Package Manager (SPM) 来管理和构建。
“`swift
// swift-tools-version:5.7
import PackageDescription

let package = Package(
name: “MySwiftLibrary”,
products: [
// Define the library product that will be built
.library(
name: “MySwiftLibrary”,
type: .dynamic, // We want a dynamic library (.so)
targets: [“MySwiftLibrary”]),
],
dependencies: [
// Add any dependencies here if needed
// .package(url: “…”, from: “…”),
],
targets: [
// Define the library target
.target(
name: “MySwiftLibrary”,
dependencies: []),
.testTarget(
name: “MySwiftLibraryTests”,
dependencies: [“MySwiftLibrary”]),
]
)
“`
创建 Swift 源文件： 在 Sources/MySwiftLibrary/ 目录下创建 MySwiftLibrary.swift 文件。

为了让 Swift 函数能够被 JNI 调用，我们需要通过 C API 暴露它们。Swift 提供了 @_cdecl 属性来实现这个目的。

“`swift
// Sources/MySwiftLibrary/MySwiftLibrary.swift

import Foundation // You might need Foundation or Darwin for basic types

// Example 1: A simple function taking and returning integers
@_cdecl(“add_numbers”) // This is the C symbol name that JNI will look for
public func addNumbers(a: Int32, b: Int32) -> Int32 {
return a + b
}

// Example 2: A function taking and returning strings
// Strings require more care for C interop
// This is a simplified example, production code needs proper memory management
@_cdecl(“greet_from_swift”)
public func greetFromSwift(name_ptr: UnsafePointer?) -> UnsafeMutablePointer? {
guard let name_ptr = name_ptr else {
return strdup(“Hello, stranger from Swift!”) // strdup allocates memory
}
let name = String(cString: name_ptr)
let greeting = “Hello, (name) from Swift!”
// Convert Swift String to C String. Needs memory management!
return strdup(greeting) // Allocate memory for the C string
}

// Note: For the String example, the caller (Java/Kotlin) is responsible
// for freeing the memory returned by strdup to avoid memory leaks.
// JNI interop with strings and complex types is non-trivial.
// You often need helper functions or specific libraries for this.
`` *注意：处理字符串和其他复杂类型在 Swift 和 C/JNI 之间传递时，需要非常小心内存管理（谁分配、谁释放）。上述strdup示例是 C 函数，它在堆上分配内存，调用方必须使用free` 释放。在实际项目中，考虑使用更 robust 的互操作层或库。*
构建 Swift 库： 使用 SPM 和 Swift Toolchain for Android 进行构建。

“`bash

Build for the target architecture defined in env variables

swift build –triple $SWIFT_TARGET -Xswiftc “-sdk” -Xswiftc “$SYSROOT” -Xswiftc “-I$SYSROOT/usr/include” -Xswiftc “-L$SYSROOT/usr/lib”
`` 这个命令会使用 Swift Toolchain，以指定的 Android 目标架构 ($SWIFT_TARGET) 编译你的 Swift 代码，并链接到 Android NDK 的系统根目录 ($SYSROOT`) 提供的库。

构建成功后，你会在 .build/$SWIFT_TARGET/debug 或 .build/$SWIFT_TARGET/release 目录下找到生成的动态库文件，名称类似于 libMySwiftLibrary.so。

集成到 Android 应用：

现在，你需要创建一个 Android Studio 项目，并将生成的 .so 文件集成进去，然后通过 JNI 调用 Swift 函数。

创建 Android Studio 项目： 在 Android Studio 中创建一个新的 Native C++ 项目（或者在现有项目中添加 C++ 支持）。选择 Basic Activity 或 Empty Activity 模板。确保项目配置了 C++ 支持。
复制 Swift .so 文件： 将前面生成的 libMySwiftLibrary.so 文件复制到你的 Android 项目的 app/src/main/jniLibs 目录下。在这个目录下，你需要为不同的架构创建子文件夹，例如 app/src/main/jniLibs/arm64-v8a/ 或 app/src/main/jniLibs/x86_64/，并将对应的 .so 文件放入相应的目录。
加载原生库： 在你的 Android 应用的 Java 或 Kotlin 代码中，加载 Swift 库。通常在 Application 或 Activity 的静态初始化块中：
java // In your Activity or Application class (Java) static { System.loadLibrary("MySwiftLibrary"); // Load the .so library named libMySwiftLibrary.so }
kotlin // In your Activity or Application class (Kotlin) companion object { init { System.loadLibrary("MySwiftLibrary") // Load the .so library named libMySwiftLibrary.so } }
声明 JNI 方法： 在 Java 或 Kotlin 代码中声明 native 方法，这些方法将映射到 C/C++ 包装层。
java // In your Activity (Java) public native int addNumbers(int a, int b); public native String greetFromSwift(String name); // For the string example public native void freeCString(long ptr); // To free the memory returned by greetFromSwift
kotlin // In your Activity (Kotlin) external fun addNumbers(a: Int, b: Int): Int external fun greetFromSwift(name: String?): String? // For the string example external fun freeCString(ptr: Long) // To free the memory returned by greetFromSwift

创建 C/C++ JNI 实现文件： 在你的 Android 项目的 app/src/main/cpp 目录下（或你配置的 JNI 目录）创建一个 C/C++ 源文件（例如 native-lib.cpp）。这个文件将实现前面声明的 native 方法，并通过 C API 调用 Swift 函数。

首先，你需要声明一个头文件来引用 Swift 暴露的 C 函数。你可以手动创建一个简单的头文件 my_swift_library_api.h：
“`c
// app/src/main/cpp/my_swift_library_api.h

ifndef MY_SWIFT_LIBRARY_API_H

define MY_SWIFT_LIBRARY_API_H

include // For int32_t

// Declare the C functions exposed by Swift
int32_t add_numbers(int32_t a, int32_t b);
char greet_from_swift(const char name); // C-style string
// You might need other helper functions declared here if your Swift code provides them

endif // MY_SWIFT_LIBRARY_API_H

`` 然后，在你的 C/C++ 实现文件 (native-lib.cpp`) 中实现 JNI 方法并调用 Swift 函数：

“`c++
// app/src/main/cpp/native-lib.cpp

include

include “my_swift_library_api.h” // Include your Swift C API header

include // For logging

define TAG “SwiftJNI”

define LOGI(…) android_log_print(ANDROID_LOG_INFO, TAG, __VA_ARGS)

// Implementation for addNumbers native method
// JNI function name format: Java_com_yourpackage_YourActivity_methodName
extern “C” JNIEXPORT jint JNICALL
Java_com_yourpackage_YourActivity_addNumbers(
JNIEnv env,
jobject / this */,
jint a,
jint b) {
LOGI(“JNI: Calling Swift add_numbers(%d, %d)”, a, b);
// Call the Swift function exposed via C API
int result = add_numbers(a, b);
LOGI(“JNI: Swift add_numbers returned %d”, result);
return result;
}

// Implementation for greetFromSwift native method
extern “C” JNIEXPORT jstring JNICALL
Java_com_yourpackage_YourActivity_greetFromSwift(
JNIEnv env,
jobject / this */,
jstring name) {
LOGI(“JNI: Calling Swift greet_from_swift”);

// Convert Java String to C String
const char *nameCStr = NULL;
if (name != NULL) {
   nameCStr = env->GetStringUTFChars(name, 0);
}

// Call the Swift function
char* swiftGreetingCStr = greet_from_swift(nameCStr);

// Release the C String obtained from Java
if (name != NULL) {
   env->ReleaseStringUTFChars(name, nameCStr);
}

if (swiftGreetingCStr == NULL) {
    return NULL; // Or return an empty string/handle error
}

// Convert C String returned by Swift to Java String
jstring resultString = env->NewStringUTF(swiftGreetingCStr);

// IMPORTANT: The Swift function (using strdup) allocated memory for swiftGreetingCStr.
// This memory *must* be freed. However, we cannot free it *immediately* here
// because the Java String `resultString` might still be using the underlying C string data
// depending on the JNI implementation details (though typically NewStringUTF copies).
// A safer approach is to return the pointer to the C string and have the Java/Kotlin side
// call a native function specifically designed to free this memory *after* the Java String is no longer needed.

// For demonstration, let's assume NewStringUTF copies and we can free immediately.
// In a real app, use the freeCString JNI method call from Java/Kotlin after getting the string.
// free(swiftGreetingCStr); // Only if you are certain NewStringUTF copies.

// Let's return the address of the allocated memory alongside the string
// or use the freeCString approach described below.
// For this simplified example, assume NewStringUTF copies the content.
// Proper memory management for cross-language strings is crucial!
// The recommended approach is to return the jstring and also expose a JNI function to free the C-string pointer later.

// Let's adapt the return for the required freeing mechanism.
// We will return the Java String and also provide a separate function to free.
// The Java/Kotlin side will need to store the native pointer if they want to free it.
// A better approach for complex data might involve a wrapper struct and managing lifecycle.

// Let's stick to returning the string and demonstrating the freeing function separately.
// The caller must manually call freeCString with the *address* of the C string.
// This requires returning the pointer address as well. JNI has limitations here.

// Revisit the String handling. A common pattern:
// 1. Swift returns a pointer to the C string.
// 2. JNI converts the C string to Java String.
// 3. JNI returns the Java String and *also* the pointer address (e.g., via an object/wrapper or by having the Swift function manage lifetime differently).
// 4. Java/Kotlin uses the string, then calls a native function with the pointer address to free the memory.

// Let's adjust the Swift API and JNI. Swift will return a pointer.
// The JNI function will convert to jstring AND return the pointer address as a long.
// This requires a different JNI signature and return type (e.g., returning a custom Java object).
// Or, simplify for demo: Just return the jstring and rely on a separate free call.

// Simpler approach for demo, but be aware of memory leak potential if NewStringUTF doesn't copy:
// return env->NewStringUTF(swiftGreetingCStr); // If NewStringUTF copies

// *Correct* approach using a separate free function:
// The Swift function `greet_from_swift` returns a `char*`.
// We convert it to jstring.
// We *should* return the jstring AND the memory address (as a long).
// This requires a different JNI function signature or a wrapper object.

// Let's define the separate freeing function first.
// And for greetFromSwift, we'll return the jstring but *know* that the C string memory needs freeing later.

// *** Simplification for Demo: Assume NewStringUTF copies the string content. This is often true, but not guaranteed by JNI spec. ***
// *** For robust production code, manage memory explicitly! ***
jstring result = env->NewStringUTF(swiftGreetingCStr);
// free(swiftGreetingCStr); // Potentially free if NewStringUTF copied

// Let's implement the explicit freeing function:
// extern "C" JNIEXPORT void JNICALL
// Java_com_yourpackage_YourActivity_freeCString(JNIEnv* env, jobject /* this */, jlong ptr) {
//    LOGI("JNI: Freeing C string at address %p", (void*)ptr);
//    free((void*)ptr);
// }

// This means the Java/Kotlin side needs to get the pointer address.
// Let's change the Swift function and JNI signature to return BOTH the string and the pointer.
// Swift: returns a struct/tuple (char*, size_t) or similar.
// JNI: returns a custom Java object { String text, long ptr }.

// This significantly increases complexity.
// For a basic intro, let's stick to the `addNumbers` which is straightforward.
// And acknowledge string handling is complex due to memory management.

// Let's return the jstring and leave the freeing part as a necessary but more advanced topic.
// **BE AWARE OF MEMORY LEAKS IF NewStringUTF DOES NOT COPY THE C STRING CONTENTS.**
jstring resultString = env->NewStringUTF(swiftGreetingCStr);

// In a real scenario, you might return a pointer ID or the raw pointer
// and manage the lifetime from the Java side via another JNI call.
// For this intro, let's make it simpler and just return the string,
// but note the complexity of string memory management.

// Let's return the jstring.
return resultString; // Potential memory leak if `greet_from_swift` uses `strdup` and this isn't freed

}

// Implement the freeing function
extern “C” JNIEXPORT void JNICALL
Java_com_yourpackage_YourActivity_freeCString(JNIEnv env, jobject / this /, jlong ptr) {
LOGI(“JNI: Freeing C string at address %p”, (void)(intptr_t)ptr);
// Cast jlong back to pointer and free
free((void*)(intptr_t)ptr);
}

`` *注意：Java_com_yourpackage_YourActivity_methodName中的com_yourpackage_YourActivity必须替换为你实际的 Java/Kotlin 包名和类名，将点号.替换为下划线_`。上面的 C++ 代码中，字符串处理的内存管理部分进行了简化说明，实际生产环境需要更严谨的内存管理策略。一个常见的模式是在 Swift 侧通过 C 接口提供分配和释放内存的函数，并在 JNI 层调用它们。*

配置 CMakeLists.txt： Android Studio 使用 CMake 来构建原生库。你需要修改 app/src/main/cpp/CMakeLists.txt 文件，告诉它如何编译你的 C/C++ JNI 文件，并链接到你的 Swift 库。

“`cmake

app/src/main/cpp/CMakeLists.txt

cmake_minimum_required(VERSION 3.22) # Use a recent CMake version

project(“MyApp”) # Replace MyApp with your project name

Find the Android NDK and set paths

include(AndroidNDK)

Add the C/C++ source file for JNI implementation

add_library( # Sets the name of the library.
native-lib # This name must match the one used in System.loadLibrary() in Java/Kotlin
SHARED
native-lib.cpp) # Add your JNI source file(s) here

Link to the Swift dynamic library.

IMPORTANT: libMySwiftLibrary.so needs to be copied into jniLibs folders manually

CMake isn’t strictly building the Swift library here, just linking against it symbolically.

The actual .so file must be present in the jniLibs folders at build time.

For the linker, we need to tell it where to find the symbols exposed by Swift.

We can either:

1. Point the linker to the directory where the Swift .so is.

2. Provide a path to the specific .so file.

Option 1: Add the jniLibs directory to the linker search path

(This might require figuring out the correct architecture subdirectory)

link_directories(${PROJECT_SOURCE_DIR}/../jniLibs/${ANDROID_ABI}) # ${ANDROID_ABI} is a CMake variable for the target architecture

Option 2: Provide the full path to the Swift library for the target ABI

This is usually more reliable. Requires you to know the path based on build output.

Replace /path/to/your/swift/build/output/libMySwiftLibrary.so with the actual path.

You might need separate paths based on ${ANDROID_ABI}

Example (replace with your build paths):

set(SWIFT_LIB_DIR “${CMAKE_SOURCE_DIR}/../../MySwiftLibrary/.build/${ANDROID_ABI}/debug”) # Adjust path to your Swift build output

Target Swift library path (assuming it’s in the jniLibs folder for the target ABI)

This path is relative to the CMakeLists.txt file (app/src/main/cpp)

set(SWIFT_LIB_PATH “${CMAKE_SOURCE_DIR}/../jniLibs/${ANDROID_ABI}/libMySwiftLibrary.so”)

Link the native-lib to the Swift library

target_link_libraries( # Specifies the target library for linking purposes.
native-lib
# Link against the Swift standard library and core libraries
# These should be handled by the Swift toolchain itself if configured correctly,
# but sometimes explicit linking is needed. The Swift .so file usually bundles
# necessary parts or expects them to be present.
```
    # Link against the Swift library we built
    ${SWIFT_LIB_PATH}

    # Link against the Android log library for __android_log_print
    android # Link against the Android logging library
    log # Alias for the logging library
```
)

You might need to add include directories if your C/C++ code includes Swift-generated headers

or your own C headers like my_swift_library_api.h

target_include_directories(native-lib PRIVATE
${CMAKE_SOURCE_DIR} # Include the directory containing my_swift_library_api.h
)

Add preprocessor definitions if needed

add_definitions(-D__ANDROID__) # Example

“`

注意：配置 CMake 链接 Swift 库是最复杂的部分之一。你需要确保 CMake 知道在哪里找到 libMySwiftLibrary.so 文件以及 Swift 运行时所需的其他库。上面的 CMake 配置示例假设 libMySwiftLibrary.so 已经存在于 jniLibs/${ANDROID_ABI} 目录中，并且 CMake 只需要链接到它。如果你的 Swift 构建过程产生其他必要的运行时库，可能也需要将它们一同复制到 jniLibs 目录或配置 CMake 链接它们。
在 Java/Kotlin 中调用 Swift 函数： 现在可以在你的 Activity 或其他地方调用你声明的 native 方法了。

“`java
// In your Activity (Java)
// Assuming you have a TextView named resultTextView
TextView resultTextView = findViewById(R.id.resultTextView);

int sum = addNumbers(5, 7);
resultTextView.setText(“Result from Swift: ” + sum);

// For the string example (requires careful memory management!)
// String greeting = greetFromSwift(“World”); // Potential memory leak if not freed
// resultTextView.append(“\nGreeting from Swift: ” + greeting);
// How to get the pointer to free? This needs the JNI return type to include the pointer.
// Example of calling the free function (requires you to have the pointer address as a long)
// long stringPtr = getPointerFromGreetResult(…); // You would need a helper function/object to get this
// freeCString(stringPtr);
kotlin
// In your Activity (Kotlin)
// Assuming you have a TextView named resultTextView
val resultTextView: TextView = findViewById(R.id.resultTextView)

val sum = addNumbers(5, 7)
resultTextView.text = “Result from Swift: $sum”

// For the string example (requires careful memory management!)
// val greeting = greetFromSwift(“World”) // Potential memory leak if not freed
// resultTextView.append(“\nGreeting from Swift: $greeting”)
// How to get the pointer to free? Need to adjust JNI/Swift return type.
// Example of calling the free function (requires you to have the pointer address as a Long)
// val stringPtr: Long = getPointerFromGreetResult(…) // Need a way to get this pointer
// freeCString(stringPtr)
“`
构建和运行： 在 Android Studio 中构建并运行你的应用。如果一切配置正确，应用应该能够加载 Swift 库，并通过 JNI 成功调用 Swift 函数。检查 Logcat 输出，特别是 NDK 的日志，可以帮助调试。

遇到的挑战和注意事项：

Toolchain 版本： Swift Toolchain for Android 仍在积极开发中，选择一个稳定且与你的 NDK 版本兼容的版本很重要。不同的版本可能有不同的构建要求和 Bug。
构建系统集成： 将 Swift 的 SPM 构建与 Android 的 Gradle/CMake 构建集成起来是整个过程中最棘手的部分。你需要一个自动化脚本来构建 Swift 库并将其复制到正确的 jniLibs 目录。手动操作很容易出错。
JNI 复杂性： JNI 本身就是复杂的，特别是处理非基本数据类型（字符串、数组、对象）和内存管理时。你需要深入理解 JNI 的工作原理，并小心处理跨语言的数据转换和资源生命周期。
依赖管理： 在 Swift 侧使用 SPM 管理依赖库，这些库也需要能够编译到 Android 目标。并非所有 Swift 库都支持 Android。
调试： 调试 Swift 代码需要使用支持原生调试的工具，例如 NDK 的 LLDB 调试器，集成到 Android Studio 中进行原生调试。
错误处理： 跨语言边界的错误处理（异常、错误码）需要仔细设计。Swift 的错误传播机制与 Java/Kotlin 不同，需要在 JNI 层进行转换。
社区支持： 相比于 Swift 在 Apple 平台或 Kotlin/Java 在 Android 平台，Swift on Android 的社区相对较小，遇到问题可能需要更多地查阅底层文档或自己探索。

第五部分：挑战、局限性与未来展望

尽管 Swift 在 Android 上提供了代码共享的可能性，但也伴随着显著的挑战和局限性：

工具链和构建系统成熟度： Swift-Android Toolchain 和相关的构建集成工具仍在发展中，不如原生 Android 或 iOS 工具链成熟稳定。配置和维护构建流程可能非常耗时。
生态系统限制： Swift 在 Android 上无法直接利用庞大的 Java/Kotlin 生态系统。所有与 Android 框架、第三方 Java/Kotlin 库的交互都需要通过 JNI 进行桥接，这会增加开发工作量和维护成本。
JNI 桥接开销和复杂性： JNI 调用存在一定的性能开销。更重要的是，为复杂的对象模型和 API 构建高效、安全且易于维护的 JNI 桥接层是一项艰巨的任务。
缺乏官方支持： Swift 在 Android 上的支持主要来自社区贡献，而非 Google 或 Apple 的官方支持。这意味着稳定性和长期维护存在不确定性。
包体大小： 将 Swift 运行时和标准库打包到 Android 应用中会显著增加应用的包体大小，这对于用户下载和安装可能会有影响。
学习曲线： 开发者需要同时理解 Swift、Android 开发、NDK、JNI 以及跨语言构建系统的知识，学习曲线陡峭。

未来展望：

尽管面临挑战，Swift 在 Android 上的探索仍在继续。社区的努力主要集中在以下几个方面：

改进 Toolchain 的稳定性和易用性： 简化安装和配置过程。
增强与 Android 构建系统的集成： 开发更方便的 Gradle 插件或 SPM 集成方案。
改善与 Java/Kotlin 的互操作性： 自动化或简化 JNI 桥接的生成。
提升标准库和核心库在 Android 上的支持： 确保 Foundation、Dispatch 等常用库的稳定运行。

然而，Swift 在 Android 上的定位很可能仍然是一个用于特定场景下的原生共享库方案，而不是构建完整 Android 应用的通用语言。它不太可能取代 Kotlin 成为 Android 开发的首选语言，但为需要在 iOS 和 Android 之间共享高性能、非 UI 核心逻辑的团队提供了一个有吸引力的选择。

结论

Swift 在 Android 平台上的运行并非天方夜谭，而是基于开源 Swift 和 Android NDK/JNI 技术栈实现的。它提供了一种在 iOS 和 Android 之间共享高性能、非 UI 业务逻辑的可能性，对于拥有现有 Swift 代码库或对跨平台原生代码共享有特定需求的团队具有吸引力。

然而，将 Swift 集成到 Android 项目中需要深入了解底层的构建系统、JNI 互操作以及内存管理等复杂性。目前，这并非一个即插即用的解决方案，工具链仍在发展中，并且存在显著的局限性，尤其是在 UI 开发和直接访问 Android Framework API 方面。

对于大多数标准的 Android 应用开发，Kotlin 仍然是现代化、高效且得到官方全面支持的首选语言。只有在明确的、需要共享复杂原生逻辑或极致性能的特定场景下，并且团队有能力投入资源解决跨语言集成的复杂性时，探索和使用 Swift on Android 才是值得考虑的。

希望本文为你提供了关于 Swift 在 Android 上可能性、技术原理和入门实践的全面介绍。如果你对此感兴趣，可以进一步深入研究 Swift-Android 社区项目，尝试搭建环境并构建一个简单的示例，亲身体验其中的挑战与乐趣。

Swift on Android：跨平台探索的新维度 – 深入介绍与入门指南

引言

第一部分：为何探索 Swift 在 Android 上的可能性？

第二部分：Swift 在 Android 上的技术原理

第三部分：Swift 在 Android 上的用例与适用场景

第四部分：Swift on Android 入门实践指南

NDK Path (replace with your NDK path)

Swift for Android Toolchain Path (replace with your toolchain path)

Set target triple (choose your target architecture)

For 64-bit ARM (most modern devices):

For 64-bit x86 (emulators/some devices):

export SWIFT_TARGET=”x86_64-unknown-linux-android”

For 32-bit ARM:

export SWIFT_TARGET=”armv7-unknown-linux-androideabi”

For 32-bit x86:

export SWIFT_TARGET=”i686-unknown-linux-android”

Minimum API level (choose your minimum supported Android API level)

Set SYSROOT

Build for the target architecture defined in env variables

ifndef MY_SWIFT_LIBRARY_API_H

define MY_SWIFT_LIBRARY_API_H

include // For int32_t

endif // MY_SWIFT_LIBRARY_API_H

include

include

include “my_swift_library_api.h” // Include your Swift C API header

include // For logging

define TAG “SwiftJNI”

define LOGI(…) android_log_print(ANDROID_LOG_INFO, TAG, __VA_ARGS)

app/src/main/cpp/CMakeLists.txt

Find the Android NDK and set paths

Add the C/C++ source file for JNI implementation

Link to the Swift dynamic library.

IMPORTANT: libMySwiftLibrary.so needs to be copied into jniLibs folders manually

CMake isn’t strictly building the Swift library here, just linking against it symbolically.

The actual .so file must be present in the jniLibs folders at build time.

For the linker, we need to tell it where to find the symbols exposed by Swift.

We can either:

1. Point the linker to the directory where the Swift .so is.

2. Provide a path to the specific .so file.

Option 1: Add the jniLibs directory to the linker search path

(This might require figuring out the correct architecture subdirectory)

link_directories(${PROJECT_SOURCE_DIR}/../jniLibs/${ANDROID_ABI}) # ${ANDROID_ABI} is a CMake variable for the target architecture

Option 2: Provide the full path to the Swift library for the target ABI

This is usually more reliable. Requires you to know the path based on build output.

Replace /path/to/your/swift/build/output/libMySwiftLibrary.so with the actual path.

You might need separate paths based on ${ANDROID_ABI}

Example (replace with your build paths):

set(SWIFT_LIB_DIR “${CMAKE_SOURCE_DIR}/../../MySwiftLibrary/.build/${ANDROID_ABI}/debug”) # Adjust path to your Swift build output

Target Swift library path (assuming it’s in the jniLibs folder for the target ABI)

This path is relative to the CMakeLists.txt file (app/src/main/cpp)

Link the native-lib to the Swift library

You might need to add include directories if your C/C++ code includes Swift-generated headers

or your own C headers like my_swift_library_api.h

Add preprocessor definitions if needed

add_definitions(-D__ANDROID__) # Example

第五部分：挑战、局限性与未来展望

结论

发表评论 取消回复

add_definitions(-DANDROID) # Example

发表评论取消回复