IT瘾工具推荐

用Qwen 3.6 35B本地模型作为主力编程工具替代Claude或GPT

Wed, 17 Jun 2026 08:59:06 CST

基于 Hacker News 上的这个热门讨论（关于是否有人在日常编程中用本地大模型完全替代 Claude/GPT），以下为您归纳出的几条 本地大模型最佳实践以及该讨论的 主要内容概述。

一、本地大模型（Local LLM）编程的 5 条最佳实践

选择最适配的混合架构模型（如 Qwen 3.6 35B） 讨论中多位资深用户指出， Qwen 3.6 35B（激活 3B 参数的混合专家模型 MoE） 是目前本地编程的“黄金甜点位（Sweet Spot）”。它在 128GB 或 36GB RAM 的设备（如 Mac Studio、Strix Halo 笔记本）上运行极快，且代码能力表现优异。对于更复杂的任务，可配合 Qwen 3.5 122B（激活 10B）作为后备。
启用“保持思考”配置（Preserve Thinking）以优化缓存 在使用推理/思考模型（如带有 <think> 标签的模型）进行多轮对话或 Agent 自动化编程时，默认的模板可能会在下一轮对话中丢弃之前的思考链（CoT），导致每一轮都要重新计算完整的 KV 缓存（Context Reprocessing）。 最佳实践是在大模型后端（如 llama.cpp）中开启 preserve_thinking: true，这能大幅提升多轮对话中的缓存命中率，避免卡顿。
使用 Vulkan 后端提升 AMD/Intel 硬件性能 在特定硬件（如 AMD Strix Halo 笔记本）上运行 llama.cpp 时，部分用户反馈 使用 Vulkan 后端甚至比官方的 ROCm 还要快且更稳定。硬件平台的后端选择（Vulkan vs ROCm/Metal）应根据实际本地测试来决定。
精确提示与迭代开发（Iterative Development），不当“甩手掌柜” 本地模型（如 Qwen 3.6 35B）相比于闭源的顶尖模型（如 Claude 3.5 Sonnet / Opus），更像是一个 需要密切指导的“初级程序员（Junior）”。最佳实践是 不要指望它一次性生成成千上万行代码，而是采用“讨论设计方案 -> 达成共识 -> 迭代编写单个功能 -> 运行测试”的循环模式，且提示词必须极其精确、消除歧义，否则模型会为了偷懒选择最糟糕的架构（例如直接在 HTML 里塞满 CSS）。
量化（Quantization）和容器化沙箱（Sandboxing）安全
- 安全： 配合 Agent 框架（如 Pi 编程脚手架）时，务必将本地模型和执行环境 容器化（Docker）并进行沙箱隔离，限制其仅能访问当前工作目录，防止断网环境下本地脚本误操作或泄露敏感凭证。
- 量化： 不要盲目相信社区的激进量化。量化对代码质量影响极大（MoE 架构对量化的耐受度稍好），建议在可能的情况下优先选用更高精度的版本（如 FP8 等）。

二、帖子主要内容概述

这个帖子（Ask HN）的核心议题是： “有没有人真正把本地模型作为主力编程工具，完全替代了 Claude 或 GPT？” 评论区的技术人员对此展开了深度讨论，主要内容可概括为以下几点：

完全替代的可能性与实际体验： 多数硬核开发者表示 完全可以替代，尤其是在注重 隐私、离线开发和完全免费的场景下。有用户分享了他们纯靠本地模型（Qwen3.6 35b + Pi 框架）重构整个 Django+Wagtail 网站主页和博客的成功经历。
本地模型 vs 闭源大模型的差距： 用户普遍认为，Claude Opus 或 Sonnet 就像一个能帮你思考架构的“高级工程师（Senior）”，能带来 15 倍的效率提升；而本地模型则是一个需要你时刻盯着的“初级工程师”，能带来约 5 倍的效率提升。虽然本地模型更容易陷入逻辑死循环或在调用编辑工具时出错，但考虑到它 完全免费且纯离线，这种表现已经令人惊叹。
技术层面的深究（KV缓存与Attention机制）： 讨论中有很大一部分篇幅在硬核切磋本地运行的底层 Bug。大家深入探讨了为什么模型在多轮对话中会频繁触发“重新处理上下文（Re-processing context）”。多位开发者指出这通常是由于 Prompt 模板不一致、系统提示词每轮被修改（Harness Bug）或没有保存思考链导致的，并给出了具体的 Jinja 模板修改方案和命令行参数。
人机协作哲学的思辨： 开发者们辩论了“AI编程是否会导致代码质量退化”。主流观点认为，AI 不是为了让人变懒去生成一堆垃圾代码（Vibe Coding），而是作为“自动化 Google”和实时常驻的专家。高水平的开发者可以通过与本地 AI 讨论、审查其方案并编写大量测试，实现“控制权在人，生产力乘数在 AI”的高质量开发。

如何使用NLEmbedding + Gemma4构建一个知识管理和检索友好的系统工具

Fri, 17 Apr 2026 14:15:33 CST

结合 NLEmbedding 与 Gemma 4 构建知识管理系统，核心是发挥两者的互补优势：NLEmbedding 负责将知识转化为可检索的向量索引（“记忆系统”），Gemma 4 负责基于检索结果生成高质量回答（“认知大脑”）。

🏗️ 系统架构核心设计

下图展示了推荐的系统架构：

图表

代码

下载

全屏

查询阶段

构建阶段

企业知识文档
PDF/Word/网页

文档切片
语义分块

NLEmbedding
向量化

向量数据库
存储索引

用户提问

NLEmbedding
向量化

相似度检索
召回Top-K相关片段

构建Prompt
上下文+问题

Gemma 4
生成回答

🧠 第一步：NLEmbedding——构建记忆检索层

NLEmbedding 的核心任务是将文档片段转化为高维向量，本质是建立语义空间索引。实际使用时需重点规划以下策略：

策略维度	推荐方案	核心理由
模型选择	中文场景推荐 `text2vec-large-chinese` 或 BGE 系列；多语言/英文推荐 `nomic-embed-text`。这些模型开源友好，支持本地部署 -9 -8。	兼顾隐私、成本和定制化需求，避免依赖外部API。
文档分块	语义分块优于固定长度切分。例如，按段落、Markdown标题或代码块边界切分，并使用 `RecursiveCharacterTextSplitter` 保留重叠区域。	防止表格、代码等被截断破坏语义，保证检索完整性 -2。
向量数据库	生产环境推荐 PgVector (PostgreSQL扩展) 或 Milvus；轻量级原型可使用 Chroma 或 FAISS -2 -8。	PgVector可复用现有PG库，降低运维成本，支持混合检索 -2。
检索策略	采用混合检索：向量相似度 + BM25关键词检索，通过RRF(Reciprocal Rank Fusion)算法融合结果。	解决纯向量检索可能漏掉精确关键词（如产品型号、编号）的问题 -2 -9。

🚀 第二步：Gemma 4——搭建生成与交互层

Gemma 4 凭借其256K超长上下文和函数调用能力，非常契合知识管理场景 -2 -6。部署时需注意：

部署方案：轻量场景（测试、个人）可直接通过 Ollama 一键运行 gemma4:4b 或 gemma4:26b-a4b 版本 -4 -9。企业级高并发场景建议使用 vLLM 框架，或通过兼容OpenAI协议的API服务调用 -6。
上下文利用：Gemma 4 的长上下文能力允许在Prompt中注入更多检索到的相关片段，减少关键信息遗漏 -7。
函数调用：可实现让模型主动查询数据库或调用内部API的智能体（Agent）行为 -2 -7。

🔗 第三步：RAG流程串联与代码示例

系统运行的完整逻辑是：查 → 拼 → 生。下面以用户提问“公司年假几天？”为例，演示核心代码逻辑：

python

复制

下载

from openai import OpenAI  # 假设使用OpenAI兼容接口
import numpy as np
from your_vector_db import VectorStore  # 假设的向量数据库客户端

client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

# 1. 检索：将用户问题向量化，从DB召回Top-K相关文档
def retrieve_context(query, top_k=5):
    query_embedding = get_nlembedding(query) # 使用你的NLEmbedding模型
    results = vector_db.similarity_search(query_embedding, k=top_k)
    return [doc.text for doc in results]

# 2. 生成：构建包含上下文的Prompt，调用Gemma 4
def ask_knowledge_base(question):
    context_chunks = retrieve_context(question)
    context_str = "\n\n---\n\n".join(context_chunks)
    
    # 精心设计的Prompt，引导模型基于上下文回答
    prompt = f"""你是一个专业的知识库助手。请严格根据下面“文档上下文”中的信息回答用户问题。
如果上下文中没有相关信息，请明确回答“根据现有知识库无法回答该问题”，不要编造信息。

<文档上下文>
{context_str}
</文档上下文>

用户问题：{question}
回答："""

    response = client.chat.completions.create(
        model="gemma4:26b-a4b-it", # 或其他 Gemma 4 模型标签
        messages=[{"role": "user", "content": prompt}],
        temperature=0.1 # 降低随机性，提高事实性
    )
    return response.choices[0].message.content

注意：代码中的 get_nlembedding 和 vector_db 需根据你实际选择的嵌入模型和向量数据库进行具体实现。

🔧 第四步：优化与进阶策略

要让系统更稳定可靠，建议加入以下机制：

多级检索架构：先使用一个极轻量的Gemma模型（如E4B版本）对用户意图进行分类（如“售后问题”、“产品咨询”），然后再在对应的小范围知识库中进行向量检索。这样可以有效降低大模型的“幻觉”并提高准确率 -9。
降级与容错：在生产环境中设置熔断机制。例如，当向量检索结果相似度普遍低于阈值（如0.7）时，可触发降级策略，转而调用Gemma 4的通用知识进行回答，并添加免责声明 -2。
精排优化：在向量检索初步召回后，增加一个 Reranker（重排序）模型对结果进行二次精排，将最相关的片段排到最前，能显著提升Gemma 4的生成质量。

💎 总结：技术选型速览

环节	推荐选择	备选/说明
Embedding模型	`nomic-embed-text`, `text2vec-large-chinese`	运行于Ollama或本地Transformers -9 -8
向量数据库	PgVector, Milvus	轻量级可选Chroma -2
大语言模型	Gemma 4 (4B/26B-A4B/31B)	根据硬件配置和性能要求选择 -2 -6
编排层	Spring AI, LangChain, LlamaIndex	Java技术栈首选Spring AI -2
部署工具	Ollama, vLLM, Docker	本地测试用Ollama，生产推荐vLLM

游戏开发团队测试500款AI工具仅6款具备实用价值

Sat, 11 Apr 2026 18:54:00 CST

尽管如今许多游戏工作室已开始在开发流程中使用AI工具，但其中绝大多数工具的实用价值都远远不够。这一观点来自游戏行业领先的技术与创意解决方案提供商Keywords Studios的转型负责人乔恩·吉布森。

Keywords Studios总部位于爱尔兰，成立于1998年，曾为《沙丘：觉醒》《漫威争锋》《深渊呼唤》《心灵杀手重制版》《死亡岛2》《漫威银河护卫队》等众多知名作品提供技术与开发支持。

吉布森在接受专访时表示，Keywords团队针对500多款游戏开发AI工具的适用性进行了测试，其中仅有约6款具备真正的实用价值。

“市面上充斥着大量华而不实的产品，”吉布森说，“Keywords内部开展了大量研发工作，我们在多个研发项目中测试了约500款不同的AI工具，最终认为仅有约6款能够以合理的方式，真正为开发工作提供助力。”

他解释称，就目前的行业现状而言，绝大多数AI工具的开发逻辑，都是围绕“工具能实现什么功能”展开，而非“能真正解决游戏开发中的哪些具体问题”。这最终导致这些工具或许能实现一些“看起来很酷”的效果，却毫无实际应用价值。

“目前的AI技术，正处于野蛮生长的混乱阶段，我们需要推动它进入真正可落地应用的阶段。”他进一步解释道，“我们该如何在实际的生产环境中应用AI?如何让AI成为开发团队的助力，而非潜在的威胁?同时，我们该如何在规范的框架内使用AI，确保它处于可控状态，保障知识产权安全、法律合规，以及伦理与道德层面的正当性?”

“那些输入一段提示词就能生成惊艳效果的炫酷AI演示，和实际生产环境中由人工把控方向、输出稳定且高质量成果的AI应用，两者之间存在着巨大的鸿沟，想要跨越绝非易事。”

他补充道：“很多人只关注什么东西看起来炫酷，把注意力放在工具或模型本身，而非自己真正想要实现的目标。有些公司会在没有明确应用场景的情况下，就去使用甚至开发一款工具，然后硬把它塞进现有的生产管线里。而正确的逻辑本该是反过来的：先明确‘我们的痛点是什么，我们想要解决什么问题’，再针对性地开发工具。”

吉布森还提到，在游戏开发者大会（GDC）最新发布的行业现状报告中，受访的开发者里有90%表示已在开发中使用AI，但同时有52%的人并不认可AI的应用。

“90%的人都在用AI，却有52%的人认为这是件坏事。”他总结道，“这中间显然存在严重的断层。我认为，对AI的应用缺乏管控与规范体系，是造成这一问题的核心原因之一。很多公司根本没有向员工真正解释清楚，他们为什么要用AI、AI的价值在哪里、相关的战略规划是什么。在没有明确这些核心问题的情况下，就贸然启用AI模型，这自然会让开发者感到担忧。”

gstack：YC总裁开源的”AI软件工厂”，68k Star的工具到底香不香？

Thu, 09 Apr 2026 22:41:07 CST

第一次看到这个项目的时候，我愣了几秒。

Garry Tan——Y Combinator的总裁，全球最顶级孵化器的掌舵人——居然把自己每天用的Claude Code配置开源了？而且还专门强调这是他” opinionated tools”，意思是一套带强烈个人偏好的工具链？68k star、9.4k fork，这个数字在GitHub上是什么概念我就不用说了吧。

更让我好奇的是：他声称用这套东西，60天写了60万行生产代码。一个人的效率，真的能顶一个20人团队？

我花了几天时间认真研究了一下，今天来聊聊gstack到底是个什么东西。

一、gstack是什么？

简单说，gstack是一套开源的AI软件工厂工具，把Claude Code变成了一个虚拟工程团队。

Garry Tan把它描述为”23个专业角色+8个强大工具”，每个角色各司其职：CEO帮你做战略审查、Designer帮你做设计系统、Eng Manager帮你做架构评审、QA帮你做浏览器测试……你一个人坐在那里，AI们在背后协作。

核心技术栈是TypeScript（71.2%）+ Go Template（18.9%），依赖Bun v1.0+或Node.js运行，用Playwright做浏览器自动化，支持macOS和Windows（通过WSL/Git Bash）。

二、数据情况

指标	数据
Star数	68k
Fork数	9.4k
Watchers	379
许可证	MIT

数据来源：GitHub公开数据

这个量级的star说明什么？要么是真的好用，要么是Garry Tan的名字太响。从我了解到的社区反馈来看，两方面原因都有。Garry本人说他在60天内用这套工具写了60万行生产代码，35%的代码是测试代码——这个比例在行业内算是相当高的质量追求了。

三、核心功能有哪些？

gstack的功能分成四个阶段：

规划阶段

/office-hours：产品定义和需求分析，AI会追问你的具体痛点
/plan-ceo-review：CEO级别的战略审查，挑战你的产品方向
/plan-eng-review：工程架构审查，设计数据流和技术方案
/plan-design-review：设计审查，确保设计符合工程可行性

构建阶段

/design-consultation：构建完整设计系统
/design-shotgun：AI原型设计探索，快速出多个方案
/design-html：生成生产级HTML/CSS

测试阶段

/review：代码审查和自动修复
/qa：真实浏览器测试（用的是Playwright，防机器人检测）
/cso：安全审计（OWASP Top 10 + STRIDE模型）

发布阶段

/ship：发布管理
/land-and-deploy：生产部署验证
/canary：部署后监控

光看功能列表可能觉得有点虚，我举个例子：你在Claude Code里说”我想做个日历应用”，然后这套工具会依次跑：产品需求分析→CEO战略审查→工程架构评审→设计系统构建→编写代码（2400行约8分钟）→代码审查修复→真实浏览器QA→创建PR。全流程自动化。

四、面向的人群有哪些？

用户类型	适用场景
独立开发者	一个人搞定全栈产品
小团队（2-5人）	提升工程质量和发布效率
初创公司	减少人力成本，加速MVP迭代
大公司内部工具	为AI编码代理提供标准化流程

说实话，这套工具对个人开发者和小团队最有价值。如果你本身就在一个大公司、有完整的工程团队，这套东西可能没那么必要——你们的流程本来就有专人负责。但对于”全栈独立开发者”或者小团队，这就是效率放大器。

五、应用场景有哪些？

场景1：快速原型验证

有个点子想快速验证？用office-hours+design-shotgun，AI帮你快速出产品方案和原型，不用先招人。

场景2：代码质量把关

写了代码担心有问题？/review自动修复+/qa真实浏览器测试，这俩组合基本能覆盖大部分常见bug。

场景3：安全审计

发布前想做个安全检查？/cso基于OWASP Top 10 + STRIDE模型，比大多数创业公司自己做的安全审查专业多了。

场景4：持续部署

接入了CI/CD但每次发布还是提心吊胆？/land-and-deploy+/canary帮你做部署验证和上线后监控。

六、和同类竞品的差异有哪些？

gstack本质上是一套Claude Code的技能包，和普通的AI编码代理相比，核心差异在于：

对比项	普通AI编码代理	gstack
角色分工	单代理啥都干	23个专业角色各司其职
代码审查	基础lint	CEO/工程架构级别审查
测试	简单单元测试	真实浏览器QA+安全审计
发布流程	手动操作	自动化发布+监控
适用规模	个人辅助	可支撑团队协作

但要注意，gstack主要是给Claude Code用户用的。不过它也支持其他AI编码代理：OpenAI Codex CLI、Cursor、Factory Droid等8种，算是有一定的跨平台能力。

七、使用技巧

技巧1：先用office-hours明确定义产品

很多人直接让AI写代码，结果写了一半发现方向不对。在开始写代码之前先用/office-hours让AI追问你的需求，这个前置动作能省很多返工时间。

技巧2：并行sprint不是噱头

Garry Tan说支持10-15个并行sprint，这不是吹的。你可以让规划、设计、测试同时跑，对于有明确里程碑的项目确实能大幅压缩周期。

技巧3：review之前先确认代码规范

gstack的代码审查很强，但如果你有自己的代码规范文档，最好先提供给AI。不然它会按自己的风格来，可能会和你现有代码风格有出入。

技巧4：团队模式要用对

gstack有团队模式（–team参数），适合多人协作场景。但如果你是个人开发者，用默认模式就够了，别把简单事情搞复杂。

八、对企业和个人的价值

价值维度	个人开发者	企业用户
效率提升	1人顶N人	降低人力成本
质量保障	自动审查+测试	标准化工程流程
知识沉淀	学习Garry的工程思维	沉淀为团队工具链
风险控制	自动化减少人为失误	安全审计前置

说实话，gstack对我最有吸引力的不是那些花哨功能，而是Garry Tan这个人本身——他是YC总裁，每天看几千个项目，什么样的工程实践是好实践，他比大多数人都清楚。这套工具反映的是他的工程哲学，花68k star去围观这个人的工作方式，本身就值回票价。

九、产品定价

版本	价格	说明
开源版	免费	MIT许可证，全部功能开源
商业使用	需遵守MIT	无额外限制

gstack是100%开源项目，MIT许可证，基本没什么使用限制。如果你公司在用Claude Code，直接部署就行，不用额外付费。

十、项目地址

GitHub仓库：https://github.com/garrytan/gstack

快速安装（在Claude Code中运行）：

  
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

团队模式安装：

  
cd ~/.claude/skills/gstack && ./setup --team
cd <your-repo>
~/.claude/skills/gstack/bin/gstack-team-init required

总体评价

gstack让我想起一句话：牛人不可怕，可怕的是牛人还比你努力。Garry Tan作为YC总裁，妥妥的人生赢家，结果他把压箱底的工具配置开源了，还附赠60万行代码的生产记录。这种量级的分享，在圈子里确实不多见。

从工具本身来说，23个专业角色覆盖了产品、设计、工程、测试、发布的完整流程，对于个人开发者和小团队来说确实能大幅提升效率。真实浏览器QA和安全审计这两个功能，在同类型工具里算是比较少见的。

但也要说，这套东西不是银弹。它最适合的场景是：你想快速验证产品方向、需要高质量代码输出、但团队人又不多。如果你本身就有完整的工程团队，这套东西能提供的增量价值有限。

另外，它强依赖Claude Code，如果你是Cursor或其他工具的重度用户，迁移成本不低。

亚马逊因 AI 编码工具引发多起故障

Wed, 11 Mar 2026 08:03:54 CST

亚马逊因 AI 编码工具引发多起故障，紧急召开工程师大会

亚马逊电商部门本周二召集大批工程师开会，对近期一连串系统故障进行"深度复盘"——其中多起事故与 AI 编码工具直接相关。

据英国《金融时报》看到的内部备忘录，亚马逊近几个月出现了"事故趋势"，特征包括"高爆炸半径"（即波及面广）以及"生成式 AI 辅助的代码变更"。备忘录明确将"尚未建立完善最佳实践和安全防护的新型 GenAI 用法"列为事故的诱因之一。

具体来说，亚马逊网站和购物 App 本月曾宕机近 6 小时，用户无法完成交易、查看账户和价格。另外，AWS 旗下的 Kiro AI 编码工具在去年 12 月造成了一次长达 13 小时的服务中断——起因是工程师让 AI 工具执行某些变更，结果 AI 自行决定"删除并重建整个环境"。

作为应对，亚马逊已要求初级和中级工程师在提交任何 AI 辅助的代码变更前，必须获得资深工程师的签字批准。

值得注意的是，这些故障发生的背景是亚马逊近年来的多轮裁员——今年 1 月刚裁掉 1.6 万个企业岗位。此前已有多名工程师向《金融时报》反映，裁员导致每天需要紧急处理的高优先级事故（内部称"Sev2"）数量明显增加，但亚马逊否认裁员与故障频发有关。

这可能是整个行业的一个预警信号：当企业大规模推广 AI 编码工具、同时又在削减人手时，代码质量和系统稳定性的风险正在累积。

来源：www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de

NotebookLM：我目前最常用、也最愿意推荐的 AI 学习与内容组织工具

Mon, 17 Nov 2025 16:44:45 CST

NotebookLM 是我迄今用过最贴合知识工作者需求的 AI 工具，它真正帮我把庞杂信息结构化，极大提升了学习和内容创作效率。

作为一个长期学习主义者、读技术规范、研究开源项目的人，我一直在寻找一种工具，能在我面对海量资料时替我“抄近道”、减少机械性阅读、帮我快速建立全局理解。 NotebookLM 是过去一年里我用下来体验最顺滑、也最稳定可靠的一个。

它不是传统意义上的“聊天式 AI 工具”，更像是一个能把你的资料吃进去、组织出来、再以各种结构化方式呈现给你的 AI 原生学习与内容组织系统。越用越觉得，它对我学习新技术、理解陌生领域、整理大项目文档、构建教学材料的帮助，是其他通用大语言模型（LLM, Large Language Model）给不了的。

NotebookLM 给我带来的核心价值

NotebookLM 在实际使用中为我带来了多方面的提升，尤其是在学习新技术、整理文档和内容创作方面表现突出。

快速理解陌生技术：把庞杂资料丢进去，它帮我生成“可学的版本”

我最常用、也是最离不开的场景，就是 学习一个我完全不熟悉的技术或开发框架。面对几十页甚至几百页的文档，我通常的做法是：

把官方文档、README、设计文档、架构草图全部加入一个 Notebook
让 NotebookLM 帮我生成：
- 学习指南
- 简报
- 关键知识点
- FAQ
- Quiz
最终得到一个结构清晰的“学习入口”，而不是一场资料洪水。

下面这张流程图展示了 NotebookLM 如何将复杂文档压缩为可学习的结构：

图 1: NotebookLM 文档结构化流程

最终我获得的是一个“整理好的知识体系”，而不是一堆等我啃的 PDF。

生成 MindMap：大量文档瞬间变成结构化知识图谱

我很依赖 MindMap 来构建“知识的骨架”。NotebookLM 的 MindMap 最大的优势有：

自动识别主题间的关联
可以交互式展开或折叠节点
支持多来源文档综合生成

虽然目前只能导出 PNG，但逻辑结构本身已经是非常好的“知识压缩”。

下表对比了不同工具的自动生成能力和可视化效果：

工具	自动生成能力	多文档整合	可视化质量	导出格式
NotebookLM	强	强	好	仅 PNG（暂不支持 SVG）
常见 LLM 工具	较弱	较弱	弱	视工具而定
思维导图软件（手工）	无	无	强	全支持

表 1: 主流工具 MindMap 能力对比

NotebookLM 最大的优势是 自动性。

生成教学大纲、培训稿、图书结构：真正节约我大量时间

NotebookLM 不只是“总结”，它能按我给的提示词帮我生成 正式的教学结构。只要把项目文档、API 说明、架构设计、案例、视频、博客全都丢进去，让它按提示词生成：

教学大纲
项目培训手册
课程结构
图书章节架构
幻灯片文本
培训案例说明

对于需要写内容、做培训、做演讲的大部分人而言，这个功能非常省心。

下面是我真实在用的典型提示词示例：

   根据提供的内容摘录，编写一份详细的培训手册，系统地阐述通过提供内容中所涉及的核心原则。手册应采用专业和指导性的语气，将复杂的概念分解为可行的步骤和课程。确保内容完全基于源材料，涵盖从所提供内容涉及的所有方面。

培训手册应包括以下内容：
1. 培训目标和预期成果
2. 培训内容和结构
3. 培训方法和工具
4. 培训评估和反馈
5. 培训总结和后续行动
6. 培训案例和实例
7. 培训资源和参考文献

实际效果往往出奇地好。

多格式输入能力：这是我见过最稳的

NotebookLM 支持直接 ingest 各种资料类型，解析能力非常稳定。下表是我的实际体验总结：

输入类型	我的实际使用体验
PDF	最稳，解析结构清晰
Google Docs	更新即同步，非常顺滑
Word / PPT	可正常识别
YouTube 视频	自动总结 + 提取关键内容，很好用
网站 URL	视网站结构，成功率高
纯文本	没问题
图片	部分成功，但足够应对截图内容

表 2: NotebookLM 多格式输入体验

相比之下，其他工具经常出现格式解析问题、乱码、丢内容、跳段落的问题。NotebookLM 在“多格式 ingest”这一点上体验特别稳定。

我目前最常用的 NotebookLM 工作流

下面这张流程图展示了我每天实际使用 NotebookLM 的工作流：

图 2: NotebookLM 日常工作流

其本质就是：让 AI 先帮我抓全局 → 再帮我深入 → 再帮我输出内容。

我遇到的小遗憾与建议

NotebookLM 已经很好用，但我仍有一些强烈期待的改进方向：

MindMap 的导出格式应该支持 SVG 或基于文本（Markmap）

目前只能 PNG，放大容易糊。下表是我对未来功能的期待：

期待功能	用途
SVG 导出	用于写书、做幻灯片、可放大不失真
Markmap 输出	对写 Markdown 的开发者最友好
原始 JSON	允许自行做二次渲染

表 3: MindMap 导出格式期待

我非常期待 NotebookLM 支持 Markmap 格式导出，这对习惯用 Markdown 写博客和文档的用户来说极为友好。

最近 Google 还推出了类似 DeepWiki 的 CodeWiki ，可为 GitHub 项目自动生成带图片的 Wiki，但目前也未支持 Mermaid 或 Markmap。

对话记录应该支持长期保存

现在的体验是：

聊天不会持续保存
只有手动“加入笔记”才能留存结果

这导致一些知识背景容易丢失，期待未来推出“Notebook 对话历史”功能。

幻灯片生产能力如果能支持模板，会更适合作为创作者工具

目前 Video Overview 的视觉风格虽然多，但无法：

上传自己的 PPT 模板
套用企业/个人品牌模版

如果未来能开放 PPT 模板能力，NotebookLM 会直接成为内容创作者的“视频生成中枢”。

Deep Research 早日上线并全面开放

我特别期待这个功能，因为它可能会让 NotebookLM 从“知识整理工具”升级为“研究级工具”。期待它能做到：

稳定地抓取更多公开网页
保证引用质量
能和 Notebook 原有资料结合

这是我个人非常关注的大升级。

移动端希望尽快增强，而不是只提供播放内容

当前移动端体验极简，只能：

听音频
查看 Notebook Guide 的摘要
简单的问答

期待移动端早日支持：

编辑 Notebook
深度对话
MindMap 交互
内容输出能力（生成文档、大纲等）

总结

NotebookLM 是我目前真正意义上“每天都在用”的 AI 工具之一，因为它做到了一件关键的事情：

把信息组织好，把知识结构化，让我不用从零开始面对庞杂文档。

无论是：

学习新技术
阅读长文档
做课程
做培训
写书
做演讲稿
做内容总结

它都能在最前期帮我节省大量时间，把注意力集中在“理解”和“创作”本身。

我会继续把 NotebookLM 作为我的重要工具之一，也会在未来继续观察它的 Deep Research、模板系统与移动端的进展。

这是一款真正贴近“知识工作者”需求的工具，也值得被更多人认识。

网络安全专家爱用的逆向工具 Top9

Tue, 17 Dec 2024 15:13:47 CST

逆向工程是指解构应用程序的过程，不论使用何种编程语言开发，目的是获得其源代码或其中的任何部分。逆向工程的代码有助于发现任何程序中的安全风险，也能用于解密任何恶意应用以进行干扰。

在寻找破解敏感数据或加密密钥的过程中，黑客们通常选择逆向工程作为一种选项，以找出整个系统中隐藏漏洞的所在之处。这导致了敏感数据的完全暴露，包括被硬编码到应用程序中的 API 密钥、 URL 和API 机密信息，开发人员用于测试的开发服务器 URL，非标准端口号，以及硬编码到应用程序文件及其子目录中的多个私钥等。

逆向工程涉及一系列步骤，包括数据编译、记录元素和功能、评估数据、记录控制流、提取流结构、审查提取的设计、生成逆向工程文档。

从实时跟踪运行的应用程序，解析二进制代码到汇编代码，管理和编辑二进制文件或嵌入式资源在 exe 文件中，逆向工具有各种各样的类型，根据其应用可以分为以下几类：

反汇编器
调试器
数据包跟踪和分析工具
脚本工具
文件分析工具

以下分享

1.十六进制编辑器

十六进制编辑器是一组用于微软 Windows 的十六进制开发工具，结合了高级的二进制编辑和字处理器的简洁易用性和多功能性。它主要用于操纵构成计算机文件的基本二进制数据。

此外，十六进制编辑器还支持查找、替换、比较、计算校验和、添加智能标签、颜色映射，并在一个扇区或文件中生成字符分布。十六进制编辑器还支持拖放功能，并可与所有的 Windows 操作系统集成，无论其迭代版本如何。

根据其不同的功能和应用，有各种不同类型的十六进制编辑器，有些允许它们以可视化方式显示文件的内部结构。因此，您可能需要在最常用的工作空间中进行快速简单的十六进制编辑。

数据检视器非常适合解释、查看和编辑十进制和二进制值。算术、逻辑、 ASCII 过程和位操作可用于帮助操作数据集。

集成结构查看器使您能够直观而充分地编辑和查看数据。结构查看器验证信息结构、对各种网络的引用，以及许多原子数据类型：char 、byte 、ubyte 、word 、uword 、long 、ulong 、longlong 、float 、double 、OLE 日期/时间、 DOSTIME 、DOSDATE 、FILETIME 和time_t 。

优点：

进行任何十六进制计算时非常方便
提供多种选项

缺点：

用户友好度不太高
有时更新问题

2.OllyDbg

OllyDbg 是一个针对 Microsoft Windows 的32 位汇编调试器。任何无法获得源代码的情况下，二进制代码的计算认知使得它在许多情况下都非常适用。此外，OllyDbg 是共享软件应用程序,可以下载使用。

OllyDbg 的一些关键特性如下：

1.保存补丁以在会话之间返回到可执行文件并进行修补升级

2.查找对象和库模式

3.代码分析——跟踪记录、查找过程切换、 API 调用、表和循环常量和字符串

4.DNow 、MMX 和为 Athlon 等SSE 数据类型和扩展提供指令

5.识别高级配置，如对事件的请求

6.用于执行的跟踪系统，日志已知可用于调和冲突

7.查找错误命令和掩盖关键字

8.检查和修改内存，设置断点并在不可见的情况下暂停应用程序

9.在会话之间输入标记，将它们还原到可执行文件并修复更新

优点：

共享软件，免费使用
功能强大的动态调试器
相对于 IDA 来说更容易操作
允许直接加载和调试 DLL
有脚本和插件可用

缺点：

仅限于 Microsoft® Windows®
只适用于 x86（或 32 位）软件
不是静态调试器

3.APKTool

Apktool 是另一种开源选择，主要用于 Android 逆向工程，可以将资源解码为几乎其原始形式。可以进行修改，并将其转换回二进制 APK/JAR 文件。

此外，Apktool 还允许逐步调试 smali 代码，并且由于项目文件的结构以及对一些重复性操作的自动化，使得处理应用程序变得更加容易。使用该程序需要 Java 7 。

优点：

在逆向 Android 应用文件方面高效
可在网上免费使用
社区支持良好

缺点：

不如 JEB 反编译工具普遍

4.WireShark

Wireshark 是一个知名的网络和网络领域的工具。它是免费和开源的，是一个 Web 调试器，可以拦截和修改 HTTP 请求，并且可以记录 HTTPS 请求。它用于数据包分析和网络故障排除。

优点：

免费且开源的 Web 调试器
支持跨平台

缺点：

对于初学者来说，可能会感到压力山大

5.Scylla

Scylla 不是一个独立的工具，而更倾向于用于重构 Windows 的x86 和x64 文件的工具。它还具有全 Unicode 支持，并且与 Windows 7 、8 和10 完全兼容。

优点：

一个开源的产品
支持 x64 和x86

缺点：

缺乏更新
有时会有错误

6.Dex2jar

Dex2jar 是一个 API，用于扫描 Dalvik Executable（.dex/.odex）格式。它与 Android 和Java .class 文件兼容。

Dex2jar 包括以下几个组件：

Dex-reader 用于扫描 Dalvik Executable（.dex/.odex）格式。它具有类似 ASM 的轻量级 API
Dex-translator 用于执行转换工作。它读取 dex 指令以 dex-or 格式，经过一些优化后，转换为 ASM 格式
Dex-用于它使用 Dex-translator 表示 dex 指令
Dex-tools 用于处理.class 文件

示例：修改应用程序、解混淆一个.jar 文件。

优点：

可以读取 Dalvik Executable 格式
轻量级 API

缺点：

只与 Android 和Java .class 文件兼容

7.CCF

CCF 是一个免费的便携式可执行编辑器，支持.NET 文件结构。 CCF 支持 32 位和 64 位PE 文件。 CCF 由NTCore 开发，还可用于解压缩 UPX 打包器。

优点：

免费的 PE 编辑器
也支持.NET 文件
支持 PE 32 位和 64 位
包含 PE 重建器
可用于解压缩 UPX

缺点：

免费版本自 2012 年以来未更新

8.Oracle VM VirtualBox

Oracle VM VirtualBox 是一个开源的虚拟化解决方案，在 Windows 、Mac 、Linux 等不同平台上皆可使用，用于在安全环境中分析恶意软件。

优点：

免费且开源
活跃的开发社区
支持虚拟机操作系统

缺点：

与 VMware 相比，功能略差

9.BinaryNinja

目前没有反编译器，但计划在将来的“高级”版本中加入。 Binary Ninja 由Vector 35 开发，以其易用性而自豪，使得自动化比其他解决方案更容易理解。

尽管易于使用，但该软件在反向工程本地主机中仍然存在一些问题。

优点：

简单易用
包含反汇编器

缺点：

不是调试器或反编译器
有时无法加载用户界面
免费版本有限

参考来源： https://www.secureblink.com/blogs/top-9-reverse-engineering-hacking-tools-for-cyber-security-experts

开源实时数据同步工具NiFi

Sat, 09 Nov 2024 21:04:10 CST

Apache NiFi简介

Apache NiFi 是一个强大的数据流管理和自动化工具，旨在简化数据的采集、传输、处理和分发。它特别适合于构建和管理复杂的数据流管道，支持从各种数据源到不同目标系统的数据传输。

Apache NiFi主要功能

Apache NiFi 是一个用于自动化数据流的强大工具，具有广泛的功能集，旨在支持从各种数据源到不同目标的复杂数据流管道。以下是 Apache NiFi 的主要功能：

数据采集与传输：
- 支持从多种数据源采集数据，包括文件系统、数据库、HTTP 服务、消息队列（如 Kafka）、传感器设备等。
- 支持将数据传输到多种目标系统，如 HDFS、数据库、云存储服务、REST API 等。
数据流可视化：
- 提供直观的 Web 用户界面，用户可以通过拖拽和配置处理器来设计和管理数据流。
- 实时显示数据流的状态和性能指标，便于监控和调试。
数据处理与转换：
- 提供丰富的内置处理器，支持数据的解析、转换、清洗、聚合和格式化等操作。
- 支持复杂的数据处理逻辑，如条件路由、数据分片、合并和拆分。
动态路由与优先级控制：
- 支持根据数据内容或属性动态路由数据到不同的处理器或目标。
- 允许为数据流设置优先级，以控制数据处理的顺序和速度。
实时流处理：
- 支持实时数据流处理，能够在数据到达时立即执行处理操作。
- 事件驱动架构，处理器在接收到数据或触发条件时自动执行。
分布式架构与扩展性：
- 支持多节点集群部署，可以水平扩展以处理大规模数据流。
- 集群中的节点通过 Apache ZooKeeper 进行协调和管理。
数据安全与合规：
- 支持数据加密、访问控制和用户身份验证，确保数据的安全性。
- 提供数据审计功能，记录数据流的处理历史和用户操作。
错误处理与重试机制：
- 自动处理数据传输和处理过程中出现的错误，支持重试和故障转移。
- 提供数据回退和恢复功能，确保数据的可靠性和完整性。
可扩展性与集成性：
- 支持自定义处理器和控制器服务的开发，用户可以根据需要扩展 NiFi 的功能。
- 与其他大数据工具和框架（如 Apache Kafka、Hadoop、Spark）紧密集成，支持复杂的数据处理和分析工作流。
监控与管理：
- 提供详细的日志记录和监控功能，帮助用户了解数据流的执行状态和性能指标。
- 支持告警和通知机制，用户可以根据特定条件设置告警，及时响应异常情况。

Apache NiFi 的设计目标是提供一个灵活、高效且易于管理的数据流管理平台，适用于各种数据集成和处理场景。其丰富的功能集使其成为企业数据管道构建和管理的理想选择。

Apache NiFi的优势

灵活性：通过丰富的处理器和自定义开发能力，NiFi 可以适应各种复杂的数据处理需求。
可扩展性：支持多节点集群部署，可以水平扩展以处理大规模数据流。
可视化管理：提供直观的 Web UI，用户可以轻松设计和管理数据流，无需编写复杂的代码。
高可用性：通过故障转移和数据重试机制，确保数据流的高可用性和可靠性。
安全性：支持数据加密、访问控制和审计，确保数据的安全性和隐私保护。

Apache NiFi的架构

Apache NiFi 的架构设计旨在提供一个灵活、高效且可扩展的数据流管理平台。它采用模块化设计，支持分布式部署，能够处理各种规模和复杂度的数据流任务。

核心组件

Web UI（用户界面）：NiFi 提供了一个直观的 Web 用户界面，用于设计、监控和管理数据流。用户可以通过拖拽和配置组件来构建数据流，并实时查看数据流的状态和性能指标。
FlowFile：FlowFile 是 NiFi 中的数据单元，包含数据内容和属性。每个 FlowFile 都有唯一标识符和元数据，支持数据的高效传输和处理。
处理器（Processor）：处理器是执行特定数据处理任务的基本单元。NiFi 提供了丰富的内置处理器，用于数据采集、转换、路由和传输。用户还可以开发自定义处理器以满足特定需求。
连接（Connection）：连接用于在处理器之间传递 FlowFile。连接可以配置为使用不同的队列策略，以控制数据的流动速度和优先级。
流程组（Process Group）：流程组用于组织和管理多个处理器和连接，形成逻辑上的子流程。这有助于复杂数据流的模块化设计和维护。
控制器服务（Controller Service）：控制器服务提供共享的配置和服务，例如数据库连接池、分布式缓存等。它们可以在多个处理器之间复用，提高资源利用率。
报告任务（Reporting Task）：报告任务用于生成和发送 NiFi 系统的运行状态和指标数据，通常用于监控和告警系统。

工作流和数据流

数据采集与处理：
- 数据流从输入处理器开始，输入处理器从外部数据源（如文件系统、HTTP、Kafka）获取数据并生成 FlowFile。
- 中间处理器对 FlowFile 进行处理，包括数据解析、转换、过滤和聚合等操作。
数据路由与分发：
- 根据业务规则和条件，NiFi 可以将 FlowFile 路由到不同的处理器或流程组。
- 输出处理器将处理后的 FlowFile 发送到目标系统（如 HDFS、数据库、云存储）。
实时监控与管理：
- Web UI 提供实时数据流监控功能，用户可以查看处理器的性能指标、队列长度、处理速率等。
- 用户可以动态调整数据流的配置和参数，以优化性能和处理逻辑。

分布式架构

多节点集群：
- NiFi 支持多节点集群部署，可以通过增加节点来扩展处理能力。集群中的每个节点都可以执行数据流任务。
- 集群节点通过 Apache ZooKeeper 进行协调和管理，以确保任务的负载均衡和高可用性。
高可用性与故障转移：
- NiFi 采用主从架构，集群中一个节点为主节点（Primary Node），负责调度任务和管理集群配置。
- 在主节点故障时，集群会自动选举新的主节点，确保数据流的持续性和可靠性。

安全性

用户认证与授权：
- 支持多种认证机制（如 LDAP、Kerberos），确保只有授权用户才能访问和管理 NiFi 系统。
- 提供细粒度的权限控制，用户可以对不同的数据流组件和操作进行授权。
数据加密：
- 支持数据传输加密和存储加密，确保数据在传输和存储过程中的安全性。
审计与日志：
- 提供详细的审计日志记录，记录用户操作和数据流处理历史，便于合规性检查和故障排查。

Apache NiFi 的架构设计使其成为一个灵活、可扩展和安全的数据流管理平台，适用于各种规模和复杂度的数据集成和处理任务。其模块化设计和丰富的功能集使得用户能够高效地构建和管理复杂的数据流管道。

Airflow、Kafka的对比

Apache NiFi、Apache Airflow 和 Apache Kafka 都是现代数据处理和管理生态系统中的重要工具，但它们各自的设计目的和应用场景有所不同。以下是它们的详细对比：

特性	Apache NiFi	Apache Airflow	Apache Kafka
主要用途	实时数据流管理和自动化	工作流调度和管理	消息队列和流处理
架构特点	可视化界面，事件驱动架构	编程接口定义工作流（DAGs），基于调度器和执行器	发布/订阅模型，分布式架构
数据处理	实时数据采集、转换和路由	批处理任务调度，不直接处理数据流	高吞吐量的消息传输，支持实时流处理
扩展性与部署	多节点集群，水平扩展	分布式调度和执行，支持多种执行器	水平扩展，通过分区和副本实现容错
安全性	细粒度权限控制和数据加密	用户认证和授权（RBAC）	SSL 加密、SASL 认证和 ACL 授权
应用场景	实时数据集成、物联网数据采集、日志管理和监控	定时数据处理任务、复杂的 ETL 管道、机器学习工作流	实时数据传输、日志收集和分析、事件驱动架构

对比总结

实时 vs 批处理：
- NiFi：适合实时数据流处理和自动化。
- Airflow：适合批处理任务调度和复杂的工作流管理。
- Kafka：适合高吞吐量的消息传输和实时流处理。
用户界面 vs 编程接口：
- NiFi：提供可视化界面，适合需要快速构建和管理数据流的场景。
- Airflow：提供编程接口，适合需要灵活定义复杂工作流的场景。
- Kafka：主要通过编程接口和命令行工具进行管理和配置。
数据流管理 vs 工作流调度 vs 消息队列：
- NiFi：专注于数据流的管理和处理。
- Airflow：专注于任务调度和工作流管理。
- Kafka：专注于消息队列和流处理。

根据具体的需求和场景，企业可以选择合适的工具或组合使用这些工具来构建复杂的数据处理和管理生态系统。例如，可以使用 NiFi 进行数据采集和预处理，使用 Kafka 进行高吞吐量的消息传输，使用 Airflow 进行批处理任务的调度和管理。

将 Android 手机变成监听工具

Tue, 15 Oct 2024 23:48:56 CST

之前的实验表明，智能手机中的陀螺仪和加速计等惯性测量单元（IMU），可以通过检测声波振动监听对话。这意味着，即使是一个没有开启麦克风权限的应用程序也可以通过 IMU 获得对话内容。为了不让攻击者获得准确信息，Google 将 Android 应用从 IMU 采样数据的频率限制在每秒 200 次，使攻击者无法准确获得对话内容。根据发表在预印本平台 arXiv 上的预印本，研究人员发现了一个漏洞——通过欺骗陀螺仪和运动传感器在时间上稍微偏移地进行测量，将应用实际采样率从每秒 200 次提高到 400 次，可以突破上述保护措施。利用这种方法，攻击者能修复获得的音频量大大提升。与每秒仅采集 200 个样本相比，他们的方法在 AI 转录时单词错误率降低了 83%。这表明，目前的安全保护措施“不足以防止复杂的窃听攻击发生”，应该对其重新评估。

Python地理数据分析工具MovingPandas

Wed, 09 Oct 2024 19:54:20 CST

MovingPandas 是一个用于分析轨迹数据的 Python 库。它在处理和分析移动对象的时空数据方面非常强大，适用于地理信息系统（GIS）、时空数据分析和可视化等领域。它是在热门的地理数据处理库 GeoPandas 的基础上构建的，GeoPandas 本身是建立在Pandas数据处理库之上的。MovingPandas 旨在提供高效、易于使用的工具，以便分析和处理包含位置信息的时间序列数据。MovingPandas使得研究移动模式、路径分析、时空聚类等任务变得更加高效和直观。

核心功能：

轨迹数据表示。MovingPandas 使用 GeoPandas GeoDataFrames 来表示轨迹数据。每条轨迹由一系列带有时间戳的点组成，形成一条时空路径。
轨迹分割。可以根据时间间隔、距离阈值等条件将轨迹分割成多个子轨迹。这对于处理长轨迹或者在某些关键事件发生前后进行分析非常有用。
轨迹特征提取。提供了多种方法来计算轨迹的特征，比如速度、加速度、方向变化等。这些特征在进行模式识别和行为分析时非常有用。
轨迹聚类。支持基于轨迹的聚类分析，可以识别出类似移动模式的轨迹群体。常用的聚类方法包括基于密度的聚类（DBSCAN）、分层聚类等。
轨迹可视化。通过与 Matplotlib 和 Folium 等库的集成，MovingPandas 能够提供强大的轨迹数据可视化功能，包括静态和交互式地图。
时空聚合。支持时空聚合分析，比如计算某个区域在特定时间段内的平均速度、轨迹数量等。

MovingPandas的使用

MovingPandas的安装

MovingPandas作者推荐在Python 3.7及以上环境下安装。请确保你的Python版本符合这一要求。如果你已经安装了Anaconda，可以使用conda命令来安装MovingPandas及其依赖包。

conda install -c conda-forge movingpandas

MovingPandas同样可以使用pip进行安装，但是不推荐，主要原因是其依赖环境较为复杂，使用pip安装可能会出现依赖项缺失或版本冲突的问题。因此，推荐使用conda进行安装。

MovingPandas接口详解

MovingPandas.Trajectory对象

在 MovingPandas 中，Trajectory 类是核心组件之一，主要用于表示和处理单个轨迹。Trajectory 对象是一个时间序列的集合，其中每个数据点代表轨迹上的一个位置，包含了位置信息（经纬度或其他地理空间参考）、时间戳和其他可能的属性（如速度、方向等）。因此，一个 Trajectory 对象是连续移动的点组成的线，这些点按照时间顺序排列。

Trajectory 对象的主要特性：

时间索引：Trajectory 对象的索引通常是时间戳，这使得基于时间的查询和操作变得直观和高效。
空间位置：每个时间点对应一个空间位置，这通常是通过经纬度坐标表示的。
其他属性：除了时间和位置，还可以包含其他相关的数据列，如速度、加速度、方向等，这些信息对于分析移动行为至关重要。

创建 Trajectory 对象通常涉及几个步骤，首先你可能需要有一个包含时空数据的pandas DataFrame。这个DataFrame应该至少包含三列：表示时间戳的列（通常会被设置为索引）、表示X坐标的列（如经度）、表示Y坐标的列（如纬度）。然后，你可以使用 MovingPandas 提供的函数或方法（如TrajectoryCollection.from_geodataframe()）来创建一个或多个 Trajectory 对象。

class movingpandas.Trajectory(df, traj_id, traj_id_col=None, obj_id=None, t=None, x=None, y=None, crs=’epsg:4326′, parent=None)

参数说明：

df：具有GeoPandas的geometry坐标列和时间戳索引的GeoDataFrame，或Pandas的DataFrame。必填参数。
traj_id：任意类型，表示轨迹的唯一标识符。必填参数。
obj_id：任意类型，表示移动物体的唯一标识符。默认为 None。
t：表示包含时间戳的列名，默认为 None。
x：表示包含x坐标的列名，使用Pandas的DataFrame需指定。默认为 None。
y：表示包含y坐标的列名，使用Pandas的DataFrame需指定。默认为 None。
crs：表示 x/y 坐标的坐标参考系统。默认为 “epsg:4326″，即 WGS84。
parent：一个Trajectory 对象，表示父轨迹。默认为 None。

基本信息与操作

copy(): 返回轨迹对象的一个副本。
drop(**kwargs) 方法用于从数据集中删除满足特定条件的行或列。
plot(self, *args, **kwargs): 绘制轨迹。
explore(*args, **kwargs) 方法用于以交互方式可视化和分析数据，支持多种参数和选项以定制显示。
is_latlon() 方法用于判断轨迹数据是否采用经纬度坐标系。
is_valid() 方法用于检查轨迹数据是否有效，例如是否包含必要的字段和合理的坐标。
size() 方法用于返回轨迹中包含的定位点数量。
get_crs() 方法用于获取当前地理数据集的坐标参考系统（CRS），返回一个描述该坐标系的对象或信息。
to_crs(self, crs): 转换轨迹的坐标参考系统。
get_column_names() 方法用于获取数据集中的所有列名，返回一个包含列名的列表。这个方法通常用于快速查看数据集的结构或在进行数据处理时动态获取列名。
get_direction_col() 方法用于获取表示方向数据的列，这些数据通常以角度或方位形式存储。
get_distance_col() 方法用于获取表示距离数据的列，这些数据通常用于计算或分析两点之间的距离。
get_speed_col() 方法用于获取表示对象速度的列名。
get_timedelta_col() 方法用于获取表示时间增量的列名。
get_traj_id_col() 方法用于获取表示轨迹标识符的列名。
get_geom_col() 方法用于获取表示几何数据的列，该列通常包含地理空间信息，如点、线或多边形。
get_angular_difference_col() 方法用于获取包含角度差异的列，这些差异通常用于分析方向或角度变化。
to_point_gdf(self): 返回包含轨迹点的GeoDataFrame。
to_line_gdf(columns=None) 方法用于将轨迹数据转换为 GeoDataFrame 格式的线条几何数据，可以选择包含特定的列。
to_linestring() 方法用于将轨迹数据转换为 LineString 对象，表示轨迹的线条几何形状。
to_linestringm_wkt() 方法用于将轨迹数据转换为包含 ZM（高程和度量）信息的 WKT（Well-Known Text）格式的 LineStringM 字符串。
to_mf_json(datetime_to_str=True, temporal_columns=None) 方法用于将轨迹数据转换为 Moving Features JSON 格式，可以选择将日期时间转换为字符串，并指定时间相关的列。
to_point_gdf(return_orig_tz=False) 方法将轨迹数据转换为 GeoDataFrame 格式的点几何数据，可以选择返回原始时区的时间。
to_traj_gdf(wkt=False, agg=False) 方法将轨迹数据转换为 GeoDataFrame 格式，可以选择生成 WKT 格式的几何数据或进行聚合处理。

轨迹分析与聚合统计

get_bbox(self): 返回轨迹的范围 (bounding box)。
get_start_location(self): 返回轨迹的起始位置。
get_end_location(self): 返回轨迹的结束位置。
get_start_time() 方法用于获取时间序列数据或对象轨迹的起始时间。
get_end_time() 方法用于获取某个事件或过程的结束时间，通常返回一个时间戳或日期时间对象。
get_max(column) 方法用于获取指定列 column 中的最大值。
get_min(column) 方法用于获取指定列 column 中的最小值。
get_position_at(t, method=’interpolated’) 方法用于获取在时间点 t 处的对象位置，默认使用插值方法来计算位置。
get_row_at(t, method=’nearest’) 方法用于获取在时间点 t 附近的对象所在的行，默认使用最近邻方法来选择行。
get_length(units=(None, None, None, None)) 方法用于计算并获取几何对象的长度，可以接受多个单位参数来指定长度的测量单位。
get_mcp() 方法用于获取某个对象的最小凸包 (Minimum Convex Polygon, MCP)，通常用于地理空间分析中确定一组点的最小包围区域。
add_direction(self, overwrite=False): 计算并添加方向信息到轨迹数据中。
get_direction() 方法用于计算和获取两个地理点之间的方向或方位角，通常以度数表示。
get_duration(self): 返回轨迹的总时长。
add_distance(overwrite=False, name=’distance’, units=None)：计算并添加轨迹数据中相邻点之间的距离信息。
add_acceleration(self, overwrite=False, name=’acceleration’): 计算并添加加速度信息到轨迹数据中。
add_speed(self, overwrite=False): 计算并添加速度信息到轨迹数据中。
add_angular_difference(overwrite=False, name=’angular_difference’)：计算并添加轨迹中相邻点之间的角度差异信息到轨迹数据中。
add_timedelta(overwrite=False, name=’timedelta’) ：计算并添加轨迹数据中相邻点之间的时间差信息。
add_traj_id(overwrite=False) 方法用于为轨迹数据添加或覆盖轨迹ID列，以标识相同轨迹中的所有点。
get_segment_between(t1, t2) 方法用于获取在时间点 t1 和 t2 之间的对象轨迹或数据段。
get_linestring_between(t1, t2, method=’interpolated’) 方法用于生成并获取在时间点 t1 和 t2 之间的一条线串，默认使用插值方法。
get_sampling_interval() 方法用于获取时间序列数据中的采样时间间隔。
hausdorff_distance(other, units=(None, None, None, None)) 方法用于计算当前轨迹与另一个轨迹之间的Hausdorff距离，并允许指定单位。
hvplot(*args, **kwargs) 方法用于使用hvPlot库创建高度可定制的图形和可视化。
hvplot_pts(*args, **kwargs) 方法用于使用hvPlot库对地理点数据进行可视化并创建交互式图形。
interpolate_position_at(t) 方法用于在给定时间 t 处插值并返回轨迹的位置。
intersection(feature, point_based=False) 方法用于计算轨迹与给定地理特征的交集，并可以选择基于点的方式进行计算。
intersects(polygon) 方法用于判断轨迹是否与指定的多边形区域相交。
clip(self, polygon): 按多边形裁剪轨迹。
apply_offset_minutes(column, offset) 方法用于将指定列的时间值按给定的分钟数进行偏移调整。
apply_offset_seconds(column, offset) 方法用于将指定列的时间值按给定的秒数进行偏移调整。

MovingPandas.TrajectoryCollection对象

TrajectoryCollection 类是 MovingPandas 中用于表示多条轨迹的集合。它允许用户以集合的形式操作多条轨迹，支持对这些轨迹的批量处理和分析。

可以通过传递一系列 Trajectory 对象来创建一个 TrajectoryCollection。每个 Trajectory 对象代表一条轨迹，包含了时间和位置的信息。

class movingpandas.TrajectoryCollection(data, traj_id_col=None, obj_id_col=None, t=None, x=None, y=None, crs=’epsg:4326′, min_length=0, min_duration=None)

参数说明：

data (list[Trajectory] 或 GeoDataFrame 或 DataFrame) – 包含 Trajectory 对象的列表，或一个包含轨迹 ID、点几何列和时间戳索引的 GeoDataFrame。
traj_id_col (string) – 包含轨迹 ID 的 GeoDataFrame 列名。
obj_id_col (string) – 包含移动对象 ID 的 GeoDataFrame 列名。
t (string) – 包含时间戳的 DataFrame 列名。
x (string) – 包含 x 坐标的 DataFrame 列名。
y (string) – 包含 y 坐标的 DataFrame 列名。
crs (string) – x/y 坐标的坐标参考系 (CRS)。
min_length (numeric) – 期望的轨迹最小长度。长度使用 CRS 单位计算，若 CRS 是地理坐标系（例如 EPSG:4326 WGS84），则长度以米为单位计算。（较短的轨迹将被丢弃。）
min_duration (timedelta) – 期望的轨迹最短持续时间。（较短的轨迹将被丢弃。）

相比MovingPandas.Trajectory多了一些方法：

filter(predicate): 根据给定条件过滤轨迹集合。

MovingPandas.TrajectoryCollectionAggregator对象

MovingPandas.TrajectoryCollectionAggregator 是 MovingPandas 库中的一个类，主要用于对轨迹集合进行聚合操作。通过对轨迹数据进行空间和时间上的聚合，可以帮助用户有效地分析和总结移动模式。

class movingpandas.TrajectoryCollectionAggregator(traj_collection, max_distance, min_distance, min_stop_duration, min_angle=45)

参数说明

traj_collection (TrajectoryCollection) – 要进行聚合的 TrajectoryCollection 对象。
max_distance (float) – 重要点之间的最大距离（距离使用 CRS 单位计算，若 CRS 是地理坐标系，例如 EPSG:4326 WGS84，则距离以米为单位计算）。
min_distance (float) – 重要点之间的最小距离。
min_stop_duration (datetime.timedelta) – 停止检测所需的最短持续时间。
min_angle (float) – 提取重要点的最小角度。

MovingPandas.TrajectoryCleaner对象

MovingPandas.TrajectoryCleaner 是 MovingPandas 库中的一个类，专门用于清理轨迹数据。清理操作可以帮助去除数据中的噪声、填补缺失值以及进行其他预处理步骤，确保轨迹数据的质量和一致性。

IqrCleaner(traj) 是一个类，用于基于四分位数范围 (IQR) 方法来清理轨迹数据中的异常值。
OutlierCleaner(traj) 是一个类，用于通过多种方法识别和清理轨迹数据中的离群点（异常值）。

MovingPandas.TrajectoryGeneralizer对象

MovingPandas.TrajectoryGeneralizer 是 MovingPandas 库中的一个类，用于对轨迹数据进行简化和概括。通过轨迹数据的概括，可以减少数据量，提高处理效率，并且在某些应用场景下有助于更清晰地展示轨迹特征。

TrajectoryGeneralizer(traj) 是一个类，用于通过多种算法对轨迹数据进行简化和概括，以减少数据量并提高处理效率。
DouglasPeuckerGeneralizer(traj) 是一个类，专门使用 Douglas-Peucker 算法对轨迹数据进行简化，保留主要特征点以减少数据量。
MinDistanceGeneralizer(traj) 是一个类，用于根据最小距离间隔对轨迹数据进行简化，移除距离变化小于指定阈值的点。
MinTimeDeltaGeneralizer(traj) 是一个类，用于根据最小时间间隔对轨迹数据进行简化，移除时间间隔小于指定阈值的点。
TopDownTimeRatioGeneralizer(traj) 是一个类，用于通过时间比率算法对轨迹数据进行简化，保留关键时间点以减少数据量。

MovingPandas.TrajectorySmoother对象

MovingPandas.TrajectorySmoother 是一个类，用于对轨迹数据进行平滑处理。轨迹平滑通常是为了减少由于数据采集误差和噪声导致的轨迹抖动和异常点，从而得到更加平滑和准确的轨迹线条。

KalmanSmootherCV(traj) 是一个类，用于使用常速模型（Constant Velocity Model）的卡尔曼滤波算法对轨迹数据进行平滑处理，以减少噪声和抖动。

MovingPandas.TrajectorySplitter对象

MovingPandas.TrajectorySplitter 是一个类，用于将轨迹数据根据特定条件进行分割。这在处理长时间、多段的轨迹数据时特别有用，比如在分析车辆行驶路径、运动员运动轨迹或动物迁徙路径时，可以根据特定的规则将连续的轨迹分割成多个部分，以便进行更细致的分析。

TrajectorySplitter(traj) 是一个类，用于根据指定的条件（如距离、时间或速度）对轨迹数据进行分割，生成多个段以便更细致的分析。
TemporalSplitter(traj) 是一个类，用于根据时间间隔对轨迹数据进行分割，将轨迹分成多个时间段以便更细致的时间序列分析。
ObservationGapSplitter(traj) 是一个类，用于根据观测数据中的时间间隙对轨迹进行分割，当连续观测点之间的时间间隔超过指定阈值时，将轨迹分割成多个部分。
SpeedSplitter(traj) 是一个类，用于根据速度阈值对轨迹数据进行分割，当轨迹点的速度超过指定阈值时，将轨迹分割成多个部分。
StopSplitter(traj) 是一个类，用于根据停留点（长时间停留的点）对轨迹数据进行分割，将轨迹分成移动段和停留段以便更细致的分析。

MovingPandas.TrajectoryStopDetector对象

TrajectoryStopDetector 通过分析轨迹点的时空属性来识别停留点。它会检查一个轨迹对象中的每个点，并根据设定的阈值参数（如最小速度、最小停留时间和最小停留距离等）来鉴定轨迹中是否存在停留段。

class movingpandas.TrajectoryStopDetector(traj, n_threads=1)

方法介绍：

get_stop_points(max_diameter, min_duration) 是 TrajectoryStopDetector 类中的方法，用于根据最大停留直径和最小持续时间来识别和提取轨迹数据中的停留点，并返回包含这些停留点的 GeoDataFrame。
get_stop_segments(max_diameter, min_duration) 是 TrajectoryStopDetector 类中的方法，用于根据最大停留直径和最小持续时间来识别和提取轨迹中的停留段，并返回包含这些停留段的列表。
get_stop_time_ranges(max_diameter, min_duration) 是 TrajectoryStopDetector 类中的方法，用于根据最大停留直径和最小持续时间来识别停留时间范围，并返回停留时间段的列表。

MovingPandas使用实例

准备工作

加载需要的库

import pandas as pd
import geopandas as gpd
import movingpandas as mpd
from datetime import datetime, timedelta
import matplotlib.pyplot as plt
import folium
import bokeh.io
bokeh.io.output_notebook()
from holoviews import opts
opts.defaults(opts.Overlay(active_tools=["wheel_zoom"], frame_width=500, frame_height=400))

加载数据

df = pd.read_excel("driver_log.xlsx")

# 将DataFrame 转换为 GeoDataFrame
gdf = gpd.GeoDataFrame(df, geometry=gpd.points_from_xy(df.lon, df.lat), crs='EPSG:4326')

# 将GeoDataFrame转化为TrajectoryCollection对象
tc = mpd.TrajectoryCollection(gdf, traj_id_col='session_id', obj_id_col = 'driver_no', t='log_time')
# 过滤某个司机的轨迹
df['driver_no'].value_counts()
df['driver_no'].value_counts().plot(kind='bar', figsize=(15,3))
driver_tc = tc.filter('driver_no', 'DR202407021504081000000')

# 展示司机轨迹
driver_tc.plot()

# 获取单个轨迹
my_traj = driver_tc.trajectories[0]

# 展示单个轨迹
traj_plot = my_traj.hvplot(title="Trajectory {}".format(my_traj.id),line_width=7.0, tiles="CartoLight", color="slategray")
traj_plot

停留点检测

针对单轨迹停留点检测

detector = mpd.TrajectoryStopDetector(my_traj)
## 检测停留的时间（这里检测5分钟位移100米以内）
stop_time_ranges = detector.get_stop_time_ranges(min_duration=timedelta(seconds=300), max_diameter=100)
## 检测停留的时间
for stop_time in stop_time_ranges:
    print(stop_time)
## 检测停留点
stop_points = detector.get_stop_points(min_duration=timedelta(seconds=300), max_diameter=100)
stop_points
## 展示停留点
stop_point_plot = traj_plot * stop_points.hvplot(geo=True, size="duration_s", color="deeppink")
stop_point_plot

## 停留点信息
stop_points_gdf = gpd.GeoDataFrame(stop_points, geometry="geometry", crs="EPSG:4326")
stop_points_gdf
## 使用folium展示停留点
# m = my_traj.explore(color="blue",style_kwds={"weight": 4},name="Trajectory")
# stop_points_gdf.explore(m=m,color="red",style_kwds={"style_function": lambda x: {"radius": x["properties"]["duration_s"] / 10 }},name="Stop points")
# folium.TileLayer("OpenStreetMap").add_to(m)
# folium.LayerControl().add_to(m)
# m
## 停留轨迹
stop_segments = detector.get_stop_segments(min_duration=timedelta(seconds=60), max_diameter=100)
stop_segments.to_traj_gdf()
## 停留轨迹
stop_segment_plot = stop_point_plot * stop_segments.hvplot(line_width=7.0, tiles=None, color="orange")
stop_segment_plot

## 使用folium绘图
# m = my_traj.explore(
#     color="blue",
#     popup=True,
#     style_kwds={"weight": 4},
#     name="Trajectory",
# )

# stop_segments.explore(
#     m=m,
#     color="orange",
#     popup=True,
#     style_kwds={"weight": 4},
#     name="Stop segments",
# )

# stop_points_gdf.explore(
#     m=m,
#     color="red",
#     tooltip="stop_id",
#     popup=True,
#     marker_kwds={"radius": 3},
#     name="Stop points",
# )

# folium.TileLayer("CartoDB positron").add_to(m)
# folium.LayerControl().add_to(m)

# m

## 行驶线路
split = mpd.StopSplitter(my_traj).split(min_duration=timedelta(seconds=300), max_diameter=100)
split.to_traj_gdf()
## 可视化行驶线路
split.explore(column="session_id", tiles="CartoDB positron", style_kwds={"weight": 4})

## 整体可视化
stop_segment_plot + split.hvplot(title="Trajectory {} split at stops".format(my_traj.id),line_width=7.0,tiles="CartoLight")

轨迹合集的经停点检测

## 停留点检测
detector = mpd.TrajectoryStopDetector(driver_tc)
stop_points = detector.get_stop_points(min_duration=timedelta(seconds=300), max_diameter=100)
stop_points
## 停留点可视化
ax = driver_tc.plot(figsize=(7, 7))
stop_points.plot(ax=ax, color="red")

## 使用folium可视化
## 使用方folium可视化
# m = driver_tc.explore(
#     column="session_id",
#     popup=True,
#     style_kwds={"weight": 4},
#     name="Trajectories",
# )

# stop_points.explore(
#     m=m,
#     color="red",
#     tooltip="stop_id",
#     popup=True,
#     marker_kwds={"radius": 5},
#     name="Stop points",
# )

# folium.TileLayer("CartoDB positron").add_to(m)
# folium.LayerControl().add_to(m)

# m

速度计算

## 单轨迹增加速度
my_traj.add_speed(overwrite=True,units=("km", "h"))
my_traj.df.head()

## 展示速度
my_traj.plot(column="speed", linewidth=5, capstyle='round', legend=True)
# my_traj.hvplot(c='speed', clim=(0,20), line_width=7.0, tiles='CartoLight', cmap='Viridis', colorbar=True)

## 添加方向
my_traj.add_direction(overwrite=True)
my_traj.df.head()

## 添加时差
my_traj.add_timedelta(overwrite=True)
my_traj.df.head()

## 添加距离
my_traj.add_distance(overwrite=True, name="distance (km)", units="m")
my_traj.df.head()

## 添加加速度
my_traj.add_acceleration(overwrite=True, name="acceleration (mph/s)", units=("mi", "h", "s"))
my_traj.df.head()

## 轨迹集增加速度
driver_tc.add_speed(overwrite=True,units=("km", "h"))
driver_tc.plot(column='speed', linewidth=5, capstyle='round', legend=True, vmax=20)

提取位置

## 获取起点与终点
ax = my_traj.plot()
gpd.GeoSeries(my_traj.get_start_location()).plot(ax=ax, color='blue')
gpd.GeoSeries(my_traj.get_end_location()).plot(ax=ax, color='red')

## 获取特定时间点的位置
t = datetime(2024,7,3,9,30,0)
print(my_traj.get_position_at(t, method="nearest"))
print(my_traj.get_position_at(t, method="interpolated"))
print(my_traj.get_position_at(t, method="ffill")) # from the previous row
print(my_traj.get_position_at(t, method="bfill")) # from the following row

point = my_traj.get_position_at(t, method="interpolated")
ax = my_traj.plot()
gpd.GeoSeries(point).plot(ax=ax, color='red', markersize=100)

## 获取特定时间区间的位置
segment = my_traj.get_segment_between(datetime(2024,7,3,9,10,0), datetime(2024,7,3,9,30,0))
print(segment)
ax = my_traj.plot()
segment.plot(ax=ax, color='red', linewidth=5)

## 获取特定区域内的轨迹
from shapely.geometry import Polygon

xmin, xmax, ymin, ymax = 104.135, 104.137, 30.642, 30.643
polygon = Polygon([(xmin, ymin), (xmin, ymax), (xmax, ymax), (xmax, ymin), (xmin, ymin)])
intersections = my_traj.clip(polygon)
ax = my_traj.plot()
gpd.GeoSeries(polygon).plot(ax=ax, color='lightgray')
intersections.plot(ax=ax, color='red', linewidth=5, capstyle='round')

导出轨迹

## 返回 GeoDataFrame
driver_tc.to_point_gdf()
driver_tc.to_line_gdf()
driver_tc.to_traj_gdf(wkt=True) # 生成wkt格式的聚合

# 聚合数据
driver_tc.add_speed(overwrite=True,units=("km", "h"))
driver_tc.to_traj_gdf(agg={'speed':['min', 'max','mode']})

# 导出数据
export_gdf = driver_tc.to_traj_gdf(agg={'speed':['min', 'max','mode']})
export_gdf.to_file("temp.gpkg", layer='trajectories', driver="GPKG")
gpd.read_file('temp.gpkg').plot()

轨迹分割

## 数据准备
my_traj.add_speed(overwrite=True,units=("km", "h"))
my_traj.plot(column='speed', vmax=20, linewidth=5, capstyle='round', figsize=(9,3), legend=True )

## 根据观测数据中的时间间隙对轨迹进行分割
split = mpd.ObservationGapSplitter(my_traj).split(gap=timedelta(minutes=1))
split.to_traj_gdf()
fig, axes = plt.subplots(nrows=1, ncols=len(split), figsize=(19,4))
for i, traj in enumerate(split):
    traj.plot(ax=axes[i], linewidth=5.0, capstyle='round', column='speed', vmax=20)

## 根据停留点（长时间停留的点）对轨迹数据进行分割
split = mpd.StopSplitter(my_traj).split(max_diameter=10, min_duration=timedelta(minutes=1), min_length=20)
split.to_traj_gdf()
fig, axes = plt.subplots(nrows=1, ncols=len(split), figsize=(19,4))
for i, traj in enumerate(split):
    traj.plot(ax=axes[i], linewidth=5.0, capstyle='round', column='speed', vmax=20)

## 根据速度阈值对轨迹数据进行分割
split = mpd.SpeedSplitter(my_traj).split(speed=0, duration=timedelta(minutes=1))
split.to_traj_gdf()
fig, axes = plt.subplots(nrows=1, ncols=len(split), figsize=(19,4))
for i, traj in enumerate(split):
    traj.plot(ax=axes[i], linewidth=5.0, capstyle='round', column='speed', vmax=20)

轨迹抽稀

## 展示原始轨迹
plot_defaults = {'linewidth':5, 'capstyle':'round', 'figsize':(9,3), 'legend':True}
my_traj.add_speed(overwrite=True,units=("km", "h"))
my_traj.plot(column='speed', vmax=20, **plot_defaults)

## 使用 Douglas-Peucker 算法对轨迹数据进行简化
dp_generalized  = mpd.DouglasPeuckerGeneralizer(my_traj).generalize(tolerance=0.0001)
dp_generalized.plot(column='speed', vmax=20, **plot_defaults)

print('Original length: %s'%(my_traj.get_length()))
print('Generalized length: %s'%(dp_generalized.get_length()))

## 根据最小时间间隔对轨迹数据进行简化
time_generalized = mpd.MinTimeDeltaGeneralizer(my_traj).generalize(tolerance=timedelta(minutes=3))
time_generalized.plot(column='speed', vmax=20, **plot_defaults)

## 通过时间比率算法对轨迹数据进行简化
tdtr_generalized = mpd.TopDownTimeRatioGeneralizer(my_traj).generalize(tolerance=0.001)
fig, axes = plt.subplots(nrows=1, ncols=2, figsize=(19,4))
tdtr_generalized.plot(ax=axes[0], column='speed', vmax=20, **plot_defaults)
dp_generalized.plot(ax=axes[1], column='speed', vmax=20, **plot_defaults)

fig, axes = plt.subplots(nrows=1, ncols=2, figsize=(19,4))
tdtr_generalized.plot(ax=axes[0], column='speed', vmax=20, **plot_defaults)
time_generalized.plot(ax=axes[1], column='speed', vmax=20, **plot_defaults)

平滑轨迹

split = mpd.ObservationGapSplitter(my_traj).split(gap=timedelta(minutes=1))
smooth = mpd.KalmanSmootherCV(split).smooth(process_noise_std=0.1, measurement_noise_std=10)
hvplot_defaults = {'tiles':'CartoLight', 'frame_height':320, 'frame_width':320, 'cmap':'Viridis', 'colorbar':True}
kwargs = {**hvplot_defaults, 'line_width':4}
(split.hvplot(title='Original Trajectories', **kwargs) +  smooth.hvplot(title='Smooth Trajectories', **kwargs))

kwargs = {**hvplot_defaults, 'c':'speed', 'line_width':7, 'clim':(0,20)}
(split.trajectories[1].hvplot(title='Original Trajectory', **kwargs) + smooth.trajectories[1].hvplot(title='Smooth Trajectory', **kwargs))

traj = split.trajectories[1]

cleaned = traj.copy()
cleaned = mpd.OutlierCleaner(cleaned).clean(alpha=2)

smoothed = mpd.KalmanSmootherCV(cleaned).smooth(process_noise_std=0.1, measurement_noise_std=10)
    
(traj.hvplot(title='Original Trajectory', **kwargs) + 
 cleaned.hvplot(title='Cleaned Trajectory', **kwargs) + 
 smoothed.hvplot(title='Cleaned & Smoothed Trajectory', **kwargs))

轨迹聚类和分类

## 查看数据
driver_tc.explore(column="session_id", cmap="plasma", style_kwds={"weight": 4})
## 根据最小距离间隔对轨迹数据进行简化
generalized = mpd.MinDistanceGeneralizer(driver_tc).generalize(tolerance=100)
generalized.to_traj_gdf()

## 对轨迹进行聚合操作
aggregator = mpd.TrajectoryCollectionAggregator(
    generalized,
    max_distance=1000,
    min_distance=100,
    min_stop_duration=timedelta(minutes=10),
)

## 提取显著点
pts = aggregator.get_significant_points_gdf()
pts.hvplot(geo=True, tiles="OSM")

## 获取聚合轨迹的簇
clusters = aggregator.get_clusters_gdf()
(pts.hvplot(geo=True, tiles="OSM") * clusters.hvplot(geo=True, color="red"))

## 使用folium绘制
# m = pts.explore(marker_kwds={"radius": 3}, name="Significant points")
# clusters.explore(m=m, color="red", marker_kwds={"radius": 3}, name="Cluster centroids")
# folium.TileLayer("CartoDB positron").add_to(m)
# folium.LayerControl().add_to(m)
# m

## 获取聚合后的轨迹数据的流动
flows = aggregator.get_flows_gdf()
(flows.hvplot(geo=True, hover_cols=["weight"], line_width=dim("weight") * 7, color="#1f77b3",tiles="CartoLight") * clusters.hvplot(geo=True, color="red", size=dim("n")))

## 使用Folium绘制
# m = flows.explore(style_kwds={"weight": 5},name="Flows")
# clusters.explore( m=m,color="red",style_kwds={"style_function": lambda x: {"radius": x["properties"]["n"]}}, name="Clusters")
# folium.TileLayer("OpenStreetMap").add_to(m)
# folium.LayerControl().add_to(m)
# m

距离计算

## 选择2个轨迹
my_traj = driver_tc.trajectories[3]
toy_traj = driver_tc.trajectories[1]
## 呈现数据
ax = my_traj.plot()
toy_traj.plot(ax=ax, color='red')

## 计算记录
print(f'Distance: {toy_traj.distance(my_traj)} meters') # 返回最短距离
print(f'Hausdorff distance: {toy_traj.hausdorff_distance(my_traj):.2f} meters') # 返回Hausdorff距离

Hausdorff距离可以理解为：对于集合A 中的每个点，计算它到集合B的最近距离，然后在这些距离中找到最大值；反过来对于集合 B 中的每个点，计算它到集合A 的最近距离，然后在这些距离中找到最大值。Hausdorff距离是这两个最大值中的较大者。

参考链接：

开源可视化报表工具：Superset

Thu, 04 Jan 2024 12:54:55 CST

Superset简介

Superset 是一个开源的数据可视化和数据探索平台，最初由 Airbnb 开发，后来成为了 Apache 软件基金会的顶级项目。它支持各种类型的数据源，如数据库和 SQL 引擎，并提供了一个易于使用的界面来创建和共享仪表板和图表。

主要特点包括：

数据可视化: Superset 提供了丰富的图表库，支持从简单的折线图和条形图到更复杂的地理信息系统 (GIS) 可视化等。
数据探索: 用户可以通过 Superset 的 SQL 编辑器执行查询，探索数据，并将结果可视化。
仪表板: 可以将多个图表组合成仪表板，为数据分析提供全面视图。
安全性和权限管理: Superset 支持细粒度的访问控制，允许管理员定义用户和角色，控制对数据和功能的访问。
易于集成: 作为一个开源工具，Superset 可以与多种数据源和其他数据工具集成。
自定义和扩展: 用户可以根据需要自定义图表和界面，并且可以开发新的可视化插件。

Superset 适用于数据分析师和开发人员，帮助他们快速有效地探索和可视化数据，从而做出更好的数据驱动决策。

看板示例：

拖拽式看板编辑器：

SQL编辑器：

Superset架构

Apache Superset 是一款开源的数据可视化和数据探索平台，它的架构设计允许用户轻松地进行数据分析并创建交互式的仪表板。Superset的架构主要由以下几个核心组件构成：

Web服务器

Flask：Superset使用Flask作为其Web框架，处理HTTP请求和渲染界面。
Gunicorn：在生产环境中，通常使用Gunicorn作为WSGI HTTP服务器来运行Flask应用。

SQL查询引擎

SQLAlchemy：Superset通过SQLAlchemy与数据源进行交互，它支持多种数据库。
Pandas：在某些情况下，Superset会使用Pandas库来处理数据。

数据库

元数据数据库：存储Superset的配置信息、仪表板定义、数据源定义等。
缓存数据库：用于缓存数据，提高查询性能。Redis和Memcached是常用的选项。

前端

React & JavaScript：Superset的前端主要使用React框架结合JavaScript开发，用于实现用户界面的交互和动态展示。
js：图表的渲染利用了D3.js库，提供丰富的可视化选项。

安全性

认证与授权：Superset提供灵活的认证选项（如LDAP、OAuth、数据库等）和基于角色的访问控制（RBAC）。
数据安全：支持数据级别的安全控制，确保用户只能访问授权的数据。

扩展性

插件系统：Superset支持自定义插件，允许用户扩展新的可视化类型或其他功能。
API：提供REST API，支持与其他系统的集成。

任务调度器

Celery：用于执行后台任务，如异步查询和发送报告。

Superset功能扩展

拓展Apache Superset主要涉及添加新的可视化类型、增强现有功能、集成更多数据源等方面。

开发自定义可视化插件

Superset支持通过插件机制添加新的图表和可视化类型。
可以使用React和JavaScript开发新的可视化组件。
开发完成后，将插件包含在Superset的配置中，使其成为可用的可视化类型。

集成更多数据源

Superset通过SQLAlchemy与数据源进行交互，可以添加对新数据库的支持。
通过添加相应的数据库驱动和SQLAlchemy方言，可以实现新的数据库支持。

增强现有功能

对Superset的源代码进行修改，可以增强或改变现有功能。
包括改进用户界面、增加新的数据处理功能、优化性能等。

使用API进行集成

Superset提供了REST API，可以用来与其他系统集成。
例如，可以通过API自动化仪表板的创建、更新数据源等。

安全性和认证的定制

可以定制Superset的安全性和认证机制，如集成企业的单点登录（SSO）系统。
修改认证流程以支持LDAP、OAuth等。

使用和配置Celery任务调度器

使用Celery来优化和管理后台任务，如数据刷新、报告发送等。
可以定制Celery的配置以满足特定的性能和规模需求。

参考链接：

你的Spring Boot应用启动很慢？不妨试试这个工具！

Sat, 22 Jul 2023 18:03:35 CST

睡不着闲逛，在GitHub上看到一个不错的开源项目： Spring Startup Analyzer。

从项目名称中就大概能猜到，这是一个分析Spring应用启动过程的工具。Spring Startup Analyzer通过采集Spring应用启动过程的数据，进而生成一个交互式的分析报告，帮助用户发现Spring应用启动慢的位置。同时，Spring Startup Analyzer还提供了Spring Bean异步初始化的工具，来帮助开发者加快Spring应用的启动时间。

下面一起来看看其提供的强大功能。

分析能力

我们可以先从该项目中给出HTML样例报告（点击这里查看）来看看它所提供的分析功能。

把报告内容的细节部分都收起来，可以看到如下图所示的内容：

主要有六个部分：

启动的统计数据。其中包括：启动时间、Bean的数量、使用/总共的JAR包数量、未使用/总共的JAR包数量、ClassLoader数量

Spring Bean初始化数据。这里采集了每个Spring Bean的初始化时间及其细节内容

Bean初始化时间线。通过时间线的方式，清晰地展现了Spring应用启动时候，各个Bean的顺序关系以及时间消耗

方法调用的详细信息。这里统计了每个方法的调用时间、总时间开销和每次调用的平均时间

点开之后，还能看到具体每次调用时候的时间开销和一些调用细节：

启动后未使用的JAR。列出了所有Spring应用启动后没有使用的jar包，可以有效的帮助你清理不需要的依赖，为应用瘦身

应用启动过程的线程火焰图

如何使用

通过上面的介绍，相信你已经了解该工具的强大之处了。接下来就可以通过下面的方法尝试分析一下自己的应用吧：

第一步：从里面的链接中下载最新的安装包

https://github.com/linyimin0812/spring-startup-analyzer/tags

第二步：解压下载的安装包，记住解压后的路径，下面一步要用

第三步：编辑Spring Boot的启动参数，包括：

该工具采用agent的方式启动，所以要添加参数 -javaagent:$HOME/spring-startup-analyzer/lib/spring-profiler-agent.jar，这里 $HOME代表以前的解压路径，记得根据上面解压后的路径编辑这个参数
配置分析工具的参数，这里根据自己需要添加即可，比如可以配置超时时间30分钟： -Dspring-startup-analyzer.app.health.check.timeout=30，其他可配置项如下表，你可以工具自己应用的情况去修改：

第四步：查看该工具的日志，可以通过 $HOME/spring-startup-analyzer/logs路径，这里 $HOME代表以前的解压路径，日志文件的类别为：

startup.log: 启动过程中的日志
transform.log: 被re-transform的类/方法信息

另外，该工具还支持自定义扩展，这里DD没试过，就不具体介绍了。感兴趣的童鞋可以根据文档去试试。

启动优化

这里提到了一个启动加速的优化思路，就是把一些耗时的Bean初始化改成异步就能实现。该项目提供了Bean的异步初始化工具，也非常好用，只需要下面几步就能完成。

第一步：引入依赖

<dependency>     
    <groupId>io.github.linyimin0812</groupId>     
    <artifactId>spring-async-bean-starter</artifactId>     
    <version>2.0.2</version>     
</dependency>

第二步：配置参数

# 异步化的Bean可能在Spring Bean初始化顺序的末尾，导致异步优化效果不佳，打开配置优先加载异步化的Bean     
spring-startup-analyzer.boost.spring.async.bean-priority-load-enable=true     
# 指定异步的Bean名称     
spring-startup-analyzer.boost.spring.async.bean-names=testBean,testComponent     
# 执行异步化Bean初始化方法线程池的核心线程数     
spring-startup-analyzer.boost.spring.async.init-bean-thread-pool-core-size=8     
# 执行异步化Bean初始化方法线程池的最大线程数     
spring-startup-analyzer.boost.spring.async.init-bean-thread-pool-max-size=8

第三步：检查Bean是否异步初始化。查看日志$HOME/spring-startup-analyzer/logs/startup.log文件，对于异步执行初始化的方法，会按照以下格式写一条日志:

async-init-bean, beanName: ${beanName}, async init method: ${initMethodName}

但是，作者在文档中也提到了，异步并不是万能的，你还需要注意以下这几点：

应该优先从代码层面优化初始化时间长的Bean，从根本上解决Bean初始化耗时长问题
对于二方包/三方包中初始化耗时长的Bean(无法进行代码优化)再考虑Bean的异步化
对于不被依赖的Bean可以放心进行异步化，可以通过各个Bean加载耗时中的Root Bean判断Bean是否被其他Bean依赖
对于被依赖的Bean需要小心分析，在应用启动过程中不能其他Bean被调用，否则可能会存在问题

好了，今天的学习就到这里！如果您学习过程中如遇困难？可以加入我们超高质量的 Spring技术交流群，参与交流与讨论，更好的学习与进步！更多 Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

最后，奉上项目地址： https://github.com/linyimin0812/spring-startup-analyzer

自动生成代码工具-cursor(集成ChatGpt)

Fri, 31 Mar 2023 20:11:04 CST

最近体验了一把cursor，自动生成代码工具，集成了最近很火的ChatGpt，目前比较好的就是代码生成工具大概就是 github copilot和 cursor，不过github copilot需要付费使用或者漫长的waitlist，所以目前比较好的是cursor

配置

配置自己经常使用的语言，比如ts、html、css等等

操作

目前来说就两个功能，如下：

ctrl+k：生成代码

描述需要生成的代码功能，回车后会自动帮你生成，比如生成一个斐波那契数列函数

如果对这段代码想做一些编辑操作，比如添加注释，只需选中代码，再次 ctrl+k 回车即可，如下：

生成之后，提供了 Accept All和 Reject All两个功能，类似于【全选/全不选】的功能

Accept All ：添加所有
Reject All ：删除所有

ctrl+l：智能对话

类型于gpt-4的功能，对他提出你的疑惑，他会给出解决方案，不用去百度答案，如下：

当对这段代码不理解时，也可以选中代码，问他实现逻辑或者代码结构等，如下：

注意：从上面对话可以看出来，cursor对于语言不敏感，所以如果想要生成对话呈中文表达，最好前面加上【请用中文】类似于这类词语

用途

cursor的功能目前对于程序员来说，算是简而全的一个代码工具，他支持多种语言，如js、ts、python、rust、go、java等等市面上比较常见的编程语言。他可以根据你的描述自动生成代码，还可以再你接受别人代码是帮助你理解、重构代码，并且可以测试bug、校验格式等等

参考链接

https://cn-sec.com/archives/1614273.html

https://cloud.tencent.com/developer/article/2242409

[分享创造] Vesta: 一个 Docker 和 Kubernetes 配置安全的快速检查工具

Sat, 17 Dec 2022 00:48:36 CST

Vesta 可以做什么

伴随着容器技术的快速发展，容器安全问题也逐渐成为企业所关注的话题，越来越多的公司以及个人开发着选择将他们的服务迁移到云上。目前市面上的容器扫描或容器配置检查的产品大部门都需要进行繁琐的环境配置，同时对机器性能也有着比较高的要求，而开发者或安全测试者或许只是需要扫描少数的镜像或者配置，繁琐的配置和高昂的机器费用对他们来说难以承担，导致安全检查的效率不佳。Vesta 是一款集容器扫描，Docker 和 Kubernetes 配置基线检查于一身的工具。检查内容包括镜像或容器中包含漏洞版本的组件，Docker 以及 Kubernetes 的危险配置。同时也是一个灵活，快速的工具，能够在各种系统上运行，包括但不限于 Windows ，Linux 以及 MacOS

Vesta 为开发者和安全测试者提供了方便、快速的解决方案。整个程序由 golang 编写，只需要使用 go build或者从 releases 下载，无需配置任何环境和数据库，并且在 1 vCPU, 2G Memory 的机器上就可运行，最大化方便使用者们。

项目地址

https://github.com/kvesta/vesta

功能介绍

Vesta 包含两大模块

scan: 扫描容器和镜像的组件信息，检测是否包含 CVE 漏洞版本
analyze: 检查 Docker 和 Kubernetes 配置，是否包含危险配置。后续考虑附加攻击方法

检查列表

Docker 检查

Supported	Check Item	Description	Severity
✔	PrivilegeAllowed	危险的特权模式	critical
✔	Capabilities	危险 capabilities 被设置	critical
✔	Volume Mount	敏感或危险目录被挂载	critical
✔	Docker Unauthorized	2375 端口打开并且未授权	critical
✔	Kernel version	当前内核版本存在逃逸漏洞	critical
✔	Network Module	Net 模式为 `host`模式并且在特定 containerd 版本下	critical
✔	Docker Server version	Docker Server 版本存在漏洞	critical/high/medium/low
✔	Docker env password check	Docker env 是否存在弱密码	high/medium
✔	Image tag check	Image 没有被打 tag 或为默认 latest	low
待定	Container env	检查数据库是否未设置密码, 包括但不限于 `MySQL`, `Redis`, `Memcache`	-
待定	IaC scan	IaC 扫描	-

Kubernetes 检查

Supported	Check Item	Description	Severity
✔	PrivilegeAllowed	危险的特权模式	critical
✔	Capabilities	危险 capabilities 被设置	critical
✔	PV and PVC	PV 被挂载到敏感目录并且状态为 active	critical/medium
✔	ClusterRoleBinding	默认账户被赋予了权限	high/medium
✔	Kubernetes-dashborad	检查 `-enable-skip-login`以及 dashborad 的账户权限	critical/high/low
✔	Kernel version (k8s versions is less than v1.24)	当前内核版本存在逃逸漏洞	critical
✔	Docker Server version (k8s versions is less than v1.24)	Docker Server 版本存在漏洞	critical/high/medium/low
✔	Kubernetes certification expiration	证书到期时间小于 30 天	medium
✔	ConfigMap and Secret check	ConfigMap 或者 Secret 是否存在弱密码	high/medium
✔	Auto Mount ServiceAccount Token	Pod 默认挂载了 `/var/run/secrets/ kubernetes.io/serviceaccount/token`.	low
✔	NoResourceLimits	没有限制资源的使用，例如 CPU,Memory, 存储	low
✔	Job and Cronjob	Job 或 CronJob 没有设置 seccomp 或 seLinux 安全策略	low
待定	CVE-2022-29179	检测 CVE-2022-29179 是否存在	critical
待定	Envoy admin	Envoy admin 被配置以及监听 `0.0.0.0`.	-
待定	Kubelet 10255 and Kubectl proxy	10255 port 打开或 Kubectl proxy 开启	-
待定	Trampoline attack	RBAC 权限不安全，容易遭受 Trampoline 攻击	-
待定	IaC scan	Iac 扫描	-

使用样例

检查 k8s 的基础配置

  $./vesta analyze k8s

2022/11/29 23:15:59 Start analysing
2022/11/29 23:15:59 Geting docker server version
2022/11/29 23:15:59 Geting kernel version

Detected 4 vulnerabilities

Pods:
+----+--------------------+------------------------------+-------------------+-----------------------+----------+--------------------------------+
| ID |     POD DETAIL     |            PARAM             |       VALUE       |         TYPE          | SEVERITY |          DESCRIPTION           |
+----+--------------------+------------------------------+-------------------+-----------------------+----------+--------------------------------+
|  1 | Name: vulntest     | test-volume                  | /etc              | Directory             | critical | Mounting '/etc' is suffer      |
|    | Namespace: default |                              |                   |                       |          | vulnerable of container        |
|    |                    |                              |                   |                       |          | escape.                        |
+    +                    +------------------------------+-------------------+-----------------------+----------+--------------------------------+
|    |                    | Privileged                   | true              | Pod                   | critical | There has a potential          |
|    |                    |                              |                   |                       |          | container escape in privileged |
|    |                    |                              |                   |                       |          | module.                        |
+    +                    +------------------------------+-------------------+-----------------------+----------+--------------------------------+
|    |                    | AllowPrivilegeEscalation     | true              | Pod                   | critical | There has a potential          |
|    |                    |                              |                   |                       |          | container escape in privileged |
|    |                    |                              |                   |                       |          | module.                        |
+    +                    +------------------------------+-------------------+-----------------------+----------+--------------------------------+
|    |                    | Resource                     | memory, cpu,      | Pod                   | low      | None of resources is be        |
|    |                    |                              | ephemeral-storage |                       |          | limited.                       |
+----+--------------------+------------------------------+-------------------+-----------------------+----------+--------------------------------+

Configures:
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
| ID |            TYPEL            |             PARAM              |                         VALUE                          | SEVERITY |          DESCRIPTION           |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
|  1 | K8s version less than v1.24 | kernel version                 | 5.10.104-linuxkit                                      | critical | Kernel version is suffering    |
|    |                             |                                |                                                        |          | the CVE-2022-0185 with         |
|    |                             |                                |                                                        |          | CAP_SYS_ADMIN vulnerablility,  |
|    |                             |                                |                                                        |          | has a potential container      |
|    |                             |                                |                                                        |          | escape.                        |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
|  2 | ConfigMap                   | data: db.string                | db.string:mysql+pymysql://dbapp:Password123@db:3306/db | high     | ConfigMap has found weak       |
|    |                             |                                |                                                        |          | password: 'Password123'.       |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
|  3 | Secret                      | data: password                 | password:Password123                                   | high     | Secret has found weak          |
|    |                             |                                |                                                        |          | password: 'Password123'.       |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
|  4 | ClusterRoleBinding          | binding name:                  | verbs:                                                 | high     | Key permission are given to    |
|    |                             | vuln-clusterrolebinding |      | get,watch,list,create,update |                         |          | the default service account    |
|    |                             | rolename: vuln-clusterrole |   | resources: pods,services                               |          | which will cause a potential   |
|    |                             | namespace: default             |                                                        |          | container escape.              |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+

展望

Vesta 希望能够最大化方便开发者们排查日常配置中的一些基线安全问题，并且也希望云上环境更加安全

黑客或者从事安全领域工作的人用metasploit、Nessus这些工具用的多吗？ - 知乎

Thu, 15 Dec 2022 09:48:57 CST

可耻地匿了。

作为一个世界500强的金融企业，我们对于漏洞自查这块，完全依赖于商业版Findstone，在买这个以前，自查都用的免费版Nessus。上面反映的威胁，中、高、高危一律限期整改，结束。

我们会自己写脚本来加固标装OS，会聘请军工来对自己进行透渗试测，会优化基线并推行，但是不会自己写工具实现自己的需求。因为领导相信：员工只需要做我安排的任务就可以了，这种专业的事情还是买来的好。(╯‵□′)╯︵┻━┻不止一个项目，我们私底下都说这大几百万你给我一半就行我保证给你办好绝对实现你的需求，但是领导不干啊，即使只考虑法律保障道德风险也就决定了领导还是只会去买厂商的整体解决方案不会交给我们耍的。

各位不管你们搞攻击的还是搞安全的机会都大大的啊。。。除了漏洞这块至少还有十几个领域，任一个领域做到了与世界水平相近，你们的机会就很大了，因为很多企事业单位不让用国外产品，或者在条件相同的情况下喜欢国内的二次开发，你看我都不提价格优势。。。

市面上有哪些安全漏洞扫描工具？ - 知乎

Thu, 15 Dec 2022 09:44:55 CST

AWVS、Nessus、AppScan、Goby、NetSparker、Xray等等一系列

如果细分的话应当区分web漏扫和主机漏扫。

web漏扫：通常需要爬虫爬取网页，先爬取再进行漏洞挖掘。
主机漏扫：则通常使用POC脚本扫描服务端口。

web漏扫一般建议使用AWVS配合Xray被动扫描

主机漏扫的话Goby就很不错了

下面分享一下上述软件以及使用的小技巧

AWVS配合Xray被动扫描

最新Acunetix14.6.211215172 支持Log4j检测

xray1.7.1 pro下载使用方法

上面两个软件可以配合使用，这里分享一个实用的批量扫描的脚本

批量扫描脚本分享

链接： https://pan.baidu.com/s/1HFSYtpygYVYo6acqPI0JHw

提取码：mhxv

需要先将批量扫描的网址填写到 url.txt中，按行分开

并设置好 awvs_config.ini中的api_key

" width="937">

需要和awvs中的密钥相同（AWVS后台中右上角的配置文件，打开找到API密钥，点击复制）

" width="1234">

都配置好之后，方可打开脚本，你可以选择直接让AWVS单独扫描，但这样的效果并不是很好。由于最新版本的AWVS与Xray被动扫描不太兼容，因此我们需要指定爬虫模式，然后配合Xray进行被动扫描

" width="622">

记住还要设置好代理的端口

然后运行xray，进行被动扫描并输出结果

        xray_windows_amd64.exe  webscan --listen 0.0.0.0:1111 --html-output scan-output.html

AppScan扫描

如果你不太习惯于使用面板类的应用，你可以选择使用HCL AppScan Standard

下载地址： HCL AppScan Standard v10.0.6.28111最新版

运行起来，输入好域名就可以扫描了。

新版的GUI界面，属实感觉颜值爆表（中间的框估计还没改，后面应该会优化）

测试版GUI界面进入方式：

C:\Program Files (x86)\HCL\AppScan Standard下运行 AppScanGui.exe

" width="1569">

NetSparker

与之类似的还有NetSparker，这里也是提供软件下载地址：

最新Netsparker6.2.0.33156-下载

" width="1289"> " width="1548">

Goby

Goby这里直接去官网下载就好了

Goby - 帮企业梳理资产暴露攻击面

如果你是做红队的，可以申请红队版本，里面POC还是蛮多的。

Nessus

最后是分享Nessus，其实很多公司的二次开发都是基于Nessus里的nasl脚本插件，这里我们分享了最新版本的插件以及Nessus8.15.2软件

Nessus pro8.15.2专业版 10月最新版 pro插件附使用说明

这里简单说一下，如果Nessus占用CPU过高，如何解决？

Nessus插件CPU占用过高问题

如何解决Nessus插件占用CPU过高的问题？

这里推荐使用 CPULimit模块进行限制，当然，如果你在安全公司内部有比较好的服务器，当我没说，跑满它！

CentOS安装CPULimit

        sudo yum install cpulimit

Ubuntu/Debian安装CPULimit

        sudo apt-get install cpulimit

安装好之后，我们可以进行测试，我们先找到nessus进程的pid

        ps aux | grep nessusd

" width="658">

这里看到PID是2544113，我们对其进行限制CPU占用率即可，我们这里设置的是60%

        cpulimit --pid 2544113 --limit 60

当然，你按ctrl+C退出便解除限制了，如果你想要后台运行可以使用 Nohup

        nohup cpulimit --pid 2544113 --limit 60

然后Nessus就老实了，不过这里也仅对于个人CPU不太高的用户，如果是企业，服务器够好，当时是最好的了。

其他的内容后续持续更新，欢迎评论给我留言

并发模拟的四种方式+工具，超级实用！

Mon, 05 Dec 2022 00:00:00 CST

长按关注此公众号，技术干货，及时送达！

一、Postman

Postman是一个款http请求模拟工具

首先演示一下postman最基本的使用

创建一个Springboot项目，测试的代码如下：

   import org.springframework.web.bind.annotation.GetMapping;    
import org.springframework.web.bind.annotation.RequestMapping;    
import org.springframework.web.bind.annotation.RestController;    
    
@RestController    
@RequestMapping("test")    
public class TestConrtoller {    
    
    @GetMapping("demo")    
    public String testDemo() {    
        return "result~";    
    }    
}

为了便于操作，一般会将

http://127.0.0.1:8080 是经常使用的地址+端口号，可以设置为环境

推荐下自己做的 Spring Boot 的实战项目：

https://gitee.com/yoodb/jing-xuan

点击右上角的设置图标

选择global

输入信息

以后再进行测试就能这样搞简写了

知道基本使用之后,我们来看一下如何模拟并发测试

填写基本信息后，创建

这个时候会创建出Concurrency的文件夹，我们可以把刚才测试的demo的例子放进这个文件夹下

这个时候就可以在Concurrency下看到这个接口测试了

选择并发测试：

这个时候弹出我们想要的框了

点击Run Concurrency

你可以立马感觉到CPU在“燃烧”，因为要记录并打印日志，显示的话是一条一条来的，其实测试的速度，要比你看到的打印的日志的速度快，绿色表示正常

二、Apache Bench（AB）

ApacheBench 是 Apache 服务器自带的一个web压力测试工具，简称ab。

ab又是一个命令行工具，对发起负载的本机要求很低，根据ab命令可以创建很多的并发访问线程，模拟多个访问者同时对某一URL地址进行访问，因此可以用来测试目标服务器的负载压力。总的来说ab工具小巧简单，上手学习较快，可以提供需要的基本性能指标，但是没有图形化结果，不能监控。

使用的话，首先需要安装Apache服务器

网站：http://httpd.apache.org/download.cgi

因为我的操作系统是windows10，这里选择File for Microsoft Windows

Linux下的安装是非常简单的，这里不再演示

选择 ApacheHaus

进入下载页面选择适合自己电脑的版本

文件解压到本地文件夹下，如果不是解压在c盘，需要设置参数，注意文件路径最好都是英文

关于需要设置参数，conf->httpd.conf 使用文本编辑器打开，

需要修改的有三个地方：

运行根目录，修改成自己解压到本地的路径

监听端口，默认监听端口是80，如果已被使用会报错需要修改，如果80端口未被使用，可不修改；如果修改了监听端口，则需要把ServerName localhost也相应改成同样的端口号

DocumentRoot 测试文件存放位置，且该目录必须存在

配置完成后，命令行cmd进入D:\softUtil\Apache24\bin目录下

   httpd.exe  -k  install

启动：

   httpd.exe -k start

测试:

-n :请求数
-c: 并发数

三、并发模拟工具JMeter

JMeter也是一款性能测试工具，是图形化的。

下载地址：传送门 http://jmeter.apache.org/

需要Java8+的环境

解压到你觉得合适的目录下（注意最好是英文路径）

进入它的bin目录下启动jmeter.bat即可

使用很简单，首先在测试计划部分新建一个线程组

设置好基础信息后添加HTTP请求（基本信息设置好没有OK哈，直接添加HTTP请求）

填写HTTP请求相关的内容

之后还要添加监听器，这里选择是图形结果

再添加一个查看结果树吧

在运行之前打开log Viewer

下面开始运行：

执行成功，来感受一下结果：

点进去

查看结果树

四、代码模拟

这里需要用到一个类，就是CountDownLatch。

CountDownLatch是一个计数器闭锁，通过它可以完成类似于阻塞当前线程的功能，即：一个线程或多个线程一直等待，直到其他线程执行的操作完成。

推荐下自己做的 Spring Cloud 的实战项目：

https://gitee.com/yoodb/jingxuan-springcloud

CountDownLatch用一个给定的计数器来初始化，该计数器的操作是原子操作，即同时只能有一个线程去操作该计数器。调用该类await方法的线程会一直处于阻塞状态，直到其他线程调用countDown方法使当前计数器的值变为零，每次调用countDown计数器的值减1。当计数器值减至零时，所有因调用await()方法而处于等待状态的线程就会继续往下执行。这种现象只会出现一次，因为计数器不能被重置。

下图和它的方法可以体现出来：

CountDownLatch类只提供了一个构造器：

   public CountDownLatch(int count) {  };  //参数count为计数值

然后下面这3个方法是CountDownLatch类中最重要的方法(上图能够反映出来）

   public void await() throws InterruptedException { };   //调用await()方法的线程会被挂起，它会等待直到count值为0才继续执行    
public boolean await(long timeout, TimeUnit unit) throws InterruptedException { };  //和await()类似，只不过等待一定的时间后count值还没变为0的话就会继续执行    
public void countDown() { };  //将count值减1

下面还需要看一个类Semaphore

Semaphore与CountDownLatch相似，不同的地方在于Semaphore的值被获取到后是可以释放的，并不像CountDownLatch那样一直减到底。另外，推荐公众号Java精选，回复java面试，获取面试资料，支持在线刷题。

它也被更多地用来限制流量，类似阀门的功能。如果限定某些资源最多有N个线程可以访问，那么超过N个主不允许再有线程来访问，同时当现有线程结束后，就会释放，然后允许新的线程进来。有点类似于锁的lock与 unlock过程。相对来说他也有两个主要的方法：

用于获取权限的acquire(),其底层实现与CountDownLatch.countdown()类似;
用于释放权限的release()，其底层实现与acquire()是一个互逆的过程。

通过这两个类可以进行并发的模拟：

测试一下：

   import lombok.extern.slf4j.Slf4j;    
    
import java.util.concurrent.*;    
    
@Slf4j    
public class CuncurrencyTest {    
    
    // 请求总数    
    public static int clientTotal = 5000;    
    
    // 同时并发执行的线程总数    
    public static int threadTotal = 200;    
    
    public static int count = 0;    
    
    public static void main(String[] args) throws InterruptedException {    
        // 定义线程池    
        ExecutorService executorService = Executors.newCachedThreadPool();    
        // 定义信号量 最大的线程数量    
        final Semaphore semaphore = new Semaphore(threadTotal);    
        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);    
    
        for (int i = 0; i < clientTotal; i++) {    
            executorService.execute(() -> {    
                try {    
                    semaphore.acquire();    
                    add();    
                    semaphore.release();    
                } catch (InterruptedException e) {    
                    e.printStackTrace();    
                    log.error("exception",e);    
                }    
                countDownLatch.countDown();    
            });    
        }    
        countDownLatch.await();    
        executorService.shutdown();    
        log.info("count:{}",count);    
    
    }    
    
    private static void  add() {    
        count++;    
    }    
}

因为count不是线程安全的，且没有做防护措施，结果是错的

上面是对代码的并发模拟的简单形式，值得注意的是，这里提到的两个类不是专门做并发模拟，它们的用途很广泛，大家可以了解一下。

来源：blog.csdn.net/qq_42322103/article/details/102736170

版权声明：此内容来源网络，版权归原作者所有。我们转载的内容，都会注明来源，除非无法确认。若有侵权，烦请告知，我们会立即删除并表示歉意。谢谢！

PS：文章若对您有用，请帮助 点赞、在看、转发吧！- END -点击卡片关注我们，更多技术干货，及时为您送达！

Meta开源JavaScript内存泄漏监测工具MemLab

Thu, 22 Sep 2022 11:26:54 CST

一、MemLab简介

上周，Facebook母公司Meta 宣布了开源 MemLab，一个基于 Chromium 的浏览器的 JavaScript 应用程序内存泄漏监测工具。同时，Facebook 技术团队指出：“应用程序的性能和功能正确性问题通常会被用户立即留意到。然而内存泄漏却不一样，它不容易被立即察觉，但它每次都会吃掉一大块内存，使得整个网络会话的响应变得非常慢。”

为了帮助开发人员解决这个问题，Meta 构建了MemLab，它可以自动进行内存泄漏检测并更容易找到泄漏的根本原因。据官方公告称，Meta 内部使用它成功地控制了不可持续的内存增长，并识别了产品和基础设施中的内存泄漏和内存优化机会。目前，Meta 已经在 GitHub 上开源了 MemLab。

Facebook在 2020 年被重新设计为单页应用程序 (SPA)，该应用程序的大部分渲染和导航使用客户端 JavaScript。而 Meta 的大多数其他流行网络应用程序都使用了类似的架构来构建，包括 Instagram 和 Workplace。

虽然这种架构使其能够提供更快的用户交互、更好的开发人员体验和更像应用程序的感觉，但在客户端维护 Web 应用程序状态会使有效管理客户端内存变得更加复杂。且内存泄漏的后果在单页应用程序（SPA）中更为严重，因为用户可能会在较长时间内持续与页面交互，而 MemLab 就是专为这种场景设计的。

在许多情况下，JavaScript 可能会泄漏内存。比如，Facebook 工程师 Liang Gong 和 Glenn Conner 就在公告中谈到，当你向 Chrome 控制台发送一个对象时，Chrome 会对其进行隐藏引用，以防止它被收集。另外，auth0 工程师 Sebastian Peyrott 也曾谈到，其他可能出现泄漏或未绑定内存增长的情况则与意外使用全局变量、忘记计时器或回调以及 DOM 外引用有关。

虽然 Chrome 开发者工具提供了检查 JavaScript 代码的内存行为的基本手段，比如时间线视图和配置文件视图，但这并不直接，也不能自动化。相反，MemLab 则可以很容易地集成到 CI/CD 管道中，Gong 和 Conner 介绍道。

二、工作原理

MemLab 的工作原理是通过预定义的测试场景运行 headless 浏览器并对 JavaScript heap snapshots 进行差异分析来发现内存泄漏。要达到这一目的，需要经过如下几步：

导航到页面并返回；
查找未释放的对象；
显示泄露追踪结果。

据悉，MemLab 使用了一个名为“Puppeteer”的 Node.js 库。它可以控制 Google Chrome 或其它基于 Chromium 内核打造的浏览器，且默认情况下以 headless 模式运行（方便命令行交互）。

Facebook 工程师解释称，MemLab 的工作方式就是导航到一个页面、然后离开。正常情况下，可预计该页面分配的大部分内存也将被释放。但若没有被释放，则意味其存在极高的内存泄露可能性。

我们知道，React 使用存储在树结构中、被称作 Fibers 的对象，来表示内存中的浏览器文档对象模型（DOM）。据该团队所述，这可能是存在“巨大内存泄露”的一个主要原因。拥有强连接图的缺点很是显著，若有任何外部引用指向图的任何部分，就无法对整个图开展垃圾回收。

对于浏览器内存泄漏检测，MemLab 需要开发人员提供的唯一输入是一个测试场景文件，该文件定义了如何通过 overriding Puppeteer API 和 CSS 选择器的三个回调来与网页进行交互。MemLab 会自动对 JavaScript heap 进行差异化处理，完善内存泄漏，并对结果进行汇总。

MemLab 的另一特性，就是提供了 JavaScript 堆的图形视图、启用了用于检查堆快照的 API 。这意味着开发者能够编写开展内存断言的测试，例如声明某个对象将不再存在于内存中。

此外还有一个用于查找重复字符串实例的工具，在某个案例中，团队发现字符串占用了 70% 的堆、且其中半数至少有一个重复的实例。包括 Chrome、Edge、Firefox 在内的浏览器，都有附带内存检查工具。但正如以为开发者在 Hacker News 上吐槽的那样，这些开发工具难以在调试过程中揪出内存泄露的问题。

最后，MemLab 的另一项强大功能，就是可以在测试期间作为命令过程的一部分而运行。这意味着如果代码中引入了严重的泄露，开发者们也能够在投入生产环境前加以捕获。

除了内存泄漏检测之外，MemLab还包括一组用于查找内存优化机会的内置CLI命令和api，并提供如下的功能：

堆内容分解
监测单个对象的内存使用情况
查找重复的字符串实例

比如，监测浏览内存泄漏部分UI。

跟踪UI内存泄漏的整个链路。

三、基本使用

3.1 安装与使用

首先，需要全局安装MemLab插件，安装的命令如下：

  npm install -g memlab

例如下面是找到谷歌Maps中的内存泄漏的例子，我妈可以创建一个场景文件来定义如何与谷歌Maps进行交互，比如将其命名为test-google-maps.js。

  function url() {
  return 'https://www.google.com/maps/@37.386427,-122.0428214,11z';
}


async function action(page) {
  await page.click('button[aria-label="Hotels"]');
}


async function back(page) {
  await page.click('[aria-label="Clear search"]');
}


module.exports = {action, back, url};

现在使用下面的命令运行上面的js代码, 当memlab与web页面进行交互时就会运行内置的泄漏检测器检测内存泄漏。

  memlab run --scenario test-google-maps.js

执行结束之后，Memlab就会打印内存泄漏结果，显示每个泄漏对象集群的一个代表性保留跟踪。

  MemLab found 46 leak(s)
--Similar leaks in this run: 4--
--Retained size of leaked objects: 8.3MB--
[Window] (native) @35847 [8.3MB]
  --20 (element)--->  [InternalNode] (native) @130981728 [8.3MB]
  --8 (element)--->  [InternalNode] (native) @130980288 [8.3MB]
  --1 (element)--->  [EventListener] (native) @131009888 [8.3MB]
  --1 (element)--->  [V8EventListener] (native) @224808192 [8.3MB]
  --1 (element)--->  [eventHandler] (closure) @168079 [8.3MB]
  --context (internal)--->  [<function scope>] (object) @181905 [8.3MB]
  --bigArray (variable)--->  [Array] (object) @182925 [8.3MB]
  --elements (internal)--->  [(object elements)] (array) @182929 [8.3MB]
...

接着，我们就可以通过这些捕获的跟踪信息定位到里面的方法。

当然，我没也可以使用Memlab查看基于从Chromium、Hermes、memlab或任何node.js或electronic .js程序中获取的单个JavaScript堆快照检测到的内存问题。

  memlab view-heap --snapshot <PATH TO .heapsnapshot FILE>

然后，我没可以使用对象的id，比如node-id @28173来精确定位特定的堆对象。

当然，Memlab也支持自定义的检漏器，自定义检漏器时需要在场景文件中添加一个 filterLeak文档。对于目标交互分配的每个未释放的堆对象(节点)将调用filterLeak。

  function filterLeak(node, heap) {
  // ... your leak detector logic
  // return true to mark the node as a memory leak
};

heap是最终JavaScript堆快照的图形表示。

3.2 堆分析与研究

除了检测内存泄露意外，Memlab还提供了很多其他有用的命令，比如查看某个对象在运行的交互过程中的整个链路。

  memlab analyze unbound-object

获取V8/hermes .heapsnapshot文件。

  memlab analyze unbound-object --snapshot-dir <DIR_OF_SNAPSHOT_FILES>

使用memlab analyze查看所有内置内存分析。

  memlab trace --node-id <HEAP_OBJECT_ID>

3.3 Memlab API

Memlab的npm包支持在浏览器中启动端到端运行并检测内存泄漏。

  const memlab = require('memlab');


const scenario = {
    url: () => 'https://www.google.com/maps/@37.386427,-122.0428214,11z',
    action: async (page) => await page.click('button[aria-label="Hotels"]'),
    back: async (page) => await page.click('[aria-label="Clear search"]'),
}
memlab.run({scenario});

3.4 内存断言

Memlab支持在Node.js程序中进行Jest测试，也可以使用图视图API来获得其自身状态的堆图视图，执行自内存检查，并编写各种内存断言。

  import type {IHeapSnapshot} from '@memlab/core';
import {config, takeNodeMinimalHeap, tagObject} from '@memlab/core';
test('memory test', async () => {
  config.muteConsole = true;
  const o1 = {};
  let o2 = {};
  tagObject(o1, 'memlab-mark-1');
  tagObject(o2, 'memlab-mark-2');
  o2 = null;
  const heap: IHeapSnapshot = await takeNodeMinimalHeap();
   //断言函数
  expect(heap.hasObjectWithTag('memlab-mark-1')).toBe(true);
  //断言函数
  expect(heap.hasObjectWithTag('memlab-mark-2')).toBe(false);
}, 30000);

附件： https://github.com/facebookincubator/memlab

开发一个在线代码对比工具

Sat, 23 Jul 2022 09:32:39 CST

highlight: monokai

我正在参加「创意开发投稿大赛」详情请看：掘金创意开发大赛来了！

前言

在开发过程中，我们经常需要用到代码对比，对比下代码是否一致，有哪些改动，方便我们可以查看问题，今天我们就来说实现下，其实很简单，不需要后端，纯前端就可以实现。

Monaco Editor

Monaco Editor 是 VS Code 中使用的开源代码编辑器，拥有代码高亮和代码自动补全的功能，并且内置了一个 Diff Editor。

官网就有一个 Diff Editor 的演示，我们要开发的就是在这个基础之上，加上语言切换的功能，让这个 Diff Editor 拥有内置云语言的语法高亮。

TypeScript, JavaScript, CSS, LESS, SCSS, JSON, HTML、XML, PHP, C#, C++, Razor, Markdown, Diff, Java, VB, CoffeeScript, Handlebars, Batch, Pug, F#, Lua, Powershell, Python, Ruby, SASS, R, Objective-C

官网罗列了这些语言，但远不止于此。

马上掘金

代码片段使用 monaco-editor 创建一个简单的代码编辑器

代码片段使用 monaco-editor 创建一个简单的 Diff 编辑器

Monaco Editor 有 2 种加载方式，分别是 amd 和 esm，也就是 Requirejs 和 ES Modules。马上掘金中使用的是 requirejs。

技术栈选择

我准备把常用的工具做成一个工具网站，所以我选择使用 next.js，并且可以使用 vercel 免费持续部署。

关于 Monaco Editor 在 next.js 中的配置，之前有介绍过，大家可以看这篇文章《在 Next.js 中使用 Monaco Editor》。

实现 Diff Editor

  import type { editor as MonacoEditor } from "monaco-editor";
import { useEffect, useRef, useState } from "react";
import * as monaco from "monaco-editor";

export default function TextDiffPage() {
 const editorContainer = useRef<HTMLDivElement | null>(null);
 const [language, setLanguage] = useState("text");
 const [inlineView, setInlineView] = useState(false);

 const [diffEditor, setDiffEditor] =
   useState<MonacoEditor.IStandaloneDiffEditor | null>(null);

 const createModel = (
   value: string,
   language: string,
   type: "original" | "modified"
 ) => {
   return monaco.editor.createModel(value, language);
 };

 const initEditor = async () => {
   const originalModel = createModel(`Hello World`, language, "original");
   const modifiedModel = createModel(`Goodbye World`, language, "modified");
   const editor = monaco.editor.createDiffEditor(editorContainer.current, {
     minimap: { enabled: false },
     theme: "vs-dark",
     renderSideBySide: !inlineView,
     originalEditable: true,
   });
   editor.setModel({
     original: originalModel,
     modified: modifiedModel,
   });

   setDiffEditor(editor);
 };

 useEffect(() => {
   initEditor();
   return () => {
     if (diffEditor) diffEditor.dispose();
   };
 }, []);

 useEffect(() => {
   if (diffEditor) {
     diffEditor.updateOptions({
       renderSideBySide: !inlineView,
     });
   }
 }, [inlineView]);

 return (
   <div className="h-screen flex flex-col">
     <header className="h-16 border-b dark:border-neutral-800 flex-shrink-0 flex items-center px-3 space-x-5">
       <label className="space-x-1 flex items-center">
         <input
           type="checkbox"
           checked={inlineView}
           onChange={(e) => setInlineView(e.target.checked)}
         />
         <span>Inline diff</span>
       </label>
     </header>
     <div ref={editorContainer} className="h-full"></div>
   </div>
 );
}

上述代码很简单，可能有同学对 createModel 方法比较疑惑，为什么是 Model ？好比 Monaco Editor 是一个容器，容器可以设置 Model、切换 Model，比如 vscode 中，每打开一个文件就是一个 Model，文件切换就是切换 model，每个文件都有状态，比如光标位置，历史记录等，这些状态都存在 model 中，这样就不会因为文件切换而状态混淆。

  // typescript 禁用类型检查
monaco.languages.typescript.typescriptDefaults.setDiagnosticsOptions({
  noSemanticValidation: true,
  noSyntaxValidation: false,
});

// typescript jsx 格式使用 React 语法解析
monaco.languages.typescript.typescriptDefaults.setCompilerOptions({
  jsx: monaco.languages.typescript.JsxEmit.React,
});

对与一些 typescript 的语法校验我们可以选择关闭，jsx 不支持，可以设置为 react 语法支持。

最后

最后我的工具网站也开源了，包含一些前端常用工具，还可以在线刷面试题。

如果对你有帮助，可以随手点个赞，这对我真的很重要。

以上就是本文全部内容，希望这篇文章对大家有所帮助，也可以参考我往期的文章或者在评论区交流你的想法和心得，欢迎一起探索前端。

简述前端包管理工具机制和相关实践

Wed, 01 Jun 2022 00:00:00 CST

简述前端包管理工具机制和相关实践

npm 依赖管理机制

区别于 Python 的包管理工具 pip 的全局安装，npm 会安装依赖包到当前项目目录，使不同项目的依赖更成体系，这样做的好处是减轻了包作者的 API 兼容性压力；但是缺陷是如果两个项目依赖了一个相同的库，一般这个库会在这两个项目中各安装一次，即相同的依赖包会被多次安装。
我们先通过一张流程图(源自掘金)来了解下 npm install 的整体流程

可以看到执行 npm install 后依次会进行以下流程

检查 package-lock.json
通过和 package.json 对比确定是否远程获取包信息
扁平化构建依赖树
添加缓存
下载包并解压到 node_modules
生成新的 lock 文件值得注意的是，早期 npm 版本(v5.0 - v5.4)发现 package.json 和 package-lock.json 不一致时，对依赖的安装方式是不一样的。 所以对于团队而言，最佳实践应该是保持 npm 版本的一致性！

缓存机制

我们可以从流程图中看到，npm install 的流程中会查找和使用缓存，以及下载包后会添加缓存的环节。由于依赖嵌套机制，项目中 node_moudles 占用的磁盘空间无疑是最大的，如果安装时每次都通过网络下载获取，那么时间成本是巨大的。常见的优化方式是“空间换时间”，npm 也通过缓存机制来解决这个问题。
简单了解下缓存的目录的和清除机制。
通过 npm config get cache命令可以查询到缓存目录：默认是用户主目录下的 .npm/_cacache 目录。
npm cache clean --force即可强制清除缓存。

yarn 带来了什么？

yarn 是于 2016 年诞生的，它的出现解决了历史上 npm 的很多问题，比如缺乏对于依赖的完整性和一致性保障(npm v3 版本还没有 package-lock.json)，以及 npm 安装速度过慢的问题等。npm 目前已经迭代到 v8 版本，在很多方面已经借鉴了 yarn 的优点，但是我们不妨了解下 yarn 诞生时带来的理念。

确定性。通过 yarn.lock 等机制，保证了确定性，这里的确定性包括但不限于明确的依赖版本、明确的依赖安装结构等。即在任何机器和环境下，都可以以相同的方式被安装。
模块扁平化安装。将依赖包的不同版本，按照一定策略，归结为单个版本，以避免创建多个副本造成冗余。
更快的速度。yarn 采取并行安装的机制进行包的安装任务，提高了性能；yarn 引入的缓存机制使二次安装的速度更快。
更好的语义化。yarn 的命令更加简洁。 解决早期 npm 的依赖管理问题

文章的开始提到 npm 是将依赖放到项目的 node_modules 中，同时如果 node_modules 中的依赖 A 还依赖了其他依赖 B，那么 B 也会被安装到 A 的 node_modules 文件夹，依次递归最终形成非常复杂和庞大的依赖树。
这种依赖管理方式会随着项目的迭代，node_moudles 会变得越来越复杂，从而造成：

非常深的项目依赖层级，难以排查问题
依赖被重复安装，浪费磁盘，网络等资源，安装速度慢那么 yarn 是如何解决这个问题的呢？那就是模块扁平化安装机制。假如我们有这样一个文件依赖结构。

  App   
 -a@2.0   
   -b@2.0   
 -b@2.0   
 -c@1.0   
   -b@2.0

yarn 在安装依赖时会打平依赖，并对重复依赖进行提升，最终形成的依赖结构如下：

  App   
 -a@2.0   
 -b@2.0   
 -c@1.0

但是需要注意的是： 模块的安装顺序可能影响 node_modules 内的文件结构。在 npm v3 版本中，假如项目一开始依赖了 a@1.0，此时 a@1.0 会被安装在顶层目录；随着迭代，又引入了模块 b@1.0，而 b@1.0 又依赖了 a@2.0，此时 a@2.0 会被安装在 b@1.0 下，因为顶层已经有一个 a@1.0 了。

pnpm: 最先进的包管理工具？

在各个场景下，pnpm 相比较于 npm(v8)和 yarn(v3)在性能上都有不错的提升。
pnpm 之所以有如此大的性能提升，简单来说 pnpm 是通过全局 store（目录 ${os.homedir}/.pnpm-store）来存储 node_modules 依赖的 hard-links，当在项目文件中引用依赖的时候则是通过 symlink 去找到对应虚拟磁盘目录下(.pnpm 目录)的依赖地址。相比于 npm 和 yarn 会在每个项目中都安装一份 node_moudles, pnpm 的全局 store 则实现了“安装一次，所有项目复用”，这样避免了二次安装带来的时间消耗。
除此之外，pnpm 本身的设计机制解决了 monorepo 的很多痛点，比如 ”幽灵依赖“和 ”依赖重复安装“的问题。如图：下面两小节内容源自：pnpm: 最先进的包管理工具 ^[1]

幽灵依赖

Phantom dependencies 被称之为幽灵依赖，解释起来很简单，即某个包没有被安装(package.json 中并没有，但是用户却能够引用到这个包)。
引发这个现象的原因一般是因为 node_modules 结构所导致的，例如使用 yarn 对项目安装依赖，依赖里面有个依赖叫做 foo，foo 这个依赖同时依赖了 bar，yarn 会对安装的 node_modules 做一个扁平化结构的处理(npm v3 之后也是这么做的)，会把依赖在 node_modules 下打平，这样相当于 foo 和 bar 出现在同一层级下面。那么根据 nodejs 的寻径原理，用户能 require 到 foo，同样也能 require 到 bar。

  package.json -> foo(bar 为 foo 依赖)   
node_modules   
  /foo   
  /bar -> 依赖

那么这里这个 bar 就成了一个幽灵依赖，如果某天某个版本的 foo 依赖不再依赖 bar 或者 foo 的版本发生了变化，那么 require bar 的模块部分就会抛错。

依赖重复安装

这个问题其实也可以说是 hoist 导致的，这个问题可能会导致有大量的依赖的被重复安装，举个例子:
例如有个 package，下面依赖有 lib_a、lib_b、lib_c、lib_d，其中 a 和 b 依赖 util_e@1.0.0，而 c 和 d 依赖 util_e@2.0.0。
那么早期 npm 的依赖结构应该是这样的:

  - package   
  - package.json   
  - node_modules   
     - lib_a   
       - node_modules <- util_e@1.0.0   
     - lib_b   
       - node_modules <- util_e@1.0.0   
     _ lib_c   
       - node_modules <- util_e@2.0.0   
     - lib_d   
       - node_modules <- util_e@2.0.0

这样必然会导致很多依赖被重复安装，于是就有了 hoist 和打平依赖的操作:

  - package   
  - package.json   
  - node_modules   
     - util_e@1.0.0   
     - lib_a   
     - lib_b   
     _ lib_c   
       - node_modules <- util_e@2.0.0   
     - lib_d   
       - node_modules <- util_e@2.0.0

但是这样也只能提升一个依赖，如果两个依赖都提升了会导致冲突，这样同样会导致一些不同版本的依赖被重复安装多次，这里就会导致使用 npm 和 yarn 的性能损失。
如果是 pnpm 的话，这里因为依赖始终都是存在 store 目录下的 hard links ，一份不同的依赖始终都只会被安装一次，因此这个是能够被彻彻底底的消除的。

项目中的相关场景实践和常见问题

npm link

适用场景：本地调试 npm 模块，将模块链接到对应的业务项目中运行使用方法：假如我们需要把模块 pkg-a 链接到主项目 App 中，首先在 pkg-a 根目录中执行 npm link，然后在 App 根目录中执行 npm link pkg-a 即可。调试完可以使用 npm unlink 取消关联。原理：npm link 通过软连接将 pkg-a 链接到 node 模块的全局目录和可执行文件中，实现 npm 包命令的全局可执行。

npx

适用场景：在 npm 5.2.0 版本之后，npm 内置了 npx 的包。npx 是一个简单的 cli 工具，可以帮助我们快速的调试，还可以让我们在不通过 npm 安装包的前提下执行一些 npm 包。

使用方法：
Before:一般情况下，如果我们想使用 es-lint, 会先通过 npm install es-lint, 然后在项目根目录执行 ./node_modules/.bin/es-lint your_file.js 或者通过 package.json 的 npm scripts 调用 eslint。
After:npx es-lint your_file.js
原理：npx 在运行时会自动去 ./node_moudles/.bin 和环境变量寻找命令

是否提交 lock.json 到代码仓库

前面我们提到 yarn 带来了 .lock 文件的机制，使得在任何环境下执行 install，都能得到一致的 node_modules 安装结果。但是是否需要提交 lockfiles(package-lock.json/yarn.lock) 到代码仓库呢？
npm 官方文档 ^[2]是建议把 package-lock.json 文件提交到代码仓库的。在多人协作的项目中，这样做确实没有问题。但是如果开发的是库，在 npm publish 的时候最好忽略 lockfiles。因为库一般是被其他项目依赖的，在不使用 lockfiles 的情况下，由于新版 npm 和 yarn 的 hoist 机制，可以复用住项目已经加载过的包，减少依赖重复和体积。
但是存在这样一种现象：即使在一些发布时忽略 lockfiles 的库中，在主项目顶层存在相关依赖包的前提下，最终生成的 lockfile 仍然没复用主项目的包。这是为什么呢？原因是库的依赖包版本和主项目存在的依赖包版本不一致。具体看下图：主项目的 yarn.lock 中显示 browser 这个包依赖了 @babel/runtime@7.0.0

主项目 node_modules 顶层的 @babel/runtime 版本为 7.10.1

知道了原因，那么如何减少库项目的依赖项呢。到这里，解决方案也就呼之欲出了：

库项目尽量使用和主项目版本一致的依赖包
在库项目 package.json 的 “peerDevpendencies” 字段中声明主项目已有的依赖包

合入其他分支代码后编译报错

相信很多同学都遇到过和我一样的问题：当自己的 feat 分支代码合入 master 或者业务班车分支的代码时，重新 yarn 时，有时候会编译失败，报大量 "can't resolve module xxx"的错误。这种错误有很多情况是依赖版本不一致的问题，但是又极其难以定位，令人头痛。那么此时有另外一个思路，那就是从 master 拉一个最新的分支再进行合入。
但更好的解决方式是：建议在日常开发过程中，定时合入 master 代码，一方面可以合入最新的 feat，另一方面可以避免长时间不合入，最后在上线阶段合入代码，可能出现大量冲突，解决不当或遗漏而造成的编译问题。同时也可以考虑将工具升级为 pnpm，以解决潜在的“幽灵依赖”和“依赖嵌套”问题，同时带来性能上的提升。

参考资料

[1]

pnpm: 最先进的包管理工具: https://bytedance.feishu.cn/docs/doccngSUrvF0qPVmBE1rq1iPZQf

[2]

npm官方文档: https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json

中台工具产品方法论

Thu, 28 Apr 2022 17:50:15 CST

背景

做中台工具产品不是一件容易的事情，需要对接上层所有业务方，做的慢业务方不满意，做的快业务方未必会给好的评价。

属于容易背锅，细节极其多，用户反馈建议多，但又难以出成绩和证明自己做的好。

场景

虚构一些场景，大家肯定都遇到过。

场景1

老板：XX功能我觉得不错，做了吗？

产品经理：收到，我研究下。

几天之后……

老板：XX和XX等N个功能都不错，马上排期做下。

产品经理：收到。

评价：产品经理是初级的工具人，执行命令，最终老板大概率不会满意，因为产品功能都是老板自己提的，上线未必效果好。

老板会认为自己是个有想法的人，同时认为产品经理没有想法，产品经理挺冤枉，干的比黄牛累。出了成绩是老板高瞻远瞩，没有成绩是没执行好。

对话通常以被动接受信息，缺乏有效的反馈和互动。收集大量需求导致执行慢，可能会被技术同事认为是战斗力等于5的渣渣。

场景2

老板：XX功能我觉得不错，做了吗？

产品经理：收到，我研究下…（几小时之后）这个功能挺好，和技术同事工作量比较大，会在下一个版本中增加。

评价：高级工具人，收到信息之后，能够给予执行的时间点，对工作量和项目节奏有一定把控能力。

场景3

老板：XX功能我觉得不错，做了吗？

产品经理：研究过了，用户给我们反馈过，XX竞品也有这个功能。我们已经在当前规划中了，计划在下一个版本中增加。

评价：有一定自主工作意识，对产品有一定思考，老板只是信息源之一，能从用户反馈和竞品等渠道提炼产品需求，有主动找信息和需求的能力。但很少反驳别人的想法，对事情的优先级把控能力还不够。

场景4

老板：XX功能我觉得不错，做了吗？

产品经理：研究过了，会放在下一个版本中增加。我们当前版本是主要提升另外一个模块的易用性，用户意见比较大，是影响产品NPS的主要因素，上线之后预期会影响xx%比例的用户。而你提的XX功能属于体验优化，我们会在下一个版本中迭代。

评价：有优先级掌控意识，在和老板的对话中体现了自身的专业性，体现了用户反馈、NPS和数据来驱动产品迭代，在产品标准上和老板拉齐认知。产品的目的在于提升NPS等，不局限于讨论某个功能点。即使拒绝了老板需求，老板也会认为产品经理有自己的思考。

但是缺陷在于，产品经理的眼光只能看到未来1-2个月的规划，对长期规划还缺乏把控。

场景5

老板：XX功能我觉得不错，做了吗？

产品经理：已经在规划当中了，房产中介对这个需求有很强需求，而其他类型的用户需求不高。我们今年的目标是满足电商等前5的用户诉求，这些行业对公司贡献大，我们最近做了调研发现电商等用户对XX功能有很强的诉求，提炼了N个需求来，比如XX……

评价：对全局有掌控，对公司战略目标有理解，基于战略目标拆解出了自己的目标，能够主导项目迭代。

老板满意，合作方满意，技术同事跟着干活能自己做事情的价值，对产品经理认可度很高，不会带着项目组做无用功。

场景6

老板：XX功能我觉得不错，做了吗？

产品经理：需求可以做，功能产品侧都可以做，细节是永远做不完的，但是缺乏方向性。我认为SaaS产品的核心目标是收入，当前提升收入的抓手我们还没有明确。通过数据分析、用户访谈和专家访谈，我觉得有xx场景是可以深挖的，这些行业还有50%+增量收入，期望与其他团队能联动在未来半年中达成这项目标。而你提的XX功能，不是典型的应用场景。

评价：这样的产品经理已经可以做业务负责人了，有完善的方向判断能力和产品方法论，有能力带领项目组走向成功。

而老板是资源，说服老板投入更多精力在某个方向，老板会对产品经理更为信任，提功能细节的次数会很少，更多是讨论项目方向，输入外界信息来帮助产品经理做判断。

做产品，超出用户预期，他们才会满意。做产品经理也是一样，认知超越周围的同事，大家才会认可你。

解放双手！推荐一款阿里开源的低代码工具，YYDS！

Tue, 19 Apr 2022 01:31:26 CST

之前分享过一些低代码相关的文章，发现大家还是比较感兴趣的。之前在我印象中低代码就是通过图形化界面来生成代码而已，其实真正的低代码不仅要负责生成代码，还要负责代码的维护，把它当做一站式开发平台也不为过！最近体验了一把阿里开源的低代码工具 LowCodeEngine，确实是一款面向企业级的低代码解决方案，推荐给大家！

SpringBoot实战电商项目mall（50k+star）地址： https://github.com/macrozheng/mall

LowCodeEngine简介

LowCodeEngine是阿里开源的一套面向扩展设计的企业级低代码技术体系，目前在在Github上已有 4.7K+Star。这个项目大概是今年2月中旬开源的，两个月不到收获这么多Star，确实非常厉害！

LowCodeEngine主要具有如下特性：

提炼自企业级低代码平台的低代码引擎，奉行高度可扩展、最小内核、最强生态的设计理念；
部署简单，基本上就是开箱即用，拥有完善的物料体系、功能强大的设置器、丰富的插件等；
可视化编辑器具有完善的工具链，支持物料体系、设置器、插件等生态元素；
强大的扩展能力，已支撑近 100 个各种垂直类低代码平台；
使用 TypeScript 开发，能生成基于React的前端代码。

下面是LowCodeEngine使用过程中的一张效果图，功能还是很强大的！

搭建低代码平台

接下来我们将使用LowCodeEngine搭建一个低代码开发平台，仅需5分钟，可以说是开箱即用！

首先我们需要想下载LowCodeEngine编辑器的示例代码，下载地址：https://github.com/alibaba/lowcode-demo

下载成功后解压到指定目录，安装此项目需要使用 Node.js和 npm，确保已经安装完毕，由于依赖中有些 npm源无法访问，这里推荐使用 cnpm来安装，先使用如下命令安装 cnpm；

  npm install -g cnpm --registry=https://registry.npmmirror.com

cnpm安装成功后，进入解压目录使用如下命令安装依赖；

  cnpm install

依赖安装完成后，使用 npm start命令启动项目；

项目运行成功后将运行在 5556端口上，访问地址：http://localhost:5556

使用低代码平台

之前在我的开源项目 mall中有个品牌管理功能，接下来我们将使用LowCodeEngine来实现下它，看看低代码开发有何神奇之处！

目标效果

mall项目中的品牌管理功能效果如下，这里使用低代码简单实现下品牌列表功能。

组件库

首先我们从 组件库中选择 查询筛选组件，通过拖拽的形式插入编辑区中；

然后选中 查询筛选组件，通过右侧的 设置器进行设置；

可以点击组件左侧的 编辑按钮对组件进行详细设置，比如说组件外观和输入提示等；

接下来再拖拽一个 高级表格组件到编辑器中去；

同样选中 高级表格组件可以对表格进行设置，我们可以通过 数据列来设置需要显示的数据。

数据源

由于表格中的数据需要访问接口来获取，这里我们可以通过 数据源功能来实现，这里我们调用演示环境的API，填入请求参数即可，值得注意的是由于数据列表在 data.list属性中，我们需要定制下请求成功的处理函数；

接下来选中 高级表格组件，修改 表格数据源，选择 表达式输入，填入我们之前设置的 数据源ID即可；

然后修改 数据列信息，将每个数据列 数据字段修改为JSON数据中对应的属性即可。

预览及出码

如果想查看搭建的页面效果的话，点击右上角的 预览按钮即可；

下面是由低代码生成的页面预览效果；

如果你想获取工具生成的代码的话，点击右上角的 出码按钮即可，支持直接下载。

其他功能

如果你想自定义一些函数的话，可以通过 源码面板进行自定义；

通过 大纲视图我们可以查看整个界面的结构。

总结

今天体验了一把阿里开源的低代码开发工具，功能确实很强大。但是低代码并不意味着可以不写代码了，想用好低代码工具还得熟悉工具生成的代码。LowCodeEngine目前仅支持生成React的前端代码，所以想要实现更为复杂的业务系统，还得熟悉React。如果有小伙伴想更深入了解低代码的概念，推荐看下这篇文章《阿里低代码引擎和生态建设实战及思考》。

参考资料

项目地址：https://github.com/alibaba/lowcode-engine
项目官网：https://lowcode-engine.cn/
操作指南：https://www.yuque.com/lce/usage

Calibre 5.36 发布，功能强大的开源电子书工具

Sun, 06 Feb 2022 09:45:55 CST

Calibre 开源项目是 Calibre 官方出的电子书管理工具。它可以查看，转换，编辑和分类所有主流格式的电子书。Calibre 是个跨平台软件，可以在 Linux、Windows 和 macOS 上运行。

Calibre 5.36.0 正式发布，此次更新内容如下：

新功能

编辑元数据对话框：允许通过「首选项->外观->编辑」元数据来控制哪些自定义列出现在这个对话框中。
编辑元数据对话框：允许在 "All on 1 tab" 模式下手动调整对话框的各个部分的大小。
编辑书籍：拼写检查，更新捆绑的英语和西班牙语词典
BibTeX 目录：支持自定义列等标签

错误修正

Amazon 元数据下载：修复评论中的段落被合并的问题
Amazon.de 元数据下载：修复某些书籍的出版日期和系列信息没有被获取的问题
邮件发送：修复通过 Hotmail 发送电子邮件从本周开始无法工作的问题，因为微软改变了 SMTP 服务器的名称
不要删除波兰语标题的文章
电子书查看器：当使用朗读时，在暂停或停止朗读前不会自动查找高亮显示的单词
电子书阅览器：修复打印时 Ctrl+p 快捷键不起作用的问题
查看特定格式且文件丢失时显示错误
编辑书籍：修复以非字开头/结尾的类的重命名不工作的问题
编辑书籍：预览面板：修复在 macOS 上行末的连字符被呈现为方框的问题
修复在图像缩小到适合大小时，修剪图像对话框中显示的不正确的选择尺寸
编辑书籍：修复从另一个编辑器实例粘贴文件时，如果已存在相同名称的文件，则导致失败的问题。

更多详情可查看： https://calibre-ebook.com/whats-new

比较Flyway与Liquibase两大数据库迁移工具_Java

Sun, 16 Jan 2022 12:14:03 CST

众所周知，对于那些使用着关系型数据库引擎的各类应用程序而言，数据库迁移工具的选用是至关重要的。它们不但能够让各种复杂且重复的过程更加自动化，而且可以让我们更加轻松且准确地完成各种大型的迁移任务。

下面，我将对两种最常见的开源迁移工具--Flyway和Liquibase，进行介绍与比较，以方便您在实际项目中做出合理的选择。

Flyway的介绍

Flyway是由Redgate公司带来的一款开源式的数据库迁移工具。该工具注重规则上的简约性，而非繁琐的配置。

目前，它能够支持诸如Postgres、Oracle、SQL Server、DB2、H2、以及MariaDB等大多数主流数据库引擎。同时，Flyway还可以支持诸如：Amazon RDS、Google Cloud SQL、以及Heroku等基于云端业务的数据库服务。

该工具所用到的脚本既可以用纯SQL(支持多种SQL语法)，又能够用Java(主要用于更复杂的转换)来进行编写。同时，它既带有命令行客户端，又提供支持Maven和Gradle的插件。此外，它的Java API，还适用于Android系统。

Flyway的Evolve非常适用于习惯了使用.NET和C#的用户。因此，如果您对其有兴趣的话，请查看文末列出的它在GitHub上的链接页面。

Liquibase的介绍

作为于2006年推出的、可用于数据库迁移的开源类工具，Liquibase是基于变更日志(changelog)和变更集(changesets)文件的相关概念实现的。这些文件可以由SQL、XML、YAML、以及JSON编写而成。它们通过存储那些针对数据库结构的更改，以便将其应用到任何其他数据库的实例上。

目前，Liquibase支持的数据库种类包括：Postgres、Oracle、DB2、H2、MariaDB、SQL Server、以及SQLite等。同时，它还支持诸如：Azure SQL、Amazon RDS、以及Amazon Aurora等许多基于云的数据库。

您可以使用诸如Maven、Gradle、甚至是Ant之类的构建工具，从Shell中运行Liquibase的迁移脚本。此外，您可以一次生成纯粹的SQL查询，以便您的DBA、Ops、DevOps团队、或负责数据库的任何人，可以进一步执行此类查询。

有了对于上述两种工具的基本概念，下面让我们来讨论一下它们之间的相同点和不同之处。

Flyway和Liquibase之间的相似之处

在某种程度上，两者都属于开源的，并且能够免费提供各种功能。当然它们也都具有提供更多高级功能的付费版本。
两者都可以使用简单、传统的SQL，来编写出迁移脚本。
两者都能完美地“面向Java”，并且都内置了针对Maven和Gradle之类基本构建工具的支持，以及可以与诸如：Spring Boot等最常见的Java框架相集成。
两者都可以从命令行处运行简单的shell脚本。
虽然两者支持的数据库版本和驱动程序，可能存在着一些细微的差异，但是从整体而言，它们能够支持的数据库品种大致相似。
在处理数据库更改时，两者用到了相同的方法，即：基于迁移的数据库交付。
两种工具都实现了由Martin Fowler提出和诠释的数据库重构(Evolutionary database) 的概念(详见本末链接)。

Flyway和Liquibase之间的不同之处

下面，让我们从横跨多个数据库引擎来运行相同脚本的角度，来讨论Flyway和Liquibase的不同之处。

首先，我们会碰到的一个实际问题是：如何针对实例生产差异(diff)。您会发现，我们可以直接使用Liquibase来生成相关差异;却无法使用Flyway来实现，而且即便是其付费版本也无法达到。这便是我们往往在项目中选择Liquibase，而非Flyway的主要原因之一。

其次，我们来看看Java客户端。Flyway拥有原生的Java API，它可以帮助我们进行诸如BLOB和CLOB的更改、以及高级批量数据的修改等较为复杂的迁移。这些功能在某些受限制的迁移场景中，是非常实用的。因此这反过来成为了用户选用Flyway，而非Liquibase的主要原因之一。

接着，我们来讨论两种工具是如何处理回滚的。我们设置Liquibase的changelog文件相对比较容易。实际上，changelog的XML结构甚至已经为回滚代码定义好了一个特殊的字段。而Flyway仅在其付费版本中提供了回滚处理的服务。因此，如果您不介意使用付费工具的话，可以考虑使用Flyway的相关功能。当然，据说Liquibase的付费版本，对于不同类型的回滚，具有更完备的支持。您如果有时间和精力的话，可以去试用一下。

最后，让我们来看看更改顺序的管理。对此，两种工具有着完全不同的处理方法。Flyway采取的是线性数据库版本控制的概念。这意味着，应用更改的顺序，取决于迁移脚本的名称顺序。实际上，Flyway的迁移脚本有着一个完整的命名规则。如果您希望它能够按照预期执行的话，就必须遵循该规则。而在Liquibase中，数据库实例的更改顺序，基于整个changelog文件中的特定更改位置。也就是说，如果您将更改按照某种特定的顺序放在changelog中的话，那么对于数据库的更改也将以完全相同的顺序执行并完成。

小结

综上所述，我们对Flyway和Liquibase两种数据库迁移工具进行了综合比较。总的说来，Flyway的优点在于，其迁移脚本更具有可读性。如果您非常熟悉SQL的话，那么它用起来更加便捷、更加顺手。当然，它的缺点是无法实现跨平台的使用。而Liquibase正好相反，其优点在于可以跨平台被使用，其不足之处在于，由于它功能强大，因此我们可能需要花费一定的精力，去维护它的迁移脚本。

容器安全扫描工具推荐 (insights.thoughtworks.cn)

Tue, 04 Jan 2022 00:00:00 CST

在现代软件开发中，我们会使用一些公共镜像作为基础镜像来快速构建我们的应用镜像，并将其部署到生产环境中。

随着越来越多的应用程序被容器化，容器安全也随之变得越来越重要。在项目的流水线中，我们可以使用漏洞扫描器进行扫描并提前获得反馈，实现 “安全左移” ，也可以更好的实践敏捷。

基于容器的应用程序的安全痛点

现在，我们使用先进的技术来构建我们的应用程序，如 NodeJS、 Java 和 Kotlin 等，然后将代码库存储在托管的 Git 平台上，如 GitHub、Gitlab 等。代码库由我们的业务代码和依赖关系组成；对于依赖项，我们可以使用专业的扫描工具来确保安全，比如 NodeJS 的 npm audit , GitHub 的 Dependabot；至于我们的业务代码，可以使用其他的一些安全工具可以扫描，比如 SoneQube 等。

因此，对于依赖（ Dependencies）和我们的业务代码，这些都在我们的控制之下，我们可以确保应用程序的安全性，并且在 Pipeline 上获得快速反馈；同时在我们将应用程序部署到生产环境之前可以通过使用各种工具建立信心。但是，通常情况下我们的应用程序运行的系统环境是不受我们控制的，可能存在潜在的安全漏洞。在这我们可以换位思考一下，如果我们不能保证我们的应用程序运行的系统的环境安全，就会导致各种各样意想不到的问题，如黑客攻击、用户信息泄露、财产损失，更会对公司的声誉造成损害。所以，确保我们产出物（Artifact）的安全是很重要的。

保持容器镜像安全的两个方案

方案1：在镜像注册表中定期扫描

通过这种方式，我们需要为镜像注册表添加一个安全扫描程序，扫描程序可以是一个定时任务（Cron Job）作业，也可以是由特定的人触发的可执行操作。

如果是一个定时任务，它将在特定时刻由定时任务自动触发。例如，Docker Hub 会在特定的时间扫描他们的官方注册表，当有任何漏洞被扫描出来时，它会向镜像维护者发送报警信息。

方案2：将扫描工具集成到 Pipeline 中

另一种方法是在 Pipeline 上对镜像产物进行扫描，这样更加简单高效。当我们将代码推送到代码存储库时， Pipeline 将自动执行扫描镜像的命令。因为 Pipeline 每次都是无差别地执行，所以我们可以发现任何安全问题并及时报警修复。

现在，越来越多的团队或公司使用敏捷来开发他们的项目。如果我们能够尽早地发现任何安全问题或者漏洞，我们就可以在产品发布之前降低产品的安全风险。 Pipeline 是确保每一行代码和基础运行环境的安全性是的最好方法之一，因为它可以在提交代码时自动执行。

容器安全扫描工具对比

针对上述解决方案，我们调查了 Trivy、Claire、Anchore Engine、Quay、Docker hub 和 GCR 等几种扫描工具，从不同维度进行对比。

参考 Trivy 官网

首先，我们可以将这些扫描工具按照其执行的环境简单分类；因为 Docker Hub、GCR 和 Quay 是需要在服务端也就是容器注册中心运行的，所以适合方案1； Trivy、Clair 和 Anchor Engine 可以在 Pipeline 上工作，所以适合解决方案2。

对于第一个维度：OS Package，这些所有的扫描工具都可以做到，但是对于第二个维度：Application dependencies，只有 Trivy 和 Anchore Engine 可以做到，对于第五个维度: Suitable for CI, 只有前三个符合条件。

对于漏洞数据库的更新，Clair 会定期从一组配置的源中获取漏洞元数据库（Vulnnerability Database），并将数据存储在其数据库中，只要不获取最新的漏洞元数据，每次执行都用之前的漏洞数据库，漏洞数据库的时效性有点差。 Trivy 和 Anchore Engine 则是每次运行都将下载最新的漏洞数据库并将其缓存在本地文件中，当扫描工具再次运行时，它将检查并更新数据库以保持数据库为最新状态。

同时，对于 Trivy、Clair 和 Anchore Engine，这三者的社区非常活跃，所以我们不能用没有人来帮你解决你的问题来评判；而且作为一种工具，它必须易于使用并且有良好的文档可供参考。经过调研，发现 Trivy 的文档非常详细，非常友好，而且 Trivy 的使用方式更加友好，比如我们可以过滤掉（.trivyignore）你指定的漏洞，对于最新发现的漏洞，官方没有给出修复版本，这时候我们就可以忽略这个漏洞继续构建，但 Anchore Engine 做不到。

2020年3月16日，领先的云原生应用和基础设施安全平台供应商 Aqua Security 宣布，其开源的 Trivy 漏洞扫描器将作为一个集成选项添加到其使用的云原生平台、CNCF 的 Harbor 注册表和 Mirantis Docker Enterprise 中。你可以在这里找到这篇文章。

Trivy集成到流水线中的使用方法

Trivy 支持多种扫描方式，如扫描容器镜像、Git 仓库和文件系统等；下面，我们使用 GitHub Actions 以 Docker 运行 Trivy 扫描构建好的镜像产出物来展示 Trivy 的强大之处，下面是 GitHub Actions 的部分代码：

   - name: Trivy scanner
  run: |
         docker run --rm -v 
/var/run/docker.sock:/var/run/docker.sock \
           aquasec/trivy image --severity HIGH,CRITICAL 
--exit-code 1 dashboard:${{ github.sha }}

在这需要对以下几个参数做特别说明：

-v /var/run/docker.sock:/var/run/docker.sock 如果想扫描本地主机上的镜像，需要挂载 docker.sock
--severity 设置要扫描的漏洞级别
--exit-code 发现漏洞时 Trivy 的退出状态(默认值：0)；在 Pipeline 中，如果将该值设置为1，且有漏洞被发现，则 Pipeline 将退出，而不会继续运行。如果将其设置为0，则 Pipeline 将继续运行，但会报告结果。所以，如果你想在发现漏洞后阻止 Pipeline 继续执行，可以设置它为1。

想了解更多关于参数和使用方法的信息，请访问 Trivy 的官方网站： https://github.com/aquasecurity/trivy。

总结

无论你在哪里，安全都是一个非常重要的问题。我们可以将 “安全左移（Shift Left Security）”，这样就可以减少生产环境中的安全风险；对于扫描工具 Trivy 来说，它对于保证镜像的安全性非常有用，它不仅可以扫描镜像，还可以扫描 Git 仓库，文件系统等。
最后，非常感谢同事张思楚、王亦晨和邢砚敏等人的大力支持和指导，在他们热心帮助和辛苦付出之下才有了这篇文章。

[原]btrace 开源！基于 Systrace 高性能 Trace 工具

Thu, 30 Dec 2021 15:24:06 CST

介绍

btrace（又名 RheaTrace）是抖音基础技术团队自研的一款高性能 Android Trace 工具，它基于 Systrace 实现，并针对 Systrace 不足之处加以改进，核心改进点如下。

效率提升：编译期间为 App 方法自动注入自定义事件，并提供高效、灵活配置规则。
性能提升：改进 Systrace 文件实时写 atrace 数据方式，性能提升最大 400 % 以上。
实用性提升：额外提供更详细 IO 等数据，大幅提升方法耗时归因效率；使用独创方案彻底来解决方法因执行异常引起 trace 数据不闭合问题。

项目地址：

https://github.com/bytedance/btrace

目前字节跳动已有多款 App 接入，包括抖音、TikTok、今日头条、幸福里等均已接入 RheaTrace，并为其体验优化提供强有力支持。借助 RheaTrace 将为您的 App 带来极致流畅体验，RheaTrace 使用效果如下（因保密原则，每个方法用 ID 表示）。

Systrace 简介

如果我们使用过 Systrace 分析应用性能，我们都知道 Systrace 提供 Category 配置让用户决定采集哪些系统 atrace 数据，如下命令，从 sched 开始后续是不同类别的 atrace 数据。

   python systrace.py -o mynewtrace.html sched freq idle am wm gfx view \
    binder_driver hal dalvik camera input res

atrace 的数据类型见下图：

其中，用户空间 atrace 类型包括应用层自定义 Trace 事件、系统层 gfx 渲染相关 Trace、系统层锁相关 Trace 信息等，其最终都是通过调用 Android SDK 提供 Trace.beginSection 或者 ATRACE_BEGIN 记录到同一个文件 /sys/kernel/debug/tracing/trace_marker 中。此节点允许用户层写入数据，ftrace 会记录该写入操作时间戳。当用户层发生函数调用时，ftrace 可以记录被跟踪函数的运行时间。atrace 若需记录用户层某一 trace 类型，只需激活对应 TAG 类型即可。如选择 gfx，则会激活 ATRACE_TAG_GRAPHICS，并将渲染事件记录到 trace_marker 文件中。

内核空间的数据主要是一些补充分析数据，如 freq、sched、binder 等，常用 CPU 调度相关信息包括：

CPU 频率变化情况。
任务执行情况。
大小核调度情况。
CPU Boost 调度情况。

关于图中一些标签释义。

CPU 使用率：右边柱状图越高，表明使用率越高。
CPU 序号：标识 CPU 核心序号，表示该设备有 8 个核心，编号 0 -7。
CPU 频率：右边对应的粉色柱状图表示其频率变化趋势。
调度任务：标识在该 CPU 核心上正在运行的任务，点击任务可查看其 ID、优先级等信息。

这些信息 App 可以直接读取 /sys/devices/system/cpu 节点下相关信息获得，而另外一部分标识线程状态信息则只能通过系统或者 adb 才能获取，且这些信息不是统一节点控制，需要激活各自对应的事件节点，让 ftrace 记录下不同事件的 tracepoint。内核在运行时，根据节点的使能状态，会往 ftrace 缓冲中记录事件。

例如，激活线程调度状态信息记录，需要激活类似如下相关节点。

   events/sched/sched_switch/enable
events/sched/sched_wakeup/enable

激活后，则可以获取到线程调度状态相关的信息，比如：

Running: 线程在正常执行代码逻辑。
Runnable: 可执行状态，等待调度，如果长时间调度不到，说明 CPU 繁忙。
Sleeping: 休眠，一般是在等待事件驱动。
Uninterruptible Sleep: 不可中断的休眠，需要看 Args 描述来确定当时状态。
Uninterruptible Sleep - Block I/O: IO 阻塞。

最终，上述两大类事件记录都汇集到内核态同一缓冲中， Systrace 工具是通过指定抓取 trace 类别等参数，然后触发手机端 /system/bin/atrace 开启对应文件节点信息，接着 atrace 会读取 ftrace 缓存，生成只包含 ftrace 信息的 atrace_raw 信息，最终通过脚本转换成可视化 HTML 文件，大致流程如下。

RheaTrace 揭秘

本章节将从 RheaTrace 重点优势一一介绍。

Systrace 源码分析

Systrace 提供 Trace#beginSection(String) 和 Trace.endSection() 采集 atrace 数据，首先，我们大致了解下 atrace 工作原理，以 android.os.Trace#beginSection 作为分析入口。

   public static void beginSection(@NonNull String sectionName) {
    if (isTagEnabled(TRACE_TAG_APP)) {
        if (sectionName.length() > MAX_SECTION_NAME_LEN) {
            throw new IllegalArgumentException("sectionName is too long");
        }
        nativeTraceBegin(TRACE_TAG_APP, sectionName);
    }
}

android.os.Trace#beginSection 会调用 nativeTraceBegin 方法，该方法实现参考 frameworks/base/core/jni/android_os_Trace.cpp。

   static void android_os_Trace_nativeTraceBegin(JNIEnv* env, jclass,
        jlong tag, jstring nameStr) {
    withString(env, nameStr, [tag](char* str) {
        atrace_begin(tag, str);
    });
}

atrace_begin 方法实现参考 system/core/libcutils/include/cutils/trace.h。

   #define ATRACE_BEGIN(name) atrace_begin(ATRACE_TAG, name)
static inline void atrace_begin(uint64_t tag, const char* name)
{
    if (CC_UNLIKELY(atrace_is_tag_enabled(tag))) {
        void atrace_begin_body(const char*);
        atrace_begin_body(name);
    }
}

atrace_begin_body 方法实现参考 system/core/libcutils/trace-dev.cpp。

   void atrace_begin_body(const char* name)
{
    WRITE_MSG("B|%d|", "%s", name, "");
}

atrace_begin_body 最终实现在宏 WRITE_MSG 实现，代码如下：

   #define WRITE_MSG(format_begin, format_end, name, value) { \
    ...
    write(atrace_marker_fd, buf, len); \
}

通过 WRITE_MSG 实现，可知，atrace 数据是实时写入 fd 为 atrace_marker_fd 的文件中，如果多线程同时写入，则会出现锁问题，导致性能损耗加大。

RheaTrace 核心优势

效率提升

RheaTrace 会在 App 编译期间自动插入 Trace 跟踪函数，大大提高效率。针对不同 Android Gradle Plugin 版本，我们支持 Proguard 之后插桩，这样可以减少 App 方法插桩量，同时也过滤 Empty、Set/Get 等简单方法。

思路基于 matrix-gradle-plugin 大量改造实现。

   rheaTrace {

   compilation {
      //为每个方法生成唯一 ID，若为 true，Trace#beginSection(String) 传入的是方法 ID。
      traceWithMethodID = true
      //决定哪些包名下的类您不需要做性能跟踪。
      traceFilterFilePath = "${project.rootDir}/rhea-trace/traceFilter.txt"
      //一些特定方法保持 ID 值固定不变。
      applyMethodMappingFilePath = "${project.rootDir}/rhea-trace/keep-method-id.txt"
   }
   runtime {
        ......
   }
}

为减少包体积、性能影响，我们也借鉴 matrix 慢函数思路，支持为每个函数生成唯一 ID， traceWithMethodID 为 true， Trace#beginSection(String)传入的是方法 ID，不再是方法名。有时候我们想某些方法 ID 固定不变，同样借鉴 matrix 慢函数思路，我们提供 applyMethodMappingFilePath 配置规则文件路径。
为进一步减少 App 方法插桩量，我们提供 traceFilterFilePath 文件配置让您决定哪些包、类、方法不做自定义事件跟踪，关于其用法请参考 RheaTrace Gradle Config。

性能提升

在 Systrace 概述中，我们了解到 atrace 数据是实时写入文件，且存在多线程同时写入带来的锁问题。因此，我们采取策略是拿到 atrace 文件 fd，在 atrace 数据写入前，先将其写至 LockFreeRingBuffer内存中，然后再将循环读取内存中 atrace 数据，写入我们定义的文件中。

首先我们通过 dlopen 获取 libcutils.so 对应句柄，通过对应 symbol 从中找到 atrace_enabled_tags 和 atrace_marker_fd 对应指针，设置 atrace_enabled_tags 用以打开 atrace，代码实现片段如下。

   int32_t ATrace::InstallAtraceProbe() {
  ......
  {
    std::string lib_name("libcutils.so");
    std::string enabled_tags_sym("atrace_enabled_tags");
    std::string marker_fd_sym("atrace_marker_fd");

    ...
    ...
    atrace_marker_fd_ = reinterpret_cast<int*>(
        dlsym(handle, marker_fd_sym.c_str()));

    if (atrace_marker_fd_ == nullptr) {
      ALOGE("'atrace_marker_fd' is not defined");
      dlclose(handle);
      return INSTALL_ATRACE_FAILED;
    }
    if (*atrace_marker_fd_ == -1) {
      *atrace_marker_fd_ = kTracerMagicFd;
    }
  dlclose(handle);
  return OK;
  }

思路参考 profilo#installSystraceSnooper，本文不做过多介绍。

接着，通过 PLT Hook libcutils.so 中 write、write_chk 方法，判定该方法传入 fd 是否与 atrace_marker_fd 一致，若一致，则将 atrace 数据写入我们定义的文件中。

   ssize_t proxy_write(int fd, const void* buf, size_t count) {
  BYTEHOOK_STACK_SCOPE();

  if (ATrace::Get().IsATrace(fd, count)) {
    ATrace::Get().LogTrace(buf, count);
    return count;
  }
  ...

  ATRACE_END();
  return ret;
}

有时候，我们可能仅需要关注主线程 atrace 数据，如果能将子线程 atrace 数据过滤掉，那么整体性能将进一步提升。一种很简单的思路，就是将 Trace#beginSection(String) 包装一层，如下代码片段。

   static void t(String methodId) {
    if (!isMainProcess) {
        return;
    }
    if (mainThreadOnly) {
        if (Thread.currentThread() == sMainThread) {
            Trace.beginSection(methodId);
        }
    } else {
        Trace.beginSection(methodId);
    }
}

该方法仅能过滤我们为 App 方法插桩的 atrace 数据，系统层 atrace 数据无法过滤。为更彻底实现仅采集主线程数据，我们通过 PLT Hook 代理 atrace_begin_body 和 atrace_end_body 实现，在该方法进入前，判断当前线程 id 是否为主线程，如果不是，则不记录该条数据，代码实现片段如下。

   void proxy_atrace_begin_body(const char *name) {
    BYTEHOOK_STACK_SCOPE();
    if (gettid() == TraceProvider::Get().GetMainThreadId()) {
        BYTEHOOK_CALL_PREV(proxy_atrace_begin_body, name);
    }
}

void proxy_atrace_end_body() {
    BYTEHOOK_STACK_SCOPE();
    if (gettid() == TraceProvider::Get().GetMainThreadId()) {
        BYTEHOOK_CALL_PREV(proxy_atrace_end_body);
    }
}

针对降低性能损耗，RheaTrace 提供编译配置供用户选择，针对不同使用场景配置合理参数。

   rheaTrace {
    ......

    runtime {
        mainThreadOnly false
        startWhenAppLaunch true
        atraceBufferSize "500000"
    }
}

上述配置释义如下。

mainThreadOnly：为 true 表示仅采集主线程 trace 数据。
startWhenAppLaunch：是否 App 启动开始就采集 trace 数据。
atraceBufferSize：指定内存存储 atrace 数据 ring buffer 的大小，如果其值过小会导致 trace 数据写入不完整，若您抓取多线程 trace 数据，建议将值设为百万左右量级；最小值为 1 万，最大值为 5 百万。

实用性提升

针对已有的 atrace 数据，额外拓展 IO 等信息；另外为通过 Python 脚本彻底解决方法因执行异常导致 trace 数据闭合异常问题，保证每个方法 trace 数据的准确性。

目前我们基于 JVMTI 方案，在 Android 8.0 及以上设备可以获取类加载以及内存访问相关 trace 数据，目前仅支持编译类型为 debuggable 的 App，目前处于实验功能，本文暂先不过多介绍。

IO 数据拓展

背景简介

在抖音启动性能优化时，我们曾统计冷启动的耗时，其中占比最长的是进程处于 D 状态（不可中断睡眠态，Uninterruptible Sleep ，通常我们用 PS 查看进程状态显示 D，因此俗称 D 状态）时间。此部分耗时占总启动耗时约 40%，进程为什么会被置于 D 状态呢？处于 uninterruptible sleep 状态的进程通常是在等待 IO，比如磁盘 IO，其他外设 IO，正是因为得不到 IO 响应，进程才进入 uninterruptible sleep 状态，所以要想使进程从 uninterruptible sleep 状态恢复，就得使进程等待 IO 恢复，类似如下。

但在使用 Systrace 进行优化时仅能得到如上内核态的调用状态，却无法得知具体的 IO 操作是什么。

方案介绍

因此，我们专门设计一套获取 IO 耗时信息方案，其包括用户空间和内核空间两部分。

一是在用户空间，为采集所需 IO 耗时信息，我们通过 Hook IO 操作标准函数簇，包括 open，write，read，fsync，fdatasync 等，插入对应 atrace 埋点用于统计对应的 IO 耗时，以 fsync 为例。

其对应 hook 代码逻辑如下：

   int proxy_fsync(int fd) {
  BYTEHOOK_STACK_SCOPE();
  ATRACE_BEGIN_VALUE("fsync:", FileInfo(fd).c_str());

  int ret = BYTEHOOK_CALL_PREV(proxy_fsync, fd);

  ATRACE_END();
  return ret;
}

二是在内核空间，除 systrace 或 atrace 可直接支持启用功能外，ftrace 还提供其他功能，并包含对调试性能问题至关重要的一些高级功能（需要 root 访问权限，通常也可能需要新内核）。我们基于此添加显示定制 IO 信息等功能，开启 /sys/kernel/debug/tracing/events/android_fs节点下 ftrace 信息，用于收集 IO 相关的信息。内核空间 IO 信息是通过 python 脚本开启，详见 io_extender.py。

解决方法闭合错误问题

背景介绍

RheaTrace 会自动在每个方法入口、出口处分别插入 Trace#beginSection(String) 和 Trace#endSection() ，一个方法有且只有一个入口，但会有多个出口，方法出口对应的结束字节码指令有 return 和 throw 等。

   public static void testCrash() {
        try {
            testA();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static void testA() {
        testB();
        testC();
    }

    public static void testB() {
        int ret = 2 / 0; // <----- crash event
        testD(ret);
    }

    public static void testC() {
        Log.d("btrace", "do some things.");
    }

    public static void testD(int num) {
        Log.d("btrace", "box size: " + num);
    }

上面的代码很简单，即 testCrash -> testA -> testB，其中 testB 出现异常，最终是在 testCrash 中捕获。通过本示例可知，testA、testB 方法出口均未正常执行完成，这也就导致 trace 数据不闭合，生成的 trace 数据如下，从中可以看出，B 和 E 数量上并不匹配，且仅从 trace 上看，我们也无法知道 E 属于哪个方法。

   5108949.231989: B|28045| TestCrash:a
5108949.232055: B|28045| TestCrash:b
5108949.232554: B|28045| TestCrash:c
5108949.232580: E|28045

方案介绍

为解决该问题，RheaTrace 做了取巧处理，方法的出口由插入 Trace#endSection()改为 Trace#beginSection(String)。那我们如何知道哪条 trace 是开始，哪条是结束？我们看如下示例。

   5108949.231989: B|28045|B:TestCrash:a
5108949.232055: B|28045|B:TestCrash:b
5108949.232554: B|28045|B:TestCrash:c
5108949.232580: B|28045|E:TestCrash:a

如上 trace 数据，每个方法描述前都会加上 B: 或 E、 T, B: 表示方法开始，E 表示方法 retrun 结束， T: 表示方法 throw 结束。然后通过 Python 脚本处理并还原正常 trace 数据。如此做以后，我们就可以明确知道方法开始和结束，同时针对异常结束方法，我们会做补全处理，处理后的 trace 数据如下。

   5108949.231989: B|28045|TestCrash:a
5108949.232055: B|28045|TestCrash:b
5108949.232554: B|28045|TestCrash:c
5108949.232554: E|28045|TestCrash:c
5108949.232554: E|28045|TestCrash:b
5108949.232580: E|28045|TestCrash:a

关于 Python 脚本的处理过程，本文不做过多介绍，大家可以阅读相关源码即可。

RheaTrace 工作流程

流程概述

RheaTrace 作为线下性能分析利器，我们首先看下其整体工作流程。

如上文介绍，我们将 Systrace 中 atrace 数据做拦截，将其转存至我们自定义的文件中。

Systrace 格式

首先我们 Systrace 生成的 trace.html 中 atrace 数据格式。

   <idle>-0     (-----) [001] d.h4 1308823.803921: sched_waking: comm=TimerDispatch pid=704 prio=97 target_cpu=001
          <idle>-0     (-----) [001] dnh5 1308823.803929: sched_wakeup: comm=TimerDispatch pid=704 prio=97 target_cpu=001
          <idle>-0     (-----) [001] d..2 1308823.803943: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=TimerDispatch next_pid=704 next_prio=97
          <idle>-0     (-----) [003] d.s3 1308823.803980: sched_waking: comm=kworker/3:0 pid=11120 prio=120 target_cpu=003
          <idle>-0     (-----) [003] d.s4 1308823.803986: sched_blocked_reason: pid=11120 iowait=0 caller=worker_thread+0x4fc/0x804
   TimerDispatch-704   (  643) [001] .... 1308823.803988: tracing_mark_write: B|643|TimerIteration #9392
          <idle>-0     (-----) [003] dns4 1308823.803988: sched_wakeup: comm=kworker/3:0 pid=11120 prio=120 target_cpu=003
   TimerDispatch-704   (  643) [001] .... 1308823.803992: tracing_mark_write: E|643
          <idle>-0     (-----) [003] d..2 1308823.803997: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/3:0 next_pid=11120 next_prio=120
   TimerDispatch-704   (  643) [001] .... 1308823.804011: tracing_mark_write: C|643|VSP-mode|0
   TimerDispatch-704   (  643) [001] .... 1308823.804014: tracing_mark_write: C|643|VSP-timePoint|405332069786762
   TimerDispatch-704   (  643) [001] .... 1308823.804016: tracing_mark_write: C|643|VSP-prediction|405332075389317
   TimerDispatch-704   (  643) [001] .... 1308823.804022: tracing_mark_write: B|643|app-alarm in:5602555 for vs:15880333
   TimerDispatch-704   (  643) [001] .... 1308823.804024: tracing_mark_write: E|643

文本形式打开 trace.html，在其底部是填充的 trace 数据，如上所示数据片段，带有 tracing_mark_write 标签的即包含 atrace 数据。在 trace.html 文件中有关于 trace 格式介绍，如下数据片段。

   # tracer: nop
#
# entries-in-buffer/entries-written: 178063/178063   #P:8
#
#                                      _-----=> irqs-off
#                                     / _----=> need-resched
#                                    | / _---=> hardirq/softirq
#                                    || / _--=> preempt-depth
#                                    ||| /     delay
#           TASK-PID    TGID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |        |      |   ||||       |         |
          <idle>-0     (-----) [003] d.s2 1308814.493991: sched_waking: comm=rcu_preempt pid=9 prio=120 target_cpu=003
          <idle>-0     (-----) [000] d.s2 1308814.493997: sched_waking: comm=rcu_sched pid=10 prio=120 target_cpu=000

在 trace.html 中，一条完整的 atrace 数据为：

   .sample.android-19452 (19452) [005] .... 1308823.801863: tracing_mark_write: B|19452|activityStart
......
.sample.android-19452 (19452) [005] .... 1308824.801753: tracing_mark_write: E|19452

在上文介绍 Systrace 时候，我们提到， Trace#beginSection(String) 和 Trace.endSection() 最终是调用如下宏。

   #define WRITE_MSG(format_begin, format_end, name, value) { \
    ...
    write(atrace_marker_fd, buf, len); \
}

其中， write 函数传入的 trace 数据为：

   B|19452|activityStart
......
E|19452

B 表示 Section 进入， E 表示 Section 退出，从以上数据片段可以看出，相较于 trace.html 中 atrace 数据少了很多信息，缺少的信息是内核补全。

Systrace 工具中 --from-file 是可以将原始 atrace 数据转化为可视化的 html 文件。因此，针对 atrace 数据我们需要补全缺少的信息。结合前面介绍的 trace 格式说明及多次验证，可被 Systrace 工具识别的 atrace 文件格式满足如下：

   <ThreadName>-<TheadID> [001] ...1 <Timestamp>: trace_mark_write:<B|E>|<ProcessID>|<TAG>

格式说明：

<ThreadName>：线程名，若为主线程，可指定为包名。
<ThreadID>：线程 ID。
<Time seconds>：方法开始或者结束时间戳。
<B|E>：标记该条记录为方法开始(B)还是结束(E)。
<ProcessID>：所在进程 ID。
<TAG>：方法标记，字符长度不可超过 127。

[001] 和 ...1 对应的数据用户层是无法获取，因此硬编码写死。

RheaTrace 格式

Systrace 中相关 atrace 数据格式有很多冗余信息，冗余信息是可以通过脚本来进行补充，这样在 atrace 存储过程中可以减少一定数据量的存储。

仅采集主线程 atrace 数据，其对应格式如下：

   1306401.857369: B|16667|VerifyClass com.bytedance.rheatrace.atrace.TraceEnableTagsHelper
1306401.857498: E|16667
1306401.857560: B|16667|VerifyClass com.bytedance.rheatrace.common.ReflectUtil
1306401.857825: E|16667
1306401.857876: B|16667|VerifyClass kotlin.jvm.internal.Intrinsics
1306401.858241: E|16667
1306401.858523: B|16667|VerifyClass com.bytedance.rheatrace.core.RheaNoticeManager
1306401.858633: E|16667

因为 RheaTrace 仅支持采集主进程 trace 数据，因此，进程 ID 信息无需写入，另外主线程名为包名也无需写入，主线程 ID 与进程 ID 一致也无需写入，剩余信息均为格式模板信息也无需写入，唯一需要记录的是时间戳。

采集所有线程 atrace 数据，其对应格式如下。

   1306401.859162 16667: B|16667|RheaApplication#onCreate
1306401.859173 16667: E|16667
1306401.859756 16667: E|16667
1306401.859877 16667: B|16667|activityStart
1306401.862738 16680: B|16667|JIT compiling int sun.util.locale.StringTokenIterator.nextDelimiter(int) (baseline=0, osr=0)
1306401.862772 16680: B|16667|Compiling
1306401.863154 16680: B|16667|ScopedCodeCacheWrite
1306401.863172 16680: B|16667|mprotect all
1306401.863207 16680: E|16667

当采集多线程数据时，我们需要获取对应的线程 ID，线程名我们没有通过在 App 期间获取，而是读取 Systrace 工具生成 trace.html 中读取。如下数据片段，我们可以获取进程 ID 为 16667 对应的所有线程 ID 及名称。当然也会存在线程 ID 如下数据片段找不到的情况，我们暂时用 <...>代替。

   USER            PID   TID CMD
root              1     1 init
root              1   548 init
root              2     2 kthreadd
root              3     3 rcu_gp
root              5     5 kworker/0:0H
root              7     7 mm_percpu_wq
root              8     8 ksoftirqd/0
root              9     9 rcu_preempt
root             10    10 rcu_sched
root             11    11 rcu_bh
.....
u0_a168       16667 16684 FinalizerWatchd
u0_a168       16667 16685 Binder:16667_1
u0_a168       16667 16686 Binder:16667_2
u0_a168       16667 16687 Binder:16667_3
u0_a168       16667 16688 Profile Saver
u0_a168       16667 16689 async-writer
u0_a168       16667 16690 RenderThread
u0_a168       16667 16693 HWC release
u0_a168       16667 16694 GPU completion

通过 RheaTrace 提供的脚本，我们就可以将原始 atrace 数据加工为标准 atrace 格式，如下数据片段。

   .sample.android-16667 [001] ...1 1306401.857369: tracing_mark_write: B|16667|VerifyClass com.bytedance.rheatrace.atrace.TraceEnableTagsHelper
 .sample.android-16667 [001] ...1 1306401.857498: tracing_mark_write: E|16667
 .sample.android-16667 [001] ...1 1306401.857560: tracing_mark_write: B|16667|VerifyClass com.bytedance.rheatrace.common.ReflectUtil
 .sample.android-16667 [001] ...1 1306401.857825: tracing_mark_write: E|16667
 .sample.android-16667 [001] ...1 1306401.857876: tracing_mark_write: B|16667|VerifyClass kotlin.jvm.internal.Intrinsics
 .sample.android-16667 [001] ...1 1306401.858241: tracing_mark_write: E|16667
 .sample.android-16667 [001] ...1 1306401.858523: tracing_mark_write: B|16667|VerifyClass com.bytedance.rheatrace.core.RheaNoticeManager
 .sample.android-16667 [001] ...1 1306401.858633: tracing_mark_write: E|16667

当通过 Systrace 命令获取 trace.html 后，trace.html 中的 atrace 因为被 RheaTrace 拦截写入自定义文件中，因此生成的 trace.html 文件中是不包含 atrace 数据。

如果不包含 atrace，那么 trace.html 的作用将非常小，因此，我们需要将 atrace 数据填充进入 trace.html 中，经过验证 atrace 数据满足如下格式，能够被 trace.html 识别。

   <ThreadName>-<TheadID> (ProcessID) [001] ...1 <Timestamp>: trace_mark_write:<B|E>|<ProcessID>|<TAG>

相较于标准 atrace 文件，它多了 (ProcessID)数据。

有了上述介绍，我们介绍下 RheaTrace 生成的 systrace.html 中间会生成哪些文件。

   python rheatrace.py -a rhea.sample.android -t 3 -o ./output/systrace.html

在 systrace.html 同级目录下会生成 .build 目录，其中包括上述中间产物文件。

   ├── .build
│   ├── atrace-standard          //标准 atrace 格式，可直接用 perfetto 打开。
│   ├── rhea-atrace              //从设备中拉取的 rhea-atrace.gz 文件解压得到，原始 RheaTrace 格式的 atrace 数据。
│   ├── systrace-fs-origin.html  //如果设备 root，其中会包括内核 IO 事件，前文有提到。
│   └── systrace-origin.html     //通过 Systrace 工具抓取的可视化 trace 文件，不包含 atrace 数据。
└── systrace.html                //atrace-standard 与 systrace-fs-origin.html 或 systrace-origin.html 合并得到。

未来规划

支持 App 独立抓取 atrace 数据，无需依赖 Systrace 环境。
提供稳定、高效的 trace 采集环境，适配更多手机机型。
支持更多维度的 trace 信息，比如渲染、内存等，更方便定位函数耗时原因。
进一步降低性能损耗，到达线上使用要求。

作者：ByteDanceTech 发表于 2021/12/30 15:24:06 原文链接 https://blog.csdn.net/ByteDanceTech/article/details/122248282

阅读：33

超级好用的免费开源文件同步工具：Syncthing

Mon, 27 Dec 2021 10:09:20 CST

相信不少小伙伴跟TJ君有一样的经历，当然相信也会有小伙伴是因为更换设备导致的文件丢失，不管怎么说，临时用用还行，平时大家还是不要把重要的文件直接存储在微信上，还是该备份的备份，该传输到本地的传输。存到网盘？你确定不开通个VIP那上传下载速度能用？

那么今天的问题就来了，平时大家都用什么文件传输工具呢？

今天TJ君要和大家分享的就是一款免费、开源的文件同步工具， Syncthing

作为一款P2P性质的文件同步工具，Syncthing在Github上广受欢迎，已经收获了42k的Star！

Syncthing有五大特点：

1、避免数据丢失
2、安全防范攻击者
3、便捷使用
4、自动化运行
5、高兼容性

像Windwos、macOS、Android、Linux这些主流平台都支持Syncthing，所以Syncthing可以跨平台的进行文件传输。

目前最新的版本是v1.18.5版本，在18天前更新，说明作者也一直在优化迭代。

以windows为例，只需要安装好Syncthing电脑端的应用程序，打开浏览器访问 http://127.0.0.1:8384/ 就可以进入 Syncthing传输平台。

如果在其他设备，例如手机端也安装完Syncthing，便会有同步提示，通过后就可以进行文件传输了。速度很快哦！

不知道大家有没有从TJ的图中发现，虽然Syncthing的开源项目都是英文描述，但是其使用界面却是中文的，算不算也是给我们大天朝的一个小小的福利呢？想试试这款工具传输文件进行备份的小伙伴们，赶紧来试试吧！

扫描下方二维码，关注公众号“TJ君”，回复“Syncthing”，获取仓库地址！

尝试解析下 Epub.js：一个在浏览器上渲染 Epub 图书的工具

Sat, 20 Nov 2021 00:00:00 CST

一直在看 Epub 类型的图书，很好奇一个 Epub 解析器是如果工作的。碰巧看到了 Epub.js，体验了一下还可以。就尝试分析一下它的实现。本文会先介绍下 EPUB 格式,再来分析 Epubjs 的实现. 我前端经验仅限于了解常见标签含义，可能会有各种错误恳请斧正。

Epub

EPub是一个自由的开放标准，属于一种可以“自动重新排版”的内容；也就是文字内容可以根据阅读设备的特性，以最适于阅读的方式显示。EPub档案内部使用了XHTML或DTBook（一种由DAISY Consortium提出的XML标准）来展现文字、并以zip压缩格式来包裹档案内容。EPub格式中包含了数位版权管理（DRM）相关功能可供选用

以上来自维基百科: https://zh.wikipedia.org/wiki/EPUB

本文参考的规范为: Epub 3.2该规范发布于 2019-05-08, 定义了 EPUB 图书格式和 EPUB 图书的浏览器应实现的功能. Epub格式由以下规范组成:

EPUB Packages — 定义内容的每个Rendition的要求。
EPUB Content Documents — 定义了在 EPUB 出版物上下文中使用的 XHTML、SVG 和 CSS 的配置文件。
EPUB Media Overlays — 定义了文本和音频同步的格式和处理模型。
EPUB Open Container Format — 定义了一种文件格式和处理模型，用于将一组相关资源封装到单个文件 (ZIP) EPUB 容器中。
EPUB Accessibility — 定义 EPUB 出版物的可访问性一致性和发现要求。

如下图: EPUB图书的内容是由一个或多个Rendition组成，每个Rendition都由所谓的EPUB Package 表示。 EPUB Package包含呈现内容所需的所有资源。其中的关键文件是Package Document，它包括阅读系统用于向用户呈现EPUB图书的所有元数据（例如标题和作者等）。它还提供了一个完整的资源清单，并包括一个 SPINE(用来表是文档出现的顺序)。 EPUB Package还包括另一个称为EPUB Navigation Document的文件。本文档提供了导航功能，例如目录，允许用户快速轻松地导航内容。 EPUB 图书的资源捆绑在一个基于 ZIP 的文件中，文件扩展名为.epub. 作为符合 ZIP 格式的文件，EPUB 出版物可以被许多软件程序解压缩，从而简化了它们的使用。

参考规范来制作一个简单Epub 图书

按照下图的方式来组织目录和文件

mimetype 文件名固定, 内容也固定位: `application/epub+zip`

META-INF/container.xml 为入口文件,文件名固定.

内容如下: 其中rootfile指定了package file

    <?xml version='1.0' encoding='utf-8'?><containerxmlns="urn:oasis:names:tc:opendocument:xmlns:container"version="1.0"><rootfiles><rootfilefull-path="OPS/package.opf"media-type="application/oebps-package+xml"/></rootfiles></container

OPS/package.opf

Package 文件, 定义了书籍的 meta 信息, 资源列表和阅读顺序(Spine) 内容如下:

metadata: 标签定义的作者等信息
manifest: 定义了资源列表,如正文页面, 目录, 封面图片, CSS, JS 等等
spine: 定义了书籍连续阅读的顺序.
- Liner 代表顺序是否为必要顺序. 如目录和封面不一定强制按照这个顺序来阅读. 或者说是在做阅读器是可以把 Liner=no页面弹窗
- 和目录/书签最显著的区别, Spine 是按照资源文件来组织循序. 目录/书签等是可以指定到资源内的标签.

    <?xml version='1.0' encoding='utf-8'?><packagexmlns="http://www.idpf.org/2007/opf"unique-identifier="uuid_id"version="3.2"prefix="calibre: https://calibre-ebook.com"><metadataxmlns:dc="http://purl.org/dc/elements/1.1/"><dc:titleid="id">Calvin用来演示 EPUBJS 的书</dc:title><dc:creatorid="Creator">Calvin Wang</dc:creator><dc:identifierid="uuid_id">urn:uuid:5F1E4C07-2A52-48BC-BBA5-E98564559794</dc:identifier><dc:language>zh-CN</dc:language><metaproperty="dcterms:modified">2021-11-14T08:32:29Z</meta></metadata><manifest><itemid="cover"href="cover.xhtml"media-type="application/xhtml+xml"/><itemid="toc"properties="nav"href="toc.xhtml"media-type="application/xhtml+xml"/><itemid="firstpage"href="first_page.xhtml"media-type="application/xhtml+xml"/><itemid="secondpage"href="second_page.xhtml"media-type="application/xhtml+xml"/><itemid="ncxtoc"href="toc.ncx"media-type="application/x-dtbncx+xml"/><itemid="cover-image"properties="cover-image"href="images/cover.png"media-type="image/png"/></manifest><spinetoc="ncxtoc"><itemrefidref="cover"linear="no"/><itemrefidref="toc"linear="no"/>ß<itemrefidref="firstpage"linear="yes"/><itemrefidref="secondpage"linear="yes"/></spine></package>

其他页面

    <--!CoverPage--><?xml version="1.0" encoding="UTF-8"?><htmlxmlns="http://www.w3.org/1999/xhtml"xmlns:epub="http://www.idpf.org/2007/ops"><head><title>Cover Page</title><metacharset="utf-8"/></head><body><div><imgsrc="images/cover.png"alt="Cover Image"title="Cover Image"/></div></body></html><--!firstpage--><?xml version="1.0" encoding="UTF-8"?><htmlxmlns="http://www.w3.org/1999/xhtml"xmlns:epub="http://www.idpf.org/2007/ops"><head><title>First Page</title><metacharset="utf-8"/></head><body><sectionepub:type="bodymatter chapter"><header><h1><spanid="c002p0000">First Page</span></h1></header><p><spanid="c002p0001">First Page: aaaaaaaaaaaa</span></p><p><spanid="c002p0002">First Page: bbbbbbbbbbbbb</span></p></section></body></html><--!TOCPage--><?xml version='1.0' encoding='utf-8'?><htmlxmlns="http://www.w3.org/1999/xhtml"xmlns:epub="http://purl.org/dc/elements/1.1/"><head><title>Cover</title></head><body><navxmlns:ns0="http://www.idpf.org/2007/ops"ns0:type="toc"><ol><li><ahref="cover.xhtml">Cover Page</a></li><li><ahref="toc.xhtml">Nav Page</a></li><li><ahref="first_page.xhtml">First Page</a></li><li><ahref="second_page.xhtml">Second Page</a></li></ol></nav></body></html>

把目录打包成 EPUB 文件

如下图: 用 ZIP 压缩文件至 first-epub.epub

    zip-r../first-epub.epub*

把做好的图书用自带的 Book 打开来看看

Epub.js

Epub.js 是一个 JavaScript 库，用于在浏览器中跨多种设备呈现 ePub 文档。 Epub.js 为常见的电子书功能（如渲染、持久化和分页）提供了一个接口，而无需开发专用的应用程序或插件。重要的是，它是 BSD 许可证。

翻译自项目 README

来看看官方的DEMO

高亮备注分页等等常用功能是均支持的

来实现一个”Hello Word”

    <!DOCTYPE html><html><head><metacharset="utf-8"><title>Demo for Epub.js</title><scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/jszip/3.1.5/jszip.min.js"></script><scriptsrc="https://futurepress.github.io/epub.js/dist/epub.js"></script></head><body><divid="nav"><selectid="toc"></select></div><divid="viewer"></div><script>var$viewer=document.getElementById("viewer");// Load the opfvarbook=ePub("https://blog.calvin.wang/assets/first-epub.epub",{store:"epubjs-test"});varrendition=book.renderTo("viewer",{width:"100%"});vardisplayed=rendition.display();book.loaded.navigation.then(function(toc){var$select=document.getElementById("toc"),docfrag=document.createDocumentFragment();toc.forEach(function(chapter){varoption=document.createElement("option");option.textContent=chapter.label;option.ref=chapter.href;docfrag.appendChild(option);});$select.appendChild(docfrag);$select.onchange=function(){varindex=$select.selectedIndex,url=$select.options[index].ref;rendition.display(url);returnfalse;};});</script></body></html>

来看看它有哪些 Model

Book: 用来代表一个 Epub 图书,用来加载和解析其内容
- Container: 用来解析 Container, 主要用来从 “META-INF/container.xml”获取 PackagePath
- Packaging: 用来解析 Package, 主要用来获取manifest cover spine metadata nav ncx
Rendition: 负责将 Book 的内容渲染在网页上,并进行控制.
- Manager: 用来控制网页上的呈现方式(default: DefaultViewManager)
- View: 展现在页面上的样式(default: IframeView)
EpubCFI: 是一个规范,定义了一种标准化方法，用于通过使用片段标识符来引用 EPUB® 出版物中的任意内容. 可以参考: http://idpf.org/epub/linking/cfi/epub-cfi.html
辅助类:
- Theme: 样式主题
- Annotations: 注解

流程怎么控制的

Rendition:
- 支持HOOK的阶段:
  - content: Pages/View内容被解析和加载,现有的 HOOK
    - handleLinks: 处理内容中的连接
    - passEvents: 内容中产生的事件同步
    - adjustImages: 调整图片
  - unloaded: Pages/View内容从屏幕中卸载
  - render: Pages/View被渲染到屏幕
Spin:
- 支持HOOK的阶段:
  - Serialize: Pages/View 被转换为 text
  - Content: Pages/View 被加载和解析. 现有的 HOOK
    - injectStylesheet: 注入样式表
    - injectScript: 注入脚本

还没有完全看懂的内容, 感觉是语言特性:

Promise 的用处?
Event的传递方式?

2021年敏捷管理工具推荐

Mon, 15 Nov 2021 00:00:00 CST

敏捷和DevOps已经很流行了，对应的工具也不少（例如JIRA、Azure DevOps、云效等等），我们在本篇文章里捋一捋截止到2021年11月都有哪些有名的敏捷工具。

1. JIRA

JIRA是Atlassian公司著名的敏捷管理工具，可以管理史诗（Epic)、用户故事(User Story)、任务（Task)，同时可以使用看板可以跟踪管理相关工作项的状态。
问题追踪和管理：用它管理项目，跟踪任务、bug、需求，通过jira的邮件通知功能进行协作通知，在实际工作中使工作效率提高很多

问题跟进情况的分析报告：可以随时了解问题和项目的进展情况
项目类别管理功能：可以将相关的项目分组管理
组件/模块负责人功能：可以将项目的不同组件/模块指派相应的负责人，来处理所负责的组件的Issues
项目email地址功能：每个项目可以有不同的email（该项目的通知邮件从该地址发出）
无限制的工作流：可以创建多个工作流为不同的项目使用

2. Azure DevOps

Azure DevOps 是由微软开发的服务平台，它提供了多种工具，可用于更好地进行团队协作。它还具有用于自动构建过程，测试，版本控制和程序包管理的工具。

Azure DevOps 提供了 5 个主要模块：

Azure Boards：这些是敏捷的工具，可以帮助我们规划、跟踪和讨论我们的工作，甚至与其他团队一起工作。
Azure Repos：提供无限的、云托管的私人和公共 Git 存储库。
Azure Pipelines：使用适用于任何语言、平台和云的 CI/CD 进行构建、测试和部署。
Azure Test Plans：使用适用于应用的手动测试和探索测试工具来提高代码整体质量。。
Azure Artifacts：与整个团队共享来自公共源和专用源的 Maven、npm、NuGet 和 Python 包。以简单且可缩放的方式将包共享集成到 CI/CD 管道中。

3. TAPD

TAPD（Tencent Agile Product Development）是腾讯的敏捷研发协作平台，提供贯穿敏捷研发生命周期的一站式服务。覆盖从产品概念形成、产品规划、需求分析、项目规划和跟踪、质量测试到构建发布、用户反馈跟踪的产品研发全生命周期，提供了灵活的可定制化应用和强大的集成能力，帮助研发团队有效地管理需求、资源、进度和质量，规范和改进产品研发过程，提高研发效率和产品质量。

产品功能:

敏捷需求规划：能够快速高效的对需求进行全周期管理。通过需求收集、分解，规划并实施，快速响应市场变化，灵活处理需求变更，过程可追溯，清晰更透明。
迭代计划：通过迭代进行目标制定与计划评审，完成工作分配，使用故事墙与燃尽图进行研发过程跟踪。迭代全程目标清晰，进度可控，研发过程敏捷迭代，小步快跑。
测试计划：对于迭代质量的全程把控。通过快速编写并管理测试用例，制定测试计划并执行，利用缺陷跟踪管理进行问题跟踪与解决，能够实现对测试工作的高效管理，保障产品高质量交付。
缺陷管理：对缺陷进行全方位记录与跟踪。配合缺陷统计报表对 BUG 进行统计分析，能够及时了解开发的质量并进行跟踪修复。同时可通过邮件创建定时报告发送给项目成员，让团队成员及时了解迭代开发质量。
工时管理：合理分配团队资源，利用工时进行工作量统计，配合工时花费报告，能够实时掌握团队成员工作完成情况与项目进展，过程清晰，风险可控。
文档管理：提供思维导图、在线文档、文件管理等功能，支持多人实时协作编辑，帮助团队集中管理项目文件，方便团队进行头脑风暴、内容分享与知识沉淀。

4 云效

云效提供项目管理、需求管理、缺陷管理、任务管理、迭代规划等丰富的项目管理功能及效能数据统计，支持单项目管理、跨项目协作等丰富的协作场景。

产品功能：

需求管理：管理需求从提出、设计、开发、测试、发布的完整流程。
迭代规划：提供将需求规划进迭代并完成迭代的交付。
项目管理：管理项目从创建、规划、实施、交付的完整流程。
研发效能度量：支持工时统计。

5 Leangoo

Leangoo是一个以看板为核心的敏捷项目协作工具，通过看板共享和实时同步团队工作来实现高效协同。团队工作体现为卡片，内容可以是需求、任务、问题等。
产品Backlog
Scrum任务板
用户故事

6. Ones

Ones 适用需求管理、任务管理、缺陷管理、迭代管理等敏捷场景
产品功能：

需求管理
迭代规划
缺陷管理
进度管理

HTTP抓包工具之Charles

Tue, 02 Nov 2021 09:20:20 CST

Charles简介

Charles是一个HTTP代理服务器，当浏览器连接Charles的代理访问互联网时，Charles可以监控浏览器发送和接收的所有数据。它允许一个开发者查看所有连接互联网的HTTP通信，这些包括request, response和HTTP headers （包含cookies与caching信息）。

Charles主要功能：

支持SSL代理。可以截取分析SSL的请求。
支持流量控制。可以模拟慢速网络以及等待时间（latency）较长的请求。
支持AJAX调试。可以自动将json或xml数据格式化，方便查看。
支持AMF调试。可以将Flash Remoting 或 Flex Remoting信息格式化，方便查看。
支持重发网络请求，方便后端调试。
支持修改网络请求参数。
支持网络请求的截获并动态修改。
检查HTML，CSS和RSS内容是否符合W3C标准。

以上介绍了Charles的主要功能，个人在使用过程中主要用的是抓取HTTP和HTTPS请求。特别是HTTPS的请求，抓取起来还是有一些麻烦，特此记录。

Charles 抓包原理

市面上绝大多数的抓包软件，背后的原理都是中间人攻击（Man-in-the-middle attack，缩写：MITM）。

维基百科是这样定义 MITM 的：中间人攻击在密码学和计算机安全领域中是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。

上面的定义写的很清晰，下图中结合箭头方向就能看懂 HTTP Packets 的流向：

Charles的使用

Charles的安装过程是比较简单，只需到官网下载安装即可。比较困难的是HTTPS请求的配置。

Windows下HTTPS请求抓包

1、配置SSL支持。点击【Proxy】–>【SSL Proxying Settings…】，在弹出选项卡中，勾选【Enable SSL Proxying】点击【add】，在Host输入【*】表示接收任何主机，在Prot输入【*】表示任何端口，最后点击【ok】保存。

2、安装证书。点击【Help】–>【SSL Proxying】–>【Install Charles Root Certificate】，按照引导流程安装证书。

完成后打开IE进行测试：出现证书错误！

打开Chrome测试：

打开Edge测试：

都被安全拦截了，装了证书都不起作用。

解决方案：安装Firefox！

安装完毕后在开启Charles时，使用Firefox打开，http://chls.pro/ssl，弹出如下页面：

选择保存文件后按确定。文件默认保存到下载文件夹。

打开Firefox【设置】–>【隐私与安全】–>【证书】–>【查看证书】

使用【证书管理器】–>【证书办法机构】–>【导入】进行导入操作。

iOS下HTTPS请求抓包

在PC上开启共享网络。将手机连接到PC共享的WIFI上。

在手机上设置代理地址，代理IP为PC的IP，端口为Charles的端口。

在手机自带浏览器Safari中输入chls.pro，完成后需要进入【设置】安装描述文件。安装完毕后，如果是iOS 10 以后需要进入【设置】–>【通用】–>【关于本机】–>【证书信任设置】，开启证书。

Android下HTTPS请求抓包

在PC上开启共享网络。将手机连接到PC共享的WIFI上。

在手机上设置代理地址，代理IP为PC的IP，端口为Charles的端口。

在手机默认浏览器中输入chls.pro，下载downloadfile.crt文件，然后在【我的下载】中进行打开，按引导进行安装。

IT瘾工具推荐

用Qwen 3.6 35B本地模型作为主力编程工具替代Claude或GPT

一、 本地大模型（Local LLM）编程的 5 条最佳实践

二、 帖子主要内容概述

如何使用NLEmbedding + Gemma4构建一个知识管理和检索友好的系统工具

🏗️ 系统架构核心设计

🧠 第一步：NLEmbedding——构建记忆检索层

🚀 第二步：Gemma 4——搭建生成与交互层

🔗 第三步：RAG流程串联与代码示例

🔧 第四步：优化与进阶策略

💎 总结：技术选型速览

游戏开发团队测试500款AI工具 仅6款具备实用价值

gstack：YC总裁开源的”AI软件工厂”，68k Star的工具到底香不香？

一、gstack是什么？

二、数据情况

三、核心功能有哪些？

规划阶段

构建阶段

测试阶段

发布阶段

四、面向的人群有哪些？

五、应用场景有哪些？

六、和同类竞品的差异有哪些？

七、使用技巧

八、对企业和个人的价值

九、产品定价

十、项目地址

总体评价

亚马逊因 AI 编码工具引发多起故障

NotebookLM：我目前最常用、也最愿意推荐的 AI 学习与内容组织工具

NotebookLM 给我带来的核心价值

快速理解陌生技术：把庞杂资料丢进去，它帮我生成“可学的版本”

生成 MindMap：大量文档瞬间变成结构化知识图谱

生成教学大纲、培训稿、图书结构：真正节约我大量时间

多格式输入能力：这是我见过最稳的

我目前最常用的 NotebookLM 工作流

我遇到的小遗憾与建议

MindMap 的导出格式应该支持 SVG 或基于文本（Markmap）

对话记录应该支持长期保存

幻灯片生产能力如果能支持模板，会更适合作为创作者工具

Deep Research 早日上线并全面开放

移动端希望尽快增强，而不是只提供播放内容

总结

网络安全专家爱用的逆向工具 Top9

1.十六进制编辑器

2.OllyDbg

3.APKTool

4.WireShark

5.Scylla

6.Dex2jar

7.CCF

8.Oracle VM VirtualBox

9.BinaryNinja

开源实时数据同步工具NiFi

Apache NiFi简介

Apache NiFi主要功能

Apache NiFi的优势

Apache NiFi的架构

核心组件

工作流和数据流

分布式架构

安全性

Airflow、Kafka的对比

相关文章:

将 Android 手机变成监听工具

Python地理数据分析工具MovingPandas

MovingPandas的使用

MovingPandas的安装

MovingPandas接口详解

MovingPandas.Trajectory对象

MovingPandas.TrajectoryCollection对象

MovingPandas.TrajectoryCollectionAggregator对象

MovingPandas.TrajectoryCleaner对象

MovingPandas.TrajectoryGeneralizer对象

MovingPandas.TrajectorySmoother对象

MovingPandas.TrajectorySplitter对象

MovingPandas.TrajectoryStopDetector对象

MovingPandas使用实例

准备工作

停留点检测

一、本地大模型（Local LLM）编程的 5 条最佳实践

二、帖子主要内容概述

游戏开发团队测试500款AI工具仅6款具备实用价值