建议广场

负一屏中进入与退出账号的动画效果生硬,并且纯白界面与负一屏的液态玻璃效果割裂,建议增加一镜到底并适配液的玻璃
17 人已参与
支持
反对
产品经理用脚考虑的用户体验吗,用户都选择使用性能模式了还差你那点电吗?隔三差五下面弹出一块狗皮膏药提示你手机开了性能模式要不要关掉,何意味?不烦吗? 好的设计为用户做减法,烂的设计天天烦用户,荣耀的软件设计天天吵用户
16 人已参与
支持
反对
因为就是更新os11前后玩的原神,感觉更新之后掉卡顿十分明显
20 人已参与
支持
反对
建议取消软件启动时预览动画的应用遮罩,每次点开软件都是白屏和一个大的低分辨率软件图案,很影响观感。
32 人已参与
支持
反对
处理完后第一时间返回桌面滑动没反应,必须等动效完后才行。不连贯 请看视频
19 人已参与
支持
反对
那个下滑浏览朋友圈终于改善了,不会跟之前总是下滑一下还会继续自动滑下去,但是上滑退出应用,立刻下滑还是不行,也是硬控1秒后下滑才能拉出状态栏!希望重视一下!
17 人已参与
支持
反对
更新过os11以后,内存确实大了十几个g,但是yoyo建议的天气无定位地点的天气信息。建议再优化一下。
12 人已参与
支持
反对
用户反馈荣耀手机在横屏播放哔哩哔哩视频时,切换到后台再返回应用切换界面,需要等待1-2秒切换后台动画播放完才能进行操作,建议优化此问题。
13 人已参与
支持
反对
返回动画不会自己回到那一页吗
39 人已参与
支持
反对
部分软件打开时会在屏幕中心显示大号的应用图标,然后进入软件的预设等待界面,大号图标的分辨率很低,相当影响观感,给人一种廉价的感觉。 看见之前的帖子已经提过此类问题,大概是24年,当时的回复是为了确保启动动画统一,但是这实际上并没有起到统一的效果,反而让打开应用出现两次加载页面,显得冗余,让系统显得缺乏美感,难以摆脱网络上对荣耀系统老年化的诟病。其他品牌的手机未遇到过此类问题,应该是可以解决的。 另外,部分软件的字体也和系统不统一,比如淘宝,软件内的字体大多是加粗的字体,看着有点怪。
16 人已参与
100%
0%
荣耀旗舰机干脆做一个极端性能机,出一个跟红魔一样能放开限制完全释放芯片性能的功能,然后藏在设置深处,打开那个设置就能出现一个一键释放性能的按键,玩游戏可以榨干芯片温度墙没有,做到跟红魔一样的性能调度,做到掉皮掉肉不掉帧。
33 人已参与
79%
21%
建议优化应用启动过程中的打断动画和并行动画,提升系统流畅度
30 人已参与
90%
10%
第一个问题,老生常谈,多任务切换平铺模式无并行动画,极其影响操作,这个问题我之前已经发过视频,截止目前未解决 第二个问题,堆叠模式,清理后台之后会卡顿很久无法立即滑动屏幕,如视频所示 荣耀在过渡动画方面真的是遥遥落后,何时才能优化好?难道真要等到下一个大版本?
72 人已参与
90%
10%
除了动画打断的底层逻辑问题,像电话里从电话到联系人再到个人收藏页面的动画太生硬,基本是直接闪现的,还有很多类似的应用如淘宝等购物app,夸克等浏览器,页面的切换都太生硬。还有桌面的文件夹打开时如果应用超过九个,则下面的六个应用显现的方式也很突兀,没有过渡动画
12 人已参与
100%
0%
建议荣耀系统工程师们把系统流畅交互动画功能性,能做全一点,学学友商华为oppo系统有多好用
38 人已参与
92%
8%
Magic OS 11的液态玻璃在点击和滑动时反馈丝滑Q弹但过于规则化,建议在蜂鸟架构中丰富物理模型参数,增加不规则流体拉伸、随机光影折射和非对称回弹效果,提升交互真实感和灵动性。
27 人已参与
81%
19%
这两个情况下的动画效果与l其他系统界面违和感很强 能不能重做一下
16 人已参与
94%
6%
打开文件夹不能立马滑动,还有打开文件夹不能全屏滑动。还有能不能做一下息屏动画和亮屏动画
33 人已参与
85%
15%
最近任务样式“堆叠”创新非常不错,极大提高了寻找效率,点赞👍🏻!但是上划关闭app划程依然过短,感觉划动距离大概只有4-5毫米左右,过于敏感,极容易误关闭app,建议增长上划划程。不信自己看视频。
23 人已参与
70%
30%
170版本新增的拼多多,B站,小红书的打开帖子动画,在搜索页面就没有了,适配的不是很彻底,可以改一下吗,很割裂,在主页有动画,搜索出来的就没有了
29 人已参与
93%
7%
CPU、GPU、NPU、ISP都是多核架构,现在负载上来后调度器容易无限制唤醒多个核心,超出最优数量后,只会造成总线争抢、能效下降。 我的优化思路: 1. 在实验室控制频率不变,给各个核心簇、各个硬件模块测绘「边际核心增加收益数据表」,找到每类场景下边际收益快速衰减的拐点核心数。 ​ 2. 调度器根据当前任务类型查表,动态生成该模块的最大可唤醒核心上限,超过上限的空闲核心直接临时禁用休眠,不让调度器调用。 ​ 3. 调度逻辑分成两步: 第一步:查表锁定本次允许开启的核心总数上限; 第二步:在上限范围内,再对比「升频收益」和「开核收益」,选择最优方案提升性能。 额外增加一个应急兜底:遇到瞬时突发峰值负载,可以短暂临时放开上限一小段时间,避免卡顿。 好处: 从源头杜绝盲目多开核心,总线冲突变少,日常功耗和发热会更低,多核调度更加克制理性。 @性能研发陈立庚 @MagicOS流畅橙子 @性能_阿勇 @MagicOS流畅李同学
24 人已参与
96%
4%
🚀 核心构想:为每个进程动态圈定一组专属的异构核心团队——比如一个CPU大核搭配两个GPU核心和一个NPU核心,让它们协同处理该进程的所有任务。这些核心被绑定在一起,任务分配上相互衔接、互相配合。同时,系统实时监控这个核心团队的平均负载,当负载超过50%时,自动收紧调度策略,把高负载核心的任务平滑迁移到低负载核心上,确保算力资源始终处于最优利用状态 目前Turbo X引擎已经能在场景层面智能分配CPU、GPU、NPU资源。我的想法是更进一步:以每个进程为单位,为它量身定制一组专属的异构核心组合。当用户切换场景时,这些组合随之动态调整。同时,系统自动监控每个组合的整体负载,在负载过高时主动进行内部的任务均衡调度,避免部分核心过载而其他核心闲置。 📐 技术原理 第一步:动态圈定进程专属核心团队。 Turbo X引擎根据当前场景和进程需求,为每个进程圈定一组专属的异构核心组合。比如游戏场景下,为游戏主进程分配两个CPU大核、四个GPU核心、一个NPU核心,让它们协同处理渲染、物理计算和AI增强任务。视频场景下,为视频解码进程分配一个CPU中核、两个GPU核心、一个NPU核心。日常浏览
25 人已参与
92%
8%
一、现有痛点 当前调度多根据负载强度统一升频。 但不同APP、不同核心的升频收益差异极大: 部分场景拉高频率几乎没有性能提升,只会造成无效耗电、轻微发热,属于“无效升频浪费”。 二、优化核心思路:为主流应用建立「频率性能弹性系数库」 利用荣耀现有AI自动化测试能力,对微信、短视频、浏览器、主流游戏等头部高频APP,提前离线批量测试: 超大核/大核/中小核在不同负载下的频率—性能收益弹性系数 简单理解: - 弹性高 = 升频收益大,可放开调度 ​ - 弹性低 = 升频收益极小,主动收敛频率省电 将数据形成可云端更新的弹性系数表,预置进Turbo X调度引擎。 三、解决最大难点:多APP混合后台场景(关键创新) 日常用户经常前台+后台多应用共存,无法全部单独测试。 我的方案无需遍历海量组合,采用交叉系数参考机制: 调度器识别当前前台应用 + 后台驻留应用 自动调取多个APP的弹性系数表 取负载区间交叉重叠的系数作为混合场景调度参考 既不需要成倍增加测试成本, 又能精准适配多任务真实使用场景。 四、双层混合调度(完美兼容现有系统) 1. 主流高
19 人已参与
95%
5%
这个版本的打断动画是真的差劲的要命,比上个版本都差 而且卡顿
25 人已参与
80%
20%
建议magicOS11推送前增加一个动画效果,就是像华为的粒子效果差不多的,那个动画效果感觉很好看
22 人已参与
100%
0%
紫薯布丁紫薯布丁紫薯布丁
42 人已参与
71%
29%
机型是air有时候没有开关屏幕的动画直接亮,非常难受
12 人已参与
100%
0%
清后台后顿一下才能操作就不说了,这怎么信息流滑动都不跟手呢,这Magic8Pro跟手度比一加ACE5Pro都差,真是硬件很强软件很弱
32 人已参与
94%
6%
现在的动画很丝滑但不够“跟手”,现在除了应用的打开动画和返回动画不用等动画完成就可打断,其他很多动画都需要等动画完全结束才能打断动画,或重复执行打开关闭的操作。希望可以优化动画打断的底层逻辑,在任何情况都可以随时随地丝滑地打断动画
47 人已参与
83%
17%
🚀 核心构想:从调度器身上拆出“代码编号器”,以用户单次点击为单位,在点击产生的代码调用过程中,编号器编号与调度器调用同步并行进行 目前的调度器,在响应用户点击时,既要分析“该调用哪些代码”,又要执行“把代码调出来”的动作。两件事串行着做,效率有提升空间。 我的想法是:从调度器身上拆一部分逻辑出来,做成一个独立的“代码编号器”。当用户点击屏幕上的某个按钮时,这个点击会触发一连串的代码调用。编号器负责根据这个点击,提前圈定接下来需要调用的代码模块范围,并按调用顺序编好号。调度器拿到编号后,直接在这个小范围内精确调用代码,不再需要自己从头分析。 关键是:编号和调用是同步并行进行的。 当编号器正在为后续的代码模块编号时,调度器正在同时调用前面已经编好号的代码。两者在同一次点击内部同步推进,互不等待,形成流水线作业。 📐 具体如何工作? 用户点击某个按钮,这个点击触发了一连串的代码调用需求。编号器立刻根据这个点击,快速圈定出需要调用的代码模块范围,并按照调用逻辑的先后顺序,从1开始逐个编号。 编号器一边编号,调度器一边执行。当编号器正在给第3个代码范围编号时,调度器已经在调用第1个
25 人已参与
80%
20%
🚀 核心构想:在应用启动动画这一瞬间,对应用图标图层进行三重增强——分辨率提升至2K、帧率提升至120帧、边缘进行锐化处理,而周围的壁纸背景则保持原分辨率、原帧率。动画结束后,所有图层立即恢复统一渲染。整个过程只需要短短几百毫秒,却能带来强烈的视觉层次感和极致流畅感 目前系统动画在启动时,所有视觉元素(应用图标、壁纸背景)通常是统一分辨率、统一帧率渲染的。这虽然保证了整体一致性,但还有进一步优化的空间。 我的想法是:利用现代GPU分层渲染的能力,在应用图标启动动画这一瞬间,集中所有渲染资源,把图标的视觉质量推到极限,同时保持背景不变。这就像电影中的浅景深效果——焦点内的主体极致清晰、丝滑运动,焦外的背景则柔美模糊,两者对比让动画的视觉冲击力达到最强。 📐 技术原理:三层增强,瞬态生效 第一层:120帧高帧率(动画流畅度)。 应用图标所在的图层,在动画启动瞬间切换到120帧渲染模式,保证运动轨迹极致丝滑。而壁纸背景所在的图层,保持60帧刷新率。因为壁纸本身是静止的,且处于高斯模糊状态,降低帧率不会影响视觉体验。 第二层:2K高分辨率(动画清晰度)。 对动画图标图层应用更高精度的
9 人已参与
100%
0%
1希望文件夹打开或关闭的动画速率可以和应用过渡动效里面的速率保持一致,也就是说,如果调成舒缓,那么打开文件夹的动画速率和打开应用的动画速率要一起变慢,如果调成高效那么文件夹的打开动画速率也要相应的变快。现在应用过渡动效设置,无论如何调整,文件夹的打开速率都是明显慢于应用动画速率的。 2文件夹的打断动画目前仍不是特别丝滑,希望能优化一下动画的打断逻辑,如果要点击文件夹中的应用必须得等文件夹完全打开后才能生效,希望在点击文件夹后立刻点击应用时,能让文件夹的打开动画渐隐并且直接衔接应用的打开动画
20 人已参与
90%
10%
希望可以增加亮屏的动画,由黑屏状态亮屏时突然出现壁纸会比较突兀,可以有缩放渐渐出的动画
10 人已参与
70%
30%
反馈好多不跟手的问题(可以看我反馈的问题),客服只会让我重启清灰,工程师说看了后台日志没有明显报错(卡顿会有报错?sleep1秒也没报错),很少承认有问题去优化的,大部分都是动画的问题,广告吹的上天各种丝滑,实际丝滑只是看到的所谓打断,不打断继续操作就各种问题不跟手,从其他品牌转来后一上手就发现这系统问题太多,下一步手机很可能就不是荣耀了,用户流失是有原因的
25 人已参与
92%
8%
🚀 核心构想:为应用图标、图片、视频等有醒目图标的文件,预先绑定专属的“动效参数包”。这个参数包内记录该文件最常用动画的渲染指令(如启动缩放、转场渐变等)。GPU在渲染动画时,直接读取参数包中的指令执行,不再需要实时计算动画参数,从而提升动画响应速度,让每一次点击都更丝滑流畅。 目前GPU在渲染动画时,需要根据应用或系统的通用指令,实时计算每个文件的动画参数(如起始位置、缩放比例、运动曲线等)。这些计算虽然极快,但如果能提前完成并直接复用,动画响应就能更快一步。 我的想法是:把动画参数的计算工作提前完成,以极小的参数包形式固化在文件旁边。GPU在渲染时只需要查表读取现成的参数,直接执行渲染,省去实时计算的时间。这个设计就像给每个文件提前写好了一份“动画剧本”,GPU拿到文件时,剧本已经在手里了,直接照着演就行。 📐 技术原理 第一步:预生成动效参数包。 系统在手机空闲时,根据文件的图标特征和常见的动画类型,预先生成一份动效参数包。这个参数包不是图片或视频,而是一组精确的数学指令,描述动画的运行规则。例如,一个应用图标从桌面放大到全屏的启动动画,其参数包的内容是:“起始位置坐标
12 人已参与
100%
0%
170版本打断打断动画没有优化,操作快了会延迟,需多次点击才有效果。
32 人已参与
91%
9%
经过上个补丁优化响应有所提升,不过这个高频场景,依旧不连贯,情况如图,再次麻烦工程师优化。
21 人已参与
95%
5%
🚀 核心构想:在编译阶段,自动将指令按类型分类,给每类指令贴上一个“适配标签”。这个标签描述了这类指令最适合运行在什么状态的核心上——比如温度在什么范围、负载剩余多少、频率在什么区间。当指令进入调度队列时,调度器直接根据标签和当前各核心的实时状态进行匹配,找到最合适的那颗核心,不再需要临时分析指令特征 目前调度器在分配指令到各个核心时,需要实时分析这条指令是什么类型、适合什么样的核心,然后再结合各核心的当前状态做出分配决策。这个过程虽然极快,但如果调度器能提前知道“这条指令适合什么状态的核心”,它就可以直接进行匹配,进一步提升效率。 我的想法是:让编译器在生成指令时就做好分类和标注工作,调度器只需要根据标签去匹配当前各核心的状态,找到最合适的那颗核心即可。 📐 技术原理 第一步:编译时对指令进行归类。 编译器在生成机器码时,会自动分析指令的静态特征,将指令归入不同的类型。比如连续的高密度浮点运算归为“浮点密集型”,频繁的内存读写归为“访存密集型”,简单的逻辑判断和跳转归为“轻量计算型”。 第二步:给每类指令贴上适配标签。 针对不同类型的指令,编译器贴上对应的适配标签。这个
12 人已参与
75%
25%
简体中文 - China
返回顶部