轨迹记录总忘按开始?我在鸿蒙上做了个App,解决了90%的痛点

HarmonyOS PC:全场景协同办公的智能中枢 操作系统正从单机运行范式迈向全场景协同新阶段。HarmonyOS PC并非传统桌面OS的替代品,而是以分布式软总线为底座、以原子化服务为单元、以AI驱动为引擎的智能办公中枢。其核心原理在于打破设备边界,通过能力抽象、动态发现与按需调度,实现人-设备-任务的自然耦合。技术价值体现在毫秒级设备发现、跨端零感协同、环境自适应运行及本体驱动的数据治理。典型应用场景覆盖研发图纸协同、供应链闭环管理、AI合同审查、会议纪要自动同步等高频办公流。本文深入解析其作为新型办公基础设施的技术逻辑与落地路径。 阅读详情

这个 App 要解决什么问题

上个月出差跑了三个城市,回来翻手机相册想回忆去过哪些地方,发现照片里全是会议室和酒店大堂。那些走过的街道、路过的江边、绕远路发现的小巷子,什么都没留下。

运动类 App 倒是能记录轨迹,但每次都要手动开始、手动结束,忘按一次就白走了。我只是想给自己留个痕迹,不想发给任何人看,也不需要什么配速心率。

困扰了挺久,后来干脆自己动手做了一个 App——雁过留痕。只干一件事:把你去过的地方,安静地留在地图上。iOS 版先做完了,今年把它迁移到了 HarmonyOS 原生,这篇文章聊聊整个鸿蒙开发过程中的技术选型和实际体感。

为什么选 HarmonyOS 原生而不是跨平台

最早 iOS 端是用 SwiftUI 写的。做鸿蒙版本时考虑过跨平台方案,但试了几天 ArkTS 之后改了主意。说实话,ArkUI 的声明式语法和 SwiftUI 在思路上非常接近,迁移的心智成本比我预想的低不少。Column、Row、Stack 和 SwiftUI 的 VStack、HStack、ZStack 几乎一一对应,我把 iOS 端的 UI 结构搬过来改改语法,大部分页面半天就能跑起来。

更关键的是鸿蒙有些能力是 iOS 生态里拿不到的,对这个 App 的场景刚好有用。

后台持续定位的处理方式就很不一样。iOS 的后台定位权限审核越来越严,而 HarmonyOS 的 continuous task(长时任务)机制让后台轨迹采集有了更清晰的系统级支持。用户授权一次,App 在后台安静记录,不需要反复弹窗确认。对于一个"开了就不用管"的足迹工具来说,这个体验差距是实质性的。

另一个鸿蒙独有的体验是原子化服务卡片。用户不用打开 App,桌面卡片上就能看到今天走过的轨迹缩略图。我觉得这比 iOS 的 Widget 更适合做"瞄一眼就够"的信息展示,因为卡片本身可以承载更丰富的交互。

核心技术实现:轨迹采集与地图渲染

轨迹记录的核心逻辑不复杂,但细节很多——GPS 漂移过滤、低速状态下的降频采集、电量优化策略等等,这些都是实际跑起来之后一个一个调出来的。地图渲染用了 HarmonyOS 的 MapComponent,把采集到的坐标点用 Polyline 画到地图上,骨架代码长这样:

@Entry
@Component
struct TrackMapView {
  @State pathPoints: Array<mapCommon.LatLng> = []
  build() {
      Column() {
            MapComponent({
                    mapOptions: { center: { latitude: 39.9, longitude: 116.4 }, zoom: 12 }
                          })
                                  .onReady((map) => {
                                            let polylineOpt: mapCommon.MapPolylineOptions = {
                                                        points: this.pathPoints,
                                                                    clickable: false,
                                                                                width: 8,
                                                                                            color: 0xFF3A7DFF
                                                                                                      }
                                                                                                                map.addPolyline(polylineOpt)
                                                                                                                        })
                                                                                                                                .width('100%')
                                                                                                                                        .height('80%')
                                                                                                                                            }
                                                                                                                                              }
                                                                                                                                              }
                                                                                                                                              ```
做的事情很直白:把坐标数组丢给地图组件,画一条线。实际项目里还有轨迹平滑、分段着色之类的处理,但整个渲染链路的骨架就是这个样子。MapComponent 的 API 设计比较直觉,如果你之前用过高德或百度的地图 SDK,上手不会有什么障碍。

桌面卡片的实现是我觉得鸿蒙版比 iOS 版体验提升最明显的地方。每天凌晨自动截取前一天的轨迹缩略图更新到卡片上,用户早上解锁手机一眼就看到昨天的足迹轮廓。卡片上只放两样东西:一张轨迹缩略图和一个距离数字,克制一点,信息密度刚刚好。

```arkts
@Entry
@Component
struct TrackWidgetCard {
  @LocalStorageProp('todayDistance') todayDistance: string = '0 km'
    @LocalStorageProp('trackSnapshot') trackImg: string = ''
  build() {
      Column({ space: 8 }) {
            Text('昨日足迹')
                    .fontSize(14)
                            .fontColor('#666')
                                  Image(this.trackImg)
                                          .width('100%')
                                                  .aspectRatio(1.6)
                                                          .borderRadius(8)
                                                                Text(this.todayDistance)
                                                                        .fontSize(20)
                                                                                .fontWeight(FontWeight.Medium)
                                                                                    }
                                                                                        .padding(12)
                                                                                          }
                                                                                          }
                                                                                          ```
## 从 SwiftUI 迁移到 ArkTS 的真实体感

聊几个具体感受,给同样在考虑双端开发的同学做参考。

状态管理思路上有差异。SwiftUI 用 @State、@ObservedObject 那套,ArkTS 的 @State、@Link、@Prop 的作用域划分更细。刚开始会有点不习惯,但写了两三个页面之后反而觉得鸿蒙这套更明确——谁持有数据、谁只是引用,代码里看得更清楚。这对有 Swift 或 TypeScript 基础的开发者来说学习曲线很友好。

工具链成熟度还在追赶。DevEco Studio 用下来整体还行,但和 Xcode 比的话,断点调试、性能分析这些工具还有打磨空间。不过每个版本都能感觉到在进步,不是什么阻塞性问题。

设备适配是个明显的加分项。同一套代码跑在手机、平板、折叠屏上,ArkUI 的自适应布局能力确实省了不少事。雁过留痕在 MatePad 上展开地图的效果比手机上好太多,大屏看轨迹图那种满足感是小屏给不了的。

## 关于"只做留痕"的产品克制

开发过程中最难的不是技术,是克制。总有人建议加社交分享、加打卡排行榜。但我一直觉得这个 App 的价值恰恰在于它什么都不多做。你出门,它安静记录;你想看了,打开地图,所有去过的地方一目了然。没有点赞,没有评论,没有"今日步数打败了 98% 的用户"。

有次出差结束看了一眼全年轨迹图,发现自己居然去过三十多个城市。那个瞬间比任何打卡成就都让人感慨。地图上那条慢慢延伸的线,就是你存在过的证据。

## 后续计划

鸿蒙版目前在持续迭代中,后面打算尝试跨设备流转——手机上录的轨迹在平板上查看大地图,在手表上快速看今日路线。这些场景在 HarmonyOS 的分布式架构下实现起来会比较自然,也是鸿蒙生态真正区别于其他平台的地方。

如果你也在做鸿蒙开发,欢迎交流技术方案,特别是后台定位功耗优化和地图渲染性能这两块,踩过坑的朋友留言聊聊。

#HarmonyOS开发 #ArkTS #ArkUI #原子化服务 #鸿蒙原生应用
AI大模型与鸿蒙分布式系统在智慧艺术场馆中的融合应用实践 在智慧场馆与数字文旅领域,AI大模型和分布式操作系统正成为技术革新的核心驱动力。AI大模型通过深度学习技术,能够理解和生成复杂内容,其原理在于对海量数据的学习与模式识别,从而具备强大的认知与创造能力。鸿蒙系统的分布式软总线与原子化服务架构,则实现了跨设备的无缝协同与资源调度,其技术价值在于打破信息孤岛,构建统一、灵活的服务生态。这两项技术的结合,为传统行业的数字化转型提供了全新范式。在艺术展览、博物馆等场景中,它们能够将孤立的导览、环境控制与互动装置整合为有机整体,实现从静态陈列到动态交互的升级。本文探讨的 阅读详情

相关推荐

APP开发周期真相:需求颗粒度与技术选型如何决定工期

移动应用开发周期并非单纯由代码量决定,而是一个受需求明确性、技术方案可行性、团队协作效率和交付目标共同约束的系统工程。其中,需求颗粒度直接影响功能边界与实现复杂度,技术选型则关系到开发效率、兼容性风险与长期维护成本。例如,‘离线使用’这一模糊需求可能对应轻量缓存(1天)、PWA增强(3–5天)或本地数据库同步(2周)三种截然不同的技术路径;同样,‘会员积分系统’若未通过场景故事法具象化,极易引发前后端返工与工期失控。理解这些底层逻辑,才能科学评估MVP、生产就绪版等不同交付目标的真实耗时,并规避80%发生在

unixboy 431

轨迹记录的痛点被我用鸿蒙原生开发解决了90%——雁过留痕 App 技术分享

iOS 的后台定位权限审核越来越严,而 HarmonyOS 的 continuous task(长时任务)机制让后台轨迹采集有了更清晰的系统级支持。轨迹记录的核心逻辑不复杂,但细节很多——GPS 漂移过滤、低速状态下的降频采集、电量优化策略,每一项都能单独写一篇。这个是鸿蒙独有的体验。我觉得这比 iOS 的 Widget 更适合做这种"瞄一眼就够"的信息展示,因为卡片本身可以承载更丰富的交互。说实话,ArkUI 的声明式语法和 SwiftUI 在思路上非常接近,迁移的心智成本比我预想的低不少。

same4869的博客 255

Zephyr OS实战指南:从入门到精通物联网开发

本文提供了一份详尽的Zephyr OS实战指南,涵盖从开发环境搭建到物联网应用开发的全过程。文章详细介绍了如何利用Zephyr OS进行线程管理、设备驱动开发、低功耗设计以及蓝牙通信,并通过具体代码示例帮助开发者快速掌握这一专为物联网设备设计的开源实时操作系统,实现从入门到精通的跨越。

weixin_29201933的博客 546

华为畅享90系列发布,首次搭载HarmonyOS 6,鸿蒙完成全机型覆盖

3月23日,华为举办春季全场景新品发布会,接连发布华为畅享90系列、华为Mate80 Pro Max 风驰版等新品。作为畅享系列首款搭载HarmonyOS 6的手机,华为畅享90系列依托系统底层优势,并与各类鸿蒙应用深度共创,让用户的社交、影音、出行等体验都焕然一新。至此,HarmonyOS 6完成了对华为全系手机机型的覆盖,推动鸿蒙的全场景体验迈入全民普及。自去年10月份发布以来,HarmonyOS 6已成为应用创新的“首选土壤”。众多伙伴争相首发独家功能,助推生态体验从“可用”加速迈向“好用”。

bineans的博客 1161

IGV新手必看:5分钟搞定ChIP-seq/DAP-seq/ATAC-seq数据可视化(附常见报错解决方案)

本文为IGV新手提供了一份快速上手的实战指南,详细讲解了如何高效完成ChIP-seq、DAP-seq、ATAC-seq等数据的可视化。内容涵盖软件安装、基因组导入、文件格式转换与优化,并重点剖析了“导入后一片空白”等常见报错的根本原因与解决方案,帮助用户在5分钟内避开雷区,生成可用于发表的IGV专业图谱。

weixin_29198045的博客 538

别再只盯着YOLOv8了!手把手带你用PaddleDetection的PP-YOLOE+搞定你的第一个检测项目

本文介绍了PP-YOLOE+在目标检测领域的优势与应用实践,对比YOLOv8展示其在精度、速度和部署便利性上的突破。通过详细的代码示例和实战教程,帮助开发者快速上手PaddleDetection工具链,实现产业级目标检测项目,提升开发效率。

weixin_42701915的博客 184

鸿蒙健康应用开发全攻略,鸿蒙系统(HarmonyOS)开发实战

好,来一场关于如何在鸿蒙(HarmonyOS NEXT)上打造一款“私人健康小管家”的思维漫游。我会用“侦探破案”的视角,带你走完全程,从灵光一现到上架商店。想象一下,你是一位“健康侦探”,你的任务是开发一个App,帮助用户“侦破”自己身体的秘密。这个App不能只是个冷冰冰的数据记录本,它得是个有温度、有洞察力的伙伴。核心线索(功能):嫌疑人画像(用户是谁):工欲善其事,必先利其器。鸿蒙给我们准备了一套相当专业的“侦探套装”。特别装备:如果要做专业级健康应用,你还需要关注HiHealth SDK,它提供了更

热爱技术与前沿创新,深耕科技领域,在科创中精进自我;探索技术乐趣,分享技术干货与成长心得,以技术为伴,热爱生活,在科创与生活中双向成长。 460

simulink可控励磁同步电机模型分析

他励同步电机模型分析

qq_26681609的博客 5551

Flutter+鸿蒙跨平台开发实战:旅游App三端兼容方案

跨平台开发框架Flutter通过Dart语言和Skia渲染引擎实现了一套代码多端运行,大幅提升移动应用开发效率。其热重载特性与丰富的插件生态,使其成为混合开发的首选方案。在鸿蒙生态中,Flutter可通过平台通道调用原子化服务等原生能力,兼顾开发效率与功能完整性。本文以旅游类App为例,详解如何利用Flutter+鸿蒙混合方案实现地图轨迹、相册访问等核心功能的三端兼容,其中涉及MethodChannel通信、性能优化等关键技术点,最终使APK体积减少40%,开发效率提升60%。

weixin_32075843的博客 216

lattice 黑盒子的生成和使用(Creating Your Own Black Box Modules)

很多客户,特别是外包项目,需要做黑盒子,防止他人看到源码,那么这就需要对相关的源码打包加封了。diamond help 说的也是模糊模糊的,这次给出实际验证过的流程。 1.先将要加封的模块间一个工程,建好工程,写好代码之后,模块名字叫做crosslink(这个使用黑盒子的时候要用),代码如下: module crosslink( output wire[3:0] led, input wire clk, input wire reset ); reg [29:0] cnt; reg [3:0] led1;

qq_39633876的博客 1481

YOLOv8训练流程-原理解析[目标检测理论篇]

本篇文章主要介绍了YOLOv8训练的流程,主要介绍了Task Aligned Assigner正负样本匹配策略以及YOLOv8的损失计算。

ice 4516

鸿蒙金融理财App全栈开发与智能运维实践

微服务架构和分布式系统是现代金融应用的核心技术支撑,通过Spring Cloud等框架实现服务解耦与弹性扩展。在鸿蒙生态中,ArkUI框架的声明式开发显著提升了跨设备适配效率,结合MySQL强事务保障金融数据一致性。智能运维体系基于Prometheus监控和ELK日志分析,实现交易成功率>99%的金融级SLA。针对金融理财场景,特别设计了用户反馈自动分类系统,通过NLP技术将问题响应时间缩短至72小时内。该项目实践表明,结合鸿蒙分布式能力(如多设备协同交易)与A/B测试驱动的迭代优化,可使关键业务指标提升4

weixin_42113456的博客 247

Android 车联网——CarAudioService介绍(六)

CarAudioService 是 Android Automotive OS 中的一个重要组件,用于管理车辆中的音频功能。它是 Android Auto 的一部分,负责处理车辆音频的播放、控制和路由。CarAudioService 使用标准的 Android 组件架构,基于 Binder 通信机制,提供了一组 API,用于管理车辆音频。它包括以下主要功能:音频路由管理:CarAudioService 可以让开发者控制音频的路由,即将音频发送到不同的输出设备,例如车辆的扬声器、耳机等。

小旭的专栏 3201

Flutter+鸿蒙跨平台运动社交App开发实践

跨平台开发框架Flutter凭借其高性能渲染引擎和热重载特性,已成为移动应用开发的重要选择。结合华为鸿蒙系统的分布式能力与原生接口,开发者可以实现真正意义上的多端统一开发。本文通过一个运动社交App的实战案例,详解如何利用Flutter的BLoC状态管理优化社交功能,以及通过鸿蒙健康Kit实现多设备运动数据同步。特别针对性能优化,介绍了SkSL预热、列表渲染优化等关键技术,最终使应用在保持15MB包体积的同时,实现60fps的流畅体验。

weixin_32147929的博客 296

Carla中如何渲染opendrive车道线和车道标识(全网独家,附代码)

carla是可以单独加载opendrive并渲染路面的,但是无法把车道线渲染出来,这是一个大坑,因为没有车道线就无法给感知输入。楼主已经实现,直接渲染车道线或者带PBR贴图的车道标识。实现起来非常简单,但必须对carla源码以及ue的开发足够了解。在carla源码中有一个很重要的类opendrivegenerator,它是关于opendrive渲染的全部方法,但是你是找不到它实例化的地方的,因为它被定义在蓝图关卡中。网上包括carla官方关于carla源码的分析少之又少,楼主将自己的经验写出来供大家参考。

u013998156的博客 1090

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

鸿蒙原生开发手记:徒步迹 - 数据模型定义与序列化

本文介绍了徒步迹App的数据模型定义与序列化方案,主要包括五大核心模型: 用户与认证模型:定义用户信息、登录注册请求响应等数据结构 路线模型:包含路线详情、海拔信息和地理坐标等 轨迹模型:记录徒步轨迹、轨迹点和分段数据 团队模型:管理团队信息和成员关系 API通用响应:统一接口返回格式 同时提供了JSON序列化工具类,实现日期转换、轨迹点压缩等实用功能,确保数据在网络传输和本地存储时的高效处理。这些标准化定义为App开发提供了清晰的数据规范。

2501_91849192的博客 178

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

植物养护日记 App基于HarmonyOS ArkTS API 24实现WateringRecordContent 浇水记录页:勾选清单 + 时间线双结构

在 HarmonyOS NEXT 正式商用的背景下,ArkTS 作为鸿蒙生态的官方应用开发语言,正在从传统的命令式 UI 开发范式向声明式 UI 范式全面迁移。ArkUI 框架以组件化、声明式、状态驱动为核心特征,要求开发者以"描述 UI 应该是什么样"而非"一步步操作 UI 怎么变"的思维方式构建界面。

2301_79651252的博客 203

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

Flutter自动化测试日志在鸿蒙设备的适配与优化

在跨平台应用开发中,自动化测试日志的解析与处理是确保应用质量的关键环节。Flutter作为流行的跨平台框架,其测试日志在Android/iOS平台表现良好,但在鸿蒙设备上却面临时间戳不同步、Widget树渲染轨迹丢失等挑战。通过分层拦截方案和时钟校准策略,可以有效解决这些问题。日志结构化处理和高性能压缩算法进一步提升了日志分析的效率与准确性。这些技术不仅适用于Flutter与鸿蒙的适配场景,也为其他跨平台框架的日志处理提供了参考。本文重点介绍了patrol_log组件的鸿蒙适配方案,包括核心架构改造、时间同

weixin_30897079的博客 375

鸿蒙NEXT主力机体验:原生应用生态与跨端协同实战报告

鸿蒙操作系统作为国产分布式OS代表,其核心价值在于通过微内核架构与原子化服务实现跨设备无缝协同。本文聚焦HarmonyOS NEXT的原生应用生态演进,解析其脱离安卓兼容层后的系统稳定性、服务调用精度与分布式能力落地效果。围绕‘鸿蒙NEXT’‘原生应用’两大热词,从用户真实主力机场景切入,探讨系统级权限管理、Service Ability接口规范、AVSession媒体会话等关键技术对日常支付、办公、健康、娱乐等刚需链路的影响。内容覆盖AppGallery原生标识验证、跨端任务接续、分布式硬件抽象等工程实践

cuankuangzhong6373的博客 567

Flutter结合开源鸿蒙构建臂力训练App:生物力学与周期化算法实战

跨平台开发是现代移动应用的重要趋势,借助Flutter的渲染自绘能力,开发者可以在非主流操作系统上复用一套代码。开源鸿蒙(OpenHarmony)作为新兴操作系统,其生态适配成为技术焦点。同时,运动训练领域需要精细化的生物力学分析与科学化的力量周期化训练方法。本文将讲解如何通过Flutter与开源鸿蒙的结合,实现一个基于生物力学模型与周期化算法的臂力训练辅助应用,并详细阐述训练矩阵的架构设计与数据建模思路。从力矩计算到1RM估算,从线性周期到波动周期,再到跨平台适配中的性能优化,为运动科学工具的开发者提供一

weixin_34409357的博客 307

智能手表App开发技术选型实战指南:RN、Flutter与原生深度对比

智能手表App开发本质是受硬件资源、系统沙盒和分发机制三重约束的嵌入式工程实践。其核心原理在于平衡渲染一致性、传感器直控能力与平台合规性——React Native擅长高频健康数据同步但受限于动态加载禁令;Flutter提供像素级UI控制却需手动调优GPU内存与ABI兼容;Kotlin/Swift则能直接对接HAL层与HealthKit等系统API,保障毫秒级响应与审核通过。技术价值体现在降低售后投诉率、提升表盘帧率稳定性及满足App Store/HarmonyOS上架要求。典型应用场景包括苹果Watch内

weixin_33912246的博客 399

Flutter跨平台应用实战:人生轨迹记录与趋势分析系统设计

在数字化的今天,个人生活中的重要事件以数据形式沉淀,如何利用这些数据发现规律、辅助回顾,成为了移动应用的一个实用方向。这类应用的核心在于数据层设计——需要采用合适的内嵌数据库模型来承载结构化事件、标签与情绪分,并借助统计图表和线性回归等方法进行趋势洞察。Flutter作为高效跨平台框架,能够以一套代码覆盖iOS、Android与鸿蒙多个生态,显著降低多端维护成本;而SQLite及类型安全的Drift封装则保证了海量轨迹数据的稳定读写。从时间线展示、情绪趋势分析到回顾提醒,完整的工程实践涉及数据库选型、长列表

weixin_34408624的博客 462

鸿蒙Flutter适配GTFS Realtime库的实践与性能优化

跨平台应用迁移鸿蒙系统时,数据解析层往往是决定工作量的关键环节。GTFS Realtime作为公共交通领域通用的实时数据交换标准,采用Protobuf二进制编码,以紧凑的结构承载车辆位置、延误和事件信息。Protobuf的高压缩率和强类型特性,使其在高频位置数据场景下显著优于JSON,同时能有效避免解析歧义。在鸿蒙Flutter开发中,将官方维护的gtfs_realtime_bindings纯Dart库集成到工程,即可复用既有Dart业务逻辑,无需重写原生桥接。本文基于鸿蒙真机实践,梳理了环境搭建、依赖冲突

weixin_29009971的博客 309

飞盘高尔夫记录与管理基于HarmonyOS API 24实战解筛选器通过 difficultyChip 构建方法渲染为横向滚动的标签组,每个标签的激活状态由 selectedDifficulty 控制

在 HarmonyOS NEXT 正式商用的背景下,ArkTS 作为鸿蒙生态的官方应用开发语言,正在从传统的命令式 UI 开发范式向声明式 UI 范式全面迁移。ArkUI 框架以组件化、声明式、状态驱动为核心特征,要求开发者以"描述 UI 应该是什么样"而非"一步步操作 UI 怎么变"的思维方式构建界面。

2401_86031952的博客 46

HarmonyOS 6 地图路程规划实战:从技术选型到路线绘制全流程

在地图应用开发中,路线规划是高频核心功能,而鸿蒙原生生态的成熟让开发者得以摆脱WebView卡顿与手势冲突。地图渲染本质是坐标点集的采集与绘制,涉及地理编码、路径搜索、折线展示及导航信息解析等基础链路。理解坐标系(如GCJ-02与WGS84)的差异是避免路线偏移的前提,合理利用地图SDK的路线规划接口,配合权限配置与性能优化,即可在HarmonyOS应用中实现流畅的起终点选点、多路线绘制与导航提示。本文以高德HarmonyOS SDK为例,完整演示在HarmonyOS 6上从环境搭建、坐标转换到路线绘制落地

weixin_29256771的博客 273

测绘像控点外业近拍重构——鸿蒙 Camera Kit 影随人动与手动对焦在地理信息行业的落地

针对像控点外业拍摄走位、对焦、记录难题,HarmonyOS 6.1.1 Camera Kit提供AUTO_FRAMING(VideoSession视频会话)实现自动构图,以及手动对焦三接口(PhotoSession)支持距离设置与读回校验。两会话互斥,需先释放旧会话再建新会话。应用采用“Stack+四页四弹窗”架构,深色主题适配野外强光。

kathy_tan的博客 489
上一篇: 翻相册找不到去年走过哪些街,我用 HarmonyOS 的思路做了个轨迹记录 App
下一篇: 轨迹记录的痛点被我用鸿蒙原生开发解决了90%——雁过留痕 App 技术分享
SameX-4869
博客等级 码龄18年 3354粉丝 657原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值