- 博客(768)
- 资源 (6)
- 收藏
- 关注
RSS订阅原创 (番外篇)从 GetEnv 到 AttachCurrentThread：彻底搞懂 JNI 的线程边界
现在进入 C/C++ 指针部分。env是一个一级指针。nullptr我们希望GetEnv()env↓真正的 JNIEnvGetEnv()env这个指针变量本身。GetEnv“这个 native 线程现在要调用 Java，所以它先要加入 JVM，并拿到属于自己的JNIEnv*。这就是这段代码真正的核心。
2026-09-27 10:51:46
227
原创 (第五篇)把 Binder、JNI、ART 和 Linux Thread 一次串起来
本文通过一个完整的AIDL跨进程调用场景，系统梳理了JNI多线程的核心机制：从Binder线程本质、JNIEnv归属、LocalRef与GlobalRef生命周期，到Native线程的Attach/Detach原理，最终揭示并发安全的关键——共享状态需通过Mutex、Atomic或串行化保护。核心在于建立“三问”思维：线程是谁？对象能活多久？共享状态是否竞争？ 以此实现对JNI多线程代码的深度理解与自主推导，而非死记硬背API。
2026-09-25 22:01:50
129
原创 (番外篇)从 Handler 到 MQ：原来“串行化”是一种通用的并发设计思想
本文深入剖析了“串行化”这一并发设计思想，指出其核心并非特定工具（如Handler、MQ），而是将多线程的并发修改收敛为有序执行序列。通过对比Mutex与串行化，揭示前者保护并发、后者减少并发的本质差异。从Android的MessageQueue到Java后端的MQ，再到Kafka分区与按业务Key分片，均体现“局部串行、全局并行”的高级架构理念。关键在于：是否同一状态由单一执行序列处理，而非是否有队列。真正的并发控制，应关注执行序列数量与状态分片逻辑，而非技术实现形式。
2026-09-25 21:57:37
270
原创 (第四篇)多线程共享状态怎么处理：Mutex、Atomic、串行化到底怎么选
本文系统解析JNI多线程中的核心并发问题，指出仅确保线程身份、JNIEnv及引用正确仍不足以保证安全，关键在于共享状态的并发访问。通过对比三种解决方案：Mutex（临界区保护）、Atomic（简单变量原子操作）与串行化（任务队列+单线程执行），强调应根据场景选择策略——简单状态用Atomic，逻辑一致用Mutex，复杂状态则优先考虑串行化以从架构上减少并发。最终提出“先判断是否有共享状态，再依复杂度选方案”的决策模型，彻底厘清多线程安全的本质。
2026-09-25 21:43:14
320
原创 (第三篇)Binder 线程池到底是什么：为什么写 AIDL 时没开线程，却已经进入了多线程世界
本文深入解析Binder多线程与JNI线程管理的本质区别：Binder线程池负责跨进程请求的分发，由系统自动管理，服务端方法可能在任意BinderThread执行；而AttachCurrentThread仅用于Native自建线程进入Java世界时的身份注册。两者无关。关键在于：当多个BinderThread并发访问共享状态时，问题已从JNI身份切换至多线程安全，需用Mutex、Atomic或串行化解决。真正核心是区分“线程身份”、“对象生命周期”与“并发控制”三层次，避免混淆。
2026-09-25 21:31:15
301
原创 (第二篇)LocalRef 和 GlobalRef：JNI 对象生命周期到底怎么回事
本文深入解析JNI多线程的核心问题：线程身份与对象引用生命周期的分离。尽管通过AttachCurrentThread可使新线程获得JNIEnv，但仅此不足以保证安全调用Java对象。关键在于，JNI方法参数中的jobject默认为局部引用（LocalRef），其生命周期仅限于当前JNI调用，无法跨异步或后续调用使用。若需长期持有，必须使用NewGlobalRef创建全局引用，并在使用后通过DeleteGlobalRef释放，避免内存泄漏。二者分别解决“能否进入Java世界”与“对象是否仍有效”两大问题，不可
2026-09-25 21:18:36
314
原创 (第一篇)JNI 多线程到底难在哪：从 Linux Thread 到 JNIEnv
本文深入解析JNI多线程的核心概念，强调理解“当前线程是谁、ART是否认识它”是掌握JNIEnv、JavaVM、AttachCurrentThread等API的关键。指出Java调JNI不切线程，JNIEnv是线程级的JNI入口，不可跨线程使用；C++自建线程需通过AttachCurrentThread接入ART体系才能调用Java代码。核心四句话：线程终归Linux、Java调JNI不切线、JNIEnv属当前线程、Native线程需主动Attach。厘清线程本质，方能真正理解JNI多线程机制。
2026-09-25 21:08:01
377
原创 第二季 · 第 8 篇：云柜机器人，本质上是在服务机器人底座上增加了哪些能力？
云柜机器人并非全新架构，而是基于服务机器人公共底座的扩展：在原有安卓、Linux、云端协同与分层控制基础上，新增柜体能力域（CabinetCapability），实现门锁、状态传感器等硬件管理；引入远程交互能力，支持手机App远程控制与实时音视频；构建三平面架构——业务面（HTTPS）、控制面（MQTT/TCP）、媒体面（RTC），分别承载数据、指令与实时音视频。其核心是复用已有CommandCenter、ControlArbiter等公共能力，通过解耦控制与媒体链路，实现可靠、实时、可观测的远程操作，体现
2026-09-25 18:55:56
886
原创 Android 系统层扫盲 12：HAL 到底是什么？Framework 为什么不能直接操作硬件？
本文深入解析Android系统中HAL（硬件抽象层）的核心作用：为何Framework不直接调用Driver，而是通过HAL实现硬件抽象。核心答案是——为了解耦不同厂商、型号的硬件差异，确保Android Framework能统一控制各类设备。通过一个“震动500ms”的实例，完整串联了从App到Hardware的整条链路：App↓Framework↓Binder↓VibratorManagerService↓JNI↓Native↓AIDL HAL↓Vendor HAL↓Kernel Driver↓Vibr
2026-09-19 12:56:09
388
原创 Android 系统层扫盲 11：JNI 到底是什么？Java / Kotlin 是怎么调用 C/C++ 的？
本文系统解析JNI的核心概念：它是Java/Kotlin与C/C++之间的受控调用桥，解决语言运行体系差异问题。通过external声明、System.loadLibrary()加载.so动态库，实现跨语言调用。关键组件包括：JNIEnv（线程级操作入口）、JavaVM（进程级Runtime入口）、jobject等JNI引用类型。JNI非IPC，仅用于同一进程内语言交互，与Binder的跨进程通信互补。结合NDK编译生成.so，JNI在Android框架中广泛应用，是理解系统层源码的关键。
2026-09-19 12:45:48
323
原创 Android 系统层扫盲 10：startActivity() 到底发生了什么？从 App 一路追到 Activity.onCreate()
本文深入剖析了startActivity()的完整启动流程，揭示其并非简单创建Activity对象，而是涉及跨进程通信与系统级调度的复杂链路。从App端调用出发，经Instrumentation、Binder、ATMS、PMS等组件，完成目标解析、进程判断、任务分发，最终通过ClientTransaction机制在目标进程的主线程中创建Activity并执行生命周期。核心要点包括：Activity由系统统一调度，非直接new；启动决策在system_server完成；冷启动需Zygote fork新进程；A
2026-09-19 12:20:22
231
原创 （KMP-Net进阶）第二篇：Ktor Multipart 文件上传——从普通 POST 到 multipart/form-data
本文系统讲解Ktor中Multipart文件上传的实践，对比普通JSON请求与Multipart的区别，强调multipart/form-data适用于文件与参数混合传输场景。重点介绍MultiPartFormDataContent与InputProvider在小文件（ByteArray）和大文件流式上传中的应用，强调避免内存溢出。同时指出KMP项目中应以文件元信息为核心，平台层转换为可读数据源，而非暴露java.io.File。最后总结上传关键点：合理使用boundary、禁用完整日志、谨慎重试、进度监听
2026-09-13 18:06:45
260
原创 Android 系统层扫盲 09：AMS、ATMS、WMS、PMS 到底分别管什么？
本文系统梳理Android Framework中四大核心服务：PMS（包管理）、ATMS（Activity任务管理）、AMS（进程与组件管理）、WMS（窗口管理）的职责与协作关系。通过用户点击Launcher图标启动App的典型场景，揭示从包信息查询、Activity调度、进程创建到窗口管理、画面合成的完整链路，明确各服务分工：PMS负责“我是谁”，ATMS负责“去哪”，AMS负责“怎么活”，WMS负责“放哪”，SurfaceFlinger负责“怎么显示”。强调现代Android架构中ATMS取代AMS成为
2026-09-13 18:05:07
292
原创 Android 系统层扫盲番外：从 Interface、Contract 到 AIDL，一步看懂跨进程接口是怎么演进出来的
本文从Android应用调用powerManager.xxx()出发，揭示跨进程调用的底层机制。通过逐步演进：直接调用→接口抽象→模块契约→跨进程代理，阐明了userService.getUser(1)看似不变的调用方式背后，实则经历了从本地方法调用到远程过程调用（RPC）的完整变迁。核心思想是：面向接口编程在跨进程场景下催生出Proxy、Stub、Parcel与Binder等组件，最终由AIDL自动化生成代码，实现“调用方只关心能力，不关心实现位置”的统一抽象。本质是接口与实现之间距离的扩展，推动了系统设
2026-09-13 17:21:48
780
原创 Android 系统层扫盲 08：Binder 到底怎么跨进程？从 PowerManager 一路跑到 system_server
本文深入解析了Android中Binder机制如何实现跨进程通信：App进程通过getSystemService()获取PowerManager，其内部的IPowerManager.Proxy作为远程服务代理，将方法调用封装成Parcel，经由transact()通过JNI和NativeBinder传递至Linux内核的BinderDriver，最终在system_server中由Stub解包并调用PowerManagerService的真正逻辑。整个过程实现了“本地调用”表象下的远程过程调用（RPC），揭
2026-09-13 14:04:32
217
原创 Android 系统层扫盲 07：SystemServer 到底是什么？AMS、WMS、PMS 为什么都从这里启动？
ZygoteAndroid Java/ART 进程工厂。Android Framework 系统服务启动中心。承载这些核心 Framework Service 的 Linux 进程。Zygote↓fork↓↓↓↓管理 App管理 Activity管理 Package管理 Window管理 Power管理 Input等核心能力。第七篇到这里，和 SystemServer 的主线已经建立起来了。接下来先不急着直接进入 Binder。││???↓和。
2026-09-12 10:03:05
293
原创 Android 系统层扫盲 06：Zygote 到底是什么？为什么 Android App 都从“受精卵”里 fork 出来？
Android为何需要Zygote？它作为提前启动的Java进程底座，通过fork+COW机制，预加载Framework类、资源与库，实现公共环境共享。系统通过system_server向Zygote发送Unix Domain Socket请求，由其fork出App进程，快速创建应用并配置权限，大幅降低启动延迟。Zygote是Android进程工厂，既保障效率又维持安全隔离，是Android高效启动的核心设计。
2026-09-10 16:07:34
141
原创 Android 系统层扫盲番外：一篇搞懂 Linux fork、COW、exec，以及 Android Zygote 为什么这么设计
<think>好的，用户要求根据这段关于Android Zygote与Linux进程机制的详细文章生成一个≤150字的摘要。需要精准提炼核心要点，把fork、COW、exec和Zygote的关系串联起来，同时突出Android与普通Linux的区别。 我数了一下摘要字数，在150字以内，符合要求。</think>Android通过Zygote预热ART/Framework，基于Linux的fork+COW机制孵化App进程，保留公共运行环境而非exec替换，实现快速、省内存的App启
2026-09-08 18:19:36
611
原创 Android 系统层扫盲 05：Android 开机后发生了什么？从 Bootloader 到 Launcher
<think>我们只需要根据内容生成摘要，不超过150字。内容是关于Android开机流程的概述。摘要需简洁，涵盖关键阶段。</think>Android开机是一场接力赛：BootROM→Bootloader→Linux Kernel→init→Zygote→system_server→System Services→Launcher。init是用户空间启动总管，Zygote是预热好的ART/Java进程底座，通过fork产生system_server和App进程，SystemSer
2026-09-08 18:18:00
229
原创 Android 系统层扫盲 04：Android 系统到底分几层？从 App 一路看到 Linux Kernel
<think>我们基于用户提供的长文，生成≤150字的摘要。摘要要抓住核心：Android系统分层地图：Applications、Framework、SystemServices、ART/Native、HAL、Kernel、Hardware；强调帮助App开发者理解API背后实现，Binder贯穿，后续文章。需简洁，≤150字。</think>本文为Android系统层扫盲第四篇，为App开发者建立Android系统分层地图：Applications→Framework→System
2026-09-07 10:42:00
490
原创 Android 系统层扫盲 03：第一次看 AOSP 源码目录，frameworks、system、packages、hardware 都是干什么的？
<think>我们只需要根据用户提供的长文生成摘要，要求≤150字。需要抓住核心：AOSP源码目录地图；按职责而非语言组织；重点frameworks/packages/system；其他目录如hardware等建立名字对应即可；目标是为后续系统分层学习打基础。用简洁中文概括。</think>AOSP源码目录应按系统职责而非编程语言划分。对App开发者，重点先记住三个入口：frameworks（Framework API与系统服务）、packages（系统App）、system（底层组
2026-09-04 23:40:16
469
原创 Android 系统层扫盲 02：Repo 为什么存在？一篇搞懂 Git、Repo 和 Manifest
一个项目↓一个 Git Repository一个 Android 源码工作区↓大量 Git Repository↓Repo 统一管理↓Manifest 告诉 Repo 管哪些仓库Manifest↓Repo↓多个 Git Repository这就是 Android 系统源码管理最基础的模型。第一阶段理解到这里已经完全够用。
2026-08-30 13:45:50
311
原创 Android 系统层扫盲 01：AOSP 到底是什么？Android App 开发者为什么要了解它？
Android 上面盖房子。我们脚下这块地基到底是怎么建出来的。第一阶段不用急着成为 Android Framework 工程师。先把这张地图建立起来。RepoAOSP 源码目录ZygoteBinderAMSWMSPMSJNIHALKernel当这些名字最终能够在脑子里连成一张图时，Android 系统层才算真正入门。《Android 系统层扫盲 02：Repo 为什么存在？一篇搞懂 Git、Repo 和 Manifest》
2026-08-30 11:15:34
382
原创 (KMP-Net进阶)第一篇：AppResult＜T＞——网络层到底应该 throw，还是返回统一 Result？
AppError混为一谈。out T> {Success↓业务数据 TFailure↓项目语义 AppError刚好形成完整体系。throw和谁先进谁落后的关系。它们解决的是不同问题。throw成功↓正常返回 T失败↓异常通道代码自然串行组合简单和 Coroutine / Ktor 机制一致成功失败↓都成为返回值函数契约明确上层必须显式处理可以直接携带 AppErrorHttpClient↓↓ApiService↓T + throw↓根据业务需要。
2026-08-25 22:25:38
684
原创 第十二篇：完整 KMP + Ktor 网络架构：从 ApiService 到 NetworkClient、Provider、Plugin、Engine
UI↓ViewModel↓Repository↓ApiService↓│↓↓ ↓│ │↓HttpClient│↓ ↓ ↓│ │ │↓ ↓ ↓RetryAuth│↓Engine↓ ↓ ↓↓HTTP↓↓↓↓↓↓ ↓↓ ↓↓ ↓T AppError为什么存在？负责什么？为什么不能放到旁边那一层？那么这套 Ktor 网络架构就已经真正理解了。Retrofit 的替代品GET 怎么写？POST 怎么写？JSON 怎么解析？
2026-08-23 12:49:01
335
1
原创 第十一篇：Ktor Auth：Bearer Token、Refresh Token 与 401 自动刷新到底怎么工作？
null,↓loadTokens↓↓Request↓↓Send↓Server↓↓ ↓200 401↓ ↓↓Refresh R1↓New A2/R2↓↓Auth Cache 更新↓↓200401↓↓↓↓↓↓重新登录AccessToken 负责访问业务资源，RefreshToken 负责换取新的 AccessToken。loadTokens负责加载已有 Token，负责在认证失效后获取新 Token。
2026-08-23 12:22:40
198
原创 第十篇：Ktor Custom Client Plugin：从 OkHttp Interceptor 真正理解请求与响应生命周期
本文深入探讨了Ktor客户端的核心扩展机制，通过与OkHttp拦截器模型的对比，揭示了Ktor基于生命周期的插件化设计思想。文章指出Ktor采用分阶段的Hook机制（如onRequest、transformRequestBody、Send、onResponse等）替代OkHttp的统一拦截器，使扩展点更加职责明确。通过分析请求签名、响应加密等实际场景，强调理解生命周期阶段比记忆API更重要。最后总结出Ktor的核心理念是：将网络请求拆解为清晰的生命周期阶段，允许插件在特定环节注入逻辑。这种设计使得Trace
2026-08-23 12:21:32
410
原创 补充篇 9.2：Ktor DSL 深入——为什么 install、get、headers 可以这样写？
本文深入解析了Ktor框架中DSL（领域特定语言）的工作原理，重点介绍了Kotlin的带接收者Lambda（Lambda with Receiver）机制。通过示例代码演示了从普通Lambda到带接收者Lambda的演变过程，解释了Ktor中看似"魔法"的语法（如直接访问logger、headers等属性）实际上是当前接收者对象的成员。文章通过分层分析Ktor的配置结构，展示了不同作用域下Receiver的变化规律，并提供了阅读Ktor DSL的方法论：遇到{}时先确定当前Receive
2026-08-23 10:04:06
399
原创 补充篇 9.1：Ktor Logging 深入：Header、Body 脱敏与自定义 Logger
setOf("token","secret","apiKey",phoneidCardbankCard只需要继续增加。不过哪些字段应该完全隐藏、哪些应该部分掩码，要根据实际业务和合规要求设计。Logger三者不是一回事。↓↓│├── level├── filter└── format↓安全日志内容↓Logger/ \↓ ↓↓↓负责 Header 日志脱敏bodyFilter↓负责 Request / Response Body如何进入日志↓。
2026-08-22 23:13:23
247
原创 第九篇：Ktor Plugin 实战：Logging、HttpTimeout 与 HttpRequestRetry
本文介绍了Ktor网络层中三个关键插件（Logging、HttpTimeout、HttpRequestRetry）的核心功能与配合机制： Logging负责请求过程可视化，通过sanitizeHeader和bodyFilter实现敏感信息脱敏，支持默认Logger和自定义日志系统接入。 HttpTimeout提供三重超时控制： ConnectTimeout（连接建立） SocketTimeout（数据传输间隔） RequestTimeout（完整请求周期） 支持Client全局配置与Request特殊覆盖。
2026-08-22 23:12:16
341
原创 补充篇 8.1：Ktor/KMP 断网处理：为什么请求前要先判断网络状态？
本文探讨了KMP网络请求中的断网处理策略，提出了两道防线设计：1. 请求前通过NetworkConnectivityProvider进行Pre-check快速失败；2. 真实请求时通过HttpClient/Engine和ExceptionMapper处理网络异常。重点解析了NetworkMonitor、NetworkConnectivityProvider和NetworkClient的职责分工，强调Provider作为动态状态源的核心价值，其内部状态由平台监听组件持续更新，实现网络状态的实时判断。同时指出公
2026-08-22 17:16:44
343
原创 第八篇：Ktor 异常体系：断网、Timeout、HTTP、JSON 与业务错误如何统一成 AppError
本文重点探讨了Ktor网络请求中的错误处理体系设计。作者指出，相较于成功流程，网络请求的失败场景更为复杂多样，需要分层处理不同阶段的错误：从请求前的网络检查、连接超时，到HTTP状态码异常、JSON解析失败，再到业务逻辑错误。文章提出通过ExceptionMapper将底层异常统一转换为业务层可理解的AppError抽象（如Network/Timeout/Unauthorized等），并强调错误分类对后续重试策略、日志记录和UI提示的重要性。关键设计包括请求前的快速失败机制（NetworkConnectiv
2026-08-22 16:34:36
409
原创 第七篇：Ktor 统一响应模型：ApiResponse、业务 code 与 data 解包
本文探讨了如何处理Ktor网络请求中的两层响应结构：HTTP层的HttpResponse与业务层的ApiResponse<T>。文章指出，后端通常返回统一格式的响应（如包含code、msg、data字段），而业务层真正关心的只是data部分。作者建议将响应解包逻辑放在NetworkClient层，通过泛型处理不同类型的data，并在该层统一检查业务状态码（code），向上层抛出结构化异常（如ApiException）。这样业务层（如Repository/ViewModel）只需处理成功后的数据对
2026-08-22 13:57:29
377
原创 KMP 平台差异到底怎么设计？从日志导出重构看扩展函数、interface 与 expect/actual
本文以KMPLogger日志导出功能为例，深入解析了Kotlin跨平台开发中处理平台差异的三种设计模式。核心观点包括： 扩展函数（如AppLogger.exportLogs()）本质是API调用优化，而非平台抽象机制，主要解决调用便利性问题。 expect/actual适用于commonMain需要的简单平台能力（如进程名、系统信息等），特点是实现固定且功能单一。 interface+平台实现类（如LogExportStorage）适合复杂组件，通过依赖注入实现平台能力，具有可测试、可替换的优势。 文章通过
2026-08-18 13:51:27
689
原创 Kafka 和 MQ 到底什么时候用？从任务队列、事件流到分布式系统真正理解消息中间件
本文通过对比MQ和Kafka的核心差异，揭示了它们在分布式系统中的不同定位。MQ本质是任务队列，关注"事情是否被处理完成"，适用于异步任务处理（如发短信、生成报告）；Kafka则是事件流平台，记录"系统发生了什么"，支持多服务独立消费事件数据（如设备状态变化）。文章提出四组件架构模型：MySQL存业务数据、Redis存当前状态、MQ处理待办任务、Kafka传递事件流，并强调理解"任务处理"与"事件流"的本质区别比单纯比较技术参数
2026-08-17 22:02:28
622
原创 第六篇：Ktor 请求层怎么封装？从 client.get() 到统一 NetworkClient
本文介绍了在Ktor项目中通过引入NetworkClient层实现业务逻辑与网络请求的解耦。主要内容包括： 直接使用HttpClient的问题：业务层会暴露过多网络细节（URL构建、Header设置等） NetworkClient的设计： 提供统一入口（get/post/put/delete） 使用泛型+reified简化响应解析 保留扩展能力（通过HttpRequestBuilder lambda） 支持多客户端配置（API/Refresh/Upload等） 分层架构： 业务层（ApiService）→
2026-08-17 05:00:00
900
原创 补充篇 5.1：Ktor 请求配置的三种作用域：静态配置、Provider 动态值与单次 Request 覆盖
本文系统阐述了Ktor网络请求中三层配置体系的设计逻辑：1. Client静态默认值（如Platform） - 长期固定配置，通过defaultRequest设置 2. Provider动态默认值（如Language） - 通过状态提供器实时获取当前值 3. Request特殊值 - 单次请求临时参数，通过请求构建器设置 核心区别在于生命周期和影响范围： Client配置在创建时确定，全局共享 Provider反映应用当前状态，变化影响后续请求 Request参数仅作用于单次调用 关键设计原则： 使用app
2026-08-16 17:33:29
282
原创 第五篇：Ktor DefaultRequest：BaseUrl、公共 Header 为什么不应该每个接口都写？
本文介绍了Ktor Client中DefaultRequest的核心作用：将公共请求配置从业务接口中抽离。通过DefaultRequest可以统一处理BaseUrl、公共Header等Client级配置，避免在每个接口重复编写。主要内容包括： DefaultRequest的作用是提供HttpClient级别的默认请求配置，包括BaseUrl、公共Header等 适用于那些不属于单个接口而属于整个Client的配置项 在多Client项目中，每个Client可以有自己独立的DefaultRequest配置 公
2026-08-16 16:36:58
330
原创 第四篇：kotlinx.serialization 从零理解：KMP 为什么不再依赖 Gson？
本文详细介绍了Kotlin多平台序列化框架kotlinx.serialization的核心概念和使用方法。主要内容包括： 序列化基础：解释了Kotlin对象与JSON互相转换的过程 kotlinx.serialization的特点：通过@Serializable注解在编译时生成序列化能力，适合KMP项目 核心API：Json.encodeToString()和Json.decodeFromString() 常用配置：ignoreUnknownKeys、默认值处理、字段映射等 与Ktor的关系：通过Conte
2026-08-16 11:28:37
291
原创 第三篇：Ktor ContentNegotiation 到底是什么？JSON 为什么能自动变成 Kotlin 对象？
本文深入解析了Ktor中的ContentNegotiation与kotlinx.serialization机制。主要内容包括： ContentNegotiation作为内容转换插件，负责管理HTTP请求/响应与序列化器的连接，而非直接处理JSON转换； kotlinx.serialization才是实际执行Kotlin对象与JSON互转的序列化框架； 通过Retrofit类比说明两者的协作关系：ContentNegotiation类似ConverterFactory，kotlinx.serializatio
2026-08-16 11:25:37
381
8方向控制圆盘-android
2025-10-30
Android Dsbridge （前端Vue3.0打包）
2025-10-30
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人