I have recently started using Flutter ad noticed that apps in debug mode shows "Slow Mode",I know that it shows slow mode only in debug mode and we can remove it by setting debugShowCheckedModeBanner: false on our MaterialApp.So,The question is,my app has a Slow Mode banner/ribbon in the upper right. Why am I seeing that?
App is supposed to be relatively slower in debug mode.
Debug mode on device (including simulators, emulators):
Turns on all the assertions in the world, includes all debugging information,
enables all the debugger aids (e.g. observatory) and service
extensions. Optimizes for fast develop/run cycles. Does not optimize
for execution speed, binary size, or deployment. Used by flutter run.
Built with sky/tools/gn --android or sky/tools/gn --ios. Also
sometimes called "checked mode" or "slow mode".
Related
I an running a script on Bluestacks for a game. Sometimes, the game gets crashed. I want to make a Program that will detect when the App crashes, and then do certain action.
How can I do it?
Once you app goes into crash state either your system will get freeze may because of low configuration as it will consume lots of resources and our script is running into Bluestacks environment. Script have no control over this situation. It takes input only from mouse and keyboard strokes.
Can you please open your Settings (gear wheel to the right) and match these settings and see if that resolves the issue for you?
Engine Tab:
Graphics Engine: Performance
Graphics Renderer: OpenGL
GPU Settings: Prefer dedicated graphics (if possible)
ASTC: Hardware decoding (if possible)
CPU: 4 Cores
RAM: 4 GB
ABI: Auto
Device Tab:
Device Profile: One Plus 3T
I have an iPhone application I'm testing - I've just noted when testing it on a device that sometimes when I resume it (i.e. launch it again in the "multitasking" sense when I expect it to appear and continue on) the startup image appears. As if it totally restarted.
Would this be an indication of memory issue with the app?
Good question. I've noticed this as well and wondered also. It might not be this app that has an issue though, but other apps have required extra memory which caused the system to take memory from this app. Im not sure exactly because (if I recall correctly) the resumed app restarts on the screens it was on, so it didnt lose state. I wonder if in this case, iOS has unloaded some of the backgrounded task's code and its taking a bit of time to read the code back in, so it puts that screen up. However, if this was the case, then the app would really need to be idle and not active in the background.
Any thoughts on why this code runs slow on device but fast on simulator in iphone, I am making a game in cocos2d, and I am moving an object from one place to another , throught CCTouchBegan , CCTouchMoved, CCTouchEneded (ccp function) and after that I take the action on it,
can any buddy tell me what is the main issue to solve this problem,
The simulator is a simulator not an emulator. All the simulator really does is provide a window for running an iOS app. You'll notice that when you build for the simulator, the system architecture is set to i386. You're compiling for the Mac when you use the simulator. There's no memory restrictions, sandboxing etc. In fact, I think your app even shows up as it's own process.
That's why when you run it on the device, you get hammered. You just have to work on optimizing your code. The simulator is terrible. Just use your device for debugging, it'll save you the confusion. If you post your code, we might be able to help you speed it up.
Happy coding.
The basic hardware of the computer on which the Simulator runs and that of an iOS device are very different, from CPU clock speed, to instruction parallelism, to branch prediction, to cache size, to memory bandwidth, to memory available. The possible compiler optimizations might also be different, given the different ISAs. It's not uncommon for general code to run an order of magnitude faster on the Simulator on a Mac than on an iPhone.
There can be many reasons like (also) #simulator vs actual device
Low Memory can be the first problem as in your actual device as you will install different kinds of huge applications but in case of simulator you will not install t.
Low power problem as the actual device will be powered by battery and not like simulators which get constant power all the time.
Other application interfering with your application run cycle but in simulator you will hardly run any application while you are testing your application.
You cannot see the UserInterface(UI) as clear in your MAC as you can see in your actual device, so which appears correct may not be actually correct.
Application interfered by calls, in simulator this type of interference will never happen.
I'm trying to use Shark to determine which method(s) are taking the most time in my iPhone app. After sampling, I get this:
alt text http://img69.imageshack.us/img69/7871/screenshot20091117at503.png
Clicking the "!" button yields:
Shark was unable to find symbol
information for this address range.
Typically this happens because the
application was compiled without
symbols or they have been subsequently
stripped away. In Xcode, make sure the
"Generate Debug Symbols" checkbox is
selected (passes the -g flag to the
compiler). Note that this does not
affect code optimization, and does not
typically alter performance
significantly. However, the extra
symbol information does consume
significantly more space and may bloat
the size of the executable.
But I AM using the Debug option, and I am running on my Device. And Generate Debug Symbols IS checked. So what's wrong?
Don't know if this applies to Shark on device, but I know that when running Instruments with the iPhone Simulator, one has to select the most recent SDK. If you run with a previous SDK, you see no debug info.
Has anybody had any success ever attaching a debugger to a tethered device? I am able to debug my j2me application in the emulator, but have a lot of trouble sorting out phone-specific problems when they come up. The phone I'm using is a Nokia N95, but ideally the debug process would work on any phone.
Is this possible? If so does anyone have steps they've used to set it up?
Sony Ericsson supports debugging on ebery phone at least since K700, this is done by using KDWP. UIQ 3 communicators also can be debugged the same way.
By the way, it the latest phones by SE it is even possible to monitor memory consumption and CPU profiling. So if you wanna debug your apps on real phones, I would suggest also using SE phones, they are really good at it. I use Netbeans, and it works without any problems with any SE phone.
Motorola phones support a debugging interface called KDWP(Motodev registration required).Their MIDway tool can also be useful for getting debug trace information from a midlet running on a device.
As other stated, on device debug is something that strictly depends on manufacturer's will and often it's nearly impossible. However, i can address you to Gear Java Mobile Framework that gives you the opportunity to use an on-device debug console to print your messages and thus read phone specific issues. If you need some explanation on how to use it, take a look to this tutorial
Unfortunately this is not generally possible. Some makers (like Sony-Erricson) support this on some of their phones but not all. I am not sure if there is on-device-debugging tool for N95 but you can use Nokia's emulator which should be pretty close to the device. The new Java ME SDK comes with promise of real ODD in near future. But it still very much depends on OEM cooperation.
I find a good debugging method is to control a string value which gets painted on top of everything else when it is not null. This will work anywhere, though obviously isn't ideal, but can be used to catch Exceptions, print values etc. Of course you're limited to the small screen, but in theory you could even code some scrolling functionality.
Some people use RMS logging but personally I could never be bothered.
As others have said here, Motorola have Midway which I think is great.
Others are correct here in that on-device debugging is very much device specific. I haven't done anything with Series 60, but at least on Series 40 phones, I had to open up a CommConnection and write out to it in order to see much of anything going on. The device emulators are again a mixed bag, but you usually can get 90% of the way to your application working on them and can usually get your debugger connected to them. If you aren't making use of any of the hardware on the phone, that should get you most of the way there.
I've used the Blackberry tools on occasion to debug J2ME applications (without using RIM APIs) but it is very slow and still is only emulation, not the actual device (but it sometimes does help to shake the odd thing out). I agree it is frustrating when you have something running on an emulator only to find that it doesn't run on the hardware.
You can not debug step by step like android or other SDK.
In J2ME you can trace the error by adding the log statement in the code and add another midlet and display that log screen in that midlet.
Example: add Log.p("Log statement.....");
LogMidlet.java
// Add the following line in the startup method of this midlet.
Log.getInstance().showLog();
This way you can somehow track the error in j2me.
I think it is possible to add additional debugging information on preprocess step. Like this:
public void myMethod() {
Debug.traceMethod("myMethod");
int var = 1;
Debug.newLine();
var++;
Debug.newLine();
...
}