Most tweaks are simple function hooks that change the code already in memory. The only way one of them was to go bad is if the creator alters a bit of programming that effects more than anticipated.
Tweaks will release ram. Most tweaks use a very, very small amount of ram that is hardly noticeable.
Do you feel these things in some way contradict what I said?
iOS is designed to be used with very little free ram. Most UNIX based operating systems are. It doesn't become unstable. The instability is all within the user's head. Those that don't obsess over free ram, report their device to be very stable.
I haven't said the iPhone becomes unstable by simple having a small amount of free RAM though.
You do realise that the freezing is less than one second and a much better solution than manually closing each app and waiting through the resulting <1 second freeze?
I'm not talking about deleting the suspended state of previously used apps, which I even pointed out.
Did you misinterpret my previous posts, perhaps?
Springboard using that much CPU and ram is very likely the cause of a poorly writing tweak or an incompatible tweak.
Yes, I'm extremely aware of this. What's your point? Your whole argument is that one never has to worry about RAM and whatnot, I'm just trying to say that with a jailbroken phone, low RAM can in fact prove to be a much bigger problem than with a non jailbroken device since some tweaks simply makes the iOS' memory handling far less effective than it is under normal circumstances.
I'm not supporting the "OMG I ONLY HAVE 200 MB OF RAM LEFT WHAT SHOULD I DO"-crowd, I'm saying that if you're not getting more than very little free RAM even after having killed off the apps and seeing a clear difference in performance, increased number of low memory warning and app crashes - there is something wrong. Saying there isn't a problem and that iOS handles memory great just isn't very relevant or accurate in these cases...
Springboard only releases ram when idle. That is how iOS is designed. Apple knows about the slow down and built in the idle requirement. With the version of Instruments the general public has, it causes Springboard to not go into an idle state as it has to relay device stats to the computer. That's why you're seeing false readings about it never releasing ram.
Although I can replicate it with or without having it connected to the computer, and Springboard is not releasing more memory when not connected than when connected.
But a funny thing I noticed is that when Springboard is using copious amounts of RAM and opening a memory intensive app, Activity Monitor and Highlights report different amount of real RAM (the pie chart in Highlights seemingly giving the correct, lower value).
Your posts are even more full of it. Start coding your own apps and tweaks, followed by intensive study and informative talks with Apple iOS engineers, then you may know something worth mentioning.
I interpreted your previous post as if you were saying that low memory due to apps/tweaks hogging resources in a manner that Apple approved tweaks and apps normally won't can't cause app crashes or system wide instability. Also, that you said that low memory is never a problem when in reality low memory logs just before a restart of Springboard are far from uncommon made me doubt you.
----------
I would like to add that in theory almost all OSes nowadays should handle the memory issues without restarts or resprings.
But practical scenario is far from ideal. I have attached the screen shot log of my diagnostic reports. At 8.25 PM springboard crashed on me for no reason and when I saw the log it was the low memory.
And yes it was after being jail broken. Before which I have had low memory logs but it never crashed my phone. So jailbreak tweaks are not that perfect and for some reasons iOS cant deal with memory issues when jail broken.
Some tweaks aren't perfect and iOS can handle most memory issues despite being jailbroken. It's memory issues due to crap tweaks that causes the problems
