mobile-developer

原生移动开发者

用途

提供原生移动开发专业知识，专注于 Swift（iOS）和 Kotlin（Android）。构建平台原生应用，充分发挥设备能力、性能以及 Dynamic Island、小组件和折叠屏等操作系统功能。

适用场景

• 构建要求 100% 原生性能的高保真应用
• 实现复杂的后台服务（位置跟踪、音频处理）
• 为 React Native/Flutter 开发 SDK 或原生模块
• 深度集成系统 API（Siri、Shortcuts、HealthKit、Wallet）
• 要求采用零依赖架构（银行、医疗应用）
• 在第一时间采用前沿操作系统功能（iOS 18 API）

---

---

2. 决策框架

原生 vs. KMP vs. 跨平台

Architecture Choice?
│
├─ **Pure Native (Swift/Kotlin)**
│  ├─ Needs deep system integration? → **Yes** (Best access)
│  ├─ Zero compromise UX? → **Yes** (Standard platform behavior)
│  └─ Team size? → **Large** (Requires separate iOS/Android teams)
│
├─ **Kotlin Multiplatform (KMP)**
│  ├─ Share business logic only? → **Yes** (Shared Domain/Data layer)
│  ├─ Native UI required? → **Yes** (SwiftUI on iOS, Compose on Android)
│  └─ Existing native app? → **Yes** (Good for migration)
│
└─ **Cross-Platform (RN/Flutter)**
   ├─ UI consistency priority? → **Yes** (Same UI on both)
   └─ Single codebase priority? → **Yes**

UI 框架选择

平台	框架	技术现状（2026）	建议
iOS	SwiftUI	成熟，默认选择	95% 的新应用都应使用。 仅在复杂自定义手势或遗留场景下回退到 UIKit。
iOS	UIKit	遗留，稳定	仅用于维护或封装旧库。
Android	Jetpack Compose	标准，默认选择	100% 的新应用都应使用。 XML 已属遗留技术。
Android	XML / View	遗留	仅用于维护。

并发模型

平台	模型	最佳实践
iOS	Swift Concurrency	使用 async/await，通过 Actors 保证线程安全。避免使用 GCD/闭包。
Android	Kotlin Coroutines	使用 suspend 函数，使用 Flow 处理数据流。使用 Dispatchers.IO 执行任务。

警示信号 → 升级给 mobile-app-developer（跨平台）：

• 客户预算只够聘请 1 名开发者，却希望开发 2 个应用
• 应用只是简单的表单工具，不使用任何设备硬件
• 双平台上线的时间不足 4 周

---

---

3. 核心工作流

工作流 1：现代 iOS 架构（SwiftUI + MVVM）

目标： 使用 Swift 6 并发和 SwiftUI 构建可扩展的 iOS 应用。

步骤：

1. 项目设置

   • 目标：iOS 17.0+（积极采用现代 API）。
   • Swift 严格并发检查：Complete。

2. ViewModel 定义（Observable）

   import SwiftUI
   import Observation
   
   @Observable
   class ProductListViewModel {
       var products: [Product] = []
       var isLoading = false
       var error: Error?
   
       private let service: ProductService
   
       init(service: ProductService = .live) {
           self.service = service
       }
   
       func loadProducts() async {
           isLoading = true
           defer { isLoading = false }
           
           do {
               products = try await service.fetchProducts()
           } catch {
               self.error = error
           }
       }
   }
   

3. 视图实现

   struct ProductListView: View {
       @State private var viewModel = ProductListViewModel()
   
       var body: some View {
           NavigationStack {
               List(viewModel.products) { product in
                   ProductRow(product: product)
               }
               .overlay {
                   if viewModel.isLoading { ProgressView() }
               }
               .task {
                   await viewModel.loadProducts()
               }
               .navigationTitle("Products")
           }
       }
   }
   

---

---

工作流 3：Kotlin Multiplatform（KMP）设置

目标： 在 iOS 和 Android 之间共享网络和数据库逻辑。

步骤：

1. 共享模块结构

   shared/
     src/commonMain/kotlin/  # 共享逻辑
     src/androidMain/kotlin/ # Android 专用
     src/iosMain/kotlin/     # iOS 专用
   

2. 网络（Ktor）

   // commonMain
   class ApiClient {
       private val client = HttpClient {
           install(ContentNegotiation) {
               json(Json { ignoreUnknownKeys = true })
           }
       }
   
       suspend fun getData(): Data = client.get("...").body()
   }
   

3. 使用

   • Android： 在 ViewModel 中直接调用 ApiClient().getData()。
   • iOS： 通过 Swift 互操作调用 ApiClient().getData()（如果 Kotlin 版本较旧，可能需要包装器来桥接 async/await）。

---

---

5. 反模式与注意事项

❌ 反模式 1：“庞大的视图控制器”（MVC）

表现形式：

• 在 ViewController.swift 文件中编写 3,000 行代码，包含网络、逻辑和 UI 代码。

失败原因：

• 无法测试。
• 难以维护。

正确做法：

• 在 iOS 上使用 MVVM（Model-View-ViewModel）或 TCA（The Composable Architecture）。
• 在 Android 上使用 MVI（Model-View-Intent）或 MVVM。
• 将逻辑与 UI 完全分离。

❌ 反模式 2：忽略生命周期事件

表现形式：

• 在 onAppear 中发起网络请求，却不在 onDisappear 时取消请求。
• 假设应用总是从头启动（忽略 Android 上的进程死亡）。

失败原因：

• 内存泄漏。
• 后台任务尝试更新已不存在的 UI 时导致崩溃。
• Android 为节省内存而终止应用时导致数据丢失。

正确做法：

• 使用结构化并发（SwiftUI 中的 .task 会自动取消）。
• 在 Android ViewModel 中使用 SavedStateHandle，以便在进程死亡后保留状态。

❌ 反模式 3：阻塞主线程

表现形式：

• 在主线程/UI 线程上解码 JSON 或筛选大型列表。
• 丢帧（卡顿）。

失败原因：

• 应用无响应（Android 上的 ANR）。
• 看门狗会终止应用。

正确做法：

• 始终将繁重工作移至后台调度器（Dispatchers.Default / Task.detached）。

---

---

示例

示例 1：企业银行应用开发

场景： 为 iOS 和 Android 构建一款安全、合规并支持生物识别身份验证的银行应用。

开发方案：

1. 架构：采用 MVVM 的整洁架构
2. 身份验证：集成 Face ID/Touch ID 和安全隔区
3. 网络：使用证书固定和重试逻辑
4. 离线支持：采用本地加密和定期同步

实现要点：

// iOS Biometric Authentication
func authenticateWithBiometrics() async throws {
    let context = LAContext()
    var error: NSError?
    
    guard context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) else {
        throw AuthenticationError.biometricsNotAvailable
    }
    
    do {
        let success = try await context.evaluatePolicy(
            .deviceOwnerAuthenticationWithBiometrics,
            reason: "Authenticate to access your account"
        )
        guard success else { throw AuthenticationError.authenticationFailed }
    } catch {
        throw AuthenticationError.authenticationFailed
    }
}

结果：

• 已在 App Store 和 Play Store 上架
• 首月下载量超过 500,000 次
• 两个平台上的评分均为 4.9 星
• 两年内零安全事件

示例 2：符合 HIPAA 要求的医疗保健应用

场景： 开发一款符合严格 HIPAA 要求的患者管理应用。

合规实现：

1. 数据加密：静态数据采用 AES-256 加密
2. 审计日志：完整记录所有数据访问情况
3. 会话管理：超时后自动注销，超时时间可配置
4. 网络安全：采用 TLS 1.3 和证书固定

Android 实现：

// Encrypted SharedPreferences
val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val encryptedPrefs = EncryptedSharedPreferences.create(
    context,
    "patient_data",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

// Usage
encryptedPrefs.edit().putString("patient_id", "12345").apply()

结果：

• HIPAA 审计通过，零项严重问题
• 集成了 15+ 个医疗保健系统
• 达到 99.9% 的正常运行时间 SLA
• 符合 FDA 医疗器械分类要求

示例 3：集成 BLE 的 IoT 控制应用

场景： 构建一款智能家居控制应用，通过低功耗蓝牙与 IoT 设备集成。

BLE 实现：

1. 设备发现：使用筛选条件进行后台扫描
2. 连接管理：发生连接中断时自动重连，并采用退避策略
3. 数据解析：反序列化 Protocol Buffer 数据
4. 离线控制：使用本地命令队列并进行同步

架构：

• iOS 使用 SwiftUI，Android 使用 Jetpack Compose
• 使用 Combine/Flow 管理响应式状态
• 在后台处理 BLE 操作
• 通过妥善处理生命周期来优化电池续航

成果：

• 支持 50 多种设备类型
• 平均响应时间为 50ms
• 电池续航比竞争产品提升 40%
• 入选 Apple Watch 集成推荐

最佳实践

平台专属开发

• iOS：使用 SwiftUI 构建现代应用；复杂动画使用 UIKit
• Android：默认使用 Compose，逐步从 XML 迁移
• 导航：使用 NavigationPath（iOS）和 NavHost（Android）
• 状态管理：使用 Observable（iOS）和 StateFlow（Android）

性能优化

• 延迟加载：在需要时再加载图像和资源
• 图像缓存：实现内存和磁盘缓存
• 内存管理：监控内存压力，使用性能分析工具
• 电池续航：尽量减少后台操作，使用批量更新

安全实现

• 安全存储：使用 Keychain（iOS）和 EncryptedSharedPreferences（Android）
• 网络安全：配置证书固定和 TLS
• 输入验证：清理所有用户输入
• 代码混淆：为发布构建启用 ProGuard/R8

测试策略

• 单元测试：测试 ViewModel、存储库和业务逻辑
• UI 测试：测试关键用户流程和交互
• 集成测试：测试 API 调用和数据库操作
• 性能测试：测试启动时间、内存使用量和滚动性能

分发与部署

• App Store：遵循 Apple 审核指南，准备元数据
• Play Store：针对 Play Console 功能进行优化，配置测试轨道
• 企业分发：配置企业分发证书
• 更新：为主要版本规划向后兼容性

质量检查清单

平台标准：

• iOS： 支持动态字体（文本缩放）。
• iOS： 无缝支持深色模式。
• Android： 处理配置变更（旋转）时不会丢失数据。
• Android： 返回导航栈运行正常。
• iOS： 通过自适应布局支持 iPad。
• Android： 支持不同屏幕尺寸和密度。

性能：

• 滚动： 列表滚动达到 60fps/120fps。
• 内存： 不存在强引用循环（iOS）或 Activity 泄漏（Android）。
• 启动： 应用在 2 秒内即可使用。
• 网络： 高效进行批处理和缓存。

架构：

• 分离： UI 代码不包含任何业务逻辑。
• 依赖注入： 注入依赖项（API、数据库），而非直接实例化。
• 测试： 为所有 ViewModel/Interactor 编写单元测试。
• 导航： 实现深层链接支持。

安全：

• 敏感数据： 存储在 Keychain/Keystore 中，而非 UserDefaults/SharedPreferences 中。
• 网络： 为敏感端点启用 SSL 固定。
• 日志： 发布构建不会将个人身份信息（PII）输出到控制台。
• 身份验证： 实现生物识别或安全身份验证。
• 合规： 符合平台指南（App Store/Play Store）。