@18258226728 #26 根据参数类型划分接口么。。。我们的思路是根据功能划分接口。

@yanyueio #15
@daveze #12
@Freeego #11
@neptuno #10
@lurenw #9

一个接口的原因是希望这部分逻辑对客户端隐藏，客户端也只需要把自己本地的 sdk 传给它的数据传到服务器就行。采用哪种 sdk 是由环境决定的，基本上在构建期间就会把这个配置同步到前后端。

说用 bean 的各位大佬，有个场景看怎么用 bean：

一个接口需要适配若干种 sdk，每种 sdk 需要的参数都不一致（基本没什么共同点），接口参数就是 sdk 需要的参数，具体用哪种 sdk 由配置决定。

这个入参怎么用 bean 呢？

这应该放在推广结点

原来那个.js 是库名的一部分。。一直以为是源码包的文件后缀。。。

纯 java 做不到。。只能 jni，GPU 相关的逻辑用 C 实现。

@LowBCoder #4 说 FilterInputStream 是 InputStream 的代理而不是装饰器的原因如下：
1. FilterInputStream 并没有给 InputStream 扩展任何功能，只是持有了一个 InputStream 的实例，所有的操作都转交给持有的这个 InputStream 的实例去做；
2. BufferedInputStream 和 BufferedInputStream 可以说是装饰器模式，都为 InputStream 增加了不属于它的特性；

抽象出一个用于代理的实现类而不是把同样的方法按照挨个在 BufferedInputStream 和 BufferedInputStream 里实现一遍，最显而易见的原因就是为了使代码简介，使用到了代理这个特性，所以抽象出一个代理者。

FilterInputStream 是代理模式，DataInputStream 和 BufferedInputStream 都使用了代理这个特性。

reviewer 告诉你不行肯定会告诉原因的，如果你觉得不合理可以刚啊。。

不要 catch throwable，全局设置一个默认的异常回调
```java
Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {...});
```

不可以，此题完结。

把她的 vx 推给我，我帮你教育她

这样就可以了，方法签名的参数类型信息是带泛型信息的。

@lihongjie0209 #2 根据约定，JavaBeans 一定是可以被序列化的，你展示的注解给序列化和反序列化带来了不确定和不一致，由此可能产生无数 bug。

没有。感觉这种东西不但没办法解决问题，还会造成问题。。

源代码的编码和运行期的内存毫无关系。

技术本身不会带来变革，需求才会带来变革。。

5G 能带来的需求无非就是高清晰度视频、物联网、云游戏之类，对现有服务端技术感觉不会带来颠覆。。现代 CDN、函数即服务这些都很成熟了。。

@yuxianjiazu #13 啊是的，我拼错了。。。

@diver02 #8 好吧，如有冒犯请见谅。很多初学者上手就刷 OJ，其实是个很坏的习惯。最基本的，大学计算机本科的数据结构和算法两门课程（有些学校 /专业是一门课程），把里面的所有知识点都过一遍，没有任何前置课程要求，正常毕业的高中生都能理解。队列和优先队列前者在数据结构书上，后者在算法书上。