# 背景
获取安卓执行日志

# 操作
命令行执行：
```bash

Windows (PowerShell)：

adb logcat --pid=$(adb shell pidof com.abc.ddd) > test1202002.txt


Windows CMD：

adb logcat --pid=%(adb shell pidof com.abc.dddn)% > test.txt

```

同时观察Android Studio中的logcat日志，复制到文本中，双备份对比

安卓日志获取

# 背景
日常使用cursor时，发现有些措施可以使得代码提效的效率倍增（经实测，通常存在半个小时完成几天开发工作量情况），特此记录，方便后续持续优化



# cursor喜好
1. 对md格式相当友好
2. 对协议层、标准的代码、二进制理解友好
3. 对已经实现的部分参考实现友好（即新需求，建议先开始调研清楚后再看具体代码引入，大致要自己心里有个理解）
4. 可以让其写具体的开发文档，便于后续开发评审

# tips
1. rules
GPT增加cursor的rules配置
在项目根目录下增加.cursor/rules.md
如果是Django的，参考：
```js
# Cursor Rules - Python / Django 项目团队规范

## ✅ 基础代码规范
- 所有 Python 代码必须遵循 PEP8
- 变量、函数、方法使用 snake_case
- 类名使用 PascalCase
- 常量使用 UPPER_CASE
- 禁止无意义命名，如 a、b、tmp、test1
- 禁止提交 print 调试代码，使用 logging

## ✅ Django 项目结构规范
- apps/ 下每个模块是独立 Django APP，遵循 “单一职责”
- models 放在 models.py 或 models/ 目录
- serializers 放在 serializers.py
- views 放在 views.py 或 views/ 目录，不写业务逻辑
- 业务逻辑写在 services.py
- 工具类放在 common/utils
- 配置放在 config/，不可硬编码在业务中

## ✅ 数据库规范
- 所有模型字段必须写 verbose_name、help_text
- 必须开启 auto_now 或 auto_now_add 的时间字段
- 删除、更新尽量使用软删除
- QuerySet 操作必须捕捉异常，不能直接裸 try
- 不允许 N+1 查询，建议使用 select_related / prefetch_related

## ✅ API 接口规范（RESTful）
- 使用 DRF 编写 API
- 所有接口返回统一结构：

成功：
{
  "code": 0,
  "msg": "success",
  "data": {...}
}

失败：
{
  "code": 非0,
  "msg": "错误信息"
}

- 分页接口必须返回 total / page / page_size
- 不允许返回内部异常堆栈
- 所有接口必须有权限控制 （IsAuthenticated 或自定义权限）

## ✅ 注释规范
- 所有类、方法必须包含 docstring
- 函数必须写入参数说明、返回值说明
- 写关键业务逻辑时必须加注释
- 注释要说明 “做什么 + 为什么” 而不是“代码翻译”

## ✅ 依赖与环境规范
- 依赖固定在 requirements.txt
- 开发/生产分离：settings/dev.py、settings/prod.py
- 禁止将敏感信息（密码、密钥、URL）写死，必须使用环境变量
- migrations 必须提交

## ✅ Git 规范（遵循 Conventional Commit）
- feat: 新功能
- fix: 修 bug
- docs: 文档
- style: 格式（不影响逻辑）
- refactor: 重构（不影响功能）
- test: 测试
- chore: 构建、脚本、依赖管理

示例：
feat: add user login API
fix: fix token expire bug
refactor: move business logic to service layer

## ✅ 单元测试
- 所有 API 必须写测试
- 覆盖率不低于 70%
- 测试命名为 test_xxxx.py
- 必须断言 status_code 和返回结构

## ✅ 日志规范
- 用 logging，不用 print
- 错误级别必须包含上下文信息
- 不输出敏感数据（密码、token、手机号明文）

## ✅ 安全规范
- 表单和接口必须进行参数校验
- 禁止 SQL 拼接
- 密码必须加盐存储
- Token 必须带过期时间
- 不返回敏感数据（密码、ID卡号、密钥）

## ✅ 其他
- 遇到不确定实现方式，优先选择 Django 官方推荐实践
- 代码尽量可读、可维护、可测试，而不是“能跑就行”

```

2. 跨项目代码使用，可以直接把需要的项目放到当前项目下，然后chat中，使用@引入所需要的部分，加上描述使用，最后是有参考某某实现

```js
参考a2l文件的解析逻辑，这个页面http://localhost:8086/#/file/data/list?current=2&pageSize=20
调用解析逻辑时，参考后端Django的接口：class DataFileViewSet(ModelViewSet):
@action(detail=True, methods=['post'], url_path='parse-hex-data')
    def parse_hex_data(self, request, pk=None)
@src 
```

3. 如果是word或PDF等其他形式的文档，需要转换为md格式再使用@引入，加上描述，目的

```js
@hex_client.py 根据地址具体是怎么分析出来最终的物理值的？给出详细的分析过程
```

4. 如果直接指定模型使用，发现有时会特别轴，比如指定sonnet 4.5时（跟他说了几遍，注意事项和需求等还是会犯同样的问题），现在都是setting设置models圈定范围，默认AUTO即可

5. 如果跨不同IDE使用，即apk开发、iOS开发等，建议使用cursor描述开发，调试用对应的IDE，比如Android Studio调试

6. 多看极客时间相关课程，看看业界对这块使用的方式，对比自己的方式

7. 直接选中命令行或输出窗口中的情况（Add to chat），告知chat处理

```js
@Python (162-307) @a2l_client.py 存在很多乱码的情况，麻烦修复
```
8. 针对已经成熟模块的改动，建议分拆成一定模块来问，附带测试进行，避免引入新bug


# 为啥要优先AI编程
1. 可以基于已经存在的代码，快速实现，尤其是类似的；
2. 由于设定了rules，会默认按照最官方的方式实现，最标准，和不容易踩坑；
3. 不用完全熟悉具体底层实现，只需要知道大概需要用到什么即可，不需要自己想代码实现；
4. 联动上下游的，使用AI不容易忘记且少硬编码实现；

# 效率分析
业界某公司调研分析为：cursor 40%；copilot 35% 其他忽略不计

经内部日常使用分析，cursor起码能到80%以上的代码编写，尤其是新项目，或参考类似的、官方的实现；

1. hex解析、a2l解析，cursor实现了90%以上的代码，1个小时，顶起码一周的工作量；（分析了类似协议的实现，需要至少2周以上，但是cursor+清晰文档md化后，1个小时就可以实现绝大部分类型协议的实现，经测试无误）
2. 日常接口新增字段，抽象类型定义及工具类的实现，cursor半个小时内可以解决起码要写一个早上的代码效果工作量；

# 其他
gemini 3 Pro
目前发现丢大量的日志分析是可以完全精准分析的，这个是个不错的实测功能；

```js
根据你提供的日志，`com.xiaopeng.remotecalibration` 应用崩溃的根本原因是 **内存溢出 (Out of Memory - OOM)**，具体表现为 **Native 层（C/C++层）内存耗尽**。

以下是详细的分析：

### 1. 崩溃的核心原因
**错误类型：** `java.lang.OutOfMemoryError`
**具体错误信息：**
```
Throwing OutOfMemoryError "Could not allocate JNI Env: Failed anonymous mmap(0x0, 8192, 0x3, 0x22, -1, 0): Out of memory. See process maps in the log." (VmSize 17019908 kB)
```
**解释：**
*   应用试图创建一个新的线程（或 JNI 环境），需要申请内存映射，但系统内存已经耗尽，无法分配。
*   日志显示进程的 **VmSize（虚拟内存占用）达到了惊人的 ~17GB (17019908 kB)**，这对于一个安卓应用来说是极不正常的，说明发生了严重的内存泄漏或内存滥用。

### 2. 异常发生的迹象（崩溃前兆）

在崩溃发生前几秒，日志中已经出现了大量的内存分配失败警告：

*   **Scudo 内存分配器报警 (15:56:12):**
    `Scudo OOM: The process has exhausted 256M for size class 33296.`
    `Stats: SizeClassAllocator64: 821M mapped`
    *   这意味着 Native 层的内存分配器检测到内存正在被疯狂消耗，从 500MB 迅速飙升至 800MB+ 并持续增长。

*   **Malloc 失败刷屏 (15:56:18):**
    `libc: malloc(32768) failed: returning null pointer`
    *   系统底层 `libc` 库在尝试分配 32KB (`32768` bytes) 的内存块时连续失败。这通常是因为没有连续的内存空间可用了。

### 3. 罪魁祸首推断

根据日志上下文，问题出在 **JNI 层对 XCP 数据的处理** 上：

1.  **高频数据接收：**
    日志中充满了 `AKLib_Jni: Received buffer: ...`。这表明应用正在通过 JNI 从底层（可能是车辆总线）接收大量的高频二进制数据。

2.  **XML 写入操作：**
    在 `15:56:10.883` 附近，日志显示 `AKLib_Jni: XML数据写入100ms数据名称...`。应用似乎在尝试将大量的信号数据写入 XML 文件。

3.  **可能的泄漏点：**
    *   **缓冲区未释放：** JNI 层接收到的 `buffer` 可能没有被及时释放 (Release)，导致堆积。
    *   **XML 构建过大：** 如果是在内存中构建一个巨大的 XML 字符串/对象然后再写入文件，会瞬间消耗巨大内存。
    *   **线程池积压：** 错误堆栈显示 `ThreadPoolExecutor`。如果数据处理速度慢于接收速度，任务队列会无限膨胀，最终撑爆内存。

### 总结

*   **崩溃原因：** **Native OOM (内存溢出)**。
*   **触发点：** `AKLib_Jni` 库在处理 XCP 协议数据接收和 XML 写入时，消耗了所有的可用内存（虚拟内存飙升至 17GB）。
*   **解决建议：**
    1.  检查 `AKLib_Jni` 的 C++ 代码，确保 `malloc/new` 分配的内存在使用后被 `free/delete`。
    2.  检查 JNI 传递数据给 Java 层时，`NewByteArray` 等引用是否被及时释放。
    3.  避免在内存中构建完整的超大 XML，改用流式写入 (Stream Writer)。
    4.  限制数据接收缓冲区的大小或频率。
```

# 参考提问

```js
对比结果页，筛选增加标定量筛选，放置于标定量类型左侧
http://localhost:8086/#/calibration-data/comparison/same-project
```


```js
标定量编辑入口，开放关键标定量 备注字段，供用户编辑，其余的只读不能改
```


```js
标定管理页面，页面调整。
要求：可对标定量进行备注说明，并且进行筛选，包括是否需要进行标定等
其中， 备注取           "remark": "",
```


```js
可视化对比按钮，请基于当前标定量的current_value做曲线对比，如果是单值，则点对比，依次类比。
@same-project 
```


```js
新增了一个专门的对比接口，返回速度快、字段精简，方便前端按 data_file 等条件拉取差异列表：
GET /calibracloud/cdm/api/v1.0/hex/compare：沿用 Hex 视图集的过滤器（data_file、hex_file、a2l_file、characteristic_type、characteristic_name 等都可用），只返回 characteristic_name、characteristic_type、current_value 三个字段，VALUE 类型仍自动去掉外层列表。
实现细节：apps/cdm/rest/serializers/hex.py 新增 HexCompareSerializer 继承现有序列化逻辑；apps/cdm/rest/viewsets/hex.py 新增 compare action，复用原过滤和分页能力。
现在前端用你给的 cURL 只需把路径换成 /hex/compare?...，就会得到更小的响应体，data_file=27/28 过滤也已生效。如需比对两组数据，可分别请求两个 data_file，拿返回的 JSON 直接做对比即可。

原接口：Request URL
http://localhost:8086/calibracloud/cdm/api/v1.0/hex?user_fields=owner&a2l_file=12&page_size=10000&data_file=27
Request Method
GET
按照以上接口调整，加快访问速度

```


```js
@src 当前已经获取到characteristic hex相关的所有信息，
需要实现一个参数对比的能力，包含：
1、可从存储的软件中，提取同项目A2L，多个不同hex之间的参数对比，识别参数一致及不一致情况，并且参数具有可视性；
2、可从存储的软件中，提取不同项目A2L，多个不同hex之间的参数对比，识别参数新增、删减、同命名信号参数的一致及不一致情况，并且参数具有可视性
同时，标定量对比功能里，可以根据标定量的类型：单值、二维表、三维表等进行筛选区分，便于进行查看标定量。
可以对于标定量进行检测，对于MAP的凸点位置或者不符合趋势的标定量进行检测和提醒。
当然 1 2可以分开不同的页面，麻烦参考以上
```


```js
参考ADB官网，要求写一个培训文档，面向对象是没有这块知识经验的人，文档需要包含背景、ADB架构、通讯逻辑、流程图、ADB常见命令（root/devices/push/pull等使用），请编写
```


```js
经查，已知数据库存在MAP类似对应的X Y坐标，估计是由于原来标定量或观测量等的判重逻辑变化，导致hex解析到对应MAP无法查到对应的坐标轴值，请参考model类及入库逻辑调整MAP类型的解析逻辑
```


```js
新接口：compare_cross_a2l
路径： GET /calibracloud/cdm/api/v1.0/hex/compare_cross_a2l
查询参数：
data_file（必需）：HEX 数据文件 ID，支持多个，用逗号分隔，如 "1,2,3"
characteristic_names（可选）：要对比的标定量名称列表，用逗号分隔，如 "CtrlACC_mV_11kwTurnU_C,OtherChar"
page_size（可选）：分页大小
返回格式：
{  "count": 100,  "next": null,  "previous": null,  "results": [    {      "characteristic_name": "CtrlACC_mV_11kwTurnU_C",      "characteristic_type": "VALUE",      "long_identifier": "剩余充电时间T4计算：11kw充电拐点电压",      "hex_values": {        "1": 123.45,  // data_file_id: value        "2": 234.56      },      "a2l_info": {        "1": {"a2l_file_id": 3, "a2l_file_name": "xxx.a2l"},        "2": {"a2l_file_id": 4, "a2l_file_name": "yyy.a2l"}      },      "a2l_files": [3, 4]  // 该标定量在哪些 A2L 中存在    }  ]}
主要特性
支持跨 A2L 对比：不要求所有 data_file 关联到同一个 A2L
基于名称匹配：按标定量名称匹配，而非 ID
性能优化：指定标定量名称时只查询相关 HEX 数据
数据验证：验证 data_file 存在性和 A2L 关联性
值规范化：自动处理 VALUE 类型的列表值
分页支持：支持分页查询
使用示例
# 对比所有匹配的标定量curl 'http://localhost:8086/calibracloud/cdm/api/v1.0/hex/compare_cross_a2l?data_file=1,2'# 对比指定的标定量curl 'http://localhost:8086/calibracloud/cdm/api/v1.0/hex/compare_cross_a2l?data_file=1,2&characteristic_names=CtrlACC_mV_11kwTurnU_C,OtherChar'
函数已实现，可直接使用。
跨A2L对比时，请参考以上后端接口调整调用，请调整
```


```js
@xcp信号测试.xls @test1201_shanchuHT(1).cfg 
其中xls xlsx都支持，默认其开头行顺序及内容固定为：
名称	角色	10msRStr	100msRStr	Polling_100ms	Polling_500ms	Polling_1s
其中Excel中内容对应为：
名称	                  角色	10msRStr	100msRStr	Polling_100ms	Polling_500ms	Polling_1s
TQR_bar_BrkPresReq		       X
TQR_bar_MasterCylPres		   X
TQR_barps_BrkPresRampReq	   X
中X代表选中对应10msRStr或后续100msRStr等字段，
上面是固定格式，下面部分，前面信号为观测量，后面x表示10ms或者100ms（最后三列不用管）
要求其转换为cfg格式，参考选中的cfg文件，格式参考：
@test1201_shanchuHT(1).cfg (1-10) 
0表示10ms周期，1表示100ms周期
其中前三行+空行是固定格式，请写一个工具类来实现以上需求。
即，要求输入Excel，输出cfg文件，其中Excel支持xls xlsx
同时，
要求转换前打印信号数，并打印转换成功后的信号数，再加个判断，用来证明转换过程中没有丢失信号
要求加一个if __main__供测试，就用当前目录下的
@xcp信号测试.xls 
```

cursor提效tips

# 理解
临时把当前修改藏起来，恢复工作区干净，以便切分支或拉代码

# 深度理解
stash 会保存什么？

默认会保存：
✅ 工作区已修改但未提交的文件
✅ 暂存区里的文件（git add 过的）

不会保存：
❌ 未被 git 追踪的新文件（除非用特殊参数）

# 高频命令操作

1. 查看所有 stash 内容

```js
git stash list
```

你会看到类似：

```js
stash@{0}: WIP on develop: 1234567 修复接口
stash@{1}: WIP on master: UI调整
```


✅ 2. 恢复（取出并删除 stash）

把最新的 stash 应用到当前分支：

```js
git stash pop
```


应用并删除 stash@{0}

如果有冲突，解决后再 git add + git commit

✅ 3. 恢复但不删除 stash（保险一点）

```js
git stash apply
```
应用 stash

stash 记录仍保留（更安全）

✅ 4. 恢复指定 stash

例如恢复第 1 个：

```js
git stash apply stash@{1}
```

若要恢复并删除：

```js
git stash pop stash@{1}
```



git stash

# 背景
我从remote_calibration分支合并到develop分支时，提示： 

```js
Merge request cherry-pick failed: Can't perform this action automatically. It may have already been done, or a more recent commit may have updated some of this content. Please perform this action locally.
```
# 理解
意思是：GitLab 在尝试把 remote_calibration 分支的变更自动合并（或 cherry-pick）到 develop 分支时失败了，需要你在本地手动处理冲突。这种情况通常发生在：

✅ 同一段代码被两个分支改动了

✅ 分支之间有冲突文件

✅ 已经有人做过部分 cherry-pick/merge

✅ GitLab 无法自动确认冲突如何解决

# 解决
直接cursor处理

更新分支：

```js
git checkout develop && git pull
git checkout remote_calibration && git pull
```

本地尝试合并：

```js
git checkout develop
git merge remote_calibration
```

用 git status 查看具体冲突

打开冲突文件并手动解决

会提示是否直接界面解决，同意后，界面合并即可，然后提交

合并完成后：
基于develop创建新分支然后合并到develop即可

git add .
git commit
git push origin develop




代码冲突解决

# 背景
由于celery最小只能到分钟级别，但是日常有需要每隔10秒同步一遍获取远程系统能力

# 实现

```python3
""" Auto reload celery runner script
Usage: python manage.py sync_perms
See: https://stackoverflow.com/a/49166246/2544762
"""
import signal
import traceback
from datetime import datetime
from logging import getLogger
from time import sleep
from typing import Dict

from django.apps import apps
from django.conf import settings
from django.core.management.base import BaseCommand

from mobile.tasks import job_watch_sonic_devices

logger = getLogger(__name__)


class Command(BaseCommand):
    def handle(self, *args, **options):
        # 退出标记
        flag_terminate = False

        # 退出信号处理（Ctrl + C），使得可以正常结束不用 kill
        def signal_handler(signal, frame):
            nonlocal flag_terminate
            flag_terminate = True

        signal.signal(signal.SIGINT, signal_handler)
        signal.signal(signal.SIGTERM, signal_handler)

        # 死循环轮询定时任务
        while not flag_terminate:
            logger.info(f'定时任务开始执行：{datetime.now().strftime("%Y-%m-%d %H:%M:%S")}')
            try:
                job_watch_sonic_devices()
            except Exception as e:
                print(f'watch sonic e: {e}')
                traceback.print_exception(e)
            # 整体执行时间需要2秒，这里设置8秒，基本10秒内一个轮回
            sleep(8)

```
## 1、信号处理

```python3
signal.signal(signal.SIGINT, signal_handler)
signal.signal(signal.SIGTERM, signal_handler)
```
捕获 Ctrl + C (SIGINT) 和 终止信号 (SIGTERM)。

使用 nonlocal flag_terminate 让信号处理函数能修改外部变量，确保可以优雅退出循环，而不是被强制 kill。

优点：

运行中按 Ctrl+C 可以安全结束（会在下个循环退出）。

避免直接 kill -9 导致状态不一致。


```python3
flag_terminate = False

def signal_handler(signal, frame):
    nonlocal flag_terminate
    flag_terminate = True

```
### 底层流程（信号机制是怎么帮忙的）：
当用户 Ctrl+C（SIGINT）或 kill（SIGTERM）时，不是立刻杀掉进程，而是执行 signal_handler：

把 flag_terminate 设成 True。

主循环每轮都会检查 flag_terminate：

如果 True，退出循环，任务结束前可以优雅清理（比如保存状态、断开连接）。

这样：

正在执行的那一轮任务会先跑完。

然后在下一轮循环检查到退出标志，再干净地退出。

### 简单理解：

信号处理就是给死循环任务加了一个“安全刹车”，让你按下 Ctrl+C 时，不是直接翻车，而是慢慢停下来。

### 是否同步？
如果只看 Python 解释器层面，当收到信号时，信号处理函数（signal_handler）的执行是同步的。

解释器会在执行字节码的“安全点”检测是否有挂起的信号：

如果有，就暂停当前的 Python 代码执行；

同步调用你注册的 signal.signal(...) 处理函数；

处理函数执行完后，回到原来的位置继续执行

## 2、技术要点总结

- 自定义 Django 管理命令：可直接用 python manage.py <command> 启动，不依赖外部调度器。
- 信号安全退出：通过 signal.signal + 外部变量标志实现优雅退出。
- 异常隔离：任务出错不会中断整个进程。
- 简单定时调度：用 sleep() 模拟固定周期调度（适合简单场景，不适合精确到秒的生产任务）。
- 日志追踪：方便监控执行情况。
- 可替代 Celery beat：适合轻量任务或测试环境，但在高并发/分布式场景下不如 Celery 稳定