这些云服务针对特定版本做了大量的魔改和优化才做成公开卖的 serverless 产品，而基线是立项时就定下来了，内部开发的很长时间才能拿出来商用，对于迭代比较快的技术，一出来就过气实属正常。

如果这种云服务追版本很快，那通常是厂商在上游有话语权，或者干脆就是上游主要维护者，可以对上游开发路线进行干涉。

淘汰是不可能的，xml 都还活得好好的。注释的话 json5 是无痛解决方案，顺带解决手撸 json 总少了引号逗号导致出错的烦恼。

json 好就好在稍微新点的编程语言都直接在标准库包含 json 实现了，省去外部依赖的麻烦。

专门做投屏方案的公司。主要好处是全平台通杀，AirPlay+DLNA+Miracast+私有协议都有。MIUI 手机投屏直接集成了乐播的方案，可以走局域网而不是用质量超烂的 Miracast 。

无线投屏就没哪家做得好的，可能是业界不看好吧。乐播在我看来是在 Android 这边比较接近及格线的方案。

另外 Android10 之前没有内录音频的 API，必须 root，所以之前想让投屏有实用意义必须依赖系统内建的投屏方案。

这个投屏还是不适合高画质或者低延迟的用途，有线方案（ MHL 或者 Type-C DP Alt Mode ）是最佳选择，但又不是什么中端机型都支持，厂商经常不标注。5 年前想要有线投屏的买索尼是最省事的方法。

DoH 并不能防止国内的 DNS 服务器被污染，DNSSEC 才能做到这点。
何况你全配了国内的服务器。

@titanium98118 主要是安全问题吧，这种小型基站可以集中管理，整个电话网络链路都是运营商控制的设备，也不用怕外部设备攻击或者影响服务质量。

这算是白嫖了个手机信号放大器了。没想到国内居然有这种进户的微基站业务。运营商用同一个接入网解决宽带、固话和蜂窝网络问题不大，光纤到户带宽管够。

以前我就想过由于 5G 的频段高不好搞覆盖，可不可以将小功率基站集成到家庭网关上，用来解决室内信号覆盖问题。个人感觉主要麻烦是信道规划比较麻烦。

@kaedea
升级安装会检查 apk 签名是否一致，能装上就行，顶多就是同一开发者不同分发渠道，通常设计上都不会有问题。楼主遇到的是 App Bundles 相关的问题。

@fishrimp
虽然 apkmirror 说会人工审核，但并因为都是用户上传，没法可靠地标注来源，所以建议下载之前现在 play 市场查一下上架的最新版本，例如现在查到是 8.0.2 那就只下 8.0.2 。

这里我之所以选的不是 versioncode 最大的 1860 而是采用 bundles 格式的 1852 是因为我手工检查过几个支持 arm64 的版本的内部情况，只有我发的那个版本符合“单一 ABI”+“未压缩原生库”这两个要求。我也不明白为啥单一 ABI 的包还要压缩来浪费安装空间，连 Google 自家产品都没统一这点。

只是一种猜测。

国外大厂商例如 MS 和 Google 是因为 TOTP 只是其中一种可选的 2FA 手段，其他 2FA 手段有电子邮箱、手机验证码、硬件密钥等。其中电子邮箱、手机验证码会暴露部分隐私信息，所以需要先行验证 PIN 才能暴露这部分信息。

国内的话也会在输密码之后进行一个黑箱的风控检查，用以决定是否需要进行额外身份验证。另外不知道是不是觉得用户教育不足，对 TOTP 的信任度还不如常用设备验证。

用 sshd_config Match 条件块( https://man.openbsd.org/sshd_config#Match )

例如这样子

```
Match Host !10.0.0.0/8, User admin
PasswordAuthentication no
PubkeyAuthentication yes
Match Host 10.0.0.0/8, User admin
PasswordAuthentication yes
PubkeyAuthentication yes
```

应用配置前先用虚拟机测试一下配置是否按预期运作。

@Cielsky 300M 的这个是同时包含 armv7 和 arm64 的 fat binary 版本，不是老旧的 armv7 手机没必要用这个。图省事不在乎多占 400M 安装空间的也可以用。

@fishrimp 这个是支持小程序的。apkm 就是一个 zip 包，你可以解压看看里面有什么东西。
关于 Webview 我不是很清楚 GP 版微信小程序是否依赖系统 Webview，个人认为不依赖。

一般建议锁版本。

Google 曾经有一种项目管理的理念：所有活跃项目都使用主线版本，如果依赖升级导致 break，就作为一个 bug 处理，bug 最终都能修掉，追不上版本的项目就是死亡的项目。

因为这个理念，golang 相当长的时间里都没有官方的依赖版本管理方案，逼着所有项目追主线。不过现在还是转向 go mod 了，估计就是这种管理模式只适合 Google 那种求快速迭代不求稳定的业务模式。

@dickinpit 目前 Google Play 推送的版本有 5 个 split apk，也就是我发的 apkmirror 那个，其中 split_delivery**模块是打开 APP 后补充的，缺了这个可能打不开小程序。可以用 LibChecker 检查。


580M 是 5 个 split apk 和 odex 优化代码的空间，由于没有压缩原生库，不需要额外解压原生库占更多空间。

@est TX 能跟 Apple 谈妥你还担心 GP 那边出问题，前者比后者严格多了，GP 那边只要内购那边没问题，Google 基本不会找开发者麻烦。

Google Play 已经停止支持 obb 了，现在用的是 App Bundles，微信已经换了。
建议去 APKMirror 下载 8.0.2(注意不是 8.0.9，有 variant 的版本才有可能是 GP 的)
建议用这个纯 arm64 480dpi 的版本，这个版本没有压缩原生库，安装时能省些空间。
( https://www.apkmirror.com/apk/wechat-tencent/wechat/wechat-8-0-2-release/wechat-8-0-2-6-android-apk-download/ )

apt-mark show hold 检查一下软件包是不是被锁版本了。
你这里好像是 nginx 和 mariadb 升级不了，如果你没在用可以暂时卸载掉，或者升级完重新安装。
do-release-upgrade 前建议运行 sudo apt autoremove 删掉无用的依赖，能少点冲突。

@AoEiuV020 以前我用 Edge 的，集成扫码翻译去广告，要不是在 MIUI 下有界面 bug 我也不会换回 chrome 。我是希望找个有个增加 APP 跳转审核的，国外产的浏览器好像都不做这个功能，国产是不可能用的。

@dingwen07
@ysc3839
我重新试了下 apkmirror，原来是我下错了，chrome 的 apk 要下 Android10+的 variant 。不过不知道实验装在刷了 PixelExperience 的 S7 上还是显示 32 位版。


@Esec
其实我是没搞懂为啥 Google 要将 Webview 部署搞得这么复杂。先不说 trichromelibrary 有没有清理机制，我是没看懂 libmonochrome.so 64 位放 trichromelibrary 、32 位放 webview 是个什么逻辑。

两个本身是同一档次的东西。

SN550 发热小，但不支持个人送保（闪迪马甲没这个缺陷），无外置 DRAM 需要靠 HMB 技术（借系统内存）提高性能。

RC10 支持个人送保，有外置 DRAM，但由于固件计算方法不同导致 CrystalDiskInfo 显示的健康度掉得很快，不太好出二手。因为这个原因在贴吧被集中黑过一段时间。

不是迫不得已就别买 SATA SSD 了，价格没便宜，上限很低，还没法支持未来的技术，例如 DirectStorage 。