What are the main differences between 1.Dalvik and standard Java virtual machines?one of the first differences between the Dalvik and the standard Java Virtual machine (JVM) is that the Dalvik is based on a register, and the JVM is stack-based.
Another big difference between Dalvik and Java is that the operating environment--dalvik optimized to allow instances of multiple virtual machines to run concurrently in limited memory, and each Dalvik application executes as a standalone Linux process.
(1) Virtual machine is small, the use of space is small;
(2) Dalvik no JIT compiler;
(3) The constant pool has been modified to use only 32-bit indexes to simplify the interpreter;
(4) It uses its own byte code, not Java bytecode.
that is, every application is running on a separate Dalvik virtual machine under the Android platform, and every Dalvik VM is the next process of Linux, so the process of the application, Dalvik the process of the virtual machine and the process of Linux, All three of these concepts are a meaning.
2.onSaveInstanceState, what's the effect? In order to ensure the correctness of the program, generally where to write the code of the persistence layer operation?Onsaveinstancestate This method is called when the activity is accidentally obscured (the difference is the user's manual exit), such as a sudden call, or when the user clicks the home button, The application interface may or may not be killed in the background, so we can save some interface values in this method, and if the activity is killed, these values will be persisted to the phone's hard drive. When we get back in, we can call Onrestoreinstancestate and do the interface recovery. since both the Onsaveinstancestate and Onrestoreinstancestate methods are not necessarily called by the system, we typically persist the data in the OnPause () method.
3.view how to refresh? Brief description of what is double buffering? There are two ways to implement view updates in Android, one is invalidate and the other is Postinvalidate, where the former is used in the UI thread itself and the latter in a non-UI thread.
Flicker is a common problem in graphic programming. A complex drawing operation can cause the rendered image to blink or have other unacceptable appearance. The use of double buffering solves these problems. Double buffering uses memory buffers to resolve flicker problems caused by multi-draw operations. When double buffering is used, all drawing operations are done in the memory buffer first, instead of drawing directly on the screen. When all the drawing operations are complete, copy the image of the memory buffer complete directly to the screen. Because only one graphics operation is performed on the screen, the problem of image flicker caused by complex drawing operations is eliminated.
With dual buffering in Android, you can use a background canvas backcanvas, where all of the drawing operations are done first. Wait until the picture is ready, and then copy the Backcanvas to
The canvas that is associated with the screen is as follows:
Bitmap bitmapbase = new Bitmap ()
Canvas Backcanvas = new Canvas (bitmapbase)
Backcanvas.draw () ...//drawing
Canvas c = Lockcanvas (null);
C.drawbitmap (bitmapbase);//output The already drawn image to the screen
Unlock (c) ....
4. Say what you know about the broadcast recipientsThe broadcast recipient (Broadcastreceiver) is used to receive broadcast intent, and the broadcast intent is sent by calling Context.sendbroadcast (), Context.sendorderedbroadcast () To achieve. Typically a broadcast intent can be received by multiple broadcast receivers subscribed to this intent, which is similar to topic message recipients in JMS. The method to implement a broadcast receiver is as follows:
The first step: Inherit Broadcastreceiver and override the OnReceive () method.
public class Incomingsmsreceiver extends Broadcastreceiver {
@Override public void OnReceive (context context, Intent Intent) {
}
}
The second step: Subscribe to the broadcast intent of interest, there are two ways to subscribe:
The first: Subscribe using code
Intentfilter filter = new Intentfilter ("Android.provider.Telephony.SMS_RECEIVED");
Incomingsmsreceiver receiver = new Incomingsmsreceiver ();
Registerreceiver (receiver, filter);
The second type: Subscribe to the <application> node in the Androidmanifest.xml file:
<receiver android:name= ". Incomingsmsreceiver ">
<intent-filter>
<action android:name= "Android.provider.Telephony.SMS_RECEIVED"/>
</intent-filter>
</receiver>
Broadcast type:
Broadcasts are divided into two different types: "Normal broadcasts" and "ordered broadcast (Ordered broadcasts)". The normal broadcast is completely asynchronous and can be received by all receivers at the same time (logically), with a higher efficiency of message delivery, but the disadvantage is that the receiver cannot pass the processing result to the next recipient and cannot terminate the broadcast intent propagation; but ordered broadcasts are in accordance with the priority level declared by the receiver. The receiver receives the broadcast in turn. For example, if the level of a is higher than b,b, then the broadcast is passed first to a, then to B, and finally to C. The precedence level is declared in the android:priority attribute of the intent-filter element, the higher the number of precedence, the greater the value range: 1000 to 1000, and the precedence level can also be set by calling the SetPriority () of the Intentfilter object. The receiver of an orderly broadcast can terminate the broadcast intent, and once the broadcast intent is transmitted, the receiver will not be able to receive the broadcast. In addition, the recipient of an ordered broadcast can pass the data to the next recipient, such as: A is broadcast, it can be stored in its result object, and when broadcast is passed to B, B can get a data from the result object of a.
Context.sendbroadcast ()
A regular broadcast is sent and all subscribers are given the opportunity to obtain and process it.
Context.sendorderedbroadcast ()
Sending an ordered broadcast, the system executes the receiver sequentially, according to the priority level declared by the receiver, and the preceding receiver has the right to terminate the broadcast (Broadcastreceiver.abortbroadcast ()), if the broadcast is terminated by the previous receiver, Subsequent receivers will no longer be able to obtain the broadcast. For ordered broadcasts, the previous receiver can store the data in the result object via the Setresultextras (bundle) method, then pass it to the next recipient, the next recipient through code: Bundle bundle = Getresultextras (True)) You can get the data that was stored in the result object by the previous recipient.
The system receives the text message, the broadcast belongs to the orderly broadcast. If you want to prevent users from receiving text messages, you can set a priority so that your customized recipients get the broadcast first, and then terminate the broadcast so that the user cannot receive the message.
Response from the broadcast receiver:
In Android, a Broadcastreceiver instance is created each time a broadcast message arrives and the OnReceive () method is executed, and the Broadcastreceiver instance is destroyed when the OnReceive () method finishes executing. When the OnReceive () method is not completed within 10 seconds, Android will consider the program unresponsive. Therefore, in the broadcastreceiver can not do some more time-consuming operation, the side will pop up the ANR (Application No Response) dialog box. If you need to complete a more time-consuming task, you should do so by sending intent to the service. It is not possible to use a child thread here because the Broadcastreceiver life cycle is short, and the child thread may not have finished broadcastreceiver before it ends. Once the broadcastreceiver is over, the broadcastreceiver process can easily be killed when the system needs memory because it belongs to the empty process (the process without any active components). If its host process is killed, then the working child thread will be killed. So using sub-threading to solve is unreliable.
public class Incomingsmsreceiver extends Broadcastreceiver {
@Override
public void OnReceive (context context, Intent Intent) {
Send intent start service, which is performed by the service for more time-consuming operations
Intent service = new Intent (context, xxxservice.class);
Context.startservice (service);
}
}
Popular Broadcast Intent:
In addition to the SMS arrival broadcast intent,android There are many broadcast intent, such as: Boot start, battery power changes, time has changed, such as broadcast intent.
Receive battery change broadcast intent, subscribe to this intent in the <application> node in the Androidmanifest.xml file:
<receiver android:name= ". Incomingsmsreceiver ">
<intent-filter>
<action android:name= "Android.intent.action.BATTERY_CHANGED"/>
</intent-filter>
</receiver>
Receive boot start broadcast intent, subscribe to this intent in the <application> node in the Androidmanifest.xml file:
<receiver android:name= ". Incomingsmsreceiver ">
<intent-filter>
<action android:name= "Android.intent.action.BOOT_COMPLETED"/>
</intent-filter>
</receiver>
And to make a permission declaration:
<uses-permission android:name= "Android.permission.RECEIVE_BOOT_COMPLETED"/>
Broadcast receiver life cycle
The life cycle of the broadcast receiver is very short, created when the broadcast is received, and destroyed after the OnReceive () method finishes
Do not do time-consuming work in the broadcast receiver, or it will pop up application No response error dialog box
It is also best not to create sub-threads in the broadcast receiver to do time-consuming work, because the broadcast recipient is destroyed and the process becomes an empty process and is easily killed by the system.
Longer time-consuming work is best done in the service
Android face question (ii)
