早期的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中定义尺寸如下：

1

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

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

1
2
3
4

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造成内存泄露的原因

1
2
3
4
5
6

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

我们通常所说的排序算法往往指的是内部排序算法，即数据记录在内存中进行排序。

　　排序算法大体可分为两种：

　　　　一种是比较排序，时间复杂度O(nlogn) ~ O(n^2)，主要有：冒泡排序，选择排序，插入排序，归并排序，堆排序，快速排序等。

　　　　另一种是非比较排序，时间复杂度可以达到O(n)，主要有：计数排序，基数排序，桶排序等。

下表给出了常见比较排序算法的性能：

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

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

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

1
2
3
4
5
6
7
8
9

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); 
        }
    }
}

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

之前对Android Gradle构建的依赖一直傻傻分不清，这段时间正好接入集团的一个二方库，踩了很多坑，也顺带把Gradle依赖这块搞清楚了，主要整理了下Gradle依赖的类型、依赖配置、如何查看依赖、依赖冲突如何解决。

依赖类型

dependencies DSL标签是标准Gradle API中的一部分，而不是Android Gradle插件的特性，所以它不属于android标签。

依赖有三种方式，如下面的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apply plugin: 'com.android.application'

android { ... }

dependencies {
    // Dependency on a local library module
    implementation project(":mylibrary")

    // Dependency on local binaries
    implementation fileTree(dir: 'libs', include: ['*.jar'])

    // Dependency on a remote binary
    implementation 'com.example.android:app-magic:12.3'
}

目录介绍

• 1.OOM和崩溃优化
  • 1.1 OOM优化
  • 1.2 ANR优化
  • 1.3 Crash优化
• 2.内存泄漏优化
  • 2.0 动画资源未释放
  • 2.1 错误使用单利
  • 2.2 错误使用静态变量
  • 2.3 handler内存泄漏
  • 2.4 线程造成内存泄漏
  • 2.5 非静态内部类
  • 2.6 未移除监听
  • 2.7 持有activity引用
  • 2.8 资源未关闭
  • 2.9 其他原因
• 3.布局优化
  • 3.1 include优化
  • 3.2 ViewStub优化
  • 3.3 merge优化
  • 3.4 其他建议
• 4.代码优化
  • 4.1 lint代码检测
  • 4.2 代码规范优化
  • 4.3 View异常优化
  • 4.4 去除淡黄色警告优化
  • 4.5 合理使用集合
  • 4.6 Activity不可见优化
  • 4.7 节制的使用Service
• 5.网络优化
  • 5.1 图片分类
  • 5.2 获取网络数据优化
  • 5.3 网络请求异常拦截优化
• 6.线程优化
  • 6.1 使用线程池
• 7.图片优化
  • 7.1 bitmap优化
  • 7.2 glide加载优化
• 8.加载优化
  • 8.1 懒加载优化
  • 8.2 启动页优化
• 9.其他优化
  • 9.1 静态变量优化
  • 9.2 注解替代枚举
  • 9.3 多渠道打包优化
  • 9.4 TrimMemory和LowMemory优化
  • 9.5 轮询操作优化
  • 9.6 去除重复依赖库优化
  • 9.7 四种引用优化
  • 9.8 加载loading优化
  • 9.9 对象池Pools优化
• 10.RecyclerView优化
  • 10.1 页面为何卡顿
  • 10.2 具体优化方案

以前做应用开发时，在数据尚未加载前一般会先给用户一个提示，最简单粗暴的方式就是菊花图，大多数做法是放一张有个性的静态图，示意正在加载数据，这样体验会好些，直到出现 Skeleton Screen（中文一般叫做骨架屏）极大地提升用户感知体验。其实一开始我并不知道这个效果叫什么名字，后来在 GitHub 看到有人开源了，赶紧 Star。今天我给大家推荐几个 Skeleton Screen 相关库，来了解学习一波。

1、ShimmerRecyclerView

简介

A custom recycler view with shimmer views to indicate that views are loading （英语渣渣，这句话始终翻译不顺/捂脸）。

效果预览

什么是Flutter

2018年2月27日，在2018世界移动大会上，Google发布了Flutter的第一个Beta版本。Flutter是Google用以帮助开发者在Ios和Android两个平台开发高质量原生应用的全新移动UI框架，点击查看Flutter介绍视频。

其实我第一次听说Flutter是在收到谷歌开发者公众号的推送里，当时读完了那篇文章觉得Flutter的优点确实比较突出：

1. 热重载（Hot Reload），作为一个菜鸟安卓开发者，能热重载真的太舒服了，利用Android Studio直接一个ctrl+s就可以保存并重载，模拟器立马就可以看见效果，就这一点比原生安卓制作简直不知道高到哪里去了。
2. 一切皆为Widget的理念，对于Flutter来说，手机应用里的所有东西都是Widget，通过可组合的空间集合、丰富的动画库以及分层课扩展的架构实现了富有感染力的灵活界面设计。
3. 借助可移植的GPU加速的渲染引擎以及高性能本地代码运行时以达到跨平台设备的高质量用户体验。 这段介绍是直接抄下来的，虽然我并不知道什么叫可移植的GPU加速的渲染引擎，但是最终结果就是利用Flutter构建的应用在运行效率上会和原生应用差不多。
   酷安上有一个Flutter的演示Demo，Flutter Gallery。
   如果经常逛酷安的一定会发现这个画廊的演示Demo的图标和另一个演示Demo的图标是一样的，Google Fuchsia OS Preview,这个应用的是传闻的Google正在研发的新一代操作系统，所以个人认为，Flutter的存在可能不仅仅是实现在安卓和IOS上的运行，更是为了日后丰富Fuchsia这个新系统的软件生态而存在的。