Android面试题总结（三）

一、android 四种更行UI的方式

使用handler.post(Runnable)更新UI

使用handler发送消息，handleMessage处理消息更新UI

使用UI线程runOnUiThread(new Runnable(){})更新UI

使用View.post( Runnable)更新UI

使用子线程自带的Looper更新UI:

private Handler handler2;
private HandlerThread thread;

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

myHandlerThread = (Button) findViewById(R.id.MyThreadHandler);
handlerThread = (Button) findViewById(R.id.HandlerThread);

//利用HandlerThread线程执行耗时操作，可以简单代替AsyncTask等。主线程给子线程发送消息
handlerThread.setOnClickListener(new OnClickListener() {

@Override
public void onClick(View v) {
thread=new HandlerThread("aaaa");
thread.start();
handler2=new Handler(thread.getLooper()){
@Override
public void handleMessage(Message msg) {
Toast.makeText(SecondActivity.this,    "this is HandlerThread", Toast.LENGTH_SHORT).show();
}
};
handler2.sendEmptyMessage(1);
}
});

二、死锁的四个必要条件以及怎样处理

http://www.cnblogs.com/jijiji/p/4855581.html

产生死锁的四个必要条件：

（1） 互斥条件：一个资源每次只能被一个进程使用。

（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。

（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。

（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。

举例说明： 资源A,B； 进程C,D

资源A,B都是不可剥夺资源：一个进程申请了之后，不能强制收回，只能进程结束之后自动释放。内存就是可剥夺资源

进程C申请了资源A，进程D申请了资源B。

接下来C的操作用到资源B，D的资源用到资源A。但是C,D都得不到接下来的资源，那么就引发了死锁。

死锁的解除与预防：

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源。因此，对资源的分配要给予合理的规划。

三、十个Android Material Design库

http://blog.csdn.net/tiankong1206/article/details/47057719

四、Android中IntentService与Service的区别

http://blog.csdn.net/matrix_xu/article/details/7974393

Service中提供了一个方法：onStartCommand(）

同时IntentService中提供了这么一个方法：onHandleIntent(Intent intent);

IntentService的内部实现：IntentService在执行onCreate的方法的时候，其实开了一个线程HandlerThread,并获得了当前线程队列管理的looper，并且在onStart的时候，把消息置入了消息队列，

在消息被handler接受并且回调的时候，执行了onHandlerIntent方法，该方法的实现是子类去做的。

IntentService是通过Handler looper message的方式实现了一个多线程的操作，同时耗时操作也可以被这个线程管理和执行，同时不会产生ANR的情况。

五、对称／非对称加密

对称加密与非对称加密

http://www.cnblogs.com/jfzhu/p/4020928.html

对称加密算法 VS 非对称加密算法

https://segmentfault.com/a/1190000004461428

白话解释 OSI模型，TLS/SSL 及 HTTPS

https://segmentfault.com/a/1190000004467714

JAVA加密算法（3）- 对称加密算法（DES、3DES、AES）

https://segmentfault.com/a/1190000007286619

Java实现非对称加密

https://segmentfault.com/a/1190000009081239

对称密钥加密（英语：Symmetric-key algorithm）又称为对称加密、私钥加密、共享密钥加密，是密码学中的一类加密算法。这类算法在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。实务上，这组密钥成为在两个或多个成员间的共同秘密，以便维持专属的通讯联系。与公开密钥加密相比，要求双方取得相同的密钥是对称密钥加密的主要缺点之一

明文 <-> 密钥 <-> 密文

常见的对称加密算法有DES、3DES、AES、Blowfish、IDEA、RC5、RC6。

每个人生成一个“私钥-公钥”对，这个私钥需要每个人自行进行保护！公钥可以随便分享，后面详细说，同时，生成的这个“私钥-公钥”对还有个强大的功能就是，使用私钥加密的信息，只能由该私钥对应的公钥才能解密，使用公钥加密的信息，只能由该公钥对应的私钥才能解密！公钥可以随意分发，所以即使别人截取了，也只是知道该公钥而已，但是要是想解密使用该公钥加密的密文！只有一个人可以办得到！就是张三！ 为什么？李四使用张三的公钥加密的信息，只有张三的公钥所对应的私钥，这里就是“张三私钥”，该私钥才可以解密！所以，没有张三私钥的第三方即时截取了这些密文，也破解不了！或者更严格的说在有限时间内比如说几千年内是暴力破解不出的！

公开密钥加密（英语：public-key cryptography，又译为公开密钥加密），也称为非对称加密（asymmetric cryptography），一种密码学算法类型，在这种密码学方法中，需要一对密钥，一个是私人密钥，另一个则是公开密钥。这两个密钥是数学相关，用某用户密钥加密后所得的信息，只能用该用户的解密密钥才能解密。如果知道了其中一个，并不能计算出另外一个。因此如果公开了一对密钥中的一个，并不会危害到另外一个的秘密性质。称公开的密钥为公钥；不公开的密钥为私钥。

这种加密算法应用非常广泛，SSH, HTTPS, TLS，电子证书，电子签名，电子身份证等等。

网警可以冒充张三！！！！发送给李四“网警的公钥”，而不是“张三的公钥”，那么当李四收到该公钥的时候，就不假思索的使用该公钥加密了他的信息，然后毫不犹豫的将加密的密文发了过去，然后网警得意的笑了。

应用层(application layer)

传输层(transport layer)

网络层(network layer)

数据链路层(data link layer)

物理层(physical layer)

物理层和数据链路层通过无线网传输使用的802.2传输协议，有线网的Ethernet(以太网)传输协议，还有网络层的IPv4, IPv6协议，传输层的TCP, UDP协议，而我们熟悉的HTTP协议其实属于应用层，所以HTTP是建立在TCP/IPv4或v6/以太网基础上进一步细化用于传输“超文本”信息的协议，比如FTP也属于应用层，也是在下面各层协议基础上进行细化，专门用于“文件传输”的协议。

TLS/SSL，SSL(secure sockets layer)是TLS(transport layer security)的前身，为什么将他们合起来的，大家可以理解成都属于同一东西的不同阶段吧，比如该协议之前叫SSL后来改名成TLS了。

为什么要有这种协议呢？因为HTTP是使用明文传输，随着网络的发展，安全性越来越重要，所以大家就要想办法让传输更加安全，同时使用密码学的成果，利用“非对称加密算法”的思想以及OSI模型，来对HTTP的信息进行加密。

信息从HTTP经过TLS/SSL非对称加密后传出去，而在接收方，接收到信息是需要一层层向上进行，经过每层的“解包/解密”，最终通过HTTP转换成超文本信息。

HTTPS 就是 “HTTP内容向下传输的时候加了一层TLS/SSL加密”

但是同样的问题，就是我们怎么知道我们使用的公钥就是银行给我们的呢？即使我们所访问的域名和银行的域名一致，因为黑客完全可以通过修改我们本地的hosts文件，或者入侵dns，将域名映射到黑客的服务器。

所以，这就是CA(certificate authority)，数字证书，数字签名，公钥基础设施(PKI)等等名词的来历。

HTTP协议如何使用 TCP 连接:

HTTP对 TCP 连接的使用，分为两种方式：俗称“短连接”和“长连接”（“长连接”又称“持久连接”，叫做“Keep-Alive”或“Persistent Connection”）

SSL/TLS协议的基本运行过程

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密，但是这里有两个问题：

（1）如何保证公钥不被篡改？

解决方法：将公钥放在数字证书中，只要证书是可信的，公钥就是可信的。

（2）公钥加密计算量太大，如何减少耗用的时间？

解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS协议的基本过程是这样的：

（1）客户端向服务器端索要并验证公钥。

（2）双方协商生成“对话密钥”。

（3）双方采用“对话密钥”进行加密通信。

上面过程的前两步，又称为“握手阶段”（handshake）。

以上图片就是“握手阶段”涉及四次通信，需要注意的是，“握手阶段”的所有通信都是明文的。

SSL是Netscape公司所提出的安全保密协议，在浏览器(如Internet Explorer、Netscape Navigator)和Web服务器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之间构造安全通道来进行数据传输，SSL运行在TCP/IP层之上、应用层之下，为应用程序提供加密数据通道，它采用了RC4、MD5 以及RSA等加密算法，使用40位的密钥，适用于商业信息的加密。

HTTPS实际上就是SSL over HTTP，它使用默认端口443，而不是像HTTP那样使用端口80来和TCP/IP进行通信。HTTPS协议使用SSL在发送方把原始数据进行加密，然后在接受方进行解密，加密和解密需要发送方和接受方通过交换共知的密钥来实现。

HTTPS协议的需求是什么？

一般来说，HTTPS和HTTP的区别主要为以下四点：

（1）、https协议需要到ca申请证书，一般免费证书很少，需要交费。

（2）、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

（3）、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

（4）、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

六、热修复、插件化技术

热修复 有demo

http://blog.csdn.net/yangxi_pekin/article/details/54929740

Android 热补丁动态修复框架小结

http://blog.csdn.net/lmj623565791/article/details/49883661

Android插件化

http://www.infoq.com/cn/articles/android-plug-ins-from-entry-to-give-up

轻量级插件化框架——Small

http://www.jianshu.com/p/7990714d10cb

Android组件化和插件化开发

http://www.cnblogs.com/android-blogs/p/5703355.html

从模块化到组件化再到插件化

http://blog.csdn.net/u011486491/article/details/70216666

插件化需要掌握的知识：

学习Binder的最好方式就是AIDL

其次，是App打包的流程。

第三，App在手机上的安装流程也很重要

第四，是App的启动流程。

第五，插件Dex的加载，如何把插件Dex中的类加载到内存；资源加载的问题。一种是是重写Context的getAsset、getResource之类的方法，偷换概念，让插件读取插件里的资源，但缺点就是宿主和插件的资源id会冲突，需要重写AAPT。另一种是重写AMS中保存的插件列表，从而让宿主和插件分别去加载各自的资源而不会冲突。第三种方法，就是打包后，执行一个脚本，修改生成包中资源id。

第六点，在实施插件化后，如何解决不同插件的开发人员的工作区问题。就要用到Gradle脚本了，每个项目分别有各自的仓库，有各自不同的打包脚本，只需要把自己的插件跟宿主项目一起打包运行起来，而不用引入其他插件，还有更厉害的是，也可以把自己的插件当作一个App来打包并运行。

技术流派，目前分三种

第一种是动态替换，也就是Hook。可以直接在Activity里做Hook，重写getAsset的几个方法，从而使用自己的ResourceManager和AssetPath；也可以在更抽象的层面，也就是在startActivity方法的位置做Hook，涉及的类包括ActivityThread、Instrumentation等；最高层次则是在AMS上做修改，也就是张勇的解决方案，这里需要修改的类非常多，AMS、PMS等都需要改动。

第二种是静态代理，这是任玉刚的框架采取的思路。写一个PluginActivity继承自Activity基类，把Activity基类里面涉及生命周期的方法全都重写一遍，插件中的Activity是没有生命周期的，所以要让插件中的Activity都继承自PluginActivity，这样就有生命周期了。

Dex合并就是Android热修复的思想。刚才说到了两个项目——AndFix和Nuwa，它们的思想是相同的。原生Apk自带的Dex是通过PathClassLoader来加载的，而插件Dex则是通过DexClassLoader来加载的。但有一个顺序问题，是由Davlik的机制决定的，如果宿主Dex和插件Dex都有一个相同命名空间的类的方法，那么先加载哪个Dex，哪个Dex中的这个类的方法将会占山为王，后面其他同名方法都替换了。所以，AndFix热修复就是优先加载插件包中的Dex，从而实现热修复。由于热修复的插件包通常只包括一个类的方法，体量很小，和正常的插件不是一个数量级的，所以只称为热修复补丁包，而不是插件。

技术周边

首先是AAPT，资源冲突，就是说默认App应用，插件里的资源和数据资源冲突，如果不引入这个资源，相安无事。很多时候就算有冲突也无所谓，问题就出在插件引用资源的时候有冲突了，无法解决，怎么办？那就要立刻改写App。有一个关于打包的App，可以加当前的前缀，改成你想要的。比如，火车票和酒店分别取名，这样就可以指定前缀、打包，插进一个模块，资源的前缀都不一样。小米也承认，会占用0x11这个前缀。这是需要关注的一个点。

第二是增量更新。360目前最牛逼的地方是，把所有数据跟之前一个版本差，产生增量的数据。他们当然也更新了插件化。360的刘存栋做了一个增量更新的框架。可以在后台服务器把两个版本的Android App做拆分，然后把增量包下载到本地，再跟本地进行合并，提供一个STK，再合在一起，这就是增量更新。

第三是插件管理平台，要管理每个版本的差异、每个插件最低数据的版本号。

七、JNI中C调用Java方法

http://blog.csdn.net/xyang81/article/details/42582213

第一步：调用FindClass函数，传入一个Class描述符，JVM会从classpath路径下搜索该类，并返回jclass类型（用于存储Class对象的引用）。注意ClassMethod的Class描述符为com/study/jnilearn/ClassMethod，要将.（点）全部换成/（反斜杠）；

第二步：调用GetStaticMethodID函数，从ClassMethod类中获取callStaticMethod方法ID，返回jmethodID类型（用于存储方法的引用）。实参clazz是第一步找到的jclass对象，实参”callStaticMethod”为方法名称，实参“(Ljava/lang/String;I)V”为方法的签名

第三步：调用CallStaticVoidMethod函数，执行ClassMethod.callStaticMethod方法调用。str_arg和100是callStaticMethod方法的实参。

第四步、释放局部变量

八、以操作系统的角度述说线程与进程

http://blog.csdn.net/luoweifu/article/details/46595285

大部分操作系统(如Windows、Linux)的任务调度是采用时间片轮转的抢占式调度方式，也就是说一个任务执行一小段时间后强制暂停去执行下一个任务，每个任务轮流执行。任务执行的一小段时间叫做时间片，任务正在执行时的状态叫运行状态，任务执行一段时间后强制暂停去执行下一个任务，被暂停的任务就处于就绪状态等待下一个属于它的时间片的到来。这样每个任务都能得到执行，由于CPU的执行效率非常高，时间片非常短，在各个任务之间快速地切换，给人的感觉就是多个任务在“同时进行”，这也就是我们所说的并发(别觉得并发有多高深，它的实现很复杂，但它的概念很简单，就是一句话：多个任务同时执行)。

进程

进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。进程是一种抽象的概念，从来没有统一的标准定义。进程一般由程序、数据集合和进程控制块三部分组成。

进程具有的特征：

动态性：进程是程序的一次执行过程，是临时的，有生命期的，是动态产生，动态消亡的；

并发性：任何进程都可以同其他进程一起并发执行；

独立性：进程是系统进行资源分配和调度的一个独立单位；

结构性：进程由程序、数据和进程控制块三部分组成。

线程

线程是程序执行中一个单一的顺序控制流程，是程序执行流的最小单元，是处理器调度和分派的基本单位。一个进程可以有一个或多个线程，各个线程之间共享程序的内存空间(也就是所在进程的内存空间)。一个标准的线程由线程ID、当前指令指针(PC)、寄存器和堆栈组成。而进程由内存空间(代码、数据、进程空间、打开的文件)和一个或多个线程组成。

九、synchronized用法，volatile用法

synchronized是Java中的关键字，是一种同步锁。它修饰的对象有以下几种：

1. 修饰一个代码块，被修饰的代码块称为同步语句块，其作用的范围是大括号{}括起来的代码，作用的对象是调用这个代码块的对象；

2. 修饰一个方法，被修饰的方法称为同步方法，其作用的范围是整个方法，作用的对象是调用这个方法的对象；

3. 修饰一个静态的方法，其作用的范围是整个静态方法，作用的对象是这个类的所有对象；

4. 修饰一个类，其作用的范围是synchronized后面括号括起来的部分，作用的对象是这个类的所有对象。

一个线程访问一个对象中的synchronized(this)同步代码块时，其他试图访问该对象的线程将被阻塞。谁拿到那个锁谁就可以运行它所控制的那段代码。

修饰方法范围是整个函数。

public synchronized void method()

{

// todo

}

public void method()

{

synchronized(this) {

// todo

}

}

写法一修饰的是一个方法，写法二修饰的是一个代码块，但写法一与写法二是等价的，都是锁定了整个方法时的内容。

A. 无论synchronized关键字加在方法上还是对象上，如果它作用的对象是非静态的，则它取得的锁是对象；如果synchronized作用的对象是一个静态方法或一个类，则它取得的锁是对类，该类所有的对象同一把锁。

B. 每个对象只有一个锁（lock）与之相关联，谁拿到这个锁谁就可以运行它所控制的那段代码。

C. 实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。

Java中Volatile关键字详解

http://www.cnblogs.com/zhengbin/p/6407137.html

Java 内存模型中的可见性、原子性和有序性。

可见性，是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果。另一个线程马上就能看到。比如：用volatile修饰的变量，就会具有可见性。volatile修饰的变量不允许线程内部缓存和重排序，即直接修改内存。所以对其他线程是可见的。但是这里需要注意一个问题，volatile只能让被他修饰内容具有可见性，但不能保证它具有原子性。比如 volatile int a = 0；之后有一个操作 a++；这个变量a具有可见性，但是a++ 依然是一个非原子操作，也就是这个操作同样存在线程安全问题。volatile、synchronized 和 final 实现可见性。

原子是世界上的最小单位，具有不可分割性。比如 a=0；（a非long和double类型） 这个操作是不可分割的，那么我们说这个操作时原子操作。再比如：a++； 这个操作实际是a = a + 1；是可分割的，所以他不是一个原子操作。非原子操作都会存在线程安全问题，需要我们使用同步技术（sychronized）来让它变成一个原子操作。一个操作是原子操作，那么我们称它具有原子性。java的concurrent包下提供了一些原子类，我们可以通过阅读API来了解这些原子类的用法。比如：AtomicInteger、AtomicLong、AtomicReference等。 synchronized 和在 lock、unlock 中操作保证原子性。

volatile 和 synchronized 两个关键字来保证线程之间操作的有序性，volatile 是因为其本身包含“禁止指令重排序”的语义，synchronized 是由“一个变量在同一个时刻只允许一条线程对其进行 lock 操作”这条规则获得的，此规则决定了持有同一个对象锁的两个同步块只能串行执行。

Volatile原理

用来确保将变量的更新操作通知到其他线程。当把变量声明为volatile类型后，编译器与运行时都会注意到这个变量是共享的，因此不会将该变量上的操作与其他内存操作一起重排序。volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会返回最新写入的值。

在访问volatile变量时不会执行加锁操作，因此也就不会使执行线程阻塞，因此volatile变量是一种比sychronized关键字更轻量级的同步机制。



声明变量是 volatile 的，JVM 保证了每次读变量都从内存中读，跳过 CPU cache 这一步。

volatile 的读性能消耗与普通变量几乎相同，但是写操作稍慢，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。

http://www.cnblogs.com/zhengbin/category/787240.html

十、网络请求缓存处理

HTTP请求信息由3部分组成：

l 请求方法URI协议/版本

l 请求头(Request Header)

l 请求正文

HTTP响应

HTTP应答与HTTP请求相似，HTTP响应也由3个部分构成，分别是：

l 　状态行

l 　响应头(Response Header)

l 　响应正文

在接收和解释请求消息后，服务器会返回一个HTTP响应消息。

状态行由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔。

格式: HTTP-Version Status-Code Reason-Phrase CRLF

详细解读LruCache类

http://www.cnblogs.com/tianzhijiexian/p/4248677.html

缓存处理可以把请求到的结果写到一定大小的内存缓存中，可以使用L ruCache 也可以自己实现最近最少使用算法，将文件存入LinkedHashMap （加同步锁）或者Collections.synchronizedMap(new HashMap

final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);

// 取八分之一的可用内存作为缓存
final int cacheSize = maxMemory / 8;

okhttp如何处理网络缓存的

十一、动态权限适配方案，权限组的概念

http://blog.csdn.net/xc765926174/article/details/49103483

十二、图片加载库相关

Glide 与Picasso 对比

https://inthecheesefactory.com/blog/get-to-know-glide-recommended-by-google/en

https://www.zhihu.com/question/40028112

bitmap如何处理大图，如一张30M的大图，如何预防OOM

http://blog.csdn.net/hello_12413/article/details/48261503

读取Bitmap尺寸和类型，设置inJustDecodeBounds 为true,解码的时候会避免内存的分配，返回的bitmap对象为空，但是却可以得到 outWidth, outHeight 和outMimeType。

加载一个按比例缩小版本到内存中

告诉解码器对Image进行采样，加载一个较小版本图片到内存中，设置BitmapFactory.Options 对象inSampleSize为true。比如一个2048*1536密度的图片，inSampleSize为4生成的样品图就是512*384。

设置inJustDecodeBounds = true,然后通过新的inSampleSize解码，最后设置inJustDecodeBounds = false。

Android bitmap图片处理

http://www.cnblogs.com/an-ly/p/5333622.html

十三 、进程保活

http://blog.csdn.net/u013263323/article/details/56285475

空进程都被杀光了，现在要杀后台进程，进程是有它的优先级的，这个优先级通过进程的adj值来反映，它是linux内核分配给每个系统进程的一个值，代表进程的优先级，进程回收机制就是根据这个优先级来决定是否进行回收，adj值定义在com.android.server.am.ProcessList类中，这个类路径是${android-sdk-path}\sources\android-23\com\android\server\am\ProcessList.java。oom_adj的值越小，进程的优先级越高，普通进程oom_adj值是大于等于0的，而系统进程oom_adj的值是小于0的，我们可以通过cat /proc/进程id/oom_adj可以看到当前进程的adj值。

oom_adj越大，占用物理内存越多会被最先kill掉，OK，那么现在对于进程如何保活这个问题就转化成，如何降低oom_adj的值，以及如何使得我们应用占的内存最少。

一、进程保活方案

1、开启一个像素的Activity

据说这个是手Q的进程保活方案，基本思想，系统一般是不会杀死前台进程的。所以要使得进程常驻，我们只需要在锁屏的时候在本进程开启一个Activity，为了欺骗用户，让这个Activity的大小是1像素，并且透明无切换动画，在开屏幕的时候，把这个Activity关闭掉，所以这个就需要监听系统锁屏广播，

在屏幕关闭的时候把LiveActivity启动起来，在开屏的时候把LiveActivity 关闭掉，所以要监听系统锁屏广播，以接口的形式通知MainActivity启动或者关闭LiveActivity。

但是还有一个问题，内存也是一个考虑的因素，内存越多会被最先kill掉，所以把上面的业务逻辑放到Service中，而Service是在另外一个 进程中，在MainActivity开启这个服务就行了，这样这个进程就更加的轻量，通过上面的操作，我们的应用就始终和前台进程是一样的优先级了，为了省电，系统检测到锁屏事件后一段时间内会杀死后台进程，如果采取这种方案，就可以避免了这个问题。但是还是有被杀掉的可能，所以我们还需要做双进程守护，关于双进程守护，比较适合的就是aidl的那种方式，但是这个不是完全的靠谱，原理是A进程死的时候，B还在活着，B可以将A进程拉起来，反之，B进程死的时候，A还活着，A可以将B拉起来。所以双进程守护的前提是，系统杀进程只能一个个的去杀，如果一次性杀两个，这种方法也是不OK的。

2、前台服务

原理如下

对于 API level < 18 ：调用startForeground(ID， new Notification())，发送空的Notification ，图标则不会显示。

对于 API level >= 18：在需要提优先级的service A启动一个InnerService，两个服务同时startForeground，且绑定同样的 ID。Stop 掉InnerService ，这样通知栏图标即被移除。

3、相互唤醒

假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app，那么你打开任意一个阿里系的app后，有可能就顺便把其他阿里系的app给唤醒了。

4、JobSheduler

JobSheduler是作为进程死后复活的一种手段，native进程方式最大缺点是费电， Native 进程费电的原因是感知主进程是否存活有两种实现方式，在 Native 进程中通过死循环或定时器，轮训判断主进程是否存活，当主进程不存活时进行拉活。其次5.0以上系统不支持。 但是JobSheduler可以替代在Android5.0以上native进程方式，这种方式即使用户强制关闭，也能被拉起来

5、粘性服务&与系统服务捆绑

这个是系统自带的，onStartCommand方法必须具有一个整形的返回值，这个整形的返回值用来告诉系统在服务启动完毕后，如果被Kill，系统将如何操作，这种方案虽然可以，但是在某些情况or某些定制ROM上可能失效，我认为可以多做一种保保守方案。

NotificationListenerService，NotificationListenerService就是一个监听通知的服务，只要手机收到了通知，NotificationListenerService都能监听到，即时用户把进程杀死，也能重启

十四、listview图片加载错乱的原理和解决方案

产生图片错位的原理：

如果我们只是简单显示list中数据，而没用convertview的复用机制和异步操作，就不会产生图片错位；重用convertview但没用异步，也不会有错位现象。但我们的项目中list一般都会用，不然会很卡。

我们能看到listview中整屏刚好显示7个item，当向下滑动时，显示出item8，而item8是重用的item1，如果此时异步网络请求item8的图片，比item1的图片慢，那么item8就会显示item1的image。当item8下载完成，此时用户向上滑显示item1时，又复用了item8的image，这样就导致了图片错位现象(item1和item8是用的同一块内存哦)

解决方法：

对imageview设置tag，并预设一张图片。

向下滑动后，item8显示，item1隐藏。但由于item1是第一次进来就显示，所以一般情况下，item1都会比item8先下载完，但由于此时可见的item8的tag，和隐藏了的item1的url不匹配，所以就算item1的图片下载完也不会显示到item8中，因为tag标识的永远是可见图片中的url。

// 给 ImageView 设置一个 tag

holder.img.setTag(imgUrl);

// 预设一个图片

holder.img.setImageResource(R.drawable.ic_launcher);

// 通过 tag 来防止图片错位

if (imageView.getTag() != null && imageView.getTag().equals(imageUrl)) {

imageView.setImageBitmap(result);

}

Android ListView异步加载图片乱序问题，原因分析及解决方案

http://blog.csdn.net/guolin_blog/article/details/45586553

ListView在借助RecycleBin机制的帮助下，实现了一个生产者和消费者的模式，不管有任意多条数据需要显示，ListView中的子View其实来来回回就那么几个，移出屏幕的子View会很快被移入屏幕的数据重新利用起来。

ImageView控件的个数其实就比一屏能显示的图片数量稍微多一点而已，移出屏幕的ImageView控件会进入到RecycleBin当中，而新进入屏幕的元素则会从RecycleBin中获取ImageView控件。

每当有新的元素进入界面时就会回调getView()方法，而在getView()方法中会开启异步请求从网络上获取图片，注意网络操作都是比较耗时的，也就是说当我们快速滑动ListView的时候就很有可能出现这样一种情况，某一个位置上的元素进入屏幕后开始从网络上请求图片，但是还没等图片下载完成，它就又被移出了屏幕。这种情况下会产生什么样的现象呢？根据ListView的工作原理，被移出屏幕的控件将会很快被新进入屏幕的元素重新利用起来，而如果在这个时候刚好前面发起的图片请求有了响应，就会将刚才位置上的图片显示到当前位置上，因为虽然它们位置不同，但都是共用的同一个ImageView实例，这样就出现了图片乱序的情况。

但是还没完，新进入屏幕的元素它也会发起一条网络请求来获取当前位置的图片，等到图片下载完的时候会设置到同样的ImageView上面，因此就会出现先显示一张图片，然后又变成了另外一张图片的情况，那么刚才我们看到的图片会自动变来变去的情况也就得到了解释。

解决方案一 使用findViewWithTag

定义一个全局变量mListView，然后在getView()方法中判断它是否为空，如果为空就把parent这个参数赋值给它。在getView()方法中我们还做了一个操作，就是调用了ImageView的setTag()方法，并把当前位置图片的URL地址作为参数传了进去，这个是为后续的findViewWithTag()方法做准备。异步下载成功后，ListView的findVIewWithTag()方法来去获取ImageView控件的实例。

解决方案二 使用弱引用关联

ImageView和BitmapWorkerTask之间建立一个双向关联，互相持有对方的引用，再通过适当的逻辑判断来解决图片乱序问题，然后为了防止出现内存泄漏的情况，双向关联要使用弱引用的方式建立。相比于第一种解决方案，第二种解决方案要明显复杂不少，但在性能和效率方面都会有更好的表现。

cancelPotentialWork（）取消掉后台的潜在任务，当认为当前ImageView存在着一个另外图片请求任务时 ，则把它取消掉并返回true，否则返回false。

这个双向弱引用关联是怎么建立的。BitmapWorkerTask指向ImageView的弱引用关联比较简单，就是在BitmapWorkerTask中加入一个构造函数，并在构造函数中要求传入ImageView这个参数。不过我们不再直接持有ImageView的引用，而是使用WeakReference对ImageView进行了一层包装

解决方案三 使用NetworkImageView

NetworkImageView是Volley当中提供的控件不需要自己再去写一个BitmapWorkerTask来处理图片的下载和显示，也不需要自己再去管理LruCache的逻辑，一切NetworkImageView都帮我们做好了。调用cancelRequest()方法把请求取消掉就可以了，这主要是得益于Volley的出色设计。Volley只是保证取消掉的请求不会进行回调而已，但并没有说可以中断任何请求。由此可见即使是Volley也无法做到中断一个正在执行的线程，如果有一个线程正在执行，Volley只会保证在它执行完之后不会进行回调，但在调用者看来，就好像是这个请求就被取消掉了一样。

十五、https相关，如何验证证书的合法性，https中哪里用了对称加密，哪里用了非对称加密，对加密算法（如RSA）等是否有了解

RSA性能是非常低的，原因在于寻找大素数、大数计算、数据分割需要耗费很多的CPU周期，所以一般的HTTPS连接只在第一次握手时使用非对称加密，

（之前步骤的1-4）通过握手交换对称加密密钥（之前步骤的5-6），在之后的通信走对称加密（之前步骤的7-8）。

客户端发起HTTPS请求

用户在浏览器里输入一个https网址，然后连接到server的443端口。

服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是非对称加密中的公钥和私钥。

传送证书

下发的证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

客户端解析证书

这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（后续对称加密中用的私匙）然后用证书(客户端下发的公匙)对该随机值(客户端生成的私匙)进行加密。

传送加密信息

传送的是用证书加密后的随机值(客户端私匙)，目的就是让服务端得到客户端生成的私匙，以后客户端和服务端的通信就可以走对称加密流程了，也就是通过这个客户端产生的私匙来进行加密解密了。

服务段解密信息

服务端用私钥(这个是第2步中和公匙对应的非对称加密的私匙)解密后，得到了客户端传过来的随机值(对称加密的私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

传输加密后的信息

这部分信息是服务段用对称加密私钥加密后的信息，可以在客户端被还原

客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

https相关，如何验证证书的合法性

客户端内置真正的公钥，当代理服务器把它自己的证书传过来的时候，客户端用内置的公钥去解密证书中的签名，因为不是真正的私钥加密的所以解密失败，校验也就失败，连接中断。

try {
//载入证书
SSLSocketFactory factory = setCertificates(getAssets().open("https.cer"));
if (factory != null) {
httpClientBuilder.sslSocketFactory(factory);
}
} catch (IOException e) {
e.printStackTrace();
}
/**
* 载入证书
*/
private SSLSocketFactory setCertificates(InputStream... certificates) {
try {
CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
keyStore.load(null);
int index = 0;
for (InputStream certificate : certificates) {
String certificateAlias = Integer.toString(index++);
keyStore.setCertificateEntry(certificateAlias, certificateFactory.generateCertificate(certificate));
try {
if (certificate != null) {
certificate.close();
}
} catch (IOException e) {
e.printStackTrace();
}
}
SSLContext sslContext = SSLContext.getInstance("TLS");
TrustManagerFactory trustManagerFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(keyStore);
sslContext.init(
null,
trustManagerFactory.getTrustManagers(),
new SecureRandom()
);
return sslContext.getSocketFactory();
} catch (Exception e) {
e.printStackTrace();
return null;
}
}

十六、APK 瘦身

http://blog.csdn.net/mynameishuangshuai/article/details/51752832

http://blog.csdn.net/mynameishuangshuai/article/details/51766185

http://www.cnblogs.com/qianxudetianxia/p/5230154.html

图片资源瘦身

项目结构瘦身

代码瘦身