没有其他操作吗？没有切换场景，创建、销毁资源之类的操作吗？
如果只创建两个 label和button，理论上是静态的页面了，不应该出现持续增长不降的情况的。
没有的 甚至连脚本都没有
不确定是不是因为 sdk ndk gradle引起的
请问你是编译 debug 还是 release 版本？
性能、内存测试，尽量要用 release 版本验证。
另外, 可以用 Android Studio 的 Profile 功能定位一下是那部分的内存有增长，是 java heap，native，graphics 还是 unknown
1赞
debug版本 内存增长的是native 不会下降的
架构是 arm64-v8a armeabi-v7a x86
试试编译一个 release 版本 apk 看看。
我打了一个release包 然后这是就在界面上挂 内存在增长 才10分钟 native从22.x M增加到36.9M
没有脚本 运行没有报错
我们的测试环境是32位的雷电模拟器
那用真机验证看吧。不排除有可能是模拟器的问题。
测试过了 雷电模拟器4 雷电模拟器5 都是32位的 涨的是native增长速度比较快 真机会涨other涨的缓慢但还是上升
同样一个界面开着不动任何操作挂一小时
WebSocket好像也会让内存缓慢上涨
在 3.8.5 中修复，感谢反馈。
为啥这么加一句就好了，能不能告诉下我们，要知其然，也要知其所以然 
其实就是 jni 申请内存和释放内存要配对，否则就会导致泄露。
jbyte *array = env->GetByteArrayElements(static_cast<jbyteArray>(strongRef), &isCopy);
wsOkHttp3->onBinaryMessage(reinterpret_cast<uint8_t *>(array), len);
env->ReleaseByteArrayElements(static_cast<jbyteArray>(strongRef), array, JNI_ABORT);
GetByteArrayElements 和 ReleaseByteArrayElements 是一对。
3赞
原来如此 
这个 PR 中修复：
1赞
这个 PR 的问题是因为啥导致的，看着好像不是websocket的那个 
两个不同的问题。
这个是跟结构体对齐编译器自动padding有关，在 x86 架构上会有问题导致 hash 计算异常，进而导致 unordered_map 被频繁添加不同的元素而导致的内存泄露问题。
3赞
原来如此，希望以后类似这种修复能稍稍的讲解下为啥，虽然不是很懂，但稍稍讲解下为啥，心里也能稍微有个数了 
请问一下，这个pr是不是只有abi 打x86的时候才有用，我们只打armv7 和 arm64的so，在模拟器上跑会不会出现对应泄露？
如果不会，我就不急着合并了。
目前只发现在 x86 上才有问题。
打 arm 的架构跑在 x86 的模拟器上，底层是用 intel 的 libhoudini.so 库来模拟执行 arm 指令集。有些模拟器问题也是很多（比如崩溃）。发布到 x86 模拟器平台，最好选择 x86 的架构，兼容度会比较好。
2赞