杨浩的个人博客【yhthu.com】

Android App的架构设计：从VM、MVC、MVP到MVVM

2016-09-22T10:08:29.146Z

随着Android应用开发规模的扩大，客户端业务逻辑也越来越复杂，已然不是简单的数据展示了。如同后端开发遇到瓶颈时采用的组件拆分思想，客户端也需要进行架构设计，拆分视图和数据，解除模块之间的耦合，提高模块内部的聚合度。

开始之前先上一张内部分享时用的PPT图：

以上是笔者在客户端开发过程中面临的问题，涉及到以下四个主题：

Android App的架构设计：从VM、MVC、MVP到MVVM
Android App的网络访问：支持REST、HTTPS及SPDY的Retrofit+Okhttp
Android App的响应式编程：RxJava/RxAndroid解决方案
Android App的依赖注入：Dagger2和ButterKnife使用

本文将从架构设计入手，分享笔者在Android开发中采用MVC、MVP及MVVM的一些想法。

一、Android原生开发中的MVC

Android原生开发采用XML文件实现页面布局，通过Java在Activity中开发业务逻辑，这种开发模式实际上已经采用了MVC的思想，分离视图和控制器。MVC模式（Model–view–controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

MVC模式最早由Trygve Reenskaug在1978年提出，是施乐帕罗奥多研究中心（Xerox
PARC）在20世纪80年代为程序语言Smalltalk发明的一种软件架构。MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式通过对复杂度的简化，使程序结构更加直观。软件系统通过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：

控制器（Controller）- 负责转发请求，对请求进行处理。

视图（View） - 界面设计人员进行图形界面设计。

模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

——以上内容来自《维基百科》

在Android编程中，View对应xml布局文件，Model对应实体模型（网络、数据库、I/O），Controller对应Activity业务逻辑，数据处理和UI处理。如下图所示。

但在实际开发过程中，纯粹作为View的各个XML文件功能较弱，Activity基本上都是View和Controller的合体，既要负责视图的显示又要加入控制逻辑，承担的功能很多，导致代码量很大。所有更贴切的目前常规的开发说应该是View-Model模式，大部分都是通过Activity的协调，连接处理逻辑的。

二、从MVC过渡到MVP

在业务逻辑稍微复杂一点的页面，Activity的代码超过一千是很容易的，如果作者又刚好读过《如何写出无法维护的代码》，那么恭喜后来接手该代码的童鞋，接下来的几个月会很酸爽的。。。

既然Activity存在代码量过大的问题，那自然会想到进行拆分。上节说到Android原生开发采用了MVC的思想，但Activity并不是一个标准的MVC模式中的Controller，它的首要职责是加载应用的布局和初始化用户界面，并接受并处理来自用户的操作请求，进而作出响应。随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。

MVP是从MVC过渡而来，MVP框架由三部分组成：View负责显示，Presenter负责逻辑处理，Model提供数据。Android开发从MVC过渡到MVP，最主要的变化就是将Activity中负责业务逻辑的代码移到Presenter中，Activity只充当MVP中的View，负责界面初始化以及建立界面控件与Presenter的关联。

这样拆分之后，Presenter承担了大量的逻辑操作，避免了Activity的臃肿。整个架构如下图所示。

View(Activity)负责响应用户操作，通过Presenter暴露的方法请求数据；
Presenter在获取数据后，通过View(Activity)暴露的方法实现界面控制（showLoading/showUsers）；
Presenter的数据是通过Model来获取的，Model包含网络、数据库以及I/O等；
Model通过回调的方式将数据传到Presenter中。

采用MVP明显的优点是避免了传统开发模式中View和Model耦合的情况，提高了代码可扩展性、组件复用能力、团队协作的效率以及单元测试的便利性。但也有一些缺点，比如：

Model到Presenter的数据传递过程需要通过回调；
View(Activity)需要持有Presenter的引用，同时，Presenter也需要持有View(Activity)的引用，增加了控制的复杂度；
MVC中Activity的代码很臃肿，转移到MVP的Presenter中，同样造成了Presenter在业务逻辑复杂时的代码臃肿。

三、从Presenter到ViewModel

MVVM是Model-View-ViewModel的简称，从实际效果来看，ViewModel是View的数据模型和Presenter的结合，具体结构如下图所示：

View（视图层）采用XML文件进行界面的描述；
Model（模型层）通过网络和本地数据库获取视图层所需数据；
ViewModel（视图-模型层）负责View和Model之间的通信，以此分离视图和数据。

View和Model之间通过Android Data Binding技术，实现视图和数据的双向绑定；ViewModel持有Model的引用，通过Model的方法请求数据；获取数据后，通过Callback（回调）的方式回到ViewModel中，由于ViewModel与View的双向绑定，使得界面得以实时更新。同时，界面输入的数据变化时，由于双向绑定技术，ViewModel中的数据得以实时更新，提高了数据采集的效率。

采用ViewModel解决MVP中View(Activity)和Presenter相互持有对方应用的问题，界面由数据进行驱动，响应界面操作无需由View(Activity)传递，数据的变化也无需Presenter调用View(Activity)实现，使得数据传递的过程更加简洁，高效。

在Android中实现MVVM架构的核心支撑技术是Google去年I/O大会开源的Data binding技术，这项技术的思想并不新颖，最初由微软提出，在前端开发中已经有成熟的应用。下面对其进行简要的介绍。

四、Android中的Data Binding

学习Data Binding主要推荐两个内容：

这两篇文章中已经将Data Binding的基本内容描述的很详细了。这里仅列两个在实践中遇到的坑，抛砖引玉。

ObservableField的get方法可能无法返回界面实时更新的内容

1	public ObservableField<String> username = new ObservableField<>();

上述username表示用户名，在界面上可能会与EditText绑定。通过username的set方法可以设置EditText显示，但如果输入变更后，通过get方法却不一定能及时返回界面的数据。

Data Binding依然有很多支持的不好的组件（listview，recyclerView等），不可能通过给所有组件绑定ViewModel从而实现Activity没有业务逻辑操作。另外，ViewModel获取数据之后，也不可能把所有数据直接绑定到界面，有些也需要通过回调传到Activity中。

从MVC、MVP到MVVM，实际上是模型和视图的分离过程。MVC中模型和视图没有完全分离，造成Activity代码臃肿，MVP中通过Presenter来进行中转，模型和视图彻底分离，但由于V和P互相引用，代码不够优雅。ViewModel通过Data Binding实现了视图和数据的绑定，解决了这种MVP的缺陷，但目前也存在Data Binding还不成熟的问题。

其实，MVC、MVP及MVVM没有绝对好坏，在软件编程过程中，也没必要非此即彼，最重要的是让软件高内聚、低耦合、可维护、可扩展，至于架构，根据实际情况选择吧。

Android开发笔记——内存泄露与线程安全

2016-05-16T03:01:44.185Z

本次分享主要结合上周Coverity扫描盘古源码发现的问题和平时的实践，对内存泄露和线程安全这两个问题进行一些说明。扫描发现的BUG大致分为四类：1）空指针；2）除0；3）内存、资源泄露；4）线程安全。第一、二个问题属于编码考虑不周，第三、四个问题则需要更深入的分析。

内存泄露
线程安全

一、内存泄露

1、很抱歉，”XXX”已停止运行。OOM？

怎样才能让app报OOM呢？最简单的办法如下：

1
2
3

Bitmap bt1 = BitmapFactory.decodeResource(this.getResources(), R.drawable.image);
Bitmap bt2 = BitmapFactory.decodeResource(this.getResources(), R.drawable.image);
Bitmap btn = ...

2、查看内存占用

命令行：adb shell dumpsys meminfo packageName

通过Android Studio的Memory Monitor查看内存中Dalvik Heap的实时变化

3、发生内存泄露的条件

首先，每个app有最大内存限制。

1
2
3

ActivityManager activityManager = (ActivityManager)
                        context.getSystemService(Context.ACTIVITY_SERVICE);
activityManager.getMemoryClass();

getMemoryClass()取到的是最大内存资源。Android中的堆内存分为Native Heap和Dalvik Heap。C/C++申请的内存空间在Native Heap中，Java申请的内存空间则在Dalvik Heap中。对于head堆的大小限制，可以查看/system/build.prop文件：

1
2
3

dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=96m
dalvik.vm.heapsize=256m

注意：

heapsize参数表示单个进程heap可用的最大内存，但如果存在以下参数”dalvik.vm.headgrowthlimit =96m”表示单个进程heap内存被限定在96m，即程序运行过程实际只能使用96m内存。

如果申请的内存资源超过上述限制，系统就会抛出OOM错误。

4、常见避免OOM的措施

以下主要从四个方面总结常见的措施：1）减小对象的内存占用；2）内存对象的重复利用；3）避免对象的内存泄露；4）内存使用策略优化。

4.1 减小对象的内存占用

使用ArrayMap/SparseArray而不是HashMap等传统数据结构。参考链接
在Android中避免使用枚举。
减小Bitmap对象的内存占用。inSampleSize和decode format。

4.2 内存对象的重复利用

ListView/GridView等出现大量重复子组件的视图里面对ConvertView的复用
使用LRU机制缓存Bitmap
避免在onDraw方法里面执行对象的创建
使用StringBuilder来替代频繁的”+”

4.3 避免对象的内存泄露

4.1和4.2都是比较常规的措施，4.3需要重点关注。

1）Activity泄露

导致Activity泄露的原因较多，下面列举一些比较常见的。从原理上主要分为两类：i）静态对象；ii）this$0。

Activity被static变量引用。这段代码来自于我们的Crash上传

private static Map<ComponentName, ExceptionHandler> configMap = 
                        new HashMap<ComponentName, ExceptionHandler>();

public static void setActivity(final Activity activity, boolean send2Server) {

    Log.d(TAG, "bind exception handler : " + activity.getComponentName().getClassName());
    //上下文初始化
    SDKContext.init(activity.getApplication());
    init(activity.getApplication());

    ExceptionHandler exceptionHandler = new ExceptionHandler(
                        activity, send2Server, Thread.getDefaultUncaughtExceptionHandler());
    configMap.put(activity.getComponentName(), exceptionHandler);
    Thread.setDefaultUncaughtExceptionHandler(exceptionHandler);
}

下面是通过MAT分析“服务+”中一个Activity泄露的截图：

内部类引用导致Activity的泄漏
最典型的场景是Handler导致的Activity泄漏，如果Handler中有延迟的任务或者是等待执行的任务队列过长，都有可能因为Handler继续执行而导致Activity发生泄漏。此时的引用关系链是Looper -> MessageQueue -> Message -> Handler -> Activity。为了解决这个问题，可以在UI退出之前，执行remove Handler消息队列中的消息与runnable对象。或者是使用Static + WeakReference的方式来达到断开Handler与Activity之间存在引用关系的目的。
可参考链接：线程通信

Handler mHandler = new Handler() {
            
    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
            
        // 根据msg调用Activity的方法
    }
};

static class MyHandler extends Handler {

    WeakReference<DemoActivity> mActivity;

    public MyHandler(DemoActivity demoActivity) {
        mActivity = new WeakReference<DemoActivity>(demoActivity);
    }

    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
        DemoActivity theActivity = mActivity.get();

        // 根据msg调用theActivity的方法
    }
}

2）考虑使用Application Context而不是Activity Context

对于大部分非必须使用Activity Context的情况（Dialog的Context就必须是Activity Context），我们都可以考虑使用Application Context而不是Activity的Context，这样可以避免不经意的Activity泄露。

3）注意临时Bitmap对象的及时回收

虽然在大多数情况下，我们会对Bitmap增加缓存机制，但是在某些时候，部分Bitmap是需要及时回收的。例如临时创建的某个相对比较大的bitmap对象，在经过变换得到新的bitmap对象之后，应该尽快回收原始的bitmap，这样能够更快释放原始bitmap所占用的空间。

4）内存占用监控
通过Runtime获取maxMemory，而maxMemory-totalMemory即为剩余可使用的dalvik内存。定期检查这个值，达到80%就去释放各种cache资源（bitmap的cache）。

/**
 * Returns the maximum number of bytes the heap can expand to. See {@link #totalMemory} for the
 * current number of bytes taken by the heap, and {@link #freeMemory} for the current number of
 * those bytes actually used by live objects.
 */
int maxMemory = Runtime.getRuntime().maxMemory()); // 应用程序最大可用内存
/**
 * Returns the number of bytes taken by the heap at its current size. The heap may expand or
 * contract over time, as the number of live objects increases or decreases. See
 * {@link #maxMemory} for the maximum heap size, and {@link #freeMemory} for an idea of how much
 * the heap could currently contract.
 */
long totalMemory = Runtime.getRuntime().totalMemory()); // 应用程序已获得内存
/**
 * Returns the number of bytes currently available on the heap without expanding the heap. See
 * {@link #totalMemory} for the heap's current size. When these bytes are exhausted, the heap
 * may expand. See {@link #maxMemory} for that limit.
 */
long freeMemory = Runtime.getRuntime().freeMemory()); // 应用程序已获得内存中未使用内存

5）注意Cursor对象是否及时关闭

在程序中我们经常会进行查询数据库的操作，但时常会存在不小心使用Cursor之后没有及时关闭的情况。这些Cursor的泄露，反复多次出现的话会对内存管理产生很大的负面影响，我们需要谨记对Cursor对象的及时关闭。

4.4 内存使用策略优化

谨慎使用large heap
综合考虑设备内存阈值与其他因素设计合适的缓存大小
onLowMemory()/onTrimMemory(int)
资源文件需要选择合适的文件夹进行存放
Try catch某些大内存分配的操作
谨慎使用static对象
优化布局层次，减少内存消耗
谨慎使用多进程
谨慎使用依赖注入框架
使用ProGuard来剔除不需要的代码
谨慎使用第三方libraries
考虑不同的实现方式来优化内存占用

二、线程安全

1、下面的方法是线程安全的吗？

class MyCounter {
	private static int counter = 0;
 
	public static int getCount() {
		return counter++;
	}
}

怎样使上述方法线程安全？

2、Java中的线程安全

怎样保持在多线程环境下的数据一致性，Java提供了多种方法实现：

synchronized
java.util.concurrent.atomic
java.util.concurrent.locks
thread safe collection（ConcurrentHashMap）
volatile

2.1 synchronized

JVM保证被synchronized关键字修饰的代码段在同一时间只能被一个线程访问，内部通过对对象或类加锁来实现的。当方法被synchronized修饰时，锁加在对象上；当方法同时为static时，锁加在类上。从性能的角度来讲，一般不建议直接将锁加在类上，这样会使得类的所有对象的该方法均为synchronized的。

从之前扫描的问题来看，在编写synchronized程序时主要有两点需要注意：

synchronized需要创建基于对象或者类的锁，所以不能在构造器或者变量上加锁。
synchronized造成死锁。

1) 锁加在哪里？

List<ResultPoint> currentPossible = possibleResultPoints;
List<ResultPoint> currentLast = lastPossibleResultPoints;
int frameLeft = frame.left;
int frameTop = frame.top;
if (currentPossible.isEmpty()) {
	lastPossibleResultPoints = null;
} else {
	possibleResultPoints = new ArrayList<>(5);
	lastPossibleResultPoints = currentPossible;
	paint.setAlpha(CURRENT_POINT_OPACITY);
	paint.setColor(resultPointColor);
	synchronized (currentPossible) {
		for (ResultPoint point : currentPossible) {
			canvas.drawCircle(frameLeft
					+ (int) (point.getX() * scaleX), frameTop
					+ (int) (point.getY() * scaleY), POINT_SIZE,
					paint);
		}
	}
}

上述方法中，possibleResultPoints的创建没有采用同步措施，需要使用Collections.synchronizedXxx。

List<MyType> list = Collections.synchronizedList(new ArrayList(<MyType>));
...
synchronized(list){
    for(MyType m : list){
        foo(m);
        m.doSomething();
    }
}

一般比较推荐创建一个虚拟的对象专门用于获取锁。

//dummy object variable for synchronization
private Object mutex=new Object();
...
//using synchronized block to read, increment and update count value synchronously
synchronized (mutex) {
        count++;
}

PS：直接在方法上加synchronized可能DoS攻击喔，举个栗子：

public class MyObject {
    // Locks on the object's monitor
    public synchronized void doSomething() { 
    // ...
    }
}
  
// 黑客的代码
MyObject myObject = new MyObject();
synchronized (myObject) {
    while (true) {
        // Indefinitely delay myObject
        Thread.sleep(Integer.MAX_VALUE); 
    }
}

黑客的代码获取了MyObject对象的锁，导致doSomething死锁，从而引发Denial of Service。

public class MyObject {
    //locks on the class object's monitor
    public static synchronized void doSomething() { 
    // ...
    }
}
  
// 黑客的代码
synchronized (MyObject.class) {
    while (true) {
        Thread.sleep(Integer.MAX_VALUE); // Indefinitely delay MyObject
    }
}

2) 死锁

public class ThreadDeadlock {
 
    public static void main(String[] args) throws InterruptedException {
        Object obj1 = new Object();
        Object obj2 = new Object();
        Object obj3 = new Object();
     
        Thread t1 = new Thread(new SyncThread(obj1, obj2), "t1");
        Thread t2 = new Thread(new SyncThread(obj2, obj3), "t2");
        Thread t3 = new Thread(new SyncThread(obj3, obj1), "t3");
         
        t1.start();
        Thread.sleep(5000);
        t2.start();
        Thread.sleep(5000);
        t3.start();
         
    }
 
}
 
class SyncThread implements Runnable{
    private Object obj1;
    private Object obj2;
 
    public SyncThread(Object o1, Object o2){
        this.obj1=o1;
        this.obj2=o2;
    }
    
    @Override
    public void run() {
        String name = Thread.currentThread().getName();
        System.out.println(name + " acquiring lock on "+obj1);
        synchronized (obj1) {
         System.out.println(name + " acquired lock on "+obj1);
         work();
         System.out.println(name + " acquiring lock on "+obj2);
         synchronized (obj2) {
            System.out.println(name + " acquired lock on "+obj2);
            work();
        }
         System.out.println(name + " released lock on "+obj2);
        }
        System.out.println(name + " released lock on "+obj1);
        System.out.println(name + " finished execution.");
    }
    
    private void work() {
        try {
            Thread.sleep(30000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

上述代码会输出什么呢？

t1 acquiring lock on java.lang.Object@6d9dd520
t1 acquired lock on java.lang.Object@6d9dd520
t2 acquiring lock on java.lang.Object@22aed3a5
t2 acquired lock on java.lang.Object@22aed3a5
t3 acquiring lock on java.lang.Object@218c2661
t3 acquired lock on java.lang.Object@218c2661
t1 acquiring lock on java.lang.Object@22aed3a5
t2 acquiring lock on java.lang.Object@218c2661
t3 acquiring lock on java.lang.Object@6d9dd520

读书笔记-Autonomous Intelligent Vehicles（一）

2016-05-16T01:19:52.006Z

Autonomous intelligent vehicles have to finish the basic procedures:

perceiving and modeling environment
localizing and building maps
planning paths and making decisions
controlling the vehicles within limit time for real-time purposes.

Meanwhile, we face the challenge of processing large amounts of data from multi-sensors, such as cameras, lidars, radars.

Our goal in writing this book is threefold:

First, it creates an updated reference book of intelligent vehicles.
Second, this book not only presents object/obstacle detection and recognition, but also introduces vehicle lateral and longitudinal control algorithms, which benefits the readers keen to learn broadly about intelligent vehicles.
Finally, we put emphasis on high-level concepts, and at the same time provide the low-level details of implementation.

We try to link theory, algorithms, and implementation to promote intelligent vehicle research.

This book is divided into four parts.

The first part Autonomous Intelligent Vehicles presents the research motivation and purposes, the state-of-art of intelligent vehicles research. Also, we introduce the framework of intelligent vehicles.
The second part Environment Perception and Modeling which includes Road detection and tracking, Vehicle detection and tracking, Multiple-sensor based multiple-object tracking introduces environment perception and modeling.
The third part Vehicle Localization and Navigation which includes An integrated DGPS/IMU positioning approach, Vehicle navigation using global views presents vehicle navigation based on integrated GPS and INS.
The fourth part Advanced Vehicle Motion Control introduces vehicle lateral and longitudinal motion control.

The Key Technologies of Intelligent Vehicles:

Multi-sensor Fusion Based Environment Perception and Modeling
Vehicle Localization and Map Building
Path Planning and Decision-Making
Low-Level Motion Control

基于环境认知与建模的多维传感器数据融合

Figure 1.2 illustrates a general environment perception and modeling framework. From this framework, we can see that:

(i) The original data are collected by various sensors;
(ii) Various features are extracted from the original data, such as road (object) colors, lane edges, building contours;
(iii) Semantic objects are recognized using classifiers, and consist of lanes, signs, vehicles, pedestrians;
(iv) We can deduce driving contexts, and vehicle positions.

Multi-sensor fusion
Multi-sensor fusion is the basic framework of intelligent vehicles for better sensing surrounding environment structures, and detecting objects/obstacles. Roughly, the sensors used for surrounding environment perception are divided into two categories: active and passive ones. Active sensors include lidar, radar, ultrasonic and radio, while the commonly-used passive sensors are infrared and visual cameras. Different sensors are capable of providing different detection precision and range, and yielding different effects on environment. That is, combining various sensors could cover not only short-range but also long-range objects/obstacles, and also work in various weather conditions. Furthermore, the original data of different sensors can be fused in low-level fusion, high-level fusion, and hybrid fusion.
Dynamic Environment Modeling
Dynamic environment modeling based on moving on-vehicle cameras plays an important role in intelligent vehicles [17]. However, this is extremely challenging due to the combined effects of ego-motion, blur, light changing. Therefore, traditional methods for gradual illumination change, small motion objects, such as background subtraction, do not work well any more, even those that have been widely used in surveillance applications. Consequently, more and more approaches try to handle these issues [2, 17]. Unfortunately, it is still an open problem to reliably model and update background. To select different driving strategies, several broad scenarios are usually considered in path planning and decision-making, when navigating roads, intersections, parking lots, jammed intersections. Hence, scenario estimators are helpful for further decision-making, which is commonly used in the Urban Challenge.
Object Detection and Tracking
In general, in a driving environment, we are interested in static/dynamic obstacles, lane markings, traffic signs, vehicles, and pedestrians. Correspondingly, object detection and tracking are the key parts of environment perception and modeling.

通过多维传感器数据融合，有效实现对短距离、长距离的物体/障碍物的识别、跟踪，从而达到对环境的建模。可以看出，计算机视觉仍然是动态环境建模的挑战。

高精度定位和地图的构建

The goal of vehicle localization and map building is to generate a global map by combining the environment model, a local map and global information.

For vehicle localization, we face several challenges as follows:

(i) Usually, the absolute positions from GPS/DGPS and its variants are insufficient due to signal transmission;
(ii) The path planning and decision-making module needs more than just the vehicle absolute position as input;
(iii) Sensor noises greatly affect the accuracy of vehicle localization.

Regarding the first issue, though the GPS and its variants have been widely used in vehicle localization, its performance could degrade due to signal blockages and reflections of buildings and trees. In the worst case, Inertia Navigation System (INS) can maintain a position solution.

As for the second issue, local maps fusing laser, radar, and vision data with vehicle states are used to locate and track both static/dynamic obstacles and lanes. Furthermore, global maps could contain lane geometric information, lane makings, step signs, parking lots, check points and provide global environment information.

Referring to the third issue, various noise modules are considered to reduce localization error.

SLAM是目前研究的比较多的机器人定位和地图构建的算法。下面是结合ROS和SLAM的一些展示：

路径规划和决策制定

Global path planning is to find the fastest and safest way to get from the initial position to the goal position, while local path planning is to avoid obstacles for safe navigation.

Road following, making lane-changes, parking, obstacle avoidance, recovering from abnormal conditions. In many cases, decision-making depends of context driving, especially in driver assistance systems.

目前在高德、百度中用到路径规划算法是否可以通用呢？

低层运动控制

Its typical applications consist of automatic vehicle following/platoon, Adaptive Cruise Control (ACC), lane following. Vehicle control can be broadly divided into two categories: lateral control and longitudinal control(Fig. 1.4). The longitudinal control is related to distance–velocity control between vehicles for safety and comfort purposes. Here some assumptions are made about the state of vehicles and the parameters of models, such as in the PATH project. The lateral control isto maintain the vehicle’s position in the lane center, and it can be used for vehicle guidance assistance. Moreover, it is well known that the lateral and longitudinal dynamics of a vehicle are coupled in a combined lateral and longitudinal control, where the coupling degree is a function of the tire and vehicle parameters. In general, there are two different approaches to design vehicle controllers. One way to do this is to mimic driver operations, and the other is based on vehicle dynamic models and control strategies.

从目前业界动态来看，国内做自动驾驶、无人驾驶创业的厂商大多从ADAS切入，有市场的原因，比如目前普通车主能接受的汽车更加安全、智能，但还没到自动驾驶的程度；有技术的原因，移动设备的数据处理能力以及算法的实时性依然有待提升。如上所述，类似ADAS的运动控制可以分为横向和纵向的控制，横向运动控制主要是使车辆保持在道路中间，如车道保持系统；纵向运动控制基于距离和速度，是行驶安全性、舒适性的关键，自适应巡航、防碰撞预警系统等控制都属于纵向运动控制。

Android源码笔记——Camera系统架构

2016-05-03T10:28:27.523Z

Camera的架构与Android系统的整体架构保持一致，如下图所示，本文主要从以下四个方面对其进行说明。

Framework：Camera.java
Android Runtime：android_hardware_Camera.cpp
Library：Camera Client和Camera Service
HAL：CameraHardwareInterface

一、Framework：Camera.java

Camera是应用层软件直接使用的类，涵盖了启动、预览、拍摄及关闭等操作摄像头的全部接口。Camera.java在Android源码中的路径为：framework/base/core/java/android/hardware。为了说明整个Camera系统的架构，这里暂不横向分析Camera.java的功能，下面从open()方法着手：

public static Camera open() {
    int numberOfCameras = getNumberOfCameras();
    CameraInfo cameraInfo = new CameraInfo();
    for (int i = 0; i < numberOfCameras; i++) {
        getCameraInfo(i, cameraInfo);
        if (cameraInfo.facing == CameraInfo.CAMERA_FACING_BACK) {
            return new Camera(i);
        }
    }
    return null;
}

open()方法需要注意以下几点：

getNumberOfCameras为native方法，实现在android_hardware_Camera.cpp中；
CameraInfo是Camera定义的静态内部类，包含facing、orientation、canDisableShutterSound；
getCameraInfo内部调用native方法_getCameraInfo获取摄像头信息；
open()默认启动的是后置摄像头（CAMERA_FACING_BACK）。

/** used by Camera#open, Camera#open(int) */
Camera(int cameraId) {
    int err = cameraInitNormal(cameraId);
    if (checkInitErrors(err)) {
        switch(err) {
            case EACCESS:
                throw new RuntimeException("Fail to connect to camera service");
            case ENODEV:
                throw new RuntimeException("Camera initialization failed");
            default:
                // Should never hit this.
                throw new RuntimeException("Unknown camera error");
        }
    }
}

Camera构造器的核心实现在cameraInitNormal中，cameraInitNormal调用cameraInitVersion，并传入参数cameraId和CAMERA_HAL_API_VERSION_NORMAL_CONNECT，后者代表HAL的版本。

private int cameraInitVersion(int cameraId, int halVersion) {
    ……
    String packageName = ActivityThread.currentPackageName();
    return native_setup(new WeakReference<Camera>(this), cameraId, halVersion, packageName);
}

cameraInitNormal调用本地方法native_setup()，由此进入到android_hardware_Camera.cpp中，native_setup()的签名如下：

1 2	private native final int native_setup(Object camera_this, int cameraId, int halVersion, String packageName);

二、Android Runtime：android_hardware_Camera.cpp

native_setup()被动态注册到JNI，通过JNI调用android_hardware_Camera_native_setup()方法。

static JNINativeMethod camMethods[] = {
    ……
    { "native_setup",    "(Ljava/lang/Object;ILjava/lang/String;)V",
    (void*)android_hardware_Camera_native_setup }
    ……
};

JNI的重点是android_hardware_Camera_native_setup()方法的实现：

// connect to camera service
static jint android_hardware_Camera_native_setup(JNIEnv *env, jobject thiz,
    jobject weak_this, jint cameraId, jint halVersion, jstring clientPackageName)
{
    // Convert jstring to String16
    const char16_t *rawClientName = env->GetStringChars(clientPackageName, NULL);
    jsize rawClientNameLen = env->GetStringLength(clientPackageName);
    String16 clientName(rawClientName, rawClientNameLen);
    env->ReleaseStringChars(clientPackageName, rawClientName);

    sp<Camera> camera;
    if (halVersion == CAMERA_HAL_API_VERSION_NORMAL_CONNECT) {
        // Default path: hal version is don't care, do normal camera connect.
        camera = Camera::connect(cameraId, clientName,
                Camera::USE_CALLING_UID);
    } else {
        jint status = Camera::connectLegacy(cameraId, halVersion, clientName,
                Camera::USE_CALLING_UID, camera);
        if (status != NO_ERROR) {
            return status;
        }
    }

    if (camera == NULL) {
        return -EACCES;
    }

    // make sure camera hardware is alive
    if (camera->getStatus() != NO_ERROR) {
        return NO_INIT;
    }

    jclass clazz = env->GetObjectClass(thiz);
    if (clazz == NULL) {
        // This should never happen
        jniThrowRuntimeException(env, "Can't find android/hardware/Camera");
        return INVALID_OPERATION;
    }

    // We use a weak reference so the Camera object can be garbage collected.
    // The reference is only used as a proxy for callbacks.
    sp<JNICameraContext> context = new JNICameraContext(env, weak_this, clazz, camera);
    context->incStrong((void*)android_hardware_Camera_native_setup);
    camera->setListener(context);

    // save context in opaque field
    env->SetLongField(thiz, fields.context, (jlong)context.get());
    return NO_ERROR;
}

android_hardware_Camera_native_setup()方法通过调用Camera::connect()方法请求连接CameraService服务。入参中：

clientName是通过将clientPackageName从jstring转换为String16格式得到；
Camera::USE_CALLING_UID是定义在Camera.h中的枚举类型，其值为ICameraService::USE_CALLING_UID（同样为枚举类型，值为-1）。

Camera::connect()位于Camera.cpp中，由此进入到Library层。

三、Library：Camera Client和Camera Service

如上述架构图中所示，ICameraService.h、ICameraClient.h和ICamera.h三个类定义了Camera的接口和架构，ICameraService.cpp和Camera.cpp两个文件用于Camera架构的实现，Camera的具体功能在下层调用硬件相关的接口来实现。Camera.h是Camera系统对上层的接口。

具体的，Camera类继承模板类CameraBase，Camera::connect()调用了CameraBase.cpp中的connect()方法。

sp<Camera> Camera::connect(int cameraId, const String16& clientPackageName,
        int clientUid) {
    return CameraBaseT::connect(cameraId, clientPackageName, clientUid);
}

CameraBase实际上又继承了IBinder的DeathRecipient内部类，DeathRecipient虚拟继承自RefBase。RefBase是Android中的引用计数基础类，其中定义了incStrong、decStrong、incWeak和decWeak等涉及sp/wp的指针操作函数，当然这扯远了。

template <typename TCam>
struct CameraTraits {
};

template <typename TCam, typename TCamTraits = CameraTraits<TCam> >
class CameraBase : public IBinder::DeathRecipient
{
public:
    
    static sp<TCam> connect(int cameraId,
                            const String16& clientPackageName,
                            int clientUid);
    ……
}

class DeathRecipient : public virtual RefBase
{
public:
    virtual void binderDied(const wp<IBinder>& who) = 0;
};

回到Camera::connect()的实现上，其中，new TCam(cameraId)生成BnCameraClient对象，BnCameraClient定义在ICameraClient.h文件中，继承自模板类BnInterface。getCameraService()方法返回CameraService的服务代理BpCameraService，BpCameraService同样继承自模板类BnInterface。然后通过Binder通信发送CONNECT命令，当BnCameraService收到CONNECT命令后调用CameraService的connect()成员函数来做相应的处理。

template <typename TCam, typename TCamTraits>
sp<TCam> CameraBase<TCam, TCamTraits>::connect(int cameraId,
                                               const String16& clientPackageName,
                                               int clientUid)
{
    ALOGV("%s: connect", __FUNCTION__);
    sp<TCam> c = new TCam(cameraId); // BnCameraClient 
    sp<TCamCallbacks> cl = c;
    status_t status = NO_ERROR;
    const sp<ICameraService>& cs = getCameraService(); // BpCameraService

    if (cs != 0) {
        TCamConnectService fnConnectService = TCamTraits::fnConnectService;
        status = (cs.get()->*fnConnectService)(cl, cameraId, clientPackageName, clientUid,
                                             /*out*/ c->mCamera);
    }
    if (status == OK && c->mCamera != 0) {
        c->mCamera->asBinder()->linkToDeath(c);
        c->mStatus = NO_ERROR;
    } else {
        ALOGW("An error occurred while connecting to camera: %d", cameraId);
        c.clear();
    }
    return c;
}

class BnCameraClient: public BnInterface<ICameraClient>
{
public:
    virtual status_t    onTransact( uint32_t code,
                                    const Parcel& data,
                                    Parcel* reply,
                                    uint32_t flags = 0);
};

class BpCameraService: public BpInterface<ICameraService>
{
public:
    BpCameraService(const sp<IBinder>& impl)
        : BpInterface<ICameraService>(impl)
    {
    }
    ……
}

注：connect()函数在BpCameraService和BnCameraService的父类ICameraService中声明为纯虚函数，在BpCameraService和CameraService中分别给出了实现，BpCameraService作为代理类，提供接口给客户端，真正实现在BnCameraService的子类CameraService中。

在BpCameraService中，connect()函数实现如下：

// connect to camera service (android.hardware.Camera)
virtual status_t connect(const sp<ICameraClient>& cameraClient, int cameraId,
                         const String16 &clientPackageName, int clientUid,
                         /*out*/
                         sp<ICamera>& device)
{
    Parcel data, reply;
    data.writeInterfaceToken(ICameraService::getInterfaceDescriptor());
    data.writeStrongBinder(cameraClient->asBinder());
    data.writeInt32(cameraId);
    data.writeString16(clientPackageName);
    data.writeInt32(clientUid);
    remote()->transact(BnCameraService::CONNECT, data, &reply); // BpBinder的transact()函数向IPCThreadState实例发送消息，通知其有消息要发送给binder driver        
    if (readExceptionCode(reply)) return -EPROTO;
    status_t status = reply.readInt32();
    if (reply.readInt32() != 0) {
        device = interface_cast<ICamera>(reply.readStrongBinder()); // client端读出server返回的bind
    }
    return status;
}

首先将传递过来的Camera对象cameraClient转换成IBinder类型，将调用的参数写到Parcel（可理解为Binder通信的管道）中，通过BpBinder的transact()函数发送消息，然后由BnCameraService去响应该连接，最后就是等待服务端返回，如果成功则生成一个BpCamera实例。

真正的服务端响应实现在BnCameraService的onTransact()函数中，其负责解包收到的Parcel并执行client端的请求的方法。

status_t BnCameraService::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    switch(code) {
        ……
     case CONNECT: {
            CHECK_INTERFACE(ICameraService, data, reply);
            sp<ICameraClient> cameraClient =
                    interface_cast<ICameraClient>(data.readStrongBinder()); // 使用Camera的Binder对象生成Camera客户代理BpCameraClient实例
              int32_t cameraId = data.readInt32();
            const String16 clientName = data.readString16();
            int32_t clientUid = data.readInt32();
            sp<ICamera> camera;
            status_t status = connect(cameraClient, cameraId,
                    clientName, clientUid, /*out*/camera); // 将生成的BpCameraClient对象作为参数传递到CameraService的connect()函数中
              reply->writeNoException();
            reply->writeInt32(status); // 将BpCamera对象以IBinder的形式打包到Parcel中返回
              if (camera != NULL) {
                reply->writeInt32(1);
                reply->writeStrongBinder(camera->asBinder());
            } else {
                reply->writeInt32(0);
            }
            return NO_ERROR;
        } break;
    ……
    }
}

主要的处理包括：

通过data中Camera的Binder对象生成Camera客户代理BpCameraClient实例；
将生成的BpCameraClient对象作为参数传递到CameraService（/frameworks/av/services/camera /libcameraservice/CameraService.cpp）的connect()函数中，该函数会返回一个BpCamera实例；
将在上述实例对象以IBinder的形式打包到Parcel中返回。

最后，BpCamera实例是通过CameraService::connect()函数返回的。CameraService::connect()实现的核心是调用connectHelperLocked()函数根据HAL不同API的版本创建不同的client实例（早期版本中好像没有connectHelperLocked()这个函数，但功能基本相似）。

status_t CameraService::connectHelperLocked(
        /*out*/
        sp<Client>& client,
        /*in*/
        const sp<ICameraClient>& cameraClient,
        int cameraId,
        const String16& clientPackageName,
        int clientUid,
        int callingPid,
        int halVersion,
        bool legacyMode) {

    int facing = -1;
    int deviceVersion = getDeviceVersion(cameraId, &facing);

    if (halVersion < 0 || halVersion == deviceVersion) {
        // Default path: HAL version is unspecified by caller, create CameraClient
        // based on device version reported by the HAL.
        switch(deviceVersion) {
          case CAMERA_DEVICE_API_VERSION_1_0:
            client = new CameraClient(this, cameraClient,
                    clientPackageName, cameraId,
                    facing, callingPid, clientUid, getpid(), legacyMode);
            break;
          case CAMERA_DEVICE_API_VERSION_2_0:
          case CAMERA_DEVICE_API_VERSION_2_1:
          case CAMERA_DEVICE_API_VERSION_3_0:
          case CAMERA_DEVICE_API_VERSION_3_1:
          case CAMERA_DEVICE_API_VERSION_3_2:
            client = new Camera2Client(this, cameraClient,
                    clientPackageName, cameraId,
                    facing, callingPid, clientUid, getpid(), legacyMode);
            break;
          case -1:
            ALOGE("Invalid camera id %d", cameraId);
            return BAD_VALUE;
          default:
            ALOGE("Unknown camera device HAL version: %d", deviceVersion);
            return INVALID_OPERATION;
        }
    } else {
        // A particular HAL version is requested by caller. Create CameraClient
        // based on the requested HAL version.
        if (deviceVersion > CAMERA_DEVICE_API_VERSION_1_0 &&
            halVersion == CAMERA_DEVICE_API_VERSION_1_0) {
            // Only support higher HAL version device opened as HAL1.0 device.
            client = new CameraClient(this, cameraClient,
                    clientPackageName, cameraId,
                    facing, callingPid, clientUid, getpid(), legacyMode);
        } else {
            // Other combinations (e.g. HAL3.x open as HAL2.x) are not supported yet.
            ALOGE("Invalid camera HAL version %x: HAL %x device can only be"
                    " opened as HAL %x device", halVersion, deviceVersion,
                    CAMERA_DEVICE_API_VERSION_1_0);
            return INVALID_OPERATION;
        }
    }

    status_t status = connectFinishUnsafe(client, client->getRemote());
    if (status != OK) {
        // this is probably not recoverable.. maybe the client can try again
        return status;
    }

    mClient[cameraId] = client;
    LOG1("CameraService::connect X (id %d, this pid is %d)", cameraId,
         getpid());

    return OK;
}

可见，在CAMERA_DEVICE_API_VERSION_2_0之前使用CameraClient进行实例化，之后则采用Camera2Client进行实例化。以CameraClient为例，其initialize()函数如下：

status_t CameraClient::initialize(camera_module_t *module) {
    int callingPid = getCallingPid();
    status_t res;

    LOG1("CameraClient::initialize E (pid %d, id %d)", callingPid, mCameraId);

    // Verify ops permissions
    res = startCameraOps();
    if (res != OK) {
        return res;
    }

    char camera_device_name[10];
    snprintf(camera_device_name, sizeof(camera_device_name), "%d", mCameraId);

    mHardware = new CameraHardwareInterface(camera_device_name);
    res = mHardware->initialize(&module->common);
    if (res != OK) {
        ALOGE("%s: Camera %d: unable to initialize device: %s (%d)",
                __FUNCTION__, mCameraId, strerror(-res), res);
        mHardware.clear();
        return res;
    }

    mHardware->setCallbacks(notifyCallback,
            dataCallback,
            dataCallbackTimestamp,
            (void *)(uintptr_t)mCameraId);

    // Enable zoom, error, focus, and metadata messages by default
    enableMsgType(CAMERA_MSG_ERROR | CAMERA_MSG_ZOOM | CAMERA_MSG_FOCUS |
                  CAMERA_MSG_PREVIEW_METADATA | CAMERA_MSG_FOCUS_MOVE);

    LOG1("CameraClient::initialize X (pid %d, id %d)", callingPid, mCameraId);
    return OK;
}

上述函数中，主要注意以下流程：

加粗的代码CameraHardwareInterface新建了了一个Camera硬件接口，当然，camera_device_name为摄像头设备名；
mHardware->initialize(&module->common)调用底层硬件的初始化方法；
mHardware->setCallbacks将CamerService处的回调函数注册到HAL处。

CameraHardwareInterface定义了Camera的硬件抽象特征，由此进入到HAL。

四、HAL：CameraHardwareInterface

CameraHardwareInterface的作用在于链接Camera Server和V4L2，通过实现CameraHardwareInterface可以屏蔽不同的driver对Camera Server的影响。CameraHardwareInterface同样虚拟继承自RefBase。

class CameraHardwareInterface : public virtual RefBase {
public:
    CameraHardwareInterface(const char *name)
    {
        mDevice = 0;
        mName = name;
    }
    ……
}

CameraHardwareInterface中包含了控制通道和数据通道，控制通道用于处理预览和视频获取的开始/停止、拍摄照片、自动对焦等功能，数据通道通过回调函数来获得预览、视频录制、自动对焦等数据。当需要支持新的硬件时就需要继承于CameraHardwareInterface ，来实现对应的功能。CameraHardwareInterface提供的public方法如下：

在前一节中，initialize()函数调用了mHardware->initialize和mHardware->setCallbacks，下面来看下CameraHardwareInterface.h对其的实现。

status_t initialize(hw_module_t *module)
{
    ALOGI("Opening camera %s", mName.string());
    camera_module_t *cameraModule = reinterpret_cast<camera_module_t *>(module);
    camera_info info;
    status_t res = cameraModule->get_camera_info(atoi(mName.string()), &info);
    if (res != OK) return res;

    int rc = OK;
    if (module->module_api_version >= CAMERA_MODULE_API_VERSION_2_3 &&
        info.device_version > CAMERA_DEVICE_API_VERSION_1_0) {
        // Open higher version camera device as HAL1.0 device.
        rc = cameraModule->open_legacy(module, mName.string(),
                                           CAMERA_DEVICE_API_VERSION_1_0,
                                           (hw_device_t **)&mDevice);
    } else {
        rc = CameraService::filterOpenErrorCode(module->methods->open(
            module, mName.string(), (hw_device_t **)&mDevice));
    }
    if (rc != OK) {
        ALOGE("Could not open camera %s: %d", mName.string(), rc);
        return rc;
    }
    initHalPreviewWindow();
    return rc;
}

在initialize()方法中，通过cameraModule->open_legacy打开摄像头模组，initHalPreviewWindow()用于初始化Preview的相关流opspreview_stream_ops，初始化hal的预览窗口。

void initHalPreviewWindow()
{
    mHalPreviewWindow.nw.cancel_buffer = __cancel_buffer;
    mHalPreviewWindow.nw.lock_buffer = __lock_buffer;
    mHalPreviewWindow.nw.dequeue_buffer = __dequeue_buffer;
    mHalPreviewWindow.nw.enqueue_buffer = __enqueue_buffer;
    mHalPreviewWindow.nw.set_buffer_count = __set_buffer_count;
    mHalPreviewWindow.nw.set_buffers_geometry = __set_buffers_geometry;
    mHalPreviewWindow.nw.set_crop = __set_crop;
    mHalPreviewWindow.nw.set_timestamp = __set_timestamp;
    mHalPreviewWindow.nw.set_usage = __set_usage;
    mHalPreviewWindow.nw.set_swap_interval = __set_swap_interval;

    mHalPreviewWindow.nw.get_min_undequeued_buffer_count =
            __get_min_undequeued_buffer_count;
}

/** Set the notification and data callbacks */
void setCallbacks(notify_callback notify_cb,
                  data_callback data_cb,
                  data_callback_timestamp data_cb_timestamp,
                  void* user)
{
    mNotifyCb = notify_cb;
    mDataCb = data_cb;
    mDataCbTimestamp = data_cb_timestamp;
    mCbUser = user;

    ALOGV("%s(%s)", __FUNCTION__, mName.string());

    if (mDevice->ops->set_callbacks) {
        mDevice->ops->set_callbacks(mDevice,
                               __notify_cb,
                               __data_cb,
                               __data_cb_timestamp,
                               __get_memory,
                               this);
    }
}

set_callbacks中，notify_cb、data_cb、data_cb_timestamp和get_memory分别消息回调，数据回调，时间戳回调，以及内存相关操作的回调。

以上通过简略分析应用层调用Camera.open()之后在Framework、ART、Library以及HAL层的响应，来说明Android中Camera系统的整体架构，希望对读者能有一定的帮助，后续将在理解Camera整体架构的基础，探索更加高效的Preview方式，敬请期待！

Android线程管理（三）——Thread类的内部原理、休眠及唤醒

2016-05-03T10:15:54.938Z

线程通信、ActivityThread及Thread类是理解Android线程管理的关键。

线程，作为CPU调度资源的基本单位，在Android等针对嵌入式设备的操作系统中，有着非常重要和基础的作用。本小节主要从以下三个方面进行分析：

《Android线程管理（一）——线程通信》
《Android线程管理（二）——ActivityThread》
《Android线程管理（三）——Thread类的内部原理、休眠及唤醒》

三、Thread类的内部原理、休眠及唤醒

3.1 Thread类的内部原理

线程是CPU资源调度的基本单位，属于抽象范畴，Java通过Thread类完成线程管理。Thread类本质其实是“可执行代码”，其实现了Runnable接口，而Runnable接口唯一的方法就是run()。

1
2
3

public class Thread implements Runnable {
    ……
}

public interface Runnable {

    /**
     * Starts executing the active part of the class' code. This method is
     * called when a thread is started that has been created with a class which
     * implements {@code Runnable}.
     */
    public void run();
}

从注释可以看出，调用Thread的start()方法就是间接调用Runnable接口的run()方法。

public synchronized void start() {
    checkNotStarted();

    hasBeenStarted = true;

    VMThread.create(this, stackSize);
}

start()方法中VMThread.create(this, stackSize)是真正创建CPU线程的地方，换句话说，只有调用start()后的Thread才真正创建CPU线程，而新创建的线程中运行的就是Runnable接口的run()方法。

3.2 线程休眠及唤醒

线程通信、同步、协作是多线程编程中常见的问题。线程协作通常是采用线程休眠及唤醒来实现的，线程的休眠通过等待某个对象的锁（monitor）实现（wait()方法），当其他线程调用该对象的notify()方法时，该线程就被唤醒。该对象实现在线程间数据传递，多个线程通过该对象实现协作。

线程协作的经典例子是Java设计模式中的“生产者-消费者模式”，生产者不断往缓冲区写入数据，消费者从缓冲区中取出数据进行消费。在实现上，生产者与消费者分别继承Thread，缓冲区采用优先级队列PriorityQueue来模拟。生产者将数据放入缓冲区的前提是缓冲区有剩余空间，消费者从缓冲区中取出数据的前提是缓冲区中有数据，因此，这就涉及到生成者线程与消费者线程之间的协作。下面通过代码简要说明下。

public class TestWait {
    private int size = 5;
    private PriorityQueue<Integer> queue = new PriorityQueue<Integer>(size);

    public static void main(String[] args) {
        TestWait test = new TestWait();
        Producer producer = test.new Producer();
        Consumer consumer = test.new Consumer();

        producer.start();
        consumer.start();
    }

    class Consumer extends Thread {

        @Override
        public void run() {
            while (true) {
                synchronized (queue) {
                    while (queue.size() == 0) {
                        try {
                            System.out.println("队列空，等待数据");
                            queue.wait();
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                            queue.notify();
                        }
                    }
                    queue.poll(); // 每次移走队首元素
                       queue.notify();
                    System.out.println("从队列取走一个元素，队列剩余" + queue.size() + "个元素");
                }
            }
        }
    }

    class Producer extends Thread {

        @Override
        public void run() {
            while (true) {
                synchronized (queue) {
                    while (queue.size() == size) {
                        try {
                            System.out.println("队列满，等待有空余空间");
                            queue.wait();
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                            queue.notify();
                        }
                    }
                    queue.offer(1); // 每次插入一个元素
                       queue.notify();
                    System.out.println("向队列取中插入一个元素，队列剩余空间："
                            + (size - queue.size()));
                }
            }
        }
    }
}

这段代码在很多讲述生产者-消费者模式的地方都会用到，其中，Producer线程首先启动，synchronized关键字使其能够获得queue的锁，其他线程处于等待状态。初始queue为空，通过offer向缓冲区队列写入数据，notify()方法使得等待该缓冲区queue的线程（此处为消费者线程）唤醒，但该线程并不能马上获得queue的锁，只有等生产者线程不断向queue中写入数据直到queue.size() == size，此时缓冲队列充满，生产者线程调用wait()方法进入等待状态。此时，消费者线程处于唤醒并且获得queue的锁，通过poll()方法消费缓冲区中的数据，同理，虽然调用了notify()方法使得生产者线程被唤醒，但其并不能马上获得queue的锁，只有等消费者线程不断消费数据直到queue.size() == 0，消费者线程调用wait()方法进入等待状态，生产者线程重新获得queue的锁，循环上述过程，从而完成生产者线程与消费者线程的协作。

在Android的SystemServer中有多处用到了线程协作的方式，比如WindowManagerService的main()中通过runWithScissors()启动的BlockingRunnable与SystemServer所在线程的协作。WindowManagerService源码地址可参考：https://github.com/android/platform_frameworks_base/blob/master/services/core/java/com/android/server/wm/WindowManagerService.java

3.3 线程中断

在Java中“中断”线程是通过interrupt()方法来实现的，之所以加引号，是因为interrupt()并不中断正在运行的线程，只是向线程发送一个中断请求，具体行为依赖于线程的状态，在文档中有如下说明：

Posts an interrupt request to this Thread. The behavior depends on the state of this Thread:

Threads blocked in one of Object's wait() methods or one of Thread's join() or sleep() methods will be woken up, their interrupt status will be cleared, and they receive an InterruptedException. 
Threads blocked in an I/O operation of an java.nio.channels.InterruptibleChannel will have their interrupt status set and receive an java.nio.channels.ClosedByInterruptException. Also, the channel will be closed. 
Threads blocked in a java.nio.channels.Selector will have their interrupt status set and return immediately. They don't receive an exception in this case.

翻译下：

如果线程处于阻塞状态，即线程被Object.wait()、Thread.join()或 Thread.sleep()阻塞，调用interrupt()方法，将接收到InterruptedException异常，中断状态被清除，结束阻塞状态；
如果线程在进行I/O操作（java.nio.channels.InterruptibleChannel）时被阻塞，那么线程将收到java.nio.channels.ClosedByInterruptException异常，通道被关闭，结束阻塞状态；
如果线程被阻塞在java.nio.channels.Selector中，那么中断状态会被置位并返回，不会抛出异常。

public void interrupt() {
    // Interrupt this thread before running actions so that other
    // threads that observe the interrupt as a result of an action
    // will see that this thread is in the interrupted state.
    VMThread vmt = this.vmThread;
    if (vmt != null) {
        vmt.interrupt();
    }

    synchronized (interruptActions) {
        for (int i = interruptActions.size() - 1; i >= 0; i--) {
            interruptActions.get(i).run();
        }
    }
}

3.4 join()和sleep()方法

join()方法也可以理解为线程之间协作的一种方式，当两个线程需要顺序执行时，调用第一个线程的join()方法能使该线程阻塞，其依然通过wait()方法来实现的。

/**
 * Blocks the current Thread (<code>Thread.currentThread()</code>) until
 * the receiver finishes its execution and dies.
 *
 * @throws InterruptedException if <code>interrupt()</code> was called for
 *         the receiver while it was in the <code>join()</code> call
 * @see Object#notifyAll
 * @see java.lang.ThreadDeath
 */
public final void join() throws InterruptedException {
    VMThread t = vmThread;
    if (t == null) {
        return;
    }
    synchronized (t) {
        while (isAlive()) {
            t.wait();
        }
    }
}

另外，还有带时间参数的join()方法，在超出规定时间后，退出阻塞状态。同样的，其通过带时间参数的wait()方法实现而已。

1 2	public final void join(long millis) throws InterruptedException{} public final void join(long millis, int nanos) throws InterruptedException {}

sleep()与wait()的相同之处在于它们都是通过等待阻塞线程，不同之处在于sleep()等待的是时间，wait()等待的是对象的锁。

1
2
3

public static void sleep(long time) throws InterruptedException {
    Thread.sleep(time, 0);
}

1
2
3

public static void sleep(long millis, int nanos) throws InterruptedException {
    VMThread.sleep(millis, nanos);
}

3.5 CountDownLatch

CountDownLatch位于java.util.concurrent.CountDownLatch，实现倒数计数锁存器，当计数减至0时，触发特定的事件。在某些主线程需要等到子线程的应用很实用，以Google的zxing开源库中的一段代码为例进行说明：

final class DecodeThread extends Thread {

  ……
  private final CountDownLatch handlerInitLatch;

  DecodeThread(CaptureActivity activity,
               Collection<BarcodeFormat> decodeFormats,
               Map<DecodeHintType,?> baseHints,
               String characterSet,
               ResultPointCallback resultPointCallback) {

    this.activity = activity;
    handlerInitLatch = new CountDownLatch(1);

    ……
  }

  Handler getHandler() {
    try {
      handlerInitLatch.await();
    } catch (InterruptedException ie) {
      // continue?
    }
    return handler;
  }

  @Override
  public void run() {
    Looper.prepare();
    handler = new DecodeHandler(activity, hints);
    handlerInitLatch.countDown();
    Looper.loop();
  }
}

在上述例子中，首先在DecodeThread构造器中初始化CountDownLatch对象，并传入初始化参数1。其次，在run()方法中调用CountDownLatch对象的countDown()方法，这很好的保证了外部实例通过getHandler()方法获取handler时，handler不为null。

Android线程管理（二）——ActivityThread

2016-05-03T10:10:30.030Z

线程通信、ActivityThread及Thread类是理解Android线程管理的关键。

线程，作为CPU调度资源的基本单位，在Android等针对嵌入式设备的操作系统中，有着非常重要和基础的作用。本小节主要从以下三个方面进行分析：

《Android线程管理（一）——线程通信》
《Android线程管理（二）——ActivityThread》
《Android线程管理（三）——Thread类的内部原理、休眠及唤醒》

二、ActivityThread的主要工作及实现机制

ActivityThread是Android应用的主线程（UI线程），说起ActivityThread，不得不提到Activity的创建、启动过程以及ActivityManagerService，但本文将仅从线程管理的角度来分析ActivityThread。ActivityManagerService、ActivityStack、ApplicationThread等会在后续文章中详细分析，敬请期待喔~~不过为了说清楚ActivityThread的由来，还是需要简单介绍下。

以下引用自罗升阳大师的博客：《Android应用程序的Activity启动过程简要介绍和学习计划》

Step 1. 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口；
Step 2. ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要启动的Activity的相关信息；
Step 3. ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了；
Step 4. ApplicationThread不执行真正的启动操作，它通过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，看看是否需要创建新的进程来启动Activity；
Step 5. 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，因为新的Activity就在原来的Activity所在的进程中进行启动；
Step 6. ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，通知相应的进程执行启动Activity的操作；
Step 7. ApplicationThread把这个启动Activity的操作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。

大师的这段描述把ActivityManagerService、ActivityStack、ApplicationThread及ActivityThread的调用关系讲的很清楚，本文将从ActivityThread的main()方法开始分析其主要工作及实现机制。

ActivityThread源码来自：https://github.com/android/platform_frameworks_base/blob/master/core/java/android/app/ActivityThread.java

public static void main(String[] args) {
    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
    SamplingProfilerIntegration.start();

    // CloseGuard defaults to true and can be quite spammy.  We
    // disable it here, but selectively enable it later (via
    // StrictMode) on debug builds, but using DropBox, not logs.
    CloseGuard.setEnabled(false);

    Environment.initForCurrentUser();

    // Set the reporter for event logging in libcore
    EventLogger.setReporter(new EventLoggingReporter());

    AndroidKeyStoreProvider.install();

    // Make sure TrustedCertificateStore looks in the right place for CA certificates
    final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId());
    TrustedCertificateStore.setDefaultUserDirectory(configDir);

    Process.setArgV0("<pre-initialized>");

    Looper.prepareMainLooper();

    ActivityThread thread = new ActivityThread();
    thread.attach(false);

    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }

    if (false) {
        Looper.myLooper().setMessageLogging(new
                LogPrinter(Log.DEBUG, "ActivityThread"));
    }

    // End of event ActivityThreadMain.
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    Looper.loop();

    throw new RuntimeException("Main thread loop unexpectedly exited");
}

上述代码中，红色部分之前的代码主要用于环境初始化、AndroidKeyStoreProvider安装等，这里不做重点说明。红色部分的代码主要分为两个功能块：1）绑定应用进程到ActivityManagerService；2）主线程Handler消息处理。

关于线程通信机制，Handler、MessageQueue、Message及Looper四者的关系请参考上一篇文章《Android线程管理——线程通信》。

2.1 应用进程绑定

main()方法通过thread.attach(false)绑定应用进程。ActivityManagerNative通过getDefault()方法返回ActivityManagerService实例，ActivityManagerService通过attachApplication将ApplicationThread对象绑定到ActivityManagerService，而ApplicationThread作为Binder实现ActivityManagerService对应用进程的通信和控制。

private void attach(boolean system) {
        sCurrentActivityThread = this;
        mSystemThread = system;
        if (!system) {
            ……            RuntimeInit.setApplicationObject(mAppThread.asBinder());
            final IActivityManager mgr = ActivityManagerNative.getDefault();
            try {
                mgr.attachApplication(mAppThread);
            } catch (RemoteException ex) {
                // Ignore
            }
            ……        } else {
    ……
    }
}

在ActivityManagerService内部，attachApplication实际是通过调用attachApplicationLocked实现的，这里采用了synchronized关键字保证同步。

@Override
public final void attachApplication(IApplicationThread thread) {
    synchronized (this) {
        int callingPid = Binder.getCallingPid();
        final long origId = Binder.clearCallingIdentity();
        attachApplicationLocked(thread, callingPid);
        Binder.restoreCallingIdentity(origId);
    }
}

attachApplicationLocked的实现较为复杂，其主要功能分为两部分：

thread.bindApplication
mStackSupervisor.attachApplicationLocked(app)

private final boolean attachApplicationLocked(IApplicationThread thread,
            int pid) {

    // Find the application record that is being attached...  either via
    // the pid if we are running in multiple processes, or just pull the
    // next app record if we are emulating process with anonymous threads.
    ProcessRecord app;
    if (pid != MY_PID && pid >= 0) {
        synchronized (mPidsSelfLocked) {
            app = mPidsSelfLocked.get(pid);
        }
    } else {
        app = null;
    }
   // ……
    try {
       // ……
        thread.bindApplication(processName, appInfo, providers, app.instrumentationClass,
                profilerInfo, app.instrumentationArguments, app.instrumentationWatcher,
                app.instrumentationUiAutomationConnection, testMode, enableOpenGlTrace,
                enableTrackAllocation, isRestrictedBackupMode || !normalMode, app.persistent,
                new Configuration(mConfiguration), app.compat,
                getCommonServicesLocked(app.isolated),
                mCoreSettingsObserver.getCoreSettingsLocked());
        updateLruProcessLocked(app, false, null);
        app.lastRequestedGc = app.lastLowMemory = SystemClock.uptimeMillis();
    } catch (Exception e) {
        // todo: Yikes!  What should we do?  For now we will try to
        // start another process, but that could easily get us in
        // an infinite loop of restarting processes...
        Slog.wtf(TAG, "Exception thrown during bind of " + app, e);

        app.resetPackageList(mProcessStats);
        app.unlinkDeathRecipient();
        startProcessLocked(app, "bind fail", processName);
        return false;
    }

    // See if the top visible activity is waiting to run in this process...
    if (normalMode) {
        try {
            if (mStackSupervisor.attachApplicationLocked(app)) {
                didSomething = true;
            }
        } catch (Exception e) {
            Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
            badApp = true;
        }
    }
// ……
}

thread对象其实是ActivityThread里ApplicationThread对象在ActivityManagerService的代理对象，故此执行thread.bindApplication，最终会调用ApplicationThread的bindApplication方法。该bindApplication方法的实质是通过向ActivityThread的消息队列发送BIND_APPLICATION消息，消息的处理调用handleBindApplication方法，handleBindApplication方法比较重要的是会调用如下方法：

1	mInstrumentation.callApplicationOnCreate(app);

callApplicationOnCreate即调用应用程序Application的onCreate()方法，说明Application的onCreate()方法会比所有activity的onCreate()方法先调用。

mStackSupervisor为ActivityManagerService的成员变量，类型为ActivityStackSupervisor。

1 2	/** Run all ActivityStacks through this */ ActivityStackSupervisor mStackSupervisor;

从注释可以看出，mStackSupervisor为Activity堆栈管理辅助类实例。ActivityStackSupervisor的attachApplicationLocked()方法的调用了realStartActivityLocked()方法，在realStartActivityLocked()方法中，会调用scheduleLaunchActivity()方法：

final boolean realStartActivityLocked(ActivityRecord r,
        ProcessRecord app, boolean andResume, boolean checkConfig)
        throws RemoteException {
 
    //...  
    try {
        //...
        app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
                System.identityHashCode(r), r.info,
                new Configuration(mService.mConfiguration),
                r.compat, r.icicle, results, newIntents, !andResume,
                mService.isNextTransitionForward(), profileFile, profileFd,
                profileAutoStop);
 
        //...
 
    } catch (RemoteException e) {
        //...
    }
    //...    
    return true;
}

app.thread也是ApplicationThread对象在ActivityManagerService的一个代理对象，最终会调用ApplicationThread的scheduleLaunchActivity方法。

// we use token to identify this activity without having to send the
// activity itself back to the activity manager. (matters more with ipc)
@Override
public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
    ActivityInfo info, Configuration curConfig, Configuration overrideConfig,
    CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor,
    int procState, Bundle state, PersistableBundle persistentState,
    List<ResultInfo> pendingResults, List<ReferrerIntent> pendingNewIntents,
    boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) {

        updateProcessState(procState, false);

        ActivityClientRecord r = new ActivityClientRecord();

        ……
        sendMessage(H.LAUNCH_ACTIVITY, r);
}

同bindApplication()方法，最终是通过向ActivityThread的消息队列发送消息，在ActivityThread完成实际的LAUNCH_ACTIVITY的操作。

public void handleMessage(Message msg) {
    if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
    switch (msg.what) {
        case LAUNCH_ACTIVITY: {
            Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
            final ActivityClientRecord r = (ActivityClientRecord) msg.obj;

            r.packageInfo = getPackageInfoNoCheck(
                r.activityInfo.applicationInfo, r.compatInfo);
            handleLaunchActivity(r, null);
            Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
            } break;
    ……
}

handleLaunchActivity()用于启动Activity。具体的启动流程不在这里详述了，这里重点说明ApplicationThread及ActivityThread的线程通信机制。

2.2 主线程消息处理

在《Android线程管理——线程通信》中谈到了普通线程中Handler、MessageQueue、Message及Looper四者的关系，那么，ActivityThread中的线程通信又有什么不同呢？不同之处主要表现为两点：1）Looper的初始化方式；2）Handler生成。

首先，ActivityThread通过Looper.prepareMainLooper()初始化Looper，为了直观比较ActivityThread与普通线程初始化Looper的区别，把两种初始化方法放在一起：

/** Initialize the current thread as a looper.
  * This gives you a chance to create handlers that then reference
  * this looper, before actually starting the loop. Be sure to call
  * {@link #loop()} after calling this method, and end it by calling
  * {@link #quit()}.
  */
public static void prepare() {
    prepare(true);
}

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

/**
 * Initialize the current thread as a looper, marking it as an
 * application's main looper. The main looper for your application
 * is created by the Android environment, so you should never need
 * to call this function yourself.  See also: {@link #prepare()}
 */
public static void prepareMainLooper() {
    prepare(false);
    synchronized (Looper.class) {
        if (sMainLooper != null) {
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();
    }
}

普通线程的prepare()方法默认quitAllowed参数为true，表示允许退出，ActivityThread在prepareMainLooper()方法中调用prepare()方法，参数为false，表示主线程不允许退出。
普通线程只调用prepare()方法，ActivityThread在调用完prepare()方法之后，会通过myLooper()方法将本地线程的Looper对象的引用交给sMainLooper。myLooper()其实就是调用sThreadLocal的get()方法实现的。

/**
 * Return the Looper object associated with the current thread.  Returns
 * null if the calling thread is not associated with a Looper.
 */
public static Looper myLooper() {
    return sThreadLocal.get();
}

之所以要通过sMainLooper指向ActivityThread的Looper对象，就是希望通过getMainLooper()方法将主线程的Looper对象开放给其他线程。

/** Returns the application's main looper, which lives in the main thread of the application.
 */
public static Looper getMainLooper() {
    synchronized (Looper.class) {
        return sMainLooper;
    }
}

其次，ActivityThread与普通线程的Handler生成方式也不一样。普通线程生成一个与Looper绑定的Handler即可，ActivityThread通过sMainThreadHandler指向getHandler()的返回值，而getHandler()方法返回的其实是一个继承Handler的H对象。

private class H extends Handler {
    ……
}

final H mH = new H();

final Handler getHandler() {
    return mH;
}

真正实现消息机制“通”信的其实是Looper的loop()方法，loop()方法的核心实现如下：

/**
 * Run the message queue in this thread. Be sure to call
 * {@link #quit()} to end the loop.
 */
public static void loop() {
    final Looper me = myLooper();
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    final MessageQueue queue = me.mQueue;

    // Make sure the identity of this thread is that of the local process,
    // and keep track of what that identity token actually is.
    Binder.clearCallingIdentity();
    final long ident = Binder.clearCallingIdentity();

    for (;;) {
        Message msg = queue.next(); // might block
        if (msg == null) {
            // No message indicates that the message queue is quitting.
            return;
        }

        // This must be in a local variable, in case a UI event sets the logger
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }

        msg.target.dispatchMessage(msg);

        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }

        // Make sure that during the course of dispatching the
        // identity of the thread wasn't corrupted.
        final long newIdent = Binder.clearCallingIdentity();
        if (ident != newIdent) {
            Log.wtf(TAG, "Thread identity changed from 0x"
                    + Long.toHexString(ident) + " to 0x"
                    + Long.toHexString(newIdent) + " while dispatching to "
                    + msg.target.getClass().getName() + " "
                    + msg.callback + " what=" + msg.what);
        }

        msg.recycle();
    }
}

大致流程如下：

首先通过上述myLooper()方法获取Looper对象，取出Looper持有的MessageQueue；
然后从MessageQueue取出Message，如果Message为null，说明线程正在退出；
Message不为空，则调用Message的target handler对该Message进行分发，具体分发、处理流程可参考《Android线程管理——线程通信》；
消息处理完毕，调用recycle()方法进行回收。

Android开发笔记——ListView模块、缓存及性能

2016-05-03T10:01:08.855Z

ListView是Android开发中最常用的组件之一。本文将重点说明如何正确使用ListView，以及使用过程中可能遇到的问题。

ListView开发模块
图片缓存
可能遇到的问题

一、ListView开发模块

从项目实践的角度来看，ListView适合“自底向上”的开发模式，即从每个条目的显示组件，到对其进行控制的数据结构，最后通过Activity等进行使用。主要包括以下模块：

首先是item组件，即用于每项布局输出的xml文件。Android SDK中有simple_list_item_1、simple_list_item_2可用，当需要比较丰富的显示效果时，一般通过自定义xml实现。本文以论坛的格式进行说明，主要包括发帖人头像、用户名，帖子的标题、内容、最后回复时间、编辑、收藏、回复等内容，布局文件比较简单，这里截取其中一项显示，用以说明：

其次是父对象layout文件，即用于Activity或者Fragment的布局输出文件，一般在此输出文件中包含ListView。当然，如果采用ListFragment或ListActivity，并不需要再显示的定义ListView组件。本文中采用Fragment默认的输出文件，当然，也可以采用自定义的布局文件。

<ListView
    android:id="@+id/topic_list"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:cacheColorHint="@android:color/transparent"
    android:divider="@color/topic_divider_color"
    android:dividerHeight="1px"
    android:listSelector="@android:color/transparent" >
</ListView>

定义数据结构（容器），即用于持有单个Item的数据，可以是简单的String，也可以通过抽象Items所需字段组成一个类，抽象的原则是与Item中的组件对应。本文中上图涉及多个字段，因此通过抽象组件形成BBSTopicItem类。
列表适配器。决定每行Item中具体显示什么内容，以怎样的样式显示等，通常通过继承ArrayAdapter、SimpleAdapter等实现。本文定义BBSTopicAdapter，继承于ArrayAdapter。
最后，需要定义一个Activity或Fragment来使用上述模块。需要说明的是，ListView可以直接被ListActivity或者ListFragment使用。

以上五个模块就是使用ListView的基本逻辑框架，开发过程中，需要时刻理清它们之间的关系。

二、图片缓存及相关

在ListView中显示图片是比较常见的应用场景，但加载图片一般需要通过缓存来进行处理。由于虚拟机的heapsize默认为16M：

AndroidRuntime.cpp

int AndroidRuntime::startVM(JavaVM** pJavaVM, JNIEnv** pEnv) {
    ……
    property_get("dalvik.vm.heapsize", heapsizeOptsBuf+4, "16M");
    ……
}

（厂商一般会修改为32M，后面会说到这个数值）
在操作大尺寸图片时无法分配所需内存，就会引起OOM。因此，使用LruCache来缓存图片是常见的做法。但在其使用过程中，也需要注意一些问题，比如使用线程池下载图片，使用SD卡缓存，ListView滑动流畅性，图片显示错乱等，下面对这些问题进行说明。

1. 首先是LruCache，该类在android-support-v4的包中提供
主要算法原理是把最近使用的对象用强引用存储在LinkedHashMap中，并且把最近最少使用的对象在缓存值达到预设定值之前从内存中移除。

以前经常会使用一种非常流行的内存缓存技术的实现，即软引用或弱引用 (SoftReference or WeakReference)。但是现在已经不再推荐使用这种方式了，因为从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得不再可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并崩溃。

那么，怎样确定一个合适的缓存大小给LruCache呢？有以下多个因素应该放入考虑范围内，例如：

设备可以为每个应用程序分配多大的内存？
设备屏幕上一次最多能显示多少张图片？有多少图片需要进行预加载？
设备的屏幕大小和分辨率分别是多少？一个超高分辨率的设备（例如 Galaxy Nexus)比起一个较低分辨率的设备（例如 Nexus S），在持有相同数量图片的时候，需要更大的缓存空间。
图片的尺寸和大小，还有每张图片会占据多少内存空间？
图片被访问的频率有多高？是否有一些图片的访问频率比其它图片要高？如果有的话，应该让一些图片常驻在内存当中，或者使用多个LruCache 对象来区分不同组的图片。
是否能维持好数量和质量之间的平衡吗？有些时候，存储多个低像素的图片，而在后台去开线程加载高像素的图片会更加的有效。

并没有一个指定的缓存大小可以满足所有的应用程序，通常需要分析程序内存的使用情况，然后制定出一个合适的解决方案。缓存太小，有可能造成图片频繁地被释放和重新加载；而缓存太大，则有可能还是会引起 java.lang.OutOfMemory 异常。
不过，读者可能会在不同的地方遇到类似下面这段定义LruCache的代码：

public ImageDownLoader(Context context){
    int maxMemory = (int) Runtime.getRuntime().maxMemory();  
    int mCacheSize = maxMemory / 8;
    mMemoryCache = new LruCache<String, Bitmap>(mCacheSize){

        @Override
        protected int sizeOf(String key, Bitmap value) {
            return value.getRowBytes() * value.getHeight();
        }
    };
}

2. 使用线程池管理图片下载任务
线程池自然是为了限制系统中执行线程的数量，通常的一种比较低效的做法是为每一张图片下载开启一个新线程（new thread），线程的创建和销毁将造成极大的性能损耗，而对服务器来讲，维护过多的线程将造成内存消耗过大。总的来讲，使用线程池是执行此类任务的一个基本做法。Java中线程池的顶级接口是Executor，但是严格意义上讲Executor并不是一个线程池，而只是一个执行线程的工具，真正的线程池接口是ExecutorService。配置线程池是略显复杂，尤其是对于线程池的原理不是很清楚的情况下，很有可能配置的线程池不是最优的。在Executors类里提供了一些静态工厂，生成一些常用的线程池。

newSingleThreadExecutor创建一个单线程的线程池。这个线程池只有一个线程在工作，也就是相当于单线程串行执行所有任务。如果这个唯一的线程因为异常结束，那么会有一个新的线程来替代它。此线程池保证所有任务的执行顺序按照任务的提交顺序执行。
newFixedThreadPool 创建固定大小的线程池。每次提交一个任务就创建一个线程，直到线程达到线程池的最大大小。线程池的大小一旦达到最大值就会保持不变，如果某个线程因为执行异常而结束，那么线程池会补充一个新线程。
newCachedThreadPool 创建一个可缓存的线程池。如果线程池的大小超过了处理任务所需要的线程，
那么就会回收部分空闲（60秒不执行任务）的线程，当任务数增加时，此线程池又可以智能的添加新线程来处理任务。此线程池不会对线程池大小做限制，线程池大小完全依赖于操作系统（或者说JVM）能够创建的最大线程大小。
newScheduledThreadPool创建一个大小无限的线程池。此线程池支持定时以及周期性执行任务的需求。

通过下面的代码创建固定大小的线程池：

private ExecutorService getThreadPools(){
    if(mImageThreadPool == null){
        synchronized(ExecutorService.class){
            if(mImageThreadPool == null){
                mImageThreadPool = Executors.newFixedThreadPool(4);
            }
        }
    }
    return mImageThreadPool;
}

(本段代码来自互联网)

对于固定大小的线程池，关键是需要根据实际应用场景设置线程数量，既快速有效的执行下载任务，又不造成资源浪费。

3. SD卡存储配合LruCache
使用SD卡存储下载的图片有多方面的好处，提高图片加载速度（从本地加载肯定比网络要快）、节约用户流量等，因此，除了LruCache，一般还会将图片存储在本地SD卡。因此，加载图片的顺序应该是

　　a. 首先从LruCache中获取图片；
　　b. 如果a的返回值为null，则检查SD卡是否存在图片；
　　c. 如果a、b的返回值都为null，则通过网络进行下载。

　　用代码表述上述逻辑为：

Bitmap bitmap;
if (getBitmapFromMemCache(url) != null) {
    bitmap = getBitmapFromMemCache(url);
} else if (fileUtils.isFileExists(url) && fileUtils.getFileSize(url) != 0) {
    bitmap = fileUtils.getBitmapFromSD(url);
} else {
    bitmap = getBitmapFormUrl(url);
}
return bitmap;

Tip：如果通过HttpURLConnection下载图片，需要注意一个小问题，如果设置HttpURLConnection对象的DoOutput属性为true（con.setDoOutput(true)），在Android4.0以后，会解析为post请求，导致filenotfound异常（获取图片应该是get请求）。

4. ListView滑动停止下载
滑动时停止下载也是提高用户体验的方式之一，因为如果在ListView滑动过程中执行下载任务，将会使得ListView出现卡顿。监听滑动状态改变的方法是onScrollStateChanged(AbsListView view, int scrollState)，该方法在OnScrollListener接口中定义的，而OnScrollListener是AbsListView中为了在列表或网格滚动时执行回调函数而定义的接口。（强烈建议做ListView相关应用的读者熟悉一下AbsListView的源码）

为了实现下载任务与滑动状态的关联，在自定义列表适配器中实现了OnScrollListener接口，在onScrollStateChanged方法中根据scrollState执行相应的下载任务操作。

@Override
public void onScrollStateChanged(AbsListView view, int scrollState) {
    this.scrollState = scrollState;
    if (scrollState == AbsListView.OnScrollListener.SCROLL_STATE_IDLE) {
        showImage(mFirstVisibleItem, mVisibleItemCount);
    } else {
        cancelTask();
    }
}

（本段代码来自互联网）

5. 图片显示错乱
这是一个比较老生常谈的问题，在百度搜索一下“listview图片错位”会见到一大片帖子在讨论这个问题，这里不再赘述，推荐几个比较靠谱链接：

http://www.cnblogs.com/lesliefang/p/3619223.html
http://www.trinea.cn/android/android-listview-display-error-image-when-scroll/
http://blog.csdn.net/shineflowers/article/details/41744477

总的来讲，图片缓存是Android开发中比较有意思的一个话题，常用的图片缓存开源库有ImageLoader、Picasso、Glide等，最近由Facebook开源了Fresco（http://www.fresco-cn.org/），根据介绍，它能够从网络、本地存储和本地资源中加载图片。同时，为了节省数据和CPU，它拥有三级缓存。此外，Fresco在显示方面是用了Drawees，可以显示占位符，直到图片加载完成。而当图片从屏幕上消失时，会自动释放图片所占的内存。这里推荐一个关于Android三大图片缓存原理、特性对比的链接：

http://www.csdn.net/article/2015-10-21/2825984#rd

三、可能遇到的问题

1. notifyDataSetChanged与局部更新
首先举一个栗子：QQ空间或者朋友圈的点赞功能，点赞之后页面会马上刷新，但不会影响本条目以外的其他条目的显示。换句话说，它使用了局部更新，而非notifyDataSetChanged。在了解notifyDataSetChanged与局部更新区别时，需要先对以下问题作出解释：

notifyDataSetChanged如何刷新界面？
什么场景需要使用notifyDataSetChanged？什么场景需要使用局部更新？
局部更新如何实现？

回到代码中，notifyDataSetChanged是在BaseAdapter中定义的，首先初始了一个DataSetObservable类的final实例mDataSetObservable：

1	private final DataSetObservable mDataSetObservable = new DataSetObservable();

notifyDataSetChanged就是通过操作mDataSetObservable实现的，DataSetObservable是观察者模式的一个实现（Android源码中有很多类似设计模式的实现）。

public void registerDataSetObserver(DataSetObserver observer) {
    mDataSetObservable.registerObserver(observer);
}

public void unregisterDataSetObserver(DataSetObserver observer) {
    mDataSetObservable.unregisterObserver(observer);
}

public void notifyDataSetChanged() {
    mDataSetObservable.notifyChanged();
}

public void notifyDataSetInvalidated() {
    mDataSetObservable.notifyInvalidated();
}

notifyDataSetChanged调用了notifyChanged方法，回到DataSetObservable中：

public void notifyChanged() {
    synchronized(mObservers) {
        // since onChanged() is implemented by the app, it could do anything, including
        // removing itself from {@link mObservers} - and that could cause problems if
        // an iterator is used on the ArrayList {@link mObservers}.
        // to avoid such problems, just march thru the list in the reverse order.
        for (int i = mObservers.size() - 1; i >= 0; i--) {
            mObservers.get(i).onChanged();
        }
    }
}

public void notifyInvalidated() {
    synchronized (mObservers) {
        for (int i = mObservers.size() - 1; i >= 0; i--) {
            mObservers.get(i).onInvalidated();
        }
    }
}

notifyChanged也只是调用了其绑定的接口，并没有具体的实现，那么这个接口是什么时候绑定的呢？回忆ListView与adapter的关联是何时开始的呢？setAdapter！是的，从setAdapter的代码中可以看到这种关联。

@Override
public void setAdapter(ListAdapter adapter) {
    if (mAdapter != null && mDataSetObserver != null) {
        mAdapter.unregisterDataSetObserver(mDataSetObserver);
    }

    resetList();
    mRecycler.clear();

    if (mHeaderViewInfos.size() > 0|| mFooterViewInfos.size() > 0) {
        mAdapter = new HeaderViewListAdapter(mHeaderViewInfos, mFooterViewInfos, adapter);
    } else {
        mAdapter = adapter;
    }

    mOldSelectedPosition = INVALID_POSITION;
    mOldSelectedRowId = INVALID_ROW_ID;

    // AbsListView#setAdapter will update choice mode states.
    super.setAdapter(adapter);

    if (mAdapter != null) {
        mAreAllItemsSelectable = mAdapter.areAllItemsEnabled();
        mOldItemCount = mItemCount;
        mItemCount = mAdapter.getCount();
        checkFocus();
        // 原来是在这里绑定了数据改变的观察者对象
        mDataSetObserver = new AdapterDataSetObserver();
        mAdapter.registerDataSetObserver(mDataSetObserver);

        mRecycler.setViewTypeCount(mAdapter.getViewTypeCount());

        int position;
        if (mStackFromBottom) {
            position = lookForSelectablePosition(mItemCount - 1, false);
        } else {
            position = lookForSelectablePosition(0, true);
        }
        setSelectedPositionInt(position);
        setNextSelectedPositionInt(position);

        if (mItemCount == 0) {
            // Nothing selected
            checkSelectionChanged();
        }
    } else {
        mAreAllItemsSelectable = true;
        checkFocus();
        // Nothing selected
        checkSelectionChanged();
    }

    requestLayout();
}

前面提到，观察者对象调用的onChanged方法，可以确定，上述绑定的AdapterDataSetObserver中必然有onChanged方法的实现。

public void onChanged() { 
    mDataChanged = true;
    mOldItemCount = mItemCount;
    mItemCount = getAdapter().getCount();

    if ((getAdapter().hasStableIds()) && 
        (mInstanceState != null) && 
        (mOldItemCount == 0) && 
        (mItemCount > 0)) {
        onRestoreInstanceState(mInstanceState);
        mInstanceState = null;
    } else {
        rememberSyncState();
    }
    checkFocus();
    requestLayout();
}

很明显，在onChanged的末尾调用了requestLayout方法，而requestLayout方法是用来绘制界面的，定义在View中。

public void requestLayout() {
    if (mMeasureCache != null) mMeasureCache.clear();

    if (mAttachInfo != null && mAttachInfo.mViewRequestingLayout == null) {
        // Only trigger request-during-layout logic if this is the view requesting it,
        // not the views in its parent hierarchy
        ViewRootImpl viewRoot = getViewRootImpl();
        if (viewRoot != null && viewRoot.isInLayout()) {
            if (!viewRoot.requestLayoutDuringLayout(this)) {
                return;
            }
        }
        mAttachInfo.mViewRequestingLayout = this;
    }

    mPrivateFlags |= PFLAG_FORCE_LAYOUT;
    mPrivateFlags |= PFLAG_INVALIDATED;

    if (mParent != null && !mParent.isLayoutRequested()) {
        mParent.requestLayout();
    }
    if (mAttachInfo != null && mAttachInfo.mViewRequestingLayout == this) {
        mAttachInfo.mViewRequestingLayout = null;
    }
}

根据上述解释，会发现notifyDataSetChanged会通知View刷新所有与其绑定的数据列表，而某些局部操作明显不需要全部刷新，全局刷新会造成极大的资源浪费。在这种情况下，就需要进行局部更新。

局部更新的实现定义在是适配器（adapter）中，根据指定的index（即item在listview中的位置），实现指定条目内容的更新：

/** 
 * 局部刷新
 * @param index item在listview中的位置 
 */  
public void updateItem(int index) {  
    if (listView == null) {  
        return;  
    }
    // 停止滑动时才更新界面
    if (scrollState == AbsListView.OnScrollListener.SCROLL_STATE_IDLE) {
        // 指定更新的位置在可见范围之内
        if (index >= listView.getFirstVisiblePosition() && 
            index <= listView.getLastVisiblePosition()) {
            // 获取当前可以看到的item位置  
            int visiblePosition = listView.getFirstVisiblePosition();
            View view = listView.getChildAt(index - visiblePosition); 
            //在这里对view中的组件进行设置，数据可以通过getItem(index)获取//
        }
    }
}

（一个小问题：ListView的getCount()与getChildCount()有什么差别呢？）

使用notifyDataSetChanged时，一个常见的问题就是调用了notifyDataSetChanged，但界面并没有刷新。很常见的原因是list的指向改变了，换句话说，list指向了与初始化时不同的堆地址。这种情况比较常见，给一个说明的链接：http://www.tuicool.com/articles/aiiYzeR。

一般的经验是在声明变量时对list进行初始化，当涉及数据改变时，通过add或者remove实现。

2. listview的item内部组件的事件响应
在具体的工程中，item组件的响应会根据对其使用的Activity（Fragment）的不同而变化，因此，不宜在其内部设定响应事件的具体实现。推荐在adapter中定义接口，将接口暴露给具体的Activity（Fragment），Activity（Fragment）根据具体的业务逻辑进行配置。以前面提到的论坛帖子为例，其包含以下操作：

/**
 * 处理Item中控件的点击事件接口
 */
public interface ITopicItemOperation {
    public void topicItemEdit(BBSTopicItem item);
    public void topicItemCollect(BBSTopicItem item);
    public void topicItemReply(BBSTopicItem item);
}

然后，在Activity（Fragment）中实现上述接口：

/**
 * 编辑主题贴
 */
@Override
public void topicItemEdit(BBSTopicItem item) {
    // 业务逻辑
}

/**
 * 收藏主题贴
 */
@Override
public void topicItemCollect(BBSTopicItem item) {
    // 业务逻辑
}

/**
 * 回复主题帖
 */
@Override
public void topicItemReply(BBSTopicItem item) {
    // 业务逻辑
}

将该实现通过adapter的构造器进行传递，以响应点击事件为例：

/**
 * 处理ListView中控件的点击事件
 */
private class TopicItemOnClickListener implements OnClickListener {

    private BBSTopicItem item;
        
    public TopicItemOnClickListener(BBSTopicItem item) {
        this.item = item;
    }
        
    @Override
    public void onClick(View v) {
        switch (v.getId()) {
        case R.id.bbs_topic_edit:
            topicItemOperation.topicItemEdit(item);
            break;
        case R.id.bbs_topic_collect:
            topicItemOperation.topicItemCollect(item);
            break;
        case R.id.bbs_topic_reply:
            topicItemOperation.topicItemReply(item);
            break;
        }
    }
}

在点击按钮时，添加TopicItemOnClickListener对象，即可实现不同的Activity（Fragment）对该项功能的复用。

3.图文混合显示
在涉及论坛帖子的时候，图文混合显示一种很常见的场景。Android中没有原生支持图文混合显示的控件，github上有一些自定义控件能实现这种需求，百度一下也能发现很多。但此类个性化的需求需要很据项目实际来灵活运用，这里描述一种通过正则来处理的方法。比如，服务端返回的帖子内容如下：

“全新宝马7系上市了，是不是很有气势？ http://img2.tuohuangzu.com/THZ/UserBlog/0/15/2015061810510550085.jpg 不过相比于7系，我还是更喜欢3系的操控，转向非常精确，而且过弯姿势的建立也是非常恰到好处，过弯姿势建立的过早过晚都不好。过早会导致操控措手不及，无法感觉方向打多少，在匝道，有时打多了要在回，回多了又要打。过晚会导致路感缺失，侧倾明显，虚的慌 http://res3.auto.ifeng.com/s/6606/0/3/13309355849880_3.jpghttp://img1.cheshi-img.com/product/1_1024/887/4b25a8df6e8ec.jpg 明天天气不错，去自驾游如何？”

帖子内容为纯文本格式，显示时需要从中提取出图片的链接。这时正则就派上用场了：

Pattern p = Pattern.compile("http://[^\\u4e00-\\u9fa5]*?[.]jpg");
Matcher m = p.matcher(text);
            
int lastTextIndex = 0;
while (m.find()) {
    // 设置文本显示
    String textFrag = text.substring(lastTextIndex, m.start());
    if (!textFrag.isEmpty()) {
        layout.addView(getTextView(context, textFrag));
    }
    // 更新最后文本下标
    lastTextIndex = m.end();
                
    // 设置图片显示
    String imageUrl = m.group();
    ImageView imageView = getImageView(context);
    setImageViewDisplay(imageView, imageUrl);
    layout.addView(imageView);
}
if (lastTextIndex < text.length()) {
    String textFrag = text.substring(lastTextIndex, text.length());
    layout.addView(getTextView(context, textFrag));
}

这段代码比较简单，只有一处需要说明。在上述帖子内容汇总，后面两张图片的链接是连续的，当正则表达式中包含能接受重复的限定符时，通常的行为是（在使整个表达式能得到匹配的前提下）匹配尽可能多的字符。以这个表达式为例：a.*b，它将会匹配最长的以a开始，以b结束的字符串。如果用它来搜索aabab的话，它会匹配整个字符串aabab。这被称为贪婪匹配。有时，我们更需要懒惰匹配，也就是匹配尽可能少的字符。前面给出的限定符都可以被转化为懒惰匹配模式，只要在它后面加上一个问号?。这样.*?就意味着匹配任意数量的重复，但是在能使整个匹配成功的前提下使用最少的重复。因此，在上述场景中，想要将连续的两个URL匹配成功，则需要进行懒惰匹配。

4.ScrollView与ListView的冲突
如果在ScrollView中嵌套了ListView（原则上应尽量避免这种情况），那么很不幸，可能会遇到以下问题：

ListView只显示一行
页面默认不从顶端开始显示
ListView滑动事件无法监听

这几个问题都是比较常见的问题了，这里不再赘述其原理，给出比较通用的解决方案：

listview需要手动设置高度，这里给出一个链接：http://www.cnblogs.com/zhwl/p/3333585.html
listview需要设置listview.setFocusable(false);
重载listview的onInterceptTouchEvent方法，在ACTION_DOWN时通过ScrollView的requestDisallowInterceptTouchEvent方法设置交出ontouch权限，ACTION_CANCEL时再恢复ontouch权限。

再次强调，应尽量避免ScrollView中嵌套了ListView。

Android开发笔记——视频录制播放常见问题

2016-05-03T10:00:44.773Z

本文分享自己在视频录制播放过程中遇到的一些问题，主要包括：

视频录制流程
视频预览及SurfaceHolder
视频清晰度及文件大小
视频文件旋转

一、视频录制流程

以微信为例，其录制触发为按下（住）录制按钮，结束录制的触发条件为松开录制按钮或录制时间结束，其流程大概可以用下图来描述。

1.1、开始录制

初始化过程主要包括View，Data以及Listener三部分。在初始化View时，添加摄像头预览，添加倒计时文本组件，设置初始状态UI组件的可见；初始化Data时，从Intent中获取初始数据；初始化Listener时，分别对录制触发按钮，保存/取消视频录制按钮以及视频预览界面添加监听。
当系统初始化成功后，等待用户按下录制按钮，因此在录制按钮的监听中，需要完成以下功能：录制，计时，更新界面组件。

if(isRecording) {
    mMediaRecorder.stop();
    releaseMediaRecorder();
    mCamera.lock();
    isRecording = false;
}
if(startRecordVideo()) {
    startTimeVideoRecord();
    isRecording = true;
}

首先判断当前录制状态，如果正在录制，则先停止录制，释放MediaRecorder资源，锁定摄像头，置位录制状态；然后开始视频录制startRecordVideo，其boolean型返回值表征是否启动成功，启动成功后，开始视频录制计时，并且置位录制状态。startRecordVideo涉及MediaRecorder的配置，准备以及启动。

翻译成代码如下：

private boolean startRecordVideo() {
    configureMediaRecorder();
    if(!prepareConfiguredMediaRecorder()) {
        return false;
    }
    mMediaRecorder.start();
    return true;
}

1.2、结束录制

根据上述流程图可知，结束录制的触发条件为松开录制按钮或计时时间到。在结束录制方法中，需要释放MediaRecorder，开始循环播放已录制视频，设置界面更新等。

翻译成代码如下：

private void stopRecordVideo() {

    releaseMediaRecorder();
    // 录制视频文件处理
    if(currentRecordProgress < MIN_RECORD_TIME) {
        Toast.makeText(VideoInputActivity.this, "录制时间太短", Toast.LENGTH_SHORT).show();
    } else {
        startVideoPlay();
        isPlaying = true;
        setUiDisplayAfterVideoRecordFinish();
    }
    currentRecordProgress = 0;
    updateProgressBar(currentRecordProgress);
    releaseTimer();
    // 状态设置
    isRecording = false;
}

二、视频预览及SurfaceHolder

视频预览采用SurfaceView，相比于普通的View，SurfaceView在一个新起的单独线程中绘制画面，该实现的优点是更新画面不会阻塞UI主线程，缺点是会带来事件同步的问题。当然，这涉及到UI事件的传递以及线程同步，这里不做详细说明，有兴趣的可以参考链接：http://wugengxin.cn/download/pdf/android/PRE_andevcon_mastering-the-android-touch-system.pdf。
在实现中，通过继承SurfaceView组件来实现自定义预览控件。首先，SurfaceView的getHolder()方法会返回SurfaceHolder，需要为SurfaceHolder添加SurfaceHolder.Callback回调；其次，重写surfaceCreated、surfaceChanged和surfaceDestroyed实现。

2.1、构造器

构造器包含了初始化域以及添加上述回调的过程。

public CameraPreview(Context context, Camera camera) {
    super(context);

    mCamera = camera;
    mSupportedPreviewSizes = mCamera.getParameters().getSupportedPreviewSizes();
    mHolder = getHolder();
    mHolder.addCallback(this);
    mHolder.setType(SurfaceHolder.SURFACE_TYPE_PUSH_BUFFERS);
}

这里需要说明mSupportedPreviewSizes，由于摄像头支持的预览尺寸由Camera本身的参数决定，因此需要首先获取其所支持的预览尺寸。

2.2、预览尺寸的设置

从Google官方的Camera示例程序中可以看出，选择预览尺寸的标准是（1）摄像头支持的预览尺寸的宽高比与SurfaceView的宽高比的绝对差值小于0.1；（2）在（1）获得的尺寸中，选取与SurfaceView的高的差值最小的。通过代码对这两个标准进行了实现，这里贴一下官方的代码：

public Camera.Size getOptimalPreviewSize(List<Camera.Size> sizes, int w, int h) {
    final double ASPECT_TOLERANCE = 0.1;
    double targetRatio = (double) w / h;
    if (sizes == null) {
        return null;
    }
    Camera.Size optimalSize = null;
    double minDiff = Double.MAX_VALUE;
    int targetHeight = h;
    for (Camera.Size size : sizes) {
        double ratio = (double) size.width / size.height;
        if (Math.abs(ratio - targetRatio) > ASPECT_TOLERANCE)
            continue;
        if (Math.abs(size.height - targetHeight) < minDiff) {
            optimalSize = size;
            minDiff = Math.abs(size.height - targetHeight);
        }
    }
    if (optimalSize == null) {
        minDiff = Double.MAX_VALUE;
        for (Camera.Size size : sizes) {
            if (Math.abs(size.height - targetHeight) < minDiff) {
                optimalSize = size;
                minDiff = Math.abs(size.height - targetHeight);
            }
        }
    }
    return optimalSize;
}

在加载预览画面时，需要考虑Camera支持的尺寸（getSupportedPreviewSizes）和加载预览画面的SurfaceView的尺寸（layout_width/layout_height），在预览阶段，两者之间的关系直接影响清晰度及图像拉伸。对于Camera的尺寸，由于设备的硬件差异，不同设备支持的尺寸存在差异，但在默认情况（orientation=landscape）下，其width>height。以HTC609d为例，Camera支持的分辨率为1280720（16：9）……640480（4：3）……480320（3：2）等十多种，而其屏幕的分辨率为960540（16：9）。因此，很容易得到以下结论：（1）当Camera预览尺寸小于SurfaceView尺寸较多时，预览画面就不清晰；（2）Camera预览尺寸宽高比与SurfaceView宽高比相差较大时，预览画面就会拉伸。
上述代码在手机设置为横屏时并没有问题，在设置为竖屏时，为获得最优的预览尺寸，需要在调用此方法前比较SurfaceView的宽高。

if (mSupportedPreviewSizes != null) {
    mPreviewSize = getOptimalPreviewSize(mSupportedPreviewSizes, 
                        Math.max(width, height), Math.min(width, height));
}

获得与当前SurfaceView匹配的预览尺寸后，即可通过Camera.Parameters进行设置。

Camera.Parameters mParams = mCamera.getParameters();
mParams.setPreviewSize(mPreviewSize.width, mPreviewSize.height);
mCamera.setDisplayOrientation(90);

List<String> focusModes = mParams.getSupportedFocusModes();
if(focusModes.contains("continuous-video")){
    mParams.setFocusMode(Camera.Parameters.FOCUS_MODE_CONTINUOUS_VIDEO);
}
mCamera.setParameters(mParams);

三、视频清晰度及文件大小

在第一节中讲到startRecordVideo，包括配置MediaRecorder，准备MediaRecorder以及启动，其中配置MediaRecorder是视频录制的重点，需要了解每项配置参数的作用，根据业务场景灵活配置。这里参考Google官方的示例给出一个可行的配置方案，然后再对其进行解释。

private void configureMediaRecorder() {
    // BEGIN_INCLUDE (configure_media_recorder)
    mMediaRecorder = new MediaRecorder();

    // Step 1: Unlock and set camera to MediaRecorder
    mCamera.unlock();
    mMediaRecorder.setCamera(mCamera);
    mMediaRecorder.setOrientationHint(90);

    // Step 2: Set sources
    mMediaRecorder.setAudioSource(MediaRecorder.AudioSource.VOICE_RECOGNITION);
    mMediaRecorder.setVideoSource(MediaRecorder.VideoSource.CAMERA);

    // Step 3: Set a Camera Parameters
    mMediaRecorder.setOutputFormat(MediaRecorder.OutputFormat.MPEG_4);
    /* Fixed video Size: 640 * 480*/
    mMediaRecorder.setVideoSize(640, 480);
    /* Encoding bit rate: 1 * 1024 * 1024*/
    mMediaRecorder.setVideoEncodingBitRate(1 * 1024 * 1024);
    mMediaRecorder.setVideoEncoder(MediaRecorder.VideoEncoder.H264);
    mMediaRecorder.setAudioEncoder(MediaRecorder.AudioEncoder.AAC);

    // Step 4: Set output file
    mMediaRecorder.setMaxFileSize(maxFileSizeInBytes);
    mMediaRecorder.setOutputFile(videoFilePath);
    // END_INCLUDE (configure_media_recorder)

    // Set MediaRecorder ErrorListener
    mMediaRecorder.setOnErrorListener(this);
}

Step 1：
setCamera参数能够使得在预览和录制中快速切换，避免Camera对象的重新加载。在某些Android手机自带的照相机程序中，切换预览与录制中的短暂卡顿，读者可自行体会。
mMediaRecorder.setOrientationHint(90)在录制方向为竖直（portrait）时使用，它能使视频文件的沿顺时针方向旋转90度，如果不设置此项，播放视频时，画面会发生90度的旋转。不过这里更重要的是，即使设置了此项，在某些播放器上，画面依然会有90度的旋转（比如将在手机上正常播放的视频导入到PC中进行播放，或者嵌入H5的video标签中），这可是为什么呢？注意setOrientationHint的说明：Note that some video players may choose to ignore the compostion matrix in a video during playback. 那么如何做到在所有播放器上都能以正常方向播放呢？稍等，后续专门对其进行说明。
Step 2：
setAudioSource(MediaRecorder.AudioSource.VOICE_RECOGNITION)，VOICE_RECOGNITION相比于MIC会根据语音识别的需要做一些调谐，当然，这需要在系统支持的情况下。
setVideoSource自然是VideoSource.CAMERA，只是在此两项设置必须在设置编码器之前设置，这无需说明。
Step 3：
setOutputFormat需要在Step 2之后，并且在prepare()之前。这里采用OutputFormat.MPEG_4格式。
setVideoSize需要权衡的因素较多，主要包括三方面：MediaRecorder支持的录制尺寸、视频文件的大小以及兼容不同Android机型。这里采用640 480（微信小视频的尺寸是320240），文件大小在500-1000kb之间，并且市面上99%以上机型支持此录制尺寸。
setVideoEncodingBitRate与视频的清晰度有关，设置此参数需要权衡清晰度与文件大小的关系。太高，文件大不易传输；太低，文件清晰度低，识别率低。需要根据实际业务场景灵活调整。
setVideoEncoder采用H264编码，MPEG4、H263、H264等不同编码的差别比较可参考http://blog.csdn.net/wcl0715/article/details/676137，实际使用中，H264的压缩率较高，推荐使用。
setAudioEncoder采用AudioEncoder.AAC，该设置主要是考虑其通用性、兼容性。
Step 4：
setMaxFileSize指定录制文件的大小限制，当然还可以限制其最大录制时间。
setOutputFile指定输出视频的路径。
setOnErrorListener指定错误监听器。

在完成上述配置之后，即可准备MediaRecorder，并在返回成功后开始视频录制。

private boolean prepareConfiguredMediaRecorder() {
    // Step 5: Prepare configured MediaRecorder
    try {
        mMediaRecorder.prepare();
    } catch (Exception e) {
        releaseMediaRecorder();
        return false;
    }
    return true;
}

四、视频文件旋转

第三节中Step 1提到对视频文件的旋转，因为某些播放器会忽略录制视频时的配置参数，因此可尝试通过第三方库对视频文件进行旋转，例如：OpenCV，fastCV等，在Camera对象的Camera.PreviewCallback中截取每帧数据byte[] data，然后对其进行处理，然后输出。该方法需要考虑处理方法的高效性，在编程时一般采用NDK，在C++中完成关键的处理，这里贴出fastCV中该处理方法的逻辑。

public void onPreviewFrame( byte[] data, Camera c ) {
    // Increment FPS counter for camera.
    util.cameraFrameTick();
    
    // Perform processing on the camera preview data.
    update( data, mDesiredWidth, mDesiredHeight );
    
    // Simple IIR filter on time.
    mProcessTime = util.getFastCVProcessTime();
    
    if( c != null ) {
        // with buffer requires addbuffer each callback frame.
        c.addCallbackBuffer( mPreviewBuffer );
        c.setPreviewCallbackWithBuffer( this );
    }
    
    // Mark dirty for render.
    requestRender();
}

其中，update为native方法，其实现由jni中对应的文件完成，其中调用了libfastcv.a中相应的API。这里涉及NDK编程的基本方法步骤：（1）开发环境；（2）编写Java代码、C/C++代码；（3）编译C/C++文件生成.so库；（4）重新编译工程，生成apk。由于本章不重点讲述NDK，这里不再展开。
除上述方法以外，笔者采用了另外一种思路进行了探索，上述方法处理的数据为每帧图像数据，可以理解为在线处理，而如果在录制完成之后再处理，可以理解为离线处理。这里采用了第三方库mp4parser，mp4parser是一款支持在Android中进行视频分割的库，这里通过其进行视频旋转。至于具体效果如何，读者有兴趣可自行尝试，这里留个悬念。

private boolean rotateVideoFileWithClockwiseDegree(String sourceFilePath, int degree) {
    if(!isFileAndDegreeValid(sourceFilePath, degree)) {
        return false;
    }
    rotateVideoFile(sourceFilePath, degree);
    return true;
}

对输入参数进行合法性检测之后，根据检测结果判断是否进行旋转。

private boolean isFileAndDegreeValid(String sourceFilePath, int degree) {
    if(sourceFilePath == null || (!sourceFilePath.endsWith(".mp4")) 
                              || (!new File(sourceFilePath).exists())) {
        return false;
    }
    if (degree == 0 || (degree % 90 != 0)) {
        return false;
    }
    return true;
}

private void rotateVideoFile(String sourceFilePath, int degree) {
    List<TrackBox> trackBoxes = getTrackBoxesOfVideoFileByPath(sourceFilePath);
    Movie rotatedMovie = getRotatedMovieOfTrackBox(trackBoxes);
    writeMovieToModifiedFile(rotatedMovie);
}

通过mp4parser旋转视频主要分为三步：（1）获取视频文件对应的TrackBoxes；（2）根据TrackBoxes获取旋转后的Movie对象；（3）将Movie对象写入文件。

private List<TrackBox> getTrackBoxesOfVideoFileByPath(String sourceFilePath) {
    IsoFile isoFile = null;
    List<TrackBox> trackBoxes = null;
    try {
        isoFile = new IsoFile(sourceFilePath);
        trackBoxes = isoFile.getMovieBox().getBoxes(TrackBox.class);
        isoFile.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
    return trackBoxes;
}

private Movie getRotatedMovieOfTrackBox(List<TrackBox> trackBoxes) {
    Movie rotatedMovie = new Movie();
    // 旋转
    for (TrackBox trackBox : trackBoxes) {
        trackBox.getTrackHeaderBox().setMatrix(Matrix.ROTATE_90);
        rotatedMovie.addTrack(new Mp4TrackImpl(trackBox));
    }
    return rotatedMovie;
}

private void writeMovieToModifiedFile(Movie movie) {
    Container container = new DefaultMp4Builder().build(movie);
    File modifiedVideoFile = new File(videoFilePath.replace(".mp4", "_MOD.mp4"));
    FileOutputStream fos;
    try {
        fos = new FileOutputStream(modifiedVideoFile);
        WritableByteChannel bb = Channels.newChannel(fos);
        container.writeContainer(bb);
        // 关闭文件流
        fos.close();
    } catch (Exception e) {
        e.printStackTrace();
    } 
}

本文对Android视频录制中常见的问题进行了说明，转载请注明出处（虽然也没什么转载）。

Android开发笔记——以Volley图片加载、缓存、请求及展示为例理解Volley架构设计

2016-05-03T10:00:09.815Z

Volley是由Google开源的、用于Android平台上的网络通信库。Volley通过优化Android的网络请求流程，形成了以Request-RequestQueue-Response为主线的网络访问链，使得Android网络访问变得简单、高效、扩展性强。（根据RTFSC原则，强烈建议Android的童鞋学习下Volley的架构设计）下面将以ImageLoader、ImageCache、ImageRequest及NetworkImageView为例，对此进行说明。

一、ImageCache-ImageLoader-ImageListener

对于图片的下载，这里采用自底向上的分析方法，即首先明确Volley加载图片是通过ImageLoader的get方法实现的，然后依次说明该方法需要的参数的构成。get方法有三种重载形式（早一些的版本没有第三种）：

1
2
3

public ImageContainer get(String requestUrl, final ImageListener listener);
public ImageContainer get(String requestUrl, ImageListener imageListener, int maxWidth, int maxHeight);
public ImageContainer get(String requestUrl, ImageListener imageListener, int maxWidth, int maxHeight, ScaleType scaleType);

不过前两种都是通过三种方法实现的，这里以第三种方法为例进行说明：

public ImageContainer get(String requestUrl, ImageListener imageListener,
        int maxWidth, int maxHeight, ScaleType scaleType) {

    // only fulfill requests that were initiated from the main thread.
    throwIfNotOnMainThread();

    final String cacheKey = getCacheKey(requestUrl, maxWidth, maxHeight, scaleType);

    // Try to look up the request in the cache of remote images.
    Bitmap cachedBitmap = mCache.getBitmap(cacheKey);
    if (cachedBitmap != null) {
        // Return the cached bitmap.
        ImageContainer container = new ImageContainer(cachedBitmap, requestUrl, null, null);
        imageListener.onResponse(container, true);
        return container;
    }

    // The bitmap did not exist in the cache, fetch it!
    ImageContainer imageContainer =
            new ImageContainer(null, requestUrl, cacheKey, imageListener);

    // Update the caller to let them know that they should use the default bitmap.
    imageListener.onResponse(imageContainer, true);

    // Check to see if a request is already in-flight.
    BatchedImageRequest request = mInFlightRequests.get(cacheKey);
    if (request != null) {
        // If it is, add this request to the list of listeners.
        request.addContainer(imageContainer);
        return imageContainer;
    }

    // The request is not already in flight. Send the new request to the network and
    // track it.
    Request<Bitmap> newRequest = makeImageRequest(requestUrl, maxWidth, maxHeight, scaleType,
            cacheKey);

    mRequestQueue.add(newRequest);
    mInFlightRequests.put(cacheKey,
            new BatchedImageRequest(newRequest, imageContainer));
    return imageContainer;
}

上述代码的逻辑非常清晰，可以下面的流程图来表示，不再赘述：

对于StringRequest、JsonRequest，Volley也采用了同样的处理流程。

从get方法的形参入手，这里着重说明ImageListener（其它的形参见名知义）。ImageListener是ImageLoader的内部接口，继承于ErrorListener，需要实现的方法为onResponse：

public interface ImageListener extends ErrorListener {
    /**
     * Listens for non-error changes to the loading of the image request.
     *
     * @param response Holds all information pertaining to the request, as well
     * as the bitmap (if it is loaded).
     * @param isImmediate True if this was called during ImageLoader.get() variants.
     * This can be used to differentiate between a cached image loading and a network
     * image loading in order to, for example, run an animation to fade in network loaded
     * images.
     */
    public void onResponse(ImageContainer response, boolean isImmediate);
}

ImageLoader还提供了静态方法getImageListener来获取ImageListener实例：

public static ImageListener getImageListener(final ImageView view,
        final int defaultImageResId, final int errorImageResId) {
    return new ImageListener() {
        @Override
        public void onErrorResponse(VolleyError error) {
            if (errorImageResId != 0) {
                view.setImageResource(errorImageResId);
            }
        }

        @Override
        public void onResponse(ImageContainer response, boolean isImmediate) {
            if (response.getBitmap() != null) {
                view.setImageBitmap(response.getBitmap());
            } else if (defaultImageResId != 0) {
                view.setImageResource(defaultImageResId);
            }
        }
    };
}

从代码很容易看出，ImageListener就是Image请求返回时的回调接口，onErrorResponse和onResponse分别实现了请求失败和成功时加载对应的图片。
分析完get方法执行的流程及形参之后，我们回到ImageLoader本身。ImageLoader的构造函数如下：

/**
 * Constructs a new ImageLoader.
 * @param queue The RequestQueue to use for making image requests.
 * @param imageCache The cache to use as an L1 cache.
 */
public ImageLoader(RequestQueue queue, ImageCache imageCache) {
    mRequestQueue = queue;
    mCache = imageCache;
}

同样，从ImageLoader的形参入手，这里需要传入RequestQueue和ImageCache的实例对象。RequestQueue即整个Volley的核心请求队列，在使用Volley时第一个初始化的对象。其构造方法在Volley源码toolbox文件夹下的Volley工具类中：

public class Volley {

    /** Default on-disk cache directory. */
    private static final String DEFAULT_CACHE_DIR = "volley";

    /**
     * Creates a default instance of the worker pool and calls {@link RequestQueue#start()} on it.
     *
     * @param context A {@link Context} to use for creating the cache dir.
     * @param stack An {@link HttpStack} to use for the network, or null for default.
     * @return A started {@link RequestQueue} instance.
     */
    public static RequestQueue newRequestQueue(Context context, HttpStack stack) {
        File cacheDir = new File(context.getCacheDir(), DEFAULT_CACHE_DIR);

        String userAgent = "volley/0";
        try {
            String packageName = context.getPackageName();
            PackageInfo info = context.getPackageManager().getPackageInfo(packageName, 0);
            userAgent = packageName + "/" + info.versionCode;
        } catch (NameNotFoundException e) {
        }

        if (stack == null) {
            if (Build.VERSION.SDK_INT >= 9) {
                stack = new HurlStack();
            } else {
                // Prior to Gingerbread, HttpUrlConnection was unreliable.
                // See: http://android-developers.blogspot.com/2011/09/androids-http-clients.html
                stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent));
            }
        }

        Network network = new BasicNetwork(stack);

        RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir), network);
        queue.start();

        return queue;
    }

    /**
     * Creates a default instance of the worker pool and calls {@link RequestQueue#start()} on it.
     *
     * @param context A {@link Context} to use for creating the cache dir.
     * @return A started {@link RequestQueue} instance.
     */
    public static RequestQueue newRequestQueue(Context context) {
        return newRequestQueue(context, null);
    }
}

这里重点说明ImageCache，即图片的缓存。ImageCache同样是定义在ImageLoader中的接口（从这里也可以看出volley的高可扩展性）：

/**
 * Simple cache adapter interface. If provided to the ImageLoader, it
 * will be used as an L1 cache before dispatch to Volley. Implementations
 * must not block. Implementation with an LruCache is recommended.
 */
public interface ImageCache {
    public Bitmap getBitmap(String url);
    public void putBitmap(String url, Bitmap bitmap);
}

根据注释可以看出，推荐使用LruCache。对于LruCache，前面的博文《Android开发笔记——ListView模块、缓存及性能》已做过详细介绍，其通过维护一个强引用来限制内容数量，每当Item被访问的时候，此Item就会移动到队列的头部。当cache已满时加入新的item，在队列尾部的item会被回收。
不过，在某些应用场景下，只使用LruCache还不够。当应用退出后，LruCache清空，重新加载时，缓存的图片依然需要重新加载。这里需要使用DiskLruCache，即磁盘缓存，原理与《Android开发笔记——ListView模块、缓存及性能》中SD卡存储配合LruCache相同，但DiskLruCache实现更为合理，获得Google官方认证。

对于DiskLruCache的源码解析，推荐Android DiskLruCache完全解析，硬盘缓存的最佳方案。

因此，建议配合LruCache和DiskLruCache，以及Volley的请求缓存，形成图片三级缓存。LruCache和DiskLruCache的初始化方法分别如下：

int maxSize = (int) (Runtime.getRuntime().maxMemory() / 8);
// 实例化LruCaceh对象
mLruCache = new LruCache<String, Bitmap>(maxSize) {
     @Override
     protected int sizeOf(String key, Bitmap bitmap) {
          return bitmap.getRowBytes() * bitmap.getHeight();
     }
};

// 实例化DiskLruCache对象
 try {
      // 获取DiskLruCahce对象
      mDiskLruCache = DiskLruCache.open(getDiskCacheDir(
                    context.getApplicationContext(), "younghao"), getAppVersion(context), 1, DISKMAXSIZE);
     } catch (IOException e) {
        e.printStackTrace();
}

ImageCaches实现getBitmap和putBitmap方法时，可以使用LruCache和DiskLruCache实例高效处理图片。存入缓存时，先存入到LruCache中，然后判断是否存在DiskLruCache缓存，若没有存入；读取图片时，先从LruCache中取，没有时再从DiskLruCache中取（取出之后，顺便存入LruCache中，供下次访问时使用，不再访问DiskLruCache）。

/**
 * 存入缓存（内存缓存，磁盘缓存）
 */
@Override
public void putBitmap(String url, Bitmap bitmap) {
    // 存入LruCache缓存
    mLruCache.put(url, bitmap);
    // 判断是否存在DiskLruCache缓存，若没有存入
    String key = MD5Utils.md5(url);
    try {
        if (mDiskLruCache.get(key) == null) {
            DiskLruCache.Editor editor = mDiskLruCache.edit(key);
            if (editor != null) {
                OutputStream outputStream = editor.newOutputStream(0);
                if (bitmap.compress(CompressFormat.JPEG, 100, outputStream)) {
                    editor.commit();
                } else {
                    editor.abort();
                }
            }
            mDiskLruCache.flush();
        }
    } catch (IOException e) {
        e.printStackTrace();
    }

}

/**
 * 从缓存（内存缓存，磁盘缓存）中获取Bitmap
 */
@Override
public Bitmap getBitmap(String url) {
    if (mLruCache.get(url) != null) {
        // 从LruCache缓存中取
        Log.i(TAG, "从LruCahce获取");
        return mLruCache.get(url);
    } else {
        String key = MD5Utils.md5(url);
        try {
            if (mDiskLruCache.get(key) != null) {
                // 从DiskLruCahce取
                DiskLruCache.Snapshot snapshot = mDiskLruCache.get(key);
                Bitmap bitmap = null;
                if (snapshot != null) {
                    bitmap = BitmapFactory.decodeStream(snapshot.getInputStream(0));
                    // 存入LruCache缓存
                    mLruCache.put(url, bitmap);
                    Log.i(TAG, "从DiskLruCahce获取");
                }
                return bitmap;
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    return null;
}

至此，通过volley加载图片的方法已完成。调用方法如下：

// 获取ImageCache实例
ImageCacheUtil imageCacheUtil = ImageCacheUtil.instance(context);
// 初始化ImageLoader实例
ImageLoader imageLoader = new ImageLoader(requestQueue, imageCacheUtil);
// 获取ImageListener实例
ImageListener listener = ImageLoader.getImageListener(imageRequestBean.getImageView(),
        imageRequestBean.getDefaultImageID(), imageRequestBean.getErrorImageID());
// 发送请求图片
imageLoader.get(imageRequestBean.getUrl(),                 listener,imageRequestBean.getMaxWidth(), imageRequestBean.getMaxHeight());

二、对Volley的架构的理解

如果有童鞋能读到这里，那么对Volley的网络请求处理逻辑应该已经有了一定的认识。下面将通过Volley的官方文档对Volley的架构作进一步的说明。Volley提供了对于网络请求的自动调度，能够处理高并发网络链接，拥有透明的磁盘及内存缓存，支持请求优先级、取消请求、异步网络请求等。Volley的源码地址为：https://android.googlesource.com/platform/frameworks/volley（git clone），不过考虑到网络问题，也可到github上下载：https://github.com/mcxiaoke/android-volley.git（git clone）。

2013年Volley发布会视频：Google I/O 2013 - Volley: Easy, Fast Networking for Android（YouTube，你懂）

2.1 发送一个简单的请求

先贴一张官网的图，后面做解释。

这张图展示了Volley的核心架构，主要包含了以下类：

Volley。前面已经提到，位于toolbox文件中，是创建请求队列的工具类；
Request。实现了Comparable
>接口的抽象类，Volley中的请求都是继承于该类实现的，Request支持八种请求方法。
1
public abstract class Request<T> implements Comparable<Request<T>>

/**
 * Supported request methods.
 */
public interface Method {
    int DEPRECATED_GET_OR_POST = -1;
    int GET = 0;
    int POST = 1;
    int PUT = 2;
    int DELETE = 3;
    int HEAD = 4;
    int OPTIONS = 5;
    int TRACE = 6;
    int PATCH = 7;
}

RequestQueue。Volley的核心，代表整个请求队列。需要重点说明的是其成员变量，包含了

CacheDispatcher（处理缓存请求的调度线程）
NetworkDispatcher[]（处理网络请求的调用线程组）
ResponseDelivery（网络请求返回接口分发）
Network （执行网络请求的网络接口）
Cache（缓存请求的接口，PS：上一节说的是缓存图片）
DEFAULT_NETWORK_THREAD_POOL_SIZE（默认线程池数目，至于为什么是4？这是一个经验值，在自己实际应用中，可根据任务、网络状况以及设备等灵活设置）
PriorityBlockingQueue> （基于优先级阻塞的请求队列，包含等待的和正在执行的）、
Set> mCurrentRequests （正在处理的请求）
Map>> mWaitingRequests（正在等待的请求）
AtomicInteger mSequenceGenerator（原子的，避免并发访问）

RequestFinishedListener接口（请求完成的回调）

/** Callback interface for completed requests. */
public static interface RequestFinishedListener<T> {
    /** Called when a request has finished processing. */
    public void onRequestFinished(Request<T> request);
}

/** Used for generating monotonically-increasing sequence numbers for requests. */
private AtomicInteger mSequenceGenerator = new AtomicInteger();

/**
 * Staging area for requests that already have a duplicate request in flight.
 *
 * <ul>
 *     <li>containsKey(cacheKey) indicates that there is a request in flight for the given cache
 *          key.</li>
 *     <li>get(cacheKey) returns waiting requests for the given cache key. The in flight request
 *          is <em>not</em> contained in that list. Is null if no requests are staged.</li>
 * </ul>
 */
private final Map<String, Queue<Request<?>>> mWaitingRequests =
        new HashMap<String, Queue<Request<?>>>();

/**
 * The set of all requests currently being processed by this RequestQueue. A Request
 * will be in this set if it is waiting in any queue or currently being processed by
 * any dispatcher.
 */
private final Set<Request<?>> mCurrentRequests = new HashSet<Request<?>>();

/** The cache triage queue. */
private final PriorityBlockingQueue<Request<?>> mCacheQueue =
    new PriorityBlockingQueue<Request<?>>();

/** The queue of requests that are actually going out to the network. */
private final PriorityBlockingQueue<Request<?>> mNetworkQueue =
    new PriorityBlockingQueue<Request<?>>();

/** Number of network request dispatcher threads to start. */
private static final int DEFAULT_NETWORK_THREAD_POOL_SIZE = 4;

/** Cache interface for retrieving and storing responses. */
private final Cache mCache;

/** Network interface for performing requests. */
private final Network mNetwork;

/** Response delivery mechanism. */
private final ResponseDelivery mDelivery;

/** The network dispatchers. */
private NetworkDispatcher[] mDispatchers;

/** The cache dispatcher. */
private CacheDispatcher mCacheDispatcher;

private List<RequestFinishedListener> mFinishedListeners =
        new ArrayList<RequestFinishedListener>();

发送一个请求，只需将请求添加到请求队列即可。官网的一段示例代码如下：

final TextView mTextView = (TextView) findViewById(R.id.text);
...

// Instantiate the RequestQueue.
RequestQueue queue = Volley.newRequestQueue(this);
String url ="http://www.google.com";

// Request a string response from the provided URL.
StringRequest stringRequest = new StringRequest(Request.Method.GET, url,
            new Response.Listener<String>() {
    @Override
    public void onResponse(String response) {
        // Display the first 500 characters of the response string.
        mTextView.setText("Response is: "+ response.substring(0,500));
    }
}, new Response.ErrorListener() {
    @Override
    public void onErrorResponse(VolleyError error) {
        mTextView.setText("That didn't work!");
    }
});
// Add the request to the RequestQueue.
queue.add(stringRequest);

取消请求同样简单，通过TAG来找到特定的request，然后取消。

public static final String TAG = "MyTag";
StringRequest stringRequest; // Assume this exists.
RequestQueue mRequestQueue;  // Assume this exists.

// Set the tag on the request.
stringRequest.setTag(TAG);

// Add the request to the RequestQueue.
mRequestQueue.add(stringRequest);

@Override
protected void onStop () {
    super.onStop();
    if (mRequestQueue != null) {
        mRequestQueue.cancelAll(TAG);
    }
}

2.2 创建一个RequestQueue

在2.1节中，使用了默认的RequestQueue构造器（即通过Volley工具类），但Volley支持自定义NetWork和Cache，实现更加个性化的网络和缓存。另外一个需要注意的问题就是单例模式，为了高效的使用RequestQueue，官方建议在整个应用的生命周期内只使用一个RequestQueue实例。不过注意到很多中文的帖子使用继承Application，在Application的onCreate()方法中创建RequestQueue，官方并不鼓励这种做法，使用静态的的单例能够以更加模块化的方式实现同样的功能。核心的思想是RequestQueue应该被Application的context实例，而不是某个Activity的context。（getApplicationContext()与getContext()方法的区别）

2.3 创建一个标准的请求

继承Request的请求类型主要有：StringRequest、ImageRequest、JsonObjectRequest和JsonArrayRequest（JsonRequest的子类），第一节对ImageRequest进行了详细的说明，这里主要说明JsonObjectRequest和JsonArrayRequest，因为在实际项目中，通Json传递数据可能是目前最常见的方式。

TextView mTxtDisplay;
ImageView mImageView;
mTxtDisplay = (TextView) findViewById(R.id.txtDisplay);
String url = "http://my-json-feed";

JsonObjectRequest jsObjRequest = new JsonObjectRequest
        (Request.Method.GET, url, null, new Response.Listener<JSONObject>() {

    @Override
    public void onResponse(JSONObject response) {
        mTxtDisplay.setText("Response: " + response.toString());
    }
}, new Response.ErrorListener() {

    @Override
    public void onErrorResponse(VolleyError error) {
        // TODO Auto-generated method stub

    }
});

// Access the RequestQueue through your singleton class.
MySingleton.getInstance(this).addToRequestQueue(jsObjRequest);

官方的示例代码比较简单。不过可以关注下Request的方法，它抽象了StringRequest、ImageRequest、JsonRequest的公共特征，这种结构设计的思路值得学习。

Android线程管理（一）——线程通信

2016-05-03T09:57:54.166Z

线程通信、ActivityThread及Thread类是理解Android线程管理的关键。

线程，作为CPU调度资源的基本单位，在Android等针对嵌入式设备的操作系统中，有着非常重要和基础的作用。本小节主要从以下三个方面进行分析：

《Android线程管理（一）——线程通信》
《Android线程管理（二）——ActivityThread》
《Android线程管理（三）——Thread》

一、Handler、MessageQueue、Message及Looper四者的关系

在开发Android多线程应用时，Handler、MessageQueue、Message及Looper是老生常谈的话题。但想彻底理清它们之间的关系，却需要深入的研究下它们各自的实现才行。首先，给出一张它们之间的关系图：

Looper依赖于MessageQueue和Thread，因为每个Thread只对应一个Looper，每个Looper只对应一个MessageQueue。
MessageQueue依赖于Message，每个MessageQueue对应多个Message。即Message被压入MessageQueue中，形成一个Message集合。
Message依赖于Handler进行处理，且每个Message最多指定一个Handler来处理。Handler依赖于MessageQueue、Looper及Callback。

从运行机制来看，Handler将Message压入MessageQueue，Looper不断从MessageQueue中取出Message（当MessageQueue为空时，进入休眠状态），其target handler则进行消息处理。因此，要彻底弄清Android的线程通信机制，需要了解以下三个问题：

Handler的消息分发、处理流程
MessageQueue的属性及操作
Looper的工作原理

1.1 Handler的消息分发、处理流程

Handler主要完成Message的入队（MessageQueue）和处理，下面将通过Handler的源码分析其消息分发、处理流程。首先，来看下Handler类的方法列表：

从上图中可以看出，Handler类核心的方法包括：1）构造器；2）分发消息；3）处理消息；4）post发送消息；5）send发送消息；6）remove消息和回调。

首先，从构造方法来看，构造器的多态最终通过调用如下方法实现，即将实参赋值给Handler类的内部域。

final MessageQueue mQueue;
final Looper mLooper;
final Callback mCallback;
final boolean mAsynchronous;

public Handler(Looper looper, Callback callback, boolean async) {
    mLooper = looper;
    mQueue = looper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

其次，消息的入队是通过post方法和send方法来实现的。

1
2
3

public final boolean postAtTime(Runnable r, long uptimeMillis) {
    return sendMessageAtTime(getPostMessage(r), uptimeMillis);
}

public final boolean sendEmptyMessageAtTime(int what, long uptimeMillis) {
    Message msg = Message.obtain();
    msg.what = what;
    return sendMessageAtTime(msg, uptimeMillis);
}

public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
    MessageQueue queue = mQueue;
    if (queue == null) {
        RuntimeException e = new RuntimeException(
                this + " sendMessageAtTime() called with no mQueue");
        Log.w("Looper", e.getMessage(), e);
        return false;
    }
    return enqueueMessage(queue, msg, uptimeMillis);
}

两者的区别在于参数类型不同，post方法传入的实例对象实现了Runnable接口，然后在内部通过getPostMessage方法将其转换为Message，最终通过send方法发出；send方法传入的实例对象为Message类型，在实现中，将Message压入MessageQueue。

private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();
    m.callback = r;
    return m;
}

通过Handler将Message压入MessageQueue之后，Looper将其轮询后交由Message的target handler处理。Handler首先会对消息进行分发。首先判断Message的回调处理接口Callback是否为null，不为null则调用该Callback进行处理；否判断Handler的回调接口mCallback是否为null，不为null则调用该Callback进行处理；如果上述Callback均为null，则调用handleMessage方法处理。

public void dispatchMessage(Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

handleMessage方法在Handler的子类中必须实现。即消息具体的处理交由应用软件实现。

/**
 * Subclasses must implement this to receive messages.
 */
public void handleMessage(Message msg) {

}

回到Activity（Fragment），在Handler的子类中实现handleMessage方法。这里需要注意一个内存泄露的问题，比较下述两种实现方式，第一种直接定义Handler的实现，第二种通过静态内部类继承Handler，定义继承类的实例。

Handler mHandler = new Handler() {
            
    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
            
        // 根据msg调用Activity的方法
    }
};

static class MyHandler extends Handler {

    WeakReference<DemoActivity> mActivity;

    public MyHandler(DemoActivity demoActivity) {
        mActivity = new WeakReference<DemoActivity>(demoActivity);
    }

    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
        DemoActivity theActivity = mActivity.get();

        // 根据msg调用theActivity的方法
    }
}

不绕弯子，直接说明为什么第一种方式会引起内存泄露，而第二种不会。

在第一种方式中，mHandler通过匿名内部类方式实例化，在Java中，内部类会强持有外部类的引用（handleMessage方法中可以直接调用Activity的方法），在外部Activity调用onDestroy()方法之后，如果Handler的MessageQueue依然有未处理的消息，那么由于Handler持有Activity的引用导致Activity无法被系统GC回收，从而引起内存泄露。

在第二种方式中，首先继承Handler定义静态内部类，由于MyHandler为静态类，即使定义在Activity的内部，也与Activity没有逻辑上的联系，即不会持有外部Activity的引用；其次，在静态类内部，定义外部Activity的弱引用，弱引用在系统资源紧张时会被系统优先回收。最后，在handleMessage()方法中，通过WeakReference的get方法获取外部Activity的引用，如果该弱引用已被回收，则get方法返回null。

struct GcSpec {
  /* If true, only the application heap is threatened. */
  bool isPartial;
  /* If true, the trace is run concurrently with the mutator. */
  bool isConcurrent;
  /* Toggles for the soft reference clearing policy. */
  bool doPreserve;
  /* A name for this garbage collection mode. */
  const char *reason;
};

这段代码定义在dalvik/vm/alloc/Heap.h中，其中doPreserve为true时，表示在执行GC的过程中，不回收软引用引用的对象；为false时，表示在执行GC的过程中，回收软引用引用的对象。

最后，使用Handler的过程中，还需要注意一点，在前面的方法列表图中已经提到。为避免Activity调用onDestroy后，Handler的MessageQueue中仍存在Message，一般会在onDestroy中调用removeCallbacksAndMessages()方法。

@Override
protected void onDestroy() {
    super.onDestroy();
    // 清空Message队列
    myHandler.removeCallbacksAndMessages(null);
}

1
2
3

public final void removeCallbacksAndMessages(Object token) {
    mQueue.removeCallbacksAndMessages(this, token);
}

removeCallbacksAndMessages()方法会移除obj为token的由post发送的callback和send发送的message，当token为null时，会移除所有callback和message。

1.2 MessageQueue的属性及操作

MessageQueue，消息队列，其属性与常规队列相似，包括入队、出队等，这里简要介绍一下MessageQueue的实现。

首先，MessageQueue新建队列的工作是通过在其构造器中调用本地方法nativeInit实现的。nativeInit会创建NativeMessageQueue对象，然后赋值给MessageQueue成员变量mPtr。mPtr是int类型数据，代表NativeMessageQueue的内存指针。

MessageQueue(boolean quitAllowed) {
    mQuitAllowed = quitAllowed;
    mPtr = nativeInit();
}

其次，Message入队的通过enqueueMessage方法实现。首先检查message是否符合入队要求（是否正在使用，target handler是否为null），符合要求后通过设置prev.next = msg队列的指针完成入队操作。

1	boolean enqueueMessage(Message msg, long when);

再次，出队是通过next()方法完成的。涉及到同步、锁等问题，这里不详细展开了。

再次，删除元素有两个实现。即分别通过p.callback == r和p.what == what来进行消息识别。

1 2	void removeMessages(Handler h, int what, Object object); void removeMessages(Handler h, Runnable r, Object object);

最后，销毁队列和创建队列一样，是通过本地函数完成的。传入的参数为MessageQueue的内存指针。

1	private native static void nativeDestroy(int ptr);

1.3 Looper的工作原理

Looper是线程通信的关键，正是因为Looper，整个线程通信机制才真正实现“通”。

在应用开发过程中，一般当主线程需要传递消息给用户自定义线程时，会在自定义线程中定义Handler进行消息处理，并在Handler实现的前后分别调用Looper的prepare()方法和loop()方法。大致实现如下：

new Thread(new Runnable() {
            
    private Handler mHandler;
            
    @Override
    public void run() {
        Looper.prepare();
        mHandler = new Handler() {
            @Override
            public void handleMessage(Message msg) {
                super.handleMessage(msg);
                        
            }
        };
        Looper.loop();
    }
});

这里重点说明prepare()方法和loop()方法，实际项目中不建议定义匿名线程。

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

可以看出，prepare方法的重点是sThreadLocal变量，sThreadLocal变量是什么呢？

1 2	// sThreadLocal.get() will return null unless you've called prepare(). static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

ThreadLocal实现了线程本地存储。简单看一下它的类注解文档，ThreadLocal是一种特殊的全局变量，全局性在于它存储于自己所在线程相关的数据，而其他线程无法访问。

/**
 * Implements a thread-local storage, that is, a variable for which each thread
 * has its own value. All threads share the same {@code ThreadLocal} object,
 * but each sees a different value when accessing it, and changes made by one
 * thread do not affect the other threads. The implementation supports
 * {@code null} values.
 *
 * @see java.lang.Thread
 * @author Bob Lee
 */
public class ThreadLocal<T> {

}

回到prepare方法中，sThreadLocal添加了一个针对当前线程的Looper对象。并且prepare方法只能调用一次，否则会抛出运行时异常。

初始化完毕之后，Handler通过post和send方法如何保证消息投递到Looper所持有的MessageQueue中呢？其实，MessageQueue是Handler和Looper的桥梁。在前面Handler章节中提到Handler的初始化方法，Handler的mLooper对象是通过Looper的静态方法myLooper()获取的，而myLooper()是通过调用sThreadLocal.get()来得到的，即Handler的mLooper就是当前线程的Looper对象，Handler的mQueue就是mLooper.mQueue。

……
mLooper = Looper.myLooper();
if (mLooper == null) {
   throw new RuntimeException(
        "Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
……

1
2
3

public static Looper myLooper() {
    return sThreadLocal.get();
}

Android开发笔记——图片缓存、手势及OOM分析

2016-05-03T09:16:34.821Z

把图片缓存、手势及OOM三个主题放在一起，是因为在Android应用开发过程中，这三个问题经常是联系在一起的。首先，预览大图需要支持手势缩放，旋转，平移等操作；其次，图片在本地需要进行缓存，避免频繁访问网络；最后，图片（Bitmap）是Android中占用内存的大户，涉及高清大图等处理时，内存占用非常大，稍不谨慎，系统就会报OOM错误。

庆幸的是，这三个主题在Android开发中属于比较普遍的问题，有很多针对于此的通用的开源解决方案。因此，本文主要说明笔者在开发过程中用到的一些第三方开源库。主要内容如下：

Universal Image Loader、Picasso、Glide与Fresco的对比及使用
PhotoView、GestureImageView的原理及使用
leakcanry内存分析工具

一、Universal Image Loader、Picasso、Glide与Fresco的对比及使用

Universal Image Loader（UIL）、Picasso、Glide与Fresco是Android中进行图片加载的常用第三方库，主要封装了内存缓存、磁盘缓存、网络请求缓存、线程池等方法，抽象了图片加载的流程，很大程度避免了加载图片引起的内存溢出，提高了图片加载的效率。下图是笔者近期从各个库的github页面查询到的信息：

需要说明的是：

Imageloader是最早开源的图片缓存库，目前作者已停止维护（11.27）；
Picasso的实际作者是Square的Jake Wharton，Android领域的绝对大牛；
Glide是由Google员工开源的，在Google I/O 2014官方应用中推荐使用；
Fresco的图片加载不使用Java堆内存，而是匿名共享内存（Ashmem）。

附上各个库的github地址：

Universal Image Loader：https://github.com/nostra13/Android-Universal-Image-Loader.git
Picasso：https://github.com/square/picasso.git
Glide：https://github.com/bumptech/glide.git
Fresco：https://github.com/facebook/fresco.git

这四个图片缓存库的基本使用（HelloWorld）都可以通过一句代码实现，分别如下：
UIL：

1	ImageLoader.getInstance().displayImage(url, imageView);

Picasso：

1	Picasso.with(context).load(url).into(imageView);

Glide：

1	Glide.with(context).load(url).into(imageView);

Fresco：

1	simpleDraweeView.setImageURI(uri);

细心的朋友可以看出，Picasso和Glide的API非常类似。事实上，这四个库在实现的核心思想上都比较相似，可以抽象为以下五个模块：

RequestManager，主要负责请求生成和管理模块；
Engine，主要负责创建任务以及执行调度；
GetDataInterface，获取数据的接口，主要用于从内存缓存、磁盘缓存以及网络等获取图片数据；
Displayer，主要用于显示图片，可能是对ImageView的封装或者其他虚拟的Displayer；
Processor，主要负责处理图片，比如图片的旋转、压缩以及截取等操作。

说一句题外话，掌握了各种开源库的实现的核心思想后，会发现软件工程的一个共同点，就是通过将流程形式化、抽象化，从而提高效率。不论是业务的效率，还是开发的效率，这或许也是软件作为一门科学的核心思想。

ImageLoader的设计及优点
ImageLoader加载的流程如下图。（需要申明：下面三张流程图来自Trinea，尊重原作者版权）

ImageLoader收到加载及显示图片的任务，ImageLoaderEngine分发任务，获得图片数据后，BitmapDisplayer 在ImageAware中显示。
ImageLoader的优点：

支持下载进度监听

可以在 View 滚动中暂停图片加载，通过 PauseOnScrollListener 接口可以在 View 滚动中暂停图片加载。

默认实现多种内存缓存算法，这几个图片缓存都可以配置缓存算法，不过 ImageLoader 默认实现了较多缓存算法，如 Size 最大先删除、使用最少先删除、最近最少使用、先进先删除、时间最长先删除等。

支持本地缓存文件名规则定义

Picasso的设计及优点
Picasso的加载流程如下图：

Picasso收到加载及显示图片的任务，Dispatcher 负责分发和处理，通过MemoryCache及Handler获取图片，通过PicassoDrawable显示到Target中。
Picasso的优点：

自带统计监控功能，支持图片缓存使用的监控，包括缓存命中率、已使用内存大小、节省的流量等。

支持优先级处理，每次任务调度前会选择优先级高的任务，比如 App 页面中 Banner 的优先级高于 Icon 时就很适用。

支持延迟到图片尺寸计算完成加载，支持飞行模式、并发线程数根据网络类型而变，手机切换到飞行模式或网络类型变换时会自动调整线程池最大并发数，比如 wifi 最大并发为 4， 4g 为 3，3g 为 2。这里 Picasso 根据网络类型来决定最大并发数，而不是 CPU 核数。

“无”本地缓存，不是说没有本地缓存，而是 Picasso 自己没有实现，交给了 Square 的另外一个网络库 okhttp 去实现，这样的好处是可以通过请求 Response Header 中的 Cache-Control 及 Expired 控制图片的过期时间。

Glide的设计及优点
Glide的加载流程如下图：

Glide 收到加载及显示资源的任务，Engine 处理请求，通过Fetcher获取数据，经Transformation 处理后交给Target显示。
Glide的优点：

(1) 图片缓存->媒体缓存
Glide 不仅是一个图片缓存，它支持 Gif、WebP、缩略图。甚至是 Video，所以更该当做一个媒体缓存。
(2) 支持优先级处理
(3) 与 Activity/Fragment 生命周期一致，支持 trimMemory
Glide 对每个 context 都保持一个 RequestManager，通过 FragmentTransaction 保持与 Activity/Fragment 生命周期一致，并且有对应的 trimMemory 接口实现可供调用。
(4) 支持 okhttp、Volley
Glide 默认通过 UrlConnection 获取数据，可以配合 okhttp 或是 Volley 使用。实际 ImageLoader、Picasso 也都支持 okhttp、Volley。
(5) 内存友好
① Glide 的内存缓存有个 active 的设计
从内存缓存中取数据时，不像一般的实现用 get，而是用 remove，再将这个缓存数据放到一个 value 为软引用的 activeResources map 中，并计数引用数，在图片加载完成后进行判断，如果引用计数为空则回收掉。
② 内存缓存更小图片
Glide 以 url、viewwidth、viewheight、屏幕的分辨率等做为联合 key，将处理后的图片缓存在内存缓存中，而不是原始图片以节省大小
③ 与 Activity/Fragment 生命周期一致，支持 trimMemory
④ 图片默认使用默认 RGB565 而不是 ARGB888
虽然清晰度差些，但图片更小，也可配置到 ARGB_888。
其他：Glide 可以通过 signature 或不使用本地缓存支持 url 过期

关于Fresco
Fresco库开源较晚，目前还没有正式的1.0版本。但其功能比前三个库都强大，比如：

图片存储系统匿名共享内存Ashmem（Anonymous Shared Memory），并不分配Java堆内存，因此图片加载不会引起堆内存抖动；
JPEG图像流加载（先显示图像轮廓，再慢慢加载清晰图像）；
更加完善的图像处理、显示方式；
JPEG图像本地（native）变换尺寸，避免OOM；
……
关于系统匿名共享内存Ashmem，会在后续的一篇关于Android的内存使用的文章中详述，这里仅作简单介绍：

在Android系统里面，Ashmem这个区域的内存并不属于Java Heap，也不属于Native Heap。当Ashmem中的某个内存空间像要被释放时候，会通过系统调用unpin来告知。但实际上这块内存空间的数据并没有被真正的擦除。如果Android系统发现内存吃紧时，就会把unpin的内存空间利用起来去存储所需的数据。而被unpin的内存空间，是可以被重新pin的，如果此时的该内存空间还没有被其他人使用的话，就节省了重新往Ashmem重新写入数据的过程了。所以，Ashmem这个工作原理是一种延迟释放。

另外，学习Ashmem可以参考罗升阳大师的博客：

Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划
Android系统匿名共享内存Ashmem（Anonymous Shared Memory）驱动程序源代码分析
Android系统匿名共享内存Ashmem（Anonymous Shared Memory）在进程间共享的原理分析

二、PhotoView、GestureImageView的原理及使用

需要使用上述第三方开源库进图片加载的一个典型场景是点击查看大图。大图支持手势缩放、旋转、平移等操作，ImageView的手势缩放，有很多种方法，绝大多数开源自定义缩放都是修改了ondraw函数来实现的。但是ImageView本身有scaleType属性，通过设置android:scaleType=”matrix” 可以轻松实现缩放功能。缩放的优点是实现起来简单，同时因为没有反复调用ondraw函数，缩放过程中不会有闪烁现象。另外，需要注意的是，scaleType控制图片的缩放方式，该图片指的是资源而不是背景，换句话说，android:src=”@drawable/ic_launcher”，而非android:background=”@drawable/ic_launcher”。

在github上可以找到很多开源的实现，这里主要举两个例子进行简单说明。

PhotoView地址：https://github.com/bm-x/PhotoView.git
GestureImageView地址：https://github.com/jasonpolites/gesture-imageview.git

PhotoView的介绍：

1.Gradle添加依赖（推荐）

1
2
3

dependencies {
    compile 'com.bm.photoview:library:1.3.6'
}

（或者也可以将项目下载下来，将Info.java和PhotoView.java两个文件拷贝到你的项目中，不推荐）——这种方式适用于Eclipse。

2.xml添加

<com.bm.library.PhotoView
     android:id="@+id/img"
     android:layout_width="match_parent"
     android:layout_height="match_parent"
     android:scaleType="centerInside"
     android:src="@drawable/bitmap1" />

3.java代码

PhotoView photoView = (PhotoView) findViewById(R.id.img);
// 启用图片缩放功能
photoView.enable();
// 禁用图片缩放功能 (默认为禁用，会跟普通的ImageView一样，缩放功能需手动调用enable()启用)
photoView.disenable();
// 获取图片信息
Info info = photoView.getInfo();
// 从一张图片信息变化到现在的图片，用于图片点击后放大浏览，具体使用可以参照demo的使用
photoView.animaFrom(info);
// 从现在的图片变化到所给定的图片信息，用于图片放大后点击缩小到原来的位置，具体使用可以参照demo的使用
photoView.animaTo(info,new Runnable() {
       @Override
       public void run() {
           //动画完成监听
       }
   });
// 获取动画持续时间
int d = PhotoView.getDefaultAnimaDuring();

PhotoView实现的基本原理是在继承于ImageView的PhotoView中采用了缩放Matrix及手势监听。

public class PhotoView extends ImageView {

    ……

    private Matrix mBaseMatrix = new Matrix();
    private Matrix mAnimaMatrix = new Matrix();
    private Matrix mSynthesisMatrix = new Matrix();
    private Matrix mTmpMatrix = new Matrix();

    private RotateGestureDetector mRotateDetector;
    private GestureDetector mDetector;
    private ScaleGestureDetector mScaleDetector;
    private OnClickListener mClickListener;

    private ScaleType mScaleType;
    
    ……
}

PhotoView的实现与上述原理基本一致，这里不再赘述。对于自定义控件的实现，后续文章会进行详细的分析。

GestureImageView的简介如下：
1.Configured as View in layout.xml

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:gesture-image="http://schemas.polites.com/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">

    <com.polites.android.GestureImageView
        android:id="@+id/image"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:src="@drawable/image"
        gesture-image:min-scale="0.1"
        gesture-image:max-scale="10.0"
        gesture-image:strict="false"/>

</LinearLayout>

2.Configured Programmatically

public class SampleActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        LayoutParams params = new LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT);

        GestureImageView view = new GestureImageView(this);
        view.setImageResource(R.drawable.image);
        view.setLayoutParams(params);

        ViewGroup layout = (ViewGroup) findViewById(R.id.layout);

        layout.addView(view);
    }
}

原理基本同PhotoView一致，不再赘述。

三、OOM分析工具——LeakCanary

LeakCanary的介绍：

A memory leak detection library for Android and Java.

可见，LeakCanary主要用于检测各种内存不能被GC，从而导致泄露的情况。

LeakCanary的地址 https://github.com/square/leakcanary.git
Demo地址：
https://github.com/liaohuqiu/leakcanary-demo.git（AS）
https://github.com/teffy/LeakcanarySample-Eclipse.git（Eclipse）

下面是demo中TestActivity中的TextView被静态变量引用导致无法回收引起的内存泄露的截图。

LeakCanary的使用较为简单，首先添加依赖工程：

dependencies {
   debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'
   releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'
}

其次，在application的onCreate()方法中进行初始化。

public class ExampleApplication extends Application {

  @Override public void onCreate() {
    super.onCreate();
    LeakCanary.install(this);
  }
}

经过这两步之后就可以使用了。LeakCanary.install(this)会返回一个预定义的 RefWatcher，同时也会启用一个ActivityRefWatcher，用于自动监控调用 Activity.onDestroy() 之后泄露的 activity。如果需要监听fragment，则在fragment的onDestroy()方法进行注册：

public abstract class BaseFragment extends Fragment {

  @Override public void onDestroy() {
    super.onDestroy();
    RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
    refWatcher.watch(this);
  }
}

当然，需要对某个变量进行监听，直接对其进行watch即可。

RefWatcher refWatcher = {...};

// We expect schrodingerCat to be gone soon (or not), let's watch it.
refWatcher.watch(schrodingerCat);

需要注意的是，在eclipse中使用LeakCanary需要在AndroidManifest文件中对堆占用分析以及展示的Service进行申明：

<service
    android:name="com.squareup.leakcanary.internal.HeapAnalyzerService"
    android:enabled="false"
    android:process=":leakcanary" />
<service
    android:name="com.squareup.leakcanary.DisplayLeakService"
    android:enabled="false" />

<activity
    android:name="com.squareup.leakcanary.internal.DisplayLeakActivity"
    android:enabled="false"
    android:icon="@drawable/leak_canary_icon"
    android:label="@string/leak_canary_display_activity_label"
    android:taskAffinity="com.squareup.leakcanary"
    android:theme="@style/leak_canary_LeakCanary.Base" >
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />

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

注意：HeapAnalyzerService采用了多进程android:process=”:leakcanary”。

上述开源工具的使用都较为简单，关于详细使用，请参考其github地址。

四、一些杂乱的总结

内存泄露的常见原因：

静态对象：监听器，广播，webview；
this$0：线程，定时器，Handler；
系统：TextLine，输入法，音频

兜底回收内存：

Activity泄露会导致该Activity引用的Bitmap/DrawingCache等无法释放，兜底回收是指对已泄露的Activity，尝试回收其持有的资源。在onDestroy中从rootview开始，递归释放所有子VIew涉及的图片，背景，DrawingCache，监听器等资源。

降低Runtime内存的方法：

减少bitmap占用的内存：1）防止bitmap占用资源过大，2.x系统打开BitmapFactory.Options中的inNativeAlloc；4.x系统采用Facebook的fresco库，将图片资源放于native中。2）图片按需加载，图片的大小不应超过view的大小。3）统一的bitmap加载器：Picasso/Fresco。4）图片存在像素浪费。
自身内存占用监控：1）实现原理：通过Runtime获取maxMemory，而totalMemory-freeMemory即为当前真正使用的dalvik内存。2）操作方式：定期检查这个值，达到80%就去释放各种cache资源（bitmap的cache）。
使用多进程。对于webview，图库等，由于存在内存系统泄露，可以采用单独的进程。