On November 4, an update was deployed to our client crash rate tracking system specifically for Android clients. This update was designed to address an existing inaccuracy within the system and reclassified certain sessions as successes which were previously reported as crashes. This reclassification provides a more precise and accurate reflection of user experience and application stability.
Due to this telemetry change, creators should anticipate a noticeable drop in the client crash rate displayed on the creator dashboard. This reduction is not an indication of an improvement in player-observed application stability, but rather a more accurate accounting of the actual crash rate.
The decrease in the client crash rate may continue over the coming days and stabilize as more Android users update their applications to the latest version. As more users upgrade to the new client, we anticipate that the new, more accurate telemetry data will gradually replace the older, less precise data.
Please note: This update is purely a telemetry change. It does not impact or alter the user experience in any way. The underlying stability and performance of our Android clients remain unchanged.
I think this is platform dependent since these are handled by the phoneâs operating system. Some junk brand phones do not follow the correct convention when reporting an ANR/app-not-responding, etc. whereas other phones do.
It would still be helpful to know what the most common conventions are for reporting an app crash versus simply being closed though.
the roblox app (home page and everything outside of a game) runs at about 20fps on my android phone, and itâs a rather high-end one as well. i donât understand why my ipad with 3gb of ram runs the home/game pages better (and in some cases, the games as well, although texture quality is horrible) than my phone with 12gb of ram. please optimize or fix the android app
If itâs VFX I would blame how particle emmiters are throttled, the rate is inconsistent depending on graphics quality. But part of the issue is textures, higher resolutions, leads to higher demand for bandwidth and larger data on your GPU. They really should allow us to use thumbnail textures on SurfaceAppearances, the settings there allow for 420x420 textures and 150x150. They work for everything else, from TextureId to Textures and gui elements, the texture ID is what makes this an arbitrary restriction, and the way roblox compresses the textures anyway on devices with low memory shows that the endpoints do work but for some reason roblox wants to lock down the feature.
It varies by device. Like @PeZsmistic mentioned, different vendors donât always follow conventions, and weâve had to manually fix up the session result to account for these issues a number of different times before (e.g. Xiaomi phones like to report bogus exit reasons & you only see the real exit reason in some arcane sub field). Itâs particularly common with the cheapest Android vendors who are focused more on razor thin margins than making a quality product. Unfortunately, swipe to kills are one of the areas vendors are not very consistent in their reporting, so yes, the creator dashboard client âcrashesâ includes swipe to kill for some devices. Itâs something weâd like to continue to improve over time.
Low FPS isnât treated as a crash. Aside from the swipe to kill issue described earlier, crashes include sessions that were terminated by the OS for any reason (e.g. low memory killer), there was a bug in our engine code that caused a crash (e.g. nullptr dereference), or we deliberately crashed for some reason (such as the application was not responding for a certain amount of time aka hang). In most cases, crashes arenât actionable by developers because they are an engine problem except in the case of out-of-memory crashes which can be reduced by lowering the amount of memory used by the game. Conveniently, the overwhelming majority of crashes on mobile are memory-related (i.e. within the developerâs control)
I donât disagree with that, but Iâll have to say that the amount of memory that Roblox CoreScripts use (that are out of developer control) have significantly risen throughout the years noticeably starting from 2021 which is the same year that CoreScripts started transitioning to React-Lua.
Memory usage on Roblox is very bizarre in general, for example, you can have decently sized game using as low as 300-900MBs on Mobile devices but have an empty baseplate using 1.5GB+ on a Windows device. Whatâs even more frustrating is how the memory amount being reported in Roblox differs from that being reported in Task Manager in Windows and probably on MacOS as well.
I appreciate the explanation (this reply post is one of those things that should just be listed from the start for clarity), but like I just wanna see react-lua thrown away for additional compatibility on weaker hardware
Depending on the mobile device, there will naturally be some differences. E.g. if you are on a 32-bit device, pointers are 4 bytes instead of 8 bytes because there is less address space, which is both a good thing (less memory used) and a bad thing (less memory available). Vs desktop is usually 64-bit these days. Mobile generally uses different graphics APIs than desktop, and some features are degraded / turned off to save memory (but there is no reason to on desktop where there is plenty of memory). The difference will be exacerbated in Studio further because we have up to three game DataModels (edit, client, server) running at once, and memory tracking is application-wide, not DataModel-wide.
Weâre aware this is a pain point. The Studio emulator at least tries to emulate lower mobile memory in some features like streaming, and ideally we can improve it further so it takes mobile feature availability/quality into consideration, but itâs close to impossible to adjust the results to account for discrepancies like pointer size and graphics API. The Creator Analytics team has put in some great work to get you information from real world devices even if you donât physically have them as well, though weâre aware that doesnât completely solve the problem. Weâll continue to try to make this better, but itâs not a trivial process for us. If you have anything in particular that you know would help you with this kind of profiling, feel free to make a feature request & we will keep an eye on it.
Yes, weâre aware of the frame time / memory impact of some of the corescripts (particularly the various PlayerListManager bug reports on the devforum). Weâve had some engineers looking at these for some time now (over a year or two), but because the source of the performance/memory degradation lies in some of the underlying infrastructure such as React-Lua rather than anything wrong the individual corescript features are doing wrong, it has not been easy to address these issues. In features like the next gen Explorer which was written using the same infrastructure, the team was able to work around these issues by effectively âescapingâ React to manage some of the most performance-sensitive parts of the UI, but the Explorer was architected around this from the beginning & itâs not a small fix that can be applied widely across all of the different corescripts. Unfortunately I donât have a great answer for you here, but know that there are multiple engineers actively evaluating how we can systemically address this problem across all internal Lua code.
Bingo! Thatâs how I can now rest assure that all my criticism and concerns about the usage of React-Lua were absolutely right, and that itâs indeed the main root cause behind all the performance and memory issues within CoreScripts. Wish if this was made more clear from the beginning by other teams or engineers though. In fact, they (especially the team behind explorer) kept making claims about how the performance difference wouldnât be major compared to QT or that React-Lua is fast and efficient enough to be used.
Why is React-Lua still being widely used if there are such significant performance impacts? (not to mention the instability of some CoreGui components)
