准备

• node & npm

  $ brew install node

• 检查 node & npm

  $ node -v $ npm -v

• vue-cli

  $ npm install -g vue-cli

  或

  $ 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），在程序中定义如下：

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内添加如下内容:

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

早期的Android系统几乎只支持ARMv5的CPU架构，你知道现在它支持多少种吗？

Android系统目前支持以下七种不同的CPU架构：ARMv5，ARMv7 (从2010年起)，x86 (从2011年起)，MIPS (从2012年起)，ARMv8，MIPS64和x86_64 (从2014年起)，每一种都关联着一个相应的ABI。

应用程序二进制接口ABI（Application Binary Interface）定义了二进制文件（尤其是.so文件）如何运行在相应的系统平台上，从使用的指令集，内存对齐到可用的系统函数库。

为什么你需要重点关注.so文件

• 项目中使用到了NDK，它将会生成.so文件。

• 如果只使用Java语言进行编码，你可能在想不需要关注.so文件了吧，因为Java是跨平台的。但你可能并没有意识到项目中依赖的函数库或者引擎库里面已经嵌入了.so文件，并依赖于不同的ABI。

Android应用支持的ABI取决于APK中位于lib/ABI目录中的.so文件，其中ABI可能是上面说过的七种ABI中的一种。

ABI和CPU的重要知识

1、 大部分cpu都支持多于一种的ABI。
2、 当一个应用安装在设备上，只有该设备支持的CPU架构对应的.so文件会被安装。
3、

• 注意：上表格中的空白部分，是我不知道它是否支持，极有可能是不支持

• 解析： x86设备上，选择ABI的优先级

  • libs/x86目录中如果存在.so文件的话，会被安装
  • 如果不存在，则会选择armeabi-v7a中的.so文件
  • 如果也不存在，则选择armeabi目录中的.so文件

• x86设备能够很好的运行ARM类型函数库，但并不保证100%不发生crash，特别是对旧设备，因为是运行在x86设备上模拟arm的虚拟层上。

问几个问题先

在app/src/main/res/values/dimens.xml中定义尺寸如下：

<dimen name="font1">18sp</dimen>

在代码中引用此尺寸如下：

mText.setTextSize(18);  // 方法1
mText.setTextSize(getResources().getDimension(R.dimen.font1));  // 方法2
mText.setTextSize(TypedValue.COMPLEX_UNIT_PX,getResources().getDimension(R.dimen.font1));  // 方法3
mText.setTextSize(TypedValue.COMPLEX_UNIT_SP,18);  // 方法4

问题1: 方法1和方法2设置的文字尺寸大小相同么？
问题2:方法3和方法4设置的文字尺寸大小相同么？
问题3:方法1和方法4设置的文字尺寸大小相同么？

如果你能很清楚的给出上面问题的答案，那就没必要再向下看了；
如果你对以上问题感到模棱两可的话，请继续往下看:

Java使用有向图机制，通过GC自动检查内存中的对象（什么时候检查由虚拟机决定），如果GC发现一个或一组对象为不可到达状态，则将该对象从内存中回收。也就是说，一个对象不被任何引用所指向，则该对象会在被GC发现的时候被回收；另外，如果一组对象中只包含互相的引用，而没有来自它们外部的引用（例如有两个对象A和B互相持有引用，但没有任何外部对象持有指向A或B的引用），这仍然属于不可到达，同样会被GC回收。

Android中使用Handler造成内存泄露的原因

Handler mHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        mImageView.setImageBitmap(mBitmap);
    }
}

前一阵子有个读者在微信里跟我聊了一件很有趣的事情，他去美团实习，面试让他哭笑不得，因为败在了冒泡排序上。

情况是这样子的，当时和面试官聊的感觉还可以，就在他觉得好像差不多快结束的时候，面试官给他扔了个题：“我这刚好有纸和笔，你来写个冒泡排序吧。”

这位读者心里一慌，为什么慌，倒并不是因为不会写，因为作为一个程序员，冒泡排序基本上没有不会写的，而是事发突然，感觉不太妙。当时他是这么写的：

public void bubbleSort(int[] a) {
    for(int i = a.length - 1; i > 0; i--) {
        for(int j = 0; j < i; j++) {
            if(a[j] > a[j+1])
                 //交换，具体实现略
                 swap(a, j, j+1); 
        }
    }
}

果不其然，他写了之后，面试官就问他，这种写法有没有什么问题？能否继续优化？结果还真没答上来。（看到这里，读者们不妨也先思考下如何优化。）