建议广场

痛点 现在安卓系统里,Linux内核负责整机CPU、内存的全局调度,ART虚拟机负责App内部GC**回收、Java线程管理。两者是两套独立的调度逻辑: - 内核不清楚App内部GC的压力,虚拟机也看不到整机的负载情况; ​ - 经常出现冲突:内核正在收紧内存资源,虚拟机却触发大规模**回收;内核要压低后台线程优先级,App内部线程还在抢占资源; ​ - 二者动作不同步,会造成卡顿、掉帧、功耗异常,这是长期存在的系统问题。 现有方案只能做到ART把线程类型上报给内核,内核再做调度,属于事后反馈,存在一定的响应滞后。 方案思路 不搞复杂的AI预测,不改动硬件权限隔离,采用内核下发调度目标、ART同步配合的思路。 1. 根据用户场景动态调整调度周期 内核实时感知用户操作(滑动、点击、打字)、前台应用场景、整机CPU和内存负载,自动改变调度周期长短: - 用户正在滑动、交互操作:使用短周期,保证响应及时; ​ - 静态浏览、轻度使用:中等周期,平衡性能与耗电; ​ - 锁屏静置、后台闲置:拉长周期,减少额外开销,降低耗电。 2. 每个周期开始,内核提前下发本
11 人已参与
支持
反对
当用户向上滑动将应用切换到画中画模式时,动画不够流畅,显得有些生硬。我建议让它能够跟随我们手指滑动的力度进行调整。目前的问题是,当用户停止与屏幕接触时,画中画动画会立即拖动窗口,而忽略滑动的力度。
23 人已参与
96%
4%
我建议让返回手势更加流畅,应用程序可以跟随按住按钮时手的移动轨迹。
18 人已参与
100%
0%
点击进入桌面文件夹然后右滑这个并行动画很难做吗?不是为什么非得老是硬控用户啊。
16 人已参与
100%
0%
当前MagicOS桌面大文件夹,执行打开过渡动画期间,点击桌面其他区域无法中断动画,必须等待文件夹完整打开动画执行完毕后,才可以响应后续点击操作,交互响应存在阻塞。 希望优化交互逻辑:允许在大文件夹打开动画播放的过程中,点击其他区域即可打断当前打开动画;同时配套增加打断状态的过渡动画,实现平滑终止动画,避免界面生硬跳转,提升桌面操作跟手性与交互体验。
16 人已参与
94%
6%
一、现存痛点 目前端侧大模型推理,大多是把整个模型提前完成静态编译。当我们发送提问之后,从输入文本编码、嵌入处理,再到注意力运算,部分算子需要在请求发起的瞬间现场编译、调度,造成首token等待时间偏长。 现有的编译方案是对整个模型做统一静态处理,不会结合当前这一条用户实际输入的聊天内容做针对性优化。 模型后续生成回答存在随机性,我们没办法预判输出内容,但是,有一部分运算,无论大模型最后回复什么内容,只要这条请求发起,就一定会执行。这一部分可以利用起来做加速。 二、优化构想 在大模型推理框架中增加请求级预编译模块。 触发时机:用户输入完内容,点击发送按钮之后,正式开始推理运算之前。 1、拿到用户完整输入文本,区分两类运算 - 【确定必执行算子】:不管模型输出什么答案都必须运行的逻辑:文本token编码、词嵌入Embedding、输入prompt的注意力计算、KV‑Cache初始化。 这部分不存在分支选择,100%会被调用。针对这一批算子,提前完成算子融合、编译、内存布局预分配。 注意:只编译算子执行逻辑,不提前计算张量内部数据,数据仍然在推理阶段实时运算。
28 人已参与
100%
0%
荣耀,我建议你千万不要学某些友商的那些过渡动画,我认为,通知中心与控制中心属于两个独立的个体,并不在一个平面,友商做的那种动画,相当于两边都在一个图层上,个人觉得应该做成像进入负一屏那样的叠加动画,就像是负一屏与桌面也不属于同一个图层一样
50 人已参与
80%
20%
一、现存痛点 现在手机CPU自带指令缓存机制:一段代码只有运行过一次之后,才会把译码结果保存下来,第二次运行才能复用,不用重新翻译指令。 但很多线程、循环代码第一次执行的时候没有缓存可用,CPU要完整做一遍译码工作,会带来额外性能开销与功耗。尤其是批量处理数据的任务,里面存在不少重复的指令片段,第一次跑的时候没法享受缓存带来的加速。 二、优化构想 在线程准备要开始运行的阶段,系统做轻量的指令预扫描: 1. 只针对循环、批量运算这类特征明显的线程,不去全部线程扫描,控制额外开销。 ​ 2. 快速识别里面重复的完整指令片段。 ​ 3. 将识别出来的重复片段,提前预填充进CPU微指令缓存。 不是创造全新硬件,是把芯片已经具备的缓存能力,由“跑完再缓存”变成提前预加载,第一次执行就可以复用缓存,减少第一次译码的负担。 遇到if分支跳转、函数调用打断代码流的时候,立刻停止预扫描,避免无效运算。同时增加开关判断,如果一段代码重复指令很少,就直接关闭该功能,防止预分析本身反而拖慢速度。 三、预期效果 1. 循环、批量处理类任务,线程第一次运行就享受缓存加速,降低C
14 人已参与
93%
7%
打开应用类文件夹的过程动画途中不能来回滑动,很影响操作体验,建议优化一下
21 人已参与
95%
5%
建议参考colorOS17的渐进式动效
50 人已参与
88%
12%
几个月前就反馈过,没想到了11系统还是没改!!工程师真的应该用一下其他家的手机,小米,OPPO等等。都没有这个先放大app图标的动画! 极其割裂!!系统自带的app也都没有放大图标这个过程,部分第三方app例如抖音,微信也没有!但很多第三方app例如淘宝,京东,小红书打开时就会先加载一段放大app图标的动画!!!! 这是什么逻辑?工程师能否解释一下???你们自己不觉得割裂吗???不要扯谷歌规定,那为什么其他家早就统一取消了!! 论坛这么多人反馈过,真的有用心听取意见吗!!! 极其失望!!!! @产品经理回音壁 @续航_强哥 @荣耀小达人丶萧萧 @MagicOS流畅李同学 @MagicOS想和您交朋友 @荣耀小达人丶小蛋 @荣耀小达人丶永恒 @MagicOS互联网建议雷达 @MagicOS_AI小苏 @坠落云端 @MagicOS人机交互小王
57 人已参与
91%
9%
桌面app文件夹组打开和关闭的动画非常生硬,希望能改进得灵动轻快一些。
19 人已参与
95%
5%
应用变了,文件夹没变,很卡手
27 人已参与
96%
4%
有点卡。。。。
19 人已参与
79%
21%
进入设置会卡顿,部分滑动会卡顿,建议优化
57 人已参与
91%
9%
MagicOS系统,整个动态效果光效还有系统互动都很少,可以多做点像删除之类的效果类似于华为的那种粒子光效
45 人已参与
93%
7%
现状问题 当前MagicOS采用蜂鸟、琉光双架构分离设计:蜂鸟负责UI动效物理运动计算,琉光负责液态玻璃视觉渲染。二者仅做基础时间戳对齐,琉光仍保留大量独立光学参数,没有强制复用蜂鸟的物理变量。 这就导致动效节奏与光影渲染容易出现不同步,第三方应用接入时需要分别适配两套接口,开发成本高;同时两套架构存在参数通信冗余,额外增加了GPU调度开销,不利于第三方应用内转场动画实现与系统桌面动效质感统一。 优化构想 不彻底推翻底层架构做颠覆性合并,而是搭建统一参数中枢层: 以蜂鸟架构的动效物理变量(动画时长、阻尼力度、回弹曲线、运动周期)作为唯一基准数据源,琉光架构所有视觉渲染函数只读调用这套标准变量,不再定义私有时序参数;上层对外封装一套统一调用接口,应用只需下发基础动效指令,即可同步完成物理运动与光影渲染。 核心优势 1. 节奏天然同步:玻璃折射、模糊渐变、光影流动完全匹配动效回弹节奏,杜绝动画结束光影残留的割裂感; ​ 2. 降低适配成本:第三方应用无需分别对接两套架构,大幅减少接入工作量,便于实现应用内转场动画与系统桌面动效质感统一; ​ 3. 精简调度链路:取
33 人已参与
91%
9%
希望下拉来个过渡动画,这感觉太割裂了,突然出现
19 人已参与
100%
0%
我建议让应用库动画更加流畅,就像 ColorOS 那样。
17 人已参与
94%
6%
具体看视频,更新150版本后发现,点进文件夹后,立即侧滑翻页没反应,感觉是动画没结束滑了无效。如果点进去后等1s侧滑就有用。
12 人已参与
100%
0%
11系统内测更新完107补丁后滑动屏幕出现明显掉帧卡顿,联系抓紧优化一下
22 人已参与
100%
0%
苹果手机下方 Dock 栏里的打断动画好像是有倾斜效果的。可不可以做一个这样的动画?看着挺好看的
30 人已参与
87%
13%
与HarmonyOS等竞争对手相比,MagicOS 11在细节处理方面严重不足。在HarmonyOS中,每一个动作都会有轻微的“抖动”。它还可以与其他元素“融合”,营造出“液体”效果。我建议荣耀元素也应该采用这种效果。观看视频可以更清楚地了解这一点。
31 人已参与
97%
3%
现状痛点 系统部分交互动画(弹窗、过渡、打开应用)存在复杂图层、模糊效果叠加,偶尔出现瞬间 GPU 压力过高,造成短暂掉帧、动画不够丝滑。 我的想法是:用轻量化实时帧负载打分机制,预测动画的哪一些帧容易卡顿,从而让系统提前渲染这些易卡顿的帧 通俗核心原理 每一段系统动画,都是由一帧一帧画面组成。 每一帧画面的 “压力大小” 不一样: 有的画面图层多、模糊重、缩放复杂 → 压力大、容易卡 有的画面简单干净 → 压力小、不会卡 系统在动画刚开始的一瞬间,通过四项基础参数快速给每一帧打分: 1. 画面图层数量多少 2. 玻璃模糊强度高低 3. 画面缩放、形变程度 4. 透明叠加复杂度 通过简单数学计算,微秒级就能判断出:哪几帧是高负载、容易卡顿的关键帧。 工作流程(通俗易懂) 1. 快速打分识别 动画启动瞬间,系统自动扫描全部帧,瞬间找出容易卡顿的画面。 2. 只预渲染压力大的关键帧 只针对打分高、压力大的少数帧,提前在后台渲染好并缓存。 普通简单画面保持实时渲染,不浪费算力。 3. 播放到卡点直接取用成品画面 当动画播放到原本容易卡顿的位置时,GPU 不需要临时高压运算,直接调取提
34 人已参与
91%
9%
现在熄屏亮屏动画非常生硬,希望增加相关动画,看着舒服点。
46 人已参与
85%
15%
现状痛点 当前MagicOS的系统动画,大多依靠固定缓动曲线、统一物理参数生成,光影模糊、回弹阻尼等效果全程不变,动效层次感比较单薄;如果想要做到每一帧单独微调参数,又会大幅增加GPU运算负担,容易造成帧率波动、功耗上升,很难落地。 脑洞构想 依托荣耀琉光渲染架构、蜂鸟物理动画架构,引入相似帧分组复用机制: 1. 系统在动画播放前,提前对整段动画做帧分析,把画面变化平缓、物理状态接近的连续帧归为同一个参数组; ​ 2. 同一个分组内的所有帧,共用一套渲染、物理参数,全程无需重复更新;只有当动画画面、运动状态出现明显变化,切换到新的分组时,才一次性调整光影、回弹力度等参数; ​ 3. 平缓过渡阶段复用参数节省算力,关键转折阶段单独精细调参,既保留动效的细腻层次感,又把运算开销降到最低。 弹窗、滑动、卡片过渡、液态玻璃光影等高频交互动效,都可以用这套逻辑优化,重复播放的动画分组数据还能缓存复用,进一步降低功耗。 约束条件 1. 提供性能档位开关,普通模式沿用现有动画逻辑,旗舰机型可开启精细帧分组调参模式; ​ 2. 异步完成帧分组预计算,不阻塞动画启动,避免出现启动
16 人已参与
94%
6%
1 退出应用回到桌面不能立刻下滑呼出全局搜索或者控制中心,也不能上滑呼出抽屉,都要等1秒 2 负一屏打开应用关闭后等2秒才能滑动回到桌面 3 文件夹打开后不能立刻滑动,要等1秒
33 人已参与
100%
0%
现状问题 当我们做手势操作,动画还没有播放完毕,立刻执行下一个系统手势动作时,上一段正在运行的动画会直接强制终止。画面会突然跳变,过渡割裂,视觉上不够连贯。 举例合适场景(不会干扰正在浏览的App页面内容): 1. 上滑返回退出应用的动画还在运行,中途立刻上滑进入多任务后台 ​ 2. 在多任务卡片滑动动画播放中途,直接点选另一张应用卡片 ​ 3. 打开应用的过渡动画还没结束,中途手势返回桌面 以上都是系统层级窗口切换,不会挤压破坏App内部浏览内容。现在旧动画直接半路掐断,画面有突兀一跳。 构想 不要直接销毁正在播放的系统窗口动画。 当触发新的系统手势动作,新的窗口动画开始入场时,顺着新动画的运动方向,把旧的系统窗口顺势向外推挤出去,新旧两套窗口动画同步联动运行。 实现思路: 1. 在琉光图层渲染管线内部增加这套推挤处理逻辑。发生动画打断一瞬间,CPU只做一次判断校验,把冲击力、阻尼、最大偏移距离、参与动画的系统图层一次性传给图形渲染层。 ​ 2. 后续每一帧推挤产生的位移、速度衰减变化,交给图形渲染层完成运算,不再需要CPU每一帧反复计算、下发位置指
19 人已参与
100%
0%
应用冷启动遮罩,打开QQ和一些系统软件冷启动也有遮罩。虽然没什么大题,但还是优化一下比较好。
25 人已参与
92%
8%
荣耀现在好像还没有并行动画,连续打开 app 会卡住,荣耀什么时候去认证一个 5 年流畅的认证呢
19 人已参与
100%
0%
现状 当前琉光架构的UI动画裁剪为逐帧实时计算控件渲染边界。系统图标、控件播放确定性动画时,GPU每帧都要重新判断渲染范围,会产生一部分无效像素渲染开销。当动画中途被其他动画打断,预生成的渲染边界会直接失效,退回普通渲染逻辑。 优化构想 针对桌面图标点击启动动画、系统弹窗、页面转场这类起止点确定、运动轨迹完全可预知的确定性动画: 1. 在动画触发瞬间,根据完整运动轨迹,预计算整个动画周期控件会覆盖的最大像素包围盒,生成虚拟渲染模子。GPU限定仅在该模子区域内执行像素渲染,模子以外区域跳过渲染计算,控件运动被约束在模子边界之内。 ​ 2. 当动画播放中途被新动画打断,不直接销毁原有模子;将旧动画模子与新动画的预计算模子做包围盒并集合并,生成可以完整容纳两段全部轨迹的全新总模子。GPU继续沿用合并后的模子作为渲染限制,避免控件画面被异常裁切,继续保留裁剪优化收益。 强制保护边界(非常关键) 1. 仅对轨迹可预知的确定性系统UI动画生效;带物理回弹、拖拽、惯性的交互动画,不启用本机制,沿用原有渲染逻辑。 ​ 2. 设置打断次数阈值:短时间内连续多次动画打断,模子持续膨
37 人已参与
95%
5%
右上角按钮,动效不一致,软件更新界面仍然沿用旧逻辑,需要统一逻辑一致性
42 人已参与
95%
5%
这个效果挺好看的
42 人已参与
93%
7%
现在的应用打断动画升级了触控响应,但最关键的并行动画到目前为止还是缺失状态,仔细看可以看到在退出第二个应用的时候第一个应用的退出动画直接消失,所谓并行就是让动画各干各的,从哪来回哪去,现在国内五大手机厂商就荣耀缺失并行动画,建议优化🙏
34 人已参与
91%
9%
建议增加场景自动化切换
24 人已参与
92%
8%
即使在OS11的内测版本,应用冷启动时依然有APP图标遮罩,并不美观(如一、二、四) 并且不是所有的APP启动都会有遮罩,又导致不同的APP启动之间会有明显的割裂感(如三) 应用冷启动时,大部分有遮罩的应用,会先显现图标遮罩,后又展示第三方启动画面,体感上显得臃肿、启动慢(如视频) 希望在未来的OS11内测版本可以把应用冷启动的遮罩统一去除,使用第三方应用自己的启动画面
18 人已参与
72%
28%
11系统的Q弹动效真的还可以!
13 人已参与
85%
15%
如题,希望优化一下这种场景下的流畅度
28 人已参与
93%
7%
简体中文 - China
返回顶部