Android 开发艺术探索看不懂对着书敲慢慢理解，设计模式之禅总结，平时记录的笔记，3w多次字防止丢失，留存。

知识点1：

1.子线程为什么不允许访问ui因为android中的ui控件不是线程安全的。

2.为什么不给Ui加上锁的机制，第一点会让ui访问的逻辑变得复杂，其次降低ui访问的效率。

3.List转化成String[]

     public static String[] toStringArray(List<String> strList) {String[] array = new String[strList.size()];strList.toArray(array);return array;}

4.webview中的常用方法

(1)goBack():后退。
(2)goForward():前进。
(3)loadUrl(String url):加载指定URL对应的网页
(4)boolean zoomIn():放大网页。
(5)boolean zoomOut():缩小网页。

5.解决ScrollView嵌套listview只显示一行item得问题
重写listview

    @Overrideprotected void onMeasure(int widthMeasureSpec, int heightMeasureSpec)
{    heightMeasureSpec=MeasureSpec.makeMeasureSpec(Integer.MAX_VALUE>>2,MeasureSpec.AT_MOST);super.onMeasure(widthMeasureSpec, heightMeasureSpec);}

6.activity切换时的overridePendingTransition动画效果：

第一个参数为第一个Activity离开时的动画，第二参数为所进入的Activity的动画效果
淡入淡出效果
Activity.overridePendingTransition(R.anim.fade, R.anim.hold);
放大淡出效果
overridePendingTransition(R.anim.my_scale_action,R.anim.my_alpha_action);
转动淡出效果
overridePendingTransition(R.anim.scale_rotate,R.anim.my_alpha_action);
转动淡出效果
overridePendingTransition(R.anim.scale_translate_rotate,R.anim.my_alpha_action);
左上角展开淡出效果
overridePendingTransition(R.anim.scale_translate,R.anim.my_alpha_action);
压缩变小淡出效果
overridePendingTransition(R.anim.hyperspace_in,R.anim.hyperspace_out);
右往左推出效果
overridePendingTransition(R.anim.push_left_in,R.anim.push_left_out);
下往上推出效果
overridePendingTransition(R.anim.push_up_in,R.anim.push_up_out);
左右交错效果
overridePendingTransition(R.anim.slide_left,R.anim.slide_right);
放大淡出效果
overridePendingTransition(R.anim.wave_scale,R.anim.my_alpha_action);
缩小效果
overridePendingTransition(R.anim.zoom_enter,R.anim.zoom_exit);
上下交错效果
overridePendingTransition(R.anim.slide_up_in,R.anim.slide_down_out);

7.app的版本时在build中的defaultConfig中的versionName中设置的。

知识点2：

1.获取手机屏幕的密度

 float xdpi = getResources().getDisplayMetrics().xdpi;float ydpi = getResources().getDisplayMetrics().ydpi;

2.androidstudio中全局替换字符串，在包的下面右边replace in path

3.广播在不通的包下面，接受要加上Intent.addFlags(0x01000000);

4.通过jks文件查看签名

keytool -list -v -keystore D:\companyjks\aaaa-storepass 123456

5.intent在页面之间跳转时只可以带上keyvalue形式的数据，可以把对象继承Serializablera(序列化)然后就可以直接讲对象传输过去。

6.Onstart和onstop是从Activity是否可见的角度去分析
OnResume和onPauser是从activity是否在前台的角度去分析的

7.adb shell ps 或者adb shell ps|grep 包名可以查看当前的进程信息

进程名以:开头的进程属于私有进程 不以:开头的进程属于全局进程，其他应用可以通过  ShareUID的方式可以和他跑在同一个进程中。

8.序列化时应该手动指定serialVersionUID的值，如过不指定，系统会自动生成hashcode值，这样的话如果增加或者删除了变量，则反序列化会失败，指定了serialVersionUID的值之后就不会，但是类的结构大声改变之后，就算指定了serialVersionUID的值也不会反序列化成功。

9.动画：

(1)ScrollTo/ScrollBy:操作简单，适合对View内容的话哦的那个
(2)动画：操作简单，主要适用于没有交互的view和实现复杂的动画效果
(3)改变布局参数：操作稍微复杂，适用于有交互的view。

10.直接用数据线去安装apk

adb install -r 应用程序.Apk。

11.使用adb命令去启动一个Activity

Adb shell am start -n  com.adam.collection.test/com.adam.collection.test.ui.MainActivity。

12.在View提供的方法当中:

getTop():获取到的是View自身的顶边到父布局顶边的距离
getLeft():获取到的是View自身的左边到父布局左边的距离
getRight():获取到的是View自身的右边边到父布局左边的距离
getBotton():获取到的是View自身的底边到父布局顶边的距离

在MotionEvient提供的方法中：

getX():获取点击事件距离控件左边的距离，即视图坐标
getY():获取点击事件距离控件顶边的距离，即视图坐标
getRawX():获取点击事件距离整个屏幕左边的距离，即绝对坐标
getRawY():获取点击事件距离整个屏幕顶边的距离，即绝对坐标

13:Androuid布局优化：

1.避免重绘ui,性能浪费
2.优化布局层级，view树不要太高，层级嵌套不要太深
3.使用include复用公共的布局
4.使用viewStub 区别于Gone是他在初始化时不会去加载
5.hierarchyviewer工具去快速找到树中冗余的布局
6LinearLayout比RelativeLayout性能好，RelativeLayout的功能比较复杂，会花费更多的cpu时间，但是在嵌套的时候，RelativeLayout的性能优于LinearLayout。
7.merge标签 在嵌套时，如果include里面的布局跟外部一样，里面的布局可以用merge来替代，来去除多余重复的层级
8.在自定义绘制view的时候  在onDraw方法中避免执行大量的耗时操作，会造成页面的卡顿。
9.不要用静态变量去引用当前的 context会造成Activity泄露，内存无法释放。
10.Activity的对象被单例模式所持有，而单例模式的特点是其生命周期和Applicatio保持一致，因此Activity对象无法被及时释放。
11.属性动画：从Android3.0开始，Google提供了属性动画，其中有一类无限循环的动画，如果在Activity中播放此类动画且没有在onDestory中停止动画，那么动画会一直播放下去，尽管已经无法在界面上看到动画效果了，并且这个时候Activity的View会被动画持有，而View又持有了Activity,最终Activity无法释放。下面的动画是无限动画，会泄露当前Activity,解决方法是在Activity的onDestory中嗲用animator.cancel()来停止动画。

14:Android内存优化

Bitmap优化：使用适合分辨率和大小的图片，及时回收内存，使用图片缓存。

代码优化：

1.对常量使用static修饰符
2.使用静态方法，静态方法会比普通方法提高15%左右的访问速度
3.减少不必要的成员变量。这点在Androidlint工具上已经集成检测了，如果一个变量可以定义为局部变量，则会建议你不要定义为成员变量。
4.减少不必要的对象，使用基础类型会比使用对象更加节省资源，同时更应该避免频繁创建短作用域的变量
5.尽量不要使用枚举，少用迭代器，枚举占用的内存空间要比整型大
6.对Cursor,ReCeiver,Sensor，File等对象，要非常注意对他们的创建，回收与注册，解注册
7.避免使用ioc框架，ioc通常使用注解，反射来进行实现，虽然现在java对反射的效率已经进行了很好的优化，但大量使用反射依然会带来性能的下降
8.使用RenderScript,OpenGl来进行非常复杂的绘图操作
9.使用SurfaceView来代替view进行大量 频繁的绘图操作
//SurfaceView适合频繁更新，被动更新的试图，像股票曲线
//view适合自己主动去更新视图
10.尽量使用视图缓存，而不是每次都执行inflate方法解析视图。
11.常量请使用static final来修饰
15:内存泄露分析工具MAT

设计模式知识点：

单例模式：
1.在sInstance=new Singleton时有三条原子操作：
(1)给Singleton的实力分配内存。
(2)调用Singleton()的构造函数，初始化成员字段
(3)讲sInstance对象指向分配的内存空间（此时sInstance就不是null了）。
由于编译器乱序执行可能 1，3，2的顺序去执行调用3之后被拿走使用了就会出错
还很难复现，可以给sInstance加上一个Volatile关键字。虽然会影响性能，但是程序的正确性也很重要。
单例模式一般没有接口，扩展很困难，若要扩展，除了修改代码基本上没有第二种途径可以实现，单例对象如何持有Context，那么很容易引发内存泄漏，此时需要注意传递给单例对象的Context最好时Application Context 引用使用Activity的Context话会造成Activity无法释放。
工厂方法模式：
产品实现类实现抽象产品方法，工厂实现类实现工厂抽象方法，工厂实现铲平的生产
抽象工厂模式：
在工厂方法模式的基础上添加接口，把方法都放在抽象方法中，由子类去实现，他的优点时高层不需要去关心产品时怎么实现的，只需要找到工厂类让他去创建就可以了。（女娲造人）
模板方法模式：
在抽象类中有基本方法跟模板方法，模板方式实现了对基本方法的调度，完成固定的逻辑，上层只需要去调用模板方法就可以了（悍马模型）
建造者模式：
将一个复杂对象的构建与他的表示分离，使得同样的构建过程可以创建不同的表示（造各种不同功能的车型能启动能停止能启动能鸣笛）创建一个产品类，创建一个抽象建造者，具体建造者实现抽象建造者，会实现产品里面的逻辑并且有个返回产品的方法，最后导演类产生了一个建造者拿到里面返回的产品。
建造者适合相同的方法，不同的执行顺序，产生不同的事件结果。
代理模式：
让其他对象提供一种代理以控制对这个对象的访问（代练着给张三打游戏，执行者时代练着，升级的时张三）代理者拿着游戏者去执行操作。
普通代理时有一个代理来执行用户的操作，方法不知道代理后面是谁，而强制代理时方法通过用户来找找到代理，这个代理时用户提供的。
原型模式：
浅拷贝是指clone方法拷贝了本对象，对是对象内部的数组，引用对象等都不拷贝，还是指向原生对象的内部元素地址。所以拷贝出来的修改的是原型中的数据。深拷贝对私有的类变量进行独立的拷贝，比如说对象内部的数组，所以在拷贝出来对象修改的是拷贝出来的数组，对原型中的数组数据并没有改变。
总结：浅拷贝只拷贝对象，操作的还是原来原型中的数据，深拷贝是把所有的都拷贝一份，是完全独立出来的。
中介者模式：
用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变他们之间的交互。在各个不同的类中间形成一个中介类，其他类中需要跟中介类交互就可以，减少类与类之间的耦合程度。
优点：减少类间的依赖，把原来的一对多的依赖变成了一对一的依赖，同事类只依赖中介者，减少依赖，降低耦合。
缺点：会导致中介者会膨胀得很大，而且逻辑复杂，同事类越多，中介者得逻辑就越复杂。
命令模式：
命令模式是一个高内聚得模式，将一个请求封装成一个对象。有一个接收者角色，一个命令角色，一个调用者角色，命令角色给个命令给调用者，调用者根据命令让接收者去完成对应得功能。
优点：调用者和接收者之间没有依赖关系，调用者实现功能只需要调用Command抽象类得execute方法就可以，不需要了解接收者是谁。
缺点：回到直Command的类膨胀问题。
责任链模式：
使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系，将这些对象连成一条链，并沿着这条链传递该请求，知道有对象处理他为止（三从四德）
优点：将请求和处理分开，请求者可以不用知道是谁处理的，处理者可以不用知道请求的全貌，两者解耦，提高系统的灵活性。
缺点：性能问题，每个请求都要从链头便利到链尾，特别是在链比较长的时候，性能是一个非常大的问题，二是调试不方便，环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂。
装饰模式：
装饰模式是动态地给一个对象添加一些额外的职责，就增加功能来说，装饰及模式相比生成子类更为灵活（成绩单）
优点：装饰类和被装饰类不会互相耦合，低耦合，装饰模式是继承关系的一个替代方案，装饰模式可以动态地扩展一个实现类的功能，类似于代理模式，扩展性非常好。
缺点：多层的装饰是很复杂的，如果最里层的装饰出现了问题，需要一层一层你排查，工作量会很大，系统的复杂度会升高。
使用环境：需要扩展一个类的功能额，或给一个类增加附加功能。
需要动态地给一个对象增加功能，这些功能可以再动态地撤销
需要为一批的兄弟类进行改装或加装功能，首选装饰模式。
策略模式：
定义一组算法，将每个算法都封装起来，并且使他们之间可以互换。（诸葛亮三个锦囊）
优点：策略模式本身定义的，只要实现抽象策略，他就成为策略家族的一个成员，通过封装角色对其进行封装，保障对外可以自由切换。
策略家族对外提供的访问接口就使封装类，简化了操作，同事避免了有条件语句判断
扩展性好，符合OCP原则。（开闭原则）
缺点：每个策略都是一个类，服用的可能性小，类数量增多。
上层模块必须知道有哪些策略，然后才能决定使用哪一个，这个与迪米特法则相违背。
类膨胀，对外暴露。
适配器模式：
将一个类的接口变成客户端所期待的另一种接口，从而使原本因接口不匹配而无法再一起工作的两个类能够在一起工作。
优点：让两个没有任何关系的类在一起运行，增加了类的透明性，具体的实现都委托给了源角色，而这些对高层次的模块使透明的，也是它不需要关心的，提高了类的复用度，灵活性特别好。
适配器模式使为了扩张而使用的，不应该在设计的时候考虑用它。
迭代器模式：
迭代器模式目前是一个没落的模式，基本上没人会单独写一个迭代器，除非是产品性质的开发，（它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节）
计量不要自己写迭代器模式，使用java提供的Iterator一般就能满足你的需求。
组合模式：
将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
把一组相似的对象当作一个单一的对象，比如说一个部门是一个对象，这个对象里面会有很多相似的对象。
观察者模式：
定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖与他的对象都会得到通知并被自动更新。（李斯监控韩非子）
优点：观察者和被观察者之间是抽象耦合，不管增加观察者还是被观察者都非常容易扩展，而且在java中都已经实现的抽象层级的定义，在系统扩展方面更是得心应手，建立一套触发机制，观察者可以完美地实现这里的链条形式。
缺点：一个被观察者，多个观察者，开发效率和运行效率问题需要考虑，在java中消息的通知默认是顺序执行，一个观察者卡死，会影响整体的执行效率，可以采用异步。
门面模式：
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，门面模式提供一个高层次的接口，使得子系统更易于使用。
门面模式注重”统一的对象“也就是提供一个访问一个子系统的接口，除了这个接口不允许有任何访问子系统的行为发生。
把子系统屏蔽掉，只暴露一个门面接口。
优点：外界只依赖门面对象，与子系统无关，提高了灵活性。安全性。
缺点：不符合开闭原则，对修改关闭，对扩展开放。
备忘录模式：
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象回复到原先保存的状态。
访问者模式：
封装一些作用于某些数据结构中的个元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
状态模式：
当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。状态模式的信心时分装，状态的变更引起了行为的变更。
优点：避免了过多的switch…case或者if…else语句的使用，避免劳累程序的复杂性，提高系统的可维护性
体现了开闭原则和单一职责原则，每个状态都是一个子类，你要增加状态就要增加子类，修改状态只修改一个子类，封装性好，符合门面模式
缺点：子类太多造成类膨胀。
解释器模式：
给定一门语言，定义它得文法得一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
优点：解释器是一个简单语法分析工具，它最显著的优点就是扩展性，修改语法规则只要修改相应的非终结符表达式就可以了，若扩展语法，则只要增加非终结符类就可以了。
缺点：解释器模式会引起类膨胀，解释器模式采用递归调用方法，还有一个效率问题。
享元模式：
享元模式是池技术的重要实现方式，使用共享对象可有效地支持大量的细粒度的对象，没有的对象直接直接创建，有的对象直接拿出来用例子中使用的是Hashmap。避免过多的对象造成内存溢出。
优点：可以减少应用程序创建的对象，降低程序内存占用，增强程序的性能。
缺点：系统的复杂性提高，需要分离出外部状态和内部状态，而且外部状态具有固化特性，不应该随内部状态改变而改变，否则导致系统的逻辑混乱。
桥梁模式：
将抽象和实现解耦，使得两者可以独立地变化，生产的工厂new 一个不同的类就可以生产不同的东西。
抽象角色引用实现角色，抽象角色的部分实现是由实现角色完成的。
优点：抽象和实现分离，解决继承的缺点而提出的设计模式，实现不受抽象的约束，不用再绑定再一个固定的抽象层次上。
优秀的扩充能力，对外暴露的接口层允许增加实现，增加抽象
客户不用关心细节的实现，它已经由抽象层通过聚合关系完成了封装。

深入理解java虚拟机

1.所有的对象实例以及数组都应当在堆上分配。

2.方法区与java堆一样，是各个线程共享的内存区域，他用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

3.运行时常量池时方法区的一部分，class文件中有一项信息时常量池表，用于存放编译期生成的各种字面量与符号引用，这部分讲在类加载后存放到方法区的运行时长常量池。

4.引用计数算法，通过计数器来判断对象是否失活，主流的java虚拟机里面没有选用应用计数算法来管理内存
原因：计数算法有很多例外情况要考虑，必须要配合大量额外处理才能保证正确地工作，譬如单纯的引用计数就很难解决对象之间相互循环引用的问题。

public class ReferenceCountingGC {
public Object instance = null;
private static final int _1MB = 1024 * 1024;
/**
* 这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否有回收过
*/
private byte[] bigSize = new byte[2 * _1MB];
public static void testGC() {
ReferenceCountingGC objA = new ReferenceCountingGC();
ReferenceCountingGC objB = new ReferenceCountingGC();
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
// 假设在这行发生GC，objA和objB是否能被回收？
System.gc();
}
}

可达性分析算法，

在主流的Java虚拟机中基本上采用的都是可达性分析算法来判断对象的存活。
这个算法是通过一些“GC Roots”的对象作为起点，从这些节点开始向下搜索，
搜索走过的路径称之为引用链，当一个对象到“GC Roots”没有任何引用链的时候，
也就是说这个对象到“GC Roots”不可达，证明这个对象是不能再被引用了
，因此就会被垃圾回收器判断为可以被回收的对象。在虚拟机中可以作为“GC Roots”的对象主要有四种：（1）虚拟机栈引用的对象（3）方法区常量引用的对象（4）本地方法栈中引用的对象
（有引用之后 GC Roots下面就会有引用链）

5.引用分为强引用，软引用，弱引用和虚引用四种，这4种引用强度依次逐渐减弱。

强引用不会被回收
软引用在内存不够的时候就会被回收
弱引用只能生存到下一次垃圾收集发生为止无论内存是否足够，都会回收掉弱引用关联的对象
为一个对象设置虚引用的目的是为了能在这个对象被收集器回收时收到一个系统通知。

6.任何一个对象的finalize()方法只会被系统自动调用一次。

7.方法区中的回收
(1)回收常量，只要这个常量并没有被任何地方引用，就可以回收
(2)回收类

①该类中所有的实例都已经被回收，也就是java堆中不存在该类及其任何派生子类的实例。
②加载该类的类加载器已经被回收，这个条件出给是经过精心设计的可替换类加载器的场景，
如osgi,jsp的重加载，否则通常是很难达成的
③该类对应得java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类得方法。