企业官网建设流程全解析

1. 项目起点：为什么在开源鸿蒙上用Flutter做视力保护应用

先说结论：这个项目本质上是把开源鸿蒙（OpenHarmony）生态、Flutter跨平台框架、健康类垂直场景三者揉在一起的一次工程实践。视力保护应用这个细分方向，看起来不算硬核，但真正落地时会遇到大量贴近系统底层的兼容性、传感器调用、进程保活和UI性能问题，尤其是当你把目标平台从手机扩展到平板、电视甚至开源鸿蒙PC版时，坑位会成倍增加。

先说开源鸿蒙这边的现状。OpenHarmony虽然生态在快速成熟，但相比Android和iOS，第三方SDK、原生插件、社区组件的数量依然有限。如果你直接使用ArkUI加ArkTS做原生开发，体验是好的，但代码复用几乎为零——后续如果还想上Android、iOS甚至Web端，等于要重新维护一套代码。而Flutter的跨平台能力刚好可以补齐这个痛点：同一套Dart代码，理论上可以跑在开源鸿蒙、Android、iOS、Web和桌面端。这正是这个项目最核心的选型逻辑：用Flutter建立视力保护应用的跨平台基座，用开源鸿蒙作为首个落地的目标系统。

至于为什么选“视力保护”这个垂直场景，原因也不难理解。这类应用的核心功能非常典型：检测用户与屏幕的距离、检测环境光、定时提醒休息、做眼保健操引导、调节屏幕色温等。每种功能都会涉及传感器、摄像头、多媒体和通知机制，几乎把全栈能力都过了一遍，非常适合作为跨平台方案的验证场景。另外，视力保护应用在国内有很强的现实需求，无论是学生上网课还是上班族盯显示器，都存在高频刚需。这也是我决定选这个方向做完整开发文档的原因——技术上能打，场景上有人用。

接下来我会把整个开发过程拆成几个部分，从环境搭建到核心功能实现，再到性能优化和常见问题排查，尽量把每一步的为什么和怎么做都讲清楚。这个项目我实际跑下来的时间是大概三周，从零开始搭框架到最后跑通OpenHarmony真机，中间踩了不少坑，文章中会全部写出来。

2. 技术选型与整体架构：跨平台方案的核心考量

2.1 Flutter在开源鸿蒙上的现状与适配层原理

在选型之前，我先花了两天时间调研OpenHarmony上Flutter的运行方案。当前主流的做法是使用社区维护的flutter_flutter（OpenHarmony适配分支）加flutter_engine和flutter_ohos两个关键包。其中flutter_ohos属于适配层的核心形态，类似于Flutter在桌面平台上使用的embedder，它负责实现Flutter引擎与OpenHarmony系统之间的桥接。

说通俗一点，Flutter引擎本身是跨平台的，但每个平台都需要一个“壳”来启动它——在Android上这个壳是FlutterActivity，在iOS上是FlutterViewController，在开源鸿蒙上，flutter_ohos就是那个壳。如果你是自己从零接入而不是使用模板工程，需要重点确认适配层版本与Flutter引擎版本的对应关系，拿错版本会导致引擎无法初始化，而且这类报错通常不会给出明确提示，排查起来非常痛苦。

我的建议是不要一上来就追最新版本，优先选择已经有不少人验证过的稳定组合。以我实际用的配置为例：OpenHarmony 4.0 Release SDK，Flutter适配分支版本3.7.12，Dart版本2.19.6，API版本9。这套组合的好处是社区讨论量大、踩坑资料多，而且官方开发文档中有专门说明。等你把业务代码跑通之后，再考虑往3.10以上版本或API 11升级都来得及。

2.2 整体架构设计：分层是避免后期被坑的关键

跨平台开发最忌讳的是一上来就写业务代码，尤其是这种涉及系统能力调用的健康类应用。如果不在前期做好架构分层，后期加功能和修Bug时，你会发现自己陷入“改一处崩两处”的泥潭。

我把整个应用分成四层：

• UI层：负责页面渲染和交互，全部使用Flutter Widget架构搭建，理论上可以做主题适配。
• 业务逻辑层：负责视力保护的规则引擎、提醒策略、行为数据存储，也全部用Dart实现，与平台无关。
• 服务层：通过统一的抽象接口定义设备能力（如摄像头、传感器、通知、系统设置），每个接口有平台侧的实现。
• 平台适配层：在OpenHarmony侧用ArkTS或C++实现Player、Camera、Sensor、Notification等系统能力，通过MethodChannel与Dart层通信。

这套分层最大的收益在于：我把所有系统相关的代码都收拢到了服务层和平台适配层，UI和业务逻辑完全不知道底层跑的是OpenHarmony还是Android。后续如果真的要出Android版本，我只需要为Service接口新写一套Android实现，UI层几乎不用动。这个方法在《Clean Architecture》那套理论里叫依赖倒置，实际开发中很多人觉得抽象麻烦，但等你被一台新设备的Camera适配折磨几天后，会发现当初半小时写完的接口抽象是最值的半小时。

2.3 MethodChannel通信设计：哪些能力走通道，哪些能力留在引擎

MethodChannel是Flutter与原生平台通信的标准方式，但在实际项目中，通道设计有讲究。一个常见错误是只建一个全局通道，所有方法都通过一个通道走——初期很爽，后期接口膨胀后，代码里全是switch-case字符串判断，维护成本极高。

我是按业务能力域拆分了三个通道：

• vision_sensor：用于距离传感器、环境光传感器的请求监听。
• vision_camera：用于摄像头权限、帧流获取、眨眼检测回调。
• vision_notification：用于本地通知调度、定时提醒、应用内提示音播放。

每个通道内部统一使用请求码（action）加参数（payload）的方式传递。比如调用距离传感器时，Dart层发出请求码“startDistanceMonitor”，平台侧根据请求码启动对应的原生模块。这样做的好处是，未来如果新增了体征检测功能，直接新开一个通道即可，不会影响现有链路。

另外要特别强调一点：MethodChannel不是为高频大数据传输设计的，尤其在OpenHarmony设备性能偏弱的情况下，频繁走MethodChannel传视频帧或连续传感器数据，掉帧和内存飙升几乎是必然的。我在项目中只有低频指令类操作走MethodChannel，连续的帧流或传感流数据采用EventChannel或共享内存方式传递，这个决策在后面人脸检测部分的性能表现上起了决定性作用。

3. 核心功能实现：视力保护应用的关键模块拆解

3.1 距离检测模块：红外传感器与摄像头方案的取舍

距离检测是视力保护应用最核心的功能之一，目的是在你离屏幕太近（通常低于30厘米）时发出提醒。开源鸿蒙设备主要分为两类：自带接近传感器的手机型和没有专用传感器的平板、电视型。针对这两种情况，我做了两套方案。

第一种方案是直接读取系统距离传感器数据。OpenHarmony的传感器框架支持@ohos.sensor接口，可以通过on('proximity')注册一个近距传感器监听。这里要注意的是，传感器的原始返回值不一定是距离值，部分设备返回的是“近/远”状态（0或1），所以你需要在平台侧再做一次换算，把状态值转成毫米级估算值。我在真机上实测，华为平板的接近传感器返回精度足以做近距提醒，但低端设备存在数据抖动严重的问题，建议在Dart层做一次均值滤波再触发提醒逻辑。

第二种方案是通用兜底方案，不依赖任何传感器，而是通过前置摄像头连续采集画面，利用人脸检测算法估算人脸到屏幕的距离。这个方案跨设备适配性好，但非常吃算力。我在OpenHarmony设备上实测，如果每次摄像头帧都完整走人脸检测，CPU占用会直接飙到60%以上。最终我的做法是采样后再检测：每3秒抓一帧进行人脸检测，并在人脸区域框内连续三帧框宽变化率小于5%时，才进入距离计算逻辑。这样能在保证可用性的同时，大幅降低计算量，实际体验也够用。

3.2 眨眼检测与疲劳度评估：OpenCV在跨平台层的集成实践

眨眼检测如果自己从零写，工作量会非常大。OpenCV提供了一个预训练的Haar级联分类器用于人脸和眼睛检测，而且开源鸿蒙版本可以通过OpenCV的交叉编译进行集成。我选择的是C++实现核心算法，通过Flutter FFI（Foreign Function Interface）暴露给Dart层调用的方式，而不是走MethodChannel。原因很简单：FFI直接内存交互，调用开销远低于MethodChannel序列化传输。

眨眼检测的逻辑模型是这样的：先用Haar分类器定位眼睛区域，然后用光流法或帧差法判断眼皮状态转换。工程上我采用的简化方案是计算眼睛区域的高宽比（EAR，Eye Aspect Ratio），当连续两帧低于阈值、随后又恢复到正常值时，计为一次眨眼。这个算法不需要训练模型，处理速度极快，在OpenHarmony的低端设备上也能跑到30fps以上。

这里有个重要的工程细节：Flutter的TextureRegistrar可以让摄像头帧直接以GPU纹理方式注册到Flutter引擎，相当于帧数据绕过了Dart侧直接到达原生侧C++。我在OpenHarmony上验证了这个路径可行。使用shared memory或external texture传输摄像头帧，配合上面提到的FFI调用，可以实现不停顿的连续检测，而不会像MethodChannel那样卡死UI线程。

达尔文阈值是这个模块的灵魂参数，不同设备和不同光线条件下的EAR阈值差异很大。我实际测试下来，正视屏幕时EAR均值约0.28，闭眼瞬间会跌到0.12以下。初版我以为一个固定阈值就能搞定，结果在弱光环境和戴眼镜用户身上频繁误判，最后我把阈值设计成了动态自适应：取用户开始使用前2分钟内的EAR均值做基线，基线乘以0.5作为闭眼阈值，这一版在实测中的误报率降低了60%以上。

3.3 休息提醒策略：Flutter本地通知与高耗时任务调度

视力保护的核心价值在于“在不扰人的前提下引导用户休息”。这里的工程难点是定时器和精确调度的实现。Flutter本身有Timer，但应用一旦进入后台，Dart的Timer是不可靠的。所以我把提醒调度做在了平台侧，使用OpenHarmony的alarm接口，配置周期性的提醒任务，通过NotificationManager在应用退到后台时也能准时弹出通知。

这里要特别注意通知权限。OpenHarmony 4.0之后，应用必须显式申请ohos.permission.NOTIFICATION_CONTROLLER权限，并且用户在系统设置中打开通知开关后才允许弹通知。很多开发者第一次适配时完全没意识到还有这层设置，导致上线后大量用户反馈“不提醒”。我在代码中做了一个检测装置：启动时获取通知授权状态，如果未授权，主动弹出引导弹窗跳转系统设置开启，并在首次进入时就用可视化界面把整个权限流程演示一遍。

每次提醒的展示策略也有讲究。视力保护并不是每次提醒都要强制弹窗，长时间高频弹提醒会导致用户直接卸载应用。我的设计思路是分紧急等级：

• 等级一（提示）：连续使用25分钟，屏幕顶部显示横幅提示“建议远眺20秒”。
• 等级二（警告）：连续使用45分钟，弹出半屏卡片，提示做眼保健操。
• 等级三（强制）：连续使用60分钟，全屏拦截式页面，强制休息1分钟，提供“稍后提醒我5分钟”的唯一退出按钮。

这个提醒体系还配合了“疲劳加速因子”——如果前面检测到眨眼频率过低（每分钟低于8次），时间阈值会自动缩短30%。比如原本45分钟才提醒，眨眼过少时30分钟就会触发等级二警告。这套策略不是拍脑袋设计的，它参考了20-20-20法则（每20分钟看20英尺外20秒）并做了一定程度的本土化改造，实际用户留存体验比之前做过的“一刀切定时提醒”好很多。

4. 开源鸿蒙侧平台能力适配与实战配置

4.1 设备能力接入：Sensor、Camera、Notification的完整配置流程

这一节是把整个项目串起来的关键，也是新手最容易卡住的地方。到这一步，你已经有了能够运行“Hello World”的Flutter工程，下面要做的是把系统侧能力一点一点接到Dart层。

首先是权限声明。在OpenHarmony工程的module.json5文件里，需要添加如下权限：

{ "module": { "requestPermissions": [ { "name": "ohos.permission.CAMERA" }, { "name": "ohos.permission.NOTIFICATION_CONTROLLER" }, { "name": "ohos.permission.APPROXIMATELY_LOCATION" } ] } }

其中APPROXIMATELY_LOCATION不是必选项，但部分设备的Camera在初始化流程中会校验定位权限（用于地理围栏相关的相机行为），加上无妨。

然后是注册传感器监听的ArkTS代码示例：

import sensor from '@ohos.sensor'; import { BusinessError } from '@ohos.base'; let callbackId: number = 0; try { sensor.on('proximity', (data: sensor.ProximityResponse) => { // 单位通常是厘米，但部分设备的返回值是0或1 // 这里做一个映射：0表示近距（<5cm），1表示远距 let distance = data.distance === 0 ? 5 : 30; // 将数据通过Channel回传给Dart层 this.context.callMethod('onDistanceChanged', { distance: distance }); }, { interval: 'game' }); } catch (err) { let error = err as BusinessError; console.error(`Failed to register sensor. Code: ${error.code}, message: ${error.message}`); }

这一步有几个初学者经常踩的坑。interval参数不要使用normal，因为正常频率大约是5秒一次，对视力保护来说太不灵敏了，要用game（帧级别）或ui。另外传感器回调是高频的，很多设备是几百赫兹，你要在接收端降采样，比如每500毫秒才回传一次给Dart，否则MethodChannel会被弹幕一样的数据淹没，UI线程直接卡死。

Camera这块我留给具体的技术验证模块来展开，因为它在开源鸿蒙上有一个关键坑：初始化Camera时必须先注册CameraStatusCallback，等回调返回CAMERA_STATUS_AVAILABLE后再调用CameraManager.createCameraInput。如果顺序反了，摄像头会直接黑屏无任何报错。这个我印象太深了，当初排了一整天，最后发现是初始化时序问题。

4.2 Flutter FFI与C++核心库的工程集成

眼睛检测和距离估算的算法我放在了C++层。集成方式没有用标准的外部Native库编译方案，而是直接在Flutter工程下添加了一个CMake子工程。具体项目结构如下：

harmony_vision_app/ ├── ohos/ │ ├── entry/src/main/cpp/ │ │ ├── CMakeLists.txt │ │ ├── native_videocap.cpp │ │ └── vision_core.cpp │ └── entry/src/main/ets/ ├── lib/ │ ├── services/ │ └── pages/ └── pubspec.yaml

CMakeLists.txt里需要链接opencv_java或opencv_world库，这取决于你交叉编译OpenCV时的配置。如果你用的是预编译库，要确认架构匹配。开源鸿蒙设备目前主流是arm64-v8a架构，预编译包需要从OpenCV官网选择android-arm64分支（背后用的是同一套LLVM工具链），但存在SO名称冲突的风险，建议在编译时用libopencv_xxx.so重命名，避免和系统包冲突。

FFI的Dart侧定义非常简单：

import 'dart:ffi'; final DynamicLibrary visionLib = DynamicLibrary.open('libvision_core.so'); typedef DetectBlinkNative = Int32 Function(Int64 framePtr, Double threshold); typedef DetectBlinkDart = int Function(int framePtr, double threshold); final DetectBlinkDart detectBlink = visionLib .lookup<NativeFunction<DetectBlinkNative>>('detect_blink') .asFunction<DetectBlinkDart>();

注意，framePtr是摄像头帧数据在共享内存中的指针地址，不要尝试把整帧数据作为参数传进去，否则FFI的Dart侧会复制一次大内存块，性能直接劣化一个数量级。

4.3 数据存储和多端适配的思考

业务数据存储我用的是Drift（SQLite的Flutter封装），简单直接。项目里需要存的数据包括：用户设置项（休息时长、提醒间隔）、检测记录（每天的近距离时长和眨眼频率）、提醒历史（何时发生了什么级别提醒）。SQLite对于这类轻量级业务数据完全够用，不需要上Hive或者系统级分布式数据管理——后者虽然跨设备同步方便，但对这个场景来说重了，而且OpenHarmony版的分布式数据服务接口和Flutter插件还有兼容性问题，我不想让项目过度依赖某个特定分支的能力。

多端适配是我在开发过程中突然想明白的。本来只想做手机端，但项目中涉及的应用场景，比如学生上网课用平板、办公族用台式机，天然地要求应用能在多端运行。OpenHarmony的ArkUI支持应用以“原子化服务”的方式在手机、平板、电视和PC上运行，但Flutter分支对PC和电视的支持成熟度还不一致。我目前的策略是先用MediaQuery.sizeOf判断屏幕尺寸，大于600逻辑像素就自动进入双栏布局、右侧显示实时分析图表；电视端则额外增加遥控器按键事件支持。这块后续扩展空间很大，当前文档先把手机端做扎实。

5. 性能优化：帧率、内存和电量的三方平衡

5.1 框架层优化：减少UI重建和布局抖动

Flutter性能优化有个基本判断：如果你发现页面卡顿，十有八九不是引擎不行，而是你的Widget构建和布局逻辑有问题。我在做实时监测页时遇到过明显的滚动掉帧，一查发现是每个传感器数据回来都会setState重建整个页面，连顶部标题栏都被无谓重建了。

修法很直接：把需要实时变化的部分隔离成独立组件，用StreamBuilder或ValueListenableBuilder包裹，只更新局部区域。Vision数据会周期性刷新，一定要使用RepaintBoundary把变化区域和不变化区域隔离，否则Flutter会在每一帧都执行整页的重新光栅化，内存和电量的开销差异非常明显。

另一个细节是不要在build方法里做耗时计算，当初我在眼睛状态的展示Widget里做了一个状态判断和字符串拼接，这本身不耗时，但每次都新建对象导致GC频率升高。优化后把这些值全部预设成常量缓存，页面流畅度立刻上了一个台阶。

5.2 算法层优化：摄像头帧采样与检测频率的动态控制

摄像头连续做AI推理是最大的性能杀手。我的做法是给检测模块加了一个动态采样器：当用户处于正常使用状态时，每3秒抓一帧做距离估算；一旦发现距离低于阈值，立即切到高频率模式，每秒抓一帧，直到连续3帧恢复远距后再降回低频。

同一时间只做一种重计算。比如眨眼检测高负荷运行时，距离传感器的数据和摄像头检测数据不要同时拉满，我设计了一个优先级仲裁结构调整计算资源的分配。检测优先级从高到低排为：眨眼检测（疲劳指标最关键）→ 距离检测 → 环境光检测 → 色温调整。这个设计加上前面的降采样策略，在OpenHarmony平板上实测可以将CPU占用率从58%压到21%，是非常显著的提升。

5.3 内存和电量：共享内存、对象池与后台限制的实践

内存优化我做了三件事。第一，摄像头帧缓冲区统一使用循环队列加共享内存，不在Dart层持有帧对象；第二，眼睛检测的Bitmap结果直接复用前一次的对象实例，用inplace方式覆写，减少对象分配；第三，用完即释放Native侧的资源，不要依赖GC去回收不归属于Dart堆内存的C++对象。

电量优化的核心是“能不动就不动”。摄像头最长连续运行时间不应超过20分钟，我设置了一个强制自动关闭机制；距离传感器在屏幕熄灭后自动注销；后台运行时只保留通知调度和低频率的间隔检测，不再持续做面部检测。这样做的电量成绩，在3500mAh级别的开发板上实测，全天后台运行耗电量仅为6%，比之前一直开着摄像头的版本下降了将近4倍。

6. 常见问题与排查技巧实录（OpenHarmony + Flutter版）

6.1 Flutter引擎启动失败：版本匹配与初始化顺序

典型报错信息是“Failed to load flutter engine”或者压根没有任何日志，应用直接闪退。绝大多数原因是flutter_ohos适配层的版本与Flutter引擎版本不匹配。比如你用3.10.0版本的Flutter源码，却去加载3.7.12版本的引擎包，启动时必挂。

另外一个容易让人抓狂的点是初始化顺序。在MainAbility的onCreate方法里，必须先初始化FlutterEngine再调用setContentView，顺序反了虽然没有编译报错，但进入页面会白屏。而且OpenHarmony侧的IContent生命周期方法和Flutter的WidgetsFlutterBinding之间的绑定必须一一对应，漏一个回调处理方法就会导致触摸事件完全失效。

6.2 MethodChannel调用原生无响应：线程问题与参数序列化

这个问题的表现是：Dart侧调用invokeMethod，Promise一直没有回调。排查步骤我基本已经固定了：

1. 先看原生侧有没有日志输出，如果连try/catch都没进，说明通道名错了或原生侧根本没有注册这个channel。
2. 再看调用线程。OpenHarmony原生侧直接在主线程执行耗时任务会导致卡死，但Dart侧的回调又要求回到主线程，所以原生侧必须使用TaskPool或者Worker把耗时任务丢出去，再通过UIContext回到主线程回调。
3. 最后检查参数类型。MethodChannel在序列化时会对Map的value类型有要求，必须是基本类型、字符串、列表或可序列化的Map套件，如果你塞进去一个自定义Class，Dart侧收到的就是异常。

6.3 摄像头画面不显示或黑屏：权限、时序与SurfaceView冲突

摄像头黑屏的排查顺序很重要。第一步检查权限是否真的授予了，OpenHarmony的Camera API在权限未授予时不会抛异常，而是直接黑屏，这是一个特别离谱的低级陷阱。第二步检查初始化的时序，要等CameraStatusCallback返回可用状态后再创建输入流，这个顺序我在4.1节强调过，再错一次就真的不该了。第三步检查是否有其他应用占用了摄像头，解决方案是监听摄像头焦点的变化，提示用户关闭其他应用释放。

如果以上检查都没问题，把纹理注册的Surface初始化放在Camera启动之前，再开始写入帧流，会有一定程度的改善。

6.4 Flutter构建报错：Gradle/Visual Studio Toolchain等跨平台工具链问题

虽然不是OpenHarmony专属问题，但这款应用在开发期也会经常遇到Flutter的标准构建错误。典型的是unable to find suitable visual studio toolc，这种情况几乎都发生在Windows上开发目标设备时，是因为本机缺少C++桌面开发环境。由于当前项目目标是开源鸿蒙设备，可以直接在android/local.properties指定不启用桌面工具链，或者在Flutter配置中禁用需要原生桌面编译的插件。

另外，You are applying Flutter's main Gradle plugin imperatively using the apply这个报错也是老熟人。新版Flutter要求用plugins块声明式配置Gradle插件，旧配置直接apply是不兼容的。修法很机械：把build.gradle里的apply plugin: 'com.android.application'等行替换为plugins { id 'com.android.application' }方式，并且版本号统一从根项目的settings.gradle里读。不要问为什么这么改，Google官方模板已经说明了这是强制趋势。

6.5 常见问题速查表

7. 实测数据与性能表现复盘

我这里放一些真实测试数据，实测设备是开源鸿蒙4.0的开发板（RK3568芯片，4GB内存）和一台HarmonyOS NEXT手机（这里指OpenHarmony兼容设备）。表格整理如下：

开发板上能跑到这样的成绩，说明这套架构的优化方向是对的。手机端的表现明显更好，主要得益于芯片性能更强。但要注意，如果想支持电视端，摄像头和传感器相关功能可能会失效，到时候只能依赖应用层的逻辑降级方案。

我还做了应用启动速度和页面切换速度的测试，没有做启动优化时，冷启动时间是1.8秒，加上启动屏后用户体感还好；但如果后续要上架，强烈建议研究一下OpenHarmony的启动卡片（Form Extension）方案，可以提前把核心信息（比如“今日近距离时长”）放到桌面卡片上，既减小冷启动压力，又提高了用户回访率。

8. 项目复盘：这套方案的扩展空间与后续迭代方向

整个项目做下来，我自己最大的感受是：跨平台开发永远不是“写一套代码跑多端”那么简单，真正的成本在于每端适配层的设计深度。用Flutter做UI和业务层，用原生能力做系统调用，这个思路本身没有错，但如果前期没有做好接口抽象，后期每加一个平台都是灾难。我在这个项目中体会最深的经验是：平台适配层不止是native功能的wrapper，更是系统的“翻译官”和“护栏”——翻译官负责把OpenHarmony的能力翻译成Flutter能懂的语言，护栏负责把不同系统的差异隔离在业务层之外。

后续迭代方向上，我列了几个已经验证过可行但还没来得及全部完成的事情：

• 引入状态管理框架（Riverpod或Bloc）替代现有的原生setState方案，适合代码规模做大之后的场景。
• 增加云同步能力，让用户的视力保护设置和检测记录能够跨设备同步，结合OpenHarmony的分布式数据管理能力。
• 把检测结果以周报形式生成可视化报表，对比不同时段的近距离使用时长和疲劳趋势。
• 做Web端适配，把纯Dart层业务逻辑复用起来，只替换平台适配层实现。
• 增加多语言支持，目前UI文案已经做了字符串抽取，但尚未完整接入ArkUI的多语言资源体系。

如果你准备开始做一个类似的项目，我给的建议是按照我文章的章节顺序推进：先跑通一个带摄像头和传感器的“最小可用版本”，验证整个链路没有硬伤，再逐渐叠加业务功能和优化策略。千万不要一上来就想着做一个功能齐全的完整产品，跨平台项目在集成阶段遇到的三方冲突数量，远比你预想的多，上来就做全部功能很容易被各种坑消耗掉所有热情。最后，把版本升级和依赖升级的动作放到项目稳定运行后再做，每次升级都需要单独安排一出回归测试的档期，这是我自己踩过好多次坑换来的经验。