㈠ android 怎么处理线程安全
UI线程及Android的单线程模型原则当应用启动，系统会创建一个主线程（main thread）。这个主线程负责向UI组件分发事件（包括绘制事件），也是在这个主线程里，应用和Android的UI组件（components from the Android UI toolkit (components from the android.widget and android.view packages)）发生交互。 当App做一些比较重（intensive）的工作的时候，除非合理地实现，否则单线程模型的performance会很poor。特别的是，如果所有的工作都在UI线程，做一些比较耗时的工作比如访问网络或者数据库查询，都会阻塞UI线程，导致事件停止分发（包括绘制事件）。对于用户来说，应用看起来像是卡住了，更坏的情况是，如果UI线程blocked的时间太长（大约超过5秒），用户就会看到ANR（application not responding）的对话框。 另外，Andoid UI toolkit并不是线程安全的，所以不能从非UI线程来操纵UI组件。必须把所有的UI操作放在UI线程里，所以Android的单线程模型有两条原则： 1.不要阻塞UI线程。 2.不要在UI线程之外访问Android UI toolkit（主要是这两个包中的组件：android.widget and android.view）。
㈡ 盘点im即时通讯开发中Android后台保活方案
对于IM应用和消息推送服务的开发者来说，在Android机型上的后台保活是个相当头疼的问题。
老板一句：“为什么微信、QQ能收到消息，而你写的APP却不行？”，直接让人崩溃，话说老板你这APP要是整成微信、APP那么牛，直接进手机厂商白名单，还要程序员在这瞎忙活？
好了，抱怨归抱怨，活还得干，不然靠谁养活广大苦逼的程序员？
正因为Android系统版本的差异，也导致了各种保活黑科技的运行效果大相径庭，所以本文正好借此机会，盘点一下当前主流（截止2019年前）的保活黑科技在市面上各版本Android手机上的运行效果，希望能给大家提供一些客观的参考。
其实Android端APP搞保活的目的倒不是为了干什么见不得人的坏事（但不排除动机不纯的开发者），主要是像IM即时通讯应用和资讯类应用等需要搞后台消息推送、运动类应用需要在后台实时监测用户的运动数据等，因为现在越来越多的手机厂商为了省电策略考虑，基本上如果你的应用没有被加入白名单，一旦处于后台就会被系统限制甚至干掉，但使用APP的用户才不听你这些解释——反正“我”就要你的APP能如期正常运行，开发者也是不得已而为之。
以消息推送为例，当APP处于后台或关闭时，消息推送对于某些应用来说非常有用，比如：
1）IM即时通讯聊天应用：聊天消息通知、音视频聊天呼叫等，典型代表有：微信、QQ、易信、米聊、钉钉、Whatsup、Line；
2）新闻资讯应用：最新资讯通知等，典型代表有：网易新闻客户端、腾讯新闻客户端；
3）SNS社交应用：转发/关注/赞等通知，典型代表有：微博、知乎；
4）邮箱客户端：新邮件通知等，典型代表有：QQ邮箱客户端、Foxmail客户端、网易邮箱大师；
5）金融支付应用：收款通知、转账通知等，典型代表有：支付宝、各大银行的手机银行等；
.... ....
在上述的各种应用中，尤其对于用户接触最多、最平常的IM聊天应用或新闻资讯来说，保活和消息推送简直事关APP的“生死”，消息推送这种能力已经被越来越多的APP作为基础能力之一，因为移动互联网时代下，用户的“全时在线”能力非常诱人和强大，能随时随地即时地将各种重要信息推送给用户，无疑是非常有意义的。
题外话：实际上，对于后台消息推送能力，Android原版系统早就内置了系统级推送服务（跟iOS上的APNs服务是一个东西），它就是GCM服务（现在升级为FCM了），但众所周之的原因，谷哥的服务在国内都是用不了的（你懂的）——无奈啊！
主要黑科技方案有：
1）监听广播：监听全局的静态广播，比如时间更新的广播、开机广播、解锁屏、网络状态、解锁加锁亮屏暗屏（3.1版本），高版本需要应用开机后运行一次才能监听这些系统广播，目前此方案失效。可以更换思路，做APP启动后的保活（监听广播启动保活的前台服务）；
2）定时器、JobScheler：假如应用被系统杀死，那么定时器则失效，此方案失效。JobService在5.0,5.1,6.0作用很大，7.0时候有一定影响（可以在电源管理中给APP授权）；
3）双进程（NDK方式Fork子进程）、双Service守护：高版本已失效，5.0起系统回收策略改成进程组。双Service方案也改成了应用被杀，任何后台Service无法正常状态运行；
4）提高Service优先级：只能一定程度上缓解Service被立马回收。 即时通讯聊天软件app开发可以咨询蔚可云。
针对上述方案，具体的实现思路，通常是这样的：
1）进程拉活：AIDL方式单进程、双进程方式保活Service（最极端的例子就是推送厂商的互相唤醒复活：极光、友盟、以及各大厂商的推送，同派系APP广播互相唤醒：比如今日头条系、阿里系）；
2）降低oom_adj的值：常驻通知栏（可通过启动另外一个服务关闭Notification，不对oom_adj值有影响）、使用”1像素“的Activity覆盖在getWindow()的view上（据传某不可言说的IM大厂用过这个方案，虽然他们从未正面承认过）、循环播放无声音频（黑科技，7.0下杀不掉）；
3）监听锁屏广播：使Activity始终保持前台；
4）使用自定义锁屏界面：覆盖了系统锁屏界面；
5）创建子进程：通过android:process属性来为Service创建一个进程；
6）白名单：跳转到系统白名单界面让用户自己添加app进入白名单。
使用AIDL绑定方式新建2个Service优先级（防止服务同时被系统杀死）不一样的守护进程互相拉起对方，并在每一个守护进程的ServiceConnection的绑定回调里判断保活Service是否需要重新拉起和对守护线程进行重新绑定。
后台播放音乐这种保活方法，亲身经历过：
记得当时用的是某运动记步APP，它为了保活就是这么干的。之所以被我发现，是因为在我的Android手机上，每次打开这个APP居然总能莫名其妙听到若有若无的环境噪音样的声音，尤其安静的场所下更明显。我个人估计这个APP里用的保活音频文件，很可能就是程序员在简陋的条件下随手自已录制的，虽然也是不得以为之，但做法确实是有点粗糙。
总结一下，以上方案在当前主流手机上的运行效果
【1】双进程守护方案（基于onStartCommand() return START_STICKY）：
1）原生5.0、5.1：原生任务栏滑动清理app，Service会被杀掉，然后被拉起，接着一直存活；
2）金立F100(5.1)：一键清理直接杀掉整个app，包括双守护进程。不手动清理情况下，经测试能锁屏存活至少40分钟；
3）华为畅享5x（6.0）：一键清理直接杀掉整个app，包括双守护进程。不手动清理下，锁屏只存活10s。结论：双进程守护方案失效；
4）美图m8s(7.1.1)：一键清理直接杀掉整个app，包括双守护进程。不清理情况下，锁屏会有被杀过程（9分钟左右被杀），之后重新复活，之后不断被干掉然后又重新复活。结论：双守护进程可在后台不断拉起Service；
5）原生7.0：任务栏清除APP后，Service存活。使用此方案后Service照样存活；
6）LG V30+(7.1.2)：不加双进程守护的时候，一键清理无法杀掉服务。加了此方案之后也不能杀掉服务，锁屏存活（测试观察大于50分钟）；
7）小米8(8.1)：一键清理直接干掉app并且包括双守护进程。不清理情况下，不加守护进程方案与加守护进程方案Service会一直存活，12分钟左右closed。结论：此方案没有起作用。
▲ 结论：除了华为此方案无效以及未更改底层的厂商不起作用外（START_STICKY字段就可以保持Service不被杀）。此方案可以与其他方案混合使用。
【2】监听锁屏广播打开1像素Activity（基于onStartCommand() return START_STICKY）：
1）原生5.0、5.1：锁屏后3s服务被干掉然后重启（START_STICKY字段起作用）；
2）华为畅享5x（6.0）：锁屏只存活4s。结论：方案失效；
3）美图m8s(7.1.1)：同原生5.0；
4）原生7.0：同美图m8s；
5）LG V30+(7.1.2)：锁屏后情况跟不加情况一致，服务一致保持运行，结论：此方案不起作用；
6）小米8(8.1)：关屏过2s之后app全部被干掉。结论：此方案没有起作用。
▲ 结论：此方案无效果。
【3】故意在后台播放无声的音乐（基于onStartCommand() return START_STICKY）：
1）原生5.0、5.1：锁屏后3s服务被干掉然后重启（START_STICKY字段起作用）；
2）华为畅享5x（6.0）：一键清理后服务依然存活，需要单独清理才可杀掉服务，锁屏8分钟后依然存活。结论：此方案适用；
3）美图m8s(7.1.1)：同5.0；
4）原生7.0：任务管理器中关闭APP后服务被干掉，大概过3s会重新复活（同仅START_STICKY字段模式）。结论：看不出此方案有没有其作用；
5）LG V30+(7.1.2)：使用此方案前后效果一致。结论：此方案不起作用；
6）小米8(8.1)：一键清理可以杀掉服务。锁屏后保活超过20分钟。
▲ 结论：成功对华为手机保活。小米8下也成功突破20分钟。
【4】使用JobScheler唤醒Service（基于onStartCommand() return START_STICKY）：
1）原生5.0、5.1：任务管理器中干掉APP，服务会在周期时间后重新启动。结论：此方案起作用；
2）华为畅享5x（6.0）：一键清理直接杀掉APP，过12s左右会自动重启服务，JobScheler起作用；
3）美图m8s(7.1.1)：一键清理直接杀掉APP，无法自动重启；
4）原生7.0：同美图m8s(7.1.1)；
5）小米8(8.1)：同美图m8s(7.1.1)。
▲ 结论：只对5.0，5.1、6.0起作用。
【5】混合使用的效果，并且在通知栏弹出通知：
1）原生5.0、5.1：任务管理器中干掉APP，服务会在周期时间后重新启动。锁屏超过11分钟存活；
2）华为畅享5x（6.0）：一键清理后服务依然存活，需要单独清理才可杀掉服务。结论：方案适用；
3）美图m8s(7.1.1)：一键清理APP会被杀掉。正常情况下锁屏后服务依然存活；
4）原生7.0：任务管理器中关闭APP后服务被干掉，过2s会重新复活；
5）小米8(8.1)：一键清理可以杀掉服务，锁屏下后台保活时间超过38分钟；
6）荣耀10（8.0）：一键清理杀掉服务，锁屏下后台保活时间超过23分钟。
㈢ Android 守护进程的实现方式
在我们进行应用开发时，会遇到上级的各种需求，其中有一条 刚需： 后台保活 ，更有甚者：
我要我们的应用永远活在用户的手机后台不被杀死 —— 这都 TM 的扯淡
除了系统级别的应用能持续运行，所有三方程序都有被杀死的那一天！当然 QQ/微信/陌陌 等会好一些，因为他们已经深入设备的 心 ；
我们能做的只是通过各种手段尽量让我们的程序在后台运行的时间长一些，或者在被干掉的时候，能够重新站起来，而且这个也不是每次都有效的，也是不能在所有的设备的上都有效的；要做到后台进程保活，我们需要做到两方便：
要实现实现上边所说，通过下边几点来实现，首先我们需要了解下进程的优先级划分：
Process Importance 记录在 ActivityManager.java 类中:
了解进程优先级之后，我们还需要知道一个进程回收机制的东西；这里参考 AngelDevil 在博客园上的一篇文章:
Android 的 Low Memory Killer 基于 linux 的 OOM 机制，在 Linux 中，内存是以页面为单位分配的，当申请页面分配时如果内存不足会通过以下流程选择bad进程来杀掉从而释放内存：
在 Low Memory Killer 中通过进程的 oom_adj 与占用内存的大小决定要杀死的进程， oom_adj 越小越不容易被杀死；
Low Memory Killer Driver 在用户空间指定了一组内存临界值及与之一一对应的一组 oom_adj 值，当系统剩余内存位于内存临界值中的一个范围内时，如果一个进程的 oom_adj 值大于或等于这个临界值对应的 oom_adj 值就会被杀掉。
下边是表示 Process State (即老版本里的 OOM_ADJ )数值对照表，数值越大，重要性越低，在新版SDK中已经在 android 层去除了小于0的进程状态
Process State （即老版本的 OOM_ADJ ）与 Process Importance 对应关系，这个方法也是在 ActivityManager.java 类中，有了这个关系，就知道可以知道我们的应用处于哪个级别，对于我们后边优化有个很好地参考
一般情况下，设备端进程被干掉有一下几种情况
由以上分析，我们可以可以总结出，如果想提高我们应用后台运行时间，就需要提高当前应用进程优先级，来减少被杀死的概率
分析了那么多，现在对Android自身后台进程管理，以及进程的回收也有了一个大致的了解，后边我们要做的就是想尽一切办法去提高应用进程优先级，降低进程被杀的概率；或者是在被杀死后能够重新启动后台守护进程
第一种方式就是利用系统漏洞，使用 startForeground() 将当前进程伪装成前台进程，将进程优先级提高到最高(这里所说的最高是服务所能达到的最高，即1);
这种方式在 7.x 之前都是很好用的，QQ、微信、IReader、Keep 等好多应用都是用的这种方式实现；因为在7.x 以后的设备上，这种伪装前台进程的方式也会显示出来通知栏提醒，这个是取消不掉的，虽然 Google 现在还没有对这种方式加以限制，不过这个已经能够被用户感知到了，这种方式估计也用不了多久了
下边看下实现方式，这边这个 VMDaemonService 就是一个守护进程服务，其中在服务的 onStartCommand() 方法中调用 startForeground() 将服务进程设置为前台进程，当运行在 API18 以下的设备是可以直接设置，API18 以上需要实现一个内部的 Service ，这个内部类实现和外部类同样的操作，然后结束自己；当这个服务启动后就会创建一个定时器去发送广播，当我们的核心服务被干掉后，就由另外的广播接收器去接收我们守护进程发出的广播，然后唤醒我们的核心服务；
当我们启动这个守护进程的时候，就可以使用以下 adb 命令查看当前程序的进程情况（需要 adb shell 进去设备），
为了等下区分进程优先级，我启动了一个普通的后台进程，两外两个一个是我们启动的守护进程，一个是当前程序的核心进程，可以看到除了后台进程外，另外两个进程都带有 isForeground=true 的属性：
然后我们可以用下边的命令查看 ProcessID
有了 ProcessID 之后，我们可以根据这个 ProcessID 获取到当前进程的优先级状态 Process State ，对应 Linux 层的 oom_adj
可以看到当前核心进程的级别为 0 ，因为这个表示当前程序运行在前台 UI 界面，守护进程级别为 1 ，因为我们利用漏洞设置成了前台进程，虽然不可见，但是他的级别也是比较高的，仅次于前台 UI 进程，然后普通后台进程级别为 4 ；当我们退到后台时，可以看到核心进程的级别变为 1 了，这就是因为我们利用 startForeground() 将进程设置成前台进程的原因，这样就降低了进程被系统回收的概率了；
可以看到这种方式确实能够提高进程优先级，但是在一些国产的设备上还是会被杀死的，比我我测试的时候小米点击清空最近运行的应用进程就别干掉了；当把应用加入到设备白名单里就不会被杀死了，微信就是这样，人家直接装上之后就已经在白名单里了，我们要做的就是在用户使用中引导他们将我们的程序设置进白名单，将守护进程和白名单结合起来，这样才能保证我们的应用持续或者
Android系统在5.x以上版本提供了一个 JobSchele 接口，系统会根据自己实现定时去调用改接口传递的进程去实现一些操作，而且这个接口在被强制停止后依然能够正常的启动；不过在一些国产设备上可能无效，比如小米；
下边是 JobServcie 的实现：
我们要做的就是在需要的时候调用 JobSchele 的 schele 来启动任务；剩下的就不需要关心了， JobSchele 会帮我们做好，下边就是我这边实现的启动任务的方法：
在实现 Service 类时，将 onStartCommand() 返回值设置为 START_STICKY ，利用系统机制在 Service 挂掉后自动拉活；不过这种方式只适合比较原生一些的系统，像小米，华为等这些定制化比较高的第三方厂商，他们都已经把这些给限制掉了；
这种方式在以下两种情况无效：
事事没有绝对，万物总有一些漏洞，就算上边的那些方式不可用了，后边肯定还会出现其他的方式；我们不能保证我们的应用不死，但我们可以提高存活率；
其实最好的方式还是把程序做好，让程序本身深入人心，别人喜欢你了，就算你被干掉了，他们也会主动的把你拉起来，然后把你加入他们的白名单，然后我们的目的就实现了不是 😁 ~
㈣ Android开发之路-多线程
多线程作为Android开发中相对而言较为高阶的知识，其中用到相关的知识点是非常的多，所以在我们需要进行设计或者写多线程的代码就必须要进行相对谨慎的处理，这样就由必要对其要有着比较系统化的认知
我们一般将Android应用分成为两种：主线程和工作线程；主线程主要是用来进行初始化UI，而工作线程主要是进行耗时操作，例如读取数据库，网络连接等
Android系统是以进程为单位来对应用程序资源进行限制，这个问题的可以解释为：一个进程最多能够开几个线程？最好能开几个？但实则这个是没有上限这一说，主要是因为资源的限制
Android中关于主线程的理解：Android的主线程是UI线程，在Android中，四大组件运行在主线程中，在主线程中做耗时操作会导致程序出现卡顿甚至出现ANR异常，一个.
在一个程序中，这些独立运行的程序片断叫作“线程”(Thread)，利用它编程的概念就叫作“多线程处理”。多线程处理一个常见的例子就是用户界面。
线程总的来就是进程的一个实体，是CPU进行分派和调度的基本单位，拥有着比进程更小且能够独立运行的基本单位，线程本身基本上是不拥有系统资源，仅拥有一点在运行过程中必须拥有的资源，但它可与同属一个进程中的其他进程进行共享其所拥有的所有资源
线程状态有些地方将之分为5中状态，而且在Java Jdk中线程被其定义为6中状态，我们可以对其进行类比
普遍定义的5中状态：新建，就绪，运行，阻塞， 死亡
Java Jdk 定义状态
线程阻塞是指在某一时刻的某一个线程在进行运行一段代码的情况下，突然另一个线程也要进行运行，但在运行过程中，那个线程执行完全运行之前，另一个线程是不可能获取到CPU的执行权，就会导致线路阻塞的出现
死锁也称之为抱死，意思就是说一个进程锁定了另外一个进程所需要的页或表是，但第二个进程同时又锁定了第一个进程所需的一页，这样就会出现死锁现象
简要介绍实现线程的三种方式：继承Thread，实现runnable，实现callable。这里有一点需要注意的是，实现callable是与线程池相关联的而callable很重要的一个特性是其带有返回值。当我们只需实现单线程时实现runnable更加利于线程程序的拓展
在线程开启之前进行调用 thread.setDaemon(true); 将thread设定成当前线程中的守护线程 使用案例
线程让步【yield方法】让当前线程释放CPU资源，让其他线程抢占
这种具体某个对象锁 wait & notify 方法与Condition 的 await以及signal方法类似； 全面这种方法的阻塞等待都可以是释放锁，而且在唤醒后，这种线程都是能够获取锁资源的，而这个门栓就跟阀门类似
㈤ Android保活系列之——双进程守护
近期跳槽到玩加电竞，加之英雄联盟云顶之弈排位模式的推出，导致个人精力有限没有时间和心情去写相关的博客。
在Context中提供了bindService的方法
绑定服务是客户端--服务器接口中的服务器。组件和服务进行绑定后，可以发送请求、接收响应、执行进程间通信（IPC）。这里的服务器模型不同于网络C-S模型而是针对于Android应用不同的功能进行进程划分，例如提供视频播放的进程我们可以把它当做视频播放服务器，我们UI层属于客户端，客户端想要调用视频播放，需要用IPC方式通过bind服务的方式调用视频播放服务。（PS:如果大家对IPC不太熟悉可以参考我的其他文章 Android跨进程通信技术的使用及原理 ）客户端可以通过调用bindService()绑定到服务。调用时，必须提供ServiceConnection的实现，后者会监控与服务的连接及销毁。
借助bindService的机制，我们可以在主进程创建时创建一个守护进程，并监听守护进程的连接及销毁，再守护进程bindService中绑定主进程，这样即使进程因为锁屏、内存等问题杀掉后，也会被守护进程拉起，这就是Android中双进程守护的概念。当然早在PC时期，网吧的计时系统就使用了双进程守护机制，防止被恶意杀掉。
实现方式就不写了，网络上一搜一堆，这里给出一篇文章
Android 双进程守护
写的中规中矩，如果不清楚如何实现可以看一下。
谷歌官方8.0变更
当版本>8.0时，如果需要在后台启动服务需要调用startForegroundService。并且在serivce中onCreate方法必须在5秒内调用startForeground ,向通知栏发一个通知告知用户你的App正在后台运行，否则就会抛出异常
8.0通知适配
保活分两种：拉活、保活
拉活和保活是相辅相成的。在6.0版本以后的机型上，系统杀应用是按照进程组杀的，会直接导致双进程守护失效。那么因此就不使用双进程了么？
1.低版本双进程守护是依然亲测好使。
2.双进程守护可以和后面讲到的 账号同步、外部PUSH、JobScheler
相结合，可以规避开系统杀进程组的问题。使双进程守护功能可以兼容高版本。
讲的有些笼统，我寻思的发Dome、写例子，但这样解决不了根本问题，只有懂得了思路，了解了什么是双进程守护，才能在开发中随机应变。只能说Android水太深，大家需要细心细心再细心。
㈥ 每个Android 都应必须了解的多线程知识点~
进程是系统调度和资源分配的一个独立单位。
在Android中，一个应用程序就是一个独立的集成，应用运行在一个独立的环境中，可以避免其他应用程序/进程的干扰。当我们启动一个应用程序时，系统就会创建一个进程（该进程是从Zygote中fork出来的，有独立的ID），接着为这个进程创建一个主线程，然后就可以运行MainActivity了，应用程序的组件默认都是运行在其进程中。开发者可以通过设置应用的组件的运行进程，在清单文件中给组件设置：android:process = "进程名";可以达到让组件运行在不同进程中的目的。让组件运行在不同的进程中，既有好处，也有坏处。我们依次的说明下。
好处：每一个应用程序（也就是每一个进程）都会有一个内存预算，所有运行在这个进程中的程序使用的总内存不能超过这个值，让组件运行不同的进程中，可以让主进程可以拥有更多的空间资源。当我们的应用程序比较大，需要的内存资源比较多时（也就是用户会抱怨应用经常出现OutOfMemory时），可以考虑使用多进程。
坏处：每个进程都会有自己的虚拟机实例，因此让在进程间共享一些数据变得相对困难，需要采用进程间的通信来实现数据的共享。
线程是进程的一个实体，是CPU调度和分派的基本单位，它是比进程更小的能独立运行的基本单位。
在Android中，线程会有那么几种状态：创建、就绪、运行、阻塞、结束。当应用程序有组件在运行时，UI线程是处于运行状态的。默认情况下，应用的所有组件的操作都是在UI线程里完成的，包括响应用户的操作（触摸，点击等），组件生命周期方法的调用，UI的更新等。因此如果UI线程处理阻塞状态时(在线程里做一些耗时的操作，如网络连接等)，就会不能响应各种操作，如果阻塞时间达到5秒，就会让程序处于ANR（application not response）状态。
1.线程作用
减少程序在并发执行时所付出的时空开销，提高操作系统的并发性能。
2.线程分类
守护线程、非守护线程（用户线程）
2.1 守护线程
定义：守护用户线程的线程，即在程序运行时为其他线程提供一种通用服务
常见：如垃圾回收线程
设置方式：thread.setDaemon(true);//设置该线程为守护线程
2.2 非守护线程（用户线程）
主线程 & 子线程。
2.2.1 主线程（UI线程）
定义：Android系统在程序启动时会自动启动一条主线程
作用：处理四大组件与用户进行交互的事情（如UI、界面交互相关）
因为用户随时会与界面发生交互，因此主线程任何时候都必须保持很高的响应速度，所以主线程不允许进行耗时操作，否则会出现ANR。
2.2.2 子线程（工作线程）
定义：手动创建的线程
作用：耗时的操作（网络请求、I/O操作等）
2.3 守护线程与非守护线程的区别和联系
区别：虚拟机是否已退出，即
a. 当所有用户线程结束时，因为没有守护的必要，所以守护线程也会终止，虚拟机也同样退出
b. 反过来，只要任何用户线程还在运行，守护线程就不会终止，虚拟机就不会退出
3.线程优先级
3.1 表示
线程优先级分为10个级别，分别用Thread类常量表示。
3.2 设置
通过方法setPriority(int grade)进行优先级设置，默认线程优先级是5，即 Thread.NORM_PRIORITY。
4.线程状态
创建状态：当用 new 操作符创建一个线程的时候
就绪状态：调用 start 方法，处于就绪状态的线程并不一定马上就会执行 run 方法，还需要等待CPU的调度
运行状态：CPU 开始调度线程，并开始执行 run 方法
阻塞（挂起）状态：线程的执行过程中由于一些原因进入阻塞状态，比如：调用 sleep/wait 方法、尝试去得到一个锁等
结束（消亡）状态：run 方法执行完 或者 执行过程中遇到了一个异常
（1）start()和run()的区别
通过调用Thread类的start()方法来启动一个线程，这时此线程是处于就绪状态，并没有运行。调用Thread类调用run()方法来完成其运行操作的，方法run()称为线程体，它包含了要执行的这个线程的内容，run()运行结束，此线程终止，然后CPU再调度其它线程。
（2）sleep()、wait()、yield()的区别
sleep()方法属于Thread类，wait()方法属于Object类。
调用sleep()方法，线程不会释放对象锁，只是暂停执行指定的时间，会自动恢复运行状态；调用wait()方法，线程会放弃对象锁，进入等待此对象的等待锁定池，不调用notify()方法，线程永远处于就绪（挂起）状态。
yield()直接由运行状态跳回就绪状态，表示退让线程，让出CPU，让CPU调度器重新调度。礼让可能成功，也可能不成功，也就是说，回到调度器和其他线程进行公平竞争。
1.Android线程的原则
（1）为什么不能再主线程中做耗时操作
防止ANR, 不能在UI主线程中做耗时的操作，因此我们可以把耗时的操作放在另一个工作线程中去做。操作完成后，再通知UI主线程做出相应的响应。这就需要掌握线程间通信的方式了。 在Android中提供了两种线程间的通信方式：一种是AsyncTask机制，另一种是Handler机制。
（2）为什么不能在非UI线程中更新UI 因为Android的UI线程是非线程安全的，应用更新UI，是调用invalidate()方法来实现界面的重绘，而invalidate()方法是非线程安全的，也就是说当我们在非UI线程来更新UI时，可能会有其他的线程或UI线程也在更新UI，这就会导致界面更新的不同步。因此我们不能在非UI主线程中做更新UI的操作。
2.Android实现多线程的几种方式
3.为何需要多线程
多线程的本质就是异步处理，直观一点说就是不要让用户感觉到“很卡”。
4.多线程机制的核心是啥
多线程核心机制是Handler
推荐Handler讲解视频： 面试总被问到Handler？带你从源码的角度解读Handler核心机制
根据上方提到的 多进程、多线程、Handler 问题，我整理了一套 Binder与Handler 机制解析的学习文档，提供给大家进行学习参考，有需要的可以 点击这里直接获取！！！ 里面记录许多Android 相关学习知识点。
㈦ android kill哪些进程可以重启
2个service ， A = service 被干掉的时候，开启另外一个 b = service， B 被干掉，开始 A =service； service生命周期里面有destroy()把，在里面开启另外一个守护线程 查看原帖>>
㈧ android守护进程
Android中应该使用Service而不应该使用线程，Android中有提供后台运行的组件,叫Service。
servie是系统的组件，它由系统进程托管（servicemanager）；它们之间的通信类似于client和server，是一种轻量级的ipc通信，这种通信的载体是binder，它是在linux层交换信息的一种ipc。而thread是由本应用程序托管。
Thread：Thread是程序执行的最小单元，它是分配CPU的基本单位。可以用Thread来执行一些异步的操作。
Service：Service是android的一种机制，当它运行的时候如果是Local Service，那么对应的Service是运行在主进程的main线程上的。如：onCreate，onStart这些函数在被系统调用的时候都是在主进程的main线程上运行的。如果是RemoteService，那么对应的Service则是运行在独立进程的main线程上。
关于用户线程和守护线程:
在Java中有两类线程：User Thread(用户线程)、Daemon Thread(守护线程)
Daemon的作用是为其他线程的运行提供便利服务，比如垃圾回收线程就是一个很称职的守护者。User和Daemon两者几乎没有区别，唯一的不同之处就在于虚拟机的离开：如果 User Thread已经全部退出运行了，只剩下Daemon Thread存在了，虚拟机也就退出了。 因为没有了被守护者，Daemon也就没有工作可做了，也就没有继续运行程序的必要了。
㈨ 如何debug自定义AbstractProcessor
在开发时，你可能对如何调试自己的AbstractProcessor有些一筹莫展。本文将介绍如何使用Android Studio和gradle来调试你自己的AbstractProcessor。
第一步，在你代码中对init()方法或process()方法设置代码断点！
设置断点
第二步，设置gradle daemon端口和JVM参数。把下面两行加入到你的gradle.properties文件。我的gradle.properties文件在哪里?
org.gradle.daemon=true
org.gradle.jvmargs=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
在命令行中运行gradle daemon来启动守护线程。
gradle --daemon
第三步，在Android Studio建立Remote Debugger并运行它。
Remote Debugger 配置
我们在这里使用默认设置，IP:localhost，端口:5005。一旦你完成并运行它，那它就会连接到daemon线程中了。
最后我们用gradle命令来运行构建。
gradle clean assembleDebug
既然我们已经启动了守护线程，Remote Debugger将触发断点并挂起构建运行。完成！
㈩ Android 初学者 关于app关闭service一直运行 求各位指点迷津
Android5.0之前可以用双守护进程 fork一个子进程来守护主进程
白名单，微信QQ等等之所以能够存活，是因为系统商给了腾讯白名单，你调用清理内存时，并没有真正的清理