I am getting aw snap or sometimes not enough memory problem when I reload my WebGL page. I have a WebGL project which is empty (just a camera + light), developed in unity3d. I am reloading it, and profile its memory.
As you can see that its load 1.2MB in the first load than 1281 MB in second then 1574 then 2160 and then get crash. I am amazed that why it is happening?
I searched and found that
One of Unity fellows told that when browser Dev Tool is open, each page reload will increment the memory:
"
One point to note is that when profiling memory usage on page reloads
in Firefox, make sure to have the Firefox web console (and debugger)
window closed. Firefox has a behavior that if web console is open, it
keeps the Firefox JS debugger alive, which pins all visited pages to
be cached in memory, never reclaiming them. Closing the Firefox web
page console allows freeing the old pages from memory
BUT
My testing suggests that it is true for Chrome but not for firefox. Firefox keeps increments the memory with each page reload no matter your Dev tools are open or close.
But my problem resolve in chrome (still question on firefox? I guess it the default behaviour of browser), after closing the dev tools memory is not incremented on chrome.
the problem
the webgl build runs fine on every desktop browser and firefox mobile, but crashes after 3 seconds when using chrome mobile or safari mobile with the "aw, snap" page.
the problem was the amount of RAM that the project was using for loading assets.
i found that the main problem was loading the audio system.
when the game started the RAM usage quickly escalated from 300 MB to 1,3GB.
how i fixed
i had a background music 20 minutes long, i cut that to 5 minutes.
click the music, then click override for webgl
set the load type to Streaming
set the quality to 1
with this workaround the RAM usage floats around 600 MB, this allows the build to run on mobile.
this is an example
EDIT
turns out that after ios 15.5 update everything runs fine.
Related
It is well known that Chrome intentionally throttles javascript setTimeout calls for background tabs to a minimum of 1 second, however very recently (Chrome 75 on MacOS 10.13), I have found that my Chrome App is still throttled after returning to the foreground and remains throttled until I close and reopen it, after which setTimeout works as expected.
This does not happen unless the app has previously been in the background or unused for a considerable period of time (e.g. hours). My issue is that returning it to the foreground (i.e. interacting with it) does not speed up its behaviour and I would rather not require my users to close and reopen it.
I have read in other questions on this topic that continually playing audio is a work around. Please can someone point me in the direction of an example of how this can be done natively in a Chrome App i.e. without adding too much bloat.
I am using crosswalk to better support older android devices. But app has 5% CPU even doing nothing and even in idle state on background.
Removing crosswalk from project solves problem, but I want it to stay included because of the benefits.
I have found two things what makes the CPU.
1. animated gif image
2. bug in ionic wrapper of device motion cordova plugin (acceleration watcher never stop then)
animated gif: I had animated gif as loading spinner in my index.html while my app becomes available. On mobile phones it was not visible at all, because splash screen is turned off after app init, but it was for browser use. Removing this gif solves about 3% CPU
I have device motion plugin in my app and I was using it as described in ionic docs, so if not needed anymore I have called unsubscribe. But ionic was not calling clearWatch method correctly (with wathID parameter), so the watcher never stops. It caused another ~3% CPU. As an workaround I have used plugin directly, bypassing ionic wrapper as described in cordova docs.
Removing those two problems I get approximately 0.4% CPU which I think is the lowest minimum, because I have tested empty index.html builded into cordova app even without the crosswalk and still getting the minimum 0.4% CPU usage.
Hope that this help someone else, happy coding ;)
I have a serious problem with an increasing CPU and RAM usage in an ionic app with createjs library. The problem cause the app to crash after a while.
As I am navigating between pages where each page has a new canvas, I see the RAM and CPU to dramatically increase.
There is no memory leak. I have tested it with chrome developer tools.
After so so much testing, the solution was to treat each template page in ionic as a root page. So when I was navigating to a new template page I always did:
$ionicHistory.nextViewOptions({
historyRoot: true,
disableBack: true
});
$ionicHistory.clearCache();
createjs.Tween.removeAllTweens();
$scope.stage.removeAllEventListeners();
$scope.stage.removeAllChildren();
$state.go("lesson", {}, {reload: true});
This way all cache that ionic kept was cleared and every event, tween motion and element in createjs was cleared too.
This increased the speed of the app drammatically!
I recently read about the HAXM , followed the steps, for first few days emulator used to get started in less than minute but now it gets stuck at this point - as shown below.. although it shows correct time & clock remains working . The worst part is all of the emulators I create show same problem .Any solution ?
You can try couple of things here
Check the RAM size allocated for Emulator. The best RAM size recommended is around 512MB for an Emulator. Make sure you have set the appropriate RAM size
Kill all your emulators, restart your machine and create fresh AVDs
Is this happening with the same application or different ones? a little bit detail on the application will help in suggesting more work around.
a. If it is an OpenGL application choose use Host GPU on your AVD and also install the correct graphics driver on your host machine
Every time I run a project from ADT to test on a virtual Android device it takes 90+ seconds to upload and another 15+ seconds to "install" it on the device.
Why does it take so long?
Any timeouts I should watch out for? (The eclipse console stays silent.)
Note: project.apk size is about 5MB and computing resources on the development machine are plentiful (i.e. CPU usage is around 5-10%, disk queue length about 0.05 and couple gigs of free RAM available during the "upload" and "install").
Not really a solution, but a workaround was found in a similar question:
Slow uploads to running Android emulator
It appears, when the Android emulator is idle its network connection is capped at 2 Mbps
and when you wake it by clicking and swiping around the bandwidth magically increases to around 10 Mbps! (At least so on my fairly modern system.)
This obviously makes a difference for uploading largish apps to the emulator.
Solution:
Go to Run -> Run Configurations... -> Target Tab -> Additional Emulator Command Line Options. Add there:
-netspeed full -netdelay none
After doing this the time for uploading went from 2 minutes to 8 seconds.
Edit:
I have also found that quitting Skype makes my emulator upload much faster.