- 博客(217)
- 收藏
- 关注
RSS订阅
原创 【WonderTrader源码详解】【写作大纲】
WonderTrader是一个基于C++的高性能量化交易框架，支持全市场品种交易，具备专业机构级架构和数十亿级实盘管理能力。该框架覆盖数据清洗、回测分析、实盘交易等全流程，通过wtpy应用层实现易用的一站式解决方案。最新0.9版本引入UFT引擎，系统延迟优化至175纳秒以内。文章将首先介绍Anaconda安装和WonderTrader编译等环境搭建步骤。
2025-08-13 21:19:21
575
原创 【车载 AOSP 蓝牙(bluedroid) 协议分析】【整体计划】
controller: 蓝牙模组host: android 上层协议栈蓝牙模组 通过uart/spi/sdio 等接口，将数据传递给 host 侧。那host 如何解析controller 的数据。是通过 hci 规定的协议。双方才能正常交流。hci 层将数据解析完成后，会根据对应的分类，将数据继续上报给更高层次的协议。例如 两个设备 连接完成后，建立acl 通道。但是此时 两个设备之间 不知道彼此支持那些功能。
2025-03-27 14:37:10
4010
6
原创 【BT-SIG】【Core_v6.2】【Vol 3 Host】【Part G: GATT】【3.3】【3.3.3 Characteristic descriptor declaration】
原文引用 (Paragraph Level)原文翻译 (Paragraph Level)特征描述符用于包含关于特征值的相关信息。GATT 配置文件定义了一组可供高层规范使用的标准特征描述符。高层规范也可以定义特定于该规范的额外特征描述符。每个特征描述符都由特征描述符 UUID 进行标识。客户端应当（shall）支持使用 16 位和 128 位特征描述符 UUID。客户端可以（may）忽略任何带有未知特征描述符 UUID 的特征描述符声明。
2026-04-15 18:04:55
882
原创 【BT-SIG】【Core_v6.2】【Vol 3 Host】【Part G: GATT】【3.3】【3.3.2 Characteristic value declaration】
摘要： 特征值声明是蓝牙GATT协议中存储实际特征数据的核心属性，必须紧跟在特征声明之后。它包含三个关键部分：属性类型（使用特征声明中的UUID）、属性值（存储特征具体数值）和访问权限（可灵活配置）。特征值声明相当于"快递包裹中的商品"，而特征声明则如同"快递面单"。协议严格规定了两者的位置关系——特征值必须作为特征声明后的第一个属性存在。访问权限方面，特征声明必须公开，但特征值可以设置加密、授权等保护措施。这种设计既保证了设备可发现性，又能灵活保护敏感数据。
2026-04-15 17:40:49
342
原创 【BT-SIG】【Core_v6.2】【Vol 3 Host】【Part G: GATT】【3.3】【3.3.1 Characteristic declaration】
原文引用 (Paragraph Level)原文翻译 (Paragraph Level)一个服务可以拥有多个具有相同特征 UUID（Characteristic UUID）的特征定义。通俗技术释义 (Paragraph Summary)💡这一句打破了一个常见的误解：一个服务里只能有一种特征。实际上，协议允许你定义多个名字完全一样的特征。例如一个“环境监测服务”，它可以定义两个“温度特征”，一个用来表示室内温度，一个用来表示室外温度。
2026-04-15 15:03:20
331
原创 【BT-SIG】【Core_v6.2】【Vol 3 Host】【Part G: GATT】【3.3 Characteristic definition】
SIG规范解析：特征定义要点 特征定义由三部分组成：必须包含特征声明和特征值声明，可选包含特征描述符声明。特征定义的边界由下一个特征/服务声明或最大属性句柄决定，各属性按句柄顺序排列在服务器中。 关键规则： 特征声明与特征值声明必须连续排列 特征描述符声明（可选）必须排在特征值声明之后 支持通过聚合特征值优化多数据读写，需使用唯一UUID并可选添加格式描述符 特征定义采用"声明+值+描述符"的层级结构，通过严格的排列顺序和句柄连续性要求，确保数据访问的可靠性，同时提供聚合机制优化传输效率
2026-04-15 14:58:22
445
原创 【BT-SIG】【Core_v6.2】【Vol 3 Host】【Part G: GATT】【3.2 Include definition】
摘要： 蓝牙协议中的"包含定义"机制允许服务间相互引用，其属性值包含被引用服务的起始/结束句柄及可选的16位UUID（128位UUID通过句柄间接关联）。协议严格禁止循环引用（如A包含B，B又包含A），发现此类情况客户端应终止连接。包含声明必须置于服务声明之后、特征定义之前，且保持只读权限。该设计类似文件系统中的快捷方式，通过句柄指向实现服务复用，同时避免无限递归风险。实现时需注意被引用服务必须真实存在，且包含声明本身无需鉴权。
2026-04-14 10:55:28
370
原创 【BT-SIG】【Core_v6.2】【Vol 3 Host】【Part G: GATT】【3.1 Service definition】
服务定义规范摘要 蓝牙GATT协议中，服务定义是数据库的基本组织单元，具有以下核心要求： 结构规则： 服务必须包含声明，可选包含include和特征定义 严格遵循"声明→include→特征"的层级顺序 通过属性句柄范围隐式界定服务边界 访问控制： 服务声明必须设为只读且无需认证 支持16位和128位UUID格式 允许重复UUID的服务定义 优化建议： 相同类型UUID的服务应连续排列 客户端不应假设服务排序 所有属性必须归属于某个服务 这些设计确保了服务发现的效率和兼容性，同时保持足够
2026-04-13 19:44:15
355
原创 【BT-SIG】【Core_v6.2】【Vol 3 Host】【Part G: GATT】【2.Profile overview】
原文逐字翻译：操作码 (Opcode) 包含特定的命令、请求、响应、指示、通知或确认操作码，以及一个用于认证的标志。属性参数 (Attribute Parameters) 包含特定命令或请求的数据，或者在响应、指示或通知中返回的数据。深度技术释义1字节 Opcode + 若干字节 Parameters + 可选的 12字节签名。原文逐字翻译。
2026-04-13 16:18:14
507
原创 【BT-SIG】【Core_v6.2】【Vol 3 Host】【Part G: GATT】【1. Introduction】
GATT协议摘要 GATT（通用属性配置文件）是蓝牙低功耗（BLE）的核心服务框架，构建于ATT协议之上。它将底层属性组织为"服务"和"特性"的层级结构，定义了发现、读写、通知等标准化操作流程。GATT通过UUID标识服务类型，采用客户端/服务器模型，将复杂的ATT属性操作封装为业务友好的接口。开发者只需关注"心率服务"等逻辑概念，无需直接处理底层属性地址。协议支持通知（无确认）和指示（需确认）两种推送方式，其架构类似酒店服务体系，通过服务分类和特
2026-04-13 14:32:32
379
原创 【车载 AOSP 蓝牙(bluedroid) 协议分析 26】【controller 相关 2】【车载环境下的蓝牙统一配对与负载均衡实现方案】
本文阐述了基于高通芯片组的车载信息娱乐系统（IVI）与真无线耳机（TWS）的连接方案。通过TrueWireless Mirroring（TWM）技术实现车机与耳机的三方协同，重点介绍了统一配对和负载均衡两大核心功能。统一配对通过共享地址和密钥同步，使车机仅识别单一蓝牙设备；负载均衡则通过动态角色切换平衡功耗和信号质量。系统采用分层架构，将核心逻辑下沉至耳机固件，车机负责传输和展示，既确保连接稳定性又降低开发复杂度。同时提出了针对不同品牌耳机的兼容方案，通过标准协议与私有扩展相结合实现广泛适配。
2026-03-18 18:54:47
188
原创 【20个考研阅读常见谚语 + 句型 + 语法分析】
没有付出就没有收获。结构：no A without B例句：No progress without effort.熟能生巧。结构：practice (主语) + makes (谓语) + perfect (宾语补足语)类似句：Experience makes people wiser.有志者事竟成。结构：Where there is A, there is B类似：Where there is smoke, there is fire.罗马不是一天建成的。意思：成功需要时间。结构：被动语态was buil
2026-03-12 08:13:03
65
原创 【车载audio】【AudioService 01】【Android 音频子系统分析：按键音（Sound Effects）开启与关闭机制深度解析】
本文深入分析了Android系统中按键音（Sound Effects）的开启与关闭机制。系统通过SettingsProvider存储开关状态（0/1），AudioService监听该状态并控制音效播放流程。当关闭时，AudioService拦截播放请求并释放SoundPool资源；开启时则预加载音效文件实现低延迟播放。该机制体现了"按需分配"设计思想，在保证交互实时性的同时优化系统资源。通过ADB命令可验证该机制：修改Settings值后，AudioService会相应调整资源加载状态和
2026-03-10 14:43:16
689
原创 【车载audio】【CarAudioService 05】【车载 Android 系统调试深度指南：解析 dumpsys car_service】
本文深入解析Android Automotive OS (AAOS)中dumpsys car_service命令输出的关键信息。重点分析了音频子系统(ArbitrationTable仲裁策略)、驾驶状态服务(档位识别)、乘客区管理(多屏映射)和UX限制管理等核心模块的日志特征。特别针对音频问题提供了专项排查技巧，包括音频路由确认、音量限制原因分析、音量曲线检查以及多音区独立控制验证。通过系统化解读这些诊断数据，开发者可以快速定位车载系统中的各类功能异常，如声音播放异常、多屏互动问题等，实现高效的问题诊断与解
2026-03-05 14:25:19
547
原创 【车载audio】【CarAudioService 04】【通过最大音量和默认音量的设置来学习car_audio_configuration.xml文件】
摘要 本文分析了Android车机系统中音量配置的解析过程。系统启动时，CarAudioService通过getAudioConfigurationPath()获取配置文件路径/vendor/etc/audio_ar/car_audio_configuration.xml。当init()被调用时，若启用动态路由（mUseDynamicRouting=true），会触发setupDynamicRoutingLocked()进行核心配置。关键步骤包括：1) 通过loadCarAudioZonesLocked()
2026-03-03 17:58:28
647
原创 【车载audio】【CarAudioService 03】【深度解析 AOSP 音频音量曲线：从数学模型到专业调音】
摘要：本文深入解析AOSP音频音量曲线的设计与调音原理。音量曲线是UI步进与实际衰减增益值的映射关系，通过数学模型抵消人耳非线性感知特性。随意调整曲线会导致陡峭感、动态范围损失等问题，必须保持单调递增和平滑斜率。专业音频设备（如APx500分析仪、人工耳）可用于实测校准，通过电信号和声学测量确保每级音量提升符合线性感知。调音需结合硬件底线、设备类别定义和多点插值，实现软硬件协同优化。音量曲线设计是声学测量与心理声学的结合，需专业调校才能打造细腻的音频体验。（149字）
2026-03-03 11:39:42
1068
原创 【车载audio】【CarAudioService 02】【主动获取音量大小流程分析】
本文分析了CarAudioManager.getGroupVolume接口的实现原理。当应用调用该接口获取音量时，会跨进程调用CarAudioService，通过zoneId和groupId找到对应的CarVolumeGroup对象，最终返回其mCurrentGainIndex值。同时，手动设置音量时也会更新这个变量。要实现CAN总线音量同步，只需将CAN信号对应的音量值更新到CarVolumeGroup.mCurrentGainIndex中，应用就能通过getGroupVolume获取最新值。整个流程涉及
2026-03-02 19:43:13
412
原创 【车载Audio】【AudioHal 09】【高通音频架构】【SA8295P 音频资源管理器 (ResourceManager) mixer_paths.xml 深度解析 】
摘要：本文分析了SA8295P智能座舱音频子系统的初始化过程，重点探讨了ResourceManager::init_audio函数实现声卡探测的核心逻辑。该过程采用轮询机制遍历/dev/snd/controlC*节点，识别gvmauto硬件声卡或VIOSND虚拟声卡，并拼接对应的mixer_paths配置文件路径。代码通过动态获取声卡名称、匹配平台标识、处理驱动加载延迟等关键步骤，最终完成音频硬件与虚拟设备的初始化配置，为后续音频功能提供基础支持。
2026-02-21 19:11:07
1098
原创 【车载Audio】【AudioHal 08】【高通音频架构】【SA8295P 音频资源管理器 (ResourceManager) 决策逻辑深度解析 】
本文深入解析了SA8295P平台音频系统中的ResourceManager决策逻辑，重点分析了XML配置文件的加载与解析机制。ResourceManager通过Expat流式XML解析库动态加载/vendor/etc目录下基于声卡名称拼接的配置文件（如resourcemanager_gvmauto8295_adp_star.xml）。解析过程采用事件驱动模型，通过注册startTag和endTag回调函数处理不同业务场景：包括语音唤醒(SoundTrigger)模块、自动内容检测(ACD)模块以及分组设备配
2026-02-21 15:51:45
1034
原创 【车载Audio】【AudioHal 07】【高通音频架构】【从逻辑策略到物理执行】
本文深入解析SA8295P车载平台的音频子系统架构，通过"导演与调音师"的比喻形象说明其运作机制。系统通过两套XML配置文件协同工作：resourcemanager.xml作为"决策手册"定义逻辑策略和设备绑定，mixer_paths.xml作为"操作指令"控制底层硬件通路。文章详细剖析了配置参数、设备画像、通路定义等关键元素，并配有时序图展示音频播放时的系统协作流程。最后提供了实用的调试指南，帮助定位"无声"问题。整个架构通过
2026-02-20 14:08:42
875
原创 【车载Audio】【AudioHal 06】【高通音频架构】【深入浅出 Android Audio HAL：从加载到函数指针绑定的全链路解析】
本文深入解析了Android音频架构中Audio HAL的加载与初始化全链路过程。从AudioFlinger通过HIDL接口发起请求，到DevicesFactory加载厂商HAL库（.so），再到最终绑定音频设备函数指针的关键步骤。重点分析了loadAudioInterface如何加载库文件，adev_open如何初始化硬件设备，以及Init函数如何完成C函数指针与C++实现的绑定。通过时序图展示了跨进程调用的完整流程，揭示了Android音频系统从框架层到硬件驱动的连接机制，为理解Android音频HAL
2026-02-17 11:38:12
870
原创 【车载Audio】【AudioHal 05】【高通音频架构】【audio_hw_device 核心接口解析】
本文解析了Android Audio HAL中的核心接口audio_hw_device结构体。该结构体作为音频硬件抽象层的关键组件，定义了音频设备必须实现的操作契约，包括设备初始化检查、音量控制、模式设置、麦克风静音等功能接口。重点介绍了open_output_stream和open_input_stream方法，它们分别用于创建和打开音频输出/输入流，支持不同设备类型（如蓝牙、USB）的地址参数格式。这些接口在Android音频系统中承担着连接上层服务与底层驱动的桥梁作用，统一了音频硬件访问规范。
2026-02-16 13:12:45
918
原创 【车载Audio】【AudioHal 04】【高通音频架构】【从 AHAL adev_open 到 PAL XML 解析：30微秒内的调用链深度追踪】
本文摘要：深入分析Android音频系统中AHAL与PAL模块的启动调用链，从Audio HAL的adev_open入口到PAL资源管理器的XML解析全过程。通过源码追踪揭示了：1) AudioFlinger通过HAL框架触发厂商audio.primary.so的加载；2) AHAL初始化时调用pal_init()拉起PAL模块；3) PAL单例ResourceManager构造时自动解析/vendor/etc/card-defs.xml等配置文件；4) 关键日志"XML parsing star
2026-02-14 15:51:20
978
原创 【车载Audio】【AudioHal 03】【深入解析 Android 音频策略：onNewAudioModulesAvailableInt 的全链路探索】
Android音频策略管理器中的onNewAudioModulesAvailableInt函数负责将XML配置转化为可用的音频资源。该函数首先扫描预定义硬件模块，通过AudioFlinger加载厂商HAL库（如audio.primary.xxx.so），然后对输出能力进行探测，包括采样率、格式等参数验证。核心流程包含两个关键阶段：1）物理链路试开流，通过AudioFlinger的openOutput接口验证硬件通路可用性；2）设备激活与挂载，只有开流成功的设备才会被加入可用设备池。函数还会处理TTS/超声波
2026-02-14 15:19:30
889
原创 【车载audio】【audio hal 02】【AudioFlinger 与 Audio HAL 的“握手”及硬件发现全链路】
本文深入解析了Android音频系统中AudioFlinger与Audio HAL的交互机制。当系统启动或驱动重启时，AudioFlinger通过hwservicemanager监听并获取Audio HAL的代理服务，触发设备工厂注册和回调通知链。关键点包括：ServiceNotificationListener捕获HAL服务上线、代理缓存到mDeviceFactories、通过独立线程异步处理回调避免死锁。整个流程实现了从底层硬件发现到上层策略管理的完整链路，确保了音频系统的可靠初始化。
2026-02-14 14:21:30
1092
原创 【车载audio】【AudioPolicyManager 01】【AudioPolicyClient 类介绍】
摘要：Android音频架构中的mpClientInterface是AudioPolicyManager(APM)与底层硬件交互的关键接口，采用委派模式设计。APM通过该接口调用AudioPolicyService(APS)执行硬件操作，如加载模块、打开音频流、设置参数等。初始化过程在APM创建时完成，由APS传入实现类AudioPolicyClient。这种设计实现了解耦决策与执行、便于测试、避免循环依赖。在车载系统中，AudioPolicyClient负责将APM的路由决策转化为具体操作，是连接策略层与
2026-02-13 18:00:59
965
原创 【车载audio】【AudioFlinger 01】【从 audio_policy_configuration.xml 静态配置到 mHwModulesAll 动态加载的全生命周期】
本文深入剖析了Android音频系统从配置文件到内存加载的全过程。音频策略管理器(APM)通过解析audio_policy_configuration.xml文件构建系统音频架构，该文件定义了硬件模块、播放/录音能力及设备链路等核心配置。系统启动时，XML配置经由PolicySerializer解析为AudioPolicyConfig对象，最终填充到mHwModulesAll全量模块列表。文章详细分析了XML标签与C++类的映射关系，包括模块(<module>对应HwModule)、接口(<
2026-02-13 16:44:54
1068
原创 【车载audio】【CarAudioService 01】【深度解析 AAOS 音量回调机制：从 VHAL 信号到 UI 刷新的全链路分析】
摘要：本文深入剖析了Android Automotive（AAOS）音量回调的全链路机制，从底层硬件信号到UI刷新的完整流程。当车载系统出现"音量条UI不刷新但实际音量变化"的问题时，需要排查跨进程通信链路。文章通过时序图展示了从VHAL信号→CarAudioService→Binder IPC→应用层Handler→UI刷新的完整路径，详细解析了应用层监听注册、Binder实例化、线程切换以及系统服务层的回调分发逻辑，为车载音频开发提供了全面的调试视角。（149字）
2026-02-12 21:06:42
1050
原创 【车载audio】【audio hal 01】【Android 音频子系统：Audio HAL Server 启动全流程深度解析】
Android音频子系统中的Audio HAL Server是连接Framework与硬件驱动的关键进程。本文深度解析了其全流程启动机制： 架构概述：作为Vendor层守护进程，负责加载驱动库并通过HIDL/AIDL接口与AudioFlinger交互。 启动流程： 由init进程根据rc配置拉起 初始化Binder线程池和共享内存 动态加载厂商实现的HAL库(.so) 向hwservicemanager注册服务 核心实现： 使用vndbinder进行跨分区通信 配置SYS_NICE权限保证实时性 通过属性控
2026-02-12 16:42:46
1590
原创 Passthrough HAL 中 HIDL_FETCH_xxx 的访问机制与对象生命周期解析
Passthrough HAL 对象的生命周期 = client 进程生命周期。
2026-02-12 15:07:02
1241
原创 【车载audio开发】【Qualcomm PAL 详解 6】【PAL 总体架构与模块交互指南】
本文介绍了Qualcomm PAL（Platform Audio Layer）的总体架构与模块交互机制。通过餐厅比喻形象地描述了各模块角色：Android HAL（顾客）、Stream（订单）、Session（厨房）、Device（餐桌）和ResourceManager（经理）。详细解析了音频播放全流程的三个阶段：创建连接、启动分配资源和数据传输，以及动态设备切换场景。文章还汇总了模块间关键接口，解答了常见问题，并提供了从入门到深入的学习路线建议，包括理解业务流程、系统配置、底层数据传输和实际配置修改等步骤
2026-01-21 20:19:21
986
原创 【车载audio开发】【Qualcomm PAL 详解 5】【Device 模块 介绍】
本文介绍了音频系统中的Device模块，将其比喻为"餐桌"或"食材来源"，对应硬件设备如麦克风、扬声器等。文章详细阐述了Device模块的核心类结构，包括Speaker、Headphone等子类，以及通过工厂模式创建实例的方式。重点讲解了Mixer Controls功能，说明Device通过TinyALSA Mixer控制硬件通路。文章还概述了关键接口如open、start、stop的操作逻辑，介绍了插件机制和常见问题排查建议。最后用表格总结了Device模块的主要功
2026-01-21 20:06:04
537
原创 【车载audio开发】【Qualcomm PAL 详解 4】【Session 模块 介绍】
Session模块是连接CPU与音频硬件的核心枢纽，负责建立和管理音频数据通路。它包含三种实现：基于TinyALSA的SessionAlsaPcm、基于AGM服务的SessionAgm和直接与GSL交互的SessionGsl。Session通过连接前端(FE)和后端(BE)设备，配置DSP处理图(Graph)，并使用mixer_ctl传输参数(TKV结构)。关键操作包括open建立连接、setConfig下发参数、prepare/start准备运行、read/write传输数据。开发者需注意FE/BE匹配、
2026-01-21 20:02:49
536
原创 【车载audio开发】【Qualcomm PAL 详解 3】【Stream 模块 介绍】
本文介绍了Android音频系统中的Stream模块，概括了其核心概念和实现机制。Stream代表具体的音频业务场景，采用工厂模式和多态设计，包含StreamPCM、StreamCompress等子类。文章详细描述了Stream的生命周期状态机、关键接口（创建、打开、启动、读写）及其调用流程，并分析了音量调节、音效设置等典型场景。最后通过生活化类比总结Stream功能，为开发者提供调试和扩展建议。Stream作为PAL顶层对象，负责管理音频业务全生命周期。
2026-01-21 19:56:01
622
原创 【车载audio开发】【Qualcomm PAL 详解 2】【ResourceManager 模块介绍】
本文介绍了Qualcomm PAL平台中的ResourceManager(RM)核心模块。RM作为音频系统的中央控制器，主要负责全局资源管理、并发控制、路由管理和配置解析。文章详细解析了RM的架构设计，包括关键数据结构如mActiveStreams、devInfo等，以及单例模式的实现方式。同时阐述了RM的初始化流程，包括XML配置解析、音频环境初始化和插件加载等核心步骤。重点讲解了流注册、设备连接/断开、设备切换和并发处理等核心功能的实现机制，并提供了常用接口函数参考表。最后给出了扩展新用例的指导建议和实
2026-01-21 19:50:44
698
原创 【车载audio开发】【Qualcomm PAL 详解 1】【 Qualcomm PAL (Platform Audio Layer) 深度开发指南】
高通PAL音频中间件开发指南摘要 PAL（Platform Audio Layer）是高通音频架构中的用户空间中间件，位于Android Audio HAL与内核驱动/DSP之间，提供统一API并支持多平台适配。其核心采用Stream-Session-Device三层架构，由Resource Manager统一调度： Stream：处理业务逻辑（如音乐播放、通话） Session：管理数据传输（DSP管道配置） Device：控制硬件路由与电源 RM：解析XML配置并仲裁资源冲突 典型流程包括流的创建（pa
2026-01-21 17:33:50
1084
原创 【ubuntu24.04】【安装jdk】
在 Ubuntu 24.04 中配置 JDK 主要包括 安装 Java、设置默认版本 和 配置 JAVA_HOME 环境变量，以下是详细步骤。
2026-01-16 15:23:48
193
原创 【vscode】【Continue】【插件使用】
pip安装：若MCP Server提供Python包，可通过pip install mcp-server安装。安装完成后，需配置MCP Server，包括环境变量和启动命令。这里可以选择 我们通过 ollama 安装的 模型。增加本地 ollama 模型。
2026-01-16 14:25:04
437
mbt reset 可以测试 蓝牙芯片通路
2026-04-03
ubuntu 下搭建 nrf52832 开发环境所需要的 软件包. md5sum : b61a6911bab6684f9721648740448926 nrf-52832-env-soft.7z
2025-06-25
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人