问题背景
近期开发过程中,踩了一个坑, 只在release包下稳定复现,本地debug包 没有出现问题。
当你辛苦写完一个页面,打开Layout Inspector 发现不能使用
1 | Could not download androidx.compose.ui:ui:1.5.0-alphao1 from maven.google.com. |
业务场景存在一个JSB,FE同学传了个JSON到端上,端上测试的时候都是正确的,有天调试Server反馈说id值找不到,端上id值回传错了,开始排查代码。
发现Jsb传输过来的Json都是String to String的格式, 类似这样
自己在平时工作中发现的一些不错的工具,记录下,方便在切换外部环境的时候,快速找回持续更新
你可能临时起意想要尝试,最好先确认一下自己的软硬件环境
fatal error: runtime: out of memory
如果你是要看源码,用不着下载
在A 跳到 B ,再跳到C的过程中,一定条件下发送广播,需要把B关掉,达到的效果就是 C直接返回A。
但是现在出现一个Bug就是C返回的时候,还是B。当时没有打印onCreate的日志,只发现B在前面finish了,居然又在后面onResume了,这显然违反科学。当时想就算B启动了多个,B也都在onCreate的时候注册了广播,都应该可以收到广播的。后面怀疑是手滑不小心点击了2次,或是系统突然响应过慢,点击了多次,造成创建了多个实例,所以我直接通过for循环快速模拟这种情况。
我们写JNI的时候,通常要通过 如果需要反调java层的代码,是需要通过jvm->AttachCurrentThread 将当前线程注册到虚拟机中,为什么一定要调用这个方法呢?我们追一下这个方法里面到底做了什么?