广西住建局和城乡建设局网站工信网企业查询

广西住建局和城乡建设局网站,工信网企业查询,2021年资料员报名入口官网,建盏世家直播近期#xff0c;Android 官方宣布了 Android Runtime 在编译时间上实现了 18% 的显著优化#xff0c;同时不牺牲编译代码的质量#xff0c;也没有增加峰值内存使用#xff0c;换句话说#xff0c;这属于是一个“速度提升 零损失”的优化成果。 实际上这个调整作为 2025 …近期Android 官方宣布了 Android Runtime 在编译时间上实现了 18% 的显著优化同时不牺牲编译代码的质量也没有增加峰值内存使用换句话说这属于是一个“速度提升 零损失”的优化成果。实际上这个调整作为 2025 年的关键 KPI 目前已经实现了分阶段 rollout部分优化已经在 2025 年 6 月的 Android 发布中上线其余会在年底发布中完成所有运行 Android 12 及以上版本的用户都可以通过 mainline 更新得到这些改进。“mainline 更新” Project Mainline / Google Play System Updates 是一种模块化更新机制它支持 Google 通过 Google Play 直接更新 Android 系统的核心组件如Android Runtime、媒体框架、安全模块等这个更新不需要用户等待 OTA 。而这次优化更加具体的说就是编译时间减少了 18%对编译器最终输出质量没有负面影响没有出现内存回归就是提升过程中不增加内存占用峰值并且这些改进对于 JIT 和 AOT预先编译 都有用当然这里提到的 Android RuntimeART“编译速度”不是你在本地用 Gradle 构建 APK 的速度而是「设备端 ART 对 app 字节码进行 AOT / JIT 编译的速度」一般而言针对ART 内部的“编译器执行速度”会有JIT 编译速度AOT / dex2oat 编译速度编译器各个 IR / 优化 pass 的执行时间例如在 ART 里有很多 pass比如 GVN、某些数据流分析每次都会遍历 IR即使当前方法根本不满足优化条件也会完整跑一遍逻辑这种行为带来的开销并没有产生收益官方提到在之前有一个名为全局值编号 (GVN) 的阶段这个过程里它有一个名为Kill的方法这个方法会根据过滤器删除一些节点由于它需要遍历所有节点并逐个检查因此非常耗时而事实上无论当时有多少节点存活其实都能预先知道检查结果为 false 那么在这种情况下完全可以跳过遍历从而将性能消耗从 1.023% 降低到约 0.3%并将 GVN 的运行时间缩短约 15%。其他的一些案例包括有FindReferenceInfoOf的查找优化LoadStoreAnalysis阶段的方法FindReferenceInfoOf原本使用线性搜索 O(n) 在向量中查找而现在将数据结构改为以指令 ID 为索引实现 O(1) 查找并预分配向量以避免 resize 从而在这个阶段加速 34 - 66%总编译时间提升 0.5-1.8%虽然增加了一个计数字段但峰值内存没有增加。结构调整代码库中使用了一个自定义的HashSet多年前是为了处理极少数的大型集合而优化的但现在的用法变成了创建大量小型的、短生命周期的集合所以本地调整实现以适应“小而短”的用法减少创建和销毁开销从而让编译时间提升 1.3-2%且内存使用量反而下降了 0.5-1%。还有通过将数据结构以引用方式传递给 lambda 表达式避免了数据结构的复制从而将编译时间缩短了约 0.5% 到 1% 这一点在最初的代码审查中被忽略了并在代码库中保留了多年内联 (Inlining) 检查编译器为了性能会内联函数原本的流程是先计算大量数据最后再做“最终检查”如指令数、寄存器需求决定是否内联而现在将这些检查从“计算后”移到了“计算前”作为启发式规则Heuristics避免了大量无效计算仅指令数检查一项的移动就带来了约 2% 的提升。事实上官方在进行这些调整时也遇到了不少问题因为即使你发现某个区域占用了大量编译时间并且投入了开发时间尝试改进有时也找不到解决方案当你修改了 A 问题后自然而然就带了 B 问题比如内存回归在优化“输出写入”阶段时团队通过缓存计算值来加速原本预计提升 1.3-2.8%但自动化测试时发现额外的缓存数据结构导致了内存使用量的显著增加历史遗留负担许多低效代码是因为历史原因遗留下来的比如上述的HashSet或者是因为代码审查疏忽将对象按值传递而不是按引用传递复杂度的权衡某些优化方案可能过于复杂或者会增加代码维护难度针对这些问题官方进行了一系列的调整尝试重构解决内存回归针对“输出写入”阶段的内存问题本次直接重构了该阶段的逻辑这里设计了一种新方案移除了两个冗余数据结构中的一个这不仅解决了内存回退问题还进一步提升了 0.5-1.8% 的速度使用 pprof 进行深度分析利用pprof工具生成 Flame Graph和 Bottom-up 视图精准定位那些“隐形”的开销如频繁的Kill方法或意外的对象拷贝“快速迭代”策略为了节省开发时间先用原型Prototype在典型应用First-party apps, Android OS上快速验证想法确认收益后再进行完整的工程实现和测试利用全新 C 特性比如使用BitVectorView替代可变长的BitVector并利用模板化实现让Union()操作在 64 位平台上一次处理两倍的位数除此之外还有Add bookkeeping 将编译时间缩短约 0.6-1.6%Lazily compute data 来避免循环计算Refactor our code 跳过不会用到的预计算工作Avoid some dependent load chains 如果可以从其他地方轻松获取 allocator避免在寄存器分配中频繁地对寄存器类型核心/浮点进行分支确保某些数组在编译时已初始化不要依赖 clang 来完成这项工作优化一些循环 使用范围循环因为 clang 可以更好地优化范围循环避免因循环副作用而重新加载容器的内部指针避免在循环中通过内联的InputAt(.)为每个输入调用虚函数HInstruction::GetInputRecords()利用编译器优化 避免在访问者模式中使用 Accept() 函数最后最后看不懂不要紧只需要知道它很牛逼并且还能让 Android 12 以后的机器变得更快在用户端体现出来就是app 启动更快冷启动更少卡顿低端机更友好安装 / 更新变快同时也展示了教科书级别的优化策略不仅要看速度更要看内存、稳定性、可维护性等综合指标所以官方这份报告不仅仅是技术公告更是一份优秀的编译器工程的案例研究。参考链接https://android-developers.googleblog.com/2025/12/18-faster-compiles-0-compromises.html