MeasureSpec

MeasureSpec = MeasureSpec = MeasureSpec = MeasureSpec = MeasureSpec = MeasureSpec = MeasureSpec = MeasureSpec = MeasureSpec = MeasureSpec = MeasureSpec = MeasureSpec MeasureSpec is a static inner class of the View class that says how the View should be measured

For a DecorView, its MeasureSpec is determined by the window size and its own LayoutParams; For a normal View, its MeasureSpec is determined by the parent’s MeasureSpec and its own LayoutParams

A control that directly inherits from a View needs to override the onMeasure method and set its size to wrap_content. Since the View uses wrap_content in its layout, its specMode is AT_MOST. Its width/height is equal to the current amount of space left in the parent container, which is equivalent to using match_parent. The solution is as follows:

protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { super.onMeasure(widthMeasureSpec, heightMeasureSpec); int widthSpecMode = MeasureSpec.getMode(widthMeasureSpec); int widthSpecSize = MeasureSpec.getSize(widthMeasureSpec); int heightSpecMode = MeasureSpec.getMode(heightMeasureSpec); int heightSpecSize = MeasureSpec.getSize(heightMeasureSpec); // If (widthSpecMode == MeasureSpec.AT_MOST &&heightSpecMode == MeasureSpec MeasureSpec.AT_MOST) { setMeasuredDimension(mWidth, mHeight); } else if (widthSpecMode == MeasureSpec.AT_MOST) { setMeasureDimension(mWidth, heightSpecSize); } else if (heightSpecMode == MeasureSpec.AT_MOST) { setMeasureDimension(widthSpecSize, mHeight); }}Copy the code

MotionEvent

Click the screen to release, the event sequence is DOWN -> UP, click the screen to slide to release, the event sequence is DOWN -> MOVE ->… > MOVE -> UP.

GetX /getY returns coordinates relative to the top left corner of the current View, and getRawX/getRawY returns coordinates relative to the top left corner of the screen

TouchSlop is the minimum distance that the system recognizes as sliding. The value may vary from device to device, and can be obtained from viewConfiguration.get (getContext()).getScaledTouchSlop().

VelocityTracker

VelocityTracker can be used to track the speed of the finger in the slide:

view.setOnTouchListener(new View.OnTouchListener() { @Override public boolean onTouch(View v, MotionEvent event) { VelocityTracker velocityTracker = VelocityTracker.obtain(); velocityTracker.addMovement(event); velocityTracker.computeCurrentVelocity(1000); int xVelocity = (int) velocityTracker.getXVelocity(); int yVelocity = (int) velocityTracker.getYVelocity(); velocityTracker.clear(); velocityTracker.recycle(); return false; }});Copy the code

GestureDetector

GestureDetector helps detect user behaviors such as clicking, swiping, long pressing, and double clicking:

final GestureDetector mGestureDetector = new GestureDetector(this, new GestureDetector.OnGestureListener() { @Override public boolean onDown(MotionEvent e) { return false; } @Override public void onShowPress(MotionEvent e) { } @Override public boolean onSingleTapUp(MotionEvent e) { return false; } @Override public boolean onScroll(MotionEvent e1, MotionEvent e2, float distanceX, float distanceY) { return false; } @Override public void onLongPress(MotionEvent e) { } @Override public boolean onFling(MotionEvent e1, MotionEvent e2, float velocityX, float velocityY) { return false; }}); mGestureDetector.setOnDoubleTapListener(new OnDoubleTapListener() { @Override public boolean onSingleTapConfirmed(MotionEvent e) { return false; } @Override public boolean onDoubleTap(MotionEvent e) { return false; } @Override public boolean onDoubleTapEvent(MotionEvent e) { return false; }}); / / solve the problem of long press screen can't drag mGestureDetector. SetIsLongpressEnabled (false); imageView.setOnTouchListener(new View.OnTouchListener() { @Override public boolean onTouch(View v, MotionEvent event) { return mGestureDetector.onTouchEvent(event); }});Copy the code

It is recommended to implement onTouchEvent if you are listening for slides, and GestureDectector if you are listening for double-clicks.

Scroller

The elastic sliding object is used to realize the elastic sliding of View. Scroller itself cannot make the View elastic sliding, so it needs to be used together with the View’s computeScroll method. The startScroll method will not allow the View to slide, invalidate will cause the View to redraw, and then the draw method will call the computeScroll method again. The computeScroll method goes to Scroller to get the current scrollX and scrollY, then slides through the scrollTo method, then calls the postInvalidate method and so on.

Scroller mScroller = new Scroller(mContext); private void smoothScrollTo(int destX) { int scrollX = getScrollX(); int delta = destX - scrollX; Mscroll. startScroll(scrollX, 0, delta, 0, 1000); invalidate(); } @Override public void computeScroll() { if (mScroller.computeScrollOffset()) { scrollTo(mScroller.getCurrX(), mScroller.getCurrY()); postInvalidate(); }}Copy the code

The View of sliding

• scrollTo/scrollBy
  
  Suitable for swiping View contents.scrollByIt’s actually calledscrollToMethods:

public void scrollTo(int x, int y) { if (mScrollX ! = x || mScrollY ! = y) { int oldX = mScrollX; int oldY = mScrollY; mScrollX = x; mScrollY = y; invalidateParentCaches(); onScrollChanged(mScrollX, mScrollY, oldX, oldY); if (! awakenScrollBars()) { postInvalidateOnAnimation(); } } } public void scrollBy(int x, int y) { scrollTo(mScrollX + x, mScrollY + y); }Copy the code

MScrollX is equal to the horizontal distance between the left edge of the View and the left edge of the View content, and mScrollY is equal to the vertical distance between the top edge of the View and the top edge of the View content. ScrollTo and scrollBy can only change the position of the contents of the View, not the position of the View in the layout.

• Animation is simple to use and is mainly suitable for views without interaction and for complex animation effects.
• Changing layout parameters is a slightly more complex operation and is suitable for interactive views.

ViewGroup.MarginLayoutParams params = (ViewGroup.MarginLayoutParams) view.getLayoutParams(); params.width += 100; params.leftMargin += 100; view.requestLayout(); / / or the setLayoutParams (params);Copy the code

View event distribution

The dispatchTouchEvent method of the ViewGroup is called. If the top-level ViewGroup intercepts the event, that is, onInterceptTouchEvent returns true. The event is handled by the ViewGroup. If the ViewGroup mOnTouchListener is set, onTouch is called, otherwise onTouchEvent is called. That is, onTouch will block the onTouchEvent if both are provided. In onTouchEvent, onClick is called if mOnClickListenser is set. If the top-level ViewGroup does not intercept the event, the event is passed to the child View in the click event chain in which it is located, at which point the child View’s dispatchTouchEvent is called. And so on.

• ViewGroup does not intercept any events by default. The onInterceptTouchEvent method of ViewGroup returns false by default.
• The View does not have an onInterceptTouchEvent method; onTouchEvent is called whenever a hit event is passed to it.
• OnTouchEvent consumes events by default when the View is clickable.
• ACTION_DOWN is intercepted, onInterceptTouchEvent is executed once, leaving a mark (mFirstTouchTarget == NULL) so that all subsequent ACTION_MOVE and ACTION_UP will be intercepted. `

Process survival scheme

• Start an Activity with one pixel
• Use the Front Desk service
• Multiple processes wake each other up
• JobSheduler awaken
• Sticky services & bundled with system services

Parcelable interface

As long as the Parcelable interface is implemented, objects of a class can be serialized and delivered with intEnts and binders.

Use the sample

import android.os.Parcel; import android.os.Parcelable; public class User implements Parcelable { private int userId; protected User(Parcel in) { userId = in.readInt(); } public static final Creator<User> CREATOR = new Creator<User>() { @Override public User createFromParcel(Parcel in) { return new User(in); } @Override public User[] newArray(int size) { return new User[size]; }}; @Override public int describeContents() { return 0; } @Override public void writeToParcel(Parcel dest, int flags) { dest.writeInt(userId); } public int getUserId() { return userId; }}Copy the code

Method statement

Parcel internally wraps serializable data that can be transferred freely in Binder. Serialization is done by the writeToParcel method and ultimately through a series of write methods in the Parcel. The deserialization is done by CREATOR, through a series of Read methods on Parcel.

Parcelable compared with Serializable

• Serializable uses I/O read and write storage on the hard disk, while Parcelable is directly read and write in memory
• Serializable will use reflection, serialization and deserialization process requires a lot of I/O operations, Parcelable own implementation of marshalling and unmarshalling (reflection) operation, data is also stored in Native memory, It’s much faster

IPC

IPC stands for inter-process Communication. Android is based on Linux, which, for security reasons, prevents different processes from manipulating each other’s data, a practice known as process isolation.

Virtual memory mechanism in Linux system, allocation of the linear continuous memory space for each process, the operating system will be this kind of virtual memory mapped to physical memory space, each process has its own virtual memory space, and cannot operate other processes memory space, only the operating system have permission to operate the physical memory space. Process isolation ensures memory safety for each process.

AIDL communication

Android Interface Definition Language

Example:

• Create an AIDL interface file

// RemoteService.aidl
package com.example.mystudyapplication3;

interface IRemoteService {

    int getUserId();

}
Copy the code

• Creating a Remote Service

public class RemoteService extends Service { private int mId = -1; private Binder binder = new IRemoteService.Stub() { @Override public int getUserId() throws RemoteException { return mId; }}; @Nullable @Override public IBinder onBind(Intent intent) { mId = 1256; return binder; }}Copy the code

• Declare remote services

<service
    android:name=".RemoteService"
    android:process=":aidl" />
Copy the code

• Bind remote Services

public class MainActivity extends AppCompatActivity { public static final String TAG = "wzq"; IRemoteService iRemoteService; private ServiceConnection mConnection = new ServiceConnection() { @Override public void onServiceConnected(ComponentName  name, IBinder service) { iRemoteService = IRemoteService.Stub.asInterface(service); try { Log.d(TAG, String.valueOf(iRemoteService.getUserId())); } catch (RemoteException e) { e.printStackTrace(); } } @Override public void onServiceDisconnected(ComponentName name) { iRemoteService = null; }}; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); bindService(new Intent(MainActivity.this, RemoteService.class), mConnection, Context.BIND_AUTO_CREATE); }}Copy the code

Messenger

Messenger can pass Message objects between different processes. By putting the data we need to pass in the Message, we can easily pass data between processes. Messenger is a lightweight IPC solution with an underlying implementation of AIDL.

Window / WindowManager

Window concept and classification

Window is an abstract class whose concrete implementation is PhoneWindow. WindowManager is the entrance for the outside world to access Windows. The concrete implementation of Windows is located in WindowManagerService. The interaction between WindowManager and WindowManagerService is an IPC process. All views in Android are rendered through Windows, so Windows is actually the direct manager of the View.

Windows internal mechanism

Window is an abstract concept, and each Window corresponds to a View and a ViewRootImpl. The Window doesn’t really exist; it exists as a View. Windows must be accessed through WindowManager, whose implementation class is WindowManagerImpl:

WindowManagerImpl.java

@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
    applyDefaultToken(params);
    mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}

@Override
public void updateViewLayout(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
    applyDefaultToken(params);
    mGlobal.updateViewLayout(view, params);
}

@Override
public void removeView(View view) {
    mGlobal.removeView(view, false);
}
Copy the code

WindowManagerImpl does not directly implement Window’s three operations. Instead, it hands over all of them to WindowManagerGlobal, which provides instances of its own in the form of factories:

WindowManagerGlobal.java

// Add public void addView(View View, ViewGroup.LayoutParams params, Display Display, Window parentWindow) {... / / child Window if need to adjust some parameters of the final layout WindowManager. LayoutParams wparams = (WindowManager.LayoutParams) params; if (parentWindow ! = null) { parentWindow.adjustLayoutParamsForSubWindow(wparams); } else {···} ViewRootImpl root; View panelParentView = null; Synchronized (mLock) {// create a ViewRootImpl, Root = new ViewRootImpl(view.getContext(), display); root = new ViewRootImpl(view.getContext(), display); view.setLayoutParams(wparams); mViews.add(view); mRoots.add(root); mParams.add(wparams); // do this last because it fires off messages to start doing things try { root.setView(view, wparams, panelParentView); } catch (RuntimeException e) { // BadTokenException or InvalidDisplayException, clean up. if (index >= 0) { removeViewLocked(index, true); } throw e; @unsupportedappusage public void removeView(View View, Boolean immediate) {··· synchronized (mLock) {int index = findViewLocked(view, true); Boolean immediate) {··· synchronized (mLock) {int index = findViewLocked(view, true); View curView = mRoots.get(index).getView(); removeViewLocked(index, immediate); ···}} private void removeViewLocked(int index, Boolean immediate) {ViewRootImpl root = mroots.get (index); View view = root.getView(); if (view ! = null) { InputMethodManager imm = InputMethodManager.getInstance(); if (imm ! = null) { imm.windowDismissed(mViews.get(index).getWindowToken()); } } boolean deferred = root.die(immediate); if (view ! = null) { view.assignParent(null); if (deferred) { mDyingViews.add(view); Public void updateViewLayout(View View, View View) ViewGroup. LayoutParams params) {... final WindowManager. LayoutParams wparams = (WindowManager. LayoutParams params); view.setLayoutParams(wparams); synchronized (mLock) { int index = findViewLocked(view, true); ViewRootImpl root = mRoots.get(index); mParams.remove(index); mParams.add(index, wparams); root.setLayoutParams(wparams, false); }}Copy the code

Windows are eventually added, updated, and deleted using WindowSession, a Binder object of type IWindowSession. The real implementation class is Session, which is an IPC process.

Window creation process

Window creation for the Activity

The Activity creation process is eventually started by the ActivityThread’s performLaunchActivity() method, which internally creates an instance of the Activity through the class loader. The attach method is called to associate a set of context variables. In the Attach method of the Activity, the system creates the attached Window object and sets the callback interface, and then attaches the view to the Window in the Activity’s setContentView method:

Activity.java

final void attach(Context context, ActivityThread aThread, Instrumentation instr, IBinder token, int ident, Application application, Intent intent, ActivityInfo info, CharSequence title, Activity parent, String id, NonConfigurationInstances lastNonConfigurationInstances, Configuration config, String referrer, IVoiceInteractor voiceInteractor, Window window, ActivityConfigCallback activityConfigCallback) { attachBaseContext(context); mFragments.attachHost(null /*parent*/); mWindow = new PhoneWindow(this, window, activityConfigCallback); mWindow.setWindowControllerCallback(this); mWindow.setCallback(this); mWindow.setOnWindowDismissedCallback(this); mWindow.getLayoutInflater().setPrivateFactory(this); if (info.softInputMode ! = WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) { mWindow.setSoftInputMode(info.softInputMode); } if (info.uiOptions ! = 0) { mWindow.setUiOptions(info.uiOptions); } ··· ··· ··· ··· ··· ··· ··· ··· ··· ··· · public void setContentView(@layoutres int layoutResID) {getWindow().setContentView(layoutResID); initWindowDecorActionBar(); }Copy the code

PhoneWindow.java

@override public void setContentView(int layoutResID) {if (mContentParent == null) {// If there is no DecorView, Create installDecor (); } else { mContentParent.removeAllViews(); } mLayoutInflater.inflate(layoutResID, mContentParent); final Callback cb = getCallback(); if (cb ! = null && ! Cb.oncontentchanged (); isDestroyed()) {// Call back the Activity's onContentChanged method to inform the Activity that the Activity view has changed. }}Copy the code

The DecorView has not been officially added by WindowManager at this time. In the ActivityThread’s handleResumeActivity method, the Activity’s onResume method is called, followed by the Activity’s makeVisible(), Complete the adding and displaying of the DecorView:

Activity.java

void makeVisible() { if (! mWindowAdded) { ViewManager wm = getWindowManager(); wm.addView(mDecor, getWindow().getAttributes()); mWindowAdded = true; } mDecor.setVisibility(View.VISIBLE); }Copy the code

Dialog Window creation process

The creation of a Dialog Window is similar to that of an Activity in that it is created through the PolicyManager makeNewWindow method, and the resulting object is actually a PhoneWindow. When the Dialog is closed, will be removed by WindowManager DecorView: mWindowManager. RemoveViewImmediate (mDecor).

Dialog.java

Dialog(@NonNull Context context, @StyleRes int themeResId, Boolean createContextThemeWrapper) {... mWindowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE); final Window w = new PhoneWindow(mContext); mWindow = w; w.setCallback(this); w.setOnWindowDismissedCallback(this); w.setOnWindowSwipeDismissedCallback(() -> { if (mCancelable) { cancel(); }}); w.setWindowManager(mWindowManager, null, null); w.setGravity(Gravity.CENTER); mListenersHandler = new ListenersHandler(this); }Copy the code

A normal Dialog must use the Activity Context. If the Application Context is used, an error is reported because the Application token is normally owned by only the Activity. Windows is special and does not require a token.

Toast Window creation process

Toast belongs to the system Window. Due to its scheduled cancellation function, the system uses Handler. Toast the internal process, there are two kinds of IPC of the first kind is access NotificationManagerService Toast, the second is NotificationManagerService callback interface of TN in the Toast.

There are two ways to View inside Toast. One is the default style of the system, and the other is setView to specify a custom View, which corresponds to mNextView, an internal member of Toast.

Toast.java

public void show() { if (mNextView == null) { throw new RuntimeException("setView must have been called"); } INotificationManager service = getService(); String pkg = mContext.getOpPackageName(); TN tn = mTN; tn.mNextView = mNextView; try { service.enqueueToast(pkg, tn, mDuration); } catch (RemoteException e) {// Empty}} ··· public void cancel() {mtn.cancel (); }Copy the code

NotificationManagerService.java

private void showNextToastLocked() { ToastRecord record = mToastQueue.get(0); while (record ! = null) { if (DBG) Slog.d(TAG, "Show pkg=" + record.pkg + " callback=" + record.callback); try { record.callback.show(); scheduleTimeoutLocked(record, false); return; } catch (RemoteException e) { Slog.w(TAG, "Object died trying to show notification " + record.callback + " in package " + record.pkg); // remove it from the list and let the process die int index = mToastQueue.indexOf(record); if (index >= 0) { mToastQueue.remove(index); } keepProcessAliveLocked(record.pid); if (mToastQueue.size() > 0) { record = mToastQueue.get(0); } else { record = null; }}}} ··· private void scheduleTimeoutLocked(ToastRecord r, Boolean immediate) {Message m = Message. Obtain (mHandler, MESSAGE_TIMEOUT, r); long delay = immediate ? 0 : (r.duration == Toast.LENGTH_LONG ? LONG_DELAY : SHORT_DELAY); mHandler.removeCallbacksAndMessages(r); mHandler.sendMessageDelayed(m, delay); }Copy the code

Bitmap

Configure information and compression mode

There are two internal enumerated classes in Bitmap:

• Config is used to set the color configuration information
• CompressFormat is used to set the compression method

When we usually optimize Bitmap, when we need to optimize performance or prevent OOM, we usually use bitmap.config. RGB_565 configuration, because bitmap.config. ALPHA_8 only has transparency, it is meaningless to display general images. ARGB_4444 display image is not clear, bitmap.config. ARGB_8888 occupies the most memory.

Common operations

Crop, scale, rotate, move

Matrix matrix = new Matrix(); // matrix. PostScale (0.8f, 0.9f); PostRotate (-45); // Left-rotate with regular right-rotate matrix. PostRotate (-45); // Left-rotate with regular right-rotate matrix. PostTranslate (100, 80); // Translate, modify set again after the last change. Each operation is the latest and overwrites the last operation. Bitmap Bitmap = bitmap.createBitmap (source, 0, 0, source.getwidth (), source.getheight (), matrix, true);Copy the code

While Matrix can also call the postSkew method for skewing, it cannot be used when creating a Bitmap at this point.

Bitmap and Drawable conversion

// Drawable -> Bitmap public static Bitmap drawableToBitmap(Drawable drawable) { Bitmap bitmap = Bitmap.createBitmap(drawable.getIntrinsicWidth(), drawable.getIntrinsicHeight(), drawable.getOpacity() ! = PixelFormat.OPAQUE ? Bitmap.Config.ARGB_8888 : Bitmap.Config.RGB_565); Canvas canvas = new Canvas(bitmap); drawable.setBounds(0, 0, drawable.getIntrinsicWidth(), drawable.getIntrinsicHeight(); drawable.draw(canvas); return bitmap; } // Bitmap -> Drawable public static Drawable bitmapToDrawable(Resources resources, Bitmap bm) { Drawable drawable = new BitmapDrawable(resources, bm); return drawable; }Copy the code

Save and release

Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.test); File file = new File(getFilesDir(),"test.jpg"); if(file.exists()){ file.delete(); } try { FileOutputStream outputStream=new FileOutputStream(file); bitmap.compress(Bitmap.CompressFormat.JPEG,90,outputStream); outputStream.flush(); outputStream.close(); } catch (FileNotFoundException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } // Release bitmap resources, which is an irreversible operation bitmap.recycle();Copy the code

Image compression

public static Bitmap compressImage(Bitmap image) { if (image == null) { return null; } ByteArrayOutputStream baos = null; try { baos = new ByteArrayOutputStream(); image.compress(Bitmap.CompressFormat.JPEG, 100, baos); byte[] bytes = baos.toByteArray(); ByteArrayInputStream isBm = new ByteArrayInputStream(bytes); Bitmap bitmap = BitmapFactory.decodeStream(isBm); return bitmap; } catch (OutOfMemoryError e) { e.printStackTrace(); } finally { try { if (baos ! = null) { baos.close(); } } catch (IOException e) { e.printStackTrace(); } } return null; }Copy the code

BitmapFactory

Bitmap creation process

The Option class

The basic use

try { FileInputStream fis = new FileInputStream(filePath); BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; // After setting inJustDecodeBounds to true, use decodeFile() and other methods, which do not allocate real space (the decodeFile map is null, but can calculate the width and height of the original image). Namely the options. OutWidth and options. OutHeight BitmapFactory. DecodeFileDescriptor (fis) getFD (), null, options); float srcWidth = options.outWidth; float srcHeight = options.outHeight; int inSampleSize = 1; if (srcHeight > height || srcWidth > width) { if (srcWidth > srcHeight) { inSampleSize = Math.round(srcHeight / height);  } else { inSampleSize = Math.round(srcWidth / width); } } options.inJustDecodeBounds = false; options.inSampleSize = inSampleSize; return BitmapFactory.decodeFileDescriptor(fis.getFD(), null, options); } catch (Exception e) { e.printStackTrace(); }Copy the code

Memory recovery

if(bitmap ! = null && ! IsRecycled ()){// Recycle and set it to null bitmap.recycle(); bitmap = null; }Copy the code

Bitmap class constructors are private, so developers cannot directly create a Bitmap object. Instead, they can instantiate a Bitmap using static methods of the BitmapFactory class. A close look at the BitmapFactory source code shows that generating Bitmap objects is ultimately done through JNI calls. So, after loading the Bitmap into memory, there are two parts of memory. In short, part of it is Java and part of it is C. This Bitmap object is allocated by the Java part, when not used, the system will automatically reclaim, but the corresponding C available memory area, virtual machine is not directly reclaimed, this can only call the underlying function release. So you need to call the recycle() method to free up memory in part C. As you can see from the Bitmap source code, the RECYCLE () method does call JNI methods.

Screen adaptation

unit

• Dpi Number of pixels per inch
• Dp density-independent pixel – an abstract unit based on the physical density of the screen. These units are relative to a 160 dpi screen, so a DP is a px on a 160 dpi screen. The ratio of DP to pixels will vary with screen density, but not necessarily directly. Provides consistency in the actual size of UI elements for different devices.
• Sp scale independent pixels – this is similar to dp units, but it can also be scaled by the user’s font size preferences. It is recommended to use this unit when specifying font sizes so that they can be adjusted according to screen density and user preferences.

dpi = px / inch

density = dpi / 160

dp = px / density
Copy the code

Headline-matching scheme

private static void setCustomDensity(@NonNull Activity activity, @NonNull final Application application) { final DisplayMetrics appDisplayMetrics = application.getResources().getDisplayMetrics(); if (sNoncompatDensity == 0) { sNoncompatDensity = appDisplayMetrics.density; sNoncompatScaledDensity = appDisplayMetrics.scaledDensity; / / to monitor font switch application. RegisterComponentCallbacks (new ComponentCallbacks () {@ Override public void onConfigurationChanged(Configuration newConfig) { if (newConfig ! = null && newConfig.fontScale > 0) { sNoncompatScaledDensity = application.getResources().getDisplayMetrics().scaledDensity; } } @Override public void onLowMemory() { } }); } / / after a dpi will be unified to 360 dpi final float targetDensity = appDisplayMetrics. WidthPixels / 360; final float targetScaledDensity = targetDensity * (sNoncompatScaledDensity / sNoncompatDensity); final int targetDensityDpi = (int)(160 * targetDensity); appDisplayMetrics.density = targetDensity; appDisplayMetrics.scaledDensity = targetScaledDensity; appDisplayMetrics.densityDpi = targetDensityDpi; final DisplayMetrics activityDisplayMetrics = activity.getResources().getDisplayMetrics(); activityDisplayMetrics.density = targetDensity; activityDisplayMetrics.scaledDensity = targetScaledDensity; activityDisplayMetrics.densityDpi = targetDensityDpi }Copy the code

Bangs fit

• Android P fringe screen adaptation scheme

Android P supports the latest full-screen and a concave screen with room for cameras and speakers. With the new DisplayCutout class, you can determine the position and shape of non-functional areas where content should not be displayed. To determine the presence and location of these notched screen areas, use the getDisplayCutout() function.

Android P the WindowManager. LayoutParams added a layout parameter properties layoutInDisplayCutoutMode:

• Android P before the bangs screen adaptation

Different manufacturers of bangs screen adaptation scheme is not the same, need to consult their respective developer documentation.

Context

Context itself is an abstract class that encapsulates a series of system service interfaces, including the management of internal resources, packages, class loading, I/O operations, permissions, main threads, IPC, and component startup operations. ContextImpl, Activity, Service, and Application are all direct or indirect subclasses of Context as follows:

ContextWrapper is an implementation of the proxy Context, simply delegating all of its calls to another Context (mBase).

Application, Activity, and Service call attachBaseContext() of ContextWrapper by attach(), setting mBase as ContextImpl. The core work of ContextWrapper is left to mBase(ContextImpl) so that the Context can be subclassed to modify its behavior without changing the original Context.

SharedPreferences

SharedPreferences in the form of key-value pairs are mainly used for lightweight data storage, which is especially suitable for storing application configuration parameters. However, it is not recommended to use SharedPreferences to store large-scale data, which may degrade performance.

SharedPreferences XML file format is used to save data. The file is located in /data/data/ /shared_prefs, for example:

<? XML version='1.0' Encoding =' UTF-8 'standalone='yes'? > <map> <string name="blog">https://github.com/JasonWu1111/Android-Review</string> </map>Copy the code

Starting with Android N, the SP file mode created does not allow MODE_WORLD_READABLE and MODE_WORLD_WRITEABLE modules, otherwise SecurityException will be thrown directly. MODE_MULTI_PROCESS is not recommended by Google and will not be supported in the future.

When MODE_MULTI_PROCESS mode is set, the getSharedPreferences process checks the last modification time and file size of the SP file and reloads the file from disk once all changes are made.

access

getPreferences

Activity.getpreferences (mode): Uses the name of the Activity class as the SP file name. Namely xxxActivity. XML Activity. Java

public SharedPreferences getPreferences(int mode) {
    return getSharedPreferences(getLocalClassName(), mode);
}
Copy the code

getDefaultSharedPreferences

PreferenceManager. GetDefaultSharedPreferences (Context) : with the package name plus _preferences as file name, in MODE_PRIVATE mode create SP file. Namely packgeName_preferences. XML.

public static SharedPreferences getDefaultSharedPreferences(Context context) {
    return context.getSharedPreferences(getDefaultSharedPreferencesName(context),
           getDefaultSharedPreferencesMode());
}
Copy the code

getSharedPreferences

Direct call Context. GetSharedPreferences (name, mode), all methods are ultimately calls to the methods as follows:

class ContextImpl extends Context { private ArrayMap<String, File> mSharedPrefsPaths; public SharedPreferences getSharedPreferences(String name, int mode) { File file; synchronized (ContextImpl.class) { if (mSharedPrefsPaths == null) { mSharedPrefsPaths = new ArrayMap<>(); } file = mSharedPrefsPaths file = mSharedPrefsPaths. Get (name); If (file == null) {// If the file does not exist, create a new file file = getSharedPreferencesPath(name); mSharedPrefsPaths.put(name, file); } } return getSharedPreferences(file, mode); }}Copy the code

architecture

SharedPreferences and Editor are just two interfaces. SharedPreferencesImpl and EditorImpl implement corresponding interfaces respectively. In addition, ContextImpl records important data for SharedPreferences.

The putxxx() operation writes data to editorImpl.mmodified;

Apply ()/commit() calls commitToMemory() to synchronize data to the SharedPreferencesImpl mMap, Save to mapToWriteToDisk of MemoryCommitResult, and then call enqueueDiskWrite() to write to disk file. The original data is saved to a file with the suffix.bak. The data can be recovered if any exception occurs during disk writing.

Getxxx () operation from SharedPreferencesImpl. MMap read data.

apply / commit

• Apply has no return value, and commit has a return value to know if the change was committed successfully
• Apply commits changes to memory and then asynchronously to disk files, while COMMIT commits to disk files synchronously
• In the case of multiple concurrent COMMIT, the commit data being processed must be updated to disk files before the execution continues, which reduces the efficiency. However, apply is only atomic update to memory, and the subsequent call to apply directly overwrites the previous memory data, thus improving efficiency to a certain extent.

Pay attention to

• It is strongly recommended not to store very large keys/values in sp to reduce the lag/ANR
• Don’t use Apply too often and commit in batches whenever possible
• Do not use MODE_MULTI_PROCESS
• High frequency write keys and high frequency read keys can split files appropriately due to reduced synchronization lock contention
• Instead of edit() multiple times in a row, you should get edit() once and then putxxx() multiple times to reduce memory fluctuations

Message mechanism

Handler mechanism

Handlers have two main uses :(1) scheduling messages and runnables to be executed at some point in the future; (2) Queue operations that will be performed on a thread other than your own. (Keep the UI safe while updating it concurrently in multiple threads.)

Android states that UI access can only be done in the main thread, because Android UI controls are not thread-safe and concurrent access by multiple threads can cause UI controls to be in an unexpected state. Why doesn’t the system lock access to UI controls? There are two disadvantages: locking complicates UI access logic; Secondly, locking mechanism will reduce the efficiency of UI access. If a child thread accesses the UI, the program throws an exception. The ViewRootImpl validates the UI operation by using the ViewRootImpl checkThread method:

ViewRootImpl.java

void checkThread() {
    if (mThread != Thread.currentThread()) {
        throw new CalledFromWrongThreadException(
                "Only the original thread that created a view hierarchy can touch its views.");
    }
}
Copy the code

• Message: The Message object received and processed by the Handler
• MessageQueue: queue of messages, first in, first out, each thread can have a maximum of one
• Looper: The message pump is the manager of the MessageQueue. It continuously retrieves messages from the MessageQueue and distributes the messages to the corresponding Handler. Each thread has only one Looper.

Handler Handler Handler Handler Handler Handler Handler Handler Handler Handler Handler Handler Handler Handler Handler Since the default UI main thread is an ActivityThread, Looper is initialized when an ActivityThread is created, which is why we can use handlers in the main thread by default.