menu

前沿技术周刊 #9

前沿技术周刊 是一份专注于技术生态的周刊,每周更新。本周刊深入挖掘高质量技术内容,为开发者提供持续的知识更新与技术洞察。

订阅渠道:【零一开源】、 【掘金】、 【RSS


大厂在做什么

抖音长期存在renderD128内存占用过多导致的虚拟内存OOM,且多次出现renderD128内存激增导致OOM指标严重劣化甚至发版熔断。因受限于闭源的GPU驱动、现场有效信息极少、线上线下的Native内存检测工具均未能检测到相关内存分配等原因,多个团队都进行过分析,但一直未能定位到问题根因,问题反馈到厂商也一直没有结论。
在当今数字化时代,动效设计已成为用户体验设计中不可或缺的一环。它不仅显著提升了用户体验,增强了用户粘性,还为业务带来了可观的收益。一个好的动效自然离不开专业且实用的动效设计工具,本文将为大家介绍一款我们自研的动效编辑器,旨在为动效设计师以及相关业务合作的同学提供一个高效、便捷且功能强大的创作平台,让设计师可以高效智能地设计动效。
你是否想过,在这个互联网高度发达的时代,软件系统就像一个错综复杂的蜘蛛网?有时,哪怕只是改动了一行代码,或者调整了一个小小的配置,都可能像“蝴蝶效应”一样,在系统中引发一连串意想不到的严重后果。 就像南美洲的一只蝴蝶扇动翅膀,可能在北美引发一场龙卷风。在软件世界里,A,通过复杂的系统依赖关系,也可能导致整个系统崩溃。 那么问题来了:为什么小小的代码改动会引发大风险?传统的测试方法有哪些不足?我们又该如何利用AI构建一个智能的测试防御体系,让我们的系统更安全、更可靠?
近期,MCP在开发者社区中广受关注,成为业界热点。值得关注的是,Cursor编辑器在0.45.x版本中已正式加入了对MCP的支持。作为深度依赖Cursor的开发者们,理解MCP的核心概念及其应用场景,将有助于我们更高效地利用它来提升开发效率。
提到AI辅助开发,很多同学都吐槽过。 “AI写的代码都很垃圾啊,问AI问题很多时候就像对牛弹琴一样,答非所问”。 其实并不见得是AI无法胜任我们的开发需求,关键在于要掌握正确的使用方法,就像学习IDE和Git工具一样。 那为什么很多同学使用AI的效果不好呢?通常有以下三个原因:
btrace 是由字节跳动抖音基础技术团队自主研发的面向移动端的性能数据采集工具,它能够高效的助力移动端应用采集性能 Trace 数据,深入剖析代码的运行状况,进而辅助优化提升移动端应用的性能体验,提升业务价值。此次更新,我们重磅推出 btrace 3.0 版本,提出了业界首创的同步抓栈的 Trace 采集方案,实现了高性能的 Trace 采集。此外,新版本在支持 Android 系统的基础上,新增了对 iOS 系统的全面支持。


新技术介绍

最近看了篇讲 Swift 6.2 和 Java 互操作的文章,重点讲怎么在 Swift 里调 Java 代码,还有 Java 调用 Swift 的新 API。用 JNI 桥接那套比以前简化不少,基本数据类型直接传,对象也能自动转换。踩了几个坑,比如线程安全要自己处理,还有泛型支持有点坑,不过用作者给的那个内存管理工具能绕过去。试了下 demo,把老 Java 库直接迁到 Swift 项目里跑通了,性能损耗比预想的小,对混合开发的老项目挺香的。


深度技术

最近啃了篇SurfaceFlinger硬件Vsync的深度文,咱做Android Framework开发的,尤其车机手机这块,这玩意儿真是绕不开。简单说,硬件Vsync就是显示芯片/驱动给的垂直同步信号,比软件模拟的稳多了——SurfaceFlinger靠它对齐渲染和屏幕刷新,卡顿、掉帧少一半。文章里还对比了车机和手机的差异:车机屏幕大、多屏联动,对Vsync精度要求更高,有时候还得处理多显示设备的同步坑;手机则更关注低延迟,尤其高刷场景。对咱开发者来说,搞懂硬件Vsync的触发链路(从驱动到SurfaceFlinger的回调),调优UI性能、解决显示不同步问题,这篇真挺实用,推荐细品。
如果你经常开发 iOS 中的第三方框架,那么你可能会遇到以下错误: “Could not find module *** for target 'x86_64-apple-ios-simulator'.” 或者: “building for iOS Simulator, but linking in dylib built for iOS, file, ‘…/Frameworks/xxx.framework/xxx’ for architecture arm64.” 要解决这个问题,我们需要了解 CPU 架构和 Xcode 构建设置的一些知识,今天我们就来聊聊这个。
在引入b-l之后,问题其实变得更加复杂。很显然,同样的运行5ms,在100MHZ频率下运行5ms跟在200MHZ的频率下运行5ms。它们对于算力的需求是不一样的,最后的量化结果也应该是不一样的。同理,在小核上运行5ms跟在大核上运行5ms。需求跟量化结果也应该是不一样的。
在Linux 内核这片广袤而复杂的 “代码丛林” 中,内存管理无疑是最为关键且棘手的领域之一。内存越界错误,就像隐匿其中的 “幽灵”,神出鬼没,难以捉摸。它可能在系统运行的任何时刻悄然现身,一个不经意间,就可能引发系统崩溃、数据损坏等严重后果,令无数开发人员和运维工程师头疼不已。
025年,AI编程工具已经从简单的代码补全进化到了真正的编程伙伴。在这个变革的浪潮中,Cline作为VS Code的开源自主编程代理,配合强大的Claude API,正在重新定义开发者的工作方式。不同于传统的代码补全工具,这个组合能够理解复杂的业务逻辑,自主规划任务步骤,甚至能够操作浏览器进行端到端测试。
在Android Runtime(ART)中,调试检测与反制是保护应用安全的重要机制。随着移动应用安全威胁的不断增加,开发者需要采取措施防止应用被调试、逆向工程或篡改。ART提供了多种调试检测机制,包括调试器存在检测、内存完整性检查、代码注入检测等。这些机制通过系统调用、内存监控和安全标志位等方式实现,能够有效识别和阻止未经授权的调试活动。


码圈新闻

在我的NLP生涯的第一个十年里,我们没有这种选择的奢侈。在遥远的BERT时代(是的,已经过去七年了),模型必须先进行微调——和评估——才能迁移到新任务。这个过程通常每次迭代需要数周时间,尽管与今天的LLM相比,这些模型非常小。对于快速发展的应用,特别是在产品市场匹配(PMF)之前,这种缓慢的反馈循环是一个致命缺陷。这是我上一个创业公司的惨痛教训,当时我从头开始训练模型用于开放信息提取和语义搜索。然后GPT-3和Flan-T5出现了,我的内部模型一夜之间变得无关紧要。具有讽刺意味的是,这些相同的模型标志着上下文学习的开始——以及一条全新的前进道路。
最近刷到OpenAI发了ChatGPT Agent,看完真觉得程序员的生产力工具要变天了。 简单说,这玩意儿不是以前那种“你问我答”的聊天机器人了,它能自己接任务、拆步骤、调用工具跑完闭环。比如你让它“爬个数据生成周报”,它会自己判断要调什么爬虫库、怎么处理格式,甚至发现接口权限不够时,主动提示你需要补充哪些token——全程不用你手把手教,像个能独立干活的小助理。 对咱们写代码的来说,最香的是它能深度对接开发场景:写脚本时自动查文档补依赖,调接口卡壳了帮你定位错误日志,甚至写完还能顺手生成单元测试。以前两天的活儿,现在丢给它拆解,自己盯进度就行,省出的时间够摸鱼改三个bug了(不是)。 不过也得留个心眼:它自主决策时偶尔会“想当然”,比如默认用某个过时库,这时候还得咱们人工校准。但整体看,这波是把“工具辅助”升级成了“协作伙伴”,生产力边界确实被撕开个口子——以后拼效率,可能真得看谁先把Agent用明白。
区块链技术是稳定币和RWA的底层架构。区块链作为Web3.0的底层架构,通过哈希链接的区块结构(每个区块包含前一区块哈希值)实现公开透明、去中心化和不可篡改三大特性,并结合智能合约实现链上功能。稳定币与RWA离不开区块链底层架构的特性——稳定币以法币/国债等为锚定物,依托区块链智能合约实现1:1资产映射,成为连接传统金融与Web3.0的价值桥梁。
最近刷到个超酷的事儿!香港那边用稳定币搞跨境结算,居然10秒就能搞定!以前大陆企业搞跨境融资,又慢又贵,银行跑来跑去折腾半天,现在成本直接暴跌90%,简直离谱! 稳定币说白了就是挂钩法币的加密货币,再配上区块链技术,结算速度比传统银行快到飞起,中间那些乱七八糟的手续费、时间成本全砍了,难怪成本降这么猛。咱们计算机专业的一看就懂,这不就是分布式账本、智能合约那些技术落地了嘛!以前总觉得区块链离我们很远,不是炒币就是概念,现在看来是真能解决企业痛点,让钱流得又快又便宜。 这波操作真的让我觉得,技术落地才是硬道理,以后搞开发得多关注这种实际应用场景,太有搞头了!


博客推荐

刚看了KotlinConf'25那个Rich Errors新特性,感觉是真懂咱们天天跟异常/Result搏斗的痛啊! 以前写Kotlin,错误处理总有点拧巴:要么无脑抛异常(结果满屏try-catch,还不知道会抛啥),要么用Result包装(但里面Error类型太模糊,拿到手还得猜是IO错还是业务错)。这次新的Rich Errors直接给了套结构化方案——核心就是用密封类搞了个错误类型层级,比如NetworkError、ValidationError这种,每个错误还能塞详细信息(错误码、描述、堆栈上下文),类型清清楚楚。 最香的是它跟Result深度绑定了,以后可能直接写Result<T, MyError>,编译器会强制你处理每个具体错误类型(像when表达式那样,少一个分支都报错),再也不怕漏处理了。而且说是支持渐进式迁移,老代码里的Exception也能自动转成通用错误类型,不用一次性重构,这点很贴心。 感觉以后写接口不用再文档里瞎猜“可能抛出XX异常”了,直接在返回类型里把错误列明白,协作效率能提一大截。调试也方便,错误信息自带上下文,不用费劲扒堆栈了。总之这波更新,我愿称之为Kotlin错误处理的“脱胎换骨”,等正式版必上车!


GitHub 一周推荐

这是一个Android系统TTS应用,内置微软演示接口,可自定义HTTP请求,可导入其他本地TTS引擎,以及根据中文双引号的简单旁白/对话识别朗读 ,还有自动重试,备用配置,文本替换等更多功能。
插件化、定制化、无广告的免费音乐播放器


关于我们

零一开源】 是一个 文章开源项目 的分享站,有写博客开源项目的也欢迎来提供投递。 每周会搜集、整理当前的新技术、新文章,欢迎大家订阅。

[奸笑]