- 博客(760)
- 收藏
- 关注
RSS订阅原创 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
317
原创 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
239
原创 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
177
原创 （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
235
原创 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
243
原创 Android 系统层扫盲番外：从 Interface、Contract 到 AIDL，一步看懂跨进程接口是怎么演进出来的
本文从Android应用调用powerManager.xxx()出发，揭示跨进程调用的底层机制。通过逐步演进：直接调用→接口抽象→模块契约→跨进程代理，阐明了userService.getUser(1)看似不变的调用方式背后，实则经历了从本地方法调用到远程过程调用（RPC）的完整变迁。核心思想是：面向接口编程在跨进程场景下催生出Proxy、Stub、Parcel与Binder等组件，最终由AIDL自动化生成代码，实现“调用方只关心能力，不关心实现位置”的统一抽象。本质是接口与实现之间距离的扩展，推动了系统设
2026-09-13 17:21:48
747
原创 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
187
原创 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
193
原创 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
108
原创 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
580
原创 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
193
原创 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
449
原创 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
370
原创 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
287
原创 Android 系统层扫盲 01：AOSP 到底是什么？Android App 开发者为什么要了解它？
Android 上面盖房子。我们脚下这块地基到底是怎么建出来的。第一阶段不用急着成为 Android Framework 工程师。先把这张地图建立起来。RepoAOSP 源码目录ZygoteBinderAMSWMSPMSJNIHALKernel当这些名字最终能够在脑子里连成一张图时，Android 系统层才算真正入门。《Android 系统层扫盲 02：Repo 为什么存在？一篇搞懂 Git、Repo 和 Manifest》
2026-08-30 11:15:34
316
原创 (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
673
原创 第十二篇：完整 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
320
原创 第十一篇：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
183
原创 第十篇：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
395
原创 补充篇 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
392
原创 补充篇 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
224
原创 第九篇：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
328
原创 补充篇 8.1：Ktor/KMP 断网处理：为什么请求前要先判断网络状态？
本文探讨了KMP网络请求中的断网处理策略，提出了两道防线设计：1. 请求前通过NetworkConnectivityProvider进行Pre-check快速失败；2. 真实请求时通过HttpClient/Engine和ExceptionMapper处理网络异常。重点解析了NetworkMonitor、NetworkConnectivityProvider和NetworkClient的职责分工，强调Provider作为动态状态源的核心价值，其内部状态由平台监听组件持续更新，实现网络状态的实时判断。同时指出公
2026-08-22 17:16:44
337
原创 第八篇：Ktor 异常体系：断网、Timeout、HTTP、JSON 与业务错误如何统一成 AppError
本文重点探讨了Ktor网络请求中的错误处理体系设计。作者指出，相较于成功流程，网络请求的失败场景更为复杂多样，需要分层处理不同阶段的错误：从请求前的网络检查、连接超时，到HTTP状态码异常、JSON解析失败，再到业务逻辑错误。文章提出通过ExceptionMapper将底层异常统一转换为业务层可理解的AppError抽象（如Network/Timeout/Unauthorized等），并强调错误分类对后续重试策略、日志记录和UI提示的重要性。关键设计包括请求前的快速失败机制（NetworkConnectiv
2026-08-22 16:34:36
400
原创 第七篇：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
366
原创 KMP 平台差异到底怎么设计？从日志导出重构看扩展函数、interface 与 expect/actual
本文以KMPLogger日志导出功能为例，深入解析了Kotlin跨平台开发中处理平台差异的三种设计模式。核心观点包括： 扩展函数（如AppLogger.exportLogs()）本质是API调用优化，而非平台抽象机制，主要解决调用便利性问题。 expect/actual适用于commonMain需要的简单平台能力（如进程名、系统信息等），特点是实现固定且功能单一。 interface+平台实现类（如LogExportStorage）适合复杂组件，通过依赖注入实现平台能力，具有可测试、可替换的优势。 文章通过
2026-08-18 13:51:27
680
原创 Kafka 和 MQ 到底什么时候用？从任务队列、事件流到分布式系统真正理解消息中间件
本文通过对比MQ和Kafka的核心差异，揭示了它们在分布式系统中的不同定位。MQ本质是任务队列，关注"事情是否被处理完成"，适用于异步任务处理（如发短信、生成报告）；Kafka则是事件流平台，记录"系统发生了什么"，支持多服务独立消费事件数据（如设备状态变化）。文章提出四组件架构模型：MySQL存业务数据、Redis存当前状态、MQ处理待办任务、Kafka传递事件流，并强调理解"任务处理"与"事件流"的本质区别比单纯比较技术参数
2026-08-17 22:02:28
605
原创 第六篇：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
887
原创 补充篇 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
272
原创 第五篇：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
321
原创 第四篇：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
261
原创 第三篇：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
372
原创 7-fix补充篇：机器人为什么需要多级控制仲裁？Cloud、Linux 与 MCU 分别管什么
《机器人控制权的多层次仲裁机制》摘要： 本文深入探讨了复杂机器人系统中控制指令的多级仲裁机制。通过服务机器人和割草机器人的对比分析，揭示了三层控制权仲裁体系：1)云端全局业务仲裁（用户权限、设备归属、远程控制权）；2)机器人本地执行仲裁（控制模式、任务状态、导航条件）；3)MCU安全联锁（急停、碰撞、硬件故障）。文章强调分层防御理念：上层拥有调度权，下层保留基于实时状态的否决权，越接近硬件的层级判断优先级越高。特别指出服务机器人因存在本地直连控制链路，需要更复杂的本地仲裁机制。最终提出机器人控制架构四大核心
2026-08-15 18:41:09
517
原创 第 7 篇：服务机器人为什么需要处理多种控制入口？LOCAL、REMOTE、AUTO 与 MAINTENANCE
服务机器人天然存在多控制入口，包括机身Android（LOCAL）、手机App/云端（REMOTE）、自主任务（AUTO）和维护模式（MAINTENANCE）。这些入口并非简单竞争，而是需要分层管理控制权。核心观点包括： 控制权分层：区分ControlMode（场景）与CommandSource（来源），由Linux主控作为本地仲裁中心（ControlArbiter），综合模式、来源、指令类型和状态决定是否执行。 优先级策略：业务指令（如导航、回充）需遵循动态策略，而非固定优先级；安全指令（如急停）独立于业
2026-08-15 12:12:45
392
原创 第 6 篇：Android、机器人主控、MCU 与硬件到底如何分层？
本文深入探讨了服务机器人架构中Android、Linux主控和MCU之间的职责划分与硬件控制逻辑。文章指出机器人系统并非简单的三级线性结构（Android→Linux→MCU），而是一个基于能力归属的多节点控制系统。关键点包括： 分层原则：Android主要负责业务交互，可直连业务外设；Linux主控管理核心能力（导航/任务/底盘）；MCU执行实时硬件控制 硬件连接灵活性：业务外设（如扫码器/打印机）可直接由Android控制，而核心运动组件需经Linux统一管理 协议解耦：无论硬件连接方式如何，都应通过H
2026-08-15 10:44:43
939
原创 第二篇：Ktor 网络请求基础：GET、POST、参数与请求体
本文摘要：Ktor通过Kotlin DSL描述HTTP请求核心要素（Method/URL/Header/Body），提供client.get()/post()等便捷方法。关键点包括： 请求构建：GET/POST方法、Path拼接、Query参数、Headers设置、JSON Body处理 响应处理：HttpResponse包含status/headers/body，通过body()反序列化为Kotlin对象 架构演进：从直接使用HttpClient到封装NetworkClient层，为统一处理BaseUrl
2026-08-14 10:23:26
313
原创 第一篇：Ktor Client 到底是什么？从 Retrofit 迁移理解 Ktor 网络请求架构
本文探讨了Kotlin Multiplatform (KMP) 中Ktor网络框架的设计理念与使用方式。与Android开发中常见的Retrofit+OkHttp组合不同，Ktor采用HttpClient+Plugin+Engine的三层架构：HttpClient作为统一网络入口，Plugin提供日志、认证等扩展能力，而Engine负责适配不同平台的实际网络实现（如Android用OkHttp，iOS用Darwin）。文章比较了Retrofit的接口注解模式与Ktor的DSL风格差异，强调Ktor通过平台化
2026-08-13 16:31:03
218
原创 补充篇：机器人为什么都需要“指令中心”？——从服务机器人到割草机器人
本文通过对比服务机器人和割草机器人的指令控制架构，揭示了指令中心（CommandCenter）的核心逻辑与部署策略差异。服务机器人采用本地控制模式，指令中心部署在机身Android端，直接管理指令生命周期；而割草机器人采用云端远程控制，指令中心上移至云端，以应对手机端不稳定的场景需求。两者本质都包含指令创建、幂等控制、超时重试等机制，区别在于指令中心的物理部署位置：本地控制强调低延迟（靠近设备），远程控制侧重可靠性（靠近云端）。文章指出指令中心是逻辑角色而非固定模块，其部署取决于网络拓扑、任务时长等要素，并
2026-08-11 22:06:30
518
原创 第 5 篇：Android 与机器人主控之间，指令、回执、超时和重试怎么设计？
摘要： 本文探讨了机器人控制中指令的完整生命周期，强调发送成功≠收到成功≠执行成功。通过引入Command、Ack、Sequence、Timeout、Retry和幂等机制，构建了可靠的指令系统：Android端通过CommandCenter管理指令状态（如PendingCommand），Linux主控通过CommandHandler校验和执行指令。关键设计包括： Sequence：匹配请求与响应； 幂等：防止重复执行； 分层超时：区分Ack超时与业务执行超时； 状态机：指令从发送到完成可能触发多阶段状态更新
2026-08-11 22:03:13
269
原创 第 4 篇：TCP 字节流中的粘包、半包与机器人协议解析
TCP协议中的粘包与半包问题解析 核心问题：TCP作为字节流协议，不保证应用层消息边界，导致发送与接收次数不匹配，出现粘包（多条消息合并读取）和半包（单条消息分次读取）。 原因： 字节流本质：TCP将数据视为连续字节流，发送/接收缓冲区、网络分段等因素影响读写粒度。 无消息概念：TCP层无法识别应用层消息的起止，需应用层自行定义协议格式（如Header+Length）。 解决方案： 协议设计： 固定包头（如AA55）标识消息起始，长度字段明确消息边界。 包含Command（消息类型）、Sequence（消息
2026-08-11 10:28:46
397
8方向控制圆盘-android
2025-10-30
Android Dsbridge （前端Vue3.0打包）
2025-10-30
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人