这跟自带的 XCUITest 有啥区别吗？

ubnt

https://ampere.shop/products/unravel-multi-device-wireless-charger-apple-watch-iphone-x-airpods-2-aw-wireless-charging-station?variant=28174740947044

众筹的时候买的，还可以，起码比 nomad 好

`http:` 后面不用加 `//` 吗？

@imn1 #40 可是按你这个思路想想，这不正是 DNA 的短板吗？指纹什么的尚需伪造，从而间接加大破解密码的难度……而 DNA 不需要啊，如果你都能接触到目标到复制指纹的程度了，那 DNA 只需要死皮、毛发或者体液，根本不需要伪造，直接获取就是 100% 可以通过验证的……

@imn1 #29 ……没明白你的观点……
现阶段 DNA 采集对比慢 → 所以 DNA 比指纹安全？
而且为了克服你说的那些指纹磨损、毁坏、伪装，指纹识别这些年一直都在进化，比如一代 Touch ID 的活体识别，而且其范围也早已超出了「指纹」的范畴，Apple 这些年在 Apple Watch 上一直在测试的 Vein Pattern 不就是为了下一代 Touch ID / Face ID 技术吗？

@troyl #27 当然，骨髓移植改变的是干细胞 DNA，不过忽略这点的话 DNA 依然安全性低于指纹，因为同卵双胞胎的指纹尽管 DNA 相同，指纹 /掌纹依然是不同的。

@imn1 #22 @rogwan #24 呃……建议多了解一下 Biometric Security，首先是同卵多胞胎的 DNA 完全相同无法区分，再者，随着骨髓捐赠和移植的普及，接受移植者的 DNA 慢慢变成捐赠者的案例已经越来越多，所以在生物识别安全领域，DNA 的安全等级甚至不如指纹……

为啥不用 Combine ？

请问走路时候的风噪如何？我的 XM3 走路的时候如果开降噪都会有难以忽略的风声，每次都要关掉 Ambient Sound Control

App 的 Swift Version 也要设置到 Swift 5.x

@mxalbert1996 #22 @mxalbert1996 普及度高，不一定更好啊？那篇 Quora 文章提到和 U1 同类的产品 [Decawave DW1000 Radio IC]( https://www.decawave.com/product/dw1000-radio-ic/)，精准度是蓝牙和 WiFi 的 100 倍。在 290 米的距离范围内，比 GPS 的延迟快 50 倍，而且能耗极低。

有更好的，为啥不用？

真厉害，不过我倒是觉得这种超高功效、超低耗能的个人雷达，不但在室内的用途前景广阔，在室外也很有用啊。现在城市日益拥挤，要是每个行人的身上和车辆上都有统一标准的 Ultra Wideband 设备（手机，车辆感知器 etc.），那可以避免多少车祸啊。

@kingcos #4 这是个伪命题…… Swift 是支持 namespace 的，所以不同 module 里如果有相同的 symbol，这个是会加上 module 的前缀的，所以不会重复。如果是 Objective-C，那么它只有一层 namespace （实际上是两层，但对开发者来说只有一层），那么如果你的 project 或者你依赖的 library/framework 有相同的 symbol，那么在 link 的时候就会报错，编译是不会通过的。我唯一遇见的一次 duplicate symbol 是有一个 framework 静态链接了一个我们也依赖的第三方库，但是既然是第三方开源库，它就不应该静态链接，它应该声明这个 dependency，让开发者或者包管理软件来负责链接。

@junho #8 其实你倒不必纠结干预 link 这一点，那是因为当时 Swift 还不支持 Static Library，我们只好自己想办法来兼容 CocoaPods。现在支持了，就直接用吧。

你可以用 `otool -l 壳工程的 binary` 来看到所有的 rpath dependency，那里就会暴露你的私有库，而且会让你的壳工程无法脱离私有库来使用，你 #2 楼的想法的第二条我觉得是可行的，你可以试试。

Dynamic Framework 参数会使 Mach-O 文件产生 @rpath 依赖，你需要在编译私有 framework 干预中间 link 过程，这样才可以保证编译出来的 SDK 仍然是 dynamic 的，但所有私有的 object 全部都 statically linked 进你 SDK 的 binary 里。但这只是第一步，你仍然需要保证 SDK 的所有 public interface 全都不会使用私有 framework 中的 public type (return type, parameter type, etc.)。然而这仍然不够，因为，swift 的 interface 文件仍然会产生私有 framework 的 import dependency，而且，这个 interface 文件 (.swiftmodule) 是 binary，不可编辑，所以你需要一个 dummy interface generator 来暴露你希望暴露给第三方用户的接口，这样的好处是你可以控制暴露给第三方和 internal use only 的公有接口。
这个方法对 Swift 1 以后的 project 都适用。当然，如果你的 project 是 Swift 4 以后的，你可以直接使用 Static Library。但仍需要消除 .swiftmodule 中对私有 framework 的 dependency。

这是我在全部重写我司 SDK 成 Swift 2 的时候研究出来的，因为 pipeline 的需要，ship 给 3rd party 和 internal team 的 SDK 是一样的，但是 internal team 可以用我们的 private framework，而 3rd party 只会拿到一个包含所有 symbols，但是混淆过的 binary。

思路就是这样，但是公司原因不能详谈实现。

祝顺利。

Command + S

@bleaker #11 笔记本是一根线的啊，在公司是 MacBook Pro + LG 5K，MBP 上就插一根连到显示器的 Thunderbolt 3 线，连电源线都不用插，然后在显示器上连网线、电源、USB 之类的线，这样每次去开会就很方便，因为只连着一根线，拔了就可以走，插上就可以用。这是 Apple 从 Thunderbolt 2 就开始提供的 seamless one cable connectivity 啊。