@ChefIsAwesome px 的大小取决于屏幕尺寸和分辨率的共同计算吧，相同分辨率，不同尺寸，px 自然不同

遗留代码内有非常多的全局变量在各种地方各种时机被修改赋值，你还需要追踪，令人崩溃

包是能抓，但是能不能解密对楼上说能解密的持怀疑态度
而且我刚才试了想看看图片是不是明文，但发现，Android Pie，play 下的 7.0.3 微信，微信的连接不走 WiFi 代理，估计是 openconnection 用了 no proxy 绕过去了，那就只能网关抓包了

一会修改 xml 一会儿修改代码这种说法并不对，Android 是 view 和 control 分开，互不影响，你一会儿 xml，一会儿代码说明是你自己开发的时候思路就没想好，一会儿写界面一会儿写逻辑
findview 的问题现在也有各种取代方案

@zyxk 对称加密不传 key 服务端不能解密吧，不是要服务端能解密？

什么体检？不体检？
什么体验？两台电脑分主内外，还有 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 这个问题，所以我好奇到底哪一环漏了