广播

国产首款eSIM旗舰来了！
OPPO Find X9 Pro卫星通信版今日正式发售，解锁“双实体卡+双eSIM”四卡灵活组合，轻松实现工作生活号分离、境内外卡无缝切换。
更融合卫星通信黑科技，无地面信号时也能双向通话、发送紧急报文。
实体卡槽+eSIM双模设计兼顾实用与创新，7500mAh大电池+强化信号天线加持，商务差旅、户外探险都靠谱，国产通信体验再攀新高峰！

在传统的安卓架构中，应用开发者使用的 Java 代码，与最终驱动硬件的底层 C/C++ 代码之间，隔着一个名为 ART 的虚拟机。
这就像一个「多层翻译」系统：Java 代码的指令需要先被虚拟机「翻译」一次，才能传递给底层代码去执行。
这个过程效率低下，而且信息在层层转手中容易失真，因为 Java 语言本身是「通用型」的，它不像 C 语言那样对 CPU 有着「专属」和深刻的理解。
测试数据显示，这种架构导致的算力浪费可能超过 30%。
这道「墙」的存在，使得上层应用的优化意图很难精准传达到硬件层面，导致了「算力空转但卡顿依旧」的尴尬局面。
在编译领域，有一个被公认为最先进、最高效的工具链叫 LLVM，但安卓过去只给底层的 C/C++ 代码使用，上层的 Java 代码是没有的，而我们这次做的，就是为 Java 而生，核心是将 Java 代码、虚拟机逻辑和原生 C 代码，全部翻译成同一种能被 LLVM 理解的「底层语言」，跑在统一的框架内进行协同优化。
这就带来了「1+1 远大于 2」的效果，以及另一个新技术——「跨级融合编译」。
在过去，系统对 Java 代码的优化和对 C 代码的优化是相互隔离的，而现在，因为它们「说」的是同一种语言，编译器得以洞察一个操作指令的完整生命周期——从用户在 ...查看全文

前几天同事和同行去开了 CLK2025 大会，讲一些会上的内容。
来自华为的黄晓嘉和 vivo 的韩棋分别分享了针对 “阅后即焚 Pagecache” 的技术探索，核心都是解决 AI 场景下大文件加载的内存占用与效率问题。
华为聚焦 AI 模型文件加载的痛点 —— 耗时长、占用内存多，而模型权重数据无需长期留存于 page cache，“阅后即焚” 成为关键诉求。
基于这一需求，华为设计了 ModelFS，核心思路是将预取（prefetch）和内存回收过程变得可编程。
它允许在用户态注册预取和驱逐（evict）回调函数，支持用户自定义算法，让加载过程具备 NUMA 感知能力，还能根据 IO 模式灵活调整预取和回收策略。
另一边，vivo 的韩棋分享了在 F2FS 文件系统上支持 uncached buffer IO 的努力。这种 IO 方式的核心是 “阅后即焚”，避免了普通 buffer IO 中 folio 的 LRU 管理及回收开销。
与完全的 cached buffer IO 相比，uncached buffer IO 的 folio 自带 PG_dropbehind 标记，能绕开 LRU 队列和常规回收机制，实现 “用完即抛”；与 direct IO 相比，它的优势在于所有并发读写仍通过 page cache 同步。
和腾讯宋恺睿正在推进的 swap in 路径优化思路相似 —— 删除 sync IO 设备绕开 swapcache 的代码 ...查看全文

Android APP 内存 GC 性能优化核心围绕三个核心思路展开：
1、尽量不存在 GC 问题
2、用户操作时不随意 GC 耽误响应
3、APP 空闲时充分 GC 且不浪费算力。
尽量不 GC 的核心是减少内存回收的必要性。熟悉 C++ 的开发者都知道，析构函数会在对象退出作用域时自动释放内存，仅手动申请的内存需要用户自行管理。
iOS 的 GC 机制和华为方舟编译器都采用了引用计数方案，早期 Objective-C 就依赖这一思路，后来 Swift 为了兼容性也沿用类似设计。
但 Java 生态并不适合直接引入引用计数，改动范围过大，它更倾向于标记清除等 GC 方案。引用计数本身无法解决循环依赖问题，这是其核心局限。
为应对循环依赖，iOS 补充了弱引用机制，方舟编译器推测也采用了 “引用计数 + 循环依赖单独处理” 的方式，大概率同样依赖弱引用。
“不要乱 GC” 的核心是保障用户操作时的流畅性，把 CPU 算力优先给到用户交互。这就需要针对性缓解卡顿，比如在输入、滚动等高性能消耗场景中抑制 GC，只要系统内存充足，即便 APP 内存超过阈值也可暂时不触发。
常规 GC 的触发多与内存压力相关，此时必须通过回收内存才能满足使用需求，由此也衍生出动态内存上限的优化方案。而定时回收则介于各类条件之间， ...查看全文

高端机要功耗，低端机要性能。
手机的屏幕刷新率从 60 到 90 到 120，到 144，到 165 ，不断突破，向着 pc 靠齐。也在为了功耗做动态切换，从固定档位的LTPS， 到可以无级切换的LTPO。如果没有LTPO 甚至 LTPS 就不能做到了么？
还是有些玩法的。 从渲染显示管线来看。 app 的 view tree，到 app 的 vsync，到 SurfaceFlinger 到 DSS 驱动 到panel 硬件。每一个阶段都可以做不同的优化。 怎么思考这些优化方案？ 简单的一个点就是：单数和双数；能否提高上限，降低下线；能否动态切换。
单数和双数问题：
1、 一个 app 怎么玩？
app 的不同的 view tree，其实刷新的速率可以做到不一样的。大家常见的视频和弹幕、评论这些 组件就是不一样。 那同一类 view tree 里面，也是有优先级的，比如 systemui app 的状态栏，这种一般给个 10hz 就 ok，有变化再给高就行了。
2、不同 app 怎么玩？
是否就有根据不同 app 设置不同刷新率的方案了。多 app 的可视化窗口，哪个是重点窗口，这些是可以根据场景来做不同刷新率的。比如 根据 不同窗口面积大小计算，比如根据各个窗口内容绘制 view 数量或者耗时等做阈值等等。SF/HWC 阶段，这个刷新率差分器，它是控制不同 app 的刷新率的 ...查看全文

本来想写一下APP 从GPU侧性能优化的，图片懒得搞。就随便写下更简单图形栈内存吧。
Android APP 内存有一部分是graphic这块消耗，skia这边对APP使用的字体字形缓存，GPU资源缓存等。 
这个就是在性能和内存之间取平衡。高性能，就缓存多些。要内存就回收狠些。最狠的时候直接把context给回收。
 skia对APP在前台和后台内存阈值也有区分。退后台后阈值减少50%。 鸿蒙继续通过prop可以动态调整，默认值再少10%。
cache的 算法 采用 lru，这一块的话是可以考虑有其他的优化方案相结合的。比如除了考虑使用顺序，还要考虑使用时间，还要考虑缓存大小。比如数据已经很久没有访问了，即使缓存阈值还有余量，也是可以考虑清理掉的。
不同APP对内存回收的要求其实不一样。但是skia系统默认值都一样。这块是有客制化空间的。对典型APP，这块可以增加一部分定制。 ...查看全文

整个工作将分为用户调研、开发、测试三个阶段推进，每个阶段聚焦核心目标，层层递进保障流畅性体验。
用户调研的核心，是明确用户对流畅性的核心关注点，以及这些关注点对体验的影响程度。首先会开展一轮用户调研，筛选出用户实际关注的流畅性相关场景。
针对这些场景设计评分量表，通过用户评分挖掘场景的实际意义。比如返回桌面场景的 7 分制评分中，1-3 分为满意、4 分为一般、5-7 分为不满意，数据显示超过 500 毫秒用户就会不满意，这类阈值会作为后续工作的核心输入标准，每个调研场景都会对应产出专属阈值。
进入开发阶段后，核心原则是保留已有优化成果，同时严防性能劣化。这一阶段会用到三个核心工具，且工具触发均有明确条件 —— 用户指标方面包括掉帧、持锁大于 8ms、binder 调用耗时等，性能指标则聚焦动画期间的 io 操作、广播注册、find service 等潜在性能问题。
O-StrictMode 工具检测到问题后，会将 backtrace 以蓝屏形式打印；Trace Analyzer 能自动分析 trace 文件，过滤无效 trace 和未抓到时间点的问题，对有效 trace 直接定位根因，减少手动分析成本、提升效率；MTrace 作为轻量型 Trace 增强工具，思路类似 measure instrumention，并非采样方案。
它 ...查看全文

软件开发模式中的敏捷模式为什么有效？有什么局限？
局部有效：敏捷模式类似动态路径规划中找局部最优解。
全局局限：对于全局最优，敏捷是看不到的。做不到统筹学里面的全局最优，只能算是战术最优。
大型跨组织复杂项目上，还要其它项目管理方法能统筹几十上百个敏捷项目做到全局最优。

分享一个dex2oat加速编译的性能优化方案，所有图片由本人现场拍摄，外传前请声明图片来源（Yangsh888）。
来源：ODC25 开发者大会 - 流畅技术分论坛 - 通过二进制重用加速APP的机器码重建，武汉大学计算机学院，李清安教授
场景：系统升级后，要重新做 oat，费时费电。
方案：核心思想是复用编译阶段的 obj 函数代码，主要只做链接阶段地址重定位。减少 5%~33%cpu 耗时，节省 14%左右耗电。

内存优化：核心是不用，少用，快速使用。
不用：这个没啥讲的。砍业务砍功能就可以不用了。
少用：一个是减少加载到内存的数据。一个是加载到内存的数据占更少的空间
快速使用：一个是快速分配，避免关键路径耗时卡顿，一个是快速释放，别占着茅坑让给更紧急更重要的场景。
当然，上面的都可以通过业务功能角度进行拆解提优化方案。功能不同方案不同，思路类似：提前/并行/延后；降品质/降精细度；。。。
说下更通用的几个方案思路：
一般文件读写都要进page cache。 page cache 要走类似lru方式释放。 行业里面有提出针对 Android /data 等可读写分区 F2FS 文件系统 使用 uncached buffer io方案。 针对只读一次的数据，直接打标签稍后直接可以优先回收。
那能否不走page cache呢？
针对Android /system只读文件系统 EROFS 也在研发 direct io方案。减少page开销，提高读取速度。
如果要走page cache呢？
又有个方案：对干净的page cache 走 zcache 内存池压缩方案。减少内存占用。释放也能直接释放， 没有回写问题。
提到压缩，也有方案。
针对zram ，Android提供了多压缩算法选择。可以根据负载等场景动态选择压缩算法。
压缩也有方案，比如卸载到GPU做压缩。
zram后的swa ...查看全文

2009 年，一位澳大利亚的麻醉医生 Con Kolivas 因为实在忍受不了自己电脑卡顿，一怒之下写了个调度器 —— BFS（Brain Fuck Scheduler）。
这个名字听起来有点“叛逆”，但在那个 CFS（Completely Fair Scheduler）主导的时代，BFS 确实用一种近乎偏执的方式，证明了“为特定场景定制调度器”这件事的价值。
它不追求通用性，而是专注于桌面环境下的低延迟响应，用一个全局队列代替每个CPU各自的调度队列，大幅减少了调度开销。
很多用户反馈，在日常使用中，BFS 比 CFS 更“跟手”，尤其是在交互场景下。
但 BFS 始终没能进入 Linux 主线。原因很简单：Linux 内核追求的是通用、稳定、可扩展，而不是为某类硬件或某类负载做特化。
Kolivas 的努力虽然启发了很多人，但 BFS 最终于 2016 年停止更新，不过他的理念，却像一颗种子，埋进了后来者的土壤里。
时间来到 2024 年 9 月，一个名为 sched-ext 的新调度框架被正式合入 Linux 主线。相较于它的其他前辈们，它最大的不同，是允许用户通过 eBPF（extended Berkeley Packet Filter）编写自己的调度策略，而无需修改内核代码，也不用说服整个社区接受你的补丁。
这听起来可能有点技术，但背后的意义非常深远：它打破了“应用层 ...查看全文

站长朋友们，MXANA今日正式发布重大版本更新！作为全球首个支持热点图、错误监控、单页面应用（SPA）分析的100%免费网站统计平台，MXANA现已全面开放三大核心功能，并承诺永久无流量限制、无隐藏付费条款！
MXANA核心亮点：
1️⃣ 全新功能上线
热点图分析：精准追踪用户点击、滚动、停留热区，优化页面布局与转化路径；错误监控：实时捕获前端JS错误、资源加载异常，保障网站稳定性；SPA深度适配：完美兼容Vue、React等框架，支持动态路由与异步加载数据追踪。
2️⃣ 行业独家能力
可用性监控：全球首创实时宕机告警，保障业务7×24小时在线；AI智能分析：本月即将开放AI驱动的崩溃预测、用户行为预测功能，提前预判风险；数据安全认证：通过国家等保、工信部、公安三重备案，代码开源透明，数据全链路加密。
3️⃣ 为何选择MXANA？
✅ 100%免费：无流量上限，无需担心成本；✅ 亿级PV支撑：日均处理能力超10亿次访问，稳定可靠；✅ 极简集成：3分钟接入，支持网站、APP、小程序全平台；✅ 企业级保障：电商、影视、游戏等行业用户验证，转化率提升15%-25%+。
🔥 注册即享：永久免费使用所有高级功能！
🌐 立即体验：https://www.mxana.com
安全、高效、透明，选择MXANA，绝不会错！ ...查看全文

​​在操作系统中，进程间通信（IPC）是协调多任务执行的关键技术。由于进程隔离机制的存在，不同进程的内存和数据空间相互独立，直接访问被严格禁止。为突破这一限制，操作系统设计了共享内存、Socket等多种IPC方案，而在Android系统中，Binder机制凭借高效性与安全性成为核心通信框架。
以32位操作系统为例，系统通过虚拟地址空间划分实现进程隔离：最高1GB地址空间（0xC0000000~0xFFFFFFFF）分配给内核，剩余3GB（0x00000000~0xBFFFFFFF）由用户进程独占。这种设计通过限制进程权限保障系统安全——内核空间可执行特权指令，而用户空间仅能运行非特权代码。CPU的Ring0~Ring3特权等级进一步强化了这种隔离，Linux系统仅使用Ring0（内核态）和Ring3（用户态）两个级别，确保关键系统资源不被恶意篡改。
不同于Socket等原生内核支持的IPC机制，Binder通过Linux的动态可加载内核模块（LKM）机制实现。该模块以内核态运行，作为用户进程间的通信桥梁。当用户进程通过Binder进行跨进程调用时，数据无需多次拷贝，而是通过内存映射（mmap）技术直接在内核空间与用户空间传递。这种设计显著减少了数据复制次数，优化了通信效率。
传统IPC机制通常需要两次数据拷贝：先从发送方用户空 ...查看全文

​​在Android开发中，卡顿与掉帧问题始终是开发者与用户关注的焦点。这类问题不仅直接影响用户体验，甚至可能成为用户流失的导火索。本文将通过真实案例剖析与技术原理分析，揭示Android卡顿问题的三大核心诱因，并结合系统级优化策略与应用层实践，提供一套完整的性能优化方案。
案例一：开机桌面滑动卡顿的溯源
某机型在首次开机后滑动桌面时出现明显卡顿。通过Systrace工具追踪发现，问题根源在于系统框架层的Binder调用阻塞。当桌面应用UI线程通过Binder向PackageManagerService（PKMS）发起getActivityInfo请求时，PKMS内部因持有全局锁执行磁盘写入操作，导致线程阻塞。此时，PKMS的锁对象已被7个线程等待，新请求线程被迫加入锁竞争队列。更严峻的是，持有锁的线程因CPU调度优先级较低，在开机高负载场景下长期处于饥饿状态，最终引发连锁反应。
针对此类问题，Android系统持续演进优化策略。例如，Android P引入LockFreeAnimation机制，通过避免在持有WindowManagerService锁时播放动画，显著降低卡顿风险；Android 12则在PackageManager中采用只读快照技术，使锁争用率下降92%。厂商侧也可通过缓存策略缩短持锁时间，或调整CPU/IO资源调度优先级，缓解系统级阻塞。
...查看全文

​​Nubia 分享过一个APP性能卡顿案例，链接见：Android卡顿掉帧问题分析之实战篇 - 简书，说的是三方应用唯品会的首页界面上下滑动严重掉帧卡顿。
系统内存不足，kswapd 线程唤醒进行内存回收。一个是占用 cpu 资源，一个是导致唯品会 app 的 page cache 被回收。唯品会 app 作为当前应用，本身就要读写文件，io 问题又进一步加剧。
标准 linux 内核中，kswapd 负责页面回收（包括 Page Cache 的回收），其回收策略并非直接以进程为维度，而是通过内存的活跃性（Active/Inactive LRU 链表）和内核的回收算法间接实现的。
​以下是具体机制：
Linux 内核将页面分为两类 LRU 链表（每个内存节点和区域均有独立的链表）：
Active List：存放最近被访问过的“活跃”页面。Inactive List：存放可能未被频繁访问的“非活跃”页面，优先从这里回收。
Page Cache 页面（文件缓存）会被挂到这些链表中，并根据访问频率动态调整（通过“第二次机会”算法或类似机制）。
kswapd的回收逻辑主要基于以下原则：
优先回收 Inactive List：首先尝试回收 Inactive List 中的页面，如果不足才会从 Active List 中迁移页面到 Inactive List。区分文件页（Page Cache）和匿名页：文件页（Page Cache）：可被直接回收（丢弃后可从磁 ...查看全文