最新文章
采集自各技术站点的近期文章。
CSS reading-flow和reading-order属性简介
阅读流(reading-flow)和阅读顺序(reading-order)是两项用于改进网页键盘无障碍访问的新CSS属性。它们解决了传统tabindex属性在复杂页面中容易产生全局索引冲突的问题,特别适用于视觉顺序与DOM顺序不一致的布局场景。这两个属性需与Flex或Grid布局配合使用。 在Flex布局中,reading-flow的常用值为flex-visual,它强制Tab键的焦点顺序与视觉排列顺序(即order属性调整后的顺序)一致,而非DOM顺序。另一个值flex-flow则使焦点顺序与flex-flow属性定义的方向保持一致。 在Grid布局中,reading-flow提供了更多选项:grid-rows使焦点按行逐个移动,grid-columns使焦点按列移动,而grid-order则优先按照CSS order属性定义的顺序来聚焦元素。 当需要更精细地控制单个子项的焦点顺序时,可以配合reading-order属性使用。通过将reading-flow设置为source-order,并为目标元素指定reading-order的数值(支持负值),可以强制该元素在焦点序列中的位置。这两项特性目前主要由Chrome浏览器支持,属于渐进增强特性,建议在Flex布局中默认添加reading-flow: flex-visual,以在支持时提升用户体验。
CSS锚点定位实战-鼠标跟随交互效果
本文通过两个实战案例,详细介绍了如何利用CSS锚点定位(Anchor Positioning)API,实现仅用纯CSS即可完成列表项的交互动效,从而替代传统的JavaScript方案。首个案例展示了单选按钮选中状态时,一个绿色对勾标记如何自动、平滑地动画跟随到当前选项,其原理是将伪元素作为锚点定位的目标对象,并通过`:has()`伪类在选中时为对应标签动态设置`anchor-name`。第二个案例实现了菜单项的悬停跟随高亮效果,背景高亮区域(伪元素)的尺寸和位置完全由`anchor-size`和锚点位置自动计算和适应,无需JavaScript介入布局。文章强调,锚点定位极大简化了浮层与交互元素的定位逻辑,具备自动调整方向和尺寸适应的能力,且可作为渐进增强特性使用,在不支持的浏览器中退化为静态背景,不影响基本功能,适合在现有项目中逐步采用。
Foundation Models:苹果设备端模型的边界探索
苹果在WWDC 2025推出的设备端Foundation Models框架,旨在让开发者使用离线模型执行基础AI任务。当前beta 1版本测试显示,框架稳定性出人意料地高,已接近可用于生产环境的状态,但开发者需清晰认知其边界与限制。 实际测试中,该框架运行时总内存消耗约为1.0至1.5GB,其中模型权重占用约750MB。性能方面,针对不同复杂度的提示词,模型响应速度存在差异。虽然功能可用,但模型能力仍集中于基础任务,在复杂推理或长文本处理上存在明显上限。需要强调的是,本次测试基于macOS/iOS/Xcode 26 Beta 1环境,模型会随系统版本持续迭代更新,实际发布版本的性能与边界可能存在变化。总体而言,它为端侧AI开发提供了新的可能,但开发者需结合其能力范围进行架构设计。
扫描全国的公网IP需要多久?
作者基于个人兴趣,在一台旧款4核迷你主机的家庭网络环境下,测试了扫描中国大陆所有公网IP地址的耗时。最终扫描约3.43亿个地址,发现其中约592万个IP可达,总耗时约1小时2分58秒。该测试旨在探索使用单台设备探测全国范围内运营商与云服务商网络连通性、识别故障或劫持情况的技术可行性。 文章核心是介绍了一款由作者重构的网络扫描程序的实现。新版本摒弃了之前依赖libpcap库的gopacket方案,完全基于Go标准库中的icmp与ipv4扩展包构建,无需启用CGO,便于部署与编译。程序架构采用并发模型,主要由三个goroutine协作:一个负责解析APNIC提供的IP网段列表并分发任务;一个负责批量构造并发送ICMP回显请求报文;一个负责监听并接收ICMP回显应答,最终将存活IP输出。代码通过设置BPF过滤器优化性能,并使用进程ID作为ICMP报文标识以准确匹配响应。整个扫描引擎仅约200行代码,展示了使用Go语言进行高效网络编程的典型范例。
啥时候等到Go官方支持SIMD?
Go语言目前缺乏官方的SIMD(单指令多数据流)支持,这一议题在官方问题追踪中持续讨论但进展缓慢。SIMD能显著提升图像处理、机器学习等计算密集型任务的性能,是C++、Rust等语言已具备的能力。Go语言追求简洁性与可移植性,而SIMD实现需针对不同硬件架构进行优化,两者存在设计冲突,导致官方支持犹豫不决。当前,标准库中已局部引入SIMD指令(如Go 1.24中Swiss Tables的实现以及crypto/sha256包),但编译器并未提供自动向量化功能。社区为弥补空缺,开发了第三方库如kelindar/simd、alivanz/go-simd和pehringer/simd,它们通过汇编或自动向量化技术在Go中实现了SIMD操作,但这些方案需要开发者自行管理,可移植性和维护性有限。总体而言,Go在高性能计算领域的潜力受限于SIMD支持的缺失,未来官方的整合将对性能优化至关重要。
unzip: unsupported compression method 99
该文章属于故障排查类内容,记录了处理AES-256加密ZIP文件时遇到的兼容性问题及其解决方案。标准unzip工具因不支持“压缩方法99”(通常与AES加密相关)而解压失败,尽管WinRAR可以处理,但命令行工具unrar同样不支持。解决方案是使用功能更强大的7zip工具。在Windows环境下使用7zip解压时,可能出现文件名乱码问题,通过指定编码参数(如-mcp=65001代表UTF-8)可解决;反之,若需在Linux下解压Windows压缩的文件且避免乱码,则应使用GBK编码(-mcp=936)。此外,文章强调了文件扩展名必须为.zip,若改为.7z会导致无法识别的错误。
dns over https 转发
该方案旨在应对办公网络中ISP强制的DNS劫持问题,通过建立内网DNS服务以提供不受污染的解析。核心方法是首先在系统hosts文件中将域名`doh.pub`静态解析至IP地址`120.53.53.53`,以此规避可能的劫持。随后,使用gost v2工具搭建一个DNS服务器,该服务器监听指定的内网IP地址的53端口(UDP协议),并将所有收到的DNS查询请求通过HTTPS协议转发至`https://doh.pub/dns-query`,从而实现DNS-over-HTTPS(DoH)转发。实施时需注意:修改hosts是确保不被劫持的关键步骤;gost工具需从其GitHub仓库获取;由于可能与systemd占用`127.0.2.1:53`冲突,服务不应监听`0.0.0.0`,必须指定具体的内网IP地址。
清理阿里云自带的垃圾服务
阿里云为ECS实例预装了一系列默认服务,这些服务在低内存规格主机上常导致资源占用过高,引发内存不足(OOM)问题。本文针对512M内存主机出现的故障,详细介绍了卸载和禁用这些“自带垃圾服务”的具体方法。 问题主要涉及三类组件:云盾安全客户端(AliYunDun)、云助手自动化工具(aliyun-assist)以及云监控代理(cloudmonitor)。文章提供了每类组件的官方卸载文档链接,并汇总了通过命令行彻底停止进程、删除服务文件和目录的完整步骤。例如,卸载云助手需执行停止守护进程、终止相关进程并移除目录等一系列命令。 此外,文章更新补充指出,阿里云的默认Ubuntu镜像还启用了多个占用内存的系统级服务,如`tuned`性能调优、`multipathd`多路径设备管理以及`fwupd`固件更新服务等。针对这些,建议使用`systemctl disable`命令将其禁用,以进一步释放系统资源。 通过执行上述卸载和禁用操作,可以显著降低主机的后台资源占用,有效解决小内存实例因服务进程过多导致的内存溢出问题,恢复系统稳定运行。
zerotier moon server
该教程详细介绍了如何在自有服务器上部署ZeroTier Moon服务器及其Web管理界面ztncui。首先需开放UDP 9993端口,通过官方脚本安装ZeroTier并生成服务器身份文件。核心步骤是在moon.json配置文件中添加服务器的公网IP地址作为稳定端点,随后生成签名后的moon文件并将其放入moons.d目录以重启服务生效。 管理界面部署部分依赖Node.js环境,通过克隆ztncui项目并安装依赖完成。关键配置在于.env文件中需填入ZeroTier认证令牌,并可通过修改参数控制Web服务监听端口及网络暴露范围。教程强调了通过SSH端口转发或HTTPS进行安全访问的必要性,以避免HTTP明文传输风险。最后,使用pm2实现服务常驻运行,并通过Web界面创建网络、生成地址,最终在客户端加入网络并经批准完成组网。
家庭网络拓扑升级
该文阐述了家庭网络拓扑从初始运营商设备升级至软路由架构的过程,核心目标是解决孩子设备过度使用的技术管理难题。初始阶段,用户尝试通过物理断网或路由器黑名单(基于MAC地址)限制设备接入,但孩子通过修改设备MAC模式为随机地址绕过控制。为此,用户引入二手x86主机刷入OpenWrt系统作为主路由,构建新拓扑:光猫与路由器启用MAC地址白名单,仅允许可信设备接入;OpenWrt负责网络过滤和DNS加速,TP-Link WiFi7路由器承担用户行为管理与无线接入,同时设置光猫备路由保障稳定性。升级后,用户发现OpenWrt的DNS Fake-IP模式影响ping/dig命令执行,部分应用如小米天气因UDP问题无法连接,且整体网络出现不稳定迹象,初步推测与代理配置相关。后续计划包括排查网络卡顿根源、启用IPv6与DDNS以实现外网访问、以及为机柜添加温度监控。此外,文章强调了设备管理需结合沟通策略,基于对孩子使用手机潜在危害的认知(如网络负面影响、成瘾风险),通过协商制定使用计划来平衡技术控制与教育引导。
Android ANR 系列 1 :理解 Android ANR 设计思想
Android ANR(应用无响应)机制是系统层面为保障稳定性而设计的核心防御体系,其设计思想远非简单的“主线程超时”。ANR的实质是系统通过跨进程的协同监控与强制干预,对应用行为实施严格约束与熔断,以在开放生态中防止单点故障蔓延。系统将应用ANR与系统级无响应(SNR)明确区分,分别采用事件驱动检测和主动轮询两种不同的治理策略。 ANR监控由system_server进程主导,核心分为两类。组件类ANR通过ActivityManagerService追踪异步任务生命周期,采用“派发-回调-熔断”模型,利用Binder同步调用与Handler延迟消息构建超时检测机制。输入类ANR则更为复杂,InputDispatcher通过socket与应用建立事件通道,依赖队列状态管理(inboundQueue、outboundQueue、waitQueue)和超时检测(默认5秒)来监控事件处理流程。此外,No Focused Window类ANR反映了窗口焦点状态异常,导致事件无法分发。 该机制遵循状态可追踪、故障隔离和用户控制权兜底的设计原则。当超时触发时,系统执行多维熔断:采集线程堆栈与性能数据至traces.txt、隔离问题进程资源、并弹出提示将最终决策权交予用户。这种设计强制开发者关注主线程响应性与异步架构。 ANR问题的分析与治理也已演进为一套方法论,从依赖traces.txt的静态堆栈分析,发展到使用systrace/perfetto进行动态追踪,再到利用机器学习预测复杂根因。最终,治理的目标是走向架构预防性设计,例如约束通信拓扑、管理资源预算与强化异步边界,从而在代码层面内化系统约束,从源头预防ANR。
Android Perfetto 系列 4:使用命令行在本地打开超大 Trace
针对Android性能分析中遇到的超过2GB的大型Perfetto Trace文件无法在网页端直接打开的问题,本文介绍了使用官方提供的trace_processor_shell命令行工具进行本地解析的解决方案。由于浏览器存在内存限制,超大Trace文件会导致在线分析工具失效。trace_processor_shell是Perfetto的核心组件之一,它基于Rust/C++实现高性能解析引擎,能够绕过浏览器限制,在本地高效处理大文件。用户需从GitHub下载对应平台的工具包,然后通过命令行添加`--httpd`参数启动本地服务,之后再访问Perfetto UI界面,选择连接该本地服务进行分析。文章对比了命令行启动与直接使用网页UI两种方式的核心区别:命令行模式提供原生加速、支持高级SQL查询和状态保持,适合复杂的大文件分析;而网页UI模式则更便捷,支持分享等功能,但性能受限。此外,文章还提醒了Mac系统可能遇到的安全权限问题及解决方法。整体而言,该工具为深度性能分析提供了更强大的本地处理能力。
Android Weekly 2025-06 期
Android Weekly 2025-06期聚焦Android技术生态的最新动态与深度解析。在UI与渲染层面,详细对比了传统DiffUtils与Jetpack Compose在列表更新中的机制差异,并深入探讨了如何通过GPU硬件加速、RenderThread优化动画流畅度,以及分析了Android系统的渲染流程与Vsync信号处理。工具与调试方面,介绍了如何使用Perfetto分析渲染机制及在本地处理超大Trace文件,以及利用Frida实现JNI方法的动态跟踪、反汇编与代码补丁。此外,内容还涵盖了Compose与原生View的跨平台混排原理、使用ASM进行字节码插桩、理解ANR设计思想,以及Android Gradle任务机制解析。AI融合趋势明显,探讨了移动端相册如何利用CLIP模型实现AI搜图,以及DeepSeek-R1等推理模型的技术突破。最后,部分文章延伸至内核技术,如鸿蒙微内核论文解读和并发错误检测方法。整体内容广泛覆盖从底层系统到上层应用开发的关键技术点。
Android Perfetto 系列 5:Android App 基于 Choreographer 的渲染流程
Choreographer 是 Android 渲染管线中承上启下的核心协调者,负责配合 Vsync 信号,为上层应用提供稳定的渲染时机,从而确保流畅的帧率输出。当 Vsync 信号到达时,Choreographer 会被唤醒,并按顺序执行 Input、Animation、Traversal(包含 Measure、Layout、Draw)等关键回调,集中处理一帧的所有更新操作。这一机制取代了早期帧与帧之间无间隔处理的模式,避免了因屏幕刷新周期不匹配而导致的帧率不稳和掉帧问题。 现代 Android(Android 12+)在 Choreographer 调度 UI 线程渲染的基础上,引入了 BlastBufferQueue 机制。RenderThread 可以通过 BlastBufferQueue 更独立地向 SurfaceFlinger 提交帧数据,而 UI 线程不必等待 RenderThread 完成当前帧即可开始准备下一帧,进一步减少了主线程的阻塞时间。深入理解 Choreographer 的初始化流程、Vsync 信号接收方式(如通过 BitTube 与 SurfaceFlinger 通信)以及其与 MessageQueue 的交互,有助于开发者从根本上理解每一帧的运行原理,并利用这些机制进行针对性的性能监控与优化。
Android Weekly 2025-15 期
本期Android Weekly聚焦于性能优化、架构分析、工具链演进及新兴AI技术在移动端的应用。性能优化领域探讨了多层次策略:从“扁鹊三兄弟”故事出发,强调通过编程范式进行预防性设计;介绍了基于预测模型提升GPU绘制效率的方法;提供了在无法adb连接时通过配置文件抓取开机trace进行性能分析的实战指南;并记录了使用perf工具在线定位死循环bug的处理过程。在架构与源码层面,深入剖析了NowInAndroid项目的模块化与数据流设计,以及MMKV相比SharedPreferences在文件操作和数据格式上实现高性能的原理。工具与语言方面,关注到IntelliJ IDEA 2025.1默认启用K2模式以提升Kotlin处理性能,同时提供了Jetpack Compose的性能优化建议以平衡其便利性与渲染开销。系统层面,分析了Linux异构CPU环境下的Misfit任务迁移调度、Android V应用冷启动的Activity生命周期机制,以及Android 16 Beta 4中需关注的JobScheduler、广播和安全等行为变更。此外,周刊还涵盖了Android副屏录制方案、AI编译器基础设施(MLIR)、GPT4.1模型能力对比,以及自适应流媒体等跨领域技术解析,为开发者提供了广泛的技能更新与技术视野。
Android Weekly 2025-16 期
本期内容聚焦Android技术生态的深度实践与前沿探索。系统层面深入剖析了GPU架构互联、eBPF调度器优化、渲染管线优化及内存管理机制,并结合OPPO极光引擎并行绘制、抖音renderD128 OOM疑难排查等实战案例,分享了性能调优与故障定位的深度经验。跨平台领域关注Flutter线程模型重构、TikTok开源框架Lynx的技术特点及Compose Multiplatform iOS稳定版发布。AI辅助开发成为亮点,涉及MCP协议实践、Cursor/Codex等智能编程工具的应用心得,以及大语言模型在编译优化中的新思路。此外,内容还涵盖Binder原理、CFI安全机制、AOSP代码贡献流程、16K页适配等核心知识,整体展现了当前Android开发在系统底层优化、跨平台效率提升与AI工具融合方面的关键动向与解决方案。
Android Perfetto 系列 07 - MainThread 和 RenderThread 解读
本文是Android Perfetto性能分析系列的第七篇,聚焦于主线程(MainThread)与渲染线程(RenderThread)的深入解读。文章旨在帮助开发者利用Perfetto工具,精准分析应用渲染流程,定位卡顿与掉帧问题的根源。核心内容阐述了自Android 5.0引入的双线程渲染架构:主线程负责处理用户输入、执行View的测量、布局与绘制准备(构建DisplayList);渲染线程则专注于通过GPU异步执行渲染命令,提升帧生成效率。文章详细剖析了一帧的完整生命周期,从等待Vsync信号唤醒,到主线程处理输入与动画、执行核心的Traversal(测量、布局、绘制)三阶段,再到通过syncAndDrawFrame将DisplayList同步给渲染线程,最终由渲染线程完成GPU渲染并提交帧至SurfaceFlinger进行合成显示。通过对Perfetto trace中关键事件(如UI Thread的performTraversals、RenderThread的drawing与queueBuffer)的识别与解读,开发者能够理解帧渲染各环节的耗时分布,从而有效区分性能瓶颈所在,并掌握软件绘制与硬件加速模式下的不同Trace表现。
Android Perfetto 系列 8:深入理解 Vsync 机制与性能分析
Vsync(垂直同步)是Android图形系统的核心同步机制,旨在协调软件渲染与显示硬件的刷新节奏,从根本上解决屏幕撕裂问题。Android的Vsync体系采用分层架构:由硬件Vsync(HW Vsync)提供精确时钟基准,但为省电常采用软件预测;进而派生出驱动应用渲染的Vsync-app和负责图层合成的Vsync-sf,Android 13还新增了vync-appSf以优化同步。在Perfetto中,可通过跟踪vsync-app、vsync-sf及HW_VSYNC的状态变化来分析时序,同时结合应用主线程的Choreographer#doFrame和渲染线程的queueBuffer等切片,可完整观测帧流水线。应用帧的生产严格遵循“申请Vsync-接收信号-执行渲染-提交合成”的流程,其关键约束在于BufferQueue时序与多缓冲机制。通过配置Vsync Offset(如appOffset与sfOffset之差),可以调整应用与SurfaceFlinger接收信号的时间差,将显示延迟从约两个周期缩短至一个周期,显著提升交互跟手性。理解这些机制及其在Trace中的表现,是分析高刷新率设备性能瓶颈的基础。
Android Perfetto 系列 (九) - CPU 信息解读
作为Android性能分析系列教程的第九篇,本文聚焦于利用Perfetto工具深入解读CPU信息,以定位性能瓶颈和功耗问题。文章核心在于解析Perfetto UI中三个关键CPU轨道:调度(展示各核心运行线程)、频率(记录核心频率变化)和空闲状态。教程详细阐述了现代异构多核架构(big.LITTLE)的任务分配逻辑,指出需将任务属性与核心类型匹配以判断调度合理性。深度剖析了Linux线程状态,重点区分了Running、Runnable(含三种抢占类型)、Sleep及关键的D(不可中断睡眠)状态的成因与性能影响,并介绍了通过Perfetto可视化唤醒关系链来分析线程依赖的方法。在CPU频率方面,文章解析了影响频率的任务负载、场景策略、温度控制与功耗限制等多重因素,强调频率需结合核心类型和系统约束综合评估。最后,阐述了Linux内核调度器(如EAS)的核心行为:基于任务利用率和能效模型进行选核,以及为进行负载均衡或适应唤醒时变化而发生的核心迁移。整体为读者提供了一套从数据采集、状态解读到调度策略分析的系统性CPU性能分析框架。