你原来 12k 月薪按 955 算，时薪是 68.97 元
而新的 25k 按 996 算（你说的上班时间 12 小时？），时薪是 80.9 元（月平均工作日取 25.75 天）

这其实算起来只是给了你加班费，平时加班按法律规定 1.5 倍，看起来工资多了，更多的是依靠延长工作时间获得，而不是依靠提升单位时间的价值获得。

开源的意义在于如果原作者不愿意，我们可以自己动手，如果你愿意可以把代码 PR 回去，如果不愿意，也可以自己维护一个版本。

因此原作者不愿意添加某些功能影响也不大呀，如果自己不能、不会、不愿意添加自己想要的功能，这时候也许要考虑付费了。

9900K 编译一次应该不需要这么久，即使是全量编译也不需要，检查一下是否磁盘存在瓶颈。我用 8700 全量编译也就 1 个小时，之后增量编译就 3 分钟以内（如果跳过 CTS 检查可以到 1 分钟以内）

我有一台工作电脑，非常的神奇，有一块 AMD 亮机卡和 i7 10700，同时外接了三个显示器。

只要使用 Chromium 内核的浏览器在外接显卡的显示器上打开腾讯视频就蓝屏，显示内存分页错误。

这应该是 7 层干的事情，网络层去搞，非常麻烦，要不你统一在目标应用上加前置代理，由前置代理决定出口，如果目标应用不提供使用代理的功能，就套上 proxychains，这相对来说容易实现，成本也低。

而你要分析 HTTP 头，那注定不能是 HTTPS，除非客户端信任你的自签证书，也就是说本身你的应用场景应该就是可控的场景，而不是针对任意第三方，所以加代理可能是比较容易的。

因为 markdown 在有渲染的情况下，表达能力比纯文本丰富，在没有渲染的情况下，由于标记简单，肉眼也可以看出格式，几乎不影响阅读。比如想编译某个项目，git clone 以后，cat ./README.md ，即使没有富文本渲染，也可以阅读。而在 GitHub 网页上，渲染后阅读效果更好。

而 HTML 不渲染，人眼是没法看的。

可以走庭前调解，法院出具调解书，有强制效力，事后还可以通过调解书申请强制执行。

一般来说，向下兼容是不错的，不过不同版本的 JDK，不同厂家的 JDK 可能对一些细节实现略有不同。
比如 new File("sample.txt")这种使用了当前工作路径的，有可能行为会不太一致，这玩意还是要多测试，大问题是不太有的，小毛病就看造化了。

五一出去了一趟，往返全程约 2000 公里，差点凉在路上，太累了，1 天超过 500 公里的驾驶，自我感觉就是磨人了。

一个是现在的网络和存储成本非常低，另一个是 JavaScript 的开发成本同样很低，这当然就用脚投票了。

至于性能？这年头大多数客户端应用都对性能不敏感，1ms 响应和 500ms 响应用户也不太能感觉出来。

五一也准备这样，杭州出发到青岛，自驾一路，停到哪里，就在哪里玩，没有固定景点。充气床垫、帐篷、蚊帐这些也都准备好了，就准备趁着最后年轻的几年去浪一把。

轨迹记录可以试试看：两步路户外助手

如果没有 HTTPS 的话，和 JWT 没有任何关系，即使你每次都走验证流程，账号密码依然可能被中间人拿到，其结果是一致的，因此假设客户端、服务端可信，而信道不可信，则需要使用类似 HTTPS 的解决方案，比如应用发出请求时就 AES 一遍，如果客户端与信道均不可信，那么此题无解

如果用过正版的 Windows，如果系统出现故障，是有 24 小时技术支持的。

这对于国企非常重要，一旦出现文件，有人背锅。背锅远比赔钱重要。

Oracle 出现故障，可以甩锅给 Oracle，Oracle 有专人负责处理，而 MySQL 出现问题，只能是自己的问题，你不能说这是社区的问题，因为这玩意本身就没有技术支持。

能看就架不住截图、外部设备翻录。

所以：
1 、用户侧设备不持久化保存
2 、服务端下发的文件可进行 AES 等方式加密，避免中间人或内存中获取明文
3 、如果有能力直接下发图片并且签署盲水印，做到事后泄露能够回溯源头。但是盲水印对抗翻录的效果也不尽如人意。

可能是地区原因，我这里一个月上传要 2~3T，还没有限速过（不过确实所属小区的联通用户非常少，主要是电信和移动）

现在 Android 应用几乎不太有不给权限就不能用的 APP 了，而设备唯一标识符、IMEI/EMID/MAC 等等，原生 Android 也很早就不允许获取了，而 Android ID 本身就是可重置，OAID 用途和 Android ID 类似，只不过重置 OAID 更轻量级。这与应用是否在小米商店上架并没有关系。

至于隐私对于设备制造商而言都是不存在的。因此，作为新西兰用户，你更相信一家美国公司，还是一家中国公司，就这点区别而已。

@RikkaW #1 感谢大佬。

简单梳理了一下，也为了方便后人，整个流程大概是这样（以 Android 10 代码为例）

目标 APK 能够获取到的 Service 是在 ActivityThread.bindApplication 方法中获得，此方法中对于应用不应该访问的服务给出了警告，但是没有拒绝访问
```
if (ServiceManager.getService(name) == null) {
Log.wtf(TAG, "Service " + name + " should be accessible by this app");
}
```
而该方法中的 services 参数是由 AMS 发过来的，继续往里跟，可以得到 ActivityManagerService.getCommonServicesLocked 方法，在源代码中也可以看到一些注释
// Add common services.
// IMPORTANT: Before adding services here, make sure ephemeral apps can access them too.
// Enable the check in ApplicationThread.bindApplication() to make sure.

最终方法落到 ActivityManagerService.addServiceToMap，此方法中调用了 ServiceManager.getService

综上，可以得到，一般应用程序获得的 Service 是由 AMS 获取后通过 Binder 发送给目标应用，此时由于 AMS 本身是有权限获得 Service 的（这也就对应了大佬说不需要专门允许应用进程 find service_manager ），而在目标应用内对获得的 Service 列表有一个权限检查（即 AMS 传递过来的 Service 应用本身是否可以获取），即通过 service name 再次通过 ServiceManager 获取，如果返回 NULL，则输出警告日志，是否影响后续使用需要等待我测试一下。