I am currently working on a game using THREE.js that will be embedded into a UIWebView within an iOS8 app.
After analyzing the application in Chrome's developer tools, I have confirmed that there are no memory leaks present. The memory usage reaches a certain point and remains consistent throughout.
However, when running the application in UIWebView, I noticed that the memory usage gradually increases over time, indicating a lack of garbage collection.
Despite my research online, I could not definitively determine whether iOS8 UIWebView implements garbage collection. Some sources claim it does, while others argue otherwise. If it does indeed include garbage collection, how can I activate it?
If garbage collection is unavailable, my current workaround involves periodically terminating or deallocating the UIWebview, and then restarting the application (specifically at the menu screen for a game).
UPDATE:
Further investigation revealed that deallocating the UIWebView does not resolve the issue - the system fails to deallocate all resources (even after trying various techniques) leading to exacerbated memory problems.
The uncertainty regarding UIWebView's mark/sweep garbage collection persists, although data from the Profile/Instruments panel suggests its presence. However, the memory usage rarely decreases. Logically, some form of garbage collection must occur as temporary objects in code and out-of-scope entities do get cleaned up.
It appears that my THREE.js elements are not being properly collected, possibly due to the need to manually dispose of resources (such as GL-related handles) according to THREE.js protocols.
Anomalies related to .bind(this) function remain problematic - functions initialized with setTimeout(object.func.bind(object), 100) seem to persist even after dispatching the timeout. As a result, I preemptively bind and store these functions as variables instead. Similarly, jQuery event handlers encounter similar issues.
To address memory management in my two-scene game setup (with menu and game scenes), I opted to retain both scenes in memory indefinitely rather than removing them. Objects and models created during gameplay are recycled instead of relying solely on garbage collection. When an object is removed from the scene, it is placed in a pool of similar objects for future re-initialization and addition back into the scene when needed. While this approach initially seemed excessive, it has proven effective in preventing memory leaks and expediting object creation and addition to the scene.