笨马

Android Activity Task launch mode

Wed, 09 May 2018 15:52:00 +0000

Android Activity Task launch mode

基本上，task / task stack / back stack / 任务栈 / 回退栈说的是一回事。

进程

在默认情况下，一个应用程序的所有组件运行在同一个进程中。

在 manifest 中用 process 属性指定组件所运行的进程的名字，同一个应用程序的不同组件可以运行在不同的进程中。

Task stack

https://github.com/aosp-mirror/platform_frameworks_base/blob/master/services/core/java/com/android/server/am/ActivityStack.java

参考：Android ActivityStack 那片文章

在 Activity 中可以用 getTaskId() 获取当前 Activity 所在的 task 的 ID

Task 就是用户为了完成某个功能而执行的一系列 Activity 序列。栈结构，栈顶的 Activity 就是屏幕正在展示的 Activity

Task 中的 Activity 不一定属于同一个应用，Activity 可能会多次实例化（即使 Activity 来自不同的 Task）

当用户启动应用时，该应用的 Task 将出现在前台。如果应用不存在 Task（应用最近未曾使用），则会创建一个新 Task，并且该应用的主Activity 加入这个栈中。

启动一个 Activity 会把这个 Activity 加入栈顶，之前的栈顶 Activity 会保存状态。用户按 返回 键会把栈顶的 Activity 出栈并 destroy，之前的栈顶 Activity 会恢复状态。

当用户开始新任务（比如点击主页键转到主屏幕），整个栈移动到后台。栈中的所有 Activity 全部停止。

当系统资源紧张时，可能将非栈顶 Activity 销毁，在非栈顶 Activity 又变成栈顶 Activity 时重建。此时需要 onSaveInstanceState() 保存状态，以便在重建时恢复状态

默认情况下，如果一个应用在后台呆的太久，系统就会对该应用的 Task 进行清理，除了根 Activity，其他 Activity 都会被清理出栈。

taskAffinity

taskAffinity 可以简单理解成 Task 的名称。默认的 taskAffinity 是包名。可以给 Activity 设置不同的 taskAffinity。

Activity 的 taskAffinity 可以设置成一个空字符串，表明这个 Activity 不属于任何 Task。

不同的 APP 的 Activity 也可以有相同的 taskAffinity。他们会进入同一个 Task 中，尽管这些 Activity 不在一个应用进程中。

launch mode

launch mode 定义 Activity 的新实例与当前 Task 如何关联

可以在 manifest 中定义，也可以在 startActivity 的 Intent 中定义

standard （默认）

不管 Task 里有没有，都创建一个新的 Activity 放在栈顶，谁启动的这个 Activity，这个 Activity 实例就在谁的 Task 中。一个 Task 可以拥有同一个 Activity 的多个实例。

当非 Activity 的 Context 以 standard 去启动一个 Activity 时，会报错，因为非 Activity 的 Context 没有 Task 。如果想让非 Activity 的 Context 去启动 Activity ，需要让 Activity 设置一个 FLAG_ACTIVITY_NEW_TASK 标记，这样就会创建一个新 Task ，此时这个 Activity 的 launch mode 实际上是 singleTask 。

singleTop

如果要启动的 Activity 正好在堆栈顶部，那就直接用它，而不去创建新的实例（会调用 onNewIntent ，而 onCreate 和 onStart 不会被调用），如果没在栈顶，则行为与 standard 一样。

singleTask

此 Acticity 的实例只有一个，只能存在于指定的 Task 中。

如果没有相同 taskAffinity 的 Task ，就创建这个 taskAffinity 的新的 Task ，并创建 Activity 实例，加入这个新栈的栈顶。

如果有相同 taskAffinity 的 Task ，没有 Activity 实例，则新建实例，加入这个栈的栈顶。

如果有相同 taskAffinity 的 Task ，并且其中已经存在相应的 Activity 实例，会把位于这个 Activity 实例上面的 Activity 全部结束掉，让这个 Activity 实例位于栈顶。并调用 onNewIntent ，而 onCreate 不会被调用。有FLAG_ACTIVITY_CLEAR_TOP的效果。

singleInstance

这个 Activity 在整个系统中只会存在于一个它专有的 Task ，这个 Task 里只有这一个 Activity 实例。只要存在这个栈，就存在 Activity 实例，反之亦然。它的意义是只存在一个实例，单独放在一个 Task 栈里给别的 Task 栈共享

启动这个 Activity 时，如果系统不存在这个 Task ，则创建一个栈，并创建这个 Activity 实例加入栈中。

如果存在这个 Task ，则直接跳转到这个栈中，调用栈里这个 Activity 实例的 onNewIntent 。

被这个 singleInstance 的 Activity 启动的任何 Activity 都会运行在其他 Task 中，被启动的 Activity 在启动时，行为与 singleTask 模式一样。

onActivityResult 将会失去作用，它的 resultCode 会直接返回 Activity.RESULT_CANCELED。

allowTaskReparenting

如果 allowTaskReparenting 设置为 true，现在这个 Activity 的实例已经存在于一个 Task T1 中，此时，如果另一个 Task T2 启动，并且 T2 的 taskAffinity 跟这个 Activity 的值相同，那么这个 Activity 实例会从 T1 移动到 T2 中。

如果这个属性没有设置，那么其对应的元素的 allowTaskReparenting 属性值就会应用到这个 Activity 上。它的默认值是false。

应用场景：短信应用里，短信详情 Activity 中，用户点击了一个网页地址超链接，就会启动浏览器应用的网页浏览 Activity 。此时的 Task T1 是短信详情 Activity - 网页浏览 Activity 。如果这个网页浏览 Activity 的 allowTaskReparenting 设置为 true。在用户回到主屏幕然后再次启动浏览器应用时，会将 T1 中的网页浏览 Activity 转移到当前新的 Task 中并打开。

alwaysRetainTaskState

默认情况下，如果一个应用在后台呆的太久，系统就会对该应用的 Task 进行清理，除了根 Activity，其他 Activity 都会被清理出栈，但是如果在根 Activity 中设置了 alwaysRetainTaskState 为 true 之后，就不会清理。用户再次打开时，仍然可以看到上一次操作的界面。这个根 Activity 的 launchMode 如果是 singleTask 或者 singleInstance 会导致无效。

应用场景：浏览器打开了很多标签页，每次打开浏览器都保存了这些标签页的打开状态。

clearTaskOnLaunch

当应用进入后台后，然后用户再次打开时。如果根 Activity 的 clearTaskOnLaunch 为 true，则 Task 中除了根 Activity 之外所有的 Activity 都会被清理出栈。（被清理出栈的 Activity 中如果有 allowTaskReparenting 设置了 true 的，会被转移到 taskAffinity 相同的 Task 中）

finishOnTaskLaunch

** 理论上 ** 当应用进入后台后，然后用户再次打开时。如果 Task 中某个 Activity 的 finishOnTaskLaunch 为 true，则把这个 Activity 从 Task 中清理出栈。

参考

官方文档中任务和返回栈，其中 singleTask 部分讲的一泡稀。

https://developer.android.com/guide/components/tasks-and-back-stack

https://blog.csdn.net/luoshengyang/article/details/6714543

Java 中的 Enum 枚举

Mon, 07 May 2018 15:40:00 +0000

Java 中的 Enum 枚举

一个典型的使用：

enum Day {
    MONDAY, TUESDAY, WEDNESDAY,
    THURSDAY, FRIDAY, SATURDAY, SUNDAY
}

使用关键字 enum 创建枚举（Day）在编译后本质上也是一个类，该类继承自java.lang.Enum

每一个枚举项（MONDAY, TUESDAY…），都会 new 一个 Day 类型的实例。并且是 public static final 的。

所以 Enum 类型所使用的内存，肯定是比一个静态 int 常量多，所以在 Android 开发中建议直接使用 @XXXDef 注解

方法

ordinal() 方法，该方法获取的是枚举变量在枚举类中声明的顺序。从 0 开始。

compareTo(E o) Enum实现了Comparable接口。比较枚举的大小，内部实现是根据每个枚举的ordinal值大小进行比较的。

name() 与toString()几乎是等同的，都是输出变量的字符串形式。

valueOf(Class<T> enumType, String name) 方法则是根据枚举类的 Class 对象和枚举名称获取枚举常量，注意该方法是静态的

valueOf(String name) 方法最终还是会调用 Enum 类的 valueOf(Class<T> enumType, String name)

values() 方法的作用就是获取枚举类中的所有变量，并作为数组返回

values()方法和valueOf(String name)方法是编译器生成的 static 方法，注意这里有两个 valueOf 方法

几个特性

enum 可以实现接口

两个枚举常量可以用 ==比较

可用于控制 switch 语句

添加方法与自定义构造函数

public enum Day {
    MONDAY("星期一"),
    TUESDAY("星期二"),
    WEDNESDAY("星期三"),
    THURSDAY("星期四"),
    FRIDAY("星期五"),
    SATURDAY("星期六"),
    SUNDAY("星期日");  // 注意这里这个分号

    private String desc; 

    private Day(String desc){
        this.desc=desc;
    }

    public String getDesc(){
        return desc;
    }

    public static void main(String[] args){
        for (Day day:Day.values()) {
            System.out.println("name:"+day.name()+ ",desc:"+day.getDesc());
        }
    }
}

抽象方法

enum 类的实例可以有类似多态的特性，但是也只是实例，不能作为方法的参数的类型。

public enum Direction {
    LEFT{
        @Override
        public String getInfo() {
            return "LEFT";
        }
    },
    RIGHT{
        @Override
        public String getInfo() {
            return "RIGHT";
        }
    }
    ;

    public abstract String getInfo();

    public static void main(String[] args){
        System.out.println("1:"+Direction.LEFT.getInfo());
        System.out.println("2:"+Direction.RIGHT.getInfo());
    }
}

HashMap

Mon, 07 May 2018 15:40:00 +0000

HashMap

哈希表 / 散列表

哈希表可以理解为数组的扩展或者关联数组，数组使用数字下标来寻址，如果关键字的范围较小且是数字的话，可以直接使用数组来完成哈希表，但是空间利用率极低。同时键也可能不是数字，所以人们使用一种映射函数(哈希函数)来将关键字映射到特定的域中。

键(key) 又称为关键字。唯一的标示要存储的数据，可以是数据本身或者数据的一部分。
槽(slot/bucket) 哈希表中用于保存数据的一个单元，也就是数据真正存放的容器。
哈希函数(hash function)：将键(key)映射(map)到数据应该存放的槽(slot)所在位置的函数。
哈希冲突(hash collision)：哈希函数将两个不同的键映射到同一个索引的情况。

与其他数据结构比较：

数组：寻址容易，插入和删除困难
链表：寻址困难，插入和删除容易
与二叉树不同，哈希表中存储的数据是无序的，对于查找任意数据高效。二叉树查找某一范围的一些数据比较高效。

理想情况下，哈希表的插入和查找操作的时间复杂度均为O(1)，任何一个数据项可以在一个与哈希表长度无关的时间内计算出一个哈希值，然后在常量时间内定位到一个桶。

可以通过使用不同的哈希函数和冲突解决方案在时间和空间性能上做取舍。

使用哈希表的插入主要有如下两个步骤：

使用哈希函数将被查找的键转换为数组的索引。这个过程是将长度不同的字符串映射为固定长度的整数值。根据键的类型和哈希表的大小选择不同的哈希函数。
处理哈希冲突。因为键是所有任意长度的字符串，数量是无穷的，而哈希值长度固定的常数，数量是有限的，同时根据生日悖论，必然有不同的键映射到同一个哈希值，这就产生了哈希冲突。

处理哈希冲突，通常有两类方法：

Open Hashing 比如拉链法，是哈希桶（Bucket Hashing）的一种。碰到哈希冲突后，用链表去延展。所以有链表带来的优缺点。（因为开辟了新空间，所以叫 Open Hashing）。
Closed Hashing 比如线性探测法。哈希冲突后，并不会在本身之外开拓新的空间，而是继续顺延下去某个位置来存放，（因为依旧在同一个密闭的空间，所以叫 Closed Hashing），至于 Open Addressing 的意思是，相对于那种通过链表来开拓新空间，它是在本身地址上，另外找个位置。所以叫开地址。常用的开地址法有探测（Probing），某些哈希桶（Bucket Hashing）等。

HashMap

Java 的 HashMap 也是一个哈希表。先分配（allocate）一定的内存位置，然后向这些位置插入数据。使用 Open Hashing 拉链法解决哈希冲突。

储存位置的确定：把 key 经过 hash 之后得到的值，取余（真正的实现是使用的位操作），得到一个在长度范围内的下标。

HashMap 非线程安全，需要线程安全的话，使用 ConcurrentHashMap 。 LinkedHashMap 是 HashMap的一个子类，是带插入顺序的 HashMap。

构造方法：

// 构造一个具有默认初始容量 (16) 和默认加载因子 (0.75) 的空 HashMap
HashMap()
// 构造一个带指定初始容量和默认负载因子 (0.75) 的空 HashMap
HashMap(int initialCapacity)
// 构造一个带指定初始容量和加载因子的空 HashMap
HashMap(int initialCapacity, float loadFactor) 

底层实现是数组，数组的每一项都是一条链表（Entry<K,V>中的 next ）（ UPDATE：Java8 中使用链表+红黑树）。其中参数 initialCapacity 就代表了该数组的长度。（实际 capacity 是 initialCapacity 向上取最接近的一个「2的幂的数」）容量表示哈希表中桶的数量，初始容量是创建哈希表时的容量，

负载因子是哈希表在扩容前可以达到多满的一种尺度（threshold = (int)(capacity * loadFactor);），它衡量的是一个哈希表的空间的使用程度，负载因子越大表示哈希表的装填程度越高，反之愈小。

对于使用链表法的哈希表来说，查找一个元素的平均时间是O(1+a)，因此如果负载因子越大，对空间的利用更充分，元素多了，哈希冲突的可能性变大，链表变长，后果是查找效率的降低；如果负载因子太小，那么链表的数据少，对空间造成严重浪费。

系统默认负载因子为 0.75，一般情况下我们是无需修改的。

插入 `put`

先 hash 元素的 key 计算 hash() ，再根据数组长度取余 indexFor(hash, table.length)，得到数组下标，

然后通过数组下标得到链表的第一个元素Entry<K, V>，同时开始通过 next 进行迭代。

判断每个Entry<K, V>的 hash 值（注意不是 key 的 hash 值）是否与当前要插入的这个元素 hash 值一样，如果一样，则覆盖，并返回旧值。

迭代完后如果还没有返回，则说明是新元素，那么把该元素插队存在链头。

扩容 `resize`

当达到负载因子设定的数量后，会创建新的数组代替已有数组。新数据长度是旧数组的 2 倍。resize(2 * table.length);

这个过程需要将所有元素重新 hash 计算，插入新的数组中，开销较大。（实际的实现中有优化）

取值 `get`

先 hash 元素的 key 计算 hash() ，再根据数组长度取余 indexFor(hash, table.length)，得到数组下标，

然后通过数组下标得到链表的第一个元素Entry<K, V>，同时开始通过 next 进行迭代。

判断每个 Entry<K, V> 的 key 是否与当前要获取的这个元素 key 一样，如果一样，则返回这个Entry<K, V>。

ArrayMap

Andoid 提供的 ArrayMap 的特性是减少内存使用。牺牲一些插入和删除的性能。比 HashMap 占用的内存少很多。比较适合 1000 以内的元素个数使用。

ArrayMap 内部使用两个数组。一个记录 key hash 后的顺序列表，另一个按照 key 的顺序记录 key-value 值。

SparseArray

Andoid 提供的这些稀疏数组，因为指定了数据类型，所以没有 HashMap 那样的自动装箱过程。

Android 内存泄漏

Mon, 07 May 2018 15:40:00 +0000

Android 内存泄漏

形成的原因

内存分配：

静态存储区：主要存放 static 数据、全局 static 数据和常量。这块内存在程序编译时就已经分配好，并且在程序整个运行期间都存在。

栈：局部变量的基本数据类型和引用存储于栈中。当方法被执行时，方法体内的局部变量都在栈上创建，生命周期随方法而结束。因为栈内存的分配效率很高，但是分配的内存容量有限。

堆：通常是在程序运行时 new 出来的内存。类成员变量全部存储在堆中（包括基本数据类型，引用和引用的对象实体）。这部分内存在不使用时将会由 GC 来负责回收。

虚拟机的垃圾处理机制：

没有直接或者间接被 GC Roots（通常是线程的 main）引用的对象，会被 GC 回收掉。Java 内存泄漏指的是进程中某些对象（垃圾对象）已经没有使用价值了，但是它们却直接或间接被 gc roots 引用导致无法被 GC 回收。

所以，生命周期不同的对象是重灾区。

常见情况和避免方式

持有A实例的B的生命周期超过了 A实例的生命周期，导致A实例无法回收。

导致生命周期不一致的原因：静态，线程的异步，作用范围（比如用作缓存的集合数据类型，引用着里面保存的图片）等

静态实例所在的类

这个静态实例的类如果不是静态的，那么这个静态实例所在的类将无法回收非静态的内部类，包括匿名内部类某些单例模式

public class Demo {
    static Inner sInnerInstance = null;

    public Demo() {
        if (sInnerInstance == null) {
            sInnerInstance= new Demo();
        }
    }

    class Inner {
        void doSomething() {
            System.out.print("dosh");
        }
    }
}

非静态内部类默认会持有外部类的引用。

Demo 的构造方法创建了一个该非静态内部类的静态实例，该实例的生命周期和应用的一样长，该静态实例一直会持有 Demo 的引用，导致 Demo 无法正常回收。

解决：

public class OutterClass {

    static class InnerClass {
        private final WeakReference<OutterClass> mOutterClassInstance;
    }
}

集合

集合类如果仅仅有添加元素的代码，而没有相应的删除机制，集合类和这个元素的生命周期不一致（比如集合是当前类的静态属性，全局性的 map 或 final 一直指向它)，会导致内存泄漏。比如通过 HashMap 做缓存时就需要注意。

线程

线程是典型的生命周期不同的情况，需要特别注意。

Android 的常见情况和避免方式

如果泄漏对象越攒越多，没有办法被回收，最终会导致 OutOfMemory，使得 system_process 进程挂掉。

Activity

想要避免 context 相关的内存泄漏，需要注意以下几点：

不要对 activity 的 context 长期引用(一个 activity 的引用的生存周期应该和activity的生命周期相同) 注意 View、 Drawable 等容易持有 Activity 的引用

如果一个 acitivity 的非静态内部类的生命周期不受控制，那么避免使用它；正确的方法是使用一个静态的内部类，并且对它的外部类有一 WeakReference，就像在 ViewRootImpl 中内部类 W 所做的那样。

持有 activity 的线程对象 mThread，确保 activity 在 destroy 后，线程已经终止，可以这样做：在 onDestroy 时调用 mThread.join();

针对整个应用生命周期的情况使用关于 application 的 context 来替代和 activity 相关的 context

View 会保持 Activity 的引用，Activity 同时还和其他内部对象也有可能保持引用关系。

一般通过不断改变屏幕方向，使 Activity 不断重建，可以直观的观察泄漏。

Handler

Handler 通过发送 Message 与其他线程交互，Message 发出之后是存储在目标线程的 MessageQueue 中的，Message 并不保证马上被处理，可能会驻留比较久的时间。在 Message 类中的成员变量 target，它强引用了 handler 实例，如果 Message 在 Queue 中一直存在，就会导致handler 实例无法被回收，如果 handler 对应的类是非静态内部类，则会导致外部类实例（ Activity 或者 Service ）不会被回收，这就造成了外部类实例的泄露。

正确处理 Handler 等之类的内部类，应该将自己的 Handler 定义为静态内部类，并且在类中增加一个成员变量，用来弱引用外部类实例。在 Activity 的 Destroy 或者 Stop 时使用 removeCallbacks 移除消息队列 MessageQueue 中的消息。

使用 HandlerThread 时，因为 HandlerThread 的 run 方法是一个无限循环，它不会自己结束，线程的生命周期超过了 activity 生命周期。应该在 onDestroy 时将线程停止掉：mThread.getLooper().quit();

广播接收器、注册观察者、系统事件的监听器

假设我们希望在锁屏界面（LockScreen）中，监听系统中的信号强度，则可以在 LockScreen 中定义一个 PhoneStateListener 的对象，同时将它注册到 TelephonyManager 服务中。

对于 LockScreen 对象，当需要显示锁屏界面的时候就会创建一个 LockScreen 对象，而当锁屏界面消失的时候 LockScreen 对象就会被释放掉。

但是如果在释放 LockScreen 对象的时候，没有取消之前注册的 PhoneStateListener 对象，则会导致LockScreen 无法被 GC 回收。内存泄了漏了。

虽然有些系统程序，它本身好像是可以自动取消注册的，但还是最好明确的手动取消注册。

资源源对象 File / Cursor

资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，并置为 null。以便它们的缓冲及时回收内存。

它们的缓冲不仅存在于 Java 虚拟机内（GC 可以回收），还存在于 Java 虚拟机外（一些缓存逻辑，需要手动关闭）。如果我们仅仅是把它的引用设置为 null，而不关闭它们，往往会造成内存泄露。

有些资源性对象，比如 SQLiteCursor（在析构函数finalize()如果我们没有关闭它，它自己会调close()关闭)，所以就算没有手动关闭，系统在会在 GC 时也会关闭它，但是这样的效率太低了。

Android 的调试

神器 LeakCanary https://github.com/square/leakcanary

MAT(Memory Analyzer Tool)

Android Profiler 类似 MAT，可以在 Android studio 中直接操作，可以直接 dump 分析类的数量

正常的操作，在正常gc后，Allocated 的内存会保持在一个平稳的水平。如果 Allocated 值在每次GC后不会有明显的回落，随着操作次数的增多 Allocated 的值会越来越大，说明代码中存在没有释放对象引用的情况。

Android 应用开发性能优化提纲

Mon, 07 May 2018 15:40:00 +0000

「已发布」Android 应用开发性能优化提纲

** 要进行优化，请先确定主要次要瓶颈是什么！ **

【UPDATE】Android Studio 3.2 之后，Android Device Monitor 已经被 Android Studio 内置的功能取代。文中提到的一些工具，做了响应的更新。如果依旧要使用Android Device Monitor，可以在 SDK 目录下 android-sdk/tools/找到monitor

布局和绘制

布局和绘制如果有问题会直接造成 UI 卡顿，甚至 ANR

布局

布局会出现的主要问题是层级过多和布局重叠。以及界面业务逻辑的实现混乱，非必要逻辑，以及重复的 inflate。

避免布局重叠（过度绘制）。使用开发中选项的调试 GPU 过度绘制功能检查

使用 merge 减少层级，include 减少布局内重复内容，viewstub 懒加载，注意 include 可能导致层级增加，最好搭配 merge 达到少增加一个层级的效果。

不使用 AbsoluteLayout，除非 APP 永远只适配一种机型。

避免布局层级过多过于复杂，

~~使用 Hierarchy Viewer 检查试图层级。~~ 如果使用 Android studio 3.1 以上的版本，直接使用自带的 Layout Inspector 工具。

绘制

不要在 UI 线程中做耗时操作，比如绘制操作太多，IO 或者计算负载过重的操作。比如同一时间动画执行的次数过多。

使用开发者选项中的 GPU 呈现模式分析，选择在屏幕上显示为条形图，动态的观察问题出现的时机。还可以使用 GPU Monitor 配合严格模式，会在主线程上做耗时操作时，闪烁屏幕。

控件 measure 的时候避免多次测量，draw 的时候避免过多的计算量或者内存开销，比如大量循环，频繁 new 对象创建内存

UI 资源

尽量使用 xml 定义的图片

使用 dp 作为单位，不使用 px 为单位，除非特殊情况，比如一条分隔线之类的

尽量使用一套资源进行多数的适配

使用 9patch

内存

内存泄漏

参考内存泄漏那篇文章

自动装箱和集合类

自动装箱的过程会 new 一个原始类型对应的对象，这个过程不但使用更多的内存，并且多了 new 的调用。会造成一定的内存浪费。

各种泛型集合中常用到对原始类型自动装箱。

选择合适的集合数据类型和结构。在合适的情况下，使用 SparseArray 替代 HashMap ，可以避免自动装箱行为，使用 ArrayMap 比 HashMap 更节约内存。

Bitmap 使用

及时销毁

虽然，系统能够确认 Bitmap 分配的内存最终会被销毁，但是由于它占用的内存过多，所以很可能会超过Java 堆的限制。因此，在用完 Bitmap 时，要及时的 recycle ，给虚拟机信号：该图片可以释放了。

设置合适的采样率

当要显示的区域很小，没必要将图片原尺寸加载出来，而只需要加载一个缩小过的图片，这时候可以设置一定的采样率，则可以大大减少占用的内存。

private ImageView iv;    
BitmapFactory.Options options = new BitmapFactory.Options();    
options.inSampleSize = 2; //图片宽高都为原来的二分之一，即图片为原来的四分之一    
Bitmap bitmap =BitmapFactory.decodeStream(cr.openInputStream(uri), null, options); iv.setImageBitmap(bitmap);   

设置合适的像素格式

Bitmap.Config 用来描述图片的像素是怎么被存储的： ARGB_8888: 每个像素4字节. 共32位，默认设置。 RGB_565:共16位，2字节，只存储RGB值。 Alpha_8: 只保存透明度，共8位，1字节。 ARGB_4444: 共16位，2字节。

BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.RGB_565;
Bitmap bitmap = BitmapFactory.decodeFile("/foo.png",options);

使用用软引用（SoftRefrence）

有时，在使用 Bitmap 后没有保留对它的引用，因此就无法调用 Recycle 函数。这种情况可以使用软引用，可以使 Bitmap 在内存不足时得到有效的释放。

SoftReference<Bitmap> bitmap_ref = new SoftReference<Bitmap>(BitmapFactory.decodeStream(inputstream));   
if (bitmap_ref .get() != null) {
  bitmap_ref.get().recycle();
}

图片缓存

通常在不同的层级都会设置缓存，比如内存缓存，文件系统缓存。

LRU 算法：设置缓存图片最大数量，当图片数量超过最大值，则删除使用较少的图片，使用次数同样少的就删除更早使用的。

FTU 算法：设置图片的缓存时限，从最后一次使用算起，当达到时限即删除

FMU 算法：设置固定大小的缓存空间，当达到空间限制后删除最大尺寸的图片

其他媒体文件

比如视频，音频，因为处理通常会使用专门的库，需要针对性的考察。

性能优化

全局使用的功能使用单例模式

缓存网络请求，大文件

同步改异步

线程池

网络优化

避免频繁的网络请求，使用线程池管理异步网络请求

图片进行缓存

大文件上传或下载使用断点续传

非 UI 交互数据的请求，尽量集中在一个时刻处理

服务器端减少重定向次数，服务器端 API 响应时间尽量不超过 100ms，CDN 缓存静态资源，APP 客户端自带一份服务器 ip，使用 ip 直连，省去 dns 时间

HTTP 请求添加 http time out

合理使用 HTTP 的 connection 的 keep－alive

使用 HTTP 缓存（ HTTP 头信息中的 Cache－Control 和 expires 确定是否缓存请求结果）

HTTP 开启 gzip 压缩

API 使用数据小的数据形式，如 json

数据库优化

使用索引

返回的结果集字段尽量少

SQL 语句的拼接使用 StringBuilder

execSQL 执行原始 SQL 语句的效率更高，在封装与效率之间选择一个平衡点

一次性修改或插入多个数据，使用 SQLite 事务，适合文件存储的尽量使用文件存储

Java 代码优化

牺牲类型安全和使用方便性，常量使用static final + @XXXDef 注解，非必要情况不使用 Enum。

减少不必要的全局变量

不必使用内部 getter 和 setter

选择合适的 Java 引用方式

某些 Java 对象注意手动回收，比如 XmlPullParserFactory、BitmapFactory、Matcher、各种流的操作和数据库的关闭，不使用的 Bitmap 对象及时 recycle，并且赋值为 null

算法优化，复杂算法用 c 完成使用 jni 调用。

使用 ~~traceview~~ Android Studio 的 CPU profiler 功能来分析调用过程，定位卡顿问题出现的位置。

在主线程上的耗时操作过多会导致 ANR。碰到 ANR 时，系统会在 /data/anr目录下创建一个 traces.txt 文件。取出这个文件adb pull /data/anr/traces.txt，通过分析这个文件来定位 ANR 发生的地方。

业务逻辑优化

减少不必要的业务流程，比如无意义的启动画面，过早请求登录用户的信息等。

参考

一些调试工具：

https://juejin.im/entry/563ae1b560b216575c53c3d6

https://developer.android.google.cn/studio/profile/systrace.html

https://developer.android.google.cn/reference/android/view/FrameMetrics.html

Android TouchEvent 触摸事件传递

Fri, 27 Apr 2018 12:16:00 +0000

Android TouchEvent 触摸事件传递

Activity

事件由 Activity 的 dispatchTouchEvent() 开始，将事件传递给当前 Activity 的根ViewGroup：mDecorView，事件开始自上而下进行传递，直至被消费。

Activity 里 dispatchTouchEvent(MotionEvent ev) 被调用，会调用 getWindow().superDispatchTouchEvent(ev)， PhoneWindow 中的 superDispatchTouchEvent(ev) 调用的是 DecorView 的 superDispatchTouchEvent(event) 再调用的是 super.dispatchTouchEvent(event);DecorView 的父类是 FrameLayout，FrameLayout 没有重写 dispatchTouchEvent 方法，所以事件开始交由 ViewGroup 的 dispatchTouchEvent 开始分发

如果 getWindow().superDispatchTouchEvent(ev) 返回 false，也就意味着整个分发过程没有人消费，则会直接调用 Activity 的 onTouchEvent(ev)

ViewGroup 中的 dispatchTouchEvent

这里的代码分析使用的是 Android 1.6 版本，之后的版本有不少改动，完善了多指触控等功能，但是行为逻辑都是一样的。 https://github.com/aosp-mirror/platform_frameworks_base/blob/donut-release/core/java/android/view/ViewGroup.java

这里调度事件在 View 层级中的传递。

ViewGroup 的 onInterceptTouchEvent 直接返回了 false，即默认是不拦截事件的。这个 onInterceptTouchEvent 是自定义 View 时，是否要在当前 View 对当前一串滑动操作进行处理。通常就写在这里。可以通过 requestDisallowInterceptTouchEvent(boolean disallowIntercept) 设置是否拦截事件。通常处理上下层滑动冲突时，下层 View 想要处理滑动事件，就会根据滑动的情况判断来调用上层 ViewGroup 的 requestDisallowInterceptTouchEvent 来获得当前滑动。如果是上层 ViewGroup 想要处理滑动事件，则是使用 onInterceptTouchEvent 。

这段伪代码就把传递过程解释了大部分，可以多看几眼。

// 1. ACTION_DOWN 时，判断是否有 target
if (action == MotionEvent.ACTION_DOWN) {
    // disallowIntercept 为 true （下层 View 不允许在这里 Intercept）
    //  或者 onInterceptTouchEvent 返回 false 时。（此处调用了onInterceptTouchEvent）
    if (disallowIntercept || !onInterceptTouchEvent(ev)) {
        // 向下层传递。循环下层 View ，找到触摸点**击中**的下层 View 
        for(){
            if (frame.contains(scrolledXInt, scrolledYInt)) {
                // 如果这个下层 View 的 dispatchTouchEvent 返回 true，则把它赋值给 mMotionTarget，同时这个 ViewGroup 中的 dispatchTouchEvent 返回true。（此处调用了下层 View 的dispatchTouchEvent）
                if (child.dispatchTouchEvent(ev)) {
                    mMotionTarget = child;
                    return true;
                }
            }
        }
    }
}
// 2. 如果 mMotionTarget 为空，这里有两种情况，一种是中断，一种是没找到合适的下层 View
// 那么调用  super.dispatchTouchEvent(ev)，也就是 View 的 dispatchTouchEvent(ev)，也就是由 ViewGroup 自身来处理事件。
final View target = mMotionTarget;
if (target == null) {
    return super.dispatchTouchEvent(ev);
} 
// 3. 如果 onInterceptTouchEvent 返回了 true
if (!disallowIntercept && onInterceptTouchEvent(ev)) {
           // 那么给 target 发去一个 CANCEL 的事件。这里调用 target.dispatchTouchEvent(ev) CANCEL 事件。
            ev.setAction(MotionEvent.ACTION_CANCEL);
            if (!target.dispatchTouchEvent(ev)) {
            
            }
            // 当前事件已经改成 CANCEL 发给 target。这里把 target 设置为 null，这个同一串事件的下一个事件开始，在运行到 「2」 时，调用 `return super.dispatchTouchEvent(ev);`
            mMotionTarget = null;
            // 这里返回 true。依旧由这个 ViewGroup 处理事件。
            return true;
}
// 4. 在一串事件的结束时，重置 target
if (isUpOrCancel) {
    mMotionTarget = null;
}
// 5. 将事件转换成 目标 View 的坐标后 ，调用 target.dispatchTouchEvent(ev); 并返回
return target.dispatchTouchEvent(ev);

首先在 ACTION_DOWN 事件时，先 onInterceptTouchEvent ，不中断的话，迭代下层 view 寻找 target 。target 的条件是点击区域在这个 child view 的范围内，同时这个 child 的 dispatchTouchEvent(ev) 返回 true。说明这个下层 View 想要消费这一串事件，则设置这个 child 为 target，注意这里形成了上下层 view 的递归，并且当前 ViewGroup 的 dispatchTouchEvent 返回 true 。事件就经过一层一层的 ViewGroup 返回 true，到达此处。
如果没找到 target，则调用 super.dispatchTouchEvent(ev); 也就是 ViewGroup 自身处理事件。这里有两种情况，一种是此时是 ACTION_DOWN 事件，没找到 target ，一种是此时不是 ACTION_DOWN 事件，之前找到了 target，但是此时是后续的比如 ACTION_MOVE 事件时，之前的 ACTION_MOVE 事件时，中断了。如果这里也返回 false ，只有此时是 ACTION_DOWN 事件，也就是确定 target 时，会起作用。
到这里时，肯定有 target ，则先判断 onInterceptTouchEvent ，中断的话则把当前时间修改成 ACTION_CANCEL事件，把这个取消事件给 target，然后把 target 设置为 null，但是让当前 ViewGroup 的 dispatchTouchEvent 依然返回 true 。这样一来，这一串事件的后续事件再进入当前 dispatchTouchEvent 方法后，在第 2 步，由于 target 是 null，会调用自身的super.dispatchTouchEvent(ev);
到这里时，有 target ，不中断。如果是一个一串事件的结束事件，那么把 target 设置为 null。重置 target。（等待下一次 ACTION_DOWN）
到这里时，有 target ，不中断，不是一串事件的结束，正常向 target 传递事件并返回。return target.dispatchTouchEvent(ev);

View 中的 dispatchTouchEvent

这里决定事件在 View 内部由哪个方法处理。

dispatchTouchEvent(MotionEvent event) 如果有 OnTouchListener ，同时当前 View 处于可用状态(mViewFlags & ENABLED_MASK) == ENABLED的话，就执行 OnTouchListener 的 onTouch，如果mOnTouchListener.onTouch(this, event)==true ，View 的 dispatchTouchEvent 在这里直接返回，返回值是 true。没有 OnTouchListener 的话就执行 onTouchEvent(MotionEvent event)

    public boolean dispatchTouchEvent(MotionEvent event) {
        if (mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED && mOnTouchListener.onTouch(this, event)) {
            return true;
        }
        return onTouchEvent(event);
    }

OnTouchListener 的 onTouch() 用户使用setOnTouchListener设置的。如果它的 onTouch() 返回 true，则 View 本身的onTouchEvent()不会被调用。如果返回 false，则 View 本身的onTouchEvent()会被调用。

所以，OnTouchListener 的 onTouch() 优先级比 View 本身的onTouchEvent() 要高。

而用户通过 setOnClickListener 设置的 OnClickListener 中的 onClick，是在 View 本身的onTouchEvent()中判断执行的，因此，用户设置的 onTouch 事件会优先于 onClick 事件。

onTouchEvent(MotionEvent event)

https://github.com/aosp-mirror/platform_frameworks_base/blob/donut-release/core/java/android/view/View.java#L4097

在 View 类中，会通过 MotionEvent 的事件类型（ ACTION_UP ）和各项条件判断去调用 performClick() 继而调用 mOnClickListener.onClick(this);

View 的 onTouchEvent 默认返回 true。也就是如果事件流到 View 的 onTouchEvent 中，默认会消费这个事件。如果当前View 是不可点击的（ clickable 和 longClickable 都是 false，longClickable 默认是 false，clickable 不同控件的值不同），那么 View 的 onTouchEvent 默认返回 false。

framework 中包含的工具

ViewConfigration 中：

Slop
ScaleSlop

处理触摸事件的相关工具：

GestureDetector
ScaleGestureDetector
VelocityTracker

控制某位置的触摸事件流向：

TouchDelegate

处理滚动的计算：

Scroller

参考

https://github.com/devunwired/custom-touch-examples

Android View 测量布局绘制过程

Fri, 27 Apr 2018 12:02:00 +0000

开始

每个 Activity 会创建一个 PhoneWindow 对象，是 Activity 和整个 View 系统交互的接口。

每个 Window 都通过一个 ViewRootImpl 与一个 VIew 关联，对于 Activity来说，ViewRootImpl 是连接 WindowManager 和 DecorView 的纽带。

绘制的入口是由 ViewRootImpl 的 performTraversals 方法去依次调用 DecorView 的 measure，layout，draw 方法。

在调用 DecorView 的 measure 时，会传入 MeasureSpec 参数。这个参数是由屏幕宽高，和WindowManager.LayoutParams 得来的。

FYI：ViewGroup 是一个抽象类，所以不能直接 new 对象，所以在 xml 布局文件中不能直接使用 ViewGroup。

把大象装冰箱，总共分三步走。

https://github.com/aosp-mirror/platform_frameworks_base/blob/donut-release/core/java/android/view/View.java#L7690

Measure

View 的 measure 主要作用就是调用自己的 onMeasure。它接收 MeasureSpec 类型的参数。另外就是维护一些 View 本身的状态变量。

View 的 measure 是 final，所以 View 的子类（比如 ViewGroup / 自定义控件）是不能 override 这个方法的。所以 ViewGroup 没有实现 measure 方法，也就是说，它使用的是父类 View 的 measure 。

在完成 measure 之后，可以使用 getMeasureWidth() 和 getMeasureHeight() 获得经过 measure 之后的控件尺寸。

onMeasure

onMeasure 的功能是测量自身的尺寸。

测量完成后调用 setMeasuredDimension 保存。

View 类中有一个的 onMeasure 实现。抽象类 ViewGroup 中没有 onMeasure 的实现，所以默认的 onMeasure 也是父类 View 的 onMeasure 。

通常，自定义的 View 和 ViewGroup 都需要根据自身业务逻辑实现自己的 onMeasure。

View.onMeasure

View 类中默认 onMeasure 方法，会测量自身的尺寸，并调用自身的 setMeasuredDimension 保存尺寸。（因为不是 ViewGroup ，所以只测量自身，不涉及下层 View ）

其中调用 getDefaultSize 时，因为 View 本身没有业务逻辑，所以会将 WRAP_CONTENT 的情况像 MATCH_PARENTS 一样填满父控件，所以自定义 View 如果需要支持 WRAP_CONTENT ，需要重写 onMeasure方法。

protected void onMeasure( int widthMeasureSpec, int heightMeasureSpec) {
    setMeasuredDimension( getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
            getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
}

getSuggestedMinimumWidth 功能是计算「内容」尺寸，在没有业务逻辑的 View 类中，计算方法是：根据有没有背景，背景最小尺寸，View 的 minWidth 来获取。

protected int getSuggestedMinimumWidth () {
    return (mBackground == null) ? mMinWidth : max(mMinWidth , mBackground.getMinimumWidth());
}

getDefaultSize ，功能是根据 getSuggestedMinimumWidth 得到的「内容」尺寸，再根据上层 View 对当前 View 的限制 measureSpec，得到最终尺寸。

计算方式是：当前 View 的 MeasureSpec 的 mode 是 UNSPECIFIED 时，使用「内容」尺寸，如果是 AT_MOST 或者 EXACTLY，使用 MeasureSpec 的尺寸（这里因为没有业务逻辑的 View，不区分 AT_MOST 或者 EXACTLY，所以布局中的 View ，设置 wrap_content 并不起作用）。

public static int getDefaultSize (int size, int measureSpec) {
    int result = size;
    int specMode = MeasureSpec. getMode(measureSpec);
    int specSize = MeasureSpec. getSize(measureSpec);
    switch (specMode) {
    case MeasureSpec. UNSPECIFIED:
        result = size;
        break;
    case MeasureSpec. AT_MOST:
    case MeasureSpec. EXACTLY:
        result = specSize;
        break;
    }
    return result;
}

在自定义 View 时，根据当前 View 的「内容」尺寸和上层 View 对当前 View 的限制（MeasureSpec），得到一个符合限制的尺寸这一步。可以使用 View 类的resolveSize()。这个方法的业务逻辑就是正常逻辑。

ViewGroup.onMeasure

ViewGroup 实现类的 onMeasure 的实现方式，基本上，分两大步🚶🚶：遍历下层 View，计算自身。遍历下层 View 也分两大步：计算 MeasureSpec，调用下层 View 的 measure 形成递归。

遍历所有下层 View：遍历到每个下层 View 时，先计算它的 MeasureSpec，（计算可以使用 ViewGroup 的 measureChild 调用 getChildMeasureSpec 方法）

然后把得到的 MeasureSpec 作为参数调用下层 View 的 measure，形成递归。

如果这个下层 View 是 ViewGroup 子类，则继续遍历它的下层 View，如果是个底层 View，则根据这个底层 View 的自身业务逻辑测量尺寸，这里会有几个参数，一个是包含了上层 ViewGroup 尺寸限制的 MeasureSpec，一个是根据自身业务计算得到到「内容」尺寸，选择一个合适的尺寸保存（setMeasuredDimension ）。View 的默认实现是：setMeasuredDimension( getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec), getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));

遍历结束时，或者遍历过程中，随着下层 View 的逐渐测量完毕（当前 ViewGroup 实现类的「内容」尺寸），根据当前 ViewGroup 实现类自身业务逻辑，得出当前 ViewGroup 实现类 自身的尺寸并保存。

一个 View ，margin 的计算，由它上一层的 ViewGroup 负责，padding 的计算，算到「内容」尺寸中。

ViewGroup 提供了几个通用的测量下层 View 相关的方法：getChildMeasureSpec ， measureChild，measureChildWithMargins，measureChildren 。

MeasureSpec

一个从上层视图角度考虑的，对当前 View 的尺寸限制。有两个数据，一个 mode ，一个 size。

整型（32位）将 size 和 mode 打包成一个 int 型，其中高两位是 mode(-1 代表的是EXACTLY，-2 是AT_MOST)，后面 30 位存的 size。

一个 View 的 MeasureSpec 是由上层 View 的 MeasureSpec 加上自身的 LayoutParams 来得到的 mode，由具体业务逻辑（比如当前 ViewGroup 剩余的空间）来得到 size。参考 getChildMeasureSpec 方法。

MeasureSpec.makeMeasureSpec() 制作一个 MeasureSpec 。

MeasureSpec 一共有三种 mode

EXACTLY 当前 View 应直接使用上层 View 给定的限制尺寸
AT_MOST 当前 View 可以是上层 View 给定限制尺寸以内的任意尺寸
UPSPECIFIED 上层 View 对当前 View 没有任何限制，当前 View 可以使用任意尺寸。这种模式一般是 Android 系统内部使用，或者 ListView 和 ScrollView 等滑动控件。

LayoutParams

当前 View 给上层 ViewGroup 提供的布局需求。

在 xml 布局中使用的以 “layout_” 开头的属性都是布局属性。

在View中有一个 mLayoutParams 的变量用来保存这个View的所有布局属性。

ViewGroup 中有两个内部类 LayoutParams 和 MarginLayoutParams，它们只有最基础的功能。

LayoutParams 只有 width / height 两个功能属性。MarginLayoutParams 是 LayoutParams 的子类，是添加了 Margin 相关属性的 LayoutParams。如果需要其他的功能，需要继承 LayoutParams

generateLayoutParams (AttributeSet attrs) 方法作用是将 xml 布局中的 AttributeSet 参数，转化成 LayoutParams。自定义控件时，自定义了 LayoutParams 属性时，需要 override 这几方法。

getChildMeasureSpec

ViewGroup 中的 getChildMeasureSpec：（measureChild 和 measureChildWithMargins 都会调用这个方法）这个方法是按照 child 在这个维度上独享上层 ViewGroup 的逻辑来计算的。如果你的 ViewGroup 并不是这种逻辑，比如一个一个排列的摆放逻辑，那么定义一个变量记录在当前 child 时，上层 ViewGroup 还剩多少尺寸。

// spec：上层 ViewGroup 的 MeasureSpec
// padding：上层 ViewGroup 的 Padding + 当前 View 的 Margin
// childDimension：当前 View 的 LayoutParams 的 lp.width 或者 lp.height（ 可以是wrap_content、match_parent、一个精确值)
public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
    int specMode = MeasureSpec.getMode(spec);
    int specSize = MeasureSpec.getSize(spec);
    int size = Math.max(0, specSize - padding);
    int resultSize = 0;
    int resultMode = 0;
    switch (specMode) {
        case MeasureSpec.EXACTLY:
            if (childDimension >= 0) {
                resultSize = childDimension;
                resultMode = MeasureSpec.EXACTLY;
            }
            else if (childDimension == LayoutParams.MATCH_PARENT) {
                resultSize = size;  
                resultMode = MeasureSpec.EXACTLY; 
            }
            else if (childDimension == LayoutParams.WRAP_CONTENT) {
                resultSize = size;
                resultMode = MeasureSpec.AT_MOST;
            }
            break;
        case MeasureSpec.AT_MOST:
            if (childDimension >= 0) {
                resultSize = childDimension; 
                resultMode = MeasureSpec.EXACTLY;  
            }
            else if (childDimension == LayoutParams.MATCH_PARENT) {
                resultSize = size;  
                resultMode = MeasureSpec.AT_MOST;  
            }
            else if (childDimension == LayoutParams.WRAP_CONTENT) {
                resultSize = size;  
                resultMode = MeasureSpec.AT_MOST;  
            }
            break;
        case MeasureSpec.UNSPECIFIED:
            if (childDimension >= 0) {
                resultSize = childDimension;  
                resultMode = MeasureSpec.EXACTLY; 
            }
            else if (childDimension == LayoutParams.MATCH_PARENT) {
                resultSize = 0;  
                resultMode = MeasureSpec.UNSPECIFIED;  
            }
            else if (childDimension == LayoutParams.WRAP_CONTENT) {
                resultSize = 0;  
                resultMode = MeasureSpec.UNSPECIFIED; 
            }
            break;
    }
    return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}

measureChild / measureChildWithMargins / measureChildren

measureChild 是对 child 的宽高调用 getChildMeasureSpec，然后调用 child.measure。

measureChildWithMargins 与 measureChild 唯一的区别是调用 getChildMeasureSpec 时，第二个参数加上了 child 的 lp.margin。

measureChildren 是遍历当前 ViewGroup 所有 child，并调用 measureChild。

Layout

摆放 View 的位置

与 Measure 过程不同的是，layout 调用时，layout 中先 setFrame 确定当前 View 的位置，再 onLayout 遍历下层 View 并确定位置。

在某些复杂情况下，PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT，在 layout 过程中，会再次进行 onMeasure。

`layout`

layout 确定 View 自身的位置。

View 中的 layout() 的参数 l, t, r, b 分别表示当前 View 相对于上层 View 的左、上、右、下的坐标。这个坐标，通常是在上一步测量当前 View 的尺寸时，上层 View 通常也能得到，保存起来，以便这里使用。

layout() 方法主要功能是：

先调用 setFrame() 设置当前 View 位置，

View 中的 setFrame() 主要功能是：将新旧位置进行对比，只要不完全相同，那么保存新的位置，保存局部渲染可能使用的位置信息。 changed 变量设置为 true，调用 onSizeChanged() 方法。同时如果 View 处于可见状态，那么调用 invalidate 来重新绘制，最后返回 changed 的值。

setFrame() 返回一个 boolean，代表位置是否变化，如果有变化，则调用onLayout() ，此时如果有 LayoutChangeListener，依次调用其 onLayoutChange 方法。

ViewGroup 中的 layout() 主要功能是：处理 ViewGroup 增加和删除下层 View 的 LayoutTransition 动画效果，如果未添加动画，或者动画此刻并未运行，那么调用 super.layout(l, t, r, b)，也就是 View 的 layout，否则等待动画完成时后调用 requestLayout()。

View 中的 layout() 是可以被覆写的。 ViewGroup 中的 layout() 是 final 的，不能被覆写。

在完成 layout 之后，可以使用 getWidth 和 getHeight，获得正常尺寸，这个尺寸是通过计算摆放完的控件坐标得来。getWidth = right - left

`onLayout`

onLayout 调度下层 View 确定位置。

onLayout 的参数跟 layout 的参数一样。 l, t, r, b 分别表示当前 View 相对于上层 View 的左、上、右、下的坐标。

View 不会再有下层 View，所以 View 的 onLayout 是空实现，ViewGroup 中的 onLayout 是抽象方法。所以 onLayout 肯定是有具体的功能的 ViewGroup 子类实现。通常需要做这些事：

根据这个 ViewGroup 子类的摆放逻辑，当前 ViewGroup 剩余空间，onMeasure 过程中得到的下层 View 的相关尺寸，LayoutParams 的 margin，gravity 等，计算出每个下层 View 应处的左上右下位置（可能已经在 onMeasure 时已经一起测量出来，并且保存在某个变量中），最终调用每个下层 View 的 layout()，形成递归。

draw(canvas)

draw 方法主要功能是：按顺序调用当前 View 各个「景深」层面的绘制。

View 中的draw() 方法不是 final 的，可以被覆写。

ViewGroup 没有draw()实现。它使用的是父类 View 的 draw 。

View 中的 draw() 的过程，源码注释已经很清楚了：

/*
  * Draw traversal performs several drawing steps which must be executed
  * in the appropriate order:
  *
  * 1. Draw the background
 skip step 2 & 5 if possible (common case)

  * 2. If necessary, save the canvas' layers to prepare for fading
  * 3. Draw view's content
  * 4. Draw children
  * 5. If necessary, draw the fading edges and restore layers
  * 6. Draw decorations (scrollbars for instance)
  */

主要就是调用了下面几个方法：（对应上面注释的序号）

drawBackground() 背景(不能覆写)
onDraw() 当前 View
dispatchDraw() 下层 View
onDrawForeground() 滑动边缘渐变提示和滚动条，前景。如果覆写，需要 minSdk>=23

不同于 measure 和 layout ，遍历下层 View 这个步骤，不是在 onDraw 中，而是在 draw 中。并且有专门的 dispatchDraw 方法遍历下层 View 。

onDraw

实现当前 View 自身内容的绘制（包括 padding 的处理）。

View 和 ViewGroup 的 onDraw(canvas) 都是空实现。

ViewGroup 的 draw() 默认不会调用 onDraw() 方法。因为正常来说，ViewGroup 是一个 View 容器，自身不会有具体画面。

如果需要回调 onDraw() 方法，在构造函数中调用 setWillNotDraw(false) 即可。（但是，如果你继承的是比如 ScrollView 这种 ViewGroup ，它已经调用过 setWillNotDraw(false) 了）

在 draw() 过程中，某些情况下，比如只是前景状态改变，系统会做相应优化，跳过 onDraw() 。

dispatchDraw

View 的 dispatchDraw() 方法是一个空实现

ViewGroup 的 dispatchDraw() 主要功能就是遍历下层 View，计算下层 View 的 canvas 剪切区（剪切区的大小正是由 layout 过程决定的，位置取决于滚动值以及当前的动画等），并调用它们的 draw(canvas) 方法。

这个实现基本能满足大部分需求，如果需要自定义下层 View 的绘制，则需要覆写这个方法。通常会在这个自定义的方法中，根据自定义的逻辑，在合适的位置调用默认过程 super.dispatchDraw(canvas); ，省时省力。

requestLayout

requestLayout 意味着视图的大小已经改变，整个 View 树将会重新测量，重新布局，可能会重新绘制。

在 requestLayout 方法中，首先先判断当前 View 树是否正在布局流程，接着为当前 View 设置标记位，该标记位的作用就是标记了当前的 View 是需要进行重新布局的，接着调用mParent.requestLayout 方法，向上层 ViewGroup 请求 layout，即调用上层 ViewGroup 的requestLayout 方法，为上层 ViewGroup 添加 PFLAG_FORCE_LAYOUT 标记位，而上层 ViewGroup 又会调用它的上层 ViewGroup 的 requestLayout 方法，形成 requestLayout 事件层层向上传递，直到最上层的 DecorView，而 DecorView 又会传递给 ViewRootImpl，也即是当前 View 的 requestLayout 事件，最终会被 ViewRootImpl 接收并处理。

在 ViewRootImpl 中，重写了requestLayout 方法，我们看看这个方法，ViewRootImpl#requestLayout

@Override
public void requestLayout() {
    if (!mHandlingLayoutInLayoutRequest) {
        checkThread();
        mLayoutRequested = true;
        scheduleTraversals();
    }
}

在这里，调用了scheduleTraversals 方法，这个方法是一个异步方法，最终会调用到ViewRootImpl#performTraversals方法，在这里会调用 measure、layout、draw 这三大流程。

在 measure 时，最开始就会判断一下 PFLAG_FORCE_LAYOUT 标记位，如果有这个标记，那么就会进行测量流程，调用 onMeasure，最后为标记位设置为PFLAG_LAYOUT_REQUIRED，这个标记位的作用就是在 layout 流程中，如果当前 View 设置了该标记位，则会进行布局流程。

有很多控件比如 TextView，做了一些会导致尺寸修改的操作时，例如 setPadding() ， setTypeface() ， setCompoundDrawables()等。在调用 requestLayout() 之后，会再调用 invalidate()

因为 requestLayout 本身不会导致绘制过程，只是有些控件内部已经调用了 invalidate 来响应 layout 更改。

因此，为了确保重新布局会导致重画，那么你应该在 requestLayout 配一个 invalidate。

invalidate

invalidate 请求把 View 重新 draw 一下。重绘不会同步发生。相反，它会将当前 View 区域标记为无效（dirty），以便在下一个渲染周期中重绘。

invalidate() 重绘这个 View，需要注意的是在开启了硬件加速时（API 14之后包括 14，硬件加速默认是开启的），绘制流程会与正常流程有不同，可能会跳过某些流程。

下面分析调用流程：

invalidate 最终都会调用 invalidateInternal 方法，在这个方法内部，进行了一系列的判断，判断当前 View 是否需要重绘，接着为当前 View 设置标记位，并调用上层 ViewGroup 的 invalidateChild 方法，把需要重绘的区域传递给上层 ViewGroup。

在 ViewGroup#invalidateChild 中，先设置当前视图的标记位，接着有一个do…while…循环，该循环的作用是不断向上递归上层 ViewGroup。当父容器不是 ViewRootImpl 的时候，调用的是 ViewGroup 的 invalidateChildInParent 方法，这个方法会返回当前 View 的上层 ViewGroup。

在 ViewGroup#invalidateChildInParent 中，调用 offset 方法，把之前传来的下层 View 的 dirty 区域的坐标转化为当前 ViewGroup 中的坐标，接着调用 union 方法，把下层 View 的 dirty 区域与当前 ViewGroup 区域求并集，也就是 dirty 区域加上了当前 ViewGroup 的。最后返回当前 ViewGroup 的上层 ViewGroup，以便进行下一次循环。

在上面 ViewGroup#invalidateChild 所说的do…while…循环中，由于不断调用上层 ViewGroup 的方法，到最后会调用到 ViewRootImpl 的 invalidateChildInParent 方法，在这里，也进行了 offset 和 union 然后把dirty区域的信息保存在 mDirty 中，最后会调用 scheduleTraversals 方法，在这里会对整个 View 树调用 measure、layout、draw 这三大流程。由于没有添加 measure 和 layout 的标记位，因此 measure、layout 流程不会执行，而是直接从 draw 流程开始。

invadite() 必须在主线程中调用。

postInvalidate() 只有视图被添加到窗口的时候才会继续执行，也就是 attachInfo 不为 null 的时候。内部是由 Handler 的消息机制实现的，所以在任何线程都可以调用，但实时性没有 invadite() 强。一般保险起见，会使用 postInvalidate() 来刷新界面。

Android 库的打包和发布

Thu, 26 Apr 2018 04:07:00 +0000

「已发布」Android 库的打包和发布

一个库项目的构建过程与一般项目是一样的。

如果只需要一个 aar 文件的话，只需要在./gradlew assembleRelease之后，在项目的 build/outputs/aar 目录下就会生成 aar 文件。然后在使用这个库的的项目里添加这个依赖就可以了

repositories {
    flatDir {
        dirs 'libs' //this way we can find the .aar file in libs folder
    }
}

dependencies {
    compile(name:'test', ext:'aar')
}·

如果需要上传到比如 jcenter 这类中央仓库。除了打包，还需要上传到 jcenter 的仓库中。

打包成 maven 仓库支持的格式，需要使用 maven，Android 项目可以通过 gradle 调用 maven，但是 maven 默认并不支持 Android 的库，所以需要使用这个：https://github.com/dcendents/android-maven-gradle-plugin

如果配置好这个插件之后，执行一下 build，就可以在项目的 build 目录下生成 JavaDoc 和 sourceJAR 等文件了。

上传到 jcenter ，可以直接在 bintray 的网站上传上面的到的文件，也可以使用 bintray 自己出的这个插件：https://github.com/bintray/gradle-bintray-plugin

打包上传的 gradle 脚本我放在 github gist 中了：https://gist.github.com/foolhorse/2175dc920e43e4abc27f72e792352fad

使用时，在根项目的 build.gradle 中添加

dependencies {
        classpath 'com.github.dcendents:android-maven-gradle-plugin:2.1'
        classpath 'com.jfrog.bintray.gradle:gradle-bintray-plugin:1.8.0'
    }

在库项目的 build.gradle 中添加

apply from: 'https://gist.githubusercontent.com/foolhorse/2175dc920e43e4abc27f72e792352fad/raw/1bfcb2b0d6fbbbb0169672f5df79f887a95fb3e8/gradle-bintray-push.gradle'

在库项目的目录下的给项目新建一个 gradle.properties ，里面放上各个需要的属性，比如：

# Project
PROJECT_NAME=lightframeview
PROJECT_PACKAGE_NAME=me.machao.lightframeview
PROJECT_DESCRIPTION=LightFrameView is able to provide a light frame animation by wrapping it to a normal View.

PROJECT_VERSION_NAME=1.0.0
PROJECT_VERSION_DESC=

PROJECT_SITE=https://github.com/foolhorse/AndroidLightFrameView
PROJECT_GIT_URL=https://github.com/foolhorse/AndroidLightFrameView.git
PROJECT_ISSUE_URL=https://github.com/foolhorse/AndroidLightFrameView/issues

PROJECT_LICENCE_NAME=Apache-2.0
PROJECT_LICENCE_URL=http://www.apache.org/licenses/LICENSE-2.0.txt

# Developer
DEVELOPER_NAME=machao
DELELOPER_EMAIL=

# POM
POM_SCM_URL=https://github.com/foolhorse/AndroidLightFrameView
POM_SCM_CONNECTION=scm:git:https://github.com/foolhorse/AndroidLightFrameView.git
POM_SCM_DEVELOPER_CONNECTION=scm:git:https://github.com/foolhorse/AndroidLightFrameView.git

# Bintray
BINTRAY_REPO=mavenrepo
BINTRAY_LABELS=android,animation
BINTRAY_VCS_TAG=

敏感信息，比如 bintray 的用户名密码等，放在 local.properties 里。

BINTRAY_USER=your_user_name
BINTRAY_USER_ORG=
BINTRAY_API_KEY=your_api_key
BINTRAY_GPG_PASSPHRASE=

当然，这些属性也可以不用 gradle.properties 的形式，因为gradle.properties 不能很好的支持变量的类型。也可以在 build.gradle 中添加 ext {} 直接写 groovy 代码的变量.

上传

./gradlew install，生成 libs docs poms，生成成功后，可以在项目的build目录下看见。

./gradlew bintrayUpload 上传到 bintray 的 jfrog 上。

进入 jfrog bintray 的这个项目的页面，点击 add to jcenter 申请添加到 jcenger 库中。

设计模式结构篇

Wed, 25 Apr 2018 16:41:00 +0000

「已发布」设计模式结构篇

装饰者、适配器、外观，代理，这几种模式在代码层面很相似，主要的区别在于对应的业务作用的区别。

组合模式 Composite Pattern

Android 里的 View 和 ViewGroup

树形结构以表示”部分-整体”的层次结构( View 可以做为 ViewGroup 的一部分)。

组合模式使得户对单个对象 View 和组合对象 ViewGroup 的使用具有一致性。

适配器模式 Adapter Pattern

也叫 Wrapper 或者 Translator。

国标插座转换成英标插座的电源适配器，这个适配器模式的作用与电源适配器作用完全一样。

业务作用是将一个接口变为另一个接口。

interface MusicPlayer{
    public void play() ;   
}

interface Singer{
    public void sing();
}

class MusicPlayerAdapter implements Singer{

    MusicPlayer musicPlayer

    public MusicPlayerAdapter(MusicPlayer musicPlayer){
        this.musicPlayer = musicPlayer;
    }
    public void singSong(){
        this.musicPlayer.play();
    }
}

public class AdpaterDemo{
    public static void main(String args[]){
        MusicPlayer musicPlayer = new MusicPlayer();
        Singer musicPlayerAdapter = new MusicPlayerAdapter(musicPlayer) ;
        musicPlayerAdapter.sing() ;
    }
}

外观模式 Facade

对于复杂的调用，比如有复杂顺序要求，有许多繁琐的 api 等，或者有些 api 的调用不想暴露出来，用一个外观类作为对外的门面，在这里用对外一个函数去调用那些复杂的内部函数。

比如 Android 中的 Context，内部有很多复杂功能通过比如 startActivty、sendBroadcast、bindService 实现。

class CPU {
    public void freeze() { ... }
    public void jump(long position) { ... }
    public void execute() { ... }
}

class HardDrive {
    public byte[] read(long lba, int size) { ... }
}

class Memory {
    public void load(long position, byte[] data) { ... }
}

/* Facade */
class ComputerFacade {
    private CPU processor;
    private Memory ram;
    private HardDrive hd;

    public ComputerFacade() {
        this.processor = new CPU();
        this.ram = new Memory();
        this.hd = new HardDrive();
    }

    public void start() {
        processor.freeze();
        ram.load(BOOT_ADDRESS, hd.read(BOOT_SECTOR, SECTOR_SIZE));
        processor.jump(BOOT_ADDRESS);
        processor.execute();
    }
}

/* Client */
class You {
    public static void main(String[] args) {
        ComputerFacade computer = new ComputerFacade();
        computer.start();
    }
}

装饰者模式 Decorator

可以在运行时，动态的添加和删除某一个或者多个功能。贯彻单一职责原则的好方法。

装饰者模式很像责任链模式，区别是在责任链中有一个明确的类来处理请求，而在装饰者模式中，所有的装饰者都参与处理请求。

可以实现类似多继承的效果。（实际上是多层的继承）

Java 的 IO 使用就是典型的装饰者模式

// The interface Coffee defines the functionality of Coffee implemented by decorator
public interface Coffee {
    public double getCost(); // Returns the cost of the coffee
    public String getIngredients(); // Returns the ingredients of the coffee
}

// Extension of a simple coffee without any extra ingredients
public class SimpleCoffee implements Coffee {
    @Override
    public double getCost() {
        return 1;
    }

    @Override
    public String getIngredients() {
        return "Coffee";
    }
}

// Abstract decorator class - note that it implements Coffee interface
public abstract class CoffeeDecorator implements Coffee {
    protected final Coffee decoratedCoffee;

    public CoffeeDecorator(Coffee c) {
        this.decoratedCoffee = c;
    }

    @Override
    public double getCost() {
        return decoratedCoffee.getCost();
    }

    @Override
    public String getIngredients() {
        return decoratedCoffee.getIngredients();
    }
}

// Decorator WithMilk mixes milk into coffee.
// Note it extends CoffeeDecorator.
class WithMilk extends CoffeeDecorator {
    public WithMilk(Coffee c) {
        super(c);
    }

    @Overriding
    public double getCost() {
        return super.getCost() + 0.5;
    }

    @Overriding
    public String getIngredients() {
        return super.getIngredients() + ", Milk";
    }
}

// Decorator WithSprinkles mixes sprinkles onto coffee.
// Note it extends CoffeeDecorator.
class WithSprinkles extends CoffeeDecorator {
    public WithSprinkles(Coffee c) {
        super(c);
    }

    @Overriding
    public double getCost() {
        return super.getCost() + 0.2;
    }

    @Overriding
    public String getIngredients() {
        return super.getIngredients() + ", Sprinkles";
    }
}

public class Main {
    public static void printInfo(Coffee c) {
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());
    }

    public static void main(String[] args) {
        Coffee c = new SimpleCoffee();
        printInfo(c);
        c = new WithMilk(c);
        printInfo(c);
        c = new WithSprinkles(c); // 类似于 c = new WithMilk(new WithSprinkles(c));
        printInfo(c);
    }
}

代理模式 Proxy Pattern

对于调用者来说，操作并没有不同，看起来是一样的。

但是真正的处理过程是通过代理人完成，代理人可以加上一些自己的操作，可以是增加操作，也可以是修改操作。

代理与装饰者的一个重要区别是：代理中可以实例化真正的操作对象。而装饰者只能包装现有的操作对象。

比如代理服务器就是修改请求，一些商品的销售代理就是把货品卖给你的同时自己也抽成。

interface Give{
    public void giveMoney() ;
}

class RealGive implements Give{
    public void giveMoney(){
        System.out.println(real give money") ;
    }
}

class GiveProxy implements Give{

    private Give give = null ;

    public GiveProxy(Give give){
        this.give = give ;
    }

    public void before(){
        System.out.println("before") ;
    }
    
    public void after(){
        System.out.println("after") ;
    }
    public void giveMoney(){
        this.before() ;
        this.give.giveMoney() ;
        this.after() ;
    }
}

public class ProxyDemo{
    public static void main(String args[]){
        Give give = new GiveProxy(new RealGive()) ;
        give.giveMoney() ;
    }
}

桥接模式 bridge

将抽象部分与实现部分分离，使他们独立地进行变化。抽象部分和实现部分（固有操作）的区别依据具体的业务逻辑而定。

其实就是，一个类除了本身的固有操作，还存在两个或者多个维度的变化，且这多个维度都扩展的可能，使用桥接模式可以方便在多个维度进行扩展。

也可以达到类似多继承的效果。本质上是通过增加耦合，不用继承。

与装饰者模式的区别在于：装饰者模式把多出来的部分放到单独的类里面，每个单独的类都是一个单一的功能。桥接模式则把多出来的功能按照某种维度抽象出来，形成不同的接口/抽象类，然后让具体的不同功能按照他的维度去实现不同的接口。

某个功能的具体实现是类的某个成员变量来提供。

/** "Implementor" */
interface DrawingAPI {
    public void drawCircle(int x, int y, int radius);
    public void drawDot(int x, int y);
}

/** "ConcreteImplementor"  1/2 */
class DrawingAPIWindows implements DrawingAPI {
    public void drawCircle(int x, int y, int radius) {
        System.out.printf("API Windows circle);
    }
     public void drawCircle(int x, int y) {
        System.out.printf("API Windows dot);
    }
}

/** "ConcreteImplementor" 2/2 */
class DrawingAPIUbuntu implements DrawingAPI {
    public void drawCircle(int x, int y, int radius) {
        System.out.printf("API Ubuntu circle);
    }
   public void drawCircle(int x, int y) {
        System.out.printf("API Ubuntu dot);
    }
}

/** "Abstraction" */
abstract class Shape {
    protected DrawingAPI drawingAPI;

    protected Shape(DrawingAPI drawingAPI){
        this.drawingAPI = drawingAPI;
    }

    public abstract void draw();                                 // low-level
    public abstract void resizeByPercentage(final double pct);   // high-level
}

/** "Refined Abstraction" */
class CircleShape extends Shape {
    private int x, y, radius;
    public CircleShape(int x, double y, int radius, DrawingAPI drawingAPI) {
        super(drawingAPI);
        this.x = x;  this.y = y;  this.radius = radius;
    }

    // low-level i.e. Implementation specific
    public void draw() {
        drawingAPI.drawCircle(x, y, radius);
    }
    // high-level i.e. Abstraction specific
    public void resizeByPercentage(final double pct) {
        radius *= (1.0 + pct/100.0);
    }
}

/** "Client" */
class BridgePattern {
    public static void main(final String[] args) {
        Shape shape =  new CircleShape(1, 2, 3, new DrawingAPIWindows()),
        shape.resizeByPercentage(2.5);
        shape.draw();
    }
}

享元模式 Flyweight

Flyweight，蝇量级，拳击里的一个体重级别，在 100 斤上下，基本是最轻的一个拳击级别。

所以，这个模式的目的就是轻，也就是减少内存，减少 io 等各种性能开销，具体的实现方式，就是中文译名：共享单元。

可以共享的相同内容称为内部状态(Intrinsic State)
需要外部环境来设置的不能共享的内容称为外部状态(Extrinsic State)
由于区分了内部状态和外部状态，因此可以通过设置不同的外部状态，使得相同的对象可以具有一些不同的特征，而相同的内部状态是可以共享的。

有 Flyweight Factory，Flyweight 接口，Flyweight 实现类这几个角色。通常使用某种工厂模式，使用Flyweight Factory 去生产 Flyweight。

仔细一看代码会发现，这不就是个简单的缓存嘛。

public interface SmartPhoneModel {
   void double getScreenSize();
}

public IPhone4 implements SmartPhoneModel{

    private String color ;

    public IPhone4(String color){
        this.color = color ;
    }

    void double getScreenSize(){
        return 3.5 ;
    }
}
 
public class SmartPhoneFactory {
    private static final Map<String, SmartPhone> extrinsicStateKeyCache = new HashMap<>();

    public static SmartPhoneModel getSmartPhone(String color) {
        SmartPhoneModel smartPhoneModel = extrinsicStateKeyCache.get(modelStr);

        if(smartPhoneModel == null) {
            smartPhoneModel = new IPhone4(color);
            extrinsicStateKeyCache.put(color, smartPhoneModel);
        }
        return smartPhoneModel;
    }
}

参考

https://en.wikipedia.org/wiki/Design_Patterns http://design-patterns.readthedocs.io/zh_CN/latest/index.html

设计模式创建篇

Wed, 25 Apr 2018 16:41:00 +0000

设计模式创建篇

单例模式

public class Singleton{
    private volatile static Singleton instance;
    private Singleton(){};
    public static Singleton getInstance(){
        if(instance==null){
            sychronized(Singleton.class){
                if(instance==null)
                    instance=new Singleton();
            }
        }
        return instatnce;
    }
}

Builder 模式 Builder Pattern

类似一个更可控的构造函数，可以方便控制参数的配置顺序，

public class MyData{
    private int id;
    private String num; 
    public void setId(int id){
        this.id=id;
    }
    public void setNum(String num){
        this.num = num + "id"; // 注意这里
    }

    public class MyBuilder{
        private int id;
        private String num;
        public MyData build(){
            MyData d = new MyData();
            d.setId(id);
            d.setNum(num);
            return t;
        }
        public MyBuilder setId(int id){
            this.id=id;
            return this;
        }
        public MyBuilder setNum(String num){
            this.num=num;
            return this;
        }
    }
}

工厂模式

工厂模式又有几个不同的实现方式：

简单工厂模式 Simple Factory / 静态工厂方法 Static Factory Method

因为工厂方法是静态方法，所以使用起来很方便，可通过类名直接调用，只需要传入参数即可，在实际开发中，还可以在调用时将所传入的参数保存在 XML/JSON 等格式的配置文件中。

简单工厂模式最大的问题在于工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑。

所有的生产都在一个工厂中，工厂无法继承，也无法将不同的产品在不同的工厂中生产。

public abstract class Instrument{
    public abstract void play();
} 

public class Guitar extends Instrument{
    public void play(){
        System.out.println("guitar solo");
    }
}

public class Bass extends Instrument{
    public void play(){
        System.out.println("bass slap");
    }
}

public class FenderFactory{

    // 注意这里是 static 方法
    public static Instrument create(int type){
        if(type == 1){
            return new Guitar();
        }else if(type == 2){
            return new Bass();
        }else{
            return null;
        }
    }
}

工厂方法模式 Factory method

当系统需要加入新产品时，无须修改现有代码，而只要添加相应的具体工厂和具体产品就可以了。

在业务复杂的时候，也会使用工厂模式去生产工厂方法模式中的具体工厂类。

public abstract class Instrument{
    public abstract void play();
} 

public class Guitar extends Instrument{
    public void play(){
        System.out.println("guitar solo");
    }
}

public class Bass extends Instrument{
    public void play(){
        System.out.println("bass slap");
    }
}

public abstract class InstrumentFactory{
    // 可以有参数，也可以没有
    public abstract Instrument create(int type);
}

public class FenderGuitarFactory extends InstrumentFactory{

    public Instrument create(int type){
        return new Guitar();
    }
}

抽象工厂模式 Abstract Factory Pattern

通常用在多种产品有依赖关系，产品原料有不同来源的情况。

public abstract class Guitar{
    public abstract void assemble();
}

public abstract class Pickup{
    public abstract void create();
}

public class Telecaster extends Guitar{

    PickupFactory pickupFactory;

    public Telecaster(PickupFactory pickupFactory){
        this.pickupFactory = pickupFactory ;
    }

    public void assemble(){
        pickupFactory.createPickup();
        System.out.println("用各种部件，组装吉他");
    }
}

public class SingleCoil extends Pickup{
    public void createPickup(){
        System.out.println("生产单线圈拾音器");
    }
}

public abstract class GuitarFactory{
    public abstract Guitar createGuitar();
}

public abstract class PickupFactory{
    public abstract Pickup createPickup();
}

public class FenderFactory extends GuitarFactory{

    // 零件工厂也可以在 create 函数中实例化，视具体情况而定
    PickupFactory pickupFactory = new SeymourDuncanFactory();

    public Guitar createGuitar(int model){
        // 这里同样可以通过参数 if else 去生产不同产品
        return new Telecaster(pickupFactory);
    }
}

public class GibsonFactory extends GuitarFactory{
    
}

public class SeymourDuncanFactory extends PickupFactory{
    public Pickup createPickup(int model){
        // 这里同样可以通过参数 if else 去生产不同产品
        return new SingleCoil();
    }
}

原型模式 Prototype

这个模式感觉像个凑数的。😂。将一个对象进行拷贝。 JAVA 继承 Cloneable，重写 clone()

参考

https://en.wikipedia.org/wiki/Design_Patterns

笨马

Android Activity Task launch mode

Android Activity Task launch mode

进程

Task stack

taskAffinity

launch mode

allowTaskReparenting

alwaysRetainTaskState

clearTaskOnLaunch

finishOnTaskLaunch

相关的 Intent FLAG

参考

Java 中的 Enum 枚举

Java 中的 Enum 枚举

方法

几个特性

添加方法与自定义构造函数

抽象方法

HashMap

HashMap

哈希表 / 散列表

HashMap

插入 put

扩容 resize

取值 get

ArrayMap

SparseArray

Android 内存泄漏

Android 内存泄漏

形成的原因

常见情况和避免方式

持有A实例的B的生命周期 超过了 A实例的生命周期，导致A实例无法回收。

静态实例 所在的类

集合

线程

Android 的常见情况和避免方式

Activity

Handler

广播接收器、注册观察者、系统事件的监听器

资源源对象 File / Cursor

Android 的调试

Android 应用开发性能优化提纲

「已发布」Android 应用开发性能优化提纲

布局和绘制

布局

绘制

UI 资源

内存

内存泄漏

自动装箱和集合类

Bitmap 使用

及时销毁

设置合适的采样率

设置合适的像素格式

使用用软引用（SoftRefrence）

图片缓存

其他媒体文件

性能优化

网络优化

数据库优化

Java 代码优化

业务逻辑优化

参考

Android TouchEvent 触摸事件传递

Android TouchEvent 触摸事件传递

Activity

ViewGroup 中的 dispatchTouchEvent

View 中的 dispatchTouchEvent

framework 中包含的工具

参考

Android View 测量布局绘制过程

开始

Measure

onMeasure

View.onMeasure

ViewGroup.onMeasure

MeasureSpec

LayoutParams

getChildMeasureSpec

插入 `put`

扩容 `resize`

取值 `get`

持有A实例的B的生命周期超过了 A实例的生命周期，导致A实例无法回收。

静态实例所在的类

`layout`

`onLayout`

设计模式结构篇

「已发布」设计模式结构篇

设计模式创建篇

设计模式创建篇