自定义View(2)Canvas简介

发表于 2017-09-21 |

一、Canvas简介

（1）Canvas简介

Canvas,即画布。

（2）Canvas详解

画布，就是我们用来绘制的载体，我们可以用画笔（Paint）在画布（Canvas）上绘制我们想要的图形。

首先介绍一下画笔Paint
- 1.三个构造函数
  - Paint() 创建一个画笔
  - Paint(int flags) 创建一个画笔，指定flag。也可在不指定flag创建后，通过setFlag指定。例如：Paint.ANTI_ALIAS_FLAG(用于绘制时抗锯齿）
  - Paint(Paint paint) 使用已构造的Paint创建一个画笔
- 2.常用方法
  - setAlpha(int a) 设置透明度
  - setARGB(int a, int r, int g, int b) 设置画笔颜色，a-alpha透明度，r-red,g-green,b-blue
  - setAntiAlias(boolean aa) 设置抗锯齿
  - setColor(@ColorInt int color) 设置颜色
  - setDither(boolean dither) 设置抖动，设置后线条会相对柔和一些，不那么僵硬
  - setUnderlineText(boolean underlineText) 设置文本下划线
  - setStyle(Style style) 设置画笔风格。FILL内部填充，STROKE描边，FILL_AND_STROKE填充内部和描边
  - setStrikeThruText(boolean strikeThruText) 设置文本删除线
  - setFilterBitmap(boolean filter) 对bitmap进行滤波处理，true-去除优化，加快显示
  - setColorFilter(ColorFilter filter) 设置颜色过滤
    
    ······
- 3.ColorFilter
  
  ColorFilter主要用来处理颜色.它有三个子类：ColorMatrixColorFilter、LightingColorFilter、PorterDuffColorFilter。下面一一进行解释。
  1. ColorMatrixColorFilter
    - ColorMatrixColorFilter在Android中，图片是以一个个 RGBA 的像素点的形式加载到内存中的，所以如果需要改变图片的颜色，就需要针对这一个个像素点的RGBA的值进行修改。修改图片的RGBA值，需要ColorMatrix类支持.
    - 通过4x5颜色矩阵转换颜色的滤色镜。该滤镜可用于改变像素的饱和度，从YUV转换为RGB等。

设计模式之路（7）里氏替换原则

发表于 2017-09-11 |

里氏替换原则（LSP）

一、基本概念：

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别，也就是说，在软件程序里面，把父类都替换成它的子类，程序的行为没有变化。简单地说，子类型必须能够替换掉它们的父类型。

二、例证

只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为特性。

举个例子：

小狗具备动物的基本行为：吃、喝等行为，当需要小猫、小猪也有类似的行为时，由于它们都是继承动物，所以只需要更改实例化的地方，程序的其他地方不要更改。

Animal animal = new Cat();//只需要修改实例化即可，如：new Dog()

animal.eat();
animal.drink();

设计模式之路（6）依赖倒转原则

发表于 2017-09-10 |

依赖倒置原则

–

概述：依赖倒置原则（Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

–

要针对接口编程，不要针对实现编程。
- 针对接口编程的意思就是说，应当使用Java接口和抽象Java类进行变量的类型声明、参量的类型声明、方法的返回类型声明，以及数据类型的转换等。
- 不要针对实现编程的意思就是说，不应当使用具体Java类进行变量的类型声明、参量的类型声明、方法的返回类型声明，以及数据类型的转换等。

一、依赖倒置原则：

A.高层模块不应该依赖低层模块。两个都应该依赖抽象。

B.抽象不应该依赖细节。细节应该依赖抽象。

二、为什么要依赖倒置

传统的过程性系统的设计方法倾向于使高层次的模块依赖于低层次的模块，抽象层次依赖于具体层次。倒置原则就是要把这个错误的依赖关系倒转过来。

三、总结

一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是，当这些模块依赖于低层模块时，低层模块的修改将会直接影响到它们，迫使它们也去改变。这种境况是荒谬的。应该是处于高层的模块去迫使那些低层的模块发生改变。应该是处于高层的模块优先于低层的模块。无论如何高层的模块也不应依赖于低层的模块。而且，我们想能够复用的是高层的模块。通过子程序库的形式，我们已经可以很好地复用低层的模块了。当高层的模块依赖于低层的模块时，这些高层模块就很难在不同的环境中复用。但是，当那些高层模块独立于低层模块时，它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则。