建议广场

YOYO建议部分建议卡片如紫外线强度、穿衣建议等点击进入没有过渡动画,退出又有过渡动画,体验割裂
16 人已参与
支持
反对
充电动画能不能改成自主选择
17 人已参与
支持
反对
🚀 核心构想:在编译阶段,自动将指令按类型分类,给每类指令贴上一个“适配标签”。这个标签描述了这类指令最适合运行在什么状态的核心上——比如温度在什么范围、负载剩余多少、频率在什么区间。当指令进入调度队列时,调度器直接根据标签和当前各核心的实时状态进行匹配,找到最合适的那颗核心,不再需要临时分析指令特征 目前调度器在分配指令到各个核心时,需要实时分析这条指令是什么类型、适合什么样的核心,然后再结合各核心的当前状态做出分配决策。这个过程虽然极快,但如果调度器能提前知道“这条指令适合什么状态的核心”,它就可以直接进行匹配,进一步提升效率。 我的想法是:让编译器在生成指令时就做好分类和标注工作,调度器只需要根据标签去匹配当前各核心的状态,找到最合适的那颗核心即可。 📐 技术原理 第一步:编译时对指令进行归类。 编译器在生成机器码时,会自动分析指令的静态特征,将指令归入不同的类型。比如连续的高密度浮点运算归为“浮点密集型”,频繁的内存读写归为“访存密集型”,简单的逻辑判断和跳转归为“轻量计算型”。 第二步:给每类指令贴上适配标签。 针对不同类型的指令,编译器贴上对应的适配标签。这个
11 人已参与
支持
反对
把过渡动画可以设置的稍微慢一点,避免傻快的感觉
17 人已参与
支持
反对
170版本打断打断动画没有优化,操作快了会延迟,需多次点击才有效果。
32 人已参与
91%
9%
抢购加速能不能自动开启
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%
第一个问题,老生常谈,多任务切换平铺模式无并行动画,极其影响操作,这个问题我之前已经发过视频,截止目前未解决 第二个问题,堆叠模式,清理后台之后会卡顿很久无法立即滑动屏幕,如视频所示 荣耀在过渡动画方面真的是遥遥落后,何时才能优化好?难道真要等到下一个大版本?
72 人已参与
90%
10%
以下结果是在使用三键导航模式下测试的结果 如第一张图平铺模式下测试结果: 1.比如现在你就已经在某一个应用里面,这种情况下使用底下方块键切换到最近任务后台,可以看到这个手机的顶部应用图标和时间这个图标它会缓慢的消失,在它消失之前,你这个最近任务里面是没法快速点击一个张卡片点进去的,或者是滑动卡片的。在你快速操作的时候手感非常卡。他必须要等到手机顶部的图标消失之后,你才能操作。 2.但是你要是从是手机的主页按方块键切换到最近任务,它顶部的应用图标和时间那个图标消失的就非常快,点击卡片的时候手感就快一些。 3.平铺模式下有一个好处就是你双击导航的方块儿键,它可以快速的在上一个和现在的应用之间快速切换。 第二张图使用的是堆叠模式: 1.堆叠模式下从最近任务切换到一个应用卡片里面之后,你没法立马点击导航的方块键切换到最近任务,基本是要等待一会才能去继续返回多任务界面,体验很卡。 2. 堆叠模式下没有平铺模式下快速双击方块儿键切换上一个应用的功能。
36 人已参与
89%
11%
破系统,越更新越**,这还断触,经常断触划不动,赶紧优化啊
47 人已参与
支持
反对
核心构想 將MagicOS的核心引擎(性能、影像、通信、电源等)升级为可对话的“专家智能体矩阵”,通过YOYO智能体平台统一协同。让每一项底层技术从“黑盒运行”走向“明盒交互”,用户可随时提问、获得解释、参与优化。 各引擎智能体的核心场景 Turbo X智能体(性能专家) 典型场景:游戏卡顿复盘。用户反馈“上局团战卡了”,智能体调取帧率曲线、CPU/GPU负载与温度数据,回复:“卡顿发生在团战瞬间,GPU峰值负载达98%触发温控降频,已优化渲染策略,下次该场景预计帧率提升12%。 影像引擎智能体(摄影指导) 典型场景:成片问题诊断。用户拍完照片后问“为什么这张脸偏黄?”,智能体分析色温与AI肤色处理参数,回复:“环境暖色灯光影响了白平衡,已为你修正并加入个人偏好,下次类似场景会自动调整。” 通信引擎智能体(网络顾问) 典型场景:连接异常诊断。用户抱怨“为什么连着Wi-Fi却刷不出内容?”,智能体分析信道拥堵与DNS响应,回复:“当前公共Wi-Fi信道拥堵,已自动切换蜂窝数据加速,网络流畅度即刻恢复。” 电源引擎智能体(续航管家) 典型场景:异常耗电溯源。用户反馈“昨晚
28 人已参与
89%
11%
现在动画的响应其实已经挺不错的了,但还是有一些地方可以优化改进,希望采纳。短时间内重复的操作好像会有“内置 CD” 一样无法立刻生效。比如在短时间内连续点击同一个文件夹就会有这种情况。或者重复做上滑退出到后台再点击应用时也会出现无法响应的情况,必须得等“内置 CD ”过完了才能继续响应。
20 人已参与
100%
0%
160版本清理后台应用上滑卡顿问题什么时候能解决
68 人已参与
96%
4%
堆叠后台完全不跟手,反应慢半拍,非常粘手!!!!
62 人已参与
92%
8%
目前清理完后台双击锁屏是不生效的,需要等清理后台动画完成之后才能双击锁屏。这样就显得很不跟手。
38 人已参与
84%
16%
目前清理完后台双击锁屏是不生效的,需要等清理后台动画完成之后才能双击锁屏。这样就显得很不跟手。
31 人已参与
81%
19%
什么时候把平铺的打断动画也优化一下呢,对齐一下堆叠
30 人已参与
87%
13%
简体中文 - China
返回顶部