建议广场

以我的荣耀Magic7为例,从magic os 9,OS 10以至于到现在Magic oS 11的整体流畅度已经得到了很大的提升,蜂鸟架构使系统响应更加迅速,但是对比友商的系统而言,打断动画以及“并行交互”方面仍存在落后于其他友商比较生硬的情况,个人觉得荣耀的打断动画还有机会能更进一步,就比如说现在基本上友商都有的弹簧阻尼调校(其中OPPO的color os比较成熟),打断的时候有惯性减速、轻微回弹,观感连贯,希望官方可以进一步优化
41 人已参与
88%
12%
当前控制栏下滑动画有明显卡顿割裂感,体验不佳,建议优化动画过度。当前的动画效果还不如我另一台小米11pro的澎湃2系统的控制栏下滑动画丝滑呢😓
48 人已参与
96%
4%
现在大部分APP启动的时候都先要过一遍这个遮罩界面,放一个巨大的模糊的APP图标,然后才过渡到APP自带的启动页面,这个真的不丑吗???而且这个应该是只有荣耀才有吧,我试了其他几家安卓系统都没有
119 人已参与
96%
4%
感觉这个动画好生硬
23 人已参与
91%
9%
建议可以做一个模糊缩放渐变动画进行过渡,目前的有一点缩放,但是生硬不够优雅流畅
37 人已参与
89%
11%
华为的粒子特效真不错,建议拿过来。魔法六握感接电话,音频啥时候上
45 人已参与
91%
9%
最新系统打断动画还是有点卡,感觉60针的样子,对比华为差距明显,希望工程师赶紧优化一下
31 人已参与
90%
10%
能不能把小横条做成回弹的样式,返回或者别的用处这样一动不动看着别扭,
20 人已参与
85%
15%
痛点 手机原生调度器是“来一个线程,就分一个核心”,响应快,但只能顾眼前。游戏、大型App启动时,大量线程同时就绪,容易出现大核忙死、小核闲死,导致帧率抖动、发热波动。而且SoC负载一直在变,提前定好的分配方案,过几微秒就不合适了。 优化思路:借鉴鸿雁射频的“多组合择优” 只在高负载(大量线程同时就绪)时开启,日常中低负载保持原生调度不变,不增加功耗。 1. 编译期先打基础分:App编译时,提前标记每条指令的耗时、发热权重、内存延迟,把基础评估做完,减少运行时工作量。 2. 运行时动态择优:线程排队等待时,持续评估3~5套候选分配方案,跟着实时负载更新打分,不用旧结果。 3. 执行瞬间锁定最优:线程即将执行的那一刻,立刻选当前最新的最优方案下发。 4. 微秒级超时兜底:设一个极短的时间上限。如果评估还没完成,直接放弃择优,切回原生调度,绝不让线程干等。 好处 · 负载更均衡:跟随实时负载动态更新,避免“评估过时”,减少帧率抖动和发热波动。 · 计算压力小:编译阶段提前完成基础打分,运行时只做少量候选比较。 · 研发成本低:复用荣耀现有的AI择优技术思路,容易理解落地。
8 人已参与
88%
12%
应用过渡动画的舒缓模式 肉眼已经能感受到轻微掉帧了 且频率较高 可以优化吗 还是说安卓机的寿命到了性能已经开始慢慢衰退了
13 人已参与
92%
8%
比如下拉菜单动画总有莫名其妙的小卡顿,建议优化系统
34 人已参与
94%
6%
老生常谈的问题了,短板如果没有彻底补上,就不要放那么多kol在各大平台上大肆宣传这一块,整天把流畅、丝滑挂在嘴上,这不是作茧自缚吗?
26 人已参与
85%
15%
荣耀旗舰机干脆做一个极端性能机,出一个跟红魔一样能放开限制完全释放芯片性能的功能,然后藏在设置深处,打开那个设置就能出现一个一键释放性能的按键,玩游戏可以榨干芯片温度墙没有,做到跟红魔一样的性能调度,做到掉皮掉肉不掉帧。
33 人已参与
79%
21%
为什么动态效果只针对于进入应用和返回桌面,不应该像缩放动画一样针对全局么?
26 人已参与
96%
4%
动画有点生硬,可以做的更Q弹,像音乐灵动胶囊那样的效果
42 人已参与
98%
2%
这方面还是学学苹果华为吧,荣耀的动画效果很多地方太生硬,不够丝滑,特别是用户每天都要接触看到的地方,比如说下拉状态栏和左右横切,锁屏锁头解锁动画,等等
44 人已参与
93%
7%
11版本已更新,但下拉控制与返回,动画依然有一种不协调的感觉,希望尽快改善一下
17 人已参与
88%
12%
打开应用时,我很喜欢苹果在iOS 27上的做法。打开应用时,会产生视差效果。能实现这个吗?但不要太夸张,只要有一点视差效果就好。
23 人已参与
91%
9%
机型 mg9pm 1、动画还是会出现不连贯不丝滑,没有完全做到从哪儿来到哪儿去的非线性动画 比如:有些应用,如微信打开时,有时候动画是从中间向上下两边扩展,有时候是从手指点下去的地方展开。前后动画不一致。 2、抖音内还是会出现掉帧情况,就是感觉生硬顿一下 3、建议和 Oppo 最新的 17 系统学一下,把动画一致性和连贯性提升 4、相机白平衡不准,前后拍同一场景竟然出现不同色差。白平衡飘忽不定,后续在固件更新中解决一下
26 人已参与
96%
4%
无论是之前的magic oS 9,10还是11均存在一个问题:例如我的荣耀Magic7是12+256 GB,如果我的手机什么软件都不装,仅占用不到50个GB,此时的系统是非常流畅的,但当我安装一些应用剩余170个g或160个g左右的时候,就会发现出现顿挫感,掉帧,抽帧,希望官方可以进一步解决这个问题,这种东西发生的频率还是比较高的
46 人已参与
96%
4%
今天到线下店里体验了一下magic9ProMax,说实话不卡顿,但是系统连续打开应用切换跟手性真的很差,连续打开应用然后打断回主页,都连不起来。希望再往这方面优化一下,作为这么多年的老用户,这方面确实做的没有友商好。
27 人已参与
93%
7%
一句话建议: 在实验室调教阶段,不要只看游戏或场景的整体跑分,而是深入观察每个关键线程(如渲染、音频、逻辑)的效率指标。通过“线程级画像”精准定位是谁在拖后腿,从而调教出真正丝滑、不发热的系统策略。 一、痛点:只盯“总分”,抓不到“内鬼” 现在的芯片调教,就像老师看班级平均分。跑个游戏,看平均帧率;刷个视频,看整机功耗。 但实际用手机时,卡顿往往是因为几个“偏科生”: · 打游戏突然卡一下,可能是渲染线程被后台偷偷抢了CPU。 · 扫码反应慢,可能是逻辑线程等在锁上,或者网络线程被延迟了。 · 听歌偶尔爆音,可能是音频线程被调度器频繁搬来搬去,缓存失效。 如果我们只看整体跑分,永远不知道具体是哪个环节出了问题,调教就像盲人摸象,治标不治本。 二、方案:实验室里的“线程级画像” 建议在实验室的自动化测试台架上,引入“线程级画像”机制: 1. 锁定关键线程:不用监控所有上百个线程,只抓核心的“干将”——比如UI渲染、音频播放、核心逻辑、网络收发。 2. 多维度体检:在跑测试场景时,不仅记录整体帧率,还要记录这些关键线程的: · 跑了多久(执行时间) · 等了多久
27 人已参与
93%
7%
建议手势返回的动画增加渐变效果,从边缘到靠近屏幕中间由纯黑逐渐变透明
18 人已参与
83%
17%
一句话建议: 建议系统增加一个“场景感知的资源联动机制”。根据用户当前在干什么(游戏、刷视频、扫码),把CPU缓存、运行内存和闪存这三个层级的资源打包成一个“专属资源包”,优先保障前台应用,不让后台应用偷偷抢资源。 一、用户的困惑 大家可能都遇到过这种情况: · 打着游戏正激烈,突然卡了一下,其实是后台某个App在偷偷读写数据。 · 扫码付款时,扫了半天才弹出来,手机像没睡醒。 · 明明没开几个应用,手机却越用越热。 这背后的原因之一,是手机的存储层级(缓存、内存、闪存)各管各的,遇到突发情况,容易互相抢资源,导致前台应用“饿着肚子干活”。 二、方案:让三层资源“抱团联动” 我们可以把手机比作一个厨房: · CPU缓存是厨师手边的调料盒(最快)。 · 运行内存是冰箱(临时存放)。 · 闪存是楼下仓库(长期存放)。 现在的系统是:厨师要什么,就派人去冰箱拿,冰箱没有再去仓库搬。遇到高峰期,大家都在抢,厨师只能干等。 建议改为“场景化资源联动”: 1. 识别场景:系统通过AI感知当前是在打游戏、看视频还是扫码。 2. 资源打包:针对这个场景,把“缓存预留空间 + 内存专
25 人已参与
92%
8%
一句话建议: 系统学习用户打断动画的习惯,在动画播放的“黄金时间窗口”内,提前预测用户是否要打断,让操作更跟手。窗口外不预测,避免干扰正常使用。 一、用户的困扰 很多用户都有这种体验:动画还没播完,点下一个操作没反应,感觉像被“硬控”了。手速快一点,就要等动画播完才能操作,不够跟手。 二、根因在哪 现在系统要等手指移动超过一定距离,才判定为“滑动”或“打断”,然后才响应。这个判定需要时间,用户感觉慢半拍。 三、方案:黄金时间窗口 + 智能预测 1. 学习用户的打断习惯 系统记录用户平时在哪些位置、什么时机、用什么手势打断动画,逐渐学习每个人的习惯。 2. 找到“黄金时间窗口” 用户打断动画有自然反应时间: · 动画刚开始:用户还在看,来不及反应,不预测。 · 动画中期:用户开始决定要不要打断,最可能出手,在这个窗口内激活预测。 · 动画后期:动画快播完了,用户通常放弃打断,不预测。 每个场景的窗口不同,系统自动学习调整。 3. 窗口内精准预测 在黄金窗口内,如果手指触碰了用户习惯的打断热区,并且有明确的方向意图,系统就高置信度判定“用户要打断”,提前通
27 人已参与
81%
19%
一句话建议: 在蜂鸟架构基础上,增加一个全局动画状态机,统一管理所有系统UI动画的状态。触控打断时,状态机直接切换状态,而不是让每个动画各自“取消再启动”。目标是让文件夹、通知栏、多任务、控制中心等所有场景都支持并行打断。 一、用户的困惑 很多荣耀用户都有同感:动画还没播完,点下一个操作没反应,像被“硬控”了。文件夹打开时不能滑动,通知栏下拉时不能点别的,返回桌面时不能呼出控制中心。手速快一点,就要等动画播完才能操作。 目前只有多任务堆叠等少数场景支持并行打断,大部分场景仍然“不支持打断”。 二、根因在哪 现在每个系统动画各自为战。动画A在跑,触控来了,动画A要先“取消自己”,再让动画B“启动自己”。这两步是串行的,中间有间隙,用户就感觉卡了一下。 而且每个场景都要单独写打断逻辑,工作量大,覆盖不全。 三、方案:全局动画状态机 1. 统一注册 所有系统UI动画启动时,向状态机注册:当前状态、能不能打断、打断后切到哪个状态。 2. 统一决策 触控事件到达时,状态机立刻判断:当前动画能不能打断?打断后切到哪个状态?决策是毫秒级的。 3. 状态切换代替“取消+启动”
30 人已参与
93%
7%
如题,现在这动画太僵硬了,强烈建议优化。
70 人已参与
96%
4%
建议荣耀系统加入上下滑动到底和到顶的触感反馈,就像目前资源库这种。文件夹动画再优化快点,从用荣耀以来明显感觉打开比收拢慢
18 人已参与
89%
11%
一句话建议: 在实验室调校阶段,引入一个AI协同调校模型。工程师调整SoC参数时,模型自动推荐电源管理芯片、E2能效芯片、C3通信芯片、H1影像芯片、触控IC、显示驱动等外挂芯片的配套参数,整组一起测试、一起优化,不再逐块芯片反复迁就。 一、痛点 现在手机里芯片越来越多:SoC、电源管理芯片、E2能效增强芯片、C3通信芯片、驭光H1影像芯片、触控IC、屏幕驱动芯片……它们各管一摊,但实际使用时互相影响。 传统调校模式是:先把SoC调好,再逐个调外挂芯片去适配SoC。问题是: · SoC调完后,外挂芯片可能要反复迁就,耗时耗力。 · 各芯片由不同团队开发,局部最优不等于全局最优。 · 调完一轮后,发现SoC和外挂芯片配合不好,又要回头改SoC,来回折腾。 · 电源管理芯片如果没和SoC调度同步,容易出现“频率上去了、电压没跟上”的能效浪费。 二、方案:AI跨芯片协同调校模型 1. 建一个实验室调校大模型 把荣耀各产品线的定位和调校目标写进模型,模型不是瞎猜,而是按荣耀的目标函数去搜最优参数组合。 2. 学习历史调校记录 每次工程师调完SoC和外挂芯片,记录:
17 人已参与
82%
18%
荣耀600元气版系统动画过渡效果调到最快还是反应慢 ,希望优化
18 人已参与
78%
22%
退出应用快速切后台动画会卡掉,灵动胶囊也一闪一闪的,建议优化
33 人已参与
94%
6%
一句话建议: 蜂鸟超感知调度已经实现了系统侧的页面级资源倾斜。本建议在此基础上,聚焦两个它还没覆盖的缺口:一是推动应用在页面不可见时主动停止定时器、动画循环等系统管不了的工作;二是把调度粒度从“页面级”推进到“视口级”——用户滑到哪,资源就跟到哪。 一、蜂鸟已经做了什么 蜂鸟超感知调度引擎已经能识别用户当前正在交互的页面,并把CPU、GPU、网络资源向这个页面倾斜。系统侧“少给不可见页面资源”这件事,已经做到了。 二、还没做到的两个缺口 缺口一:系统管不了应用内部的定时器和动画循环 系统能降低不可见页面的调度优先级,但没法强制应用停止内部的setInterval、requestAnimationFrame、后台轮询。只要应用不主动停,这些工作就会持续触发,持续消耗资源。华为开发者文档已明确要求应用在页面不可见时必须主动停止动画和定时器,说明系统侧确实管不了。 缺口二:页面级粒度不够细 一个长页面可能有十几屏内容。用户只看到其中一屏,但整个页面都在占用资源。系统目前只能做到“这个页面可见,给它资源”,做不到“用户看到哪一屏,就给哪一屏资源”。 三、方案:视口级资源调度 1
17 人已参与
94%
6%
用户建议荣耀考虑为折叠屏手机安排内屏外屏贯通的动画效果,认为该效果很不错。
29 人已参与
93%
7%
一、痛点 手机SoC内部,CPU超大核、大核、小核、GPU、NPU访问不同内存通道的延迟各不相同。但现有内存分配是“就近随便放”,数据可能被分配到离使用它的核心最远的通道上。用户感受到的“偶尔卡一下”,很多时候不是算力不够,是数据“住得太远”,核心每次访问都要跑长途。 二、具体方案 开发一套NUMA感知的内存调度机制,实时感知SoC各核心簇的数据访问特征,动态调整数据在物理内存通道中的分布,让高频访问的数据主动“跑”到离使用它的核心最近的地方。 核心逻辑: · 实时监测:追踪每个核心簇的内存访问模式,识别热点数据页 · 亲和性映射:将热点数据页的逻辑地址映射到离目标核心簇最近的物理内存通道 · 动态迁移:在后台将“住得远”的热点数据迁移到“近”通道,按需渐进,不阻塞前台 · 闭环优化:持续学习用户使用习惯,不同场景下为不同核心簇预置最优数据布局 @HONOR2608234508028 @MagicOS流畅橙子 @性能_阿勇 @MagicOS流畅李同学
15 人已参与
93%
7%
能给荣耀。添加个卸载图标的动画,不也不指望啥好看,高级的动画,普普通通的也行
15 人已参与
93%
7%
在主屏幕上向下滑动时,会出现一个搜索菜单,方便您查找和搜索应用程序。但是动画看起来杂乱廉价。当你从该界面滑出并再次向下滑动到主屏幕时,必须等待 1-2 秒才能识别你的滑动操作,这令人沮丧。我建议添加更具弹性的动画效果,并使其支持并行动画,从而使整个系统看起来更加协调统一。
22 人已参与
86%
14%
桌面文件夹打开的动画速度太慢了,如果调成 0.5 又太快,如果有 0.75 的选项就完美了
11 人已参与
82%
18%
根据自己的爱好,可以选择加快动画过渡时间或者正常速度。
17 人已参与
94%
6%
一句话建议: 用轻量视觉模型识别“小程序加载、页面跳转”这类UI特征,结合系统已有的网络状态,提前给Turbo X发场景提示,让它提前准备调度预案,减少瞬时卡顿。 一、现状:Turbo X反应快,但有时“看到得晚” Turbo X已经能根据进程、CPU/GPU负载做预测。但有一个盲区: 在同一个APP里打开小程序、跳转网页时,进程名不会变,CPU负载也还没涨上来。调度系统要等负载起来才知道“要忙了”,这时候卡顿已经发生了。 小程序加载转圈,通常分两类原因: 1. 网络/服务器拥堵; 2. 本地页面渲染、JS执行带来瞬时高负载。 网络问题调度优化不了,但本地渲染负载可以提前准备。 二、方案:让视觉模型当“副驾”,提前报路况 用MagicGUI能力蒸馏出一个轻量视觉模型,后台低功耗运行,只识别小程序加载动画、页面跳转这类UI特征。 只有识别到加载动画,并且置信度达标,才去读系统已经缓存好的网络状态,做联合判断: · 网络差:判定卡顿来自网络,不向Turbo X发任何调度提示; · 网络好:判定即将出现本地瞬时渲染负载,异步给Turbo X发一个简短场景标记。 Turbo
32 人已参与
100%
0%
简体中文 - China
返回顶部