Memory management within a resource constrained architecture is always a challenge - and it has to be said that memory management within iPadOS13.x has had a bumpy ride.
Assuming you have updated to iPadOS 13.3.1, your iPad Pro should be relatively stable; some earlier versions were really bad at unexpectedly ejecting processes from memory. If you’ve not undated to iPadOS 13.3.1, you should do so.
Some understanding of how memory management works within iOS/iPadOS might help. This is not an in-depth explanation, but will hopefully capture the essentials in basic terms...:
Your iPad/iPhone will always attempt to use most of its available RAM - unused RAM in this system architecture is pointless. Apps are generally in one of four states - the first three are the most relevant.
- The App is “Active” - it is running running in the foreground. When you switch tasks, the App will continue to run in active state for some minutes before its resources are released and is placed into an Inactive state.
- The App is “Inactive” but remains loaded in [fast] RAM. In this state, the App can be instantly restored to an Active state - but is not consuming CPU or other resources whilst in the inactive state.
- The App is “Inactive” and unloaded. In this state, the App has been completely offloaded (releasing RAM for use by other processes) but its running state has been saved to [slow] flash memory. Returning to an App will cause the App’s saved state to be reloaded from flash memory into Active RAM.
- The App has been closed. All running data has been expelled - there is no “saved” state; relaunch will reload the App from scratch.
Memory management is generally a juggling act - and for the most part, if Apps are not left “dormant” for too long, iPadOS does a pretty good job. That said, the “multi-tasking” features of iPadOS adds considerable stress to the decision making process - as more system resources are consumed.
The seemingly biggest area of problems appear to occur with web-applications (e.g. webmail) - or web forms (like this page). Switching away to another process (App) on the iPad causes the Safari process to be temporarily “parked” in an Active state; whilst in this state, you can switch back and all should resume without issue. However, if the “parked” Safari process becomes “inactive” - at present returning to Safari may trigger the focussed page to reload; anything not previously submitted/saved to the web form will likely be lost to the page reload. This phenomena is not unique to iPadOS Safari - it can been seen on all other platforms - but is perhaps more likely to occur within a resource constrained architecture such as iPadOS!
Now, some of your observation relate specifically to Google Docs... this being a primary example of a web-App that may be adversely affected by page timeouts and reloads. With adequate network bandwidth - and a desktop computer with similarly adequate system resources - Google Docs can be used largely without issue.
I hope this info proves to be helpful - if only in providing some explanation as to what might be occurring.
