不会是 JNI 和 Native 在内存分配上没有协商吧，写这两个模块的人要有清晰的职责划分，不然，就是一团粥

多喝水，能上厕所，不容易患结石，上厕所能活动筋骨，有条件还能远眺以下，也放松了眼睛，一举多得，毫无成本，也没有副作用

三星，之前做电视 APP 开发时，觉得三星是最棒的，（不特指显示

送花，送花，送花

切了，难受两星期，后面就不会那么容易感冒啥的了

是，感觉还能等等的想法，都是不需要或者可替代。当然，买了也方便，当个 kindle 也行

这个 IP 显示真的需要对策吗？不需要吧

QUIC 已经于去年标准化了，当然，还是 google 自己一套，非 Google 的一套，Google 自己那套并非完全符合标准化的 QUIC 协议。当然，效果不错，现在很多公司都上了，如果你不是家宽，QOS 的可能性也不是太大吧?

我比较欣赏 GitHub 的 API ，也比较好套用到自己的理念上

更多的是非代码的东西吧，主要 封装协议，http adaptive protocol ，常见 codec ，和 rtc ，主要就这么几块

看的 Android.com

@Tolcol 多谢。问题不在这里，这两个获得的 view 对象是同一个。根本原因在其他地方（后来发现切换横屏导致了这段代码执行了两次。）。thread 结束

C/C++ 没有那么卷，面试的时候不用背太多被太多八股文，也不用说 HashMAP 的原理。

还是交给云不错，只靠 java 很难做到高性能的音视频处理。推拉的过程带来的时延和卡顿一直都是业界研究的重点，比较靠谱的方案是推给 CDN ，这个 CDN 还是得支持 http chunck encoding 的，使用 low latency 的 DASH/HLS, 延迟能到 2s 左右，但是这都是商业方案才能做到的，开源方案基本上没有较好的办法

搞这个的，分推拉，推的话，国内主要用 rtmp ，（ youtuebe twitch 也是），你可能需要在服务器段进行转封装或转码，这个想简单的话就 ffmpeg 了，或者有音视频开发资源的话，自己去开发，成本比较大。拉流就随意了，DASH/HLS 都支持 low latency ，还是有现成的方案的。主要还是在服务器这里，没有 C/C++ 技术栈去深入的话，基本上就只能用现成的。

前者不知道，智慧树是夫妻店

就算是三星，开了几个国产的程序后，就会梦回 2013 ，Android 2.2 的时代