I guess I always looked at Android's propensity to killing processes ultimately not just as a RAM saving tool, but as a battery saving tool.
That whole process lifecycle thing that you have to jump through with activities and bundles and what have you is so that your app disappears not just out of RAM, but out of the scheduler too from a piece of code that can make such decisions at a complete system level. Yes, it kills processes essentially arbitrarily, but the processes should have all of the hooks and places to squirrel away state to come back from the aether as if nothing happened. Programming Android code should embrace that rather than fight it.
As for webview, I think they're generally pushing a security fix and think that your app should be able to pull itself back together, the same as if a browser was refreshed.
I do have 5 tablets in my home, held with magnets against the walls, which do nothing else but have a custom app running which displays a full-screen WebView.
It shows stuff like weather, clock, calendar, land-line phone calls and has buttons for light scenes.
I used to use Chrome for this, but I always had to manually maximize the page, and hosting it in a custom app has additional benefits, like loading and maximizing the page as soon as the device boots, and offering a JavaScript interface so that the page can interact with Java functionality. It's much better that just hosting the page in Chrome.
Each time Chrome gets updated, the app gets killed. And even though the app has set up an alarm which makes Android call into the app every minute to ensure it is running, for some reason this doesn't bring up the UI (probably something which I need to debug).
But I know that if this app were running on Linux directly, in some Python Qt app with a Qt WebView, it would never get killed, as it has plenty of resources available.
I've also considered integrating Mozilla's rendering engine into the app, but decided not to, I can't remember why, but there were some drawbacks in doing so.
It would be hard to imagine using such an app in an industrial setting, where the app would need to be visible all the time, displaying gauges and stuff like that. The hardware could do that, with a proper OS.
That whole process lifecycle thing that you have to jump through with activities and bundles and what have you is so that your app disappears not just out of RAM, but out of the scheduler too from a piece of code that can make such decisions at a complete system level. Yes, it kills processes essentially arbitrarily, but the processes should have all of the hooks and places to squirrel away state to come back from the aether as if nothing happened. Programming Android code should embrace that rather than fight it.
As for webview, I think they're generally pushing a security fix and think that your app should be able to pull itself back together, the same as if a browser was refreshed.