建议广场

170版本新增的拼多多,B站,小红书的打开帖子动画,在搜索页面就没有了,适配的不是很彻底,可以改一下吗,很割裂,在主页有动画,搜索出来的就没有了
29 人已参与
93%
7%
一、问题背景(现有机制的微小瓶颈) 目前 MagicOS 的系统动画、滑动回弹、惯性动效,全部由 CPU 逐帧计算、逐帧生成渲染指令。 即使蜂鸟引擎已经独立线程优化,但依然存在两个无法彻底解决的微小短板: 1. 每一次屏幕刷新(VSYNC),CPU 都必须重复计算动画进度、坐标、透明度、缓动数值,长期占用渲染线程资源。 ​ 2. 一整段滑动动画仅使用单一套物理公式拟合全程,拖拽、惯性、回弹三种不同运动规律无法完美适配,极限场景下会有轻微曲线不够细腻、手感一致性偏差的问题。 这也是极少数场景下会出现微顿挫、滑动收尾不够丝滑、频繁手势打断响应延迟略高的根本原因。 二、我的优化构想:GPU智能分段公式动画渲染 建议在现有琉光、蜂鸟引擎基础上,新增一套并行的GPU程序化动画管线(不替代原有机制,完美兼容安卓生态) 核心逻辑非常简单: CPU不再逐帧算动画,只负责下发「分段规则+初始数据」,后续全部交给GPU自动算帧、自动渲染。 具体实现方式 1. 智能分段(核心创新) 系统UI的连续动效(列表滑动、弹窗动画、惯性回弹),可以自动智能拆分为 2~3段不同运动
35 人已参与
94%
6%
一、持续优化系统引擎内核,确保动画特效高效丝滑流畅。 当前系统流畅度尚可,但距离无缝衔接、丝滑流转仍有差距。希望在应用切换、页面滑动、多任务呼出等高频场景中,做到动画过渡自然细腻、跟手性极佳,达到行业顶尖水准。 二、深度优化系统功耗控制,切实保障系统续航能力。 实际续航表现必须与宣传数值一致,不能再出现新版本更新后续航严重缩水的问题。功耗控制应作为每次OTA的必测红线,凡是续航衰减超出合理范围(如超过5%)的版本不应推送。实际续航能力必须符合宣传的续航能力。 三、做好后台管控,清理多任务时保留当前任务。 一键清理后台时不应杀掉用户当前正在使用的应用。建议建立白名单机制,确保导航、会议、游戏、远程协助等高频场景应用常驻内存,切换回来时秒开且停留在原界面,彻底解决清后台清掉当前任务的痛点。 四、深化与阿莱影像的合作,确保系统影像画质超高清臻满。 具体标准是:拍风景不过度锐化,拍人像不假白磨皮,拍夜景不暴力提亮导致色彩失真。直出色彩要经得起放大,达到拍摄即出片的标准,让普通用户随手一拍也能获得高质量照片,这才是阿莱合作的价值所在。 五、系统主题设计要年轻化,设置专门奖项鼓励主题
27 人已参与
96%
4%
持续适配第三方应用一镜到底动画
37 人已参与
89%
11%
App 返回桌面时,桌面壁纸会缩放,如何关闭啊,真受不了这个动画,别缩放。
30 人已参与
80%
20%
建议给游戏应用添加桌面启动打断动画,保持全场景协调统一,增加美感
36 人已参与
92%
8%
优化切换应用时的流畅度,快速切应用时需要等待一秒后才能操作
19 人已参与
95%
5%
MagicOS 11在视觉和流畅度上的革新令人印象深刻,但系统体验是一场马拉松。基于用户反馈和行业趋势,我为MagicOS的未来发展提出以下几点建议: 🏗️ 夯实基础:性能、功耗与温控是根本 · 优化温控策略:不少用户反映系统温控过于“一刀切”,温度一到阈值就大幅度锁帧,导致游戏体验割裂。建议采用更温和的阶梯式降频策略。 · 平衡功耗与特效:“液态玻璃”等新特效被指加大了续航负担。未来应在系统层级提供更灵活的开关,让用户自主选择性能模式。 · 信号与基础稳定性:信号和网络稳定是用户最核心的诉求。未来大版本更新应持续将“优化信号稳定性”和修复影响日常体验的BUG作为重中之重。 ✨ 打磨细节:动效、UI与交互体验 · 补齐动画短板:目前的动画在横屏场景、文件夹滑动、负一屏退出等场景仍有卡顿。强烈建议补齐锁屏到桌面的“一镜到底” 过渡动画。 · 完善“灵动胶囊”:作为较早跟进“岛”设计的厂商,目前功能丰富度和交互逻辑已落后。应丰富更多场景,并优化多胶囊时的显示逻辑。 · 统一UI风格与加强细节:系统级应用的UI风格各异。同时需优化状态栏设计、锁屏小组件和通知的点击逻辑等细节。 · 提
52 人已参与
94%
6%
MagicOS 11双架构已经优化了图层合并、动画曲线与全局渲染效率,但GPU内部任务分配依旧是全局混跑模式: 页面按钮、图标动画、交互特效与静态背景、空白图层全部混在一起随机分配核心渲染。 这造成两个底层短板: 1. 交互动画没有算力优先级保障,容易被静态任务挤占资源,导致点击轻微滞后、动画不稳; ​ 2. GPU核心全开全关、一刀切调度,不会根据界面交互复杂度精细控核,简单界面耗电冗余、复杂界面算力不足。 为此我提出一套可落地、低风险的GPU细分调度优化方案,作为现有渲染架构的底层补充。 一、核心技术原理(核心重点) 1. 固定设立「交互常驻GPU核心池」 系统后台固定预留少量闲置GPU核心,专门绑定所有可交互控件渲染任务。 凡是页面内可点击、可操作元素:图标、按钮、弹窗、开关、按压反馈、转场动画,统一归类为交互任务组,优先由常驻核心池渲染。 技术价值: - 把「用户交互渲染」和「静态画面渲染」物理拆分算力队列 ​ - 彻底杜绝静态图层抢占触控动画算力 ​ - 交互动画始终走连续、稳定的核心资源,避免随机乱分配导致的微小掉帧、撕裂、延迟 2
24 人已参与
92%
8%
CPU、GPU、NPU、ISP都是多核架构,现在负载上来后调度器容易无限制唤醒多个核心,超出最优数量后,只会造成总线争抢、能效下降。 我的优化思路: 1. 在实验室控制频率不变,给各个核心簇、各个硬件模块测绘「边际核心增加收益数据表」,找到每类场景下边际收益快速衰减的拐点核心数。 ​ 2. 调度器根据当前任务类型查表,动态生成该模块的最大可唤醒核心上限,超过上限的空闲核心直接临时禁用休眠,不让调度器调用。 ​ 3. 调度逻辑分成两步: 第一步:查表锁定本次允许开启的核心总数上限; 第二步:在上限范围内,再对比「升频收益」和「开核收益」,选择最优方案提升性能。 额外增加一个应急兜底:遇到瞬时突发峰值负载,可以短暂临时放开上限一小段时间,避免卡顿。 好处: 从源头杜绝盲目多开核心,总线冲突变少,日常功耗和发热会更低,多核调度更加克制理性。 @性能研发陈立庚 @MagicOS流畅橙子 @性能_阿勇 @MagicOS流畅李同学
24 人已参与
96%
4%
目前荣耀是唯一一个删除应用没有任何动画的主流手机厂商,建议增加。
59 人已参与
93%
7%
🚀 核心构想:为每个进程动态圈定一组专属的异构核心团队——比如一个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%
🚀 核心构想:让AI学习用户的动画打断习惯,提前预判用户一般会在动画的第几帧到第几帧之间打断。当AI高度确信打断即将发生时,让CPU暂时停止为当前动画生成新的渲染指令。这样一来,被打断后那些再也用不上的无用指令就不会被生成,既省电又省算力。整个过程用户完全无感,动画始终保持丝滑流畅 我们在使用手机时,偶尔会在一个应用打开动画还没播完时就上滑打断。但CPU并不知道用户会打断,它为了保证流畅,会提前生成后续好多帧的渲染指令。一旦打断发生,这些已经生成好的指令就全部浪费了,白白消耗了CPU算力和电量。 我的想法是:让AI预测打断时机,在打断即将发生时暂时停一停指令生成,避免无效开销。 📐 技术原理 第一步:AI学习用户的打断习惯。 系统在后台默默记录用户在哪些场景、哪些动画上最常打断,以及打断通常发生在动画的哪个阶段。通过长期学习,AI能总结出用户的打断规律。 第二步:预测打断时机,暂缓生成指令。 当用户再次触发同一类动画时,AI根据以往规律判断:用户大概率会在某个帧区间内打断。此时AI通知CPU:在这个帧区间内,暂时停一停,不要再为当前动画生成新的渲染指令了。GPU命令缓冲里
30 人已参与
83%
17%
长按抢购加速应该进入图二这个界面 而不是图三
15 人已参与
80%
20%
希望可以做一些动效,例如华为的粒子粉碎效果等,观感更好,吸引用户
36 人已参与
83%
17%
动画优化下,负一拦点应用卡不连贯,通透控制中心有时不显示通透,动画有bug,其他没啥缺点
58 人已参与
97%
3%
建议magicOS11推送前增加一个动画效果,就是像华为的粒子效果差不多的,那个动画效果感觉很好看
22 人已参与
100%
0%
紫薯布丁紫薯布丁紫薯布丁
42 人已参与
71%
29%
性能模式下调度确实会激进一些,大核更愿意跑在高频段,不会像正常模式下划水。如果在佩戴散热器的情况下,开性能模式打游戏应该会好很多。 1-3是正常模式,4-6是性能模式。之所以性能模式有一段时间帧率波动的情况很大是因为我分屏刷抖音了。大家如果夏天不戴散热器的请况还是介意正常模式玩就行。
13 人已参与
92%
8%
性能模式下调度确实会激进一些,大核更愿意跑在高频段,不会像正常模式下划水。如果在佩戴散热器的情况下,开性能模式打游戏应该会好很多。 1-3是正常模式,4-6是性能模式。之所以性能模式有一段时间帧率波动的情况很大是因为我分屏刷抖音了。大家如果夏天不戴散热器的请况还是介意正常模式玩就行。
32 人已参与
91%
9%
荣耀手机在桌面状态,上滑和下滑,分别可以触发 app 搜索和个性化搜索,但是下滑触发个性化搜索明显不灵敏,有延迟,且很多时候一次难以触发,延迟感很明显。 对比 ios 系统的桌面下滑打开搜索,有明显的使用差异,体验不好 强烈建议优化这个下滑触发搜索的逻辑判断,优先级和性能表现。
27 人已参与
89%
11%
能不能把合并的软件也整个动画,为什么软件在一起就没有打断动画啥的了一个软件退出全出去了
14 人已参与
86%
14%
不如原来的按钮扩展,现在这个右上角展开太生硬了,而且在平板大屏幕上观感也不好,展开面覆盖到右下角的时候还会丢帧瞬移,挺牛的
26 人已参与
81%
19%
荣耀旗舰机干脆做一个极端性能机,出一个跟红魔一样能放开限制完全释放芯片性能的功能,然后藏在设置深处,打开那个设置就能出现一个一键释放性能的按键,玩游戏可以榨干芯片温度墙没有,做到跟红魔一样的性能调度,做到掉皮掉肉不掉帧。
33 人已参与
79%
21%
建议荣耀将Turbo X引擎从上层调度升级为系统级底层重构平台,借鉴ColorOS 16的三大技术方向:动效方面采用跨模块统一渲染的无缝架构,打破安卓模块独立绘制导致的动画割裂;性能方面引入芯片级动态追帧机制,基于渲染负载预测提前干预算力供给,从事后补偿转为事前预防,兼顾稳帧与功耗;编译方面自研从Java到硬件专属的完整编译链,以突破中低端机型的编译效率瓶颈。将上述技术栈整合至Turbo X引擎,可使MagicOS从单点场景优化跃升为全链路底层重构,从而奠定持久流畅的竞争壁垒。
32 人已参与
97%
3%
文件夹动画过于生硬,只有简单位移放大。 中端机添加实时背景模糊
22 人已参与
91%
9%
过渡动画能不能加上 0.75 倍速动画,倍感觉慢,0.5 倍又感觉太快了,0.75 倍刚刚好,以前用荣耀 2 0 的时候就就有个 0.75 倍速的选项感觉很好。很跟手,希望过渡动画加上 0.75 倍速选项
34 人已参与
88%
12%
希望过渡动画可以调0.75倍速,目前情况是0.5倍太快。1倍又有点慢,希望增加0.5倍速选项,以前用的荣耀20就可以调0.75倍速动画,很丝滑舒服。希望采纳
16 人已参与
88%
12%
过渡动画可以添加0.75倍速选项吗,现在这个0.5倍太快了,1倍又慢了一拍,0.15倍速正合适,上个荣耀20就有这个选项,可以加上去吗?
24 人已参与
100%
0%
iPhone/vivo(iQOO)系统内置减弱动态效果开关,用户可以选择开启此开关来节约电量 “移除动画”开关开启后,所有的动画都没有了导致过渡很生硬,没有开启动画一样的流畅体验 我建议在下一个小版本或Magic OS11加入此功能
23 人已参与
65%
35%
建议让充电气泡动画重新回归或者可以自定义充电动画
18 人已参与
94%
6%
动画做的非常好,说明产品经理(动画)已经认真在做了,荣耀确实也比较听劝,希望能继续保持,给耀子点赞!
28 人已参与
96%
4%
🚀 核心构想:从调度器身上拆出“代码编号器”,以用户单次点击为单位,在点击产生的代码调用过程中,编号器编号与调度器调用同步并行进行 目前的调度器,在响应用户点击时,既要分析“该调用哪些代码”,又要执行“把代码调出来”的动作。两件事串行着做,效率有提升空间。 我的想法是:从调度器身上拆一部分逻辑出来,做成一个独立的“代码编号器”。当用户点击屏幕上的某个按钮时,这个点击会触发一连串的代码调用。编号器负责根据这个点击,提前圈定接下来需要调用的代码模块范围,并按调用顺序编好号。调度器拿到编号后,直接在这个小范围内精确调用代码,不再需要自己从头分析。 关键是:编号和调用是同步并行进行的。 当编号器正在为后续的代码模块编号时,调度器正在同时调用前面已经编好号的代码。两者在同一次点击内部同步推进,互不等待,形成流水线作业。 📐 具体如何工作? 用户点击某个按钮,这个点击触发了一连串的代码调用需求。编号器立刻根据这个点击,快速圈定出需要调用的代码模块范围,并按照调用逻辑的先后顺序,从1开始逐个编号。 编号器一边编号,调度器一边执行。当编号器正在给第3个代码范围编号时,调度器已经在调用第1个
25 人已参与
80%
20%
建议参考魅族那样的开屏动画,原声的开屏动画太僵硬了
32 人已参与
91%
9%
🚀 核心构想:在应用启动动画这一瞬间,对应用图标图层进行三重增强——分辨率提升至2K、帧率提升至120帧、边缘进行锐化处理,而周围的壁纸背景则保持原分辨率、原帧率。动画结束后,所有图层立即恢复统一渲染。整个过程只需要短短几百毫秒,却能带来强烈的视觉层次感和极致流畅感 目前系统动画在启动时,所有视觉元素(应用图标、壁纸背景)通常是统一分辨率、统一帧率渲染的。这虽然保证了整体一致性,但还有进一步优化的空间。 我的想法是:利用现代GPU分层渲染的能力,在应用图标启动动画这一瞬间,集中所有渲染资源,把图标的视觉质量推到极限,同时保持背景不变。这就像电影中的浅景深效果——焦点内的主体极致清晰、丝滑运动,焦外的背景则柔美模糊,两者对比让动画的视觉冲击力达到最强。 📐 技术原理:三层增强,瞬态生效 第一层:120帧高帧率(动画流畅度)。 应用图标所在的图层,在动画启动瞬间切换到120帧渲染模式,保证运动轨迹极致丝滑。而壁纸背景所在的图层,保持60帧刷新率。因为壁纸本身是静止的,且处于高斯模糊状态,降低帧率不会影响视觉体验。 第二层:2K高分辨率(动画清晰度)。 对动画图标图层应用更高精度的
9 人已参与
100%
0%
1希望文件夹打开或关闭的动画速率可以和应用过渡动效里面的速率保持一致,也就是说,如果调成舒缓,那么打开文件夹的动画速率和打开应用的动画速率要一起变慢,如果调成高效那么文件夹的打开动画速率也要相应的变快。现在应用过渡动效设置,无论如何调整,文件夹的打开速率都是明显慢于应用动画速率的。 2文件夹的打断动画目前仍不是特别丝滑,希望能优化一下动画的打断逻辑,如果要点击文件夹中的应用必须得等文件夹完全打开后才能生效,希望在点击文件夹后立刻点击应用时,能让文件夹的打开动画渐隐并且直接衔接应用的打开动画
20 人已参与
90%
10%
针对主流 app 加入更多的无缝动画,例如微博
30 人已参与
87%
13%
magic7,最新170系统版本,动画变得很贼很油的感觉,用起来心理很痒很刺挠的感觉。就是感觉用着不舒服。希望官方有看到
19 人已参与
84%
16%
简体中文 - China
返回顶部