建议广场

荣耀手机的慢动作7680功能需要明确具体的上线时间。
16 人已参与
支持
反对
机型是air有时候没有开关屏幕的动画直接亮,非常难受
11 人已参与
支持
反对
现在的动画很丝滑但不够“跟手”,现在除了应用的打开动画和返回动画不用等动画完成就可打断,其他很多动画都需要等动画完全结束才能打断动画,或重复执行打开关闭的操作。希望可以优化动画打断的底层逻辑,在任何情况都可以随时随地丝滑地打断动画
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%
这动效优化还是不行啊,一坨大便,一个个消掉后台之后会停顿很长时间才返回桌面,好好优化一下
29 人已参与
97%
3%
把过渡动画可以设置的稍微慢一点,避免傻快的感觉
18 人已参与
83%
17%
抢购加速能不能自动开启
31 人已参与
90%
10%
应用内转场动画感觉太生硬,速度太快,没有柔和的曲线,能不能让他跟应用图标打开动画一样柔和一点?
15 人已参与
87%
13%
希望工程师后续针对流畅度,续航,网络信号,软件这几点着重优化,少开发些不实用新功能,现在开发的新功能对大部分用户而言,真的用不上,咱老百姓注重实用
32 人已参与
84%
16%
🚀 核心构想:让调度器、内存管理等性能模块具备“记忆属性”,学习Turbo X引擎的调度规律。高频场景下,这些模块能自我调配,Turbo X引擎只需在旁边监督;只有在模块力不从心时,Turbo X才精准介入。从“全程指挥”升级为“监督兜底”,降低调配功耗,提升响应速度 目前的Turbo X引擎是“全程实时指挥”模式——每一次调度决策都由它发出。这保证了精准度,但持续的实时调配也消耗了可观的功耗。 我的想法是:让Turbo X引擎培养一批“徒弟”。在日常高频场景下,徒弟们自己干活;只有在徒弟搞不定时,师傅才出手。这就像学开车——教练不会一直帮你打方向盘,而是在你熟练后只在关键时刻提醒你。 📐 技术原理:记忆、执行、监督、兜底 第一步:形成“肌肉记忆”。 Turbo X引擎在某个高频场景下多次采用相似的调度策略时,性能模块会记录下这些参数组合,形成一条记忆规则。比如“游戏团战时,CPU频率应该拉到这个区间,内存回收策略应该设成这样”。 第二步:自我调配。 下次再遇到相似的场景特征时,性能模块先自己查记忆库。如果命中,直接按记忆中的参数自我调配——这个查表操作极轻量,不增加任何实时
21 人已参与
90%
10%
🚀 核心构想:部署两个Turbo X引擎实例,各自负责不同的系统模块,分工互补,协同作战,实现单位时间内更精细化的全局资源调配 两个引擎在程序上设计为互补关系,各自独立决策,互不争抢。例如,引擎A分管CPU和GPU频率调度,引擎B分管内存管理和I/O调度。两者共享同一个系统状态视图和全局功耗预算约束。 当引擎A在游戏场景下拉高频率以保障帧率时,引擎B会自动在内存和I/O层面寻找节能空间来抹平增加的功耗。反之,当引擎B检测到内存带宽成为瓶颈时,引擎A会主动调整频率策略,避免CPU空转。这种协同不是通过中央协调器强制同步,而是通过共享全局约束和实时状态感知自然实现的。 这种架构不仅限于固定的分工,还可灵活调整。引擎A负责计算密集型任务调度,引擎B负责IO密集型任务调度;或引擎A保障前台应用资源,引擎B限制后台任务资源;或引擎A负责CPU调度,引擎B负责NPU调度。当需要增加新的调度维度时,只需调整分工边界或增加新的引擎实例,无需重构整个系统。 💎 总结 让Turbo X引擎从“单兵作战”升级为“双核协同”。两个引擎模块分工互补,各司其职,共享全局约束,实现更精细化的资源调配。期待
42 人已参与
79%
21%
🚀 核心构想:为每颗CPU核心增加一个“有效负载利用率”评估机制,实时区分核心当前负载中哪些是真正高效执行任务的,哪些是空转等待的。当某颗核心负载占比高但有效利用率低时,自动触发上下文切换或任务迁移 目前调度器在决定是否切换任务时,主要依赖时间片耗尽、任务优先级等宏观指标。但有一个重要的信息维度被忽略了:核心当前的高负载,到底有多少是真正高效执行任务的,有多少是在空转等待数据? 我的想法是:让调度器拥有更精细的感知能力,能实时知道每颗核心的“有效负载利用率”——也就是核心被占用的时间里,真正用于有效执行指令的比例。 📐 技术原理:如何区分“有效负载”与“冗余负载”? 现代CPU内部集成了性能监控单元(PMU),可以实时记录指令处理速度、缓存命中率、内存访问延迟等微观指标。通过这些数据,我们可以精确判断核心当前的工作状态。 · 有效负载:核心正在高密度地执行指令,指令处理速度快,缓存命中率高,内存访问延迟低。此时核心虽然负载高,但工作高效,不应被强制切换。 · 冗余负载:核心虽然被任务占用,但大量时间花在等待数据上。指令处理速度慢,缓存命中率低,内存访问延迟高。此时核心负载高但
14 人已参与
86%
14%
🚀 核心构想:为Turbo X引擎增加一个“频率有效度评估与自优化模块”,让它能像智能手环监测心率一样,实时评估每一次频率拉升的实际效果,并根据反馈持续校准升频策略,越用越聪明 目前的频率调度,通常是“只管拉,不管对不对”——调度器决定升频后,并不知道这次升频是否真正提升了任务处理速度。有时升了频,但性能没提升多少,电却白费了。 我的想法是:给Turbo X装上“智能手环”,让它在每次升频后,自动评估这次升频的“有效度”——性能到底提升了多少。然后,AI根据这个反馈,自动微调后续的升频策略,让每一次升频都物有所值。 📐 技术原理:如何实现? 第一步:利用CPU自带的“体检仪”获取数据。 现代CPU内部集成了性能监控单元(PMU),它能像医院的CT机一样,实时记录CPU的工作状态。我们可以从中读取三个核心指标:指令执行速度(频率拉升后,CPU干活是不是真的更快了)、缓存命中率(CPU需要的数据是否能在高速缓存中找到,还是需要去更慢的内存中等待)、内存访问延迟(CPU等待数据的时间是变短了还是变长了)。荣耀与高通已有的超融核架构合作基础,为获取这些底层数据提供了前提。 第二步
35 人已参与
86%
14%
🚀 核心构想:让SoC的频率调节主动跟随用户的触控操作。手指触碰屏幕时,系统先小幅预升频,消除启动延迟;随后根据任务的轻重,决定是继续大幅拉升频率全力输出,还是快速回落到低位以省电 目前的SoC调频,更多是被动响应CPU/GPU的负载变化。而我的想法是,让系统更主动地去感知用户的触控意图,并以此驱动频率的精准调节。这就像赛车手在入弯前就提前降档补油,而不是等发动机转速掉下来再被动调整。 📐 具体如何实现?—— 一个“两步走”的智能调频策略 第一步:触控瞬间,小幅预升频。 当用户手指触碰屏幕上的应用图标或按钮时,系统立刻将SoC频率从待机或低频状态,小幅拉高到一个预设的“预启动”频率。这个频率足以让系统快速响应,启动应用框架,让用户感觉手机立刻“动”了起来,响应极快。 第二步:任务感知,按需大幅升频。 调度器接收到触控事件对应的具体任务后,会立刻判断这个任务的负载大小。如果任务比较重,比如打开一个大型3D游戏或加载高清视频,调度器会在预升频的基础上,继续将SoC频率拉高到满足任务需求的水平,全力保障性能,确保应用流畅启动。 反之,如果任务很轻,比如只是打开计算器或备忘录,那么调
35 人已参与
69%
31%
上滑到多任务快速切换无响应,需要等待一两秒,希望可以优化一下。
18 人已参与
89%
11%
建议桌面文件夹打开时的动效,参考华为的丝滑,现在太生硬了
18 人已参与
94%
6%
🚀 核心构想:为SoC各模块设定总频率上限,Turbo X根据场景实时调整,并在上限内精细分配每颗核心的频率 现代SoC集成了CPU、GPU、NPU等多个模块,每个模块内部又有多个核心。目前频率调度主要以温度或功耗撞墙后的被动降频为主。 我的想法是:让Turbo X主动为每个模块(CPU、GPU、NPU等)设定一个总频率上限,这个上限根据当前使用场景实时调整。同时,在总上限内,Turbo X精细分配每颗核心的具体频率,让算力分配更加合理。 📐 具体如何实现? Turbo X将设备的总功耗预算和散热能力视为一个“全局资源池”,根据使用场景,为每个模块设定总频率上限,再在总上限内精细分配每颗核心的频率。 手机端: 荣耀可以深度定制Linux内核调度器,直接控制每个核心的频率。游戏场景下,GPU总频率上限提高,CPU大核优先分配高频,小核适度限制。视频播放场景下,CPU总频率上限大幅压缩,GPU适度分配用于硬件解码。日常浏览场景下,所有核心均衡运行,功耗与响应速度兼顾。 笔记本端: 虽然Windows内核是闭源的,但微软提供了公开的电源管理API和硬件驱动接口。Turbo X可以
23 人已参与
87%
13%
🚀 核心构想:指令预分析单元在线程排队时,比较前一条指令与后一条指令的复杂程度变化,贴上“升频”或“降频”的方向标签。同时,AI根据指令流的复杂度波动特征,动态生成频率调节的“布林线”——合理频率的上轨、下轨和中轨。标签指示方向,布林线划定边界,两者协同,让调度器在弹性区间内平滑调频 📐 技术原理 第一步:比较前后指令复杂度,贴上方向标签。 指令预分析单元在线程排队时,扫描相邻指令的复杂程度变化。如果后一条指令比前一条更复杂,就贴上“升频”标签;如果更简单,就贴上“降频”标签。这个标签不要求精确数值,只指示方向,因此生成极快、开销极低。 第二步:AI动态生成频率的“布林线”。 AI根据排队指令流的复杂度波动特征,动态生成三条频率曲线: · 中轨:根据指令序列的平均复杂度,计算出的最合理基准频率。 · 上轨:当指令复杂度波动加剧时,AI自动放宽上限,允许频率有更大的上升空间。 · 下轨:当指令复杂度趋于平稳时,AI自动收窄下轨,让频率在更窄的区间内稳定运行。 AI不是分析历史负载记录,而是直接扫描线程中正在排队的指令流,根据指令复杂度的变化趋势,提前调整频率区间的宽窄。
24 人已参与
71%
29%
应用过渡动效 影响不了 打开软件文件夹速度,想调只能开发者里 动画程序时长调整,但是强行调动画太抽搐,希望能加入调整功能。另外希望加入开启锁屏时震动反馈。
15 人已参与
87%
13%
关于“液态玻璃”,我还有一个动效方面的补充构想。 💧 核心构想:应用打开与退出的“水滴形变”动效 让应用图标不再是机械地弹出和关闭,而是拥有一个完整的、有生命的液态循环过程。 打开应用:用户点击玻璃图标,图标逐渐融化为一颗晶莹的水滴,水滴向四周扩散,如同一滩水渍自然蔓延,最终铺满整个屏幕,成为应用首屏界面。整个过程是渐进的、柔性的形变动画。 退出应用:用户上滑退出,应用界面从边缘开始向中心收缩,如同一张凝固的薄膜重新融化为流动的水渍。水渍继续收缩,聚拢为一颗水滴,水滴冷却,凝固回原本的液态玻璃图标。整个过程是打开动画的完美逆向,形成有始有终的循环。 ✨ UI元素的统一延展 这套动效不仅适用于应用图标。系统中的卡片、通知栏等所有玻璃元素,都应遵循同一套物理规律——展开时如水渍蔓延,收缩时如水滴凝聚,让整个系统成为一个风格统一、充满灵性的数字世界。 💎 总结 让应用的打开与退出拥有完整的生命循环。启动时从图标融化到水渍铺满,退出时从界面收缩到水滴凝固。所有UI元素遵循统一的液态规律,让MagicOS成为一个充满灵性的数字世界。期待荣耀能在这个方向上展开探索! @性能研发陈
42 人已参与
86%
14%
工程师看下,我建议你这个最新版本160的m8pro的堆叠后台动画这个上滑卡片需要划一半甚至超过一半才能关掉,这划动行程太长了,平铺后台就没有这个问题,这前版本的堆叠后台也没有这个样子,这么多版本都一直没改,你突然动这个,太难受了,希望改回来
56 人已参与
84%
16%
160的堆叠后台比较上个版本有点不跟手,希望后期优化
61 人已参与
84%
16%
🚀 核心构想:通过分析线程中正在排队的指令,提前预判应用即将增加或减少多少活动空间,Turbo X据此动态调整各应用的内存配额 目前手机的内存管理,通常是在内存压力已经出现后才被动应对——系统发现内存不够了,才开始回收或压缩后台应用。这种方式属于事后补救,用户有时会感知到卡顿或应用被杀。 我的想法是:让Turbo X引擎提前知道每个应用接下来会需要多少内存。当指令预分析单元在线程中看到大量内存分配指令时,它预判“这个应用接下来需要更多活动空间”。当它看到内存释放指令时,预判“这个应用的活动空间即将缩减”。Turbo X根据这些预判,提前、主动地调整各应用的活动空间配额,不需要等待系统报告内存压力。 📐 具体如何实现? 第一步:从排队指令中捕捉内存活动信号。 当指令预分析单元在线程中看到连续的内存分配指令时,它预判当前应用即将需要更多活动空间。当它看到内存释放或缓存清理指令时,预判当前应用的活动空间即将缩减。 第二步:Turbo X提前调整配额。 根据预判信息,Turbo X主动为即将需要更多内存的应用预留活动空间,同时适当压缩其他后台应用的活动空间——压缩缓存、限制非活跃数据
23 人已参与
87%
13%
怎么更新后堆叠尝鲜版感觉好生硬啊???比之前难用多了...我不需要尝鲜...谢谢...改回去吧
31 人已参与
87%
13%
麻烦认真优化一下可以吗 总有莫名其妙的掉帧
28 人已参与
93%
7%
手头有m8rsr和v6两部手机 同样升级了160,m8rsr后台任务栏单独上滑关闭时卡顿,上滑一次卡一下 再上滑一下才可以 v6未有此问题
26 人已参与
92%
8%
用户更新了荣耀的最新系统后出现了卡顿掉帧的情况,频率特别高,尤其是上划屏幕清理后台的时候,特别影响使用体验,虽然是提前升级尝鲜,但是也不至于有这么大的问题,询问这个问题以后是否会解决。
32 人已参与
84%
16%
希望后面可以做成手动长期打开抢购加速,发现打开抢购加速后网速和手机的反应能力都有加强,效果明显
15 人已参与
87%
13%
平铺的比之前还愣了,而且感觉很明显:上滑后必须等软件名称出来(这个过程比较久感知明显)才能有后续操作
49 人已参与
90%
10%
最近任务样式“堆叠”创新非常不错,极大提高了寻找效率,点赞👍🏻!但是上划关闭app划程依然过短,感觉划动距离大概只有4-5毫米左右,过于敏感,极容易误关闭app,建议增长上划划程。不信自己看视频。
23 人已参与
70%
30%
简体中文 - China
返回顶部