封面 一、技术底座：Kuikly 到底怎么工作的 1.1 核心架构：让 native 层尽量薄 1.2 六平台覆盖与动态化 1.3 代码量对比 二、为什么 2026 年值得重新评估 Kuikly 2.1 鸿蒙生态：KMP 系的天然优势 2.2 AI 驱动开发：不只是口号 2.3 Compose DSL 走向正式 Release 三、KMP 与 Kuikly 的分界线：为什么用了 KMP 还要选 Kuikly 3.1 KMP 做到哪一步 3.2 Kuikly 在 KMP 之上加了什么 3.3 和 Flutter、RN 的本质差异 四、QQ 音乐实战：React H5 → Kuikly 智能转码全记录 4.1 背景与痛点 4.2 成果数据 4.3 技术方案拆解：为什么 AI 转码能落地 五、横向对比：Kuikly 放在选型表里是什么位置 5.1

- 阅读剩余部分 -

AI Agent 的 Skill 到底是什么？一文说清写法、路径和推荐清单 什么是 Skill？ Skill 的两种存放位置 不同 Agent 的默认加载路径 Skill 怎么被触发？ 如何写一个简单的 Skill 写 Skill 的几个实战原则 1. 只放 Agent 不知道的东西 2. 自由度和约束要匹配 3. 一个 Skill 只干一件事 4. 触发词要真实 5. 版本和更新日期要留痕 哪些通用 Skill 值得装？ 1. 代码质量与工程规范 2. 架构与部署 3. 前端与 UI 4. 研究、搜索与自动化 5. AI 工程自身 6. 沟通与输出 7. 安全与代码审计 8. 浏览器自动化与数据采集 9. 运维与可观测性 10. 音视频与多媒体创作 选 Skill 的判断标准 Skill 与 Prompt、Rules 的关系 从一个过时 Skill

- 阅读剩余部分 -

PAG 是什么？ 为什么它是 SVGA 的最佳替代者？（核心优势） PAG vs Lottie vs SVGA 深度对比 Android 接入指南 (Kotlin) 潜在缺点与注意事项 总结 本文首发地址 https://h89.cn/archives/493.html 前文分析了SVGA等动画的对比，但是SVGAPlayer（由 YY 团队开发）目前已归档（Public archive） ，今天我们来看看另外一种动画 PAG (Portable Animated Graphics) ， 它是目前安卓开发中，替代 SVGA 和 Lottie 的最强方案，尤其是针对直播礼物、游戏特效、UI 复杂动效等场景。 它由 腾讯 (Tencent) 内部研发并开源，目前已经成为国内大厂（腾讯系、抖音、快手、B站等）的行业标准。 以下是对 PAG 的详细技术介绍，包括核心优势、工作原理以及与 S

- 阅读剩余部分 -

1. 什么是 Gemini Agent？ 2. 如何启用和配置 Gemini Agent 2.1 获取 API Key 2.2 在 Android Studio 中配置 3. 实际使用场景示例 3.1 自动更新依赖版本 3.2 自动接受建议 3.3 自定义项目规则 4. 总结与展望 本文首发地址 https://h89.cn/archives/421.html 本文基于 Android Studio Narwhal Feature Drop | 2025.1.2 或更高版本。 1. 什么是 Gemini Agent？ Gemini Agent 是 Android Studio 内置的 AI 编程助手，它利用 Google 最先进的 Gemini 模型，旨在提升开发者的生产力。Agent 模式在您编码时主动提供

- 阅读剩余部分 -

前言 项目概述--核心特性 Clean Architecture 架构的三层分离设计理念 Presentation Layer（表现层） Domain Layer（领域层） Data Layer（数据层） MVI 模式深度解析 单向数据流的优势 状态管理策略 Room 数据库架构设计 数据库设计 类型转换器 Solana Mobile SDK 集成 钱包连接 区块链交易 依赖注入架构--Hilt 模块配置 UI 设计与 Jetpack Compose 科技美学设计系统 可复用组件设计 性能优化策略 1. Lazy Loading 2. 状态管理优化 3. 数据库优化 测试策略 单元测试 UI 测试 架构优势总结 1. 可维护性 2. 可测试性 3. 可扩展性 4. 开发效率 与其他架构

- 阅读剩余部分 -

安卓AOP变天了？AspectJ的黄昏与KSP的崛起 安卓AOP变天了？AspectJ的黄昏与KSP的崛起 前言 AOP技术概述 什么是AOP AspectJ简介 AspectJ在Android中的衰落趋势 维护状况堪忧 社区转向现代方案 AspectJ使用减少的主要原因 1. 编译性能问题 2. 配置复杂性 3. 调试困难 4. 学习成本高 5. 维护成本高 现代替代方案 1. Kotlin符号处理器（KSP）（强烈推荐） 2. 注解处理器（APT）（传统方案） 3. 其他替代方案 现代Android项目的AOP方案选择指南 🎯 推荐方案优先级 ⚠️ 不推荐AspectJ的场景 ✅ 仍可考虑AspectJ的特殊场景 总结 🚀 现代化转型的关键 💡 技术选型建议 🔮 未来展望 参考资料 本文首发地址 https://h

- 阅读剩余部分 -

一、告别泛型“擦除”之痛：Reified 的诞生 二、Reified 核心原理：编译器的“魔法” 2.1 传统泛型的类型擦除：为何会丢失？ 2.2 Reified 的编译器增强：实化类型信息 三、Reified 实用场景与代码示例 3.1 简化类型解析：告别显式 Class 参数 3.2 安全的类型检查：is 关键字的泛型增强 3.3 泛型集合过滤：类型安全的筛选逻辑 3.4 网络请求封装：统一处理响应类型 四、Reified 使用限制与最佳实践 4.1 必须与 inline 关键字联用 4.2 泛型参数的约束 4.3 避免滥用：性能与可读性权衡 五、与 Java 泛型对比：Kotlin 的独特优势 六、总结：Reified 如何提升开发效率 一、告别泛型“擦除”之痛：Reified 的诞生 在 Kotlin 开发中，泛型无疑是提升代码复用性和

- 阅读剩余部分 -

1. 引言 2. 核心概念：Compose的革新性设计 2.1 Jetpack Compose 2.2 传统安卓View系统 3. 开发体验：Compose大幅提升效率 3.1 使用Jetpack Compose构建UI 3.2 使用传统View系统构建UI 4. 性能表现：Compose更胜一筹 4.1 渲染效率 4.2 内存使用 5. 可维护性与可测试性：Compose优势明显 5.1 可维护性 5.2 可测试性 6. 兼容性与混合开发：Compose提供灵活过渡方案 7. 结论：Compose引领安卓UI开发未来 本文首发地址 https://h89.cn/archives/371.html 1. 引言 在安卓应用开发领域，传统View系统长期作为UI构建的核心方案，基于命令式编程模型，依赖XML布局文件与Java/Kotlin代码

- 阅读剩余部分 -