- 博客(670)
- 资源 (6)
- 收藏
- 关注
RSS订阅原创 密码与加密基础篇（4）：bcrypt / Argon2id 为什么比 MD5 更适合存密码？
本文分析了密码存储中的核心问题，指出MD5等快速哈希算法不适合用于密码存储的原因——计算速度过快，容易被暴力破解。文章详细介绍了bcrypt和Argon2id两种慢哈希算法的优势：bcrypt自带salt、cost参数可调、计算成本可控；Argon2id则进一步引入内存成本，增加并行破解难度。相比MD5，这些算法通过提高计算成本有效抵御离线攻击。文中还提供了Spring Security中的实现方案、老系统迁移策略，并强调密码安全需要HTTPS传输、防暴力破解等多层防护，而非仅依赖存储算法。最终结论是：密码
2026-06-24 08:15:00
290
原创 密码与加密基础篇（3）：salt 和 pepper 到底是什么？为什么 salt 可以放数据库？
本文深入解析了密码存储中的两个关键概念：salt和pepper。salt是公开的随机字符串，主要作用是防止相同密码产生相同哈希值，避免彩虹表攻击，可安全存储在数据库中；pepper则是服务端私有秘密，用于在数据库泄露后增加破解难度，必须严格保密且不应存储在数据库。文章强调现代密码存储应优先使用bcrypt/Argon2id等慢哈希算法，配合salt和pepper形成多层防护。同时指出常见误区，如混淆两者的保密要求或试图用pepper替代安全哈希算法。最终建议完整的密码安全策略应包含：强哈希算法、salt机制
2026-06-24 06:00:00
447
原创 密码与加密基础篇（2）：密码到底怎么存？为什么 MD5 已经过时？
本文核心观点总结：密码存储应采用专用哈希算法而非MD5或明文存储。MD5因其计算速度过快，易受暴力破解攻击，即使加盐仍不足够安全。推荐使用bcrypt、Argon2id或PBKDF2等算法，它们具备不可逆、自带盐值、可调计算成本等特性，能有效提高攻击者破解难度。 关键实践建议：1）新项目直接使用Spring Security的BCryptPasswordEncoder；2）老系统MD5密码应采用"登录验证后升级"的渐进迁移方案；3）密码字段需添加算法标识前缀（如{bcrypt}）以支持多
2026-06-23 09:50:23
269
原创 Android AGP 8.x 多渠道打包：ProductFlavor、Build Variant 与资源覆盖
本文详细介绍了Android多渠道打包的实现方案，重点解析了Gradle变体构建体系。主要内容包括：1. 核心概念区分：BuildVariant=ProductFlavor×BuildType，其中BuildType用于定义构建方式（debug/release），ProductFlavor表示渠道/地区/客户差异。2. 多渠道打包策略：保持相同applicationId，通过BuildConfig、manifestPlaceholders和资源覆盖机制实现渠道差异化，避免复制项目。3. 组件化项目适配：普通
2026-06-23 09:33:57
577
原创 密码与加密基础篇（2）：密码到底怎么存？为什么 MD5 已经过时？
这篇文章详细探讨了密码存储的正确方式及其重要性。主要内容包括：1. 密码绝对不应明文存储，否则一旦数据库泄露将造成严重后果；2. MD5等快速哈希算法已不适合现代密码存储，因其计算速度过快易被暴力破解；3. 即使加盐(salt)的MD5仍不够安全，因无法有效抵御现代计算设备的破解能力；4. 推荐使用bcrypt、Argon2id或PBKDF2等专门设计的密码哈希算法，这些算法具有计算成本可调、自带盐值、抗暴力破解等特性；5. 在Spring Security中应使用PasswordEncoder而非手动实现
2026-06-21 09:30:39
331
原创 密码与加密基础篇（1）：别再说 MD5 加密了：编码、摘要、加密到底有什么区别？
这篇文章澄清了开发中常见的加密概念混淆问题，强调准确区分编码、摘要、加密等概念的重要性。文章指出：Base64是编码而非加密；MD5/SHA是摘要算法不可逆；AES是对称加密可解密；RSA是非对称加密适合密钥保护；HTTPS是传输层安全；JWT是Token格式而非加密容器；AndroidKeystore用于密钥保护而非直接存储数据。文章通过对比分析，明确了密码存储、Token加密、接口签名等场景的正确技术选型，并纠正了"MD5加密"等常见错误表述。理解这些基础概念的差异，是构建安全系统的
2026-06-21 09:22:51
303
原创 移动端登录态安全设计（3）：AES-GCM + Android Keystore：Android Token 本地安全存储
本文详细介绍了Android应用中Token的安全存储方案，强调应采用多层防护机制：使用AES-GCM算法加密Token，密钥由Android Keystore系统生成和保护，加密后的密文存储在DataStore/MMKV等本地存储中。文章解答了关键问题，包括为何不直接存Token到Keystore、AES-GCM的选择原因、代码结构设计、老版本迁移策略等，并指出安全是一个整体工程，需配合HTTPS传输、日志脱敏、服务端Token失效机制等形成闭环。最终目标是实现"密文存储、密钥保护、运行时解密&
2026-06-20 10:40:35
465
原创 移动端登录态安全设计（2）：Token 拿到后，为什么不能明文存？
移动端Token安全存储最佳实践：避免明文存储，采用AES-GCM加密结合Android Keystore保护密钥。文章指出Token本质是用户身份凭证，若泄露将导致账户被盗用。建议将accessToken（短期）和refreshToken（长期）分开处理，后者需重点保护。通过加密存储、内存缓存、日志脱敏等多层防护，并配合后端Token失效机制，构建完整安全闭环。关键点是：先加密再存储（AES-GCM），密钥由Keystore保管，DataStore/MMKV仅存密文，运行时解密使用。同时需处理旧版本迁移、
2026-06-20 10:02:09
374
原创 移动端登录态安全设计（1）：App 登录时密码到底要不要加密？为什么通常走 HTTPS？
文章摘要：移动端登录接口中，密码传输的安全性问题常引发讨论。传统客户端MD5加密的做法（将密码哈希后传输）存在误区，因为哈希值实际上成为了等效密码。正确的安全实践应遵循：客户端通过HTTPS/TLS加密通道直接传输原始密码，后端使用bcrypt/Argon2等算法进行安全哈希校验和存储。密码安全的关键在于传输层HTTPS保护、后端安全哈希处理及严格的日志脱敏，而非客户端自行加密。高安全场景可叠加AES+RSA业务层加密，但绝不能替代HTTPS。核心原则是：客户端保证HTTPS传输且不存储密码，后端负责密码哈
2026-06-19 22:03:49
495
原创 从割草机项目聊地图业务中的边界处理：Android 开发必须考虑的 9 个问题
地图业务远比简单的点线面绘制复杂，尤其在割草机、机器人等场景中，边界处理涉及9大核心问题：工作区域与禁区边界的绘制校验；设备轨迹断点与定位漂移处理；贴边作业的安全距离判断；已割/未割区域的任务管理；用户绘制边界的合法性验证；App/设备/服务端的数据同步；以及地图坐标系的统一转换。Android侧需要重点关注状态展示、异常提示、数据校验和同步机制，确保设备位置、轨迹与用户认知一致，而非仅实现基础的地图绘制功能。
2026-06-19 13:05:51
400
原创 从 Interface 到 Lambda：一次串起 Java 和 Kotlin 的回调设计
文章摘要：本文通过作者设计日志库时的思考，系统梳理了从Java到Kotlin的回调机制演变过程。从最基础的Interface实现多态，到Listener模式的事件通知，再到Kotlin的Lambda和高阶函数，揭示了这些看似不同的技术本质上都在解决同一个核心问题：如何将行为逻辑传递给其他模块并在适当时机执行。作者通过对比分析指出，Interface更适合多回调场景的组织性，而高阶函数在单回调场景中更轻量简洁。最终认识到技术演进的本质是同一设计思想在不同语言时代的差异化呈现。
2026-06-16 07:25:35
888
原创 Kotlin 协程设计思想（十）：Kotlin 协程到底解决了什么问题？
本文系统梳理了Kotlin协程的设计哲学，通过分析异步编程发展历程（从Thread、Executor、Future到Callback、RxJava），揭示了协程诞生的必然性。文章指出协程并非简单的"轻量级线程"，而是一套完整的任务管理模型：CoroutineContext/Job/Dispatcher/Scope/Suspend构成任务流（TaskFlow）体系，Flow/StateFlow/Channel等组件构成数据流（DataFlow）体系。最终阐明Kotlin协程的核心价值在于统
2026-06-09 17:29:33
298
原创 Kotlin 协程设计思想（九）：Flow 到底是什么？为什么 suspend 函数还需要 Flow？
Kotlin Flow的设计哲学可以概括为：为解决连续异步数据流问题而设计的支持挂起的Sequence。相比suspend函数只能处理单次异步结果（如网络请求），Flow专门应对需要持续产生数据的场景（如定位、WebSocket、下载进度等）。其核心特点包括：1) 通过emit/collect两个挂起函数实现生产者和消费者的速度协调；2) 采用Cold模式按需启动数据生产，配合生命周期更安全；3) 与协程体系其他组件形成完整解决方案（StateFlow处理状态、SharedFlow处理事件等）。Flow本质
2026-06-08 23:27:21
524
1
原创 Kotlin 协程设计思想（八）：suspend 到底是什么？为什么 suspend 不是开启协程？
Kotlin协程的suspend关键字并非启动协程，而是标记函数可能挂起。真正的协程启动器是launch/async/runBlocking。suspend的核心在于允许函数内部出现挂起点，通过Continuation机制实现协程的暂停与恢复。编译器会将suspend函数转换为状态机，Continuation保存执行现场，使协程能从中断处继续执行。这种机制让异步代码以同步方式书写，同时避免线程阻塞。理解suspend和Continuation是掌握Kotlin协程底层设计的关键，它揭示了协程的本质是挂起/恢
2026-06-08 21:38:13
433
原创 管理类考研数学第一章、第二章：整数和实数错题整理、对应知识点与解题思路
本篇是我第一轮学习管理类考研数学“整数与实数”部分后的错题复盘笔记。重点不是讲给别人看，而是方便自己后续复习。以后遇到同类题应该怎么想。
2026-06-06 19:48:03
303
原创 Kotlin 协程设计思想（七）：为什么 Kotlin 要设计 SupervisorJob 和 supervisorScope？
本文深入解析Kotlin协程中SupervisorJob()与supervisorScope{}的本质区别： 功能定位 SupervisorJob是Job配置项，植入CoroutineContext后可使兄弟协程异常互不传播（如ViewModelScope设计） supervisorScope是作用域构造器，临时创建异常隔离域（适合多独立任务场景） 设计思想 两者共同实现结构化并发的异常控制策略：SupervisorJob配置运行环境，supervisorScope划定隔离边界，本质都是阻止异常无限传播。
2026-06-06 15:19:41
362
原创 Kotlin 协程设计思想（六）：结构化并发到底是什么？为什么 Google 一直强调 Scope？
本文深入解析Kotlin协程的核心设计理念——结构化并发。结构化并发要求所有协程必须组织成树状结构（Job树），每个协程都有明确的父节点和生命周期归属。Scope作为Job树的根节点，定义了协程的生命周期边界（如ViewModelScope、LifecycleScope），确保父节点取消时所有子协程自动终止。与Java线程的随意创建不同，协程通过这种结构化设计解决了生命周期管理和内存泄漏问题。GlobalScope因缺乏父节点而被视为反模式，而repeatOnLifecycle等机制则通过动态Job树实现精
2026-06-06 15:01:58
255
原创 Kotlin 协程设计思想（五）：协程异常为什么这么难理解？
本文深入解析Kotlin协程异常传播机制，核心观点是"异常永远沿着Job树向上传播"。文章对比了launch和async的异常处理差异：launch会立即将异常传播给父协程，而async则将异常暂存于Deferred对象，直到await调用时才抛出。同时解释了CoroutineExceptionHandler失效原因、try-catch的适用场景，以及SupervisorJob的隔离作用。通过Job树的传播模型，揭示了协程异常处理的底层逻辑，并给出项目实践建议：launch内部使用try
2026-06-03 20:46:27
257
原创 Kotlin 协程设计思想（三）：Dispatchers 到底是什么？切线程真的只是切线程吗？
本文深入解析Kotlin协程中Dispatcher的设计思想，指出其本质是协程调度策略而非简单线程切换。Dispatchers.IO通过动态扩容线程池（最大64线程）处理阻塞型任务；Dispatchers.Default固定为CPU核心数线程，专用于计算密集型任务；Dispatchers.Main确保UI线程执行。文章澄清了withContext与launch的本质区别（换车道vs开新车），并揭示Dispatcher作为CoroutineContext核心组件，是连接协程与线程的调度桥梁。
2026-06-03 01:30:00
886
原创 Kotlin 协程设计思想（四）：launch、async、withContext 到底有什么区别？
本文深入解析Kotlin协程的三种启动方式：launch、async和withContext。launch用于启动无需返回值的任务，返回Job对象用于管理任务生命周期；async用于并发执行并获取结果，返回Deferred<T>对象；withContext则是在当前协程中切换运行环境并等待结果。文章通过对比三者的设计思想、使用场景和异常处理机制，阐明了它们在结构化并发中的作用：launch解决任务启动、async解决并发结果、withContext解决上下文切换。最后指出理解这些核心概念才能真正
2026-06-02 10:16:12
451
原创 Kotlin 协程设计思想（二）：Job 到底是什么？为什么协程能被取消？
本文深入解析Kotlin协程的Job机制：1. Job本质是协程生命周期管理器，负责记录启动/完成/取消状态及父子关系；2. 协程取消是协作式的，通过状态变更而非强制终止；3. Job树实现结构化并发，父Job取消会级联取消子Job；4. SupervisorJob允许子协程独立失败；5. viewModelScope等生命周期感知源于Job树设计；6. 结构化并发确保协程始终有父级管理，避免内存泄漏。文章还对比了普通Job和SupervisorJob的差异，并预告下篇将探讨Dispatchers的设计思想
2026-06-02 08:50:46
260
原创 Kotlin 协程设计思想（一）：CoroutineContext 到底是什么？为什么 Job 和 Dispatcher 可以直接相加？
文章摘要： 本文揭示了Kotlin协程的核心设计——CoroutineContext的本质，它并非普通对象，而是一个类似Map<Key, Value>的配置集合，用于管理协程的运行环境。通过解析SupervisorJob() + Dispatchers.IO等常见写法，指出+操作实则是合并上下文配置（如Job、Dispatcher），而非数学加法。文章强调CoroutineContext是协程体系的根基，统一承载线程调度、生命周期、异常处理等关键配置，并预告后续将探讨Job的取消机制与结构化并发
2026-06-01 10:36:46
638
1
原创 企业认证与安全体系（五）：Spring Security + JWT + Redis 企业级认证实战
本文介绍了基于SpringSecurity+JWT+Redis的企业级认证系统实现方案。主要内容包括：1）系统需求分析，支持多端统一认证、Token续签、强制下线等功能；2）项目结构设计，划分JWT工具类、认证过滤器等模块；3）核心实现步骤：登录认证、JWT生成、Redis会话管理、续签机制等；4）企业级功能实现，如单设备登录、强制下线等；5）面试常见问题解答。该方案整合了SpringSecurity的认证框架、JWT的无状态特性和Redis的会话管理能力，形成完整的企业认证体系。文末预告了下篇将探讨微服务
2026-05-31 08:14:09
249
原创 企业认证与安全体系（四）：企业登录认证流程全解析——JWT、Redis、Spring Security 如何协同工作？
SpringSecurity是企业级认证授权框架，其核心价值在于提供标准化的安全解决方案，而非仅是JWT或权限管理。它将认证流程抽象为：请求→身份解析（支持JWT/OAuth2等多方式）→构建Authentication对象→存入SecurityContext→自动权限校验。这种设计使业务代码无需关心底层认证方式变更（如JWT切换为OAuth2），通过过滤器链实现全流程自动化，避免了重复开发Token解析、权限校验等通用逻辑。企业采用SpringSecurity的关键在于其工程化封装能力和高扩展性，能快速适
2026-05-30 22:23:59
307
原创 callbackFlow 实战：如何把定位、蓝牙、WebSocket 回调改造成 Flow？—— 从 Callback 到 Flow，彻底讲透 callbackFlow 的设计思想
本文系统讲解了Kotlin Flow中的四种核心模型：StateFlow用于管理状态，SharedFlow处理事件，Channel实现队列消费，callbackFlow则作为连接系统回调与Flow的桥梁。重点解析了callbackFlow的设计意义、实现原理（通过Channel转换回调数据）及使用场景（定位、蓝牙等系统回调），并对比了它与SharedFlow的适用场景差异。文章通过多个实战案例展示了如何将传统回调封装为Flow流式操作，最终构建起完整的Flow知识体系，帮助开发者理解状态、事件、队列和回调四
2026-05-30 18:25:10
256
原创 Channel 与 callbackFlow：Google 为什么还要设计第三套模型？—— 从 State、Event 到 Queue，彻底串起 Kotlin Flow 体系
这篇文章系统梳理了Kotlin Flow体系中StateFlow、SharedFlow、Channel和callbackFlow四种数据流动模型的本质区别与应用场景： StateFlow处理持久状态（如页面状态），像教室黑板持续展示最新信息； SharedFlow处理瞬时事件（如Toast），像广播一次性通知多个接收者； Channel实现消息队列（生产者-消费者模型），保证消息单次消费； callbackFlow作为适配器，将回调API转换为Flow流式处理。 文章通过生活化类比（黑板/广播/作业分发）揭
2026-05-30 09:38:27
283
原创 StateFlow 与 SharedFlow：Google 为什么要设计两套 Flow？—— 从一次 tryEmit(false) 到 WindowLeaked，彻底理解 Flow 的设计思想
本文通过实际项目踩坑经历，深入解析了Kotlin中StateFlow和SharedFlow的设计差异。作者发现SharedFlow的tryEmit()可能返回false，进而探究出：StateFlow用于持久状态（如loading状态），具有粘性；SharedFlow用于一次性事件（如Toast），默认不粘性。关键区别在于replay和buffer参数的设计，前者保存最新状态，后者控制事件传递机制。文章还揭示了正确处理生命周期的重要性，指出Google通过这两种Flow引导开发者建立状态(State)、事件
2026-05-29 16:23:50
245
原创 Android企业级网络架构实战：一套完整的双Token认证解决方案 ——（401自动续期｜请求重放｜RefreshToken刷新｜并发401治理）
本文介绍了一套Android企业级双Token认证方案，重点解决传统单Token机制在复杂场景下的问题。方案采用AccessToken(短期)和RefreshToken(长期)双Token机制，通过以下核心组件实现： TokenManager统一管理Token状态，包含内存缓存和持久化存储 TokenAuthInterceptor拦截请求和401响应，实现自动续期和请求重放 独立RefreshRetrofit避免拦截器循环 TokenRefresher处理并发刷新，采用synchronized+锁内二次检查
2026-05-29 15:37:16
1257
原创 第一篇：为什么多个 Flow collect 必须 launch？——一篇讲透 Android 协程生命周期
Android开发中Flow的正确收集方式 摘要：本文深入剖析了Kotlin协程中Flow收集的常见误区。很多开发者会遇到多个collect时第二个不执行的问题，这是因为collect是长期挂起操作，会阻塞后续代码。正确做法是使用launch创建子协程并发收集。文章详细解释了lifecycleScope的本质和局限，推荐使用repeatOnLifecycle实现生命周期感知的收集，并提出了结构化并发的企业级解决方案。核心观点包括：1) collect是持续监听操作；2) 多个Flow需要并发收集；3) li
2026-05-27 17:28:45
359
原创 企业认证与安全体系（三）：一篇讲透 JWT 原理与企业级实践
JWT是一种自带身份信息的Token，由Header、Payload和Signature三部分组成。其核心原理是通过签名算法确保数据不可篡改，实现无状态认证，服务端只需验签无需查库，性能极高。但JWT存在无法主动失效的缺陷，企业通常采用JWT+Redis混合方案：JWT负责高频认证，Redis管理会话生命周期。JWT仅适合存储非敏感信息，必须配合HTTPS使用。这种组合方案既保留了JWT的高效特性，又解决了会话控制问题，成为企业级认证的主流实践。
2026-05-25 09:01:34
452
原创 (管综逻辑) 第一章核心总结: 一篇真正讲透联言、选言、假言与命题转换
摘要：管综逻辑的核心在于掌握三大关键：德摩根律、箭头公式和逆否命题。德摩根律用于拆解否定命题（¬(P∧Q)=¬P∨¬Q，¬(P∨Q)=¬P∧¬Q）；箭头公式实现条件命题与选言命题的转换（P→Q=¬P∨Q）；逆否命题则用于等价推理（P→Q=¬Q→¬P）。联言命题（P∧Q）强调"且"关系，选言命题（P∨Q）表示"或"关系，不相容选言（P⊕Q）则要求有且仅有一个为真。解题时只需遵循"拆括号→变箭头→做逆否"的流程，即可化繁为简。特别注意中文关键词的逻辑对
2026-05-24 21:53:13
464
原创 企业认证与安全体系（二）：为什么很多企业放弃纯 JWT，而选择 Token + Redis？
企业认证体系往往放弃纯JWT方案，转而采用Token+Redis混合模式。虽然JWT具有无状态、分布式友好等优势，但其致命缺陷是无法主动失效令牌，导致用户退出或账号异常时仍能通过验证。企业更关注会话的可控性，如强制下线、风险控制等功能，这正是Redis的强项。Redis支持TTL过期、主动删除等特性，完美契合企业级认证需求。实际应用中，高频接口调用使用JWT验签，会话管理则交给Redis，形成优势互补。这种混合方案既保留了JWT的性能优势，又通过Redis实现了精细化的会话控制。
2026-05-24 11:40:18
405
原创 第五篇：NMEA、RTCM、NTRIP 到底是什么？——RTK 数据链路详解
本文深入解析RTK系统的数据链路，重点介绍NMEA、RTCM和NTRIP三大核心协议。NMEA是GNSS定位数据输出格式，包含经纬度、速度等关键信息；RTCM作为差分数据传输协议，承载卫星误差修正数据；NTRIP则通过网络传输RTCM差分数据。文章详细阐述了RTK工程中的数据流：从卫星信号接收、基站生成RTCM差分数据，到通过NTRIP网络传输，最终由RTK模块输出NMEA定位数据。同时指出了工程实践中常见的网络延迟、数据解析等问题，并提供了面试标准答案模板。最后预告了下篇将探讨Android/IoT设备接
2026-05-24 10:36:16
655
原创 第四篇：Point-In-Polygon 是什么？——机器人电子围栏核心算法
这篇文章深入解析了机器人电子围栏的核心算法Point-In-Polygon（PIP）。电子围栏通过判断机器人当前位置是否在预设多边形区域内来防止越界，主要采用射线法进行判断：从点向右发射射线，与多边形边相交奇数次则在内部，偶数次则在外部。文章指出RTK定位系统与电子围栏是两套独立系统，RTK负责定位，PIP算法负责边界判断，二者共同构成完整的电子围栏系统。文中还讨论了工程实现中的常见问题，如RTK漂移、控制延迟等导致的边界误差，并提供了面试标准答案。
2026-05-23 16:51:20
861
原创 第三篇 ：机器人为什么会“漂”？——RTK 漂移问题详解
RTK定位漂移问题解析 RTK技术虽能实现厘米级定位，但在实际应用中常出现漂移现象。主要原因包括：1）卫星信号遮挡导致定位精度下降；2）多路径效应造成信号反射误差；3）差分数据不稳定或中断；4）未达到FIX状态（仅处于FLOAT或SINGLE状态）。此外，天线质量、安装位置及环境干扰也会影响定位精度。 工程实践中，高端机器人系统通常采用多传感器融合方案（RTK+IMU+视觉+激光雷达+SLAM），而非单一依赖RTK。IMU负责短时运动估计，在RTK信号丢失时维持系统稳定，待RTK恢复后再进行校正。这种组合方
2026-05-23 15:59:42
733
原创 为什么 Android App 启动会白一下？——一篇讲透 Android SplashScreen 启动机制演进
Android启动白屏问题与SplashScreen演进解析 摘要：Android启动白屏问题本质源于StartingWindow阶段的背景色处理。传统方案通过SplashActivity+windowBackground模拟启动页，但Android12后系统引入SplashScreen API，强制接管启动流程。现代解决方案应分层处理：系统Splash负责防白屏过渡（Theme.SplashScreen），业务SplashActivity处理广告等逻辑。关键变化在于Android12将启动页升级为系统级能
2026-05-22 09:51:58
556
原创 为什么 Android 正在从 LiveData 全面转向 StateFlow？——一篇讲透 LiveData、StateFlow 与 SharedFlow
本文深入解析了Android开发中LiveData、StateFlow和SharedFlow的核心区别与适用场景。LiveData是Android专用的生命周期感知数据容器，适合传统MVVM架构；StateFlow是协程原生的状态流，适合UI状态管理；SharedFlow则是事件流，适合处理一次性事件。文章指出Google转向Flow的本质是将生命周期管理从数据层解耦到UI层，体现了架构从"封装式"到"组合式"的升级。建议新项目采用StateFlow+SharedFl
2026-05-20 20:22:15
377
原创 第二篇 ：RTK 为什么比 GPS 准？——差分定位原理详解
RTK技术通过差分定位实现厘米级精度，其核心在于利用固定基站实时修正GPS误差。基站通过比较已知位置与GPS计算结果获取误差数据，并发送给移动设备进行修正。由于基站与设备距离相近，二者受到的大气层、卫星时钟等误差影响相似，使修正有效。RTK常与IMU等传感器融合使用，在信号遮挡时维持定位。该技术解决了普通GPS米级误差问题，但会受环境因素影响精度。
2026-05-18 18:08:06
522
原创 第一篇：为什么机器人能厘米级定位？——一篇讲透 GPS、北斗 与 RTK
《从GPS到RTK：揭秘厘米级定位技术的关键突破》 传统GPS定位存在3-10米的误差，难以满足机器人、自动驾驶等高精度需求。RTK技术通过基站差分修正，将定位精度提升至厘米级。其核心在于基站通过对比已知坐标与GPS数据，计算出实时误差并发送给移动端进行修正。这种技术已广泛应用于割草机器人、无人车、农机作业等领域，通过与IMU、电子围栏等系统的协同工作，构建完整的精准定位体系。文章系统解析了GPS误差来源、RTK工作原理及工程实现要点，揭示了现代定位技术从"米级"到"厘米级&q
2026-05-17 11:17:28
688
原创 企业认证与安全体系（一）：为什么企业都在用双 Token 机制？一篇讲透 AccessToken、RefreshToken 与企业级认证体系
企业级认证体系的核心在于双Token机制（AccessToken+RefreshToken），通过短期有效的AccessToken（30分钟-2小时）降低泄露风险，配合RefreshToken实现无感续签。RefreshToken需设置有效期（通常7天）并存储于Redis而非JWT，以支持主动撤销和安全管控。典型实现包含JWT+Redis组合、Token轮换机制和自动续签流程，同时延伸出OAuth2、权限管理等完整安全体系。该设计平衡了安全性与用户体验，解决了传统Session的扩展性问题，形成包含会话生命
2026-05-17 07:40:32
422
8方向控制圆盘-android
2025-10-30
Android Dsbridge （前端Vue3.0打包）
2025-10-30
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人