@KunMinX #5
@RikkaW #6 的补充可以更好的理解这个问题，因为如果分享的是 file:// 的话，读写的是 B，A 丧失了主动权，无法控制权限范围和时效，但是用 FileProvider 的话，读写的是 A，A 对自己的内容拥有完整的控制权。

换个角度想，App A 要分享一个文件 F 给 App B，对于 A 来说，要么把这个文件写到一个外部路径，让 B 去获取（ A 需要文件权限）， 要么 A 把自己的内部文件权限给 B （基本上不可能也不安全）。在这种情况下，FileProvider 表示，你可以给一个只有 A 你自己能明白的路径给 B，并且只给 B 这一个路径的权限，这样 B 在读取的时候就可以安全的拿到且只能拿到这一个文件了。

所以说保护谁这个问题， 一方面保护了用户，不是每个需要分享功能的 app 都必须给文件权限， 另一方面保护了 A，因为它可以很方便的控制自己对外部暴露的内容，对于 B 而言，这种方式更像是一个黑盒，不需要关注对方有什么其他的东西，给我这个我就用这个。

个人拙见，希望有所帮助。

进大厂锻炼一下能力，然后去外企啊，只要对工资要求不那么的高，工作强度和福利保障绝对令人满意

Kotlin ？

Xbox/PS4/Switch/Steam 全修，还是 Switch 玩的比较多，不过最近打算 PS4 好好玩玩了

都已经有了 Pro 了，就用着呗，这两个体验相差不少呢

放在下面太占用空间，比如写代码的时候，上下多一排意味着多看几行代码，放在左右可以节约竖排的空间

英语和算法一定是非常重要的，算法是在这个行业内想要往上走必备的知识，英语是想要在这个社会往上走必备的能力。不管最终去哪里，学这两个一定不会错

log 太多把 buffer 冲掉了，看看能不能把 buffer 变大些

Foreground service + CPU Partial Wakelock， 再打点 log 看 network state，有必要的话可加 Wi-Fi lock

@wpblank 这话听着好分裂啊哈哈哈

大学毕业以后新买的衣服几乎都是优衣库......好像也该换换风格了

有，foreground service + Full screen intent + activity

可以创建多个实例，只是 default instance 是个单例。
至于有没有必要，看业务需求，大多数情况下我认为是没有必要的。

@maty 以前项目用 swig，现在项目用 jinja2，我个人比较喜欢 jinja2

@maty 手写？ AS 啊，我们写了一些包装类和 helper，除了那部分的代码很少会直接调用原生 JNI，所以你说的这种飘红的状态我遇到的不多。

我们的 JNI 都是生成的。。。少部分手写的没这个问题

@Livid AppRTC 能满足么

这样的系统，方案应该很多，但是 host 不太好找，self host 的话对带宽要求比较高，而且有法律风险，cloud host 的话资费不便宜。可以考虑一些公司的免费服务，但不一定有 TV APP