Tag Archives: callback

Android get screen width and height and get control width and height

The width and height of a control have a drawing process. The width and height of the control are directly obtained in the oncreate method, which is generally 0. Therefore, we need to use the following methods to obtain the width and height of the control:
Load onmeasure twice, but the callback function only calls back once

ViewTreeObserver vto2 = imageView.getViewTreeObserver();    
        vto2.addOnGlobalLayoutListener(new OnGlobalLayoutListener() {  
            @Override    
            public void onGlobalLayout() {  
                imageView.getViewTreeObserver().removeGlobalOnLayoutListener(this);    
                textView.append("\n\n"+imageView.getHeight()+","+imageView.getWidth());  
            }    
        });

Android avoids memory leak: reasonable use of getcontext() and getapplication ()

To conclude:
GetApplicationContext () can fetch the Application object, and getContext() is generally considered to return an Activity object (which, of course, is not actually limited to the Activity). 2. For Application, you can see from the Manifest file that an Application typically has only one Application node. Application is just an Application, that is, as long as the current Application is still running, it can get to the Application object. 3.Application is a long reference, and Activity is a short reference. Application is suitable for storing objects that need to be read repeatedly, such as the user’s username and password, the current Settings of the Application, and so on. When an Activity is applied to the current active form, such as displaying a Dialog, or creating a new View, the context object passed in should be the current Activity, not the Application.
    
Android applications limit heap memory to 16M (note: heap memory is also related to device performance; available heap memory for high performance devices may be 24M or more), with phone functions taking up a portion of the heap and developers having very limited access to it. If you’re not going to run out of memory, your application should use as little as possible so that other programs don’t get killed when they run. The more applications the Android system can hold in memory, the faster users can switch between applications. As part of my work, I researched memory leaks in Android applications and found that most of the time it was the same problem: holding a long reference to the Context.
In Android, Context is used for many operations, but mostly to load or access resources. This is why all Widget components receive a Context parameter in the constructor. For a typical Android Application, there are usually two contexts, namely Activity and Application. Developers often need the context to select an Activity when passing between classes or methods.

this indicates that Views have a reference to the entire Activity, so anything in your Activity will be held by Views, which are generally held by the view hierarchy and its corresponding resources. So, if you give away the Context, you’re giving away some memory. If you’re not careful, it’s very easy to reveal an Activity.
when the screen direction changes, the system will save its state by default, destroy the current Activity, and create a new one. To do this, Android reloads the application’s UI from resources. Now let’s say you’re developing an app that contains a lot of bitmaps, and you don’t want to load bitmaps every time you switch screens. So the easiest way to do this is to use the static static field.