Starting today, we will open up a new topic: professional skills of mobile architects in simple terms, with the goal of becoming an architect step by step, detailing the most direct use value of an architect's skills, horizontal peripheral knowledge and in-depth professional technology

The most direct use value: I'm most afraid to see an article on the Internet. The full text is tall at the beginning, which makes people feel out of reach. However, it doesn't show how the technology is landing and what effect it will be after landing. When an article is written, it is necessary to take the reader into the author's world in the most acceptable way, rather than pretending to be high above all living beings. Therefore, the beginning of the article must be the most direct demonstration of the landing effect of technology. A runnable Demo is provided to let readers try it for themselves.

Horizontal peripheral knowledge: a core technology must not exist independently. Technology is a system, but the technology that can be detailed in an article is limited. It must be centered on one technology and supplemented by other technologies. The core technology needs to be detailed, but the surrounding technology also needs to be explained. The towering trees rise from the ground without soil as their attachment. Explain the surrounding knowledge in concise language and provide the correct research direction of these knowledge. It is also a step that can not be ignored by a responsible blogger.

In depth professional technology: the most taboo to do technology is to taste it. If you go a little deeper, you will quit. On the one hand, it is not conducive to understanding the underlying implementation. In the long run, you will always be a technical white and can't become a master; Second, it is not conducive to long-term memory. No matter how strong the memory is, the technical details will be blurred for a long time. However, if you go deep into the kernel and understand the principle, you will never deviate in the general direction of technology. As a man who wants to be an architect, even if he can't remember so many details, he can't grasp the general direction wrong. Therefore, technical depth is necessary.

Text outline

1. Demo address

2. Technical Inventory involved in this paper

3. About Android permissions

4. Writing method of permission request for primary / intermediate / advanced android Development

5. Detailed explanation of AOP elegant permission framework

   gradle configuration

   Java code

6. AOP idea and common AOP framework

7. In depth principle research of AspectJ AOP framework

text

1.Demo address

Demo address: https://github.com/18598925736/GracefulPermissionFramework/tree/dev_aspectJ

2. Technical Inventory involved in this paper

The following is suitable for developers with certain Android development years. You can understand the demo code of this article only after you have at least a basic understanding of the following technical points

• java annotation Foundation

The @ symbol is widely used as an annotation mark in java code. Annotations have a variety of uses, but they are basically marked for special processing in source code period, compilation period, or runtime. Annotations have their own specific syntax and API s.

• Gradle plug-in Basics

Gradle is a project construction framework in android studio, which is used to integrate and compile android source code projects into apk. You can customize the gradle plug-in, or reference the gradle plug-in published by others to add your own logic to the project construction process.

• Java reflection Foundation

java reflection. Some classes or methods that are inconvenient to use directly can be used by reflection. Reflection is usually used in frame design and hook technology.

• Android rights Basics

The focus of this article is to write the code of permission application gracefully. If you want to understand this article, you can't know nothing about permission.

• AOP aspect oriented programming idea

Aspect oriented programming is one of the important means of code decoupling. See below for more information.

3. About Android permissions

The issue of permissions has been a stumbling block since the advent of Android. The first batch of people who did Android could easily obtain user information, including contacts, including SMS content, including call records. It can be said that the security problem criticized by Android came from this. At the code level, developers only need to declare the required permissions in the manifest file according to the permission description of the Android official website, so as to access the required data in the code type. There are many kinds of permissions, more than hundreds of permissions, which are applicable to different scenarios. You can't write them down, and generally don't need to write them down.

Go to the official website when necessary https://developer.android.com/reference/android/Manifest.permission.html Just find it

The following is a summary of the development history of Android and major changes in the permission system.

• Android 1.0 - Android 5.0/5.1 App developers only need to declare permissions in the manifest file, which will be granted automatically during installation.

• Since Android 6.0, Google has divided all permissions into 2 categories, ordinary permissions, that is, they still only need to be declared in the list file. The other category is dangerous permission, which involves user privacy. In addition to a statement in the list file, it also needs to be applied dynamically when the App is started. In addition, Google also provides the conceptual difference between permission group and permission, and puts some permissions with similar functions in one group. When you apply for one of them, In fact, other permissions of this group are applied by default. Although this approach allows you to write one less permission, Google still recommends that you write the required permissions completely, because Google will change the permission group one day. At that time, there will be compatibility problems in the code, which is not necessary, and it is also a good habit to write the required permissions completely.

  The following figure shows all dangerous permissions and permission groups.

• There has been another major change since Android Q. From the process of adapting Android Q, it is found that
  1. Two permissions of the storage permission group, READ_EXTERNAL_STORAGE / WRITE_ETERNAL_STORAGE does not need dynamic application (but it still needs to be declared in the list file), because Q system enables sandbox mechanism, and app does not need any permission to access its own directory. If you want to access places outside the directory of app, you need to apply for READ_EXTERNAL_STORAGE / WRITE_ETERNAL_STORAGE these two permissions.
  2. When the device is running in the background, it needs to use location information and dynamically apply for permission. Q introduces access_ BACKGROUND_ The purpose of the new permission location is to restrict the background process from obtaining user location information quietly. This permission will be granted by default if it runs on systems below Q (excluding), but it must be applied if Q or above.
  3. For other changes, see the official website, https://developer.android.google.cn/about/versions/10/privacy/changes?hl=zh-tw.
• Another troublesome problem is that if you run my Demo, you will find that the effect may be completely different on many models. Take two extreme examples: Android 6 0 version of mumu simulator, many permissions will be granted by default, such as location information permissions. In addition, on some Huawei mobile phones, some permissions will be rejected by default. Every time you apply, the user has permanently rejected. This is because mobile phone manufacturers or simulator manufacturers have deeply customized Google's native Android system and changed the code related to permissions. Therefore, to deal with this problem, it is necessary to adapt a variety of models.

4. Writing method of permission request for primary / intermediate / advanced android Development

In fact, there are some restrictions on permissions, which are relatively simple. The only thing we need to pay special attention to is the dynamic permission application after 6.0. It is handled as follows:

The main process is transformed into code and displayed:

AndroidManifest.xml

    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

Java code

    /**
     * Apply for permission
     */
    protected void requestPermission(String[] permissions, int requestCode) {
        // Check that you already have these permissions
        if (PermissionUtil.hasSelfPermissions(this, permissions)) {
            Log.e(TAG, "Activity，requestPermission: All permissions are already available,No application required");
        } else {
            // Start requesting permissions
            ActivityCompat.requestPermissions(this, permissions, requestCode);
        }
    }

    /**
     * Process callback
     *
     * @param requestCode
     * @param permissions
     * @param grantResults
     */
    @Override
    public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
        if (PermissionUtil.verifyPermissions(grantResults)) {//Check whether all permissions are granted
            granted(requestCode);
        } else {
            // Show tips
            if (PermissionUtil.shouldShowRequestPermissionRationale(this, permissions)) {
                //Shouldshowrequestpermissionrational this method is to check whether the permission is permanently denied...
                //If you reject with, false will be returned here. If you reject for the first time, true will be returned

                // Cancel permission
                denied(requestCode);
            } else {
                // Permission denied
                deniedForever(requestCode);
            }
        }
    }

Apply for permission above activitycompat Requestpermissions and the processing callback onrequestpermissions result are where developers need to code manually.

The same is the above logic. The processing methods of junior / intermediate / advanced developers are quite different.

• primary

A complete commercial project is bound to involve many activities, fragments, and ordinary Java classes. Specific permissions need to be used in many places. If we search onRequestPermissionsResult with ctrl+H, we find the following scenarios:

The same callback method appears 25 times in the project Moreover, the code of permission application, which is not directly related to the business, is also embedded in the business code. OK, I won't say much here.

(PS: actually, this is the code of my own company. I don't know why... Maybe there are too many staff changes in the company, and future generations are too lazy to change the architecture)

• intermediate

  PS: Reference https://github.com/18598925736/GracefulPermissionFramework/tree/dev

Intermediate development, as a programmer with certain work experience, knows how to optimize code and reduce maintenance costs. He is likely to find that where permission applications need to be used, they are basically based on Activity and Fragment. As long as the code redundancy here is solved, he will write this

public abstract class BaseActivity extends AppCompatActivity implements IPermissionCallback {
    protected static final String TAG = "BaseActivity";

    /**
     * Apply for permission
     */
    protected void requestPermission(String[] permissions, int requestCode) {
        // Check that you already have these permissions
        if (PermissionUtil.hasSelfPermissions(this, permissions)) {
            Log.e(TAG, "Activity，requestPermission: All permissions are already available,No application required");
        } else {
            // Start requesting permissions
            ActivityCompat.requestPermissions(this, permissions, requestCode);
        }
    }

    /**
     * Request feedback
     *
     * @param requestCode
     * @param permissions
     * @param grantResults
     */
    @Override
    public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
        if (PermissionUtil.verifyPermissions(grantResults)) {//Check whether all permissions are granted
            granted(requestCode);


# summary

We always like to visit the great gods of big factories, but in fact, the great gods are just mortals. Compared with rookie programmers, they spend a little more time. If you don't work hard, the gap will only become bigger and bigger.

The interview questions are more or less helpful for what you have to do next, but I hope you can summarize your shortcomings through the interview questions to improve your core technical competitiveness. Every interview experience is a literacy of your technology. The effect of re examination and summary after the interview is excellent! If you need this full version**Interview notes**，As long as you do more**support**I this article.

**[Data collection method: free download here](https://gitee.com/vip204888/java-p7)**

The distance will only get bigger and bigger.

The interview questions are more or less helpful for what you have to do next, but I hope you can summarize your shortcomings through the interview questions to improve your core technical competitiveness. Every interview experience is a literacy of your technology. The effect of re examination and summary after the interview is excellent! If you need this full version**Interview notes**，As long as you do more**support**I this article.

**[Data collection method: free download here](https://gitee.com/vip204888/java-p7)**

![](https://img-blog.csdnimg.cn/img_convert/88f9e118b966487139ca61fa52469025.png)