一、OkHttp3流程图

概述

Android安全架构规定：默认情况下，任何应用都没有权限执行对其他应用、操作系统或用户有不利影响的任何操作。这包括读写用户的私有数据（如联系人或电子邮件等）、读写其他应用的文件、执行网络访问、使设备保持唤醒状态等等。
如果要使用这些受保护的设备功能，首先要在应用的清单文件(AndroidManifest.xml)中添加一个或多个 标记：

1
2
3
4
5

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.app.myapp" >
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    ...
</manifest>

Android 中 Activity 是作为应用程序的载体存在，代表着一个完整的用户界面，提供了一个窗口来绘制各种视图，当 Activity 启动时，我们会通过 setContentView 方法来设置一个内容视图，这个内容视图就是用户看到的界面。

PhoneWindow 是 Android 系统中最基本的窗口系统，每个 Activity 会创建一个。PhoneWindow 是 Activity 和 View 系统交互的借口。DecorView 本质上是一个 FrameLayout，是 Activity 中所有 View 的祖先。

Optimizing Layout Hierarchies

It is a common misconception that using the basic layout structures leads to the most efficient layouts. However, each widget and layout you add to your application requires initialization, layout, and drawing. For example, using nested instances of LinearLayout can lead to an excessively deep view hierarchy. Furthermore, nesting several instances ofLinearLayout that use the layout_weight parameter can be especially expensive as each child needs to be measured twice. This is particularly important when the layout is inflated repeatedly, such as when used in a ListViewor GridView.

这句话是对减少布局层次的描述。

有一个误解就是，使用基类布局可用产生更有效的布局方式。然而每一个你添加到application里面的控件和布局，都需要初始化，布局，绘制。例如，布局复杂的时候使用LinearLayout，会导致深层次的布局嵌套问题，而进一步来说，使用LinearLayout的weight属性给每个子view去分配位置的时候，会导致每一个子view被绘制两次，而LinearLayout嵌套LinearLayout使用weight会更加严重。如果布局被重复的inflated的话，当我们使用ListView或者GridView的时候就会特别明显的影响绘制效率。

准备

• node & npm

  1	$ brew install node

• 检查 node & npm

  1 2	$ node -v $ npm -v

• vue-cli

  1	$ npm install -g vue-cli

  或

  1	$ npm install -g @vue/cli @vue/cli-init @vue/cli-service-global

命名

• 文件夹、.JS、.CSS: 小驼峰(little camel-case)
• .vue 组件: 大驼峰(big camel-case)*
• css的class命名遵循 BEM

重构

组件

组件存放位置

只有 一个 页面内的组件，放在页面文件夹下的 components 文件夹下；

两个 页面共用的组件，放在第一个页面文件夹下的 components 文件夹下；

三个以上 页面的共用组件，放在项目文件夹下的 components 文件夹下。

• 组件存放的位置会在开发过程中不断的调整重构。
• 添加项目级公用组件需将组件参数及用法描述添加到 README.md 。

本文旨在讨论抽象类和接口的作用、实例及使用场景，都是我的理解和总结。更多关于接口和抽象类的概念知识，可自行查阅相关文档。

1. 抽象类及其作用

抽象类，顾名思义，即类的抽象。

在介绍面向对象概念时，我们知道类是客观事物的抽象，而抽象类又是类的进一步抽象，该怎么理解呢？

举个例子，我们定义若干个类 class BMW、class Benz、class Audi，分别对客观事物“宝马”、“奔驰”、“奥迪”三种汽车进行抽象，包含相关属性和行为（即方法）。但是我们知道，汽车都有通用的属性和行为，比如品牌、发动机、方向盘、轮胎等属性，前进、后退、转弯等行为，所以我们可以在宝马、奔驰等汽车之上，进一步抽象出“汽车”类 abstract class Car，包含通用的特性（属性和方法）。让 BMW、Benz、Audi 等继承抽象类 extends Car，便拥有了汽车的通用特性，然后在抽象类基础上定义各自的特殊属性及方法。

这里的 abstract class Car 即抽象类，可以看出，抽象类是用来捕捉子类的通用特性的，包括属性及行为。

2. 接口及其作用

下面我们来看看接口，假使我研发出来一台会飞的汽车“伯特莱斯”（Bote-Royce），在程序中定义如下：

1
2
3
4
5
6
7
8
9
10

class BoteRoyce extends Car {
    //...省略通用特性

    /**
     * 可以飞
     */
    void fly() {
        System.out.println("假装会飞~");
    }
}

了解完 armeabi、armeabi-v7a、arm64-v8a、mips、mips64、x86、x86_64等abi的原理后，很久以前一般都只是用armeabi在做兼容。

现在其实市面上主流的手机都支持armeabi-v7a和arm64-v8a。请看如下简介：
各版本的分析如下所示：

• mips / mips64: 极少用于手机可以忽略，有兴趣的可以百度一下。
• x86 / x86_64: x86 架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具，实现 对 arm .so 的兼容，再考虑 x86 1% 以下的市场占有率，x86 相关的两个 .so 也是可以忽略的
• armeabi: ARM v5 这是相当老旧的一个版本，缺少对浮点数计算的硬件支持，在需要大量计算时有性能瓶颈
• armeabi-v7a: ARM v7 目前主流版本，一般市面上的骁龙系列或者麒麟系列的处理器绝大部分都是这种架构
• arm64-v8a: 64位支持
  所谓的ARMv8架构，就是在MIPS64架构上增加了ARMv7架构中已经拥有的的TrustZone技术、虚拟化技术及NEON advanced SIMD技术等特性，研发成的。

综上所述建议大家兼容armeabi-v7a和arm64-v8a这两个，其他架构少之又少，armeabi基本淘汰所以现在就不怎么考虑了。对于一般项目来说，足够了。

在build.gradle的android里的defaultConfig内添加如下内容:

1
2
3
4
5

defaultConfig {  
    ndk {
        abiFilters "armeabi-v7a"
        abiFilters "arm64-v8a"
    }