去年写过一篇 RAG 概念科普，这次不一样：在本地从零手写了一个最小 RAG 系统。不引入 LlamaIndex、LangChain 的检索部分，链路里的每一环——分块、embedding 调用、向量存取、相似度检索——都是自己写的。

这么做的原因很简单：目标是学习，而只有手写一遍，才能回答那些框架文档不会告诉你的问题：

• embedding 到底返回了什么？数值长什么样？
• 为什么"苹果"和"汽车"的相似度也有 0.53？
• 检索为什么不能只看 top-k，还要看分数？
• 全量遍历检索在什么时候会撑不住？

这篇文章是完整的过程记录，包含所有实验结果和踩坑经历。

一、环境：老显卡上的 Ollama

选型结论：本地模型 bge-m3（1024 维，中文效果好，离线免费），通过 Ollama 提供 OpenAI 兼容的 /v1/embeddings 接口。

踩了个大坑：本机是 GTX 1060（Pascal 架构，太老），新版 Ollama 的 CUDA 内核一加载就崩：

llama-server process has terminated:
CUDA error: the provided PTX was compiled with an unsupported toolchain

排查过程值得记录（每个变量都试过）：

经验：embedding 是纯推理（无生成），小模型跑 CPU 完全够用。12 个分块建索引总共才 2 秒。以后遇到老显卡 + 新 CUDA 内核的组合，OLLAMA_LLM_LIBRARY=cpu 是第一选择。

今天我们要聊一个让许多 Flutter 开发者在尝试使用 dart:ffi 与原生 C/C++ 代码交互时，尤其是在 iOS 平台上，非常头疼的问题：为什么我的 FFI 调用在 Debug 模式下好好的，一到 Release 或 Archive 模式就报 Failed to lookup symbol (dlsym(RTLD_DEFAULT, your_c_func): symbol not found) 错误？

这个问题，简单来说就是 Dart 代码想在 iOS 的二进制文件里找到一个 C 函数，但它就是找不到。这背后，藏着 Xcode 编译和链接的一些“秘密”。

1. dlsym 符号查找失败：问题的表面现象

当你使用 dart:ffi 调用原生 C/C++ 函数时，Dart 内部会通过 DynamicLibrary.lookup() 方法去查找这个函数。在 iOS 上，这最终会调用到底层 dlsym 函数。

错误信息 dlsym(RTLD_DEFAULT, your_c_func): symbol not found 的核心含义是：操作系统在你的 App 可执行文件或其依赖库中，无法找到名为 your_c_func 的函数符号。

这个错误的诡异之处在于，它往往只在 Release 或 Archive（用于上传 App Store）构建模式下出现，而在 Debug 模式下运行一切正常。

摘要

在现代移动应用开发中，用户对应用的流畅性和响应性有着极高的要求。无论是 Android 原生应用还是基于 Flutter 构建的跨平台应用，其底层的消息（事件）处理机制都扮演着核心角色。本文将深入解析 Android Handler 中一个鲜为人知但至关重要的机制——同步屏障（Synchronization Barrier），并将其与 Flutter Dart 语言中的单线程、事件循环以及**微任务队列（Microtask Queue）**进行详尽对比。理解这些底层机制，不仅能帮助开发者优化应用性能，更能提升对各自平台运行原理的认知。

1. Android Handler 中的同步屏障 (Synchronization Barrier) 🚦

Android 应用的 UI 线程（主线程）是单线程的，所有 UI 更新和绝大部分应用逻辑都在此线程上执行。为了避免 UI 阻塞和 ANR (Application Not Responding)，Android 提供了一套基于 Handler、Looper 和 MessageQueue 的消息机制。

1.1 Android 消息机制概览

• Handler: 用于发送和处理消息 (Message) 或任务 (Runnable)。它将消息发送到与当前线程关联的 MessageQueue 中。
• MessageQueue: 一个存储消息的队列，采用单链表结构。它负责管理由 Handler 发送的各种消息。
• Looper: 消息循环器，每个线程最多拥有一个 Looper。它不断地从 MessageQueue 中取出消息，并分发给对应的 Handler 进行处理。

整个流程概括为：Handler 发送消息 -> MessageQueue 存储消息 -> Looper 从 MessageQueue 中取出消息 -> Looper 将消息分发给 Handler 处理。这是一个典型的单线程事件循环模型。

摘要

在 Android 应用开发中，管理 UI 状态和数据流是一项复杂的任务。Jetpack LiveData 作为 Lifecycle-aware（生命周期感知）的数据持有者，极大地简化了这一过程，解决了传统数据绑定中常见的内存泄漏、UI 状态不一致等问题。它使得数据更新能够自动地在 LifecycleOwner（如 Activity 或 Fragment）的生命周期内进行，并确保只有活跃的 UI 组件才能接收更新。本文将深入剖析 LiveData 的核心设计理念、关键组件以及其数据分发和生命周期感知能力的底层实现原理。

1. LiveData 核心概念与优势 ✨

LiveData 是一个可观察的数据持有者类。与传统的 Observable 不同，LiveData 是生命周期感知型的，这意味着它会尊重应用组件（如 Activity、Fragment 或 Service）的生命周期。这种特性带来了显著的优势：

• UI 与数据状态同步: 当 LiveData 中的数据发生变化时，它会通知所有活跃的 Observer。
• 无内存泄漏: LiveData 只在 LifecycleOwner 处于活跃状态（STARTED 或 RESUMED）时更新 Observer。当 LifecycleOwner 被销毁时，它会自动移除 Observer 订阅，避免内存泄漏。
• 不再因 stop 而崩溃: 如果 Observer 处于非活跃状态（例如 Activity 处于 onStop() 状态），它将不会接收任何 LiveData 事件。当它再次变为活跃状态时，会立即接收到最新的数据。
• 无需手动处理生命周期: LiveData 会自动管理观察者注册和注销，开发者无需在 onResume()/onPause() 或 onStart()/onStop() 中手动添加/移除观察者。
• 始终保持最新数据: 如果 LifecycleOwner 从非活跃状态变为活跃状态，它会立即接收到 LiveData 中存储的最新数据。

2. LiveData 的核心组件与交互 🔗

理解 LiveData 的实现，需要先了解几个关键的参与者：

近年来，大型语言模型（LLMs）如 GPT 系列取得了惊人的进步，能够生成流畅、连贯且富有创造性的文本。然而，它们也存在一些固有的局限性，例如：

• 知识截止日期 (Knowledge Cutoff)：模型只知道训练时接触过的信息，无法获取实时或最新的知识。
• 幻觉 (Hallucination)：有时会编造看似合理但不正确或无事实依据的信息。
• 领域特定知识缺乏：对于未包含在训练数据中的私有或特定领域知识，表现不佳。

为了解决这些问题，检索增强生成 (Retrieval-Augmented Generation, RAG) 技术应运而生。

RAG 是什么？

RAG 是一种结合了信息检索 (Information Retrieval) 系统和大型语言模型生成能力的技术框架。

其核心思想是：在让 LLM 生成回答之前，先从一个外部知识库（如文档集合、数据库、网页等）中检索出与用户提问相关的最新或特定信息，然后将这些检索到的信息作为上下文 (Context)，连同用户的原始问题一起提供给 LLM，让 LLM 基于这些“增强”过的信息来生成最终的回答。

RAG 的工作流程

一个典型的 RAG 系统通常包含以下步骤：

1. 检索 (Retrieve)：

   • 当用户提出一个问题或指令 (Query/Prompt) 时，系统首先使用这个查询去搜索一个外部的知识库。
   • 这个知识库通常是预先处理好的文档集合，可能存储在向量数据库 (Vector Database) 中，通过计算查询与文档之间的语义相似度（例如使用 Embedding 技术）来找到最相关的几段文本或文档片段。

2. 增强 (Augment)：

   • 将上一步检索到的相关信息（即上下文 Context）与用户的原始查询结合起来，形成一个增强后的提示 (Augmented Prompt)。
   • 这个增强后的提示包含了原始问题的意图以及相关的背景知识或事实依据。

3. 生成 (Generate)：

   • 将这个增强后的提示输入给大型语言模型 (LLM)。
   • LLM 基于其强大的理解和生成能力，同时参考提供的上下文信息，生成一个更加准确、可靠且与特定知识相关的回答。

可以将其想象成一个“开卷考试”的过程： LLM（学生）在回答问题前，被允许先去查找相关的参考资料（检索到的上下文），然后再根据这些资料来组织答案。

为什么使用 RAG？ RAG 的优势

相比于直接使用 LLM 或对其进行微调 (Fine-tuning)，RAG 提供了诸多优势：

• 提高事实准确性，减少幻觉：通过引入外部的、可验证的信息源，显著降低了 LLM “凭空捏造”信息的可能性。
• 访问最新知识：可以轻松地通过更新外部知识库来让模型获取最新信息，无需重新训练庞大的 LLM。
• 利用特定领域/私有知识：能够让 LLM 回答关于特定数据集（如公司内部文档、特定领域的专业知识库）的问题，而无需将这些私有数据用于模型训练。
• 更具成本效益：相比于为特定知识对 LLM 进行大规模微调或重新训练，维护和更新外部知识库通常成本更低、效率更高。
• 可解释性与可追溯性：可以更容易地追踪到答案所依据的信息来源（检索到的文档），提高了系统的透明度。

总结

RAG 是一种强大的技术，它有效地将大型语言模型的生成能力与外部知识库的广度和实时性结合起来，显著提升了 AI 应用在处理需要特定、最新或准确信息场景下的表现。它已成为构建更可靠、更智能的问答系统、聊天机器人和其他知识密集型 AI 应用的关键技术之一。

引言

在现代 Java 和 Android 应用开发中，并发编程是提升系统性能和响应能力的关键。然而，直接创建和管理线程会带来显著的开销：线程创建/销毁成本高、无限制创建线程可能耗尽系统资源。为了解决这些问题，Java 提供了强大的线程池（Thread Pool）机制，特别是 java.util.concurrent.ThreadPoolExecutor 类，它是构建高效、可控并发应用的核心组件。对于 Android 开发而言，合理使用线程池对于避免主线程阻塞、提升用户体验至关重要。

理解线程池的内部工作原理、核心参数以及调度逻辑，对于合理配置和使用线程池，从而优化应用性能至关重要。本文将带你深入探索 ThreadPoolExecutor 的内部世界，并介绍 Android 中常用的线程池创建方式。

为什么需要线程池？

使用线程池主要有以下好处：

1. 降低资源消耗：通过复用已创建的线程，减少了线程创建和销毁带来的开销。
2. 提高响应速度：当任务到达时，可以立即使用空闲线程执行，无需等待线程创建。
3. 提高线程的可管理性：线程是稀缺资源，线程池可以统一分配、调优和监控，防止无限制创建线程导致资源耗尽。
4. 提供更强大的功能：线程池可以提供定时执行、定期执行、单线程、并发数控制等功能。

ThreadPoolExecutor 的核心参数

ThreadPoolExecutor 是 Java 线程池最核心的实现类，其构造函数接受几个关键参数，理解这些参数是掌握线程池的第一步：

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler) {
    // ...
}

让我们逐一解析这些参数：