“哪怕是 FCM ，也极为依赖 App 的后台机制，需要 App 保持在后台运行，在内存里存在进程，FCM 才能正常推送”

不太理解这句话。

如果说的是 Notifications Composer ，并不依赖 app 进程。都是通过唯一 ID 进行系统级别的下发，然后直接唤出 notification 功能。点击后可以携带参数，app 在根据当前的生命周期进行逻辑响应（唤醒、调出对应业务界面等等）。

反之如果是数据消息（国内推送往往叫“透传消息”），确实需要应用保活，因为需要 service 处理传递过来的字符串，但这并不是一个常见的场景。因为需要 service 或者 app 加工时，app 也往往在活动中。

hack news

既然是没有电池需求（也就是不需要便携属性，只需要移动属性），那就不如自组一个 ITX 吧，比笔记本的性能释放好，性价比高。

有多种可能，除了楼上的欠拟合，loss 跑飞了这种模型角度的叙述。

还有一种就是过拟合，导致最终落到了错误的局部最优，而不是全局最优区间。

任天堂的两次性能革命都以失败告终（ N64 和 NGC ）。

群晖和 icloud 并没有使用成本，上传（或者理解为备份）都是无痛的。

1 、可以多摄像机，也可以单摄像机拍几次。
2 、声音是单独的一个音轨。（可以完全单独录，也可以挑几条不同机位视频里效果最好的一条）
3 、每种乐器都有不同的录制技巧，需要具体问题具体分析。比如吉他有专门的琴麦。
4 、个人用手机，且只有一台手机的情况下，就几个几位录几条。然后多轨合成。