工程实践Grab Tech
Grab 工程博客介绍其 Android/iOS 超级应用在每周发布和 AI 辅助编码导致变更量上升背景下维持稳定性的分层防御体系。文章按预防、发布门禁和响应三阶段组织：合并前用 Lint 自定义规则及单元、UI、E2E、QA 测试拦截；发布前通过 GEA 内测和自动崩溃工单形成一周质量门禁；上线时用分阶段放量和功能开关控制爆炸半径；生产后用实时监控、自动分诊、功能开关历史和 Crashlytics 导出 BigQuery 加自定义元数据诊断。结论强调 shift-left，越早发现崩溃成本越低，无法完全消除的崩溃应纳入监控与遏制基线。适用边界是大型移动应用、多团队周发布场景，具体工具和数据来自 Android，iOS 使用等价工具。
推荐收录，因为文章完整展示了从 Lint 规则、测试分层、GEA 内测、分阶段放量、功能开关到实时监控和自动分诊的稳定性工程闭环，并给出崩溃暂停发布、热修复后补 Lint 规则等可验证实践。适合移动端负责人、SRE/稳定性工程师和多团队发布管理者参考。其分层检查点设计和“越左越便宜”的取舍可迁移到其他大型客户端，但具体阈值和工具链依赖 Grab 规模，需结合自身发布节奏调整。
工程实践Yelp Engineering
文章复盘 Yelp Assistant 这一面向消费者的 LLM 聊天产品 UI 的构建过程，核心问题是在移动端发版受应用商店审核约束、技术快速演进且决策容易过时的背景下，如何降低做决策与改决策的成本。作者介绍了 Yelp 自研的服务端驱动 UI 框架 CHAOS，并解释最终采用混合方案的原因：顶部栏与输入栏为原生实现，聊天内容区由 SDUI 渲染，因为 CHAOS 当时缺少网络请求和文本输入能力。文中给出将视图与数据分离、用 datasets 存储 MessageEvent、乐观插入用户消息与输入指示器、快速回复轮播、区分可恢复与不可恢复两类失败，以及用客户端动作 DisableChat 结束会话等实现细节。作者也坦承该方案的代价：团队需要额外时间熟悉 CHAOS 与架构，多平台一致性难以保证，并说明它如何为后续产品复用打下基础。
推荐收录。文章给出了完整的架构取舍证据：为何在原生与服务端驱动 UI 之间反复权衡、为何最终落在混合方案、CHAOS 当时缺哪些能力，以及视图与数据分离、MessageEvent、客户端动作等可验证机制。适合移动端与多平台前端架构师、做 LLM 产品工程化的读者，其“用 SDUI 换快速迭代、把决策成本显式化”的思路可迁移到其他客户端产品；风险是具体实现强依赖 Yelp 私有框架 CHAOS，需自行评估可移植性。
工程实践GitHub Security Lab
文章介绍 GitHub Security Lab 使用开源 Taskflow Agent 自动化审计 Android 应用并报告 24 个漏洞的实践。作者新增移动端入口点收集任务，并修改分类任务要求 LLM 按漏洞类别检查入口点，结合严格提示与多次运行提升发现率。案例包括 OsmAnd 导出 Activity 被恶意应用导入设置后窃取定位和路线，以及 Wikipedia Android 因 deeplink 域名后缀校验缺陷导致账户接管。作者指出 LLM 擅长发现逻辑漏洞和理解安全 API 行为，但严重性评估不准、易产生低危误报，需人工复核并生成 PoC。该方案适用于移动安全审计，但依赖 Copilot 许可、token 消耗大，且结果需验证。
推荐收录：文章给出了可运行的开放 taskflow 配置、跑法与 24 个真实 Android 漏洞的披露案例，而非泛泛讨论 AI 安全。它适合移动安全研究者、AppSec 工程师和 AI Agent 开发者，可迁移其入口点分类、漏洞类别提示与严格/宽松提示组合方法；同时明确提醒 LLM 严重性误判、误报和 token 成本，需人工复核。
技术文章Bram.us
文章介绍 WebKit 实现了 viewport meta 标签中的 interactive-widget 指令，并梳理其来龙去脉。背景是 Interop 2022 的视口调查工作：Chrome 108 把虚拟键盘弹出时的默认行为改为只缩放 visual viewport，与 Safari 对齐，但副作用是 position: fixed 内容会被键盘遮挡。为此引入 interactive-widget，提供 resizes-visual、resizes-content、overlays-content 三个取值，分别控制是否缩放 layout/visual viewport 或整体不缩放。作者本地编译 WebKit 并在 iPhone 模拟器的 MobileMiniBrowser 中验证三个取值均生效，Safari 正式版与 Technology Preview 尚未发布该特性，浮动地址栏等 Safari 特有 UI 的影响仍待实测；目前 Chrome 108 与 Firefox 133 的 Android 版已支持。
推荐收录：文章虽短，但由参与制定该指令的作者清楚解释了 interactive-widget 的三个取值语义、Chrome 108 改变默认行为的动机与副作用，以及各浏览器支持现状，属于一手技术资料。适合处理移动端虚拟键盘遮挡固定定位、需要控制视口缩放的前端开发者参考。主要风险是 Safari 尚未正式发布，实际行为可能变化。
工程实践Salesforce Engineering
文章以问答形式复盘 Salesforce 团队如何在 iOS、Android、React Native 和 Flutter 四套技术栈上构建实时移动个性化架构。核心矛盾是跨端渲染与生命周期差异、跨渠道身份拼接、隐私与同意、有限屏幕空间内的动态原生渲染，以及营销活动变更不应触发 App 重新发版。团队通过统一 schema、事件语义和 SDK API、桥接层复用原生能力，并把身份解析与决策保留在服务端，移动 SDK 只接收决策并渲染开发者注册的原生组件。同时将应用埋点与体验配置分离，用 content zones、模板和 CDN 下发配置，并提供二维码预览与模拟器注入真实画像来验证定向和布局。结论是“一次埋点、营销可配置、服务端决策、动态渲染原生组件”，但文章偏经验总结，缺少具体性能数据、失败案例和实现细节。
推荐收录，因为文章给出了跨 iOS、Android、React Native 和 Flutter 的实时移动个性化架构取舍：统一 SDK 与桥接层、服务端身份解析与决策、content zones/模板分离配置与代码、CDN 下发、二维码预览等。适合移动端、平台工程和个性化系统架构读者，可迁移到多端 SDK、跨渠道身份和低代码配置场景；但属于厂商经验总结，落地细节与失败边界有限，需结合自身约束验证。
工程实践Quarkslab Blog
文章系统解析了Android硬件认证机制，从Keystore、Keymaster/KeyMint、TEE/StrongBox到证书链、KeyDescription和RootOfTrust，揭示了后端验证的关键字段与信任边界。作者提出一种基于Frida的中继绕过方法：在rooted设备上拦截认证请求，将挑战转发给干净设备生成真实硬件认证链，再将其返回给目标应用，从而在不攻击密码学或硬件的情况下绕过设备完整性检查。文章还提供了可复现的代码仓库，并讨论了后端应如何通过检查attestationApplicationId和证明密钥持有来缓解此类攻击，同时指出该方法仅适用于一次性门控场景，若需持续签名则需升级为实时代理。
推荐收录，因为文章不仅深入解释了Android硬件认证的底层机制，还给出了一个可复现的工程化绕过方案，并配套完整代码仓库。它适合移动安全分析师、逆向工程师和后端安全设计者阅读，能帮助读者理解硬件信任的边界、正确实施验证逻辑，并评估现有方案的漏洞。文章同时展示了攻击与防御的双重视角，具有很高的可迁移价值。
工程实践Salesforce Engineering
文章介绍 Salesforce Mobile CI/CD 团队如何把八年积累的移动构建排障经验，抽象成名为 Analyze Build Tools 的 AI 排查系统。该系统不再只展示仪表盘，而是像资深支持工程师一样基于假设主动收集证据，联动 Managed Pipelines、Splunk、历史构建和内部指标，判断失败更可能来自应用代码、平台基础设施还是 Apple/Google 外部变更。它通过 /mp-investigate-build 等能力，让开发者直接询问“为什么失败”，减少人工拼接日志和跨系统检索的成本。作者给出明确成效：事故解决时间约缩短 60%，构建失败分析工作量下降 75%，使 8 人团队能够支撑 60+ 仓库和更多移动工程师。文章也指出当前系统仍以事后排障为主，下一步是做异常检测与主动告警，但告警噪声控制将决定其可用性。
推荐收录，因为文章给出了从“看仪表盘”到“像支持工程师一样做假设并取证”的具体工程方法，并用 60% 与 75% 两组结果证明了其价值。适合做移动 CI/CD、AI 辅助运维和开发者效率系统的参考，尤其对共享平台如何规模化支持多仓库、多团队场景具有可迁移意义。
工程实践Yelp Engineering
文章接着前文介绍 Yelp 的 server-driven UI 框架 CHAOS，重点讲它如何与跨平台设计系统 Cookbook 以及自动生成的桥接库 Konbini 协同工作。作者先说明 Yelp 与 Yelp for Business 在 Web、iOS、Android 上存在多套界面变体，导致视觉与交互一致性难以维护。随后描述如何把设计系统组件抽象成可复用的 SDUI 组件，并通过桥接层把同一套定义映射到不同平台渲染实现。文章也讨论了自动生成桥接代码在减少重复劳动、降低差异漂移方面的作用。它更适合已有多端应用和设计系统的团队参考，但前提是组件边界清晰、平台能力差异可被抽象，否则一致性和灵活性仍会冲突。
推荐收录，因为正文直接围绕 CHAOS、Cookbook 和 Konbini 的集成展开，讨论了如何在 Web、iOS、Android 多端保持界面一致，并用自动生成桥接层降低实现分叉。适合做多端产品、设计系统或 SDUI 落地的团队参考；可迁移价值在于组件抽象、跨平台映射和减少重复代码，但也依赖平台差异可被稳定封装。
工程实践Instacart Tech Blog
文章复盘了 Instacart Caper 智能购物车 Android 应用从 Fragments/XML 迁移到 Jetpack Compose 的全过程。作者将迁移拆成四阶段：先用隐式 Fragment host 承接 Compose 页面，再把导航图迁到 Kotlin DSL 与类型安全路由，随后把存量 Fragment 逐步改造成纯 Compose，最后切换到 Compose Navigation。文中最有价值的部分是 AI 辅助重构方法：通过 Git 历史提供上下文、实时纠错、持续更新迁移指南，并把 17 步流程固化为 AI skill。作者给出了 5–7 倍提速、节省约 300–350 工时的结果，但也强调在高风险硬件场景中必须保留截图对比、测试和人工验证。整体结论是：AI 适合重复性强、边界清晰的大规模现代化改造，但前提是先定义好架构目标、约定和检查点。
收录价值明确：文章不仅描述了 Compose 迁移路径，还给出可复用的 AI 辅助重构工作流、检查点和度量结果，属于可迁移的工程经验。适合做 Android 现代化、存量代码重构和 AI 提效实践的参考，但读者需要注意其前提是明确的迁移规范与严格的人为验证。