一般来说，向下兼容是不错的，不过不同版本的 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，则输出警告日志，是否影响后续使用需要等待我测试一下。

感谢大佬，自己写了个 chrome 插件测试了一下，确实原来不能使用网页版的微信号可以登录了。

还是挺期待的，就前几天写的一个 Android framework 模块，由于存在需要读取的配置文件，来创建目录，结果没注意文件结尾时 CRLF，在 Android 设备上创建出来的目录，死活都带上了\r

大意了

讲真，开发环境，除了 Windows 开发意外，都对 Windows 不是很友好，把一个纯 c 的项目交叉编译到 Android 上，各种工具链，也折腾了我一天。最后还是 WSL 编译好了，拿出来用，Windows 里放弃了

假设 a.jar 包含 com.sample.MyClass，b.jar 包含 com.sample.MyClass，
a 与 b 的功能完全不同，则可以考虑在编译时，不引入 a.jar 与 b.jar

在使用期间（运行期间）通过不同的 ClassLoader 分别加载 a 与 b 即可
对应到 Android 即 BaseDexClassLoader 。

缺点是需要通过反射调用 a 与 b 的方法，当然如果他们有共同实现的接口或共同的父类，可以把这个这个接口或类放到主 jar 中，可以方便调用。

盲猜困难，Chrome 都已经不支持 Windows 7 很久了，况且 Edge 是套壳的 Chromium 。

转投 Firefox 吧

@Jat001 #7，便宜是便宜的，可本地游戏的硬件成本由玩家承担，云端的硬件成本由发行方承担。

阿里云香港节点有免费的流量，因此访问流量不大的情况下，可以试试，国内访问速度也很不错。

大城市应该区别不大，乡村道路个人感觉高德明显好于其他。

哪个人可以拒绝一个逗逼导航呢，所以是高德的团子语音。

可惜车载是厂家和百度合作的 OS，不能自己装高德地图，很遗憾了。

这个可能和具体设备有关，我目前用的 Surface Pro 6 识别速度是非常迅速的，即使在全黑环境下，识别率和识别速度已经非常迅速，通常可以在 1~2 秒以内完成，也就是当人坐下，稍微一抬头就已经完成了解锁。

系统大家是一样的，所以盲猜这可能和具体负责图像识别的硬件有关系