square.github.io

Square Open Source是什么网站?

Square Open Source 是 Square 公司把自家开源项目集中展示出来的官网，地址在 square.github.io。它本身不提供托管或代码仓库，而是按编程语言分类，给出每个项目的一句话说明和指向 GitHub 的入口。

主要用途

• 让 Android、Java、Kotlin、Go、C、iOS 等方向的开发者快速找到 Square 出品的库和工具。
• 每个条目说明“这个库解决什么问题”，点进去到 GitHub 看源码、文档和版本。

适合谁、什么时候用

• Android 开发者选型网络、图片、JSON、测试工具时，可以在这里横向对比同一家公司的方案。
• 后端或基础设施开发者找证书、TLS、指标、SQL 相关工具时，Go 分类下有对应项目。
• 想了解 Square 技术栈、或按语言筛选开源库的人。

页面里有哪些代表项目

• Android：OkHttp（HTTP 客户端）、Retrofit（类型安全 HTTP 客户端）、Picasso（图片下载与缓存）、LeakCanary（内存泄漏检测）、Moshi（JSON 库）。
• Go：ghostunnel（带双向认证的 SSL/TLS 代理）、certigo（证书检查与验证）、metrics（指标查询引擎）。
• iOS：PonyDebugger（用 Chrome 开发者工具远程调试网络与数据）、Aardvark（生成可操作的 bug 报告）。

和其他开源聚合站的区别

它只收 Square 自家项目，不做全社区索引，所以范围窄但方向集中；相比直接在 GitHub 上搜，这里按语言分好类、每条有用途说明，适合先建立候选清单，再逐个跳去 GitHub 看细节。

在Android项目里如何选择OkHttp、Retrofit和Moshi搭配使用?

在 Android 项目里，这三者不是三选一，而是常见的一套组合：Retrofit 负责接口声明，OkHttp 负责底层网络，Moshi 负责 JSON 与对象的转换。三者都能在 Square Open Source 找到：Square Open Source 收录了 okhttp、retrofit、moshi，定位分别是 HTTP 客户端、类型安全的 HTTP 客户端、面向 Kotlin/Java 的现代 JSON 库。

搭配时的分工

• OkHttp：真正发请求、连接池、拦截器、缓存、超时。需要统一加日志、加请求头、做重试或换 base URL 时，改的是它。
• Retrofit：把 HTTP 接口写成 Kotlin/Java 方法，用注解描述路径和参数。它内部默认用 OkHttp 发请求，所以两者天然一起用。
• Moshi：把响应 JSON 转成数据类，或把请求对象转成 JSON。Retrofit 通过 converter 接入它。

选择条件

• 只用 OkHttp 就够：接口很少、请求逻辑简单，或者你只想手动拼 URL、手动解析 JSON。
• 需要 Retrofit：接口数量多、希望用接口方法统一管理、想让请求和响应自动映射成对象。
• 需要 Moshi：项目用 Kotlin，想要比 Gson 更贴近 Kotlin 的空安全和默认值行为，或者需要自定义 adapter 处理特殊字段。

具体组合方式

1. 用 OkHttpClient 配置超时、拦截器、缓存。
2. 创建 Retrofit 实例时传入这个 OkHttpClient。
3. 给 Retrofit 添加 MoshiConverterFactory，让返回值直接是数据类。
4. 接口方法用 suspend 或返回 Call，按项目协程方案决定。

例如需要给所有请求加统一 header、同时把 JSON 自动转成 Kotlin data class，就可以按上面四步搭：OkHttp 管传输，Retrofit 管接口，Moshi 管序列化。

如果项目里已经用了 Gson，也可以先只换 Retrofit + OkHttp，Moshi 作为后续替换项；但新 Kotlin 项目直接三者搭配更顺。

LeakCanary怎么帮助定位和修复Android内存泄漏?

LeakCanary 是 Square 开源、托管在 Square Open Source 上的 Android 内存泄漏检测库，核心价值是自动发现“该被回收却没被回收”的对象，并给出引用链，帮你定位是谁在持有它。

它怎么定位泄漏

• 在 Android 应用运行期间自动监控 Activity、Fragment 等对象的销毁与回收情况。
• 对象本应被回收却仍可达时，主动触发堆转储（heap dump）并分析引用路径。
• 输出泄漏对象的引用链，指出是哪条引用把它“挂住”了，通常能直接看到罪魁祸首（如静态变量、未注销的监听器、非静态内部类等）。
• 以通知和日志形式呈现结果，不需要你手动抓 hprof 再慢慢翻。

拿到引用链之后怎么修

1. 看引用链最靠近泄漏对象的那一环：是谁持有它。
2. 常见修法：把静态引用改为弱引用或在合适时机置空；在 onDestroy 里注销监听器、广播、回调；把非静态内部类改成静态内部类并避免隐式持有外部 Activity。
3. 修完重跑，确认 LeakCanary 不再报告同一处泄漏。

适合谁、什么场景用

• 开发阶段排查偶发或反复出现的 Activity/Fragment 泄漏。
• 代码评审前后做回归验证，或给团队新人一个直观的“泄漏长什么样”的示例。
• 注意它主要用于调试，通常不随正式发布版本一起打包。

和同类思路的侧重点

• 相比手动用 Android Studio Profiler 抓堆转储，LeakCanary 更偏“自动发现 + 直接给引用链”，省去自己判断哪些对象可疑的步骤；Profiler 更适合做整体内存占用和分配分析。
• 相比只做静态检查的工具，它基于运行时真实对象可达性，报出的泄漏更贴近实际发生的问题。

下一步：在 debug 依赖里引入 LeakCanary，跑一遍主要页面（尤其是频繁进出的 Activity），按通知里的引用链逐条排查。

Picasso和Pollexor在图片加载与处理上有什么区别?

Picasso 和 Pollexor 解决的是图片链路里两个不同环节的问题，不是同类竞品。

• Picasso：Android 端的图片下载与缓存库，负责把网络或本地图片取回来、缓存并加载进 ImageView。
• Pollexor：Thumbor 图片服务的 Java 客户端，负责拼装带处理参数的图片 URL，把缩放、裁剪等处理交给 Thumbor 服务端完成。

各自的使用场景

用 Picasso 的情况：App 需要在列表、详情页里展示远程图片，希望自动处理内存与磁盘缓存、请求取消、占位图，避免自己写下载和缓存逻辑。它工作在客户端。

用 Pollexor 的情况：团队已经部署了 Thumbor 图片服务，需要在 Java/Android 代码里以流式 API 生成处理后的图片地址，例如按尺寸、裁剪区域、滤镜拼出 URL。它本身不做下载和缓存，只负责生成地址。

关键区别

怎么选

• 只做常规图片加载与缓存：用 Picasso。
• 已有 Thumbor、希望把图片处理集中到服务端：用 Pollexor 生成 URL，再交给加载库（例如 Picasso 或 Square Open Source 里的 okhttp）去请求。

两者可以组合：Pollexor 负责“要哪个处理版本”，Picasso 负责“把它取回来并显示”。

如何用Sqldelight根据SQL生成类型安全的Kotlin API?

SQLDelight 的核心思路是：你写 .sq 文件里的 SQL，编译期生成类型安全的 Kotlin API，而不是运行时拼字符串。它属于 Square Open Source 收录的项目，资料中的定位是“Generates typesafe Kotlin APIs from SQL”。

使用步骤

1. 在项目中添加 SQLDelight 的 Gradle 插件，并配置数据库名称和包名。
2. 在 src/main/sqldelight/<包名>/*.sq 下写建表和查询语句，例如：
   • CREATE TABLE player (id INTEGER PRIMARY KEY, name TEXT);
   • selectAll: SELECT * FROM player;
3. 编译项目，插件会为每条查询生成对应的 Kotlin 函数和返回类型，如 selectAll() 返回 List<Player>。
4. 在代码里通过生成的 Database 类调用这些函数，插入、更新、删除同样以带参数的方法暴露。

适合谁

需要跨 Android 与 Kotlin 多平台、又希望 SQL 保持可读和可校验的团队。相比在代码里手写 SQL 字符串，它把列名、参数类型和返回值都交给编译器检查，写错列名或类型会在编译阶段报错。

选择条件

• 如果你已经在用 Room 这类注解式 ORM，SQLDelight 更偏向“SQL 优先”，SQL 文件本身就是唯一事实来源。
• 如果你只是做简单的键值存储或单表 CRUD，引入它的配置成本可能不划算。
• 资料中 SQLDelight 与 workflow、anvil 等并列在 Square 的开源项目列表里，说明它面向的是 Android/Kotlin 生态中需要类型安全和多平台支持的场景。

下一步

从官方 GitHub 仓库的 Gradle 配置示例入手，先建一张表加一条查询，跑通编译和调用，再逐步把现有 SQL 迁移进去。

ghostunnel如何为不支持TLS的服务提供双向认证代理?

ghostunnel 是 Square 开源的一个 Go 语言 SSL/TLS 代理，核心用途就是给本身不支持 TLS 的服务加上一层加密和双向认证（mTLS），而不用改动后端服务代码。

它怎么工作

• 在服务前面起一个 ghostunnel 进程，对外监听 TLS 端口。
• 客户端连 ghostunnel 时完成 TLS 握手，ghostunnel 校验证书（双向认证：既验证客户端证书，也让客户端验证服务端证书）。
• 握手通过后，ghostunnel 把解密后的明文流量转发给后面那个只讲明文、不懂 TLS 的服务。
• 后端服务完全无感知，仍然按原来的方式收发数据。

典型使用场景

例如你有一个只监听 localhost、不支持 TLS 的内部服务，想安全地暴露给其他机器或团队访问：在服务所在机器上跑 ghostunnel，让它监听对外端口并配置好证书，后端指向本地服务端口即可。这样加密和身份校验都由代理承担。

选择它的条件

• 后端服务无法改造、不能自己加 TLS。
• 需要双向认证，而不只是加密。
• 环境是 Go 生态、希望部署简单（单个二进制）。

相关工具

同属 Square 开源、常一起出现的还有 Square Open Source 里的 certstrap（用于搭建 CA、签发证书），可以用它来生成 ghostunnel 所需的证书链。