动态库 & 静态库，若单独输出并接入主工程，逻辑倒很清晰。如果牵涉到多个 framework 不同类型并且相互依赖，会增加不少复杂度。
以下说明中，动态库使用 DFramework 表示，静态库使用 SFramework 表示。

1 framework

仅需要提供 1 个 framework，直接提供 DFramework 即可。DFramework 优先，必要的时候再提供 SFramework

n framework

因为代码结构分组，可能需要提供多个 framework：

1. DFramework 优先，能不提供 SFramework 就不要提供
   • 有 n 个 DFramework 就提供 n 个。相互之间做好依赖文档，App 需要根据依赖文档 flat 平铺接入所有需要的 DFramework。
   • 如果 b DFramework 仅仅被 a DFramework 依赖，可以将 b 打入 a DFramework 的 frameworks 文件夹中，通过 embed 实现。
     • 这样就可以不再文档中说明 b DFramework 的存在，对外界透明。
     • 这种方案，最终的 app 中 framework 不是 flat 平铺的，而是具有层级结构，如 ：App - a DFramework - b DFramework
   • 如果 b DFramework 同时被 m DFramework 和 n DFramework 依赖，不能将 b 隐藏（打入 m 和 n 中）。
     • 否则，App 集成 m 和 n 的时候，b 会出现多份。如果 b 的版本不一样，将按照打包顺序只使用其中一个。

Mac 系统上，默认没有提供 git、xcodebuild 这些开发者命令。所以当一些终端命令 (brew 等) 被触发后，macos 系统会弹窗提醒用户进行【开发者工具】的安装，即【Command Lines Tools】(下面简称 tools)。
如果安装了不同版本的 xcode，则每个版本都会携带各自 xcode 版本的【tools】。
上面提到的系统弹窗，是不需要安装 xcode 也可以安装【tools】。但这个 tools 版本会比较低，内部的命令数量也会少于 xcode 携带的。即：最新版本的 xcode，携带的 tools 也是最新的。
这里就可以发现有多个 tools 目录了，如下：

1. 非 xcode 携带：/Library/Developer/CommandLineTools
2. xcode:/Applications/Xcode.app/Contents/Developer
3. xcode beta: /Applications/Xcode-16.2.0-Beta.2.app/Contents/Developer

在终端执行 git 、xcodebuild 的时候，一定会使用某一个 tools 中的命令，可具体使用哪一个呢？

今天配置 cloudflare 中站点的 dns，遇到一些关于 cname、tls、cloudflare 代理相关的问题，做了下梳理。重点有下：

1. cname 负责提供目标 ip，在机制上类似【权威域名服务器】
2. 目标 ip 所在的服务如果非自行掌控（比如强行设置一个目标域名），很可能无法工作。
3. cloudflare 设置 cname 的时候有一个【代理】功能。这个设计非常糟糕，完全脱离了 cname 的本意。

以下介绍中，使用 cloudflare 配置 test.yigegongjiang.com 的 cname 为 httpbin.org，默认不配置【代理】。

最近工作上在使用 WebRTC，在公司内部做了技术分享。这里把内容进行脱敏，整理公开。

快速进入 WebRTC

Server-Sent Events（SSE）是一种允许服务器通过 HTTP 连接主动向客户端发送数据的技术。它主要被用于创建实时应用，如消息推送和实时通知。SSE 使用简单的文本格式发送消息，这种格式使得其易于在浏览器中实现和使用。

SSE 注意事项：

1. 通过 HTTP 协议通道 建立单向长连接，即 Client 连接 Server 后，Server 不断开连接，并持续的通过 socket 套接字发送 data 给 Client。
2. 网关等设备会主动关闭 tcp 通道，需要 SSE Server 端增加心跳。很多种场景都会导致 tcp 连接中断，和 IM 心跳一致。这里需要 SSE Server 增加应用层心跳，非 TCP 层心跳。

实际测试结果，虽然 Cloudflare 号称服务部署非常多，但使用 Warp 的 【VPN / 代理】功能，会明显增加网络延迟。（location & ip： Japan）

Cloudflare 提供了 1.1.1.1 DNS 服务，以及 WARP VPN + 代理。

公共 DNS

运营商 DNS 有什么问题？

直接使用运营商的 DNS 服务，有下面两个重要的问题：

1. ISP 会通过 DNS 查询的域名，分析用户访问的网站。（DNS 查询是明文的 UDP）
2. ISP DNS 会有劫持、污染、缓存等

那么公共 DNS 可以解决上面的问题吗？不行。

对于普通用户来说，使用运营商 DNS 没有任何问题，也会加快域名解析的速度。
如果想要安全，避免被运营商做【DNS 查询】分析，公共 DNS 无能为力。不管使用的公共 DNS 是 ipv4、ipv6、DoH，都无法解决。
DoH 是能用到最安全的级别了，但还是有 SNI 泄漏。

换端能力

在移动应用生态中，换端 (App Switching) 是一个常见的需求。同一台设备上，有以下三个端: M(Web网页)、 A(移动应用 app)、 B(待唤端的应用 app)。 当 M 或 A 需要跳转至 B 时，有两种技术方案: URL Scheme 和 Universal Link。

URL Scheme

1. App 端先行验证能力:
   • A 可以通过 canOpen 方法预先判断 B 是否已安装，且此操作不会触发跳转

Bonjour

local net 服务发现。核心是两个 api：NSNetService & NSNetServiceBrowser。

Bonjour 的目的，是希望发现局域网中的设备，包括这些设备的 ip、port 等信息，从而进行下一步业务操作。因为有了 ip、port，就可以精确定位一台设备了，就可以做很多事情了，比如打通 socket 等。

NSNetService 用来发布服务，表明 m 提供了哪些能力，如打印机、http 服务等等。

对于电子显示屏而言，第一要务是要显示信息。与信息显示直接相关的硬件，是光源。每一个光源称为【物理像素】。

光源 - 像素密度 - 物理像素

像素本身是没有大小和尺寸的。同一个显示屏，可以有 100 * 100 个像素（光源），也可以有 10000 * 10000 个像素。但是显示屏的大小并没有改变，改变的是 光源 的多少。如果显示屏有更多的 光源，那么就可以显示更加细腻的画面。这是【像素密度】。

对于硬件来说，提升【像素密度】，可以在单个面积上，展示更加丰富的色彩。这需要制作工艺的提升，iPhone 4 首次将其商业化，开发出了 Retina （HiDPI）屏幕。当时称为 2 倍屏，和 iPhone 3G 相比，屏幕的物理尺寸没有改变，但是像素密度提升了 4 倍，即 宽、高 的密度提升了 2 倍。

这是硬件制作工艺上的提升，但如何有效的使用塞了更多光源的屏幕，是软件来工作的。实际上，很多复杂的逻辑，都是软件来规定的。毕竟硬件只提供了【像素密度】更高、更多的【光源】，其他并没有做。比如软件开发中如何实现 0.5px 的宽高、如何调整设置系统的分辨率等等。

光源，也称为【物理像素】，是真实的提供发光和色彩的源头。

很久之前，写过一篇关于 【计算机字符编码与内存编码 - Unicode】 的快照，根据 码位、码表 对字符进行了介绍。这里特别说明一下 Mac 系统上的字体库。

系统自带软件：Font book
字体文件夹： /System/Library/Fonts 、/Library/Fonts、~/Library/Fonts
苹果提供的字体：Applexxx 、Apple xxx 、SFxxx 、PingFangxxx

如何使用字体

1. 操作系统根据语言的不同，会使用默认字体。比如中文系统，会使用 PingFang 字体。英文系统，会使用 SF 字体。
2. app、dmg 等软件，可以直接使用 defaultfont:xxx 的形式直接使用系统字体，或者使用 fontname:xxx 的形式自行选择字体。自行选择的时候，可以使用系统提供的字体，也可以将 xx 字体打入 app 中来使用。
3. app 提供修改字体的功能，用户可以自行选择需要的字体。