给旧设备写 app 时遇到一个问题，在重写的 Application 类里使用 Java 8 特性会在运行时报错找不到类，而在其他地方使用都没问题。

E/AndroidRuntime: FATAL EXCEPTION: main
    java.lang.NoClassDefFoundError: $r8$backportedMethods$utility$Objects$2$equals
        at MyApplication.onCreate(MyApplication.java:xx)

排查了一圈才发现是 multidex 惹的祸，由于执行 attachBaseContext() 需要先加载 MyApplication 类，此时 multidex 还没来得及安装，所以 MyApplication 里不能调用主 DEX 文件中不存在的类。

public class MyApplication extends SomeOtherApplication {
  @Override
  protected void attachBaseContext(Context base) {
     super.attachBaseContext(base);
     MultiDex.install(this);
  }
}

参考资料

https://developer.android.com/studio/write/java8-support#library-desugaring
https://developer.android.com/studio/build/multidex

先在 Prism 的下载页面选好想要的配置，复制到主题目录下。然后在主题的 header.php 里添加以下两行即可。

<link rel="stylesheet" href="<?php $this->options->themeUrl('prism.css'); ?>">
<script defer src="<?php $this->options->themeUrl('prism.js'); ?>"></script>

https://pari.math.u-bordeaux.fr/

gp 可以直接当计算器用，我试过很多命令行计算器，gp 是用得最顺手的之一。gp 在进程退出时不保留历史，启动速度也很快，支持整数、小数、分数计算。

? 4/6
%1 = 2/3
? 100./2
%2 = 50.000000000000000000000000000000000000
? 2^4
%3 = 16
? Pi
%4 = 3.1415926535897932384626433832795028842
? exp(1)
%5 = 2.7182818284590452353602874713526624978

https://www.macports.org/

说到想在 macOS 下装点啥，一般都会想到 Homebrew。但 macOS 上也有其他包管理软件，MacPorts、Nix、pkgsrc、Fink 等等。MacPorts 社区相对活跃且有针对 macOS 优化，这回就来聊下 MacPorts 和 Homebrew 相比优势和劣势在哪。

优势

1. 软件数量多，大部分你需要的包都能找到。根据 ports 站统计 MacPorts 目前有 25000+ 个包，而 homebrew/core 只有 5000 左右。数量差距如此之大的原因一是 MacPorts 支持同时安装多版本 Python、Perl、PHP 包导致这类包数量较多，二是 Homebrew 的准入标准较高。
2. 准入门槛较低意味着你想要的软件基本都可以自己写 Portfile 提交进来，当然也有些不成文的规定，例如尽可能从源码编译。
3. PortGroup 丰富，CMake？Meson？没问题，大多数情况下照着现有的 Portfile 抄作业就足够了，语法非常直观。
4. ${prefix} 灵活，安装到自定义路径下后可以直接打包成 .pkg 分发，MacPorts 自身的安装包就是通过这个机制生成的。
5. sudo 大法好，多用户环境下也很方便。

劣势

1. 包数量太多加重了维护负担，目前很多包版本都落后于上游。这块只能靠社区贡献了。
2. 软件协议检查严格，协议不兼容时不提供二进制包。由于 MacPorts 的策略是避免使用系统库，OpenSSL 和 GPL 等协议兼容性问题十分常见。Homebrew 似乎没有考虑这个问题，全部提供二进制，用户体验好很多。
3. 自动打包系统规模很小，除了一台 Apple Silicon 的编译机由 MacStadium 赞助以外都在 Austin 由 Ryan 管理。¹
4. port 命令本身使用 Tcl 语言实现。这个语言圈子较小，目前只能通过 GSoC 吃人吸引新鲜血液。
5. 性能较差，安装包时遍历依赖要很久，装的包多了自动 rev-upgrade 会很慢。

参考资料

• https://lists.macports.org/pipermail/macports-dev/2017-September/036377.html
• https://lists.macports.org/pipermail/macports-users/2021-February/049571.html

从 man 5 launchd.plist 可以看出不指定 ProcessType 时，系统会限制后台服务的 CPU 使用率和 I/O 带宽，严重影响对低延迟和 I/O 有要求的无损音频播放。添加 <key>ProcessType</key><string>Interactive</string> 后一般可以解决卡顿问题。

如果修改 plist 仍不能解决问题，可以考虑以下两个 mpd.conf 的 buffer 配置。其中 buffer_time 有个副作用是暂停播放后缓冲区内的音频会继续播放，所以不能配置太长。

audio_buffer_size "8192"
audio_output {
        type    "ao"
        name    "default"
        options "buffer_time=600"
}

参考 https://github.com/MusicPlayerDaemon/MPD/issues/72