建议广场

部分软件打开时会在屏幕中心显示大号的应用图标,然后进入软件的预设等待界面,大号图标的分辨率很低,相当影响观感,给人一种廉价的感觉。 看见之前的帖子已经提过此类问题,大概是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%
这动效优化还是不行啊,一坨大便,一个个消掉后台之后会停顿很长时间才返回桌面,好好优化一下
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%
简体中文 - China
返回顶部