建议广场

一句话建议: 系统学习用户打断动画的习惯,在动画播放的“黄金时间窗口”内,提前预测用户是否要打断,让操作更跟手。窗口外不预测,避免干扰正常使用。 一、用户的困扰 很多用户都有这种体验:动画还没播完,点下一个操作没反应,感觉像被“硬控”了。手速快一点,就要等动画播完才能操作,不够跟手。 二、根因在哪 现在系统要等手指移动超过一定距离,才判定为“滑动”或“打断”,然后才响应。这个判定需要时间,用户感觉慢半拍。 三、方案:黄金时间窗口 + 智能预测 1. 学习用户的打断习惯 系统记录用户平时在哪些位置、什么时机、用什么手势打断动画,逐渐学习每个人的习惯。 2. 找到“黄金时间窗口” 用户打断动画有自然反应时间: · 动画刚开始:用户还在看,来不及反应,不预测。 · 动画中期:用户开始决定要不要打断,最可能出手,在这个窗口内激活预测。 · 动画后期:动画快播完了,用户通常放弃打断,不预测。 每个场景的窗口不同,系统自动学习调整。 3. 窗口内精准预测 在黄金窗口内,如果手指触碰了用户习惯的打断热区,并且有明确的方向意图,系统就高置信度判定“用户要打断”,提前通
27 人已参与
81%
19%
一句话建议: 在蜂鸟架构基础上,增加一个全局动画状态机,统一管理所有系统UI动画的状态。触控打断时,状态机直接切换状态,而不是让每个动画各自“取消再启动”。目标是让文件夹、通知栏、多任务、控制中心等所有场景都支持并行打断。 一、用户的困惑 很多荣耀用户都有同感:动画还没播完,点下一个操作没反应,像被“硬控”了。文件夹打开时不能滑动,通知栏下拉时不能点别的,返回桌面时不能呼出控制中心。手速快一点,就要等动画播完才能操作。 目前只有多任务堆叠等少数场景支持并行打断,大部分场景仍然“不支持打断”。 二、根因在哪 现在每个系统动画各自为战。动画A在跑,触控来了,动画A要先“取消自己”,再让动画B“启动自己”。这两步是串行的,中间有间隙,用户就感觉卡了一下。 而且每个场景都要单独写打断逻辑,工作量大,覆盖不全。 三、方案:全局动画状态机 1. 统一注册 所有系统UI动画启动时,向状态机注册:当前状态、能不能打断、打断后切到哪个状态。 2. 统一决策 触控事件到达时,状态机立刻判断:当前动画能不能打断?打断后切到哪个状态?决策是毫秒级的。 3. 状态切换代替“取消+启动”
30 人已参与
93%
7%
如题,现在这动画太僵硬了,强烈建议优化。
70 人已参与
96%
4%
建议荣耀系统加入上下滑动到底和到顶的触感反馈,就像目前资源库这种。文件夹动画再优化快点,从用荣耀以来明显感觉打开比收拢慢
18 人已参与
89%
11%
一句话建议: 在实验室调校阶段,引入一个AI协同调校模型。工程师调整SoC参数时,模型自动推荐电源管理芯片、E2能效芯片、C3通信芯片、H1影像芯片、触控IC、显示驱动等外挂芯片的配套参数,整组一起测试、一起优化,不再逐块芯片反复迁就。 一、痛点 现在手机里芯片越来越多:SoC、电源管理芯片、E2能效增强芯片、C3通信芯片、驭光H1影像芯片、触控IC、屏幕驱动芯片……它们各管一摊,但实际使用时互相影响。 传统调校模式是:先把SoC调好,再逐个调外挂芯片去适配SoC。问题是: · SoC调完后,外挂芯片可能要反复迁就,耗时耗力。 · 各芯片由不同团队开发,局部最优不等于全局最优。 · 调完一轮后,发现SoC和外挂芯片配合不好,又要回头改SoC,来回折腾。 · 电源管理芯片如果没和SoC调度同步,容易出现“频率上去了、电压没跟上”的能效浪费。 二、方案:AI跨芯片协同调校模型 1. 建一个实验室调校大模型 把荣耀各产品线的定位和调校目标写进模型,模型不是瞎猜,而是按荣耀的目标函数去搜最优参数组合。 2. 学习历史调校记录 每次工程师调完SoC和外挂芯片,记录:
17 人已参与
82%
18%
荣耀600元气版系统动画过渡效果调到最快还是反应慢 ,希望优化
18 人已参与
78%
22%
退出应用快速切后台动画会卡掉,灵动胶囊也一闪一闪的,建议优化
33 人已参与
94%
6%
一句话建议: 蜂鸟超感知调度已经实现了系统侧的页面级资源倾斜。本建议在此基础上,聚焦两个它还没覆盖的缺口:一是推动应用在页面不可见时主动停止定时器、动画循环等系统管不了的工作;二是把调度粒度从“页面级”推进到“视口级”——用户滑到哪,资源就跟到哪。 一、蜂鸟已经做了什么 蜂鸟超感知调度引擎已经能识别用户当前正在交互的页面,并把CPU、GPU、网络资源向这个页面倾斜。系统侧“少给不可见页面资源”这件事,已经做到了。 二、还没做到的两个缺口 缺口一:系统管不了应用内部的定时器和动画循环 系统能降低不可见页面的调度优先级,但没法强制应用停止内部的setInterval、requestAnimationFrame、后台轮询。只要应用不主动停,这些工作就会持续触发,持续消耗资源。华为开发者文档已明确要求应用在页面不可见时必须主动停止动画和定时器,说明系统侧确实管不了。 缺口二:页面级粒度不够细 一个长页面可能有十几屏内容。用户只看到其中一屏,但整个页面都在占用资源。系统目前只能做到“这个页面可见,给它资源”,做不到“用户看到哪一屏,就给哪一屏资源”。 三、方案:视口级资源调度 1
17 人已参与
94%
6%
用户建议荣耀考虑为折叠屏手机安排内屏外屏贯通的动画效果,认为该效果很不错。
29 人已参与
93%
7%
一、痛点 手机SoC内部,CPU超大核、大核、小核、GPU、NPU访问不同内存通道的延迟各不相同。但现有内存分配是“就近随便放”,数据可能被分配到离使用它的核心最远的通道上。用户感受到的“偶尔卡一下”,很多时候不是算力不够,是数据“住得太远”,核心每次访问都要跑长途。 二、具体方案 开发一套NUMA感知的内存调度机制,实时感知SoC各核心簇的数据访问特征,动态调整数据在物理内存通道中的分布,让高频访问的数据主动“跑”到离使用它的核心最近的地方。 核心逻辑: · 实时监测:追踪每个核心簇的内存访问模式,识别热点数据页 · 亲和性映射:将热点数据页的逻辑地址映射到离目标核心簇最近的物理内存通道 · 动态迁移:在后台将“住得远”的热点数据迁移到“近”通道,按需渐进,不阻塞前台 · 闭环优化:持续学习用户使用习惯,不同场景下为不同核心簇预置最优数据布局 @HONOR2608234508028 @MagicOS流畅橙子 @性能_阿勇 @MagicOS流畅李同学
15 人已参与
93%
7%
在主屏幕上向下滑动时,会出现一个搜索菜单,方便您查找和搜索应用程序。但是动画看起来杂乱廉价。当你从该界面滑出并再次向下滑动到主屏幕时,必须等待 1-2 秒才能识别你的滑动操作,这令人沮丧。我建议添加更具弹性的动画效果,并使其支持并行动画,从而使整个系统看起来更加协调统一。
22 人已参与
86%
14%
桌面文件夹打开的动画速度太慢了,如果调成 0.5 又太快,如果有 0.75 的选项就完美了
11 人已参与
82%
18%
根据自己的爱好,可以选择加快动画过渡时间或者正常速度。
17 人已参与
94%
6%
一句话建议: 用轻量视觉模型识别“小程序加载、页面跳转”这类UI特征,结合系统已有的网络状态,提前给Turbo X发场景提示,让它提前准备调度预案,减少瞬时卡顿。 一、现状:Turbo X反应快,但有时“看到得晚” Turbo X已经能根据进程、CPU/GPU负载做预测。但有一个盲区: 在同一个APP里打开小程序、跳转网页时,进程名不会变,CPU负载也还没涨上来。调度系统要等负载起来才知道“要忙了”,这时候卡顿已经发生了。 小程序加载转圈,通常分两类原因: 1. 网络/服务器拥堵; 2. 本地页面渲染、JS执行带来瞬时高负载。 网络问题调度优化不了,但本地渲染负载可以提前准备。 二、方案:让视觉模型当“副驾”,提前报路况 用MagicGUI能力蒸馏出一个轻量视觉模型,后台低功耗运行,只识别小程序加载动画、页面跳转这类UI特征。 只有识别到加载动画,并且置信度达标,才去读系统已经缓存好的网络状态,做联合判断: · 网络差:判定卡顿来自网络,不向Turbo X发任何调度提示; · 网络好:判定即将出现本地瞬时渲染负载,异步给Turbo X发一个简短场景标记。 Turbo
32 人已参与
100%
0%
建议加入vivoOS6系统的逐层飞入进入桌面动画,或者可以再加入像苹果系统的进入桌面动画那样回弹动画,回弹动画要根据上滑力度和速度来改变回弹动画
22 人已参与
100%
0%
在底部按钮之间加入滑动特效
40 人已参与
93%
7%
能不能把那个打断动画做的更好一点,打断的时候,要么点不到,要么就是老是返回主界面
35 人已参与
86%
14%
第一,动画是主流厂商最差的,目前下拉控制中心的动画很烂,几乎没有任何过渡动画,参考友商华为,OPPO以及小米,下拉控制中心都做了卷帘渐近出现的动画。控制中心和通知中心左右滑动切换也没有任何过渡动画,及其生硬,参考华为,vivo的上下阶梯式动画和小米,OPPO的摆动动画;桌面文件夹打开的动画也没有友商那种飞入飞出的动画那么丝滑;其次,整个系统大量地方缺失并行和打断动画,平铺后台目前没有任何优化,非常卡手,堆叠后台横屏卡手,底部左右滑动切换应用后不能立即在应用内部上下滑动,硬控两秒。负一屏从应用或者卡片退出后也不能立即进行下一步操作,比如左滑退出负一屏或者在负一屏上下滑动,依然硬控两秒,缺失负一屏退出应用到下一步操作之间的并行动画;应用退回桌面下滑全局搜索也会硬控两秒,还有很多数不清的地方硬控,导致用户感觉荣耀系统不跟手,不丝滑。 第二,细节是主流最差的,完全不注重细节,控制中心和通知中心顶部的一刀切,别的厂家早就是模糊过渡了,就荣耀还是一刀切,直到现在好像才说快解决控制中心顶部一刀切了;负一屏的卡片适配的打断和并行动画,并没有覆盖所有卡片,包括设备电量,快递等卡片都没适配
34 人已参与
94%
6%
用户建议荣耀新系统增加粒子特效。
15 人已参与
80%
20%
可不可以用心打磨一下系统动画,模仿一下oppo的最新系统的动画!
26 人已参与
100%
0%
一、现有问题 目前系统调度主要优化APP线程资源,但忽略了调度器本身的算力开销: 1. 游戏、快速滑动、多任务切换时,调度任务极度密集,若调度器运行在小核,会产生隐形调度延迟,造成跟手度波动、细微掉帧。 ​ 2. 看书、静态浏览、待机低负载场景,调度器仍可能占用大核,造成不必要耗电。 ​ 3. 调度器需要升核提速时,相邻空闲核心常被APP线程占用,只能远距离跨核迁移,导致缓存失效、迁移抖动、响应变慢。 ​ 4. 系统时间片固定不变,无法适配高交互、低静态等不同场景,无法同时兼顾流畅和省电。 二、优化方案建议(基于蜂鸟感知+Turbo X现有框架) 1. 根据调度密集度,动态升降调度器核心与频率 实时监测系统任务切换、线程新建销毁频率: - 高密集场景(游戏、滑动、多任务):自动将调度器迁移到大核、拉高频率,消除调度自身瓶颈,提升触控跟手度。 ​ - 低负载场景(阅读、静态页面、待机):自动切至小核降频运行,降低空载功耗。 2. 核心创新:邻核优先迁移 + 邻核智能预留 为解决调度器迁移卡顿、跨核开销大的问题: - 调度器迁移优先选择物理相邻核心,缓
33 人已参与
91%
9%
如题
21 人已参与
81%
19%
文件夹打开的瞬间,是没有办法往右滑动,必须等动画完全结束,才能往右滑动,我之前的华为手机是可以的,就是点开文件夹的瞬间就可以往右翻页
14 人已参与
93%
7%
有卡顿。
19 人已参与
100%
0%
从应用界面滑出时,它会缩小成图标,但在最后几秒会突然跳动一下,感觉像是“锁定”在了某个位置。请观看视频。
19 人已参与
89%
11%
动效方面有点差还有很大的进步空间 1.一镜到底的动画不够全场景,二级页面就没有一镜到底了 2.系统各个地方回弹不够(特别是应用打开关闭) 3.上滑卡片、图标、通知卡片,圆角不够圆润 4.并行动画效果没感觉到,不知道是不是没有 总结:整个系统动效没有让我感觉到一体性,果冻版的回弹,没有duangduangduang的感觉
48 人已参与
90%
10%
我建议在锁屏和主屏幕弹出通知时,添加液态玻璃的抖动动画,使它们看起来更有Q弹效果。
41 人已参与
98%
2%
在现在安卓系统百家争鸣的情况下,荣耀就拿出这种动画水平和流畅度,还好意思说是最强玻璃效果,真是贻笑大方
36 人已参与
97%
3%
横屏动画啥时候优化?
33 人已参与
91%
9%
有些弹出窗口和动画缺乏“流畅感”,有时感觉像塑料一样。打开控制中心不会像液体一样弹跳和抖动,从控制中心滑动到通知中心也不会。请记下oppo、vivo、iOS和HyperOS。 尤其是按住应用程序菜单时,感觉一点也不像液体,反而像塑料一样。
30 人已参与
97%
3%
一句话建议: 在TurboX里增加一个独立“调度规划引擎”,不改原生调度器,专门给排队线程提前预约合适的核心,减少乱迁移和能效抖动。 一、痛点 游戏、多线程并发等重载场景下,线程一多就会排队。原生调度实时决策,容易来回迁移,导致瞬时发热、帧率波动,而且相似场景会反复出现。 二、方案 1. 独立模块:和TurboX类似,与原生调度器分开,只做预调度建议。 2. 线程级预约:不给每条指令预约,只给排队线程预约接下来短时间窗口内的核心。 3. 实时同步:调度器分配线程后,把“分到哪个核”告诉规划引擎;规划引擎更新预约表,避免预约冲突。 4. 优先低负载核:预约时优先选负载低、温度低、频点合适的核心。 5. 预约账本:每颗核心记录“正在运行负载 + 有效预约 + 系统保留”。按优先级、预计时长、算力需求折算。超过安全阈值,标记为“预约饱和”。 6. 分级饱和:轻度饱和只接高优先级线程,重度饱和只接关键线程,普通线程交给原生调度。 7. 预约有效期:超时、结束、取消后自动释放,防止核心“假爆满”。 三、工程兜底 · 只在游戏、多线程重载场景开启,轻载关闭。 · 冲突时原生调度优先,
25 人已参与
96%
4%
能不能把开关应用的动画做一个新的样式出来,就比如类似某些页面按钮点击后弹出二级菜单的液态玻璃灵动效果,图标像水滴一样Q弹,感觉会很好看
24 人已参与
92%
8%
建议出个类似于OPPO ColorOS17的渐进式运动的动画效果 当通控界面切换时,各种界面元素会随着手势滑动位置,力度与速度渐进呈现,也希望在此基础上再加入类似于果冻的q弹效果
24 人已参与
92%
8%
痛点 当前调度分配核心,大多只看线程负载大小。 但有些高负载线程,频繁访问内存、缓存命中率很低:就算扔到大核,大部分时间都在等内存数据,大核算力空转,白白耗电,提速效果却很有限。 反过来,有些线程缓存命中率高、内存等待少,指令可以持续跑满,放到大核就能快速完成,整体反而更省电。 优化思路 TurboX在分配核心时,不只看负载,额外读取缓存命中率、内存访问延迟两个指标,提前算出临界点: 1. 线程缓存命中率低、内存访问延迟高 → 优先分配中核。大核算力会被内存等待卡住,提升很小,中核就能完成任务,功耗更低。 ​ 2. 线程缓存命中率高、内存访问延迟低 → 优先分配大核。指令可以持续执行,大核快速跑完,缩短任务时长,综合功耗反而更优。 临界点由荣耀提前做大量真机实验标定,固化参考阈值;运行时实时读取硬件性能计数器的数据来判断。 好处 - 减少大核“空转耗电”,游戏、多任务场景,在不损失流畅度前提下压低峰值功耗、控制发热。 ​ - 调度决策更贴合真实硬件瓶颈,而不是单纯凭线程负载判断。 @HONOR2608234508028 @MagicOS流畅橙子 @性能
22 人已参与
100%
0%
能不能加一个横屏打断动画
19 人已参与
89%
11%
一句话总结: 在游戏、多线程等重载场景里,TurboX 用“本地调度习惯 + 云端同机型数据”提前判断哪些状态点容易能效下滑,临时屏蔽容易拖后腿的调度策略,让调度提前绕坑,减少发热和帧率波动。 一、要解决的痛点 原生调度在游戏、多线程并发这类负载突变场景下,可能在特定状态点做出不够优的调度选择。结果就是功耗和性能忽高忽低,出现瞬时发热、帧率波动。更麻烦的是,这类问题往往会在相似场景下反复出现。 这里说的“能效下行”,简单理解就是:更费电、更容易热,性能还容易掉。 二、TurboX 怎么做 核心思路:不等抖动发生再补救,而是提前预判、事前避坑。 1. 本地学习:学习这台设备过去的调度行为习惯。 2. 云端汇总:汇总大量同机型用户在同场景下的运行数据。 3. 找风险点:提前预测哪些系统状态点容易发生能效下行。 4. 提前推演:在到达这些点之前,模拟哪些调度策略可能造成能效下滑。 5. 临时拉黑:把这些高危策略临时加入黑名单。 6. 调度避坑:调度决策时避开黑名单,从剩余可选方案里挑更合适的动作。 可以理解为:原生调度仍是主司机,TurboX 是提前看路况的副驾,快到容易堵车、打滑
16 人已参与
100%
0%
就是说这种粒子消散效果真的感觉好好看。
14 人已参与
86%
14%
我觉得可以在这些地方优化一下动效,要不然实在是太僵硬了一点都不 q 弹
13 人已参与
100%
0%
什么时候把平铺的打断动画也优化一下呢,对齐一下堆叠
30 人已参与
87%
13%
简体中文 - China
返回顶部