随着AI浪潮的兴起,越来越多的应用都在利用大模型重构业务形态,在设计和优化Prompt的过程中,我们发现整个Prompt测评和优化周期非常长,因此,我们提出了一种Prompt生成、评估与迭代的一体化解决方案,以解决Prompt测评和优化过程中的挑战,加快业务和大模型结合的速度。
这篇文章会全方位讲解事件循环机制,从这篇文章你可以学到,「事件循环」和「浏览器渲染」的关系,浏览器setTimeout、requestAnimationFrame(RAF)、requestIdleCallback(RIC)等API在事件循环的「执行时机」,导致浏览器卡顿的原因、交互指标是如何测量的以及如何提升网站的交互性能。
本文将简单介绍搜索展现服务发展过程,以及当前其面临的三大挑战:研发难度高、架构能力欠缺、可复用性低,最后提出核心解决思路和具体落地方案,期望大家能有所收货和借鉴。
百度APP作为日活过亿的国民级应用,经过这些年的发展,从最初的搜索,发展到现在包含搜索、Feed、视频、直播、小说、购物、小程序、网盘和众多垂类模块的超级应用,为服务更多用户满足更多用户需求不断迭代,应用像滚雪球一样越滚越大,包体积从最初的几十MB发展到最高时的420MB,每个版本自然迭代会有至少3MB的涨幅,过大的包体积带来的负面作用开始显现,400M的体积对下载转化率和卸载率提出了很大的挑战,因此包体积成为百度超级APP发展的拦路虎。 22年Q3开启包体积优化项目,从编译器优化(OC&Swift&C++优化、LTO优化、剥离调试符号、三方SDK优化)、图片优化(无用图片、HEIC图片优化、Asset Catalog图片优化、图片压缩)、资源瘦身(大资源优化、无用配置文件、重复资源)、代码瘦身(无用类、无用方法、无用模块、精简重复代码、工具类瘦身、AB实验固化)和工程架构(Xcode打包、防劣化)等方向做优化。 在满足正常业务迭代情况下,优化落地收益50M,百度APP包体积从七月初的395M下降到十二月末的352M,同一时间段内,国内大厂主流APP中,微信从502M上涨到530M,
百度APP iOS端包体积优化系列文章的前三篇重点介绍了包体积优化整体方案、图片优化和资源优化,图片优化是从无用图片、Asset Catalog和HEIC格式三个角度做深度优化,资源优化包括大资源优化、无用配置文件和重复资源优化,本文重点介绍代码优化,在百度APP实践中,代码优化包括无用类优化、无用模块瘦身、无用方法瘦身、精简重复代码、工具类瘦身和AB实验固化。在代码优化过程,需要分析Mach-O和Link Map,在前面的文章我们已经针对Mach-O文件做过了分析,本文先介绍Link Map文件,然后再详细介绍代码优化方案。