❶ 为什么说android主线程是线程不安全的，既然不安全为什么要在主线程中更新UI，有点晕 求大师解答
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）。
❷ Android线程池ThreadPoolExecutor详解
传统的多线程是通过继承Thread类及实现Runnable接口来实现的，每次创建及销毁线程都会消耗资源、响应速度慢，且线程缺乏统一管理，容易出现阻塞的情况，针对以上缺点，线程池就出现了。
线程池是一个创建使用线程并能保存使用过的线程以达到复用的对象，简单的说就是一块缓存了一定数量线程的区域。
1.复用线程：线程执行完不会立刻退出，继续执行其他线程；
2.管理线程：统一分配、管理、控制最大并发数；
1.降低因频繁创建&销毁线程带来的性能开销，复用缓存在线程池中的线程；
2.提高线程执行效率&响应速度，复用线程：响应速度；管理线程：优化线程执行顺序，避免大量线程抢占资源导致阻塞现象；
3.提高对线程的管理度；
线程池的使用也比较简单，流程如下：
接下来通过源码来介绍一下ThreadPoolExecutor内部实现及工作原理。
线程池的最终实现类是ThreadPoolExecutor，通过实现可以一步一步的看到，父接口为Executor:
其他的继承及实现关系就不一一列举了，直接通过以下图来看一下：
从构造方法开始看：
通过以上可以看到，在创建ThreadPoolExecutor时，对传入的参数是有要求的：corePoolSize不能小于0；maximumPoolSize需要大于0，且需要大于等于corePoolSize；keepAliveTime大于0；workQueue、threadFactory都不能为null。
在创建完后就需要执行Runnable了，看以下execute()方法：
在execute()内部主要执行的逻辑如下：
分析点1：如果当前线程数未超过核心线程数，则将runnable作为参数执行addWorker()，true表示核心线程，false表示非核心线程；
分析点2：核心线程满了，如果线程池处于运行状态则往workQueue队列中添加任务，接下来判断是否需要拒绝或者执行addWorker()；
分析点3：以上都不满足时 [corePoolSize=0且没有运行的线程，或workQueue已经满了] ，执行addWorker()添加runnable，失败则执行拒绝策略；
总结一下：线程池对线程创建的管理，流程图如下：
在执行addWorker时，主要做了以下两件事：
分析点1：将runnable作为参数创建Worker对象w，然后获取w内部的变量thread；
分析点2：调用start()来启动thread；
在addWorker()内部会将runnable作为参数传给Worker，然后从Worker内部读取变量thread，看一下Worker类的实现：
Worker实现了Runnable接口，在Worker内部，进行了赋值及创建操作，先将execute()时传入的runnable赋值给内部变量firstTask，然后通过ThreadFactory.newThread(this)创建Thread，上面讲到在addWorker内部执行t.start()后，会执行到Worker内部的run()方法，接着会执行runWorker(this)，一起看一下：
前面可以看到，runWorker是执行在子线程内部，主要执行了三件事：
分析1：获取当前线程，当执行shutdown()时需要将线程interrupt()，接下来从Worker内部取到firstTask，即execute传入的runnable，接下来会执行；
分析2：while循环，task不空直接执行；否则执行getTask()去获取，不为空直接执行；
分析3：对有效的task执行run()，由于是在子线程中执行，因此直接run()即可，不需要start()；
前面看到，在while内部有执行getTask()，一起看一下：
getTask()是从workQueue内部获取接下来需要执行的runnable，内部主要做了两件事：
分析1：先获取到当前正在执行工作的线程数量wc，通过判断allowCoreThreadTimeOut[在创建ThreadPoolExecutor时可以进行设置]及wc > corePoolSize来确定timed值；
分析2：通过timed值来决定执行poll()或者take()，如果WorkQueue中有未执行的线程时，两者作用是相同的，立刻返回线程；如果WorkQueue中没有线程时，poll()有超时返回，take()会一直阻塞；如果allowCoreThreadTimeOut为true，则核心线程在超时时间没有使用的话，是需要退出的；wc > corePoolSize时，非核心线程在超时时间没有使用的话，是需要退出的；
allowCoreThreadTimeOut是可以通过以下方式进行设置的：
如果没有进行设置，那么corePoolSize数量的核心线程会一直存在。
总结一下：ThreadPoolExecutor内部的核心线程如何确保一直存在，不退出？
上面分析已经回答了这个问题，每个线程在执行时会执行runWorker()，而在runWorker()内部有while()循环会判断getTask()，在getTask()内部会对当前执行的线程数量及allowCoreThreadTimeOut进行实时判断，如果工作数量大于corePoolSize且workQueue中没有未执行的线程时，会执行poll()超时退出；如果工作数量不大于corePoolSize且workQueue中没有未执行的线程时，会执行take()进行阻塞，确保有corePoolSize数量的线程阻塞在runWorker()内部的while()循环不退出。
如果需要关闭线程池，需要如何操作呢，看一下shutdown()方法：
以上可以看到，关闭线程池的原理：a. 遍历线程池中的所有工作线程；b. 逐个调用线程的interrupt()中断线程（注：无法响应中断的任务可能永远无法终止）
也可调用shutdownNow()来关闭线程池，二者区别：
shutdown()：设置线程池的状态为SHUTDOWN，然后中断所有没有正在执行任务的线程；
shutdownNow()：设置线程池的状态为STOP，然后尝试停止所有的正在执行或暂停任务的线程，并返回等待执行任务的列表；
使用建议：一般调用shutdown()关闭线程池；若任务不一定要执行完，则调用shutdownNow()；
总结一下：ThreadPoolExecutor在执行execute()及shutdown()时的调用关系，流程图如下：
线程池可以通过Executors来进行不同类型的创建，具体分为四种不同的类型，如下：
可缓存线程池：不固定线程数量，且支持最大为Integer.MAX_VALUE的线程数量：
1、线程数无限制
2、有空闲线程则复用空闲线程，若无空闲线程则新建线程
3、一定程度上减少频繁创建/销毁线程，减少系统开销
固定线程数量的线程池：定长线程池
1、可控制线程最大并发数(同时执行的线程数)
2、超出的线程会在队列中等待。
单线程化的线程池：可以理解为线程数量为1的FixedThreadPool
1、有且仅有一个工作线程执行任务
2、所有任务按照指定顺序执行，即遵循队列的入队出队规则
定时以指定周期循环执行任务
一般来说，等待队列 BlockingQueue 有: ArrayBlockingQueue 、 LinkedBlockingQueue 与 SynchronousQueue 。
假设向线程池提交任务时，核心线程都被占用的情况下:
ArrayBlockingQueue ：基于数组的阻塞队列，初始化需要指定固定大小。
当使用此队列时，向线程池提交任务，会首先加入到等待队列中，当等待队列满了之后，再次提交任务，尝试加入队列就会失败，这时就会检查如果当前线程池中的线程数未达到最大线程，则会新建线程执行新提交的任务。所以最终可能出现后提交的任务先执行，而先提交的任务一直在等待。
LinkedBlockingQueue ：基于链表实现的阻塞队列，初始化可以指定大小，也可以不指定。
当指定大小后，行为就和 ArrayBlockingQueue一致。而如果未指定大小，则会使用默认的 Integer.MAX_VALUE 作为队列大小。这时候就会出现线程池的最大线程数参数无用，因为无论如何，向线程池提交任务加入等待队列都会成功。最终意味着所有任务都是在核心线程执行。如果核心线程一直被占，那就一直等待。
SynchronousQueue ：无容量的队列。
使用此队列意味着希望获得最大并发量。因为无论如何，向线程池提交任务，往队列提交任务都会失败。而失败后如果没有空闲的非核心线程，就会检查如果当前线程池中的线程数未达到最大线程，则会新建线程执行新提交的任务。完全没有任何等待，唯一制约它的就是最大线程数的个数。因此一般配合Integer.MAX_VALUE就实现了真正的无等待。
但是需要注意的是， 进程的内存是存在限制的，而每一个线程都需要分配一定的内存。所以线程并不能无限个。
❸ android进程管理机制
Android系统与其他操作系统有个很不一样的地方，就是其他操作系统尽可能移除不再活动的进程，从而尽可能保证多的内存空间，而Android系统却是反其道而行之，尽可能保留进程。Android这样设计有什么优势呢？又是通过怎样的方法来管理这些被保留的进程的呢？Android用户又该如何正确使用手机从而更好发挥Android系统所特有的优势呢？本文将一一为您解开这些谜团。
本文的主要内容如下：
一、Android进程管理的特殊设计
Linux系统对进程的管理方式是一旦进程活动停止，系统就会结束该进程。尽管Android基于Linux Kernel，但在进程管理上，却采取了另外一种独特的设计：当进程活动停止时，系统并不会立刻结束它，而是会尽可能地将该进程保存在内存中，在以后的某个时间，一旦需要该进程，系统就会立即打开它，而不用再做一些初始化操作。只有当剩余内存不够用了，为了维持新开启的进程或者比较重要的进程的正常运行，系统才会选择性地杀掉一些不重要的内存，腾出内存空间来，所以Android系统永远不会有内存不足的提示。
二、Android独特进程管理设计的好处
Android这种独特的设计，也正是Android标榜的优势之一，这有两个好处：
1、最大限度地提高内存的使用率。
比如，你的内存是8G，如果每次使用完某个进程就杀掉，那么被使用的内存基本上会始终保持在某个值，比如4G以内，那么内存的使用率就总是保存在50%以内，剩余的4G内存形同虚设，发挥用处的机会非常少。而Android的这种设计，就可以做到有多少内存就用多少内存，尽可能大地提高内存使用率。同样比如有8G内存，使用完的进程仍保留在内存中，累积下来，被使用的内存就尽可能地会接近8G。
2、提高再次启动时的启动速度
被驻留在内存中不再活动的进程（后台进程或空进程，后面会再讲到），很多是经常需要使用的，当再次使用该进程的时候，系统立即打开它，而不需要再重新初始化。例如，我们常用的浏览器，当暂时不再使用时，按下Home键或Back键，浏览器进程就变成了不再活动的进程。如果下次又要使用了，点击多任务键，在最近使用应用列表中点击浏览器即可，浏览器界面仍然保持着退出前的界面。但如果退出时把该进程移除了，那么再次使用时，就需要重新初始化，然后进入该应用，这往往会花费不少的时间。
三、Android进程的五个等级
Android系统将尽量长时间地保持应用进程，但为了新建进程或运行更重要的进程，最终需要移除旧进程来回收内存。为了确定保留或终止哪些进程，系统会根据进程中正在运行的组件以及这些组件的状态，将每个进程放入“重要性层次结构”中。必要时，系统会首先消除重要性最低的进程，然后是重要性略逊的进程，以此类推，以回收系统资源。该“重要性层级结构”将进程分为了五个等级：
1、前台进程（foreground）
前台进程是指那些有组件正和用户进行交互的应用程序的进程，也称为Active进程。这些都是Android尝试通过回收其他应用程序来使其保持相应的进程。这些进程的数量非常少，只有等到最后关头才会终止这些进程，是用户最不希望终止的进程。例如：而当你运行浏览器这类应用时，它们的界面就会显示在前台，它们就属于前台进程，当你按home键回到主界面，他们就变成了后台程序。
如果一个进程满足以下任一条件，即视为前台进程：
（1）托管处于活动状态的Activity，也就是说，它们位于前台并对用户事件进行响应，此时的情形为响应了Activity中的onResume()生命周期方法，但没有响应onPause()。
（2）托管正在执行onReceive()方法处理事件程序的BroadcastReceiver。
（3）托管正在执行onStart()、onCreate()或onDestroy()事件处理程序的Service。
（4）托管正在运行且被标记为在前台运行的Service，即调用了该Service的startForeground()方法。
（5）托管某个Service，且该Service正绑定在用户正在交互的Activity的Service，即该Activity正处于活动状态。
2、可见进程（visible）
没有任何前台组件、但仍然会影响用户在屏幕上所见内容的进程。如果一个进程满足以下任一条件，即视为可见进程：
（1）托管不在前台、但仍对用户可见的Activity（已调用其onPause（）方法）。例如：如果前台Acitivty启动了一个对话框，或者启动了一个非全屏，亦或是一个透明的Activity，允许在其后显示上一个Activity，则可能会发生这种情况，这类Activity不在前台运行，也不能对用户事件作出反应。
（2）托管绑定到可见Activity的Service。（官网上说是绑定到可见或前台Activity，但笔者有一点疑问，这个和“前台进程”中第（5）点相矛盾吗，绑定到前台Activity，那就是前台进程了）
可见进程被视为是极其重要的进程，这类进程的数量也很少，只有在资源极度匮乏的环境下，为保证前台进程继续执行时才会终止。
3、服务进程（Service）
正在运行已使用startService（）方法启动的Serice且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联，但是它们通常在执行一些用户关心的操作。因此，除非内存不足以维持所有前台进程和可见进程同时运行，否则系统会让服务进程保持运行状态。
有些资料上面也称这种进程为次要服务（Secondary Service），而属于上述两个更高类别的进程则被称为主要服务，主要服务往往属于系统进程，如拨号进程等，不可能被进程管理轻易终止。这里我们以Android开发者官网的称呼为标准，称为服务进程。
4、后台进程（hidden）
包含目前对用户不可见的Activity，即该Activity调用了onStop()方法。这些进程对用户体验没有直接影响，系统可能随时终止它们，以回收内存供上述三个更高级别的进程使用。通常会有很多后台进程在运行，它们会保存在LRU（Least Recently Used，最近最少使用）列表中，以确保包含用户最近查看的Activity的进程最后一个被终止。如果某个Activity正确实现了生命周期方法，并保存了其当前状态，则终止其进程不会对用户体验产生明显影响，因为当用户导航回该Activity时，Activity会恢复其所有可见状态。
这里读者可以做个试验，先开启微信，进入到朋友圈界面， 然后点击手机屏幕下方的导航栏中的Home按键进入到后台，再点击最近使用应用列表显示按钮（不同的手机位置不一样，有的在Home键左边，有的则在Home键右边），在显示的最近使用应用的列表中清理掉微信应用，最后再点击桌面的微信图标启动微信，会发现显示的界面仍然是朋友圈界面。
后台进程，我们可以简单理解为，应用（只考虑只有Activity组件的情况）启动后按Home键后被切换到后台的进程。如浏览器、阅读器等，当程序显示在屏幕上时，它们所运行的进程即为前台进程（foreground），一旦按home键（注意不是back键）返回到桌面，程序就停留在后台，成为后台进程。
5、空进程（empty）
不含任何活动应用组件的进程。保留这种进程的唯一目的是用作缓存，以缩短下次再其中运行组件所需要的启动时间。一般来说，当应用按back按键退出后应用后，就变成了一个空进程。比如BTE，在程序退出后，依然会在进程中驻留一个空进程，这个进程里没有任何数据在运行，作用往往是提高该程序下次的启动速度或者记录程序的一些历史信息。当系统内存不够用时，无疑，该进程是应该最先终止的。在最近使用应用列表中，可以看到按back键退出的应用。
根据进程中当前活动组件的重要程度，Android会将进程评定为它可能达到的最高级别。通俗地说，就是如果一个进程同时拥有多个对应上述不同等级进程的组件时，会以最高的那个等级作为该进程的等级。例如，如果某进程托管着服务和可见Activity，则会将此进程评定为可见进程，而不是服务进程。
此外，一个进程的级别可能会因为其他进程对它的依赖而有所提高，即服务于另一进程的进程其级别永远不会低于其所服务的进程。例如，如果进程A中的内容提供程序为进程B中的客户端提供服务，或者如果进程A中的服务绑定到进程B中的组件，则进程A始终被视为至少与进程B同样重要。
由于运行服务的进程其级别高于托管后台Activity的进程，因此启动长时间运行操作的Activity最好为该操作启动Service，而不是简单地创建工作线程，当操作有可能比Activity更加持久时更应该如此。例如，正在将图片上传到网站的Activity应该启动服务来执行上传，这样一来，即使用户退出Activity，仍可在后台继续执行上传操作。使用服务可以保证，无论Activity发生什么情况，该操作至少具备“服务进程”优先级。如果某个Activity开启了线程执行耗时操作，当Activity退出时，该Activity的实例将不会释放内存资源，直到线程执行完，这样容易导致内存泄漏。同理，广播接收器也应该使用服务，而不是简单地将耗时冗长的操作放入线程中。
四、进程移除顺序的依据——阈（yu，第四声）值
前面讲到，内存不够用时，会根据进程的等级来决定优先回收哪类进程。那么系统是根据什么来判断需要移除这些进程的时机的呢？答案是阈值。
1、查看阈值
我们可以采用如下方法查看手机中各个等级进程的阈值（需要root权限），如第二排数据所示（其单位为页）：
以第一个数据44032为例，计算方法为：
1page=4KB=4*1024B=4096B
44032page* 4048B/page = 180355072B
180355072B/1024/1024 = 172M
即第一个等级的进程的阈值为172M。依次类推，阈值依次为：172M，190M，208M，226M，316M，415M。
有必要说明一下，在Android开发者官方文档中，是将Android应用进程分为了5个等级，但很多资料却是分的6个等级，在后台进程和空进程之间还有一个“内容提供节点（content provider）进程”。内容提供节点，没有实体程序，仅提供内容供别的程序去用 ，比如日历供应节点，邮件供应节点等，在终止进程时，这类进程有比较高的优先权。手机中应该是采用的6个等级的方式，如上六个数据，正好对应着六个等级的进程，等级越高，阈值越低，即前台进程阈值为172M，空进程为415M。当系统的剩余内存只剩余不到415M的时候，系统首先会回收空进程，依次类推，只有剩余内存不到172M了，才会去回收前台进程，这样就起到了优化保护重要进程的作用。
五、Home键、Back键和多任务键
Home键、Back键和多任务键，在手机屏幕的下方，这三个按键一般称为导航栏，中间的按钮为Home键，多任务键和Back键分别在其左右，一般根据手机品牌不同，左右位置也有所差异。
在运行App的时候，如果按一下Home键或者Back键，都可以退到桌面，那么这两者有什么区别呢？
Home键。按Home键的时候，App如果没有Service开启，会从一个前台进程转变为一个后台进程；如果有前台service运行，就仍然是前台进程，比如QQ音乐播放器等；如果是只有普通service运行，那么就转变为服务进程（参照前文中讲的Android进程的5个级别）。
Back键。按Back键的时候，App如果没有Service开启，会从一个前台进程转变为一个空进程；对于有Service运行的情况，和按Home键一样。
后台进程和空进程，都是驻留在后台，处于暂停状态，也都是除了占用一部分内存外，不占用其他如cpu等资源的，那么问题来了，为什么要设计后台进程和空进程这两种空进程呢？它们的区别到底在哪里呢？我们在前文讲Android进程的5个等级的时候讲到过，当剩余内存不足的时候，系统会按照等级顺序，优先移除不太重要进程，以收回内存供更重要的进程运行。那么，它们的区别就是，在剩余内存不足时，会优先移除空进程，再不足，才会移除空进程。所以，如果确实要退出某个应用一段时间内不大使用了，如果这款应用有退出按钮，就用应用自带的退出功能；如果没有，则最好按系统的Back键，这样可以变成空进程，当系统要回收内存时，就会优先被回收，从而释放的所占的资源。如果只是暂时退出去做点别的，过一会还要切换回来，或者对这款应用使用比较频繁，那就使用Home键，因为相比于按Back键，这样可以尽可能保住后台进程，方便下次使用的时候快速启动。
当然，按Home键或Back键，对用户来说，其实感觉不到差异，使用起来没什么两样，但是，对于Android开发者来说，却有必要作为常识来了解其中的道理和差异。无论是按Home键还是按Back键，在按多任务键的时候，都可以看到这些进程，如下图所示。最下面的按键为清理按键，点击后可以清除掉这些进程，回收内存了，当然，前面也讲了很多遍了，不建议这样做。
2、修改阈值。
可以采用命令：echo "44032,48640,53248,57856,80896,106241" > /sys/mole/lowmemorykiller/parameters/minfree来修改阈值，如下所示：
重启后，会恢复为原来的值。至于如何永久性修改该阈值，这里不深入探讨，有兴趣的童鞋可以自行研究，一般来说，就按照系统给定的默认值使用就可以了，没特殊用途的话，没必要修改。
对于这一节阈值的内容，暂时先讲到这里，如果要更深入，可以自行多研究研究。笔者也没有看到比较好的更深入的文章，所以也不好推荐，如果读者看到比较好的，可以推荐给笔者，感激不尽。
六、开发者选项中的进程管理功能
Android手机都带有开发者选项，隐藏了很多功能，顾名思义，这些功能主要用于辅助开发者调试程序用的。其中有一些就是关于进程管理功能的，笔者这里简单介绍一下其中两款，如下图红框部分所示：
不保留活动。用户离开以后即销毁每个活动（Activity），这样做使得后台进程都被销毁了。笔者试验过几款app，比如微信，浏览器，开启/关闭“不保留活动”前后，按Home键后，再打开应用，有明显的差别。当然，也试用了短信，DD打车，就没看出起了什么作用。读者若是感兴趣可以深入研究研究，到时候在指导指导笔者！
后台进程限制。如下图所示，给出了后台进程个数限制的选项。
七、进程管理软件的使用
Windows操作系统用户往往总想着保留更多的内存，在使用Android手机的时候，喜欢经常清理后台进程或空进程，而且清理完后，心里有一种特别爽的感觉，就像给家里做了一次大扫除一样，笔者最初使用Android手机的时候也是这样的心态-_-！基于这样的心态，一些进程清理软件，很受普通用户的青睐。其实这样做却正好抹杀了Android系统所标榜的优势，如前文所讲到的。
那么进程管理软件有无必要呢？当然有的，只是需要注意使用场合。当需要运行大型程序的时候，可以手动关闭掉一些进程，腾出足够的空间供大型程序使用，这样就可以有效避免系统调用进程调度策略而引起的卡顿，这一点，第八大点第3小节中会有说明。而且由于开发者的原因，可能是程序写得太烂，或程序容易出错，或做不该做的动作，或是恶意程序，对于这类程序进程，手动移除也是有好处的。
但如果是运行一些小程序，就完全没有必要去预先杀进程了，完全可以交给系统自己管理。读者可能会疑惑，因为小程序启动的时候，也有可能会因为内存不足而导致需要移除部分进程的情况。笔者认为，即便是内存不足，小程序运行引起的调用进程调度策略测的次数非常少，要移除的进程也非常少，产生的影响不大。同时，我们也要意识到另外一点就是，无论是手动杀死进程还是自动杀进程，都需要cpu去执行这些任务，所以也会拖慢手机和消耗电量。所以从这一点看，频繁杀进程，也是一个不好的习惯。
八、答疑解惑
在以前没有专门去了解Android进程管理机制的时候，甚至是在研究的过程中，笔者心里都经常存在很多疑惑，以下整理了其中5个，不知道读者您是否有也类似的困惑呢？
1、这么多驻留在内存的进程，不会耗电吗？
大多数用惯了Windows操作系统的童鞋，看到Android系统尽可能保留不在活动的进程的设计，可能第一反应就是质疑，难道这样不会增加耗电量吗？其实，但一个程序按home键变成后台进程或者按back键退出变成空进程后，其实已经被暂停了，只保留了运行状态，不会消耗cpu，一个程序会耗电，是因为它需要调用cpu来运算，现在不消耗cpu了，当然就不会耗电了。当然，开了service的应用就另当别论了，比如QQ音乐播放器，当按home键或back键后，音乐仍然播放，是因为它开启了服务，而且是一个前台服务，在后面我们会继续讲到，此时它是一个前台进程，而不是后台进程或空进程。
2、为什么一个不太app，运行时会占用很大的内存呢？
我们经常会碰到这样一种现象，一个只有20M的App，运行起来的时候，却会耗掉100M以上的内存。一方面是，程序运行时为对象分配内存，另一方面，是Android虚拟机的原因。Android中的应用启动的时候，系统都会给它开启一个独立的虚拟机，这样做的好处是可以避免虚拟机崩溃导致整个系统崩溃，代价就是耗用更多的内存。
3、为什么内存少的时候，运行大型程序会卡顿呢？
当剩余内存不多时，打开大型程序，系统会触发自身的进程调度策略，去移除一些等级比较低的进程来回收内存，以供大型程序运行。而这个进程调度策略在决定哪些进程需要被移除的过程，是一个十分消耗资源的操作，特别是一个程序频繁像系统申内存的时候，这样就导致了系统的卡顿。
4、应用开得太多了，手机变慢，是因为内存被占用太多吗？
其实手机变慢的根本原因是cpu被耗用太多，而不是内存占用太多，因为真正执行程序所要完成的任务的最终执行者是CPU，而不是内存（RAM）。在内存足够的情况下，如果系统中占用cpu的进程太多，那无疑cpu总有忙不过来的时候，那肯定就会变慢了。这就好比，在一条道路上驾车，道路就像内存，车的引擎就像cpu，如果车的引擎的动力不够，或者承载的货物太多，车都跑不快，即便是道路上一路畅通无阻，也无济于事。所以，内存占用多少并不重要，只要道路提供给车辆前行的空间是足够的，手机变慢的责任，就和内存无关了。这个比喻用来解释第三点也很恰当，道路提供的车辆前进的空间无法满足车辆所必需的空间时，就需要交通机制花时间来调节交通，给这辆车提供足够的空间，而在此期间，这辆车只能乖乖候着。
5、Android手机越用越慢，是什么原因呢？
Android手机常常是越用越慢，即使是恢复出厂设置，也无法改变这个现象。手机越用越慢，主要由如下几个原因：（1）虚拟机机制问题。这一点在上一个问题中也提到了，在Android4.4以前的系统，使用的是Dalvik虚拟机，它的设计机制有缺陷，就是越用越慢；在Android4.4系统中有切换按钮，可以在Art虚拟机和Dalvik虚拟机之间切换；在Android4.4以后的系统就彻底抛弃了Dalvik而全面使用Art。（2）开启了太多的服务，导致耗用太多的CPU。随着手机开机使用时间的增长，应用使用越来越多，很多应用看似退出了，而其实后台可能开了不少的服务，而他们可能还没有关闭。这些服务正在执行一些操作，会消耗CPU，而CPU才是手机变慢的根本原因。 而且Android app比较开放的，有很多不良应用充斥其中，可能对服务处理不当，滥用服务等，增加系统中的服务。（3）系统频繁调用自身的进程调度算法。这一点在前面已经说明了，这里不再赘述。（4）手机硬件的自然老化
❹ 为什么 Android 的 UI 框架使用单线程模型，比多线程模型有什么优点
·如果有大量的线程,会影响性能,因为操作系统需要在它们之间切换。·的线程需要的内存空间。·线程可能会给程序带来“bug”，因此要小心使用。·线程的中止需要考虑其对程序运行的影响。·通常块模型数据是在多个线程间共享的，需要防止线程死锁情况的发生。一些线程模型的背景可以重点讨论一下在Win32环境中常用的一些模型。·单线程模型在这种线程模型中，一个进程中只能有一个线程，剩下的进程必须等待当前的线程执行完。这种模型的缺点在于系统完成一个很小的任务都必须占用很长的时间。·块线程模型（单线程多块模型STA）这种模型里，一个程序里可能会包含多个执行的线程。在这里，每个线程被分为进程里一个单独的块。每个进程可以含有多个块，可以共享多个块中的数据。程序规定了每个块中线程的执行时间。所有的请求通过Windows消息队列进行串行化，这样保证了每个时刻只能访问一个块，因而只有一个单独的进程可以在某一个时刻得到执行。这种模型比单线程模型的好处在于，可以响应同一时刻的多个用户请求的任务而不只是单个用户请求。但它的性能还不是很好，因为它使用了串行化的线程模型，任务是一个接一个得到执行的。·多线程块模型（自由线程块模型）多线程块模型（MTA）在每个进程里只有一个块而不是多个块。这单个块控制着多个线程而不是单个线程。这里不需要消息队列，因为所有的线程都是相同的块的一个部分，并且可以共享。这样的程序比单线程模型和STA的执行速度都要快，因为降低了系统的负载，因而可以优化来减少系统idle的时间。这些应用程序一般比较复杂，因为程序员必须提供线程同步以保证线程不会并发的请求相同的资源，因而导致竞争情况的发生。这里有必要提供一个锁机制。但是这样也许会导致系统死锁的发生。进程和线程都是操作系统的概念。进程是应用程序的执行实例，每个进程是由私有的虚拟地址空间、代码、数据和其它各种系统资源组成，进程在运行过程中创建的资源随着进程的终止而被销毁，所使用的系统资源在进程终止时被释放或关闭。线程是进程内部的一个执行单元。系统创建好进程后，实际上就启动执行了该进程的主执行线程，主执行线程以函数地址形式，比如说main或WinMain函数，将程序的启动点提供给Windows系统。主执行线程终止了，进程也就随之终止。每一个进程至少有一个主执行线程，它无需由用户去主动创建，是由系统自动创建的。用户根据需要在应用程序中创建其它线程，多个线程并发地运行于同一个进程中。一个进程中的所有线程都在该进程的虚拟地址空间中，共同使用这些虚拟地址空间、全局变量和系统资源，所以线程间的通讯非常方便，多线程技术的应用也较为广泛。多线程可以实现并行处理，避免了某项任务长时间占用CPU时间。要说明的一点是，到2015年为止，大多数的计算机都是单处理器（CPU）的，为了运行所有这些线程，操作系统为每个独立线程安排一些CPU时间，操作系统以轮换方式向线程提供时间片，这就给人一种假象，好象这些线程都在同时运行。由此可见，如果两个非常活跃的线程为了抢夺对CPU的控制权，在线程切换时会消耗很多的CPU资源，反而会降低系统的性能。这一点在多线程编程时应该注意。C++11标准中，STL类库也实现了多线程的类std::thread，使得多线程编程更加方便。