Memory monitoring is not so accurate (using RSS instead of the more accurate PSS)

[shijiannihao]

It is found that memory monitoring is less accurate than Android studio profiler memory monitoring?

[Almouro]

Hi @shijiannihao, thanks for posting an issue!

Do you have any examples of reporting that is inaccurate to show? What's the device/os version you're using?

In my experience, Android Studio profiler actually increases the app memory consumption by a few dozens MB so it's usally a bit higher than the reality.

Could also be related to #13 which could completely mess up measures for some devices

[shijiannihao]

Hello, the first screenshot is the memory value of Android studio profiler, and the second screenshot is the memory value viewed on flipper using your plug-in. The device operating system version used is Android 11, not Android 13

[Almouro]

Thanks @shijiannihao for the screenshots! 🙏

Right, this is quite off in this case. I think this is because we report RSS (Residential Set Size, reported also by top and ps) but Android Studio reports PSS (Proportional Set Size)

Basically Android processes can share memory with other processes, so the PSS takes that into account by proportionally dividing the shared memory between the process that share it, while the RSS does not.

So RSS > PSS (see https://elinux.org/Android_Memory_Usage#procrank for more explanation)

Sure but which is the most accurate?

PSS is said to be the most accurate representation of the program memory footprint (and is the one used by Android Studio, so hopefully they're not wrong)

The Flipper plugin with RSS should still give a good value and should help detect potential memory leaks, however the baseline will always be higher than the value reported by Android Studio.

I think we should still move to use PSS instead, however we have some issues:

• RSS was easy to get in a performant way (we just have to read one file)
• PSS requires to read some files like /proc/{pid}/smaps which seem to be denying access (starting with Android 8)
• the only way we can get this value for a production app seems thus to be via dumpsys meminfo which is exceedingly slow (takes almost 1s!! on my Samsung J3)

Plan

When the C++ profiler gets released, I think we can then, periodically run dumpsys meminfo in a separate thread and report the most recent value since even though the reporting will be slow, memory usage usually doesn't change drastically every 100ms

All in all, stay tuned! 🤞

[shijiannihao]

Thank you very much for your reply
In our opinion, PSS is more accurate in representing the memory usage of a process