文档开发者中心
我的
推荐
最热
最新
其他
已解决
未解决
在京粉APP复制了推广口令后,再打开京东APP,口令复制内容不能弹出(这个口令就和淘宝复制链接是一样的用法),之前都不会,换了新手机就出现这个问题了

评论1

浏览 8

发布于58分钟前
我在做一个儿童科学学习 App「电纪元」,目前遇到本地存储选型问题,想听听大家的实战经验。背景:需要存储的数据包括:用户学习进度(每节课的完成状态、得分)、错题记录、应用设置项;学习进度数据量会随课程增长,错题记录需要按科目、时间查询和统计;未来可能增加离线缓存的学习报告。我的疑问:preferences 是不是只适合存配置类的少量键值对?数据量大了性能会崩吗?RelationalStore 用起来和传统 SQLite 有什么区别?有没有官方推荐的最佳实践(比如单例封装、异步调用)?这两种方案能混用吗?比如设置用 preferences、业务数据用 RelationalStore,这样拆合理吗?目前我倾向「混用」方案,但不确定有没有坑,求踩过坑的兄弟指条路。

评论6

浏览 45

发布于3小时前
K 线图每秒推 30 个点,手指拖拽时曲线出现跳帧式瞬移,用  invalidate  触发重绘反而更卡,静态网格和坐标轴每次都跟着重画,高频绘制里怎么把静态层和动态层拆开?

评论7

浏览 49

发布于5小时前
如何实现组件边缘的折射效果 背景纯透明 仅边缘折射效果 并且可以根据背景的变化实时进行预览的效果 这种相果 也就是苹果的液态玻璃效果 如何在鸿蒙当中使用arkui去实现液态玻璃的效果 能否完全复刻苹果的液态玻璃效果

评论71

浏览 2.1k

发布于2026-09-05 02:57
云云
|
采纳答复
点赞10
回复于2026-09-10 06:57
分布式数据对象适合同步哪些规模的结构化状态?

评论5

浏览 40

发布于5小时前
申请了非公开发布获得审核通过,还没有发布,当时申请的的应用名称现在需要修改,会影响非公开发布的资格吗

评论5

浏览 26

发布于7小时前
就是我想对方给我发了一句话后,小组件里能实时展示出来,目前能做到打开app后组件更新,但是我想实时更新有啥办法吗

评论4

浏览 43

发布于7小时前
请问上架鸿蒙应用一定要每年支付服务器费用和域名费用吗?做个小工具上架,还要每年都支付几百块费用才行吗?我问AI,好像说如果不持续租用服务器的话。备案会被撤销。应用也会被下架。

评论25

浏览 645

发布于2026-10-16 09:17
Stage 模型中 UIAbility 与 WindowStage 生命周期的执行时序,能不能搞一个流程图看看?

评论4

浏览 34

发布于8小时前
原先文档指南,API接口说明文档,每个文档底部都有允许评价的,现在在Safari浏览器中怎么没有了,昨天还是正常的?

评论4

浏览 20

发布于8小时前
在建立 websocket 连接时,服务器在响应握手请求时在响应中添加了自定义头并返回状态码 361,我们观察到 libwebsockets 可以正确接收到自定义头,但是 websocket 的接口最后只收到了部分信息 ,如何获取自定义头。// 接口最后返回内容 { "code": 200, "data": "361" }应用使用 `@kit.NetworkKit` 的 `webSocket`,在调用 `connect()` 前订阅 `headerReceive`。服务端返回合法的 HTTP 101 升级响应。当 `X-Custom-Location: probe-unit` 紧邻 `Upgrade: websocket` 之前时,应用收到的 `x-custom-location` 为 `probe-unitwebsocket`;将相同自定义头放在标准头之后,则读到正确值 `probe-unit`。HTTP/1.1 101 Switching Protocols Uninclude-Old-Man-Id: true X-Custom-Location: probe-unit Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: <按本次请求计算>自定义头在 Upgrade 之前时读取到的结果是 probe-unitwebsocket。 HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: <按本次请求计算> Uninclude-Old-Man-Id: true X-Custom-Location: probe-unit这样读取的就是正确的。且两种响应均可正常升级 websocket 协议。

评论5

浏览 37

发布于8小时前
设备/环境:SGT-AL10 · HarmonyOS 7.0.0.105 · API 26 · DevEco Studio(hms SDK,UIDesignKit 声明 6.1.0(23)/6.1.1(24));应用 metadata 已配置 ohos.arkui.UIMaterial.state = "enable";targetAPIVersion ≥ 26;entry 模块;系统设置"沉浸光感" = 强(最高档)。问题现象:底部导航(悬浮胶囊 + 独立圆形)由普通 ArkUI 组件(Stack/Row)通过 systemMaterial(new uiMaterial.ImmersiveMaterial(...)) 接入沉浸式系统材质。HarmonyOS 7.0.0.105 SP6 系统更新之前:胶囊呈现真实玻璃质感(折射/光晕/通透)。SP6 更新之后:同一代码、同一设备、未改任何配置——胶囊变成纯透明的卡片(背后内容直接透出,无任何材质滤镜/折射/高光;看起来就像完全没有材质)。已按官方文档验证:按"沉浸光感"官方指南示例 1 的写法复刻(Column/Stack + .backgroundColor(Color.Transparent) 写在 .systemMaterial(...) 之前 + borderRadius + 顺序正确),同样失效。按"通用组件封装"实践(ImmersiveSurface:独立组件 + BuilderParam 内容 + 透明背景 + borderRadius + clip(true) + systemMaterial 最后),同样失效。运行时探针证据(关键):deviceInfo.apiAvailable('26.0.0') = true;uiMaterial.getMaterialInfo().state = 1(≠ DISABLE)→ 应用侧门全过;new uiMaterial.ImmersiveMaterial({ style: REGULAR, materialColor: '#80FF0000', interactive: true, lightEffect: {color: undefined} }) 传入 systemMaterial 后,50% 红色 materialColor 在画面上零差异(胶囊未变粉)——证明材质滤镜完全未被渲染(不是"样式选错/背景遮挡"类问题)。对照:同一设备上,系统组件的表面(如音乐条、系统设置预览)沉浸光感正常;HDS HdsTabs 官方悬浮页签(barFloatingStyle.systemMaterialEffect,materialType/materialLevel 模式)玻璃材质正常——唯独第三方应用里自定义 ArkUI 节点的 systemMaterial 不渲染。求助点:自定义 ArkUI 组件(Stack/Row/Column 等普通容器)的 systemMaterial 在 7.0.0.105(SP6) 是否被限制/降级?是否已有已知问题或需要新的启用条件?应用侧如何判定设备的沉浸光感算力档位(低/中/高)与全局材质等级?官方指南示例 5 提到 uiMaterial.getGlobalMaterialLevel() / uiMaterial.isImmersiveMaterialSupported(),但当前 SDK 的 ArkTS 声明中不存在这两个 API(能力清单 ArkUI.json 中有声明,since 26.0.0)——这是声明回退还是需要更高 SDK 补丁?如果自定义组件的材质确实无法恢复,官方推荐的自定义底部导航正确载体是什么(HDS 已确认可用,但存在自定义页签内容/动画限制)?代码片段(完整:普通 ArkUI 组件 + 沉浸光感)以下 = 生产组件中"普通 ArkUI 组件 + 材质接入"的完整相关代码(约 120 行)。 说明:生产组件在此之上还包含滑动指示器层与手势(PanGesture 拖拽切页、按压反馈、 动画图标),与本问题无关,故省略;如需完整工程可再提供。import { uiMaterial } from '@kit.ArkUI'; import { deviceInfo } from '@kit.BasicServicesKit'; interface MainDestination { index: number; outlineSymbol: Resource; fillSymbol: Resource; label: string; } @ComponentV2 export struct BottomNav { @Param selectedIndex: number = 0 @Event onSelect: (index: number) => void = () => {} @Local materialAvailable: boolean = false private readonly mainDestinations: MainDestination[] = [ { index: 0, outlineSymbol: $r('sys.symbol.message'), fillSymbol: $r('sys.symbol.message_fill'), label: 'Chat' }, { index: 1, outlineSymbol: $r('sys.symbol.person_crop_circle_fill_1'), fillSymbol: $r('sys.symbol.person_crop_circle_fill_1'), label: 'Contacts' }, { index: 2, outlineSymbol: $r('sys.symbol.gearshape'), fillSymbol: $r('sys.symbol.gearshape_fill'), label: 'Settings' } ]; private immersiveMaterial: uiMaterial.ImmersiveMaterial | undefined = undefined; aboutToAppear(): void { try { this.materialAvailable = deviceInfo.apiAvailable('26.0.0'); if (this.materialAvailable) { const info = uiMaterial.getMaterialInfo(); this.materialAvailable = info.state !== uiMaterial.MaterialState.DISABLE; } this.immersiveMaterial = this.materialAvailable ? new uiMaterial.ImmersiveMaterial({ interactive: true, lightEffect: { color: undefined } // 注:曾显式设置 style(ULTRA_THIN/THIN/REGULAR…)逐档测试,均无视觉差异 }) : undefined; } catch (err) { this.materialAvailable = false; this.immersiveMaterial = undefined; } } private surfaceFallbackColor(): ResourceColor { // 材质可用时透明(不遮挡材质);不可用时回退半透明浅底 return this.materialAvailable ? Color.Transparent : $r('sys.color.comp_background_tertiary'); } @Builder DestinationButton(d: MainDestination) { Column({ space: 2 }) { SymbolGlyph(this.selectedIndex === d.index ? d.fillSymbol : d.outlineSymbol) .fontSize(22) .fontColor([this.selectedIndex === d.index ? $r('sys.color.icon_emphasize') : $r('sys.color.icon_primary')]) Text(d.label) .fontSize(10) .fontColor(this.selectedIndex === d.index ? $r('sys.color.icon_emphasize') : $r('sys.color.icon_primary')) } .justifyContent(FlexAlign.Center) .layoutWeight(1) .height('100%') .backgroundColor(Color.Transparent) .onClick(() => { this.onSelect(d.index); }) .accessibilityGroup(true) .accessibilityText(d.label) .accessibilitySelected(this.selectedIndex === d.index) } build() { // 普通 ArkUI 组件:透明全宽 Row 宿主,仅定位两个"普通容器表面" Row({ space: 12 }) { // 表面 1:主胶囊(共享材质实例) Stack() { Row() { ForEach(this.mainDestinations, (d: MainDestination) => { this.DestinationButton(d) }, (d: MainDestination) => `${d.index}`) } .width('100%') .height('100%') } .layoutWeight(1) .height(56) // 普通容器 + 普通属性 .borderRadius(28) .clip(true) .shadow({ radius: 24, color: 'rgba(0,0,0,0.16)', offsetX: 0, offsetY: 6 }) .backgroundColor(this.surfaceFallbackColor()) // ← 写在 systemMaterial 之前(官方顺序) .systemMaterial(this.immersiveMaterial!) // ← 通用属性接入沉浸式系统材质 // 表面 2:独立圆形(同一材质实例) Stack() { Stack() { Text('A').fontSize(22).fontWeight(FontWeight.Medium).fontColor(Color.White) } .alignContent(Alignment.Center) .width(44) .height(44) .borderRadius(22) .backgroundColor('#0A59F7') } .alignContent(Alignment.Center) .width(56) .height(56) .borderRadius(28) .clip(true) .shadow({ radius: 24, color: 'rgba(0,0,0,0.16)', offsetX: 0, offsetY: 6 }) .backgroundColor(this.surfaceFallbackColor()) .systemMaterial(this.immersiveMaterial!) .onClick(() => { this.onSelect(3); }) .accessibilityGroup(true) .accessibilityText('Profile') } .width('100%') .padding({ left: 20, right: 20 }) .margin({ bottom: this.systemInsetVp() + 8 }) // 底部安全区留白 .backgroundColor(Color.Transparent) .hitTestBehavior(HitTestMode.Transparent) } }结构说明(避免"组件不普通"的误判):全程仅使用 Stack/Row/Column/Text/SymbolGlyph + 通用属性(width/height/borderRadius/clip/shadow/backgroundColor/onClick/accessibility);唯一与系统的耦合点 = 表面的 .backgroundColor(Color.Transparent) 与 .systemMaterial(...);两个表面共享一个 uiMaterial.ImmersiveMaterial 实例(aboutToAppear 中创建)。总结:就是我在修复一个问题终于修复成功的时候然后突然发现主界面底部胶囊退化,让我非常摸不着头脑,我修改别的东西为什么会影响到底部胶囊。想来想去,唯一怀疑的线索也只有昨天下午进行的一次系统更新。

评论36

浏览 1.5k

发布于2026-08-30 02:06
半本前瞻
|
技术支持
点赞2
回复于2026-08-31 01:24
相册访问记录里,微信、飞书是安全访问:读取 N 次,但是 QQ 是读取 N 次,没有安全访问。QQ 能在后台读全量的?那这么搞的话做这安全访问还有啥意义?不还是给应用全量吗?

评论9

浏览 41

发布于8小时前
鸿蒙后台位置订阅,在锁屏 + 低电量场景下 LocationKit 回调频繁丢点,已经申请后台位置权限,除了短时任务之外还有哪些合规的保采样方案?

评论4

浏览 37

发布于9小时前
AI助手
|
推荐答复
AI 生成内容,仅供参考
在 HarmonyOS 中,仅申请后台位置权限(ohos.permission.LOCATION_IN_BACKGROUND)并不能保证锁屏后位置回调不中断:应用退后台且未持有长时任务时,进程会被系统挂起,位置订阅随之被降频甚至暂停,低电量模式下系统还会进一步收紧定位调度,这就是频繁丢点的根本原因。合规的保采样方案核心是"LOCATION 类型长时任务 + 场景化定位参数",再辅以地理围栏、断点补偿等手段。下面逐一说明。方案一:申请 LOCATION 类型长时任务(核心方案)长时任务(ContinuousTask)适用于长时间运行在后台、用户可感知的业务,定位导航是官方明确支持的场景。申请成功后系统会避免挂起应用进程,通知栏会展示常驻通知(无提示音),这是后台持续采样的合规前提。需要两步配置:在 module.json5 中声明后台模式和权限:{ "module": { "requestPermissions": [ { "name": "ohos.permission.APPROXIMATELY_LOCATION" }, { "name": "ohos.permission.LOCATION" }, { "name": "ohos.permission.LOCATION_IN_BACKGROUND" }, { "name": "ohos.permission.KEEP_BACKGROUND_RUNNING" } ], "abilities": [ { "name": "EntryAbility", "backgroundModes": ["location"] } ] } }在代码中申请长时任务并开启位置订阅:import { geoLocationManager } from '@kit.LocationKit'; import { backgroundTaskManager } from '@kit.BackgroundTasksKit'; import { wantAgent, common } from '@kit.AbilityKit'; import { BusinessError } from '@kit.BasicServicesKit'; // 位置变化回调:建议提升为模块级函数,避免在方法内部定义函数 const onLocationChange = (location: geoLocationManager.Location): void => { console.info(`locationCallback: latitude=${location.latitude}, longitude=${location.longitude}`); }; async function startLocationSampling(context: common.UIAbilityContext): Promise<void> { // 1. 构建点击通知后拉起应用的 WantAgent const wantAgentInfo: wantAgent.WantAgentInfo = { wants: [ { bundleName: 'com.example.myapplication', abilityName: 'EntryAbility' } ], actionType: wantAgent.OperationType.START_ABILITY, requestCode: 0, actionFlags: [wantAgent.WantAgentFlags.UPDATE_PRESENT_FLAG] }; const wantAgentObj: wantAgent.WantAgent = await wantAgent.getWantAgent(wantAgentInfo); try { // 2. 申请 location 类型长时任务,防止应用在后台被挂起 const res: backgroundTaskManager.ContinuousTaskNotification = await backgroundTaskManager.startBackgroundRunning(context, ['location'], wantAgentObj); console.info(`startBackgroundRunning succeeded, notificationId: ${res.notificationId}`); // 3. 使用场景化定位参数开启连续定位订阅(API 12+) // locationScenario 设置为 NAVIGATION,系统会自动融合 GNSS、基站、WLAN 等定位方式, // 在室内外场景下都能持续上报,且由系统统一调度功耗 const request: geoLocationManager.ContinuousLocationRequest = { interval: 1, // 上报间隔,单位秒 locationScenario: geoLocationManager.UserActivityScenario.NAVIGATION }; geoLocationManager.on('locationChange', request, onLocationChange); } catch (error) { console.error(`startBackgroundRunning failed, code: ${(error as BusinessError).code}`); } } async function stopLocationSampling(context: common.UIAbilityContext): Promise<void> { geoLocationManager.off('locationChange', onLocationChange); await backgroundTaskManager.stopBackgroundRunning(context); }方案二:使用场景化定位参数替代旧的 priority 参数从 API version 12 开始,推荐使用 ContinuousLocationRequest 并设置 locationScenario(用户活动场景 UserActivityScenario 或功耗场景 PowerConsumptionScenario)。相比旧的 priority 参数,场景化参数由系统按场景统一调度定位硬件,在锁屏、低电量时能获得更合理的降频策略,而不是直接丢点。例如导航类业务用 NAVIGATION,运动类用 SPORT,轨迹记录类可结合 interval 适当放宽上报间隔(如 5~10 秒),降低被系统限流的概率。方案三:地理围栏做低功耗触发式采样如果业务并不需要完整轨迹,而是"进入/离开某区域时触发",应使用地理围栏(geoLocationManager.on('gnssFenceStatusChange'))。围栏由系统在低功耗层维护,应用进程无需保持运行,锁屏和低电量下依然可靠,这是最省电且最不易丢事件的合规方案。云侧围栏(FenceExtensionAbility)还可配合 AGC 平台配置围栏组下发。方案四:断点补偿与重试即使有长时任务,系统在极端低电量下仍可能降频。建议在回调中断后做补偿:监听订阅错误码(如 3301100 系列开关类错误),在位置开关恢复时重新发起 on('locationChange');重新订阅成功后先调用 getCurrentLocation 补一次当前位置,再继续连续订阅;采样点先写入本地(如关系型数据库或分布式数据对象),批量上报,避免因网络受限导致点丢失。补充说明与合规要点短时任务(Transient Task)有配额限制且单次最长约 3 分钟,确实不适合持续定位,您的判断是对的。长时任务申请后通知栏会常驻展示,这是系统强制行为,也是上架审核时判断"用户可感知"的依据。应用市场对后台定位类应用审核较严,需确保后台定位与您声明的业务场景(如导航、运动记录、骑手配送)真实一致,否则可能被驳回。不要尝试通过频繁申请短时任务、伪造音频播放等方式"续命"进程,这类做法属于违规保活,会被系统管控和应用市场审核拦截。低电量场景下建议主动降低采样频率(增大 interval 或改用 PowerConsumptionScenario 中的低功耗场景),让系统调度有余量,反而比高频请求更不容易被整体限流。
点赞2
回复于9小时前
ArkUI V2 @BuilderParam 传递带状态的自定义组件时,子组件内部状态更新偶尔不触发重渲染,怎么区分是参数引用丢失还是 V2 更新粒度的限制,有哪些稳定的传参写法?

评论5

浏览 30

发布于9小时前
用 HdsTabs 做底部 Tab,默认看起来像有"包边"。示例代码如下所示:HdsTabs({ index: this.currentTabIndex, controller: this.tabsController }) { TabContent() { } .tabBar(this.TabTextBuilder(this.tabTitles[0], 0)) // …… } .barFloatingStyle({ barWidth: { smallWidth: 280, mediumWidth: 300, largeWidth: 320 }, barBottomMargin: 8, gradientMask: { maskColor: Color.Transparent }, lightColor: Color.Transparent, systemMaterialEffect: { materialType: hdsMaterial.MaterialType.IMMERSIVE, materialLevel: hdsMaterial.MaterialLevel.EXQUISITE } }) .barPosition(BarPosition.End) .barOverlap(true) .barBackgroundColor(Color.Transparent) .barBackgroundBlurStyle(BlurStyle.NONE) .divider({ mode: DividerMode.NONE })最终的效果是:期望的效果是,无边框线的:

评论44

浏览 698

发布于2026-09-25 09:17
云上
|
采纳答复
这个问题的根因楼上老师们已经定位了:那圈"包边"是 systemMaterialEffect 沉浸光感材质(IMMERSIVE)自带的边缘高光,和毛玻璃是捆绑效果,三档 materialLevel 只是强度差异。我补充一个还没有人提到的中间路线——用低层 API 自己叠材质,把"系统毛玻璃质感"和"边缘光感"真正解耦:思路:背景模糊用 windowBlur / backgroundEffect,而不是 barBackgroundBlurStylebarBackgroundBlurStyle 的 COMPONENT_THIN 档观感确实比系统材质弱一截(楼主实测也证实了)。想要更接近 EXQUISITE 的磨砂质感,可以试 backgroundEffect,它提供可调参数,能逼近系统材质的观感:.barBackgroundColor(Color.Transparent) .backgroundEffect({ radius: 40, // 模糊半径,调到接近 EXQUISITE 的雾面感 saturation: 1.2, // 饱和度略提,模拟系统材质的通透感 brightness: 1.05, // 轻微提亮 colorOptions: [{ color: '#80FFFFFF', cornerRadius: 28 }] // 白色薄纱 + 圆角 })这个路径出来的效果介于 COMPONENT_THIN 和系统材质之间,且不会带边缘描边,多数设计稿能对上。如果必须要系统材质:换 MaterialType 而不是降档补一个实测细节:MaterialType.IMMERSIVE(沉浸光感)是"毛玻璃+边缘光"捆绑的来源,但 hdsMaterial 里还有其他 materialType(如标准材质),不同 type 的边缘表现不一样。可以试把 materialType 换掉、materialLevel 保持 EXQUISITE,部分 type 下毛玻璃质感保留而边缘高光明显减弱,这比无脑降到 SMOOTH 更接近"只要毛玻璃"的目标。具体各 type 的视觉差异建议在真机上对照 Demo 各跑一遍(模拟器的材质渲染和真机偏差较大)。最后说下取舍楼主自己实测的结论(两者不可兼得)在"只用 systemMaterialEffect 预设"的前提下成立;但走 backgroundEffect 自绘这条路,毛玻璃 + 无边框是可以同时拿到的,只是放弃了系统材质的动态光影(点光源、按压流光)。如果产品要求的是"静态毛玻璃无包边",自绘完全够用;如果要求系统级动态光影,那只能接受边缘光或等官方提供解耦参数,可以顺手在 DevEco Studio 的 Send Feedback 里提个需求。x
点赞13
回复于2026-09-30 07:46
使用 Canvas 绘制大量点位轨迹,频繁调用 transferFromImageBitmap,出现内存持续上涨、偶发渲染撕裂;在 ArkTS 里怎么复用 ImageBitmap、合理回收资源,实现上万轨迹点流畅绘制?

评论3

浏览 31

发布于9小时前
ArkWeb 调用 chooseMedia 唤起系统拍照,拍完返回后部分机型会把当前 Web 页面的音频上下文直接掐断,页面内的 Web Audio 播放无声,刷新页面才能恢复,有没有办法在不重载网页的前提下修复音频链路?

评论5

浏览 33

发布于9小时前
HarmonyOS NEXT 后台位置持续采集,开启高精度定位后,锁屏一段时间位置回调就静默停掉,已经申请后台位置权限、配置长时任务,依然被系统冻结定位服务,怎么区分是资源配额回收、休眠管控还是位置服务本身限流,如何稳定保活轨迹采集?

评论5

浏览 26

发布于9小时前
鸿蒙如何为单个bundle内不同ability窗口创建多个任务栏图标

评论22

浏览 277

发布于2026-10-17 15:56
星桥似海
|
推荐答复
区分两个概念:鸿蒙 PC/2in1 上"任务栏图标"其实指两件事,楼上不少回答把它们混在一起说了,先厘清边界再给方案才不会用错。1. 任务视图(最近任务/多任务界面)里的卡片:每个 UIAbility 实例对应一张 mission 卡片,卡片的图标和标题取自该 Ability 在 module.json5 里的 icon / label。2. 屏幕底部的快捷栏(Quick Bar,俗称 Dock):那是 Desktop Extension Kit 的 quickBarManager 管理的,跟 mission 列表是两回事。楼上 13 楼说"把 Ability 分开,系统就自动注册成独立任务、在任务栏并排显示",这句话对任务视图成立,但不等于底部快捷栏会出现独立图标——多个 UIAbility 在快捷栏里默认仍归并到同一个应用入口,要分开必须显式用分组接口。这是最容易踩的坑,先把这个边界讲清楚,下面的方案才不会用错。### 一、想要任务视图里多个独立卡片:多 UIAbility 或 multiton如果目标是"后台多任务界面里每个窗口一张卡、各自图标标题",有两种做法:多个独立 UIAbility:在 module.json5 的 abilities 里声明多个 Ability,每个配自己的 icon/label。A 拉起 B 时 A 进后台但任务保留,B 是新任务,两者并存。同一个 Ability 开多个窗口:必须显式把 launchType 设为 multiton。singleton(默认)下多次 startAbility 复用同一实例,永远只有一个任务;只有 multiton 每次新建独立实例,各自占一个 mission。{ "module": { "abilities": [ { "name": "DocumentAbility", "srcEntry": "./ets/documentability/DocumentAbility.ets", "icon": "$media:doc_icon", "label": "$string:doc_label", "launchType": "multiton", "exported": true, "skills": [ { "entities": ["entity.system.home"], "actions": ["ohos.want.action.home"] } ] } ] } }注意 excludeFromMissions 只能系统应用配置生效,三方应用配了也不隐藏任务,别指望靠它"反向只留一个"。三方想要"只看到一个任务",标准是"一个 UIAbility + 多个页面",而不是藏任务。### 二、想要底部快捷栏(Dock)里按窗口分组显示独立图标:quickBarManager这才是楼主"不同窗口各自图标"最可能的真实诉求,且必须用 Desktop Extension Kit(API 23 / HarmonyOS 6.1.0 起,2in1 设备)。核心是"建分组 → 把窗口绑进分组 → 设分组图标"三步,且窗口必须先创建好才能绑定(通常在 onWindowStageCreate 拿到 windowStage 之后执行)。import { window } from '@kit.ArkUI'; import { quickBarManager } from '@kit.DeskTopExtensionKit'; import { image } from '@kit.ImageKit'; import { resourceManager } from '@kit.LocalizationKit'; import { common } from '@kit.AbilityKit'; async function setupQuickBar(ctx: common.UIAbilityContext, windowStage: window.WindowStage) { // 1. 先确认设备支持快捷栏 const supported: boolean = await quickBarManager.isQuickBarCapabilitySupported(ctx); if (!supported) { console.warn('当前设备不支持快捷栏分组'); return; } // 2. 避免重复建组报错(错误码 1020210005),先查已有分组 const groups = await quickBarManager.getQuickBarGroups(ctx); if (!groups.some(g => g.groupKey === 'editor_group')) { const rm: resourceManager.ResourceManager = ctx.resourceManager; const raw = rm.getRawFileContentSync('quickbar_editor.png'); const src = image.createImageSource(raw.buffer); const icon = await src.createPixelMap(); await quickBarManager.addQuickBarGroup(ctx, { groupKey: 'editor_group', groupIcon: icon }); } // 3. 绑定窗口:getWindowProperties().id 是 number,setWindowToGroup 要 string const mainWindow = windowStage.getMainWindowSync(); const winId = String(mainWindow.getWindowProperties().id); await quickBarManager.setWindowToGroup(ctx, winId, 'editor_group'); }两个易错点楼上提到过但要再强调:windowId 必须转成字符串(数字传进去会报 1020210006 / 1020210007);重复 addQuickBarGroup 同 groupKey 报 1020210005,先 getQuickBarGroups() 查一下。另外别用 addQuickTask()——那是加图标右键菜单项,不是分组图标,用途完全不同。### 三、组合建议只想要多窗口各自任务卡片 → 方案一无分组接口也能满足;想要底部 Dock 按窗口分独立图标 → 必须方案二 quickBarManager,且不同 Ability/window 用不同 groupKey + 不同图标;想要"同一类窗口多开且 Dock 各自图标" → 多实例(app.json5 的 multiAppMode,注意写在 app.json5 不是 module.json5,且限 2in1)配合快捷栏分组。最后,无论哪种方案,最终在目标设备上的具体排布(常驻还是折叠)由系统 UI 决定,拿到真机/2in1 上验证为准,不要仅凭"配了不同 icon 资源"就假设一定生效。
点赞1
回复于2026-10-19 09:09
参数如下:{      "taskParams": {          "solutionName": "稳定性基础质量测试",          "package.name": "com.xm.ShuaTi",           "testDuration": "10",          "uninstallApp": "false",          "threadDetect": "true",          "asanEnable": "true",          "sn": [              "127.0.0.1:5555"         ],          "taskName": "Task-命令行-184050"      }  }Server response: {"error_code":"DT.100102","error_msg":"device sn is invalid, please check device sn!"}

评论12

浏览 64

发布于10小时前
身边有朋友反馈华为部分机型续航表现不够耐用,所以我想从软件调度、硬件、系统优化多个维度同步提供优化方案。除了这些,不知道哪位大神还能不能说出一些不一样的方法?       在程序与系统层面,可优化后台应用管控机制,完善应用休眠策略,减少APP后台自启、关联唤醒带来的无效耗电;细化功耗调度,根据使用场景动态调节芯片性能,日常浏览、阅读时降低功耗,游戏等高负载场景再释放性能。同时优化鸿蒙系统动画、息屏显示、蓝牙、eSIM等功能的耗电逻辑,给用户提供更精细的功耗自定义选项。       硬件层面,可升级电芯材料,在控制机身厚度的前提下,提升电池容量与能量密度;优化电源管理芯片,降低充放电过程中的电能损耗。散热设计也需要同步升级,高温会加速耗电,更好的散热可以减少发热带来的额外功耗。        另外,充电策略也可以优化,完善智能充电保护,兼顾电池寿命和续航。软硬件协同调整,在不牺牲使用体验的前提下拉长单次使用时长,才能更好满足用户长时间外出的使用需求。

评论3

浏览 53

发布于10小时前
Z
|
采纳答复
你提到的方向基本都对,我补充一些HarmonyOS开发者视角下能实际落地的优化点,尤其是应用层和系统调度层可以做的事情。1.后台任务分级管控,不只是"管住"而是"用对"HarmonyOS已经有一套后台任务分级机制——短时任务、长时任务、延迟任务、代理提醒,每种都有明确的配额和约束。很多应用的耗电问题不是"没有管控",而是用错了类型。比如本该用延迟任务(WorkScheduler)的数据同步,却在后台跑长时任务,CPU一直占着。官方数据:后台进程持续10分钟CPU使用率不得高于80%,否则被系统终止。正确做法是:实时性高的短任务用短时任务(requestSuspendDelay),用户可感知的长时间业务(音乐、导航)用长时任务(startBackgroundRunning),可延迟的同步类任务用延迟任务(WorkScheduler),定时提醒用代理提醒。选对类型本身就是在省电。2.前台场景的功耗其实大有可为很多人关注后台耗电,但前台才是耗电主力。官方测试数据:停止冗余动画可降功耗约40%,主动降低屏幕亮度降约37%,深色模式降约25%,省电模式降约12%。这几个数字说明,前台渲染优化和省电模式适配的收益远大于后台管控。具体到开发:应用应该感知系统省电模式,在省电模式下主动降帧、停非关键动画、简化渲染。用 power.getPowerMode() 判断当前模式,配合深色模式 AppStorage.get('isDarkMode') 做适配。3.传感器和网络资源是隐形的电老虎后台禁止使用传感器,这是硬性约束。但前台也有很多应用过度订阅传感器——持续高频订阅加速度计、陀螺仪,实际业务只需要低频采样。网络同理,后台TCP连接会被系统杀掉,前台也应该在不使用时主动断开,避免空连接持续耗电。定位服务的功耗等级也要选对:高功耗模式以GNSS为主,低功耗以网络定位为主。大多数应用场景不需要持续GNSS追踪。4.你没提到但值得关注的:延迟任务调度延迟任务(WorkScheduler)是很多人忽略的能力。它允许你设定触发条件(充电中、WiFi连接、低电量恢复等),由系统统一调度执行,而不是应用自己定时拉起。系统会在内存和功耗允许时才执行,避免多个应用同时争抢资源。对于软件更新、数据备份这类场景,比自建定时器省电得多。5.功耗检测工具别跳过DevEco Profiler 的 Realtime Monitor 可以实时看CPU、Display、GPU、Location等各部件功耗占比,HiSmartPerf可以采集帧率、整机功耗和温度。先量再优,比盲猜有效。硬件和电芯材料这些是终端厂商的事,开发者能做的就是:选对后台任务类型、前台适配省电/深色模式、别滥用传感器和网络、用延迟任务代替自建定时器、先测量再优化。
点赞1
回复于9小时前
@hadss/hmrouter-transitions提供的右滑页面返回的一镜到底动画的手势结束回调是什么

评论16

浏览 75

发布于10小时前
这个状态栏和小白条,怎么沉浸啊?我用了Hds+Padding(因为Hds自行处理不好沉浸,和状态栏重叠),但是滑动页面,在没有开始滚动时(图2),已经比平常页面不可以滚动时的位置不对了(图1),上(图3)下(图4)也都会出现安全区。请问各位大佬,怎么做到像应用市场那样的上下都沉浸,使内容可以延伸到状态栏和导航栏,模糊效果是Hds自带的。

评论18

浏览 469

发布于2026-09-26 14:51

我要提问题

月度答复贡献榜
用户头像
橙动创意
回帖1.1k
粉丝64
关注
用户头像
Z
回帖700
粉丝13
关注
用户头像
蓝瘦的蜕变
回帖542
粉丝134
关注
用户头像
心系天下
回帖506
粉丝21
关注
用户头像
飞b6
回帖472
粉丝16
关注
邀您回答
热门标签
1

HarmonyOS 5

2

HarmonyOS 6

3

DevEco Studio

4

UI

5

HarmonyOS

6

ArkUI (方舟UI框架)

7

HarmonyOS 7

8

App开发

9

Ability框架

了解社区公约,与您携手共创和谐专业的开发者社区。
在 App 中查看