继承图

Map

概述

结构

HashMap

• HashMap 是一个最常用的Map，它根据键的HashCode值存储数据，根据键可以直接获取它的值，具有很快的访问速度。HashMap最多只允许一条记录的键为Null。在JDK1.8中，链表⻓度⼤于8的时候，链表会转成红⿊树。
• DEFAULT_INITIAL_CAPACITY: Table数组的初始化长度 = 16。
• DEFAULT_LOAD_FACTOR: 负载因子默认值为 0.75。当 元素的总个数>当前数组的长度 * 负载因子 时数组会扩容为原来的两倍。
• TREEIFY_THRESHOLD: 链表树化阙值默认值为 8 。表示在一个node（Table）节点下的值的个数大于8时候，会将链表转换成为红黑树。
• UNTREEIFY_THRESHOLD: 红黑树链化阙值：默认值为 6 。表示在进行扩容期间，单个Node节点下的红黑树节点的个数小于6时候，会将红黑树转化成为链表。
• MIN_TREEIFY_CAPACITY: 64 最小树化阈值，当Table所有元素超过该值时才会进行树化（为了防止前期阶段频繁扩容和树化过程冲突）。
• HashMap中存储的是泛型，因此不能是基础类型，可能会产生自动装箱的消耗，创建新的装箱对象。

为什么是2次幂的初始容量，为什么扩容也是2倍？

因为计算下标时采用的是 (n - 1) & hash 方式，位运算特别高效，按位与 & 的计算方法是，只有当对应位置的数据都为1时，运算结果也为1，当 HashMap 的容量是 2 的 n 次幂时，(n-1) 的 2 进制也就是 1111111***111 这样形式的，这样与添加元素的 hash 值进行位运算时，能够充分的散列，使得添加的元素均匀分布在 HashMap 的每个位置上，减少hash碰撞，避免形成链表的结构，使得查询效率降低！

为什么使用链表+数组？⽤ LinkedList/ArrayList 代替数组结构可以吗？

在对key值进行散列取到下标以后，放入到数组中时，难免出现两个key值不同，但是却放入到下标相同的格子中，此时我们就可以使用链表来对其进行链式的存放。数组的查找效率比 LinkedList 大，所以使用数组。另外 ArrayList 底层虽然也是数组，但它是 1.5 倍扩容机制。

put方法

1. 对 key 做 hash 运算，计算 index；
2. 如果没碰撞直接放到数组⾥；如果碰撞了则以链表的形式存在数组后；
3. 如果碰撞导致链表过⻓(⼤于等于TREEIFY_THRESHOLD)，就把链表转换成红⿊树(JDK1.8中的改动)；
4. 如果节点已经存在就替换 old value(保证key的唯⼀性)；
5. 如果达到了扩容条件则扩容。

resise方法

HashMap 的扩容实现机制是将原 table 数组中所有的 Entry 取出来，重新对其 Hashcode 做 Hash 散列到扩容后新的 Table 中。

get方法

1. 对 key 做 hash 运算，计算 index；
2. 如果与数组⾥的第⼀个节点直接命中，则直接返回；
3. 如果有冲突，则去查找对应的 Entry；若为树则为 O(logn)；若为链表则为 O(n)。

ArrayMap

ArrayMap是一个通用的key-value映射数据结构，它相比HashMap会占用更少的内存空间。

数据结构

在ArrayMap内部有两个比较重要的数组，一个是mHashes,另一个是mArray。

• mHashes用来存放key的hashcode值
• mArray用来存储key与value的值，它是一个Object数组。依旧存在自动装箱的消耗。

其中这两个数组的索引对应关系是：

1
2
3
4
5
6

int[] mHashes;
Object[] mArray;

mHashes[index] = hash;
mArray[index<<1] = key;  //等同于 mArray[index * 2] = key;
mArray[(index<<1)+1] = value; //等同于 mArray[index * 2 + 1] = value;

注：向左移一位的效率要比 乘以2倍 高一些。

查找数据

查找数据分成两步：

• 根据key的hashcode找到在mHashes数组中的索引值
• 根据上一步的索引值去查找key所对应的value值

mHashes是一个有序数组，查找元素的时候使用的是二分查找。

插入数据

1. 新数据位置确定
   • 根据key的hashcode在mHashes表中二分查找确定合适的位置。
   • 如果新添加的数据的索引不是最后位置，在需要对这个索引之后的全部数据向后移动
2. 当key为null时，其实和其他正常的key差不多，只是对应的hashcode会默认成0来处理。
3. 数组扩容问题
   • 首先数组的容量会扩充到BASE_SIZE
   • 如果BASE_SIZE无法容纳，则扩大到2 * BASE_SIZE
   • 如果2 * BASE_SIZE仍然无法容纳，则每次扩容为当前容量的1.5倍。

删除数据

• 如果当前ArrayMap只有一项数据，则删除操作将mHashes，mArray置为空数组，mSize置为0.
• 如果当前ArrayMap容量过大（大于BASE_SIZE*2）并且持有的数据量过小（不足1/3）则降低ArrayMap容量，减少内存占用
• 如果不符合上面的情况，则从mHashes删除对应的值，将mArray中对应的索引置为null

ArrayMap的缓存优化

在元素的新增和删除过程中，会频繁出现多个容量为BASE_SIZE和2 * BASE_SIZE的int数组和Object数组(put方法增加数据，扩大容量；remove方法删除数据，减小容量)。ArrayMap设计者为了避免创建不必要的对象，减少GC的压力，采用了类似对象池的优化设计。

SparseArray

1
2

private int[] mKeys;
private Object[] mValues;

SparseArray 比 HashMap 更省内存，某些条件下性能更好，因为它避免了对key的自动装箱。ArrayMap 与 SparseArray 最大的一点不同就是 ArrayMap 的 key 可以为任意的类型，而 SparseAraay 的 key 只能是整型。它也对 key 使用二分法进行排序。

ConcurrentHashMap

• 通过把整个Map分为N个Segment,可以提供相同的线程安全,但是效率提升N倍,默认提升16倍。(读操作不加锁,由于HashEntry的value变量是 volatile的,也能保证读取到最新的值。)
• 有些方法需要跨段,比如size()和containsValue(),它们可能需要锁定整个表而而不仅仅是某个段,这需要按顺序锁定所有段,操作完毕后,又按顺序释放所有段的锁
• 扩容:段内扩容(段内元素超过该段对应Entry数组长度的75%触发扩容,不会对整个Map进行扩容),插入前检测需不需要扩容,有效避免无效扩容

ConcurrentSkipListMap

• 它是一个有序的Map，相当于TreeMap。
• TreeMap采用红黑树实现排序，而ConcurrentHashMap采用跳表实现有序。

HashTable

HashTable与 HashMap类似，它继承自Dictionary类，不同的是：

• 它不允许记录的键或者值为空。
• 它支持线程的同步，实现线程安全的方式是在修改数据时锁住整个HashTable，因此也导致了 HashTable在写入时会比较慢。
• 初始size为11,扩容:newsize = olesize*2+1

LinkedHashMap

LinkedHashMap 直接继承自 HashMap, 内部维护了一个 LinkedList 双向链表。LinkedHashMap 保存了记录的插入顺序，在用 Iterator 遍历 LinkedHashMap 时，先得到的记录是先插入的，它还可以在此基础上再根据访问顺序(get,put)来排序，可以用来实现 Lru 算法。

在遍历的时候会比HashMap慢，不过有种情况例外，当HashMap容量很大，实际数据较少时，遍历起来可能会比LinkedHashMap慢，因为LinkedHashMap的遍历速度只和实际数据有关，和容量无关，而HashMap的遍历速度和容量有关。

初始化

1
2
3
4
5
6

public class LinkedHashMap<K,V> extends HashMap<K,V> implements Map<K,V> {
    public LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder) {
        super(initialCapacity, loadFactor);
        this.accessOrder = accessOrder; // 是否按照访问顺序排序
    }
}

LinkedHashMapEntry

1
2
3
4
5
6

static class LinkedHashMapEntry<K,V> extends HashMap.Node<K,V> {
    LinkedHashMapEntry<K,V> before, after;
    LinkedHashMapEntry(int hash, K key, V value, Node<K,V> next) {
        super(hash, key, value, next);
    }
}

LinkedHashMap 的 Entry 新增了 before 和 after 两个指针，before 在每次添加元素的时候将会指向上一次添加的元素，而上一次添加的元素的 after 指针将指向本次添加的元素，来形成双向链表。

put元素

LinkedHashMap 没有重写 put 方法，只是重写了 newNode 方法生成新的节点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Node<K,V> newNode(int hash, K key, V value, Node<K,V> e) {
    LinkedHashMapEntry<K,V> p = new LinkedHashMapEntry<K,V>(hash, key, value, e);
    linkNodeLast(p);
    return p;
}

transient LinkedHashMapEntry<K,V> head;
transient LinkedHashMapEntry<K,V> tail;

// 将 p 放到链表尾部
private void linkNodeLast(LinkedHashMapEntry<K,V> p) {
    LinkedHashMapEntry<K,V> last = tail;
    tail = p;
    if (last == null) head = p;
    else {
        p.before = last;
        last.after = p;
    }
}

remove元素

LinkedHashMap 没有重写 remove 方法，只是重写了 afterNodeRemoval 方法处理删除的节点。

1
2
3
4
5
6
7

// 从双向链表中删除节点 e
void afterNodeRemoval(Node<K,V> e) {
    LinkedHashMapEntry<K,V> p = (LinkedHashMapEntry<K,V>)e, b = p.before, a = p.after;
    p.before = p.after = null;
    if (b == null) head = a; else b.after = a;
    if (a == null) tail = b; else a.before = b;
}

维护节点访问顺序

accessOrder 参数默认为 false, 当设置为 true 时, LinkedHashMap 会维护节点访问顺序。在 putVal/get/repalce 方法最后都调用了 afterNodeAccess 方法，LinkedHashMap 重写了这个方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// 将被访问节点移动到链表最后
void afterNodeAccess(Node<K,V> e) { // move node to last
    LinkedHashMapEntry<K,V> last;
    if (accessOrder && (last = tail) != e) {
        LinkedHashMapEntry<K,V> p =
            (LinkedHashMapEntry<K,V>)e, b = p.before, a = p.after;
        p.after = null;
        if (b == null)
            head = a;
        else
            b.after = a;
        if (a != null)
            a.before = b;
        else
            last = b;
        if (last == null)
            head = p;
        else {
            p.before = last;
            last.after = p;
        }
        tail = p;
        ++modCount;
    }
}

迭代器

LinkedHashMap 实现了自己的迭代器，其迭代是通过双向链表实现的。

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

abstract class LinkedHashIterator {
    // ...

    final LinkedHashMapEntry<K,V> nextNode() {
        LinkedHashMapEntry<K,V> e = next;
        if (modCount != expectedModCount) throw new ConcurrentModificationException();
        if (e == null) throw new NoSuchElementException();
        current = e;
        next = e.after;
        return e;
    }
}

其 containsValue 方法也是通过遍历双向链表实现的：

1
2
3
4
5
6
7
8

public boolean containsValue(Object value) {
    for (LinkedHashMapEntry<K,V> e = head; e != null; e = e.after) {
        V v = e.value;
        if (v == value || (value != null && value.equals(v)))
            return true;
    }
    return false;
}

TreeMap

• TreeMap实现SortMap接口，内部是红黑树，能够把它保存的记录根据键排序，默认是按键值的升序排序，也可以指定排序的比较器，当用 Iterator 遍历TreeMap时，得到的记录是排过序的。

比较

• 一般情况下，我们用的最多的是HashMap，HashMap里面存入的键值对在取出的时候是随机的，它根据键的HashCode值存储数据，根据键可以直接获取它的值，具有很快的访问速度。在Map中插入、删除和定位元素，HashMap 是最好的选择。
• TreeMap取出来的是排序后的键值对。但如果要按自然顺序或自定义顺序遍历键，那么TreeMap会更好。
• LinkedHashMap是HashMap的一个子类，如果需要输出的顺序和输入的相同，那么用LinkedHashMap可以实现，它还可以按读取顺序来排列，像连接池中可以应用。
• HashMap : 内存占用较大，增、删的效率较高，改、查的效率一般
• ThreadLocal.Values : 内存占用一般，当数据量比较小时，增删改查的效率高；数据量大时，增删改查效率一般
• ArrayMap: 内存占用较小，改、查的效率高，增、删的效率较低
• SparseArray : 内存占用较小，改、查的效率高，增、删的效率低，且主键是数字

List

• 有序，可重复。

Vector

• 底层维护一个Object数组。
• 查询速度快，增删慢。
• 线程安全，操作效率低。

ArrayList

• 底层维护一个Object数组。
• 查询速度快，增删慢。
• 1.5 倍扩容。

LinkedList

LinkedList是List接口的实现类，因此它可以是一个集合，可以根据索引来随机访问集合中的元素。此外，它还是Duque接口的实现类，因此也可以作为一个双端队列，或者栈来使用。

• LinkedList是一个双向链表.
• 查询速度慢，增删快

CopyOnWriteArrayList

CopyOnWriteArrayList使用了一种叫写时复制的方法，当有新元素添加到CopyOnWriteArrayList时，先从原有的数组中拷贝一份出来，然后在新的数组做写操作，写完之后，再将原来的数组引用指向到新数组。

CopyOnWriteArrayList的整个add操作都是在锁的保护下进行的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public boolean add(E e) {
    //1、先加锁
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        Object[] elements = getArray();
        int len = elements.length;
        //2、拷贝数组
        Object[] newElements = Arrays.copyOf(elements, len + 1);
        //3、将元素加入到新数组中
        newElements[len] = e;
        //4、将array引用指向到新数组
        setArray(newElements);
        return true;
    } finally {
       //5、解锁
        lock.unlock();
    }
}

由于所有的写操作都是在新数组进行的，这个时候如果有线程并发的写，则通过锁来控制，如果有线程并发的读，则分几种情况：

1. 如果写操作未完成，那么直接读取原数组的数据；
2. 如果写操作完成，但是引用还未指向新数组，那么也是读取原数组数据；
3. 如果写操作完成，并且引用已经指向了新的数组，那么直接从新数组中读取数据。

可见，CopyOnWriteArrayList的读操作是可以不用加锁的。

CopyOnWriteArrayList表达的一些思想：

1. 读写分离，读和写分开
2. 最终一致性
3. 使用另外开辟空间的思路，来解决并发冲突

Stack

继承自Vector.

• boolean empty():测试堆栈是否为空。
• Object peek():查看堆栈顶部的对象，但不从堆栈中移除它。
• Object pop():移除堆栈顶部的对象，并作为此函数的值返回该对象。
• Object push(Object element):把项压入堆栈顶部。
• int search(Object element):返回对象在堆栈中的位置,从栈顶往下，以1为基数。

Set

• 无序，不可重复。

HashSet

HashSet 底层用的是 HashMap:

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

public class HashSet<E> extends AbstractSet<E> implements Set<E>, Cloneable, java.io.Serializable {
    private transient HashMap<E,Object> map;
    private static final Object PRESENT = new Object();

    public boolean add(E e) {
        return map.put(e, PRESENT)==null;
    }

    public boolean remove(Object o) {
        return map.remove(o)==PRESENT;
    }
}

HashSet导致的内存泄漏：把一个对象存储进hashSet集合后，修改这个对象中参与计算hash的变量的值，这时这个对象的hash值也会随之改变，那么这么对象不可以正常地被删除。

TreeSet

TreeSet采用的数据结构是红黑树，我们可以让它按指定规则对其中的元素进行排序。它又是如何判断两个元素是否相同呢？除了用equals方法检查两个元素是否相同外，还要检查compareTo方法是否返回为0。所以如果对象要存放到Tree集合里，需要在重写compareTo时，把相同的对象的比较值定为0，防止相同的元素被重复添加进集合中。

ConcurrentSkipListSet

• 它是一个有序的、线程安全的Set，相当于线程安全的TreeSet。
• 它内部拥有ConcurrentSkipListMap实例，本质上就是一个ConcurrentSkipListMap，只不过仅使用了Map中的key。

Queue

• void add(Object e):将指定元素插入到队列的尾部。

• Object remove():获取队列头部的元素，并删除该元素。

• object element():获取队列头部的元素，但是不删除该元素。

• boolean offer(Object e):将指定的元素插入此队列的尾部。当使用容量有限的队列时，此方法通常比add(Object e)有效。　

• Object poll():返回队列头部的元素，并删除该元素。如果队列为空，则返回null。

• Object peek():返回队列头部的元素，但是不删除该元素。如果队列为空，则返回null。

Queue

1

Queue<T> queue = new LinkedList<T>();

PriorityQueue

PriorityQueue 默认是小根堆，容量没有界限，会在指定的初始容量基础上扩容，默认排序是自然排序，队头元素是最小元素。可以这样实现大根堆：

1
2
3
4
5
6
7
8

val queue = PriorityQueue<Int>(10) { o1, o2 -> o2.compareTo(o1) }
for (i in 0..9) {
    queue.add(Random.nextInt(50))
}
println(queue)
for (i in 0..9) {
    println("${queue.remove()} - $queue")
}

输出：

1
2
3
4
5
6
7
8
9
10
11

[47, 41, 28, 38, 25, 11, 19, 11, 23, 21]
47 - [41, 38, 28, 23, 25, 11, 19, 11, 21]
41 - [38, 25, 28, 23, 21, 11, 19, 11]
38 - [28, 25, 19, 23, 21, 11, 11]
28 - [25, 23, 19, 11, 21, 11]
25 - [23, 21, 19, 11, 11]
23 - [21, 11, 19, 11]
21 - [19, 11, 11]
19 - [11, 11]
11 - [11]
11 - []

Deque

Deque接口是Queue接口的子接口，它代表一个双端队列，Deque定义了一些方法：

• void addFirst(Object e): 　　将指定元素添加到双端队列的头部。
• void addLast(Object e):　　将指定元素添加到双端队列的尾部。
• Iteratord descendingItrator():　　返回该双端队列对应的迭代器，该迭代器以逆向顺序来迭代队列中的元素。
• Object getFirst():　　获取但不删除双端队列的第一个元素。
• Object getLast():　　获取但不删除双端队列的最后一个元素。
• boolean offFirst(Object e):　　将指定元素添加到双端队列的头部。
• boolean offLast(OBject e):　　将指定元素添加到双端队列的尾部。
• Object peekFirst():　　获取但不删除双端队列的第一个元素；如果双端队列为空，则返回null。
• Object PeekLast():　　获取但不删除双端队列的最后一个元素；如果双端队列为空，则返回null。
• Object pollFirst():　　获取并删除双端队列的第一个元素；如果双端队列为空，则返回null。
• Object pollLast():　　获取并删除双端队列的最后一个元素；如果双端队列为空，则返回null。
• Object pop()(栈方法):　　pop出该双端队列所表示的栈的栈顶元素。相当于removeFirst()。
• void push(Object e)(栈方法)：　　将一个元素push进该双端队列所表示的栈的栈顶。相当于addFirst()。
• Object removeFirst():　　获取并删除该双端队列的第一个元素。
• Object removeFirstOccurence(Object o):　　删除该双端队列的第一次出现的元素o。
• Object removeLast():　　获取并删除该双端队列的最后一个元素o。
• Object removeLastOccurence(Object o):　　删除该双端队列的最后一次出现的元素o。

BlockingQueue

ArrayBlockingQueue

此队列创建时必须指定大小.

基于数组的阻塞队列实现，在ArrayBlockingQueue内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外，ArrayBlockingQueue内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。

ArrayBlockingQueue在生产者放入数据和消费者获取数据，都是共用同一个锁对象，由此也意味着两者无法真正并行运行，这点尤其不同于LinkedBlockingQueue；按照实现原理来分析，ArrayBlockingQueue完全可以采用分离锁，从而实现生产者和消费者操作的完全并行运行。Doug Lea之所以没这样去做，也许是因为ArrayBlockingQueue的数据写入和获取操作已经足够轻巧，以至于引入独立的锁机制，除了给代码带来额外的复杂性外，其在性能上完全占不到任何便宜。

ArrayBlockingQueue和LinkedBlockingQueue间还有一个明显的不同之处在于，前者在插入或删除元素时不会产生或销毁任何额外的对象实例，而后者则会生成一个额外的Node对象。这在长时间内需要高效并发地处理大批量数据的系统中，其对于GC的影响还是存在一定的区别。而在创建ArrayBlockingQueue时，我们还可以控制对象的内部锁是否采用公平锁，默认采用非公平锁。

LinkedBlockingQueue

基于链表的阻塞队列，同ArrayListBlockingQueue类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。

而LinkedBlockingQueue之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。

作为开发者，我们需要注意的是，如果构造一个LinkedBlockingQueue对象，而没有指定其容量大小，LinkedBlockingQueue会默认一个类似无限大小的容量（Integer.MAX_VALUE），这样的话，如果生产者的速度一旦大于消费者的速度，也许还没有等到队列满阻塞产生，系统内存就有可能已被消耗殆尽了。

SynchronousQueue

SynchronousQueue是一个没有数据缓冲的BlockingQueue(队列只能存储一个元素)，生产者线程对其的插入操作put必须等待消费者的移除操作take，反过来也一样，消费者移除数据操作必须等待生产者的插入。

ConcurrentLinkedQueue

ConcurrentLinkedQueue 是非阻塞队列,它是一个基于链接节点的、无界的、线程安全。此队列按照 FIFO（先进先出）原则对元素进行排序。队列的头部是队列中时间最长的元素。队列的尾部是队列中时间最短的元素。新的元素插入到队列的尾部，队列检索操作从队列头部获得元素。当许多线程共享访问一个公共 collection 时，ConcurrentLinkedQueue 是一个恰当的选择。此队列不允许 null 元素。

使用非阻塞队列，虽然能即时返回结果（消费结果），但必须自行编码解决返回为空的情况处理（以及消费重试等问题）。

并发容器

CopyOnWrite容器

包括:CopyOnWriteArrayList和CopyOnWriteArraySet。

• 适用于读操作远远多于写操作，并且数据量较小的情况。
• 修改容器的代价是昂贵的，因此建议批量增加addAll、批量删除removeAll。

概述

• 运行时注解：通过反射在运行时动态处理注解的逻辑
• 编译时注解：通过注解处理器在编译期动态处理相关逻辑

使用代码自动生成，一是为了提高编码的效率，二是避免在运行期大量使用反射，通过在编译期利用反射生成辅助类和方法以供运行时使用。

gcc，make，CMake

1. gcc是GNU Compiler Collection（就是GNU编译器套件），也可以简单认为是编译器，它可以编译很多种编程语言（括C、C++、Objective-C、Fortran、Java等等）。
2. 程序只有一个源文件时，可以直接用gcc命令编译它。
3. 当程序包含很多个源文件时，用gcc命令逐个去编译时，很容易混乱而且工作量大。
4. make工具可以看成是一个智能的批处理工具，它本身并没有编译和链接的功能，而是用类似于批处理的方式：通过调用makefile文件中用户指定的命令来进行编译和链接的。
5. makefile就像一首歌的乐谱，make工具就像指挥家，指挥家根据乐谱指挥整个乐团怎么样演奏，make工具就根据makefile中的命令进行编译和链接的。makefile命令中就包含了调用gcc（也可以是别的编译器）去编译某个源文件的命令。
6. makefile在一些简单的工程中可以人工编写，但是当工程非常大的时候，手写makefile也是非常麻烦的，如果换了个平台makefile又要重新修改。
7. cmake 是一个跨平台、开源的构建系统。它是一个集软件构建、测试、打包于一身的软件。它使用与平台和编译器独立的配置文件来对软件编译过程进行控制。cmake可以生成makefile文件，并且可以跨平台生成对应平台能用的makefile。
8. cmake根据CMakeLists.txt文件去生成makefile。

CMakeLists.txt语法

常用命令

指定 cmake 的最小版本

1

cmake_minimum_required(VERSION 3.4.1)

这行命令是可选的，在有些情况下，如果 CMakeLists.txt 文件中使用了一些高版本 cmake 特有的一些命令的时候，就需要加上这样一行，提醒用户升级到该版本之后再执行 cmake。

设置项目名称

1

project(demo)

这个命令不是强制性的，但最好都加上。它会引入两个变量 demo_BINARY_DIR 和 demo_SOURCE_DIR，同时，cmake 自动定义了两个等价的变量 PROJECT_BINARY_DIR 和 PROJECT_SOURCE_DIR。

设置编译类型

1
2
3

add_executable(demo demo.cpp) # 生成可执行文件
add_library(common STATIC util.cpp) # 生成静态库
add_library(common SHARED util.cpp) # 生成动态库或共享库

add_library 默认生成是静态库，通过以上命令生成文件名字，在 Linux 下是：

• demo
• libcommon.a
• libcommon.so

在 Windows 下是：

• demo.exe
• common.lib
• common.dll

指定编译包含的源文件

明确指定包含哪些源文件

1

add_library(demo demo.cpp test.cpp util.cpp)

搜索所有的 cpp 文件

aux_source_directory(dir VAR) 发现一个目录下所有的源代码文件并将列表存储在一个变量中。

1
2

aux_source_directory(. SRC_LIST) # 搜索当前目录下的所有.cpp文件
add_library(demo ${SRC_LIST})

自定义搜索规则

1
2
3
4
5
6
7
8
9
10

file(GLOB SRC_LIST "*.cpp" "protocol/*.cpp")
add_library(demo ${SRC_LIST})
# 或者
file(GLOB SRC_LIST "*.cpp")
file(GLOB SRC_PROTOCOL_LIST "protocol/*.cpp")
add_library(demo ${SRC_LIST} ${SRC_PROTOCOL_LIST})
# 或者
aux_source_directory(. SRC_LIST)
aux_source_directory(protocol SRC_PROTOCOL_LIST)
add_library(demo ${SRC_LIST} ${SRC_PROTOCOL_LIST})

查找指定的库文件

find_library(VAR name path)查找到指定的预编译库，并将它的路径存储在变量中。默认的搜索路径为 cmake 包含的系统库，因此如果是 NDK 的公共库只需要指定库的 name 即可。

1
2
3
4
5
6

find_library( # Sets the name of the path variable.
              log-lib
 
              # Specifies the name of the NDK library that
              # you want CMake to locate.
              log )

类似的命令还有 find_file()、find_path()、find_program()、find_package()。

设置包含的目录

1
2
3
4
5

include_directories(
    ${CMAKE_CURRENT_SOURCE_DIR}
    ${CMAKE_CURRENT_BINARY_DIR}
    ${CMAKE_CURRENT_SOURCE_DIR}/include
)

Linux 下还可以通过如下方式设置包含的目录

1

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -I${CMAKE_CURRENT_SOURCE_DIR}")

设置链接库搜索目录

1
2
3

link_directories(
    ${CMAKE_CURRENT_SOURCE_DIR}/libs
)

Linux 下还可以通过如下方式设置包含的目录

1

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -L${CMAKE_CURRENT_SOURCE_DIR}/libs")

设置 target 需要链接的库

1
2
3
4
5
6

target_link_libraries( # 目标库
                       demo
 
                       # 目标库需要链接的库
                       # log-lib 是上面 find_library 指定的变量名
                       ${log-lib} )

在 Windows 下，系统会根据链接库目录，搜索xxx.lib 文件，Linux 下会搜索 xxx.so 或者 xxx.a 文件，如果都存在会优先链接动态库（so 后缀）。

指定链接动态库或静态库

1
2

target_link_libraries(demo libface.a) # 链接libface.a
target_link_libraries(demo libface.so) # 链接libface.so

指定全路径

1
2

target_link_libraries(demo ${CMAKE_CURRENT_SOURCE_DIR}/libs/libface.a)
target_link_libraries(demo ${CMAKE_CURRENT_SOURCE_DIR}/libs/libface.so)

指定链接多个库

1
2
3
4
5

target_link_libraries(demo
    ${CMAKE_CURRENT_SOURCE_DIR}/libs/libface.a
    boost_system.a
    boost_thread
    pthread)

设置变量

set 直接设置变量的值

1
2

set(SRC_LIST main.cpp test.cpp)
add_executable(demo ${SRC_LIST})

set 追加设置变量的值

1
2
3

set(SRC_LIST main.cpp)
set(SRC_LIST ${SRC_LIST} test.cpp)
add_executable(demo ${SRC_LIST})

list 追加或者删除变量的值

1
2
3
4

set(SRC_LIST main.cpp)
list(APPEND SRC_LIST test.cpp)
list(REMOVE_ITEM SRC_LIST main.cpp)
add_executable(demo ${SRC_LIST})

条件控制

if…elseif…else…endif

逻辑判断和比较：

• if (expression)：expression 不为空（0,N,NO,OFF,FALSE,NOTFOUND）时为真
• if (not exp)：与上面相反
• if (var1 AND var2)
• if (var1 OR var2)
• if (COMMAND cmd)：如果 cmd 确实是命令并可调用为真
• if (EXISTS dir) if (EXISTS file)：如果目录或文件存在为真
• if (file1 IS_NEWER_THAN file2)：当 file1 比 file2 新，或 file1/file2 中有一个不存在时为真，文件名需使用全路径
• if (IS_DIRECTORY dir)：当 dir 是目录时为真
• if (DEFINED var)：如果变量被定义为真
• if (var MATCHES regex)：给定的变量或者字符串能够匹配正则表达式 regex 时为真，此处 var 可以用 var 名，也可以用 ${var}
• if (string MATCHES regex)

数字比较：

• if (variable LESS number)：LESS 小于
• if (string LESS number)
• if (variable GREATER number)：GREATER 大于
• if (string GREATER number)
• if (variable EQUAL number)：EQUAL 等于
• if (string EQUAL number)

字母表顺序比较：

• if (variable STRLESS string)
• if (string STRLESS string)
• if (variable STRGREATER string)
• if (string STRGREATER string)
• if (variable STREQUAL string)
• if (string STREQUAL string)

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

if(MSVC)
    set(LINK_LIBS common)
else()
    set(boost_thread boost_log.a boost_system.a)
endif()
target_link_libraries(demo ${LINK_LIBS})
# 或者
if(UNIX)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -fpermissive -g")
else()
    add_definitions(-D_SCL_SECURE_NO_WARNINGS
    D_CRT_SECURE_NO_WARNINGS
    -D_WIN32_WINNT=0x601
    -D_WINSOCK_DEPRECATED_NO_WARNINGS)
endif()
 
if(${CMAKE_BUILD_TYPE} MATCHES "debug")
    ...
else()
    ...
endif()

while…endwhile

1
2
3

while(condition)
    ...
endwhile()

foreach…endforeach

1
2
3

foreach(loop_var RANGE start stop [step])
    ...
endforeach(loop_var)

start 表示起始数，stop 表示终止数，step 表示步长，示例：

1
2
3
4

foreach(i RANGE 1 9 2)
    message(${i})
endforeach(i)
# 输出：13579

打印信息

1
2
3
4

message(${PROJECT_SOURCE_DIR})
message("build with debug mode")
message(WARNING "this is warnning message")
message(FATAL_ERROR "this build has many error") # FATAL_ERROR 会导致编译失败

包含其它 cmake 文件

1
2
3

include(./common.cmake) # 指定包含文件的全路径
include(def) # 在搜索路径中搜索def.cmake文件
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake) # 设置include的搜索路径

常用变量

预定义变量

• PROJECT_SOURCE_DIR：工程的根目录
• PROJECT_BINARY_DIR：运行 cmake 命令的目录，通常是 ${PROJECT_SOURCE_DIR}/build
• PROJECT_NAME：返回通过 project 命令定义的项目名称
• CMAKE_CURRENT_SOURCE_DIR：当前处理的 CMakeLists.txt 所在的路径
• CMAKE_CURRENT_BINARY_DIR：target 编译目录
• CMAKE_CURRENT_LIST_DIR：CMakeLists.txt 的完整路径
• CMAKE_CURRENT_LIST_LINE：当前所在的行
• CMAKE_MODULE_PATH：定义自己的 cmake 模块所在的路径，SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake)，然后可以用INCLUDE命令来调用自己的模块
• EXECUTABLE_OUTPUT_PATH：重新定义目标二进制可执行文件的存放位置
• LIBRARY_OUTPUT_PATH：重新定义目标链接库文件的存放位置

环境变量

• 使用环境变量: $ENV{Name}
• 写入环境变量: set(ENV{Name} value)(这里没有“$”符号)

系统信息

• CMAKE_MAJOR_VERSION：cmake 主版本号，比如 3.4.1 中的 3
• CMAKE_MINOR_VERSION：cmake 次版本号，比如 3.4.1 中的 4
• CMAKE_PATCH_VERSION：cmake 补丁等级，比如 3.4.1 中的 1
• CMAKE_SYSTEM：系统名称，比如 Linux-­2.6.22
• CMAKE_SYSTEM_NAME：不包含版本的系统名，比如 Linux
• CMAKE_SYSTEM_VERSION：系统版本，比如 2.6.22
• CMAKE_SYSTEM_PROCESSOR：处理器名称，比如 i686
• UNIX：在所有的类 UNIX 平台下该值为 TRUE，包括 OS X 和 cygwin
• WIN32：在所有的 win32 平台下该值为 TRUE，包括 cygwin

主要开关选项

• BUILD_SHARED_LIBS：这个开关用来控制默认的库编译方式，如果不进行设置，使用 add_library 又没有指定库类型的情况下，默认编译生成的库都是静态库。如果 set(BUILD_SHARED_LIBS ON) 后，默认生成的为动态库
• CMAKE_C_FLAGS：设置 C 编译选项，也可以通过指令 add_definitions() 添加
• CMAKE_CXX_FLAGS：设置 C++ 编译选项，也可以通过指令 add_definitions() 添加
• add_definitions(-DENABLE_DEBUG -DABC) 参数之间用空格分隔

项目示例

简单项目（单个源文件）

新建cpp文件main.cpp

新建CMakeList.txt

1
2

project(HELLO)
add_executable(hello main.c)

编译运行

一般采用 cmake 的 out-of-source 方式来构建（即生成的中间产物和源代码分离），这样做可以让生成的文件和源文件不会弄混，且目录结构看起来也会清晰明了。所以推荐使用这种方式，至于这个文件夹的命名并无限制，习惯命名为 build。在build目录下依次执行以下命令：

1
2

cd build
cmake ..

然后执行make命令即可生成可执行文件。

复杂项目

目录结构如下：

1
2
3
4
5
6
7
8

.
├── build
├── CMakeLists.txt
├── main.cpp
└── util
    ├── CMakeLists.txt
    ├── util.cpp
    └── util.hpp

demo 根目录下的 CMakeLists.txt 文件如下：

1
2
3
4
5
6
7
8
9

cmake_minimum_required (VERSION 2.8)
project(demo)
aux_source_directory(. DIR_SRCS)
# 添加math子目录
add_subdirectory(util)
# 指定生成目标
add_executable(demo ${DIR_SRCS})
# 添加链接库
target_link_libraries(demo Util)

math 目录下的 CMakeLists.txt 文件如下：

1
2
3

aux_source_directory(. DIR_LIB_SRCS)
# 生成链接库
add_library(Util ${DIR_LIB_SRCS})

CI：持续集成（CONTINUOUS INTEGRATION）

CI的全称是Continuous Integration，表示持续集成。

在CI环境中，开发人员将会频繁地向主干提交代码。这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。

CD：持续部署（CONTINUOUS DEPLOYMENT）

CD的全称是Continuous Deployment，表示持续部署。

在CD环境中，通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，任何修改通过了所有已有的工作流就会直接和客户见面，只有当一个修改在工作流中构建失败才能阻止它部署到产品线。

持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。

基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。

CD：持续交付（CONTINUOUS DELIVERY）

持续交付的英文全称是：Continuous delivery，缩写也是CD，它是一种软件工程手法。

它可以让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

DevOps

DevOps是Development和Operations的组合，是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。以期打破传统开发和运营之间的壁垒和鸿沟。

DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。具体来说，就是在软件交付和部署过程中提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品。

也就是说DevOps是一组过程和方法的统称，并不指代某一特定的软件工具或软件工具组合。各种工具软件或软件组合可以实现DevOps的概念方法。其本质是一整套的方法论，而不是指某种或某些工具集合，与软件开发中设计到的OOP、AOP、IOC（或DI）等类似，是一种理论或过程或方法的抽象或代称。

概述

模块

模块指的是独立的业务模块，比如直播模块，会员模块等。

组件

组件指的是单一的功能组件，如登录组件、上报组件等，每个组件都可以以一个单独的module开发，并且可以单独抽出来作为SDK对外发布使用。

模块和组件间最明显的区别就是模块相对与组件来说粒度更大，一个模块中可能包含多个组件。并且两种方式的本质思想是一样的，都是为了代码重用和业务解耦。在划分的时候，模块化是业务导向，组件化是功能导向。

一个可用的组件化架构图从上向下分别为APP壳，业务层、组件层和基础层：

• 基础层：基础层包含的是一些基础库以及对基础库的封装，比如常用的图片加载，网络请求，数据上报操作等等，其他模块或者组件甚至App应用都可以引用同一套基础库，因此这些基础库最好在另一个项目/git仓库中维护。在基础库上面可以再增加一个Common组件，它位于App应用所在的项目中，用来添加一些都需要引用到的依赖以及本App应用独有的共有方法，UI控件等。
• 组件层：基础层往上是组件层，组件层包含一些功能组件，比如分享，登录，下载，播放等等。
• 业务层：组件层往上是业务层，一个具体的业务模块会按需引用不同的组件，最终实现业务功能。
• APP壳：在APP模块中根据需求统筹各个业务组件，最终输出为一个完整的应用。

组件单独调试

Android Gradle提供了三种插件，在开发中可以通过配置不同的插件来配置不同的工程。

• App插件：com.android.application
• Library插件：com.android.libraay
• Test插件：com.android.test

可以在gradle.properties配置文件中声明一个boolean变量：isAlone，在build.gradle中通过判断这个变量来动态加载不同的插件，ApplicationId以及AndroidManifest文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<!-- main/manifest/AndroidManifest.xml 单独调试 -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.hearing.share">

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">
        <activity android:name=".ShareActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

</manifest>

<!-- main/AndroidManifest.xml 集成调试 -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.hearing.share">

    <application android:theme="@style/AppTheme">
        <activity android:name=".ShareActivity"/>
    </application>
</manifest>

在组件的build.gradle中配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

android {
    defaultConfig {
        if (isAlone.toBoolean()) {
            // 单独调试时添加 applicationId ，集成调试时移除
            applicationId "com.hearing.login"
        }
        // ...
    }

    sourceSets {
        main {
            // 单独调试与集成调试时使用不同的 AndroidManifest.xml 文件
            if (isAlone.toBoolean()) {
                manifest.srcFile 'src/main/manifest/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/AndroidManifest.xml'
            }
        }
    }
}

另外为了使组件化项目中的所有组件的compileSdkVersion、buildToolsVersion以及开源库版本等都能保持统一，也为了方便修改版本号，统一在Android工程根目录下的build.gradle中定义这些版本号，当然也可以在项目根目录添加一个单独的gradle文件定义这些常量，然后由根build.gradle引入。

组件混淆方案

组件化项目的代码混淆方案采用在集成模式下集中在app壳工程中混淆，各个业务组件不配置混淆文件。

组件Application

组件化开发中每一个组件可能都会自定义一个Application类，当所有组件要打包合并在一起的时候，由于程序只能有一个Application，组件中自己定义的Application无法使用。因此需要想办法在任何一个业务组件中都能获取到一个可用的全局Context，而且这个Context不管是在组件开发模式还是在集成开发模式都是生效的。

在基础库组件中封装了项目中用到的各种Base类（BaseActivity，BaseFragment等），这些基类中有一个BaseApplication类，它主要作用是使各个业务组件和app壳工程中都能访问到全局Context，且在其中可以存储一些全局对象：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

object BaseApplication {
    private val mGlobalObjects = mutableMapOf<Any, Any>()
    private var mApplication: Application? = null
    private var mContext: Context? = null

    fun init(application: Application) {
        mApplication = application
        mContext = application.baseContext
    }

    fun getContext(): Context? {
        return mContext ?: mApplication
    }

    fun getApplication(): Application? {
        return mApplication
    }

    @Synchronized
    fun putGlobalObject(key: Any, obj: Any) {
        mGlobalObjects[key] = obj
    }

    @Synchronized
    fun getGlobalObject(key: Any): Any? {
        return mGlobalObjects[key]
    }

    @Synchronized
    fun removeGlobalObject(key: Any): Any? {
        return mGlobalObjects.remove(key)
    }
}

然后可以在本应用的Common组件中定义一个公用的Application基类，然后在各自组件中定义一个Application继承这个基类，这样就可以通过BaseApplication来获取全局的Context了：

1
2
3
4
5
6

open class MyBaseApplication : Application() {
    override fun attachBaseContext(base: Context?) {
        super.attachBaseContext(base)
        BaseApplication.init(this)
    }
}

另外需要在项目从组件模式转换到集成模式后将组件的Application剔除出项目，可以在组件的Java文件夹下创建一个debug文件夹，用于存放不会在业务组件中引用的类，比如说Application类：

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

sourceSets {
    main {
        if (isAlone.toBoolean()) {
            manifest.srcFile 'src/main/module/AndroidManifest.xml'
        } else {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            // 集成开发模式下排除debug文件夹中的所有Java文件
            java {
                exclude 'debug/**'
            }
        }
    }
}

组件间数据传递与方法调用

接下来模拟一个组件间数据传递和方法调用的场景：分享组件分享时需要根据用户是否登录来判断分享的动作。

base_component

base_component组件用来提供组件间数据传递和方法调用的功能。

ILoginService

1
2
3
4

interface ILoginService {
    fun isLogin(): Boolean
    fun getUserId(): String
}

空实现：EmptyLoginService

1
2
3
4
5
6
7
8
9

class EmptyLoginService : ILoginService {
    override fun isLogin(): Boolean {
        return false
    }

    override fun getUserId(): String {
        return ""
    }
}

Service工厂：ServiceFactory

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

object ServiceFactory {
    private val mServices = CopyOnWriteArrayList<Any>()

    fun register(service: Any) {
        if (!mServices.contains(service)) {
            mServices.add(service)
        }
    }

    private fun <T> getService(cls: Class<T>): Any? {
        mServices.forEach {
            if (cls.isInstance(it)) {
                return it
            }
        }
        return null
    }

    fun getLoginService(): ILoginService {
        val service = getService(ILoginService::class.java)
        return service as? ILoginService ?: EmptyLoginService()
    }
}

component_login

登录组件中提供ILoginService的具体实现：

1
2
3
4
5
6
7
8
9

class LoginService : ILoginService {
    override fun isLogin(): Boolean {
        return true
    }

    override fun getUserId(): String {
        return "1024"
    }
}

component_share

分享组件中进行分享的逻辑判断：

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

object ShareHelper {
    fun share() {
        val loginService = ServiceFactory.getLoginService()
        if (loginService.isLogin()) {
            Toast.makeText(
                BaseApplication.getContext(),
                "Share from ${loginService.getUserId()}", Toast.LENGTH_SHORT
            ).show()
        } else {
            Toast.makeText(
                BaseApplication.getContext(),
                "Not login", Toast.LENGTH_SHORT
            ).show()
        }
    }
}

app

在App主Module中进行ILoginService服务的注册：

1
2
3
4
5
6

class MainApplication : MyBaseApplication() {
    override fun onCreate() {
        super.onCreate()
        ServiceFactory.register(LoginService())
    }
}

然后根据业务逻辑调用分享组件的功能：

1
2
3
4
5
6
7
8
9
10

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        findViewById<TextView>(R.id.text_view).setOnClickListener {
            ShareHelper.share()
        }
    }
}

组件间界面跳转

可以使用开源框架：ARouter或者CC等。

总结

以上组件化的内容是在参考了网络上一些关于Android组件化的解析后，结合了自己的理解与思考得到的一些想法，在实际场景里可能会有问题，期待在以后的开发中有更多的实践与思考！

Activity

生命周期

看一下以下操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

// 程序启动
09-25 22:05:34.687 13204-13204/com.hearing.demo D/LLL: onCreate
09-25 22:05:34.718 13204-13204/com.hearing.demo D/LLL: MainActivity-onCreate
09-25 22:05:34.819 13204-13204/com.hearing.demo D/LLL: MainActivity-onStart
09-25 22:05:34.823 13204-13204/com.hearing.demo D/LLL: MainActivity-onResume
// 进入SecondActivity
09-25 22:05:53.802 13204-13204/com.hearing.demo D/LLL: MainActivity-onPause
09-25 22:05:53.815 13204-13204/com.hearing.demo D/LLL: SecondActivity-onCreate
09-25 22:05:53.822 13204-13204/com.hearing.demo D/LLL: SecondActivity-onStart
09-25 22:05:53.824 13204-13204/com.hearing.demo D/LLL: SecondActivity-onResume
09-25 22:05:54.156 13204-13204/com.hearing.demo D/LLL: MainActivity-onStop
// 按下back键
09-25 22:06:04.672 13204-13204/com.hearing.demo D/LLL: SecondActivity-onPause
09-25 22:06:04.716 13204-13204/com.hearing.demo D/LLL: MainActivity-onRestart
09-25 22:06:04.717 13204-13204/com.hearing.demo D/LLL: MainActivity-onStart
09-25 22:06:04.718 13204-13204/com.hearing.demo D/LLL: MainActivity-onResume
09-25 22:06:05.071 13204-13204/com.hearing.demo D/LLL: SecondActivity-onStop
09-25 22:06:05.071 13204-13204/com.hearing.demo D/LLL: SecondActivity-onDestroy
// 按下home键
09-25 22:06:14.703 13204-13204/com.hearing.demo D/LLL: MainActivity-onPause
09-25 22:06:14.722 13204-13204/com.hearing.demo D/LLL: MainActivity-onStop
09-25 22:06:14.723 13204-13204/com.hearing.demo D/LLL: onTrimMemory
// 返回应用
09-25 22:06:18.968 13204-13204/com.hearing.demo D/LLL: MainActivity-onRestart
09-25 22:06:18.970 13204-13204/com.hearing.demo D/LLL: MainActivity-onStart
09-25 22:06:18.970 13204-13204/com.hearing.demo D/LLL: MainActivity-onResume
// 按下back键
09-25 22:06:20.822 13204-13204/com.hearing.demo D/LLL: MainActivity-onPause
09-25 22:06:21.274 13204-13204/com.hearing.demo D/LLL: onTrimMemory
09-25 22:06:21.275 13204-13204/com.hearing.demo D/LLL: MainActivity-onStop
09-25 22:06:21.275 13204-13204/com.hearing.demo D/LLL: MainActivity-onDestroy
// 进入应用
09-25 22:06:39.925 13204-13204/com.hearing.demo D/LLL: MainActivity-onCreate
09-25 22:06:39.959 13204-13204/com.hearing.demo D/LLL: MainActivity-onStart
09-25 22:06:39.963 13204-13204/com.hearing.demo D/LLL: MainActivity-onResume
// 进入task
09-25 22:06:47.056 13204-13204/com.hearing.demo D/LLL: MainActivity-onPause
09-25 22:06:47.068 13204-13204/com.hearing.demo D/LLL: MainActivity-onStop
09-25 22:06:47.088 13204-13204/com.hearing.demo D/LLL: onTrimMemory
// 后台终止
09-25 22:06:51.310 13204-13204/com.hearing.demo D/LLL: MainActivity-onDestroy

各个生命周期的作用：

• onCreate: Activity 已创建 状态，在 Activity 的整个生命周期中只发生一次，用来进行 Activity 的一些初始化工作。
• onStart: 为 Activity 可见做准备工作，此时还不在前台。
• onResume: Activity 进入前台，对用户可见了。
• onPause: 将要离开 Activity, 此时 Activity 依旧可见。可以做一些轻量级数据存储任务，因为在跳转 Activity 时只有当一个 Activity 执行完了 onPause 方法后另一个 Activity 才会启动。
• onStop: 此时 Activity 已经不可见了，但是 Activity 对象还在内存中，在此可以做一些资源回收操作。
• onDestroy: Activity 被销毁。

关于 onRestoreInstanceState 和 onSaveInstanceState 方法：

• onSaveInstanceState 在 onStop 后被调用；
• onRestoreInstanceState 在 onStart 后被调用；

在 Activity 中有一个属性 — View mDecor, 在 PhoneWindow 中有一个属性 — DecorView mDecor，在 handleResumeActivity 方法中，会把 PhoneWindow 中的 mDecor 赋值给 Activity.mDecor。

启动方式

standard

standard 是 Activity 默认的启动模式。在 standard 模式下，每启动一个 Activity 都会创建一个新的实例进入任务栈栈顶。

singleTop

singleTop 模式与 standard 类似，不同的是当启动的 Activity 已经位于栈顶时，则直接使用它不创建新的实例，此时栈顶的 Activity 实例会调 onNewIntent 方法。如果启动的 Activity 没有位于栈顶时，则创建一个新的实例位于栈顶。

singleTask

当 Activity 的启动模式指定为 singleTask，每次启动该 Activity 时，系统首先会检查栈中是否存在该 Activity 的实例，如果发现已经存在则直接使用该实例，此时栈顶的 Activity 实例会调 onNewIntent 方法，并将当前 Activity 之上的所有 Activity 出栈，如果没有发现则创建一个新的实例。

singleInstance

在程序开发过程中，如果需要 Activity 在整个系统中都只有一个实例，这时就需要用到 singleInstance 模式。指定为 singleInstance 模式的 Activity 会启动一个新的任务栈来管理这个 Activity。

singleInstance模式加载Activity时，无论从哪个任务栈中启动该Activity，只会创建一个Activity实例，并且会使用一个全新的任务栈来装载该Activity实例。采用这种模式启动Activity会分为一下两种情况：

• 如果要启动的Activity不存在，系统会创建一个新的任务栈，在创建该Activity的实例，并把该Activity加入栈顶.
• 如果要启动的Activity已经存在，无论位于哪个应用程序或者哪个任务栈中，系统都会把该Activity所在的任务栈转到前台，从而使该Activity显示出来。

taskAffinity

概述

每个Activity都有taskAffinity属性，这个属性指出了它希望进入的Task。如果一个Activity没有显式的指明该Activity的taskAffinity，那么它的这个属性就等于Application指明的taskAffinity，如果Application也没有指明，那么该taskAffinity的值就等于包名。而Task也有自己的affinity属性，它的值等于它的根Activity的taskAffinity的值。

allowTaskReparenting

如果该Activity的allowTaskReparenting设置为true，它进入后台，当一个和它有相同affinity的Task进入前台时，它会重新宿主，进入到该前台的task中。

创建两个工程：application1和application2，分别含有Activity1和Activity2，它们的taskAffinity相同，Activity1的allowTaskReparenting为true。

首先，我们启动application1,加载Activity1，然后按Home键，使该task（假设为task1）进入后台。然后启动application2，默认加载Activity2。本来应该是显示Activity2，但是我们却看到了Activity1。实际上Activity2也被加载了，只是Activity1重新宿主，所以看到了Activity1。

FLAG_ACTIVITY_NEW_TASK

如果加载某个Activity的intent，Flag被设置成FLAG_ACTIVITY_NEW_TASK时，它会首先检查是否存在与自己taskAffinity相同的Task，如果存在，那么它会直接宿主到该Task中，如果不存在则重新创建Task。

写一个应用，包含两个Activity：Activity1的taskAffinity为com.hearing.task，Activity2为入口，且点击Activity2会以FLAG_ACTIVITY_NEW_TASK启动Activity1。再写一个应用MyActivity，它包含一个Activity（MyActivity），其taskAffinity为com.hearing.task。

首先启动MyActivity，然后Home回桌面，然后打开Activity2，点击Activity2，进入Activity1。然后按返回键。进入Activity的顺序为Activity2->Activity1，而返回时顺序为Activity1->MyActivity。这就说明了一个问题，Activity1在启动时，重新宿主到了MyActivity所在的Task中去了。

launchMode

• 当一个应用程序加载一个singleTask模式的Activity时，首先该Activity会检查是否存在与它的taskAffinity相同的Task。如果存在，那么检查是否实例化，如果已经实例化，那么销毁在该Activity以上的Activity并调用onNewIntent。如果没有实例化，那么该Activity实例化并入栈。如果不存在，那么就重新创建Task，并入栈。
• 当一个应用程序加载一个singleInstance模式的Activity时，如果该Activity没有被实例化，那么就重新创建一个Task，并入栈，如果已经被实例化，那么就调用该Activity的onNewIntent.singleInstance的Activity所在的Task不允许存在其他Activity，任何从该Activity加载的其它Activity（假设为Activity2）都会被放入其它的Task中，如果存在与Activity2相同affinity的Task，则在该Task内创建Activity2。如果不存在，则重新生成新的Task并入栈。

启动方式的问题

MainActivity是SingleTask或者SingleInstance模式，启动TestActivity，TestActivity马上跳转到MainActivity，这种情况下，MainActivity的onResume会回调两次。日志如下：

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

com.hearing.activitytest.MainActivity@2c5d2eb onCreate
com.hearing.activitytest.MainActivity@2c5d2eb onStart
com.hearing.activitytest.MainActivity@2c5d2eb onResume
com.hearing.activitytest.MainActivity@2c5d2eb onPause
TestActivity onCreate
TestActivity onStart
TestActivity onResume
TestActivity onPause
com.hearing.activitytest.MainActivity@2c5d2eb onNewIntent
com.hearing.activitytest.MainActivity@2c5d2eb onResume
com.hearing.activitytest.MainActivity@2c5d2eb onPause
com.hearing.activitytest.MainActivity@2c5d2eb onResume
TestActivity onStop

适当延时500ms再跳转回MainActivity可以解决这个问题（可能由于业务场景不同，会带来新的问题）。

在stackoverflow上也有人发现过类似的问题。

BroadcastReceiver

分类

• 普通广播（Normal Broadcast）
• 系统广播（System Broadcast）
• 有序广播（Ordered Broadcast）
• 粘性广播（Sticky Broadcast）（已弃用）
• App应用内广播（Local Broadcast）

使用步骤

BroadcastReceiver

• 继承BroadcastReceivre基类
• 复写抽象方法onReceive()方法

注册

静态注册

• 常驻：不受任何组件声明周期影响
• 耗电，占内存

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<receiver 
    android:enabled=["true" | "false"]
    //此broadcastReceiver能否接收其他App的发出的广播
    //默认值是由receiver中有无intent-filter决定的：如果有intent-filter，默认值为true，否则为false
    android:exported=["true" | "false"]
    android:icon="drawable resource"
    android:label="string resource"
    //继承BroadcastReceiver子类的类名
    android:name=".mBroadcastReceiver"
    //具有相应权限的广播发送者发送的广播才能被此BroadcastReceiver所接收；
    android:permission="string"
    //BroadcastReceiver运行所处的进程
    //默认为app的进程，可以指定独立的进程
    //注：Android四大基本组件都可以通过此属性指定自己的独立进程
    android:process="string" >

    //用于指定此广播接收器将接收的广播类型
    //本示例中给出的是用于接收网络状态改变时发出的广播
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>

动态注册

• 非常驻，灵活
• 手动释放

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

@Override
protected void onResume(){
    super.onResume();
    mBroadcastReceiver mBroadcastReceiver = new mBroadcastReceiver();
    IntentFilter intentFilter = new IntentFilter();
    intentFilter.addAction(android.net.conn.CONNECTIVITY_CHANGE);
    registerReceiver(mBroadcastReceiver, intentFilter);
}

@Override
protected void onPause() {
    super.onPause();
    unregisterReceiver(mBroadcastReceiver);
}

Service

概述

生命周期:

1. startService()

   • 作用：启动Service服务
   • 手动调用startService()后，自动调用内部方法：onCreate()、onStartCommand()
   • 如果一个service被startService多次启动，onCreate()只会调用一次
   • onStartCommand()调用次数=startService()次数

2. stopService()

   • 作用：关闭Service服务
   • 手动调用stopService()后，自动调用内部方法：onDestory()
   • 如果一个service被启动且被绑定，如果没有在绑定的前提下stopService()是无法停止服务的。

3. bindService()

   • 作用：绑定Service服务
   • 手动调用bindService()后，自动调用内部方法：onCreate()、onBind()

4. unbindService()

   • 作用：解绑Service服务
   • 手动调用unbindService()后，自动调用内部方法：onCreate()、onBind()、onDestory()

接口函数：

• onStartCommand()：当其他组件调用startService()方法请求启动Service时，该方法被回调。一旦Service启动，它会在后台独立运行。当Service执行完以后，需调用stopSelf() 或 stopService()方法停止Service。（若您只希望bind Service，则无需调用这些方法）
• onBind()：当其他组件调用bindService()方法请求绑定Service时，该方法被回调。该方法返回一个IBinder接口，该接口是Service与绑定的组件进行交互的桥梁。若Service未绑定其他组件，该方法应返回null。
• onCreate()：当Service第一次创建时，回调该方法。该方法只被回调一次，并在onStartCommand() 或 onBind()方法被回调之前执行。若Service处于运行状态，该方法不会回调。
• onDestroy()：当Service被销毁时回调，在该方法中应清除一些占用的资源，如停止线程、接触绑定注册的监听器或broadcast receiver 等。该方法是Service中的最后一个回调。

启动方式：

• Started：其他组件调用startService()方法启动一个Service。一旦启动，Service将一直运行在后台（run in the background indefinitely）即便启动Service的组件已被destroy。通常，一个被start的Service会在后台执行单独的操作，也并不给启动它的组件返回结果。比如说，一个start的Service执行在后台下载或上传一个文件的操作，完成之后，Service应自己停止。
• Bound：其他组件调用bindService()方法绑定一个Service。通过绑定方式启动的Service是一个client-server结构，该Service可以与绑定它的组件进行交互。一个bound service仅在有组件与其绑定时才会运行（A bound service runs only as long as another application component is bound to it），多个组件可与一个service绑定，service不再与任何组件绑定时，该service会被destroy。

注意：

• Service运行在主线程中（A service runs in the main thread of its hosting process），Service并不是一个新的线程，也不是新的进程。也就是说，若您需要在Service中执行较为耗时的操作（如播放音乐、执行网络请求等），需要在Service中创建一个新的线程。这可以防止ANR的发生，同时主线程可以执行正常的UI操作。
• 如果某个组件通过调用startService()启动了Service（系统会回调onStartCommand()方法），那么直到在Service中手动调用stopSelf()方法、或在其他组件中手动调用stopService()方法，该Service才会停止。
• 如果某个组件通过调用bindService()绑定了Service（系统不会回调onStartCommand()方法），只要该组件与Service处于绑定状态，Service就会一直运行，当Service不再与组件绑定时，该Service将被destroy。
• 当系统内存低时，系统将强制停止Service的运行；若Service绑定了正在与用户交互的activity，那么该Service将不大可能被系统kill（ less likely to be killed）。如果创建的是前台Service，那么该Service几乎不会被kill（almost never be killed）。否则，当创建了一个长时间在后台运行的Service后，系统会降低该Service在后台任务栈中的级别——这意味着它容易被kill（lower its position in the list of background tasks over time and the service will become highly susceptible to killing），所以在开发Service时，需要使Service变得容易被restart，因为一旦Service被kill，再restart它需要其资源可用时才行

注册

1

<service android:name="com.example.servicetest.MyService"/>

继承IntentService类

• 默认在子线程中处理回传到onStartCommand()方法中的Intent；
• 在重写的onHandleIntent()方法中处理按时间排序的Intent队列，所以不用担心多线程带来的问题。
• 当所有请求处理完成后，自动停止service，无需手动调用stopSelf()方法；
• 默认实现了onBind()方法，并返回null；
• 默认实现了onStartCommand()方法，并将回传的Intent以序列的形式发送给onHandleIntent()，只需重写该方法并处理Intent即可。

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

class MyService : IntentService("MyService") {

    override fun onCreate() {
        Log.d("LLL", "onCreate")
        super.onCreate()
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        Log.d("LLL", "onStartCommand: $startId")
        return super.onStartCommand(intent, flags, startId)
    }

    override fun onDestroy() {
        Log.d("LLL", "onDestroy")
        super.onDestroy()
    }

    override fun onHandleIntent(intent: Intent?) {
        Log.d("LLL", "Current thread: ${Thread.currentThread().name}")
        Log.d("LLL", "Intent: ${intent?.getStringExtra("name")}")
        Thread.sleep(1000)
    }
}

// 使用
val intent = Intent(this, MyService::class.java)
intent.putExtra("name", "hearing-1")
startService(intent)
Thread.sleep(20)
intent.putExtra("name", "hearing-2")
startService(intent)
Thread.sleep(20)
intent.putExtra("name", "hearing-3")
startService(intent)

// 日志
D/LLL: onCreate
D/LLL: onStartCommand: 1
D/LLL: onStartCommand: 2
D/LLL: onStartCommand: 3
D/LLL: Current thread: IntentService[MyService]
D/LLL: Intent: hearing-1
D/LLL: Current thread: IntentService[MyService]
D/LLL: Intent: hearing-2
D/LLL: Current thread: IntentService[MyService]
D/LLL: Intent: hearing-3
D/LLL: onDestroy

如果启动的 Service 存在则不会再次创，而会回调 onStartCommand 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public int onStartCommand(@Nullable Intent intent, int flags, int startId) {
    onStart(intent, startId);
    return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY;
}

public void onStart(@Nullable Intent intent, int startId) {
    Message msg = mServiceHandler.obtainMessage();
    msg.arg1 = startId;
    msg.obj = intent;
    mServiceHandler.sendMessage(msg);
}

private final class ServiceHandler extends Handler {
    public ServiceHandler(Looper looper) {
        super(looper);
    }

    @Override
    public void handleMessage(Message msg) {
        onHandleIntent((Intent)msg.obj);
        // 会检查 id 是否为最后一个 id，是则停止服务
        stopSelf(msg.arg1);
    }
}

继承Service类

如果需要在Service中执行多线程而不是处理一个请求队列，那么需要继承Service类，分别处理每个Intent。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

public class MyService extends Service {

    public static final String TAG = "MyService";

    private MyBinder mBinder = new MyBinder();

    @Override
    public void onCreate() {
        super.onCreate();
        Log.d(TAG, "onCreate() executed");
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        Log.d(TAG, "onStartCommand() executed");
        return super.onStartCommand(intent, flags, startId);
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        Log.d(TAG, "onDestroy() executed");
    }

    @Override
    public IBinder onBind(Intent intent) {
        return mBinder;
    }

    class MyBinder extends Binder {
        public void startDownload() {
            Log.d("TAG", "startDownload() executed");
            // 执行具体的下载任务
        }
    }
}

onStartCommand()返回一个整形变量，该变量必须是下列常量之一：

• START_NOT_STICKY：若执行完onStartCommand()方法后，系统就kill了service，不要再重新创建service，除非系统回传了一个pending intent。这避免了在不必要的时候运行service，您的应用也可以restart任何未完成的操作。
• START_STICKY：若系统在onStartCommand()执行并返回后kill了service，那么service会被recreate并回调onStartCommand()。dangerous不要重新传递最后一个Intent（do not redeliver the last intent）。相反，系统回调onStartCommand()时回传一个空的Intent，除非有 pending intents传递，否则Intent将为null。该模式适合做一些类似播放音乐的操作。
• START_REDELIVER_INTENT：若系统在onStartCommand()执行并返回后kill了service，那么service会被recreate并回调onStartCommand()并将最后一个Intent回传至该方法。任何 pending intents都会被轮流传递。该模式适合做一些类似下载文件的操作。

启动服务

startService(intent)方法将立即返回，并回调onStartCommand()（请不要手动调用该方法），若该Service未处于运行状态，系统将首先回调onCreate()，接着再回调onStartCommand()。若您希望Service可以返回结果，那么需要通过调用getBroadcast 返回的PendingIntent启动Service（将PendingIntent包装为Intent），service可使用broadcast 传递结果。

多个启动Service的请求可能导致onStartCommand()多次调用，但只需调用stopSelf() 、 stopService()这两个方法之一，就可停止该服务。

绑定Service

• 通过其他组件调用bindService()方法可以绑定一个Service以保持长连接（long-standing connection），这时一般不允许其他组件调用startService()启动Service。
• 当其他组件需要与Service交互或者需要跨进程通信时，可以创建一个bound Service。
• 为创建一个bound Service，必须重写onBind()回调，该方法返回一个IBinder接口。该接口时组件与Service通信的桥梁。组件调用bindService()与Service绑定，该组件可获取IBinder接口，一旦获取该接口，就可以调用Service中的方法。一旦没有组件与Service绑定，系统将destroy它，您不必手动停止它。
• 为创建一个bound Service，必须定义一个接口 ，该接口指定组件与Service如何通信。定义的接口在组件与Service之间，且必须实现IBinder接口。这正是onBind()的返回值。一旦组件接收了IBinder，组件与Service便可以开始通信。
• 多个组件可同时与Service绑定，当组件与Service交互结束后，可调用unbindService()方法解绑。bound Service比start Service要复杂，故我将在后续单独翻译。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

public class MainActivity extends Activity implements OnClickListener {

    private MyService.MyBinder myBinder;

    private ServiceConnection connection = new ServiceConnection() {

        @Override
        public void onServiceDisconnected(ComponentName name) {
        }

        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            myBinder = (MyService.MyBinder) service;
            myBinder.startDownload();
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
        case R.id.start_service:
            Intent startIntent = new Intent(this, MyService.class);
            startService(startIntent);
            break;
        case R.id.stop_service:
            Intent stopIntent = new Intent(this, MyService.class);
            stopService(stopIntent);
            break;
        case R.id.bind_service:
            Intent bindIntent = new Intent(this, MyService.class);
            bindService(bindIntent, connection, BIND_AUTO_CREATE);
            break;
        case R.id.unbind_service:
            unbindService(connection);
            break;
        default:
            break;
        }
    }
}

运行前台Service

• 前台Service用于动态通知消息，如天气预报。该Service不易被kill。前台Service必须提供status bar，只有前台Service被destroy后，status bar才能消失。
• 举例来说，一个播放音乐的Service必须是前台Service，只有这样用户才能确知其运行状态。为前台Service提供的status bar可以显示当前音乐的播放状态，并可以启动播放音乐的Activity。
• 调用startForeground()可以启动前台Service。该方法接收两个参数，参数一是一个int型变量，用户指定该通知的唯一性标识，而参数而是一个Notification用于配置status bar

ContentProvider

概述

ContentProvider 需要实现的接口：

1
2
3
4
5
6

public Uri insert(Uri uri, ContentValues values) 
public int delete(Uri uri, String selection, String[] selectionArgs) 
public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs)
public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs,  String sortOrder)　 
public boolean onCreate() 
public String getType(Uri uri)

参数含义：

• projection: 返回内容(conlumn名)，null 表示返回所有
• selection: 设置条件
• selectionArgs: selection 参数条件的内容
• sortOrder: ASC(升序)，DESC(降序)，默认升序

例如：

1

Cursor cursor = contentResolver.query(uri, new String[]{"name"}, "name=?", new String[]{"hearing"}, "id DESC");

可以通过 ContentResolver 类与 ContentProvider 统一进行交互；可以通过 ContentObserver 类监听 ContentProvider 中指定 Uri 的数据变化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class MyObserver extends ContentObserver {

    public MyObserver(Handler handler) {
        super(handler);
    }

    @Override
    public void onChange(boolean selfChange, Uri uri) {
        super.onChange(selfChange, uri);
    }
}

// 步骤1：注册内容观察者ContentObserver
getContentResolver().registerContentObserver(uri, true, myOberver);

// 步骤2：当该URI的ContentProvider数据发生变化时，通知外界
public class UserContentProvider extends ContentProvider { 
    public Uri insert(Uri uri, ContentValues values) { 
        db.insert("user", "userid", values); 
        getContext().getContentResolver().notifyChange(uri, null); 
    }
}

// 步骤3：解除观察者
getContentResolver().unregisterContentObserver(myOberver);

Uri

Uri 的四个组成部分：content://contacts/people/5

• schema：已由Android固定设置为content://
• authority：ContentProvider权限，在AndroidMenifest中设置权限
• path：要操作的数据库表
• id：查询的关键字（可选字段）

Uri匹配模式：Uri的匹配表示要查询的数据，对于单个数据查询，可直接使用Uri定位具体的资源位置，但当范围查询时就需要结合通配符的使用，Uri提供以下两种通配符：

• *：匹配由任意长度的任何有效字符组成的字符串
• #：匹配由任意长度的数字字符组成的字符串

示例：

1
2
3

content://com.example.app.provider/table2/*  //多数据查询
content://com.example.app.provider/table3/#
content://com.example.app.provider/table3/6  //单数据查询

ContentUris

核心方法有两个：

• withAppendedId()：向Uri追加一个id
• parseId()：从Uri中获取id

1
2
3
4
5
6
7

Uri uri = Uri.parse("content://com.hearing.provider/user")
// 生成的Uri为：content://com.hearing.provider/user/7
Uri resultUri = ContentUris.withAppendedId(uri, 7);

Uri uri = Uri.parse("content://com.hearing.provider/user/7")
//获取的结果为:7
long personid = ContentUris.parseId(uri);

UriMatcher

UriMatcher的作用：

• 在 ContentProvider 中注册Uri
• 根据 Uri 匹配 ContentProvider 中对应的数据表

使用步骤：

1. 初始化UriMatcher对象
2. 在ContentProvider 中注册URI（addURI()）
3. 根据URI 匹配 URI_CODE，从而匹配ContentProvider中相应的资源（match()）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// 步骤1：初始化UriMatcher对象
// 常量UriMatcher.NO_MATCH：不匹配任何路径的返回码
UriMatcher matcher = new UriMatcher(UriMatcher.NO_MATCH);

// 步骤2：在ContentProvider 中注册URI
int URI_CODE_a = 1；
int URI_CODE_b = 2；
matcher.addURI("com.hearing.provider", "user1", URI_CODE_a); 
matcher.addURI("com.hearing.provider", "user2", URI_CODE_b); 
// 若URI资源路径 = content://com.hearing.provider/user1 ，则返回注册码URI_CODE_a
// 若URI资源路径 = content://com.hearing.provider/user2 ，则返回注册码URI_CODE_b

// 步骤3：根据URI 匹配 URI_CODE，从而匹配ContentProvider中相应的资源
private String getTableName(Uri uri) {
    Uri uri = Uri.parse("content://com.hearing.provider/user1");

    switch(matcher.match(uri)) {
        case URI_CODE_a:
            return tableNameUser1;
        case URI_CODE_b:
            return tableNameUser2;
    }
}

权限

概述

指定其他应用访问提供程序的数据所必须具备权限的属性。

grantUriPermssions

android:grantUriPermssions：表示是否可以通过临时权限访问数据，默认为false，在开发中可以只对限定的内容提供临时权限，如对照片的内容 URI 设置临时权限。

1
2
3
4
5

android:grantUriPermissions="false"

<grant-uri-permission android:path="string"
    android:pathPattern="string"
    android:pathPrefix="string" />

• true：系统会向整个系统授予临时权限，并替代其他设置的权限。
• false：需添加<grant-uri-permission>并表明可以授权临时权限所对应的URI
  • path：表示绝对路径Uri
  • pathPattern：表示限定完整的路径但可以使用./*通配符匹配
  • pathPrefix：限定路径的初始部分后面可以变化，只要初始部分符合即可授权

permission

• android:permission：统一提供程序范围读取/写入权限
• android:readPermission：提供程序范围读取权限，优先于permission权限
• android:writePermission：提供程序范围写入权限，优先于permission权限

1
2
3

android:readPermission="com.hearing.provider.permission.READ_PERMISSION"
android:writePermission="com.hearing.provider.permission.WRITE_PERMISSION"
android:permission="com.hearing.provider.permission.PERMISSION"

使用

1. 创建两个程序A和B，在程序A中使用ContentProvider保存数据，在程序B中进行查询，在开始A程序中不设置任何权限，B程序进行访问数据会报错；
2. 修改A程序清单文件添加android:exported=”true”，再次访问数据访问成功；
3. 在A程序的清单文件中，为Provider添加两个读写权限，添加完权限后再次在B程序中获取数据，还是会报错，也很正常因为已经对数据的访问设置了门槛，所以在B程序中声明读写权限即可。

1
2
3
4
5
6
7

<!-- A程序 -->
android:writePermission="com.hearing.provider.provider.WRITE"
android:readPermission="com.hearing.provider.provider.READ"

<!-- B程序 -->
<uses-permission android:name="com.hearing.provider.provider.READ"/>
<uses-permission android:name="com.hearing.provider.provider.WRITE"/>

实例：IPC

进程一

创建数据库类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class DBHelper extends SQLiteOpenHelper {

    // 数据库名
    private static final String DATABASE_NAME = "finch.db";

    // 表名
    public static final String USER_TABLE_NAME = "user";
    public static final String JOB_TABLE_NAME = "job";

    // 数据库版本号
    private static final int DATABASE_VERSION = 1;

    public DBHelper(Context context) {
        super(context, DATABASE_NAME, null, DATABASE_VERSION);
    }

    @Override
    public void onCreate(SQLiteDatabase db) {
        // 创建两个表格:用户表 和职业表
        db.execSQL("CREATE TABLE IF NOT EXISTS " + USER_TABLE_NAME + "(_id INTEGER PRIMARY KEY AUTOINCREMENT," + " name TEXT)");
        db.execSQL("CREATE TABLE IF NOT EXISTS " + JOB_TABLE_NAME + "(_id INTEGER PRIMARY KEY AUTOINCREMENT," + " job TEXT)");
    }

    @Override
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion)   {
    }
}

自定义ContentProvider：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

public class MyProvider extends ContentProvider {

    private Context mContext;
    DBHelper mDbHelper = null;
    SQLiteDatabase db = null;

    // 设置ContentProvider的唯一标识
    public static final String AUTOHORITY = "com.hearing.provider";

    public static final int User_Code = 1;
    public static final int Job_Code = 2;

    // UriMatcher类使用:在ContentProvider 中注册URI
    private static final UriMatcher mMatcher;

    static {
        mMatcher = new UriMatcher(UriMatcher.NO_MATCH);
        // 初始化
        mMatcher.addURI(AUTOHORITY, "user", User_Code);
        mMatcher.addURI(AUTOHORITY, "job", Job_Code);
    }

    @Override
    public boolean onCreate() {
        mContext = getContext();
        // 在ContentProvider创建时对数据库进行初始化，不能做耗时操作，此处仅作展示
        mDbHelper = new DBHelper(getContext());
        db = mDbHelper.getWritableDatabase();

        db.execSQL("delete from user");
        db.execSQL("insert into user values(1,'Carson');");
        db.execSQL("insert into user values(2,'Kobe');");

        db.execSQL("delete from job");
        db.execSQL("insert into job values(1,'Android');");
        db.execSQL("insert into job values(2,'iOS');");

        return true;
    }

    @Override
    public Uri insert(Uri uri, ContentValues values) {
        String table = getTableName(uri);
        db.insert(table, null, values);
        mContext.getContentResolver().notifyChange(uri, null);
        return uri;
    }

    @Override
    public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
        String table = getTableName(uri);
        return db.query(table, projection, selection, selectionArgs, null, null, sortOrder, null);
    }

    @Override
    public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) {
        // 此处不作展开
        return 0;
    }

    @Override
    public int delete(Uri uri, String selection, String[] selectionArgs) {
        // 此处不作展开
        return 0;
    }

    @Override
    public String getType(Uri uri) {
        // 此处不作展开
        return null;
    }

    private String getTableName(Uri uri) {
        String tableName = null;
        switch (mMatcher.match(uri)) {
            case User_Code:
                tableName = DBHelper.USER_TABLE_NAME;
                break;
            case Job_Code:
                tableName = DBHelper.JOB_TABLE_NAME;
                break;
        }
        return tableName;
    }
}

注册ContentProvider：

1
2
3
4
5
6
7
8
9
10
11

<provider
    android:name="MyProvider"
    android:authorities="com.hearing.provider.myprovider"
    android:permission="com.hearing.provider.PROVIDER"
    android:readPermission = "com.hearing.provider.Read"
    android:writePermission = "com.hearing.provider.Write"
    android:exported="true"/>

<permission android:name="com.hearing.provider.Read" android:protectionLevel="normal"/>
<permission android:name="com.hearing.provider.Write" android:protectionLevel="normal"/>
<permission android:name="com.hearing.provider.PROVIDER" android:protectionLevel="normal"/>

进程二

声明权限：

1
2
3
4

<uses-permission android:name="com.hearing.provider.PROVIDER"/>

<uses-permission android:name="com.hearing.provider.Read"/>
<uses-permission android:name="com.hearing.provider.Write"/>

访问ContentProvider：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // 设置URI
        Uri uri_user = Uri.parse("content://com.hearing.provider.myprovider/user");

        // 插入表中数据
        ContentValues values = new ContentValues();
        values.put("_id", 4);
        values.put("name", "Jordan");

        // 获取ContentResolver
        ContentResolver resolver = getContentResolver();
        // 通过ContentResolver 根据URI 向ContentProvider中插入数据
        resolver.insert(uri_user, values);

        // 通过ContentResolver 向ContentProvider中查询数据
        Cursor cursor = resolver.query(uri_user, new String[]{"_id","name"}, null, null, null);
        while (cursor.moveToNext()) {
            System.out.println("query book:" + cursor.getInt(0) +" "+ cursor.getString(1));
        }
        cursor.close();

        // 和上述类似,只是URI需要更改,从而匹配不同的URI CODE,从而找到不同的数据资源
        Uri uri_job = Uri.parse("content://com.hearing.provider.myprovider/job");

        // 插入表中数据
        ContentValues values2 = new ContentValues();
        values2.put("_id", 4);
        values2.put("job", "NBA Player");

        // 获取ContentResolver
        ContentResolver resolver2 = getContentResolver();
        // 通过ContentResolver 根据URI 向ContentProvider中插入数据
        resolver2.insert(uri_job,values2);

        // 通过ContentResolver 向ContentProvider中查询数据
        Cursor cursor2 = resolver2.query(uri_job, new String[]{"_id","job"}, null, null, null);
        while (cursor2.moveToNext()) {
            System.out.println("query job:" + cursor2.getInt(0) +" "+ cursor2.getString(1));
        }
        cursor2.close();
    }
}

FileProvider

概述

对于面向Android 7.0及以上的应用，Android禁止在应用外部公开file://url。如果一项包含文件URI的intent离开应用，则应用会抛出FileUriExposedException异常。

解决方案：要在应用间共享文件，应发送一项content://URI，并授予URI临时访问权限。进行此授权的最简单方式是使用FileProvider类。FileProvider是ContentProvider的一个特殊的子类，它让应用间共享文件变得更加容易，其通过创建一个Content URI来代替File URI。

注册FileProvider

由于FileProvider中已经包含了为file生成Content URI的基本代码了，所以开发者不必再去定义一个FileProvider的子类。你可以在XML文件中指定一个FileProvider：在manifest中使用<provider>标签来指定。

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

<manifest>
    ...
    <application>
        ...
        <provider
            android:name="android.support.v4.content.FileProvider"
            android:authorities="com.hearing.fileprovider"
            android:exported="false"
            android:grantUriPermissions="true">
            <meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/file_paths" />
        </provider>
        ...
    </application>
</manifest>

• name的值一般都固定为android.support.v4.content.FileProvider。如果开发者继承了FileProvider，则可以写上其绝对路径。
• authorities字段的值用来表明使用的使用者，在FileProvider的函数getUriForFile需要传入该参数。
• exported 的值为false，表示该FileProvider只能本应用使用，不是public的。
• grantUriPermissions 的值为true，表示允许赋予临时权限。

xml配置

只有事先指定了目录，一个FileProvider才可以为文件生成一个对应的Content URI。要指定一个路径，需要在XML文件中指定其存储的路径。使用<paths>标签。例如:

1
2
3

<paths xmlns:android="http://schemas.android.com/apk/res/android">
    <files-path name="my_images" path="images/"/>
</paths>

• <root-path name="name" path="path" />: /
• <files-path name="name" path="path" />: /data/data/<package-name>/files/path/
• <cache-path name="name" path="path" />: /data/data/<package-name>/cache/path/
• <external-files-path name="name" path="path" />: Context.getExternalFilesDir(null) + "/path/"，/storage/emulated/0/Android/data/<package_name>/files/path/
• <external-cache-path name="name" path="path" />: Context.getExternalCacheDir() + "/path/"，即/storage/emulated/0/Android/data/<package-name>/cache/path/
• <external-media-path name="name" path="path" />: Context.getExternalMediaDirs() + "/path/"，即/storage/emulated/0/Android/media/<package-name>/path/
• <external-path name="name" path="path" />: Environment.getExternalStorageDirectory() + "/path/"，即/storage/emulated/0/path/

在res目录下新建xml目录，然后新建文件file_paths.xml，根据上述内容编写。

获取Content Uri

1
2
3
4
5
6
7

File file = new File(mContext.getFilesDir() + "/text", "hello.txt");
Uri data;
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
    data = FileProvider.getUriForFile(mContext, "com.hearing.fileprovider", file);
} else {
    data = Uri.fromFile(file);
}

赋予临时权限

两种方法：（通常使用第2种）

1. Context.grantUriPermission(package, Uri, mode_flags)
2. Intent.setFlags()：intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | FLAG_GRANT_WRITE_URI_PERMISSION);

Flag意义如下：

• FLAG_GRANT_READ_URI_PERMISSION：表示读取权限；
• FLAG_GRANT_WRITE_URI_PERMISSION：表示写入权限。

分享文件URI

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

private void shareFile() {
    Log.d(TAG, "shareFile: ");
    Intent intent = new Intent();
    ComponentName componentName = new ComponentName("com.hearing.fileproviderclient",
            "com.hearing.fileproviderclient.MainActivity");
    intent.setComponent(componentName);
    File file = new File(mContext.getFilesDir() + "/text", "hello.txt");
    Uri data;
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
        data = FileProvider.getUriForFile(mContext, FILE_PROVIDER_AUTHORITIES, file);
        // 给目标应用一个临时授权
        intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
    } else {
        data = Uri.fromFile(file);
    }
    intent.setData(data);
    startActivity(intent);
}

Mime Type

概述

MIME：多用途互联网邮件扩展（Multipurpose Internet Mail Extensions）是一个互联网标准，它扩展了电子邮件标准，使其能够支持非ASCII字符、二进制格式附件等多种格式的邮件消息。

MIME TYPE一般以这种形式出现：[type]/[subtype]

type标识内容type，有下面的形式：

• Text：用于标准化地表示的文本信息，文本消息可以是多种字符集和或者多种格式的；
• Multipart：用于连接消息体的多个部分构成一个消息，这些部分可以是不同类型的数据；
• Application：用于传输应用程序数据或者二进制数据；
• Message：用于包装一个E-mail消息；
• Image：用于传输静态图片数据；
• Audio：用于传输音频或者音声数据；
• Video：用于传输动态影像数据，可以是与音频编辑在一起的视频数据格式。

subtype用于指定type的详细形式。content-type/subtype配对的集合和与此相关的参数，将随着时间而增长。为了确保这些值在一个有序而且公开的状态下开发，MIME使用Internet Assigned Numbers Authority (IANA)作为中心的注册机制来管理这些值。常用的subtype值如下所示：

• text/plain（纯文本）
• text/html（HTML文档）
• application/xhtml+xml（XHTML文档）
• image/gif（GIF图像）
• image/jpeg（JPEG图像）
• image/png（PNG图像）
• video/mpeg（MPEG动画）
• application/octet-stream（任意的二进制数据）
• application/pdf（PDF文档）
• application/msword（Microsoft Word文件）
• message/rfc822（RFC 822形式）
• multipart/alternative（HTML邮件的HTML形式和纯文本形式，相同内容使用不同形式表示）
• application/x-www-form-urlencoded（使用HTTP的POST方法提交的表单）
• multipart/form-data（同上，但主要用于表单提交时伴随文件上传的场合）

使用

当Android系统接收到一个隐式Intent要启动一个Activity(或其他组件)时，Android会根据以下三个信息比较Intent的信息与注册的组件的intent-filter的信息，从而为该Intent选择出最匹配的Activity(或其他组件)：

• intent中的action
• intent中的category
• intent中的data（包含Uri以及data的MIME类型）

也就是隐式intent对象要满足要启动的目标组件中注册的intent-filter中的<action/>、<category/>、<data/>三个标签中的信息，即要分别通过action测试、category测试以及data测试。

MINI类型即在data中指定。

Intent和Intent-filter

概述

• Intent 是一个消息传递对象，可以用来从其他应用组件请求操作, Intent 包括显式和隐式。
• Intent-filter 是 Manifest 中的一个表达式，用于指定该组件要接收的 Intent 类型。

为了确保应用的安全性，启动 Service 时应该始终使用显式 Intent，且不要为服务声明 Intent-filter。

构建Intent

Component name

可选项，如果没有组件名称，则 Intent 为隐式，如需在应用中启动特定的组件，则应指定该组件的名称。可以使用 setComponent(), setClass(), setClassName() 或 Intent 构造函数设置组件名称。

Action

可以指定自己的 action。以下是一些用于启动 Activity 的常见操作：

1. ACTION_VIEW: 拥有一些可向用户显示的信息(查看照片 或 观看视频等)。
2. ACTION_SEND：拥有一些用户可通过其他应用(例如电子邮件应用 或 社交共享应用)共享的数据。

可以使用 setAction() 或 Intent 构造函数为 Intent 指定操作。

Data

指定数据 MIME 类型的 URI，提供的数据类型通常由 Intent 的 Action 决定，例如如果操作是 ACTION_EDIT 则数据应包含待编辑文档的 URI。

可以使用 setData() 设置数据 URI；可以使用 setType() 设置 MIME 类型；可以使用 setDataAndType() 同时显式设置二者。注意：若要同时设置 URI 和 MIME 类型，请勿调用 setData() 和 setType()，因为它们会互相抵消彼此的值。

Category

一个包含应处理 Intent 组件类型的附加信息的字符串。可以将任意数量的Category放入一个 Intent 中，但大多数 Intent 均不需要 Category。以下是一些常见category：

• CATEGORY_BROWSABLE：目标 Activity 允许本身通过网络浏览器启动，以显示链接引用的数据，如图像或电子邮件。
• CATEGORY_LAUNCHER：该 Activity 是任务的初始 Activity，在系统的应用启动器中列出。
• CATEGORY_HOME：桌面应用需要声明。
• CATEGORY_DEFAULT：通过隐式启动Activity时，Android会默认加上一个CATEGORY_DEFAULT，所以如果Activity要支持隐式启动的话，除了默认LaunchActivity，其余都需要加上CATEGORY_DEFAULT。

可以使用 addCategory() 指定 category。

Extras

携带完成请求操作所需的附加信息的键值对，可以使用各种 putExtra() 方法添加 extra 数据。

Flags

可以使用 setFlags() 方法添加Flags。

接收隐式 Intent

应用组件应当为自身可执行的每个独特作业声明单独的filter。例如，图像库应用中的一个 Activity 可能会有两个filter，分别用于查看图像和编辑图像。

在 <intent-filter> 内部可以使用以下三个元素中的一个或多个指定要接受的 Intent 类型：

• <action>：在 name 属性中，声明接受的 Intent 操作。
• <data>：使用一个或多个指定数据 URI（scheme、host、port、path）各个方面和 MIME 类型的属性，声明接受的数据类型。
• <category>：在 name 属性中，声明接受的 Intent category。

请注意：要接收隐式 Intent，必须将 CATEGORY_DEFAULT category 包括在 Intent-filter中。方法 startActivity() 和 startActivityForResult() 将按照其声明 CATEGORY_DEFAULT category的方式处理所有 Intent。如果未在 Intent-filter中声明此category，则隐式 Intent 不会解析为您的 Activity。

可以创建一个包括多个 <action>、<data> 或 <category> 实例的filter，创建时，需确定组件能够处理这些filter元素的任何及所有组合。系统通过将 Intent 与所有这三个元素进行比较，根据filter测试隐式 Intent。隐式 Intent 若要传递给组件，必须通过所有这三项测试。

Intent 解析

当收到隐式 Intent 以启动 Activity 时，系统会根据以下三个方面将该 Intent 与 Intent-filter进行比较，搜索该 Intent 的最佳 Activity：

• Action
• Data（URI 和数据类型）。
• Category

Action测试

要指定接受的 Intent action，Intent-filter既可以不声明任何 <action> 元素，也可以声明多个此类元素。要通过此filter，Intent 中指定的action必须与filter中列出的某一action匹配。

Category测试

要指定接受的 Intent category，Intent-filter既可以不声明任何 <category> 元素，也可以声明多个此类元素。要使 Intent 通过category测试，则 Intent 中的每个category均必须与filter中的category匹配。Intent-filter声明的category可以超出 Intent 中指定的数量，因此不含category的 Intent 应当始终会通过此测试，无论filter中声明何种category均是如此。

请注意：Android 会自动将 CATEGORY_DEFAULT category应用于传递给 startActivity() 和 startActivityForResult() 的所有隐式 Intent。如需 Activity 接收隐式 Intent，则必须将 “android.intent.category.DEFAULT” 的category包括在其 Intent-filter中。

Data测试

要指定接受的 Intent 数据，Intent-filter既可以不声明任何 <data> 元素，也可以声明多个此类元素，如下例所示：

1
2
3
4
5

<intent-filter>
    <data android:mimeType="video/mpeg" android:scheme="http" ... />
    <data android:mimeType="audio/mpeg" android:scheme="http" ... />
    ...
</intent-filter>

每个 <data> 元素均可指定 URI 结构和数据类型（MIME 媒体类型）。URI 的每个部分都是一个单独的属性：scheme、host、port 和 path：<scheme>://<host>:<port>/<path>

在 <data> 元素中，上述每个属性均为可选，但存在线性依赖关系：

• 如果未指定scheme，则会忽略host。
• 如果未指定host，则会忽略port。
• 如果未指定scheme和host，则会忽略path。

将 Intent 中的 URI 与filter中的 URI 规范进行比较时，它仅与filter中包含的部分 URI 进行比较。例如：

• 如果filter仅指定scheme，则具有该scheme的所有 URI 均与该filter匹配。
• 如果filter指定scheme和host，但未指定path，则具有相同scheme和host的所有 URI 都会通过filter，无论其path如何均是如此。
• 如果filter指定scheme、host和path，则仅具有相同scheme、host和path的 URI 才会通过filter。

请注意：path规范可以包含星号通配符 (*)，因此仅需部分匹配路径名即可。

数据测试会将 Intent 中的 URI 和 MIME 类型与filter中指定的 URI 和 MIME 类型进行比较。规则如下：

• 仅当filter未指定任何 URI 或 MIME 类型时，不含 URI 和 MIME 类型的 Intent 才会通过测试。
• 对于包含 URI 但不含 MIME 类型（既未显式声明，也无法通过 URI 推断得出）的 Intent，仅当其 URI 与filter的 URI 格式匹配、且filter同样未指定 MIME 类型时，才会通过测试。
• 仅当filter列出相同的 MIME 类型且未指定 URI 格式时，包含 MIME 类型但不含 URI 的 Intent 才会通过测试。
• 仅当 MIME 类型与filter中列出的类型匹配时，同时包含 URI 类型和 MIME 类型（通过显式声明，或可以通过 URI 推断得出）的 Intent 才会通过测试的 MIME 类型部分。如果 Intent 的 URI 与filter中的 URI 匹配，或者如果 Intent 具有 content: 或 file: URI 且filter未指定 URI，则 Intent 会通过测试的 URI 部分。换言之，如果filter只是列出 MIME 类型，则假定组件支持 content: 和 file: 数据。

请注意：如果 Intent 指定 URI 或 MIME 类型，则数据测试会在 <intent-filter> 中没有 <data> 元素时失败。

最后一条规则反映出对组件能够从文件中或内容提供程序处获得本地数据的预期。因此，其filter只能列出数据类型，不需要显式命名 content: 和 file: scheme。以下是一个典型示例，说明 <data> 元素向 Android 指出，组件可从内容提供程序处获得并显示图像数据：

1
2
3
4

<intent-filter>
    <data android:mimeType="image/*" />
    ...
</intent-filter>

由于大部分可用数据均由内容提供程序分发，因此指定数据类型（而非 URI）的filter也许最为常见。

另一常见的配置是具有scheme和数据类型的filter。例如，下文中的 <data> 元素向 Android 指出，组件可从网络中检索视频数据以执行操作：

1
2
3
4

<intent-filter>
    <data android:scheme="http" android:mimeType="video/*" />
    ...
</intent-filter>

View动画（补间动画）

常用命令

多条命令执行结果不输出到终端

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 使用;分隔的多条命令执行结果之间互不干扰
$ ls;lls;ls
Downloads  termux-packages
zsh: command not found: lls
Downloads  termux-packages

# 使用&&分割的多条命令后一条会在前一条命令执行成功后才执行
$ ls&&lls&&ls
Downloads  termux-packages
zsh: command not found: lls

# 使用cmd > /dev/null 2>&1将输出重定向到null，即不输出到终端
# 使用if [ $? -ne 0 ]; then echo 1; else echo 0;fi;可以得到上一条命令的执行结果（$?表示上一条命令的执行结果）
$ ls > /dev/null 2>&1;if [ $? -ne 0 ]; then echo 1; else echo 0;fi;
0

# 使用{}包裹起来的多条命令
$ {ls&&ls&&ls} > /dev/null 2>&1;if [ $? -ne 0 ]; then echo 1; else echo 0;fi;
0

# echo指定-e参数可开启转移，添加/c可不换行输出
$ echo -e "please input a value:\c";

后台运行

当用户注销（logout）或者网络断开时，终端会收到 HUP（hangup）信号从而关闭其所有子进程。因此，解决办法有两种途径：

• 让进程忽略 HUP 信号；
• 让进程运行在新的会话里从而成为不属于此终端的子进程。

nohup

nohup 的用途就是让提交的命令忽略 hangup 信号，一般我们可在结尾加上”&”来将命令同时放入后台运行，也可用”>filename 2>&1”来更改缺省的重定向文件名。

1
2
3
4
5
6

$ nohup ping www.baidu.com &
[1] 3059
nohup: appending output to 'nohup.out'
$ ps -ef |grep 3059
root      3059   984  0 21:06 pts/3    00:00:00 ping www.baidu.com
root      3067   984  0 21:06 pts/3    00:00:00 grep 3059

setsid

换个角度思考，如果我们的进程不属于接受 HUP 信号的终端的子进程，那么自然也就不会受到 HUP 信号的影响了。setsid 就能做到这一点。

1
2
3
4

$ setsid ping www.baidu.com
$ ps -ef |grep www.baidu.com
root     31094     1  0 07:28 ?        00:00:00 ping www.baidu.com
root     31102 29217  0 07:29 pts/4    00:00:00 grep www.baidu.com

进程 ID(PID)为31094，而它的父 ID（PPID）为1（即为 init 进程 ID），并不是当前终端的进程 ID。

&

将一个或多个命名包含在()中就能让这些命令在子 shell 中运行中，从而扩展出很多有趣的功能。

当我们将&也放入()内之后，就会发现所提交的作业并不在作业列表中，也就是说，是无法通过jobs来查看的。

1
2
3
4

$ (ping www.baidu.com &)
$ ps -ef |grep www.baidu.com
root     16270     1  0 14:13 pts/4    00:00:00 ping www.baidu.com
root     16278 15362  0 14:13 pts/4    00:00:00 grep www.baidu.com

从上例中可以看出，新提交的进程的父 ID（PPID）为1（init 进程的 PID），并不是当前终端的进程 ID。因此并不属于当前终端的子进程，从而也就不会受到当前终端的 HUP 信号的影响了。

查看进程

概述

• VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存），一个进程总共可访问的地址空间。其大小还包括了可能不在RAM中的内存（比如虽然malloc分配了空间，但尚未写入）。 VSS 很少被用于判断一个进程的真实内存使用量。
• RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存），一个进程在RAM中真实存储的总内存。但是RSS还是可能会造成误导，因为它仅仅表示该进程所使用的所有共享库的大小，它不管有多少个进程使用该共享库，该共享库仅被加载到内存一次。所以RSS并不能准确反映单进程的内存占用情况。
• PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存），按比例表示使用的共享库， 例如：如果有三个进程都使用了一个共享库，共占用了30页内存。那么PSS将认为每个进程分别占用该共享库10页的大小。 PSS是非常有用的数据，因为系统中所有进程的PSS都相加的话，就刚好反映了系统中的总共占用的内存。 而当一个进程被销毁之后， 其占用的共享库那部分比例的PSS，将会再次按比例分配给余下使用该库的进程。这样PSS可能会造成一点的误导，因为当一个进程被销毁后，PSS不能准确地表示返回给全局系统的内存（the memory returned to the overall system）。
• USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存），一个进程所占用的私有内存。即该进程独占的内存。 USS是非常非常有用的数据，因为它反映了运行一个特定进程真实的边际成本（增量成本）。当一个进程被销毁后，USS是真实返回给系统的内存。当进程中存在一个可疑的内存泄露时，USS是最佳观察数据。

一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS

free

1
2
3
4

$ free -h
       total       used        free      shared  buff/cache   available
Mem:   7.9G        6.6G        1.0G         17M        223M        1.1G
Swap:  19G         566M         19G