ARTICLE DETAIL

资讯详情

深耕商务建站与企业官网运营的一线实战洞察。

UTS iOS插件开发实战:从环境搭建到蓝牙BLE封装

UTS iOS插件开发实战:从环境搭建到蓝牙BLE封装 1. 项目缘起为什么要在uni-app里折腾iOS原生插件如果你用uni-app做过跨端开发尤其是涉及到一些需要深度调用iOS原生能力的场景比如蓝牙连接、消息推送、音视频处理或者想用一些App Store里没有的私有API那你大概率会遇到一个瓶颈uni-app官方提供的API不够用了。这时候你可能会听到一个词——UTS插件。我第一次接触UTS是在一个智能硬件的项目里。我们需要在uni-app开发的微信小程序和App端实现一套稳定、低延迟的蓝牙通信协议。小程序端还好uniapp的API基本够用。但一到iOS App这边问题就来了官方的uni.connectBluetoothDevice在连接某些特定芯片的设备时握手成功率低得感人更别提那些复杂的自定义数据分包、校验和重传逻辑了。HBuilderX的控制台里飘红的错误日志和测试同事那边“iOS又连不上了”的反馈成了那段时间的日常。当时摆在我面前的路有几条一是用uni-app的renderjs或wxs去硬写但性能和数据交互是硬伤二是用老办法写一个uni_modules的Native.js插件但这东西对iOS原生开发者的要求不低而且调试起来像在走钢丝三是干脆放弃跨端原生iOS和Android各写一套——这显然违背了用uni-app的初衷。直到团队里的架构师提到了DCloud新推的UTSUni-TypeScript。他说这玩意儿能让你用TypeScript的语法直接调用iOS的Swift/Objective-C和Android的Kotlin/Java。听起来有点像“魔法”将跨端开发的便利性和原生代码的性能、能力结合在了一起。我们的蓝牙难题似乎看到了用一套代码主要是UTS层逻辑解决两端原生适配问题的曙光。这就是我决定深入研究并亲手打造一个UTS iOS插件的开始。简单来说UTS插件就是uni-app生态中用于扩展原生能力的“桥梁”。它不像uni_modules那样只是封装网页组件或纯JS逻辑而是真的能编译成iOS的.framework或Android的.aar让你的TypeScript代码拥有直接操作设备硬件、调用系统私有API的能力。对于那些追求极致性能、或需要实现uni-app官方API尚未覆盖功能的开发者来说UTS几乎是目前的最优解。2. UTS iOS插件开发环境搭建与踩坑实录理论很美好但第一步搭建环境就给了我一个下马威。UTS插件的开发和普通的uni-app项目差别很大它更接近于一个原生库的开发流程。2.1 核心工具链选择Xcode与HBuilderX的版本之痛首先明确开发UTS iOS插件你离不开两个核心工具HBuilderX和Xcode。但它们的版本兼容性是第一个大坑。HBuilderX必须使用3.6.5及以上的Alpha版本。正式版是不支持UTS插件开发和真机调试的。我一开始用了3.5的正式版创建UTS插件项目后根本找不到编译和运行的按钮。切换到Alpha版后插件项目目录下才会出现正确的运行和调试菜单。Xcode推荐使用14.x或15.x的稳定版本。这里有个血泪教训我电脑上之前为了兼容一个老项目装了Xcode 10对应iOS 12 SDK。当我尝试编译UTS插件时控制台报了一个诡异的错误xcode 10 (ios 12) does not contain libstdc6.0.9。这个错误信息极具误导性它让你以为是缺少某个C库。实际上根本原因是Xcode版本太低其内置的编译器和SDK无法兼容UTS插件编译所需的新特性。UTS插件在编译时会依赖较新的Swift Module稳定性和Clang编译器特性老版本Xcode无法满足。解决方案就是老老实实从官网下载安装最新稳定版的Xcode并确保命令行工具xcode-select --install也指向新版本。注意在Mac上可以通过sudo xcode-select -s /Applications/Xcode.app/Contents/Developer来切换当前生效的Xcode路径确保HBuilderX调用的是正确的版本。2.2 项目结构初窥从零创建一个UTS插件在HBuilderX Alpha版中新建项目时选择“UTS插件”模板。生成的项目结构是理解UTS如何工作的关键my-uts-plugin/ ├── uni_modules/ # 插件存放目录 │ └── my-uts-plugin/ # 你的插件目录 │ ├── uts/ │ │ ├── index.uts # UTS层主入口用TypeScript编写跨平台逻辑 │ │ ├── ios/ │ │ │ ├── index.uts # iOS平台特有的UTS实现 │ │ │ └── Swift/ │ │ │ └── MyUtsPlugin.swift # 真正的Swift原生代码 │ │ └── android/ │ │ └── index.uts # Android平台特有的UTS实现 │ ├── package.json # 插件配置文件声明名称、依赖、权限等 │ └── ... (其他资源文件) └── ... (其他项目文件)这个结构清晰地展示了UTS的分层思想顶层index.uts这里写公共的TypeScript接口和逻辑。如果某个功能iOS和Android实现完全一样可以写在这里。平台层ios/index.uts和android/index.uts在这里写平台特定的TypeScript逻辑。更重要的是在这里你可以通过UTSiOS或UTSAndroid命名空间直接调用下一层的原生代码。原生层Swift/或Kotlin/目录这里就是纯正的Swift或Kotlin代码了。你在平台层UTS文件中调用的方法最终会在这里被实现。2.3 第一个“Hello World”插件与调试技巧让我们实现一个最简单的功能在iOS端弹出一个原生Alert对话框。这能帮你打通整个调用链路。第一步在uni_modules/my-uts-plugin/uts/ios/index.uts中编写平台层代码。// uni_modules/my-uts-plugin/uts/ios/index.uts import { UTSiOS } from uts-ios; // 声明一个平台特有的函数 export function showNativeAlert(title: string, message: string): void { // 关键这里调用原生Swift类的方法 UTSiOS.invoke(MyUtsPlugin, showAlertWithTitle:message:, [title, message]); }第二步在uni_modules/my-uts-plugin/uts/ios/Swift/MyUtsPlugin.swift中编写原生Swift代码。// uni_modules/my-uts-plugin/uts/ios/Swift/MyUtsPlugin.swift import Foundation import UIKit objc(MyUtsPlugin) public class MyUtsPlugin: NSObject { // 这个方法必须使用objc暴露且参数类型要与UTS调用匹配 objc public static func showAlertWithTitle(_ title: String, message: String) - Void { // 注意原生代码运行在主线程但UTS调用可能来自JS线程。UI操作必须切回主线程。 DispatchQueue.main.async { let alert UIAlertController(title: title, message: message, preferredStyle: .alert) alert.addAction(UIAlertAction(title: OK, style: .default)) // 获取当前活动的UIViewController是关键难点 if let rootVC UIApplication.shared.keyWindow?.rootViewController { // 处理可能存在的presentedViewController var topVC rootVC while let presentedVC topVC.presentedViewController { topVC presentedVC } topVC.present(alert, animated: true) } } } }第三步在公共入口uni_modules/my-uts-plugin/uts/index.uts中统一暴露接口。// uni_modules/my-uts-plugin/uts/index.uts // 导出公共接口如果各平台实现不同可以在这里做兼容判断 export * from ./ios/index.uts // 如果有android实现也可以在这里导出 // export * from ./android/index.uts第四步在uni-app的Vue页面中调用。template view button clickshowAlert点击弹出原生Alert/button /view /template script // 引入UTS插件 import { showNativeAlert } from /uni_modules/my-uts-plugin/uts/index.uts export default { methods: { showAlert() { // 像调用普通JS函数一样调用 showNativeAlert(UTS提示, 你好这是来自Swift的原生弹窗); } } } /script调试过程中的核心技巧日志输出在Swift代码中使用print(...)或os_log(...)。输出会显示在HBuilderX的“运行”-“运行到iOS设备”的控制台里而不是浏览器的Console。真机调试UTS插件必须运行到真机或模拟器才能测试。选择“运行”-“运行到iOS App基座”。首次运行会编译较久因为它需要将UTS和Swift代码编译成原生框架。错误定位如果插件调用失败HBuilderX控制台通常会给出比较清晰的错误栈指出是UTS编译错误还是Swift运行时错误。仔细阅读错误信息大部分是语法或类型不匹配问题。3. 实战封装一个iOS蓝牙低功耗BLE通信插件回到最初的问题我们如何用UTS封装一个更稳定、功能更强的BLE插件这里分享核心部分的实现思路和代码这比简单的Alert要复杂得多涉及状态管理、回调处理和原生API的深度使用。3.1 设计插件接口从JS到原生的协议映射首先我们要设计一个给Vue页面使用的、友好的JavaScript API。我们希望它是这样的// 在Vue组件中理想的使用方式 import { BLEManager } from /uni_modules/my-ble-plugin const ble new BLEManager(); ble.onDeviceFound(device console.log(发现设备:, device)); ble.onConnected(() console.log(连接成功)); ble.onDataReceived(data console.log(收到数据:, data)); ble.startScan([FFE0, FFE1]); // 扫描指定服务的设备 ble.connectToDevice(deviceId); ble.writeDataToCharacteristic(serviceUUID, charUUID, dataArray);为了实现这个我们需要在UTS层定义好类型和接口。在uts/index.uts中定义公共类型和接口// uni_modules/my-ble-plugin/uts/index.uts // 定义设备信息结构 export interface BLEDevice { deviceId: string; name: string; rssi: number; advertisementData?: Recordstring, any; } // 定义特征值信息结构 export interface BLECharacteristic { serviceUUID: string; characteristicUUID: string; properties: string[]; // e.g., [read, write, notify] } // 定义插件主类 export class BLEManager { private static instance: BLEManager; private constructor() {} static getInstance(): BLEManager { if (!BLEManager.instance) { BLEManager.instance new BLEManager(); } return BLEManager.instance; } // 平台特定的实现会在ios/index.uts中 public startScan(serviceUUIDs?: string[]): void { /* 由平台实现 */ } public stopScan(): void { /* 由平台实现 */ } public connect(deviceId: string): void { /* 由平台实现 */ } public disconnect(): void { /* 由平台实现 */ } public write(serviceUUID: string, characteristicUUID: string, data: ArrayBuffer): Promiseboolean { /* 由平台实现 */ } // 事件回调 public onDeviceFound(callback: (device: BLEDevice) void): void { /* 由平台实现 */ } public onConnected(callback: () void): void { /* 由平台实现 */ } // ... 其他事件 }3.2 iOS平台层实现桥接Swift核心逻辑接下来在iOS平台层我们需要实现上述接口并调用Swift代码。这里的关键是处理异步回调。iOS的CoreBluetooth框架是高度异步的我们需要把CBCentralManager的回调Delegate转换成UTS/JS能理解的Promise或Callback。在uts/ios/index.uts中实现平台层// uni_modules/my-ble-plugin/uts/ios/index.uts import { UTSiOS } from uts-ios; import { BLEDevice, BLEManager } from ../index.uts; // 单例模式实现 class BLEManageriOS extends BLEManager { private deviceFoundCallback: ((device: BLEDevice) void) | null null; private connectedCallback: (() void) | null null; // ... 其他回调存储 constructor() { super(); // 初始化原生管理器 UTSiOS.invoke(MyBLEManager, shared); } public startScan(serviceUUIDs?: string[]): void { const args serviceUUIDs ? [serviceUUIDs] : []; UTSiOS.invoke(MyBLEManager, startScanWithServiceUUIDs:, args); } public stopScan(): void { UTSiOS.invoke(MyBLEManager, stopScan); } public connect(deviceId: string): void { UTSiOS.invoke(MyBLEManager, connectToDevice:, [deviceId]); } // 关键注册回调函数给原生层调用 public onDeviceFound(callback: (device: BLEDevice) void): void { this.deviceFoundCallback callback; // 告诉原生层当发现设备时调用一个名为 _onDeviceFoundFromNative 的全局函数 UTSiOS.invoke(MyBLEManager, setDeviceFoundHandler, []); } // 这个函数将被Swift代码直接调用通过UTS的机制 public _onDeviceFoundFromNative(deviceInfo: any): void { if (this.deviceFoundCallback) { const device: BLEDevice { deviceId: deviceInfo.identifier, name: deviceInfo.name || Unknown, rssi: deviceInfo.rssi }; this.deviceFoundCallback(device); } } // ... 实现其他方法 } // 导出平台特定的单例 export const bleManager: BLEManager new BLEManageriOS();3.3 Swift原生层核心封装CoreBluetooth这是最核心的部分我们需要用Swift完整地封装CBCentralManager。在uts/ios/Swift/MyBLEManager.swift中// uni_modules/my-ble-plugin/uts/ios/Swift/MyBLEManager.swift import CoreBluetooth import Foundation // 定义一个协议用于将Swift事件传递回UTS/JS层 objc protocol MyBLEManagerJSExport { func _onDeviceFoundFromNative(deviceInfo: [String: Any]) func _onConnectedFromNative() func _onDisconnectedFromNative() func _onDataReceivedFromNative(data: [UInt8], serviceUUID: String, charUUID: String) } objc(MyBLEManager) public class MyBLEManager: NSObject { objc public static let shared MyBLEManager() private var centralManager: CBCentralManager! private var connectedPeripheral: CBPeripheral? private var discoveredPeripherals: [UUID: CBPeripheral] [:] // 持有对JS导出对象的弱引用UTS运行时提供 private weak var jsHandler: MyBLEManagerJSExport? private override init() { super.init() // 在后台队列运行避免阻塞主线程 let centralQueue DispatchQueue(label: com.myapp.ble.central) centralManager CBCentralManager(delegate: self, queue: centralQueue) } // MARK: - Public Methods called from UTS objc public func startScanWithServiceUUIDs(_ serviceUUIDStrings: [String]?) { guard centralManager.state .poweredOn else { print(蓝牙未开启) return } var serviceUUIDs: [CBUUID]? if let strings serviceUUIDStrings { serviceUUIDs strings.map { CBUUID(string: $0) } } // 允许重复发现用于RSSI更新 centralManager.scanForPeripherals(withServices: serviceUUIDs, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) } objc public func stopScan() { centralManager.stopScan() } objc public func connectToDevice(_ deviceId: String) { guard let uuid UUID(uuidString: deviceId), let peripheral discoveredPeripherals[uuid] else { print(未找到设备: \(deviceId)) return } centralManager.connect(peripheral, options: nil) } // 设置回调处理器 objc public func setDeviceFoundHandler() { // 这里UTS运行时会自动将实现了MyBLEManagerJSExport协议的对象传递进来 // 我们通过一个内部方法获取它具体机制由UTS桥接层处理这里简化表示 self.jsHandler getJSHandler() // 假设的获取方法 } // MARK: - 将事件传递回JS private func notifyDeviceFound(peripheral: CBPeripheral, rssi: NSNumber, advertisementData: [String: Any]) { let deviceInfo: [String: Any] [ identifier: peripheral.identifier.uuidString, name: peripheral.name ?? advertisementData[CBAdvertisementDataLocalNameKey] as? String ?? , rssi: rssi.intValue, advertisementData: advertisementData ] // 切换到主线程调用JS方法 DispatchQueue.main.async { self.jsHandler?._onDeviceFoundFromNative(deviceInfo: deviceInfo) } } private func notifyConnected() { DispatchQueue.main.async { self.jsHandler?._onConnectedFromNative() } } } // MARK: - CBCentralManagerDelegate extension MyBLEManager: CBCentralManagerDelegate { public func centralManagerDidUpdateState(_ central: CBCentralManager) { print(蓝牙状态更新: \(central.state.rawValue)) } public func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { discoveredPeripherals[peripheral.identifier] peripheral notifyDeviceFound(peripheral: peripheral, rssi: RSSI, advertisementData: advertisementData) } public func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) { connectedPeripheral peripheral peripheral.delegate self // 设置Peripheral委托 peripheral.discoverServices(nil) // 发现所有服务 notifyConnected() } // ... 实现其他CBCentralManagerDelegate方法 } // MARK: - CBPeripheralDelegate extension MyBLEManager: CBPeripheralDelegate { public func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) { guard let services peripheral.services else { return } for service in services { peripheral.discoverCharacteristics(nil, for: service) } } public func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) { // 处理发现的特征值例如订阅通知等 guard let characteristics service.characteristics else { return } for characteristic in characteristics { if characteristic.properties.contains(.notify) { peripheral.setNotifyValue(true, for: characteristic) } } } public func peripheral(_ peripheral: CBPeripheral, didUpdateValueFor characteristic: CBCharacteristic, error: Error?) { // 收到数据来自读操作或通知 if let data characteristic.value { let byteArray [UInt8](data) // 通知JS层 DispatchQueue.main.async { self.jsHandler?._onDataReceivedFromNative(data: byteArray, serviceUUID: characteristic.service?.uuid.uuidString ?? , charUUID: characteristic.uuid.uuidString) } } } // ... 实现其他CBPeripheralDelegate方法如写入回调、断开连接等 }这个Swift类做了几件关键事单例管理确保只有一个CBCentralManager实例。状态与队列管理在自定义队列处理蓝牙事件不阻塞UI。桥接回调通过一个假设的jsHandler实际由UTS运行时注入将原生事件发现设备、连接成功、收到数据传递回UTS/JS层。完整的BLE生命周期实现了扫描、连接、发现服务/特征、订阅通知、接收数据等核心流程。3.4 在uni-app页面中集成与使用最后在Vue页面中你就可以像使用一个纯JavaScript库一样使用这个功能强大的BLE插件了template view classcontent button clickstartScanning开始扫描蓝牙设备/button view v-fordevice in devices :keydevice.deviceId clickconnectDevice(device) text{{ device.name }} ({{ device.deviceId }}) - RSSI: {{ device.rssi }}/text /view button clicksendData :disabled!isConnected发送测试数据/button /view /template script import { bleManager } from /uni_modules/my-ble-plugin/uts/index.uts export default { data() { return { devices: [], isConnected: false, connectedDeviceId: null } }, onLoad() { this.setupBLEListeners(); }, methods: { setupBLEListeners() { bleManager.onDeviceFound((device) { console.log(发现设备:, device); // 去重 if (!this.devices.find(d d.deviceId device.deviceId)) { this.devices.push(device); } }); bleManager.onConnected(() { console.log(蓝牙连接成功); this.isConnected true; uni.showToast({ title: 连接成功 }); }); bleManager.onDataReceived((data, serviceUUID, charUUID) { console.log(从[${serviceUUID}][${charUUID}]收到数据:, data); // 处理数据... }); }, startScanning() { this.devices []; // 只扫描包含特定服务例如0xFFE0的设备 bleManager.startScan([FFE0]); }, connectDevice(device) { this.connectedDeviceId device.deviceId; bleManager.connect(device.deviceId); }, async sendData() { const testData new Uint8Array([0x01, 0x02, 0x03, 0x04]); const success await bleManager.write(FFE0, FFE1, testData.buffer); if (success) { uni.showToast({ title: 发送成功 }); } } } } /script通过这样的封装我们成功将一个复杂的、平台相关的iOS CoreBluetooth功能转化成了一个简洁、易用、类型安全的JavaScript API并且在uni-app的Vue组件中可以无缝调用。这解决了文章开头提到的官方API能力不足、连接不稳定的问题。4. UTS插件开发中的进阶技巧与避坑指南走通了整个流程后你会发现UTS插件开发虽然强大但细节处陷阱不少。下面分享一些我积累下来的进阶技巧和常见问题的解决方案。4.1 数据类型映射UTS与Swift/Obj-C的“翻译官”这是最容易出错的地方。UTSTypeScript中的数据类型需要精确映射到Swift/Objective-C。基本类型string-Stringnumber-Double(默认) 或Int/Float(需在Swift端明确指定类型UTS调用时需匹配)boolean-BoolArray-Array(元素类型需一致)Recordstring, any/object-DictionaryString, Any/NSDictionary特殊类型ArrayBuffer/Uint8Array 这是处理二进制数据的关键。在Swift中通常对应Data或[UInt8]。UTS传ArrayBuffer到 Swift在Swift方法参数中声明为Data类型。UTS桥接层会自动转换。Swift 返回Data给 UTS在UTS中会收到一个ArrayBuffer。// Swift objc func processData(_ data: Data) - Data { var bytes [UInt8](data) // ... 处理bytes return Data(bytes) }// UTS let inputBuffer new ArrayBuffer(4); let outputBuffer: ArrayBuffer UTSiOS.invoke(MyClass, processData:, [inputBuffer]);回调函数CallbackUTS不能直接将一个JS函数对象传到Swift。标准的做法是在UTS层定义一个事件处理器如我们前面BLE例子中的_onDeviceFoundFromNative。在Swift端通过UTS运行时提供的机制通常是UTSiOS.invoke的某种变体或特定API来调用这个UTS层的方法。在上面的例子中我们简化了jsHandler的获取实际开发中需要查阅UTS的官方文档了解如何正确设置和使用UTSiOS的交互API来注册和触发回调。4.2 内存管理与循环引用在Swift和UTS/JavaScript交互时要特别注意内存管理避免循环引用导致内存泄漏。Swift中持有JS回调如果Swift类强引用了一个来自JS的对象或回调而这个JS对象又间接引用了Swift实例就会形成循环引用。解决方案是使用弱引用weak。class MyPlugin { // 错误强引用可能导致循环引用 // var jsCallback: SomeJSType? // 正确弱引用 weak var jsDelegate: MyPluginJSDelegate? }在我们的BLE例子中jsHandler就被声明为weak。UTS中的对象生命周期UTS对象在JavaScript环境中被垃圾回收。只要Swift端没有不必要的强引用当Vue组件销毁或页面关闭时对应的UTS插件实例和Swift实例都应该能被正确释放。4.3 线程安全UI操作必须回主线程这是一个非常经典的iOS开发陷阱在UTS插件中同样存在。所有涉及更新用户界面的操作如显示Alert、更新UI控件状态必须在主线程Main Thread上执行。CoreBluetooth等后台线程回调如centralManager(_:didDiscover:advertisementData:rssi:)是在初始化CBCentralManager时指定的队列我们用了后台队列上调用的。切换到主线程在需要更新UI或调用会触发UI更新的JS回调时务必使用DispatchQueue.main.async。public func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { // 这个回调在后台队列 DispatchQueue.main.async { // 切换到主线程 self.jsHandler?.onDeviceFound(deviceInfo: ...) // 安全调用JS回调 } }忘记切线程会导致UI无响应、崩溃或不可预知的行为。4.4 插件调试与问题排查调试UTS插件比调试普通uni-app页面复杂因为涉及原生代码编译。编译错误首先检查HBuilderX控制台的编译输出。UTS语法错误、Swift语法错误、类型不匹配都会在这里显示。错误信息通常比较直接按提示修改即可。运行时崩溃如果App在调用插件时崩溃首先连接真机或模拟器在Xcode中运行项目HBuilderX运行到iOS基座后可以在Xcode的“Devices and Simulators”窗口中找到对应进程点击底部调试按钮。这样可以在Xcode中看到原生层的崩溃堆栈精准定位到是Swift代码的哪一行出了问题。常见原因有强制解包可选值!、数组越界、线程冲突、回调参数类型错误。日志输出在Swift代码中大量使用print或os_log。这些日志会输出到HBuilderX的运行控制台选择对应的iOS设备日志标签页或Xcode的控制台。真机调试限制某些系统API如部分蓝牙后台模式、推送通知在模拟器上行为可能与真机不同甚至不可用。关键功能务必在真机上测试。4.5 插件发布与集成开发完成后你需要将插件提供给其他项目使用或者上传到插件市场。本地集成直接将整个uni_modules/my-uts-plugin目录复制到目标uni-app项目的uni_modules目录下即可。在项目的pages.json或需要使用的页面中无需像组件一样注册直接import使用。发布到插件市场完善package.json中的name,version,description,keywords等信息。编写详细的README.md文档说明功能、安装方式、API、示例。在HBuilderX中右键插件目录选择“发布到插件市场”。版本管理UTS插件遵循uni_modules的版本规范。在package.json中定义好版本号更新时注意兼容性。开发UTS iOS插件本质上是在用TypeScript作为“粘合剂”将uni-app的跨端便利性与iOS原生的强大能力结合。这个过程需要你同时理解JavaScript/TypeScript和Swift/Objective-C两套生态对开发者的综合能力要求较高。但一旦打通你将能突破uni-app的能力边界实现那些“官方做不到”的复杂功能在跨端开发中游刃有余。从解决一个具体的蓝牙连接问题出发到掌握一整套原生插件开发方法论这种投资对于深耕uni-app生态的开发者来说无疑是极具价值的。
返回列表
PREV
查看更多资讯
NEXT
返回资讯列表