什么体检？不体检？
什么体验？两台电脑分主内外，还有 usb 封禁，转虚拟桌面开发，虚拟桌面和本地不可互通

这就解释了玩啥能坎大山的会拿到远比实际能力好的 offer 的原因，手动狗头
瞎 j8 吹呗，反正大家都不知道，说的连你自己都信了，面试官都觉得你对👀

如果你的初始 iv、key、salt 什么的明文传输，那么 cbc 也没有意义吧，cbc 是链式的，只是拿前一块密文异或下一块明文后加密，又不是魔法，安全传输还是考虑下 https 比较好
到了服务器了，你是不是 cbc 也无所谓了吧

有点想笑，反对的义正言辞，自己却在上班时间摸鱼来上 v2，拿着老板的薪水，替自己摸鱼就无所谓，偶尔替前老板解决下问题就是不对，这很双标

异步消息说错了吧，postSyncBarrier 和异步消息执行不执行没有什么关系，只不过是有 barrier 的时候，只执行异步消息，没有 barrier 就无所谓异步还是同步

代码加密是什么鬼？

getReceiverInfo()是从 mSettings 里查找，未找到就从 mReceivers 查找呗，查找源不通而已

@ysc3839 我知道问题在哪了，DisplayMetrics.xdpi/ydpi 代表的是实际的物理 dpi，这个值两个 pad 返回的都是 224、225 左右，我的布局出现偏差问题在于我绘制布局的时候调用了 Resource.getDimensionPixelSize 这个方法来转换 dp，而这个转换方法是以 dp*DisplayMetrics.density , 这个 density 正是你说的系统设置的 densityDp 相对于基准 160 的缩放倍率
我只要用 xdpi 计算实际的 dpi 的缩放倍率来重新计算应该就可以解决我的问题了

@ysc3839 但是单位 dp 对应到屏幕的物理大小的确在两台 pad 上是不一样的，同样的布局在两台 pad 上展示并不相同，那么这些设置对 dp 的计算会产生什么样的影响？考虑实际 dpi 本身就是为了适配，即使这些设置不代表实际 dpi，但确切的对适配上产生了影响

@ysc3839 即使这样，也无法解释相同尺寸和分辨率的 pad 具有不同 dpi 这个问题，所以我好奇到底哪一环漏了

基础是基础，谁的基础？应用层开发的网络交互撑死到传输层，不面试谁关心你 ip 头什么组成，万年用不上，就像 9 楼说的，知道包含来去 ip 不带端口就不错了，但要是做什么交换机系统的，这可能就是工作基础
你要说这是所有人的基础，妥妥“八股文”

@BBCCBB 会用 linkedHashmap 去实现本身就说明理解了思路吧，不然问为什么用说不出来不是一样么

@BBCCBB 没有啊，你既然都用了 HashMap 本身就表示接受 JDK 类了，HashMap 本身也是优化后的实现，既然不能用 LinkedHashMap，那么就不能用 HashMap，那么文章里就应该用数组自己去实现 Hash 存储

没研究过，不过可以抽象看看
首先，要确定 audiorecorder 录的声源，是直接录环境声音，还是直接读取声源
如果直接录的环境内的声音，我觉得肯定是分不开的，因为没办法区分是谁说的
如果直接读取声源，那通话对象的声音至少是读取音箱，更上一层可能读取通信信号，而当前手机持有人的声音应该是读取的麦克风，这样自然就是分开的，你只要分别录制两边的声源就好了
我觉得这个挖起来至少要挖到 HAL 层以下了，不熟悉系统可能挺难的

既然已经用了 HashMap，直接 LinkedHashMap 可破，不需要自己再去实现链表吧
count > capacity 时，你需要 foreach map 逐个排除，直至 count 降到 capacity 以下，这里是以个数为准，所以直接踢掉 tail 也可以

概念不一样而已，微信提供给你的只是他认为是缓存，可以让用户自行管理的比如聊天图片之类的文件大小
系统则是在应用层面提供数据，包括微信安装后跟微信有关的空间占用，比如微信自身的 sqlite 数据库，so 文件、apk 内封装的多媒体文件资源等等

2，8 有用

裸辞期间是最有动力学习的
今天面试败了，我艹，赶紧补补没答上来的，下次面试又有信心了
已经一个月了还没有 offer，我艹，赶紧上网看看技术博客，又充实了一点点
把焦虑感转换成动力，不努力又没 offer 会形成堕落负罪感，又能提升强制学习的想法，形成正向循环