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 ;)
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 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.
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've had lots of problems getting a simple UIImagePicker working (see my other posts), and I've been getting memory warning notifications after taking a picture and before I even get a chance to dismiss the UIImagePicker
Now, however... I've loaded up my app in Xcode today and all is working fine. Can't get the memory warning at all, under the same build settings etc.
My question is.. is this normal? Perhaps it was cleared by an iPhone restart, or XCode restart. Or should I be worried that I've still got a hidden memory warning, only now it's hiding from me?
Thanks!
yes, very normal. memory is used by lots of background tasks on the phone, so it really depends what your email client is doing, whether you're installing apps in the background, and lots more.
It also depends a lot on the device you're testing on too. For example, if you're testing on an iPhone 2G, you'll have a significantly lower amount of memory to play with than if you were testing on a 3GS for example.
Depending on what kind of requirements your app has, and what choices you're making in terms of what to target (3.0 only? 3G upwards, etc) its best to always test on the least capable device so that you can get an accurate idea of how the app will perform on that device.
Following iPad's announcement and its SDK (iPhone SDK 3.2), porting apps to iPad becomes an important issue. What guidelines I should follow in my iPhone apps to ensure I can port it to iPad as seamlessly as possible?
The different resolution is particularly an important issue. While the iPad runs iPhone apps unmodified, it's not really the desirable behavior for a native app. How can we make our iPhone apps resolution-independent so that they can run gracefully on all resolutions like most desktop apps?
If you've been using IB and setting the resize behaviors of elements properly, and also coding frame coordinates all relative to each other you are half-way to having a UI that can potentially scale to a larger screen.
From the screen shots there are new kinds of action-sheets as well, potentially attached to UI elements instead of floating - if you use overlays today they will probably work about the same but you may want to consider changing placement from the center on larger display.
UPDATE:
Now the event is over, and registered developers can download the SDK - although we cannot talk about specific features here just yet, read through ALL of the documents related to the new OS version as there are a number of things aimed at helping you transition to supporting both platforms. Also before you start using custom libraries for things take a look through the API changes to see what new abilities might be supported that are not today.
Generally speaking, what I said above about IB holds true, and also you should start thinking about how your apps today could use more space to present more information at once instead of being split out over multiple screens. Also if you are doing any projects right now that use images, make sure to initially design the images large enough that you can also use them for higher resolution tablet applications.
It is far more reasonable to expect users to input text (and larger amounts of it) than with a non-iPad device.
Nothing, it appears. Although we don't have the SDK quite yet. It will all existing run iPhone app without an issue, albeit at reduced resolution.
It remains to be seen how much of the existing iPhone SDK is shared with the iPad SDK UI wise.
Judging by what has been said, absolutely nothing. You will have to adapt to the new screen size and better hardware all together, if you want to take advantage of the features that the improved device offers. The lack of a 3g module is also something to consider if your app(s) rely on that functionality.