android机制分析

A. 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）手机硬件的自然老化

B. [Android源码分析] － 异步通信Handler机制

一、问题：在Android启动后会在新进程里创建一个主线程，也叫UI线程（ 非线程安全 ）这个线程主要负责监听屏幕点击事件与界面绘制。当Application需要进行耗时操作如网络请求等，如直接在主线程进行容易发生ANR错误。所以会创建子线程来执行耗时任务，当子线程执行完毕需要通知UI线程并修改界面时，不可以直接在子线程修改UI，怎么办？

解决方法：Message Queue机制可以实现子线程与UI线程的通信。

该机制包括Handler、Message Queue、Looper。Handler可以把消息/ Runnable对象 发给Looper，由它把消息放入所属线程的消息队列中，然后Looper又会自动把消息队列里的消息/Runnable对象 广播 到所属线程里的Handler，由Handler处理接收到的消息或Runnable对象。

1、Handler

每次创建Handler对象时，它会自动绑定到创建它的线程上。如果是主线程则默认包含一个Message Queue，否则需要自己创建一个消息队列来存储。

Handler是多个线程通信的信使。比如在线程A中创建AHandler，给它绑定一个ALooper，同时创建属于A的消息队列AMessageQueue。然后在线程B中使用AHandler发送消息给ALooper，ALooper会把消息存入到AMessageQueue，然后再把AMessageQueue广播给A线程里的AHandler，它接收到消息会进行处理。从而实现通信。

2、Message Queue

在主线程里默认包含了一个消息队列不需要手动创建。在子线程里，使用Looper.prepare()方法后，会先检查子线程是否已有一个looper对象，如果有则无法创建，因为每个线程只能拥有一个消息队列。没有的话就为子线程创建一个消息队列。

Handler类包含Looper指针和MessageQueue指针，而Looper里包含实际MessageQueue与当前线程指针。

下面分别就UI线程和worker线程讲解handler创建过程：

首先，创建handler时，会自动检查当前线程是否包含looper对象，如果包含，则将handler内的消息队列指向looper内部的消息队列，否则，抛出异常请求执行looper.prepare()方法。

 － 在 UI线程 中，系统自动创建了Looper 对象，所以，直接new一个handler即可使用该机制；

－ 在 worker线程 中，如果直接创建handler会抛出运行时异常－即通过查‘线程－value’映射表发现当前线程无looper对象。所以需要先调用Looper.prepare()方法。在prepare方法里，利用ThreadLocal<Looper>对象为当前线程创建一个Looper（利用了一个Values类，即一个Map映射表，专为thread存储value，此处为当前thread存储一个looper对象）。然后继续创建handler， 让handler内部的消息队列指向该looper的消息队列（这个很重要，让handler指向looper里的消息队列，即二者共享同一个消息队列，然后handler向这个消息队列发送消息，looper从这个消息队列获取消息） 。然后looper循环消息队列即可。当获取到message消息，会找出message对象里的target，即原始发送handler，从而回调handler的handleMessage() 方法进行处理。

 － handler与looper共享消息队列 ，所以handler发送消息只要入列，looper直接取消息即可。

 － 线程与looper映射表 ：一个线程最多可以映射一个looper对象。通过查表可知当前线程是否包含looper，如果已经包含则不再创建新looper。

5、基于这样的机制是怎样实现线程隔离的，即在线程中通信呢。 

核心在于 每一个线程拥有自己的handler、message queue、looper体系 。而 每个线程的Handler是公开 的。B线程可以调用A线程的handler发送消息到A的共享消息队列去，然后A的looper会自动从共享消息队列取出消息进行处理。反之一样。

二、上面是基于子线程中利用主线程提供的Handler发送消息出去，然后主线程的Looper从消息队列中获取并处理。那么还有另外两种情况：

1、主线程发送消息到子线程中；

采用的方法和前面类似。要在子线程中实例化AHandler并设定处理消息的方法，同时由于子线程没有消息队列和Looper的轮询，所以要加上Looper.prepare(),Looper.loop()分别创建消息队列和开启轮询。然后在主线程中使用该AHandler去发送消息即可。

2、子线程A与子线程B之间的通信。

1、 Handler为什么能够实现不同线程的通信？核心点在哪？

不同线程之间，每个线程拥有自己的Handler、消息队列和Looper。Handler是公共的，线程可以通过使用目标线程的Handler对象来发送消息，这个消息会自动发送到所属线程的消息队列中去，线程自带的Looper对象会不断循环从里面取出消息并把消息发送给Handler，回调自身Handler的handlerMessage方法，从而实现了消息的线程间传递。

2、 Handler的核心是一种事件激活式（类似传递一个中断）的还是主要是用于传递大量数据的？重点在Message的内容，偏向于数据传输还是事件传输。

目前的理解，它所依赖的是消息队列，发送的自然是消息，即类似事件中断。

0、 Android消息处理机制(Handler、Looper、MessageQueue与Message)

1、 Handler、Looper源码阅读

2、 Android异步消息处理机制完全解析，带你从源码的角度彻底理解

谢谢！

wingjay


C. Android V1及V2签名原理简析

Android为了保证系统及应用的安全性，在安装APK的时候需要校验包的完整性，同时，对于覆盖安装的场景还要校验新旧是否匹配，这两者都是通过Android签名机制来进行保证的，本文就简单看下Android的签名与校验原理，分一下几个部分分析下：

签名是摘要与非对称密钥加密相相结合的产物，摘要就像内容的一个指纹信息，一旦内容被篡改，摘要就会改变，签名是摘要的加密结果，摘要改变，签名也会失效。Android APK签名也是这个道理，如果APK签名跟内容对应不起来，Android系统就认为APK内容被篡改了，从而拒绝安装，以保证系统的安全性。目前Android有三种签名V1、V2（N）、V3（P），本文只看前两种V1跟V2，对于V3的轮密先不考虑。先看下只有V1签名后APK的样式：

再看下只有V2签名的APK包样式：

同时具有V1 V2签名：

可以看到，如果只有V2签名，那么APK包内容几乎是没有改动的，META_INF中不会有新增文件，按Google官方文档：在使用v2签名方案进行签名时，会在APK文件中插入一个APK签名分块，该分块位于zip中央目录部分之前并紧邻该部分。在APK签名分块内， 签名和签名者身份信息会存储在APK签名方案v2分块中，保证整个APK文件不可修改 ，如下图：

而V1签名是通过META-INF中的三个文件保证签名及信息的完整性：

V1签名是如何保证信息的完整性呢？V1签名主要包含三部分内容，如果狭义上说签名跟公钥的话，仅仅在.rsa文件中，V1签名的三个文件其实是一套机制，不能单单拿一个来说事，

如果对APK中的资源文件进行了替换，那么该资源的摘要必定发生改变，如果没有修改MANIFEST.MF中的信息，那么在安装时候V1校验就会失败，无法安装，不过如果篡改文件的同时，也修改其MANIFEST.MF中的摘要值，那么MANIFEST.MF校验就可以绕过。

CERT.SF个人觉得有点像冗余，更像对文件完整性的二次保证，同绕过MANIFEST.MF一样，.SF校验也很容易被绕过。

CERT.RSA与CERT.SF是相互对应的，两者名字前缀必须一致，不知道算不算一个无聊的标准。看下CERT.RSA文件内容：

CERT.RSA文件里面存储了证书公钥、过期日期、发行人、加密算法等信息，根据公钥及加密算法，Android系统就能计算出CERT.SF的摘要信息，其严格的格式如下：

从CERT.RSA中，我们能获的证书的指纹信息，在微信分享、第三方SDK申请的时候经常用到，其实就是公钥+开发者信息的一个签名：

除了CERT.RSA文件，其余两个签名文件其实跟keystore没什么关系，主要是文件自身的摘要及二次摘要，用不同的keystore进行签名，生成的MANIFEST.MF与CERT.SF都是一样的，不同的只有CERT.RSA签名文件。也就是说前两者主要保证各个文件的完整性，CERT.RSA从整体上保证APK的来源及完整性，不过META_INF中的文件不在校验范围中，这也是V1的一个缺点。V2签名又是如何保证信息的完整性呢？

前面说过V1签名中文件的完整性很容易被绕过，可以理解 单个文件完整性校验的意义并不是很大 ，安装的时候反而耗时，不如采用更加简单的便捷的校验方式。V2签名就不针对单个文件校验了，而是 针对APK进行校验 ，将APK分成1M的块，对每个块计算值摘要，之后针对所有摘要进行摘要，再利用摘要进行签名。

也就是说，V2摘要签名分两级，第一级是对APK文件的1、3 、4 部分进行摘要，第二级是对第一级的摘要集合进行摘要，然后利用秘钥进行签名。安装的时候，块摘要可以并行处理，这样可以提高校验速度。

APK是先摘要，再签名，先看下摘要的定义：Message Digest：摘要是对消息数据执行一个单向Hash，从而生成一个固定长度的Hash值，这个值就是消息摘要，至于常听到的MD5、SHA1都是摘要算法的一种。理论上说，摘要一定会有碰撞，但只要保证有限长度内碰撞率很低就可以，这样就能利用摘要来保证消息的完整性，只要消息被篡改，摘要一定会发生改变。但是，如果消息跟摘要同时被修改，那就无从得知了。

而数字签名是什么呢（公钥数字签名），利用非对称加密技术，通过私钥对摘要进行加密，产生一个字符串，这个字符串+公钥证书就可以看做消息的数字签名，如RSA就是常用的非对称加密算法。在没有私钥的前提下，非对称加密算法能确保别人无法伪造签名，因此数字签名也是对发送者信息真实性的一个有效证明。不过由于Android的keystore证书是自签名的，没有第三方权威机构认证，用户可以自行生成keystore，Android签名方案无法保证APK不被二次签名。

知道了摘要跟签名的概念后，再来看看Android的签名文件怎么来的？如何影响原来APK包？通过sdk中的apksign来对一个APK进行签名的命令如下：

其主要实现在 android/platform/tools/apksig 文件夹中，主体是ApkSigner.java的sign函数，函数比较长，分几步分析

先来看这一步，ApkUtils.findZipSections，这个函数主要是解析APK文件，获得ZIP格式的一些简单信息，并返回一个ZipSections，

ZipSections包含了ZIP文件格式的一些信息，比如中央目录信息、中央目录结尾信息等，对比到zip文件格式如下：

获取到 ZipSections之后，就可以进一步解析APK这个ZIP包，继续走后面的签名流程，

可以看到先进行了一个V2签名的检验，这里是用来签名，为什么先检验了一次？第一次签名的时候会直接走这个异常逻辑分支，重复签名的时候才能获到取之前的V2签名，怀疑这里获取V2签名的目的应该是为了排除V2签名，并获取V2签名以外的数据块，因为签名本身不能被算入到签名中，之后会解析中央目录区，构建一个DefaultApkSignerEngine用于签名

先解析中央目录区，获取AndroidManifest文件，获取minSdkVersion(影响签名算法)，并构建DefaultApkSignerEngine，默认情况下V1 V2签名都是打开的。

第五步与第六步的主要工作是：apk的预处理，包括目录的一些排序之类的工作，应该是为了更高效处理签名，预处理结束后，就开始签名流程，首先做的是V1签名（默认存在，除非主动关闭）：

步骤7、8、9都可以看做是V1签名的处理逻辑，主要在V1SchemeSigner中处理，其中包括创建META-INFO文件夹下的一些签名文件，更新中央目录、更新中央目录结尾等，流程不复杂，不在赘述，简单流程就是：

这里特殊提一下重复签名的问题： 对一个已经V1签名的APK再次V1签名不会有任何问题 ，原理就是：再次签名的时候，会排除之前的签名文件。

可以看到目录、META-INF文件夹下的文件、sf、rsa等结尾的文件都不会被V1签名进行处理，所以这里不用担心多次签名的问题。接下来就是处理V2签名。

V2SchemeSigner处理V2签名，逻辑比较清晰，直接对V1签名过的APK进行分块摘要，再集合签名，V2签名不会改变之前V1签名后的任何信息，签名后，在中央目录前添加V2签名块，并更新中央目录结尾信息，因为V2签名后，中央目录的偏移会再次改变：

签名校验的过程可以看做签名的逆向，只不过覆盖安装可能还要校验公钥及证书信息一致，否则覆盖安装会失败。签名校验的入口在PackageManagerService的install里，安装官方文档，7.0以上的手机优先检测V2签名，如果V2签名不存在，再校验V1签名，对于7.0以下的手机，不存在V2签名校验机制，只会校验V1，所以，如果你的App的miniSdkVersion<24(N)，那么你的签名方式必须内含V1签名：

校验流程就是签名的逆向，了解签名流程即可，本文不求甚解，有兴趣自己去分析，只是额外提下覆盖安装，覆盖安装除了检验APK自己的完整性以外，还要校验证书是否一致只有证书一致（同一个keystore签名），才有可能覆盖升级。覆盖安装同全新安装相比较多了几个校验

这里只关心证书部分：

Android V1及V2签名签名原理简析

仅供参考，欢迎指正

D. 深入分析Android-Handler消息机制

Handler是Android消息机制的上层接口。通过它可以轻松地将一个任务切换到Handler所在的线程中去执行。通常情况下，Handler的使用场景就是 更新UI 。

在子线程中，进行耗时操作，执行完操作后，发送消息，通知主线程更新UI。

Handler消息机制主要包括： MessageQueue 、 Handler 、 Looper 这三大部分，以及 Message 。

从上面的类图可以看出：

MessageQueue、Handler和Looper三者之间的关系： 每个线程中只能存在一个Looper，Looper是保存在ThreadLocal中的。 主线程（UI线程）已经创建了一个Looper，所以在主线程中不需要再创建Looper，但是在其他线程中需要创建Looper。 每个线程中可以有多个Handler，即一个Looper可以处理来自多个Handler的消息。 Looper中维护一个MessageQueue，来维护消息队列，消息队列中的Message可以来自不同的Handler。

在子线程执行完耗时操作，当Handler发送消息时，将会调用 MessageQueue.enqueueMessage ，向消息队列中添加消息。 当通过 Looper.loop 开启循环后，会不断地从消息池中读取消息，即调用 MessageQueue.next ， 然后调用目标Handler（即发送该消息的Handler）的 dispatchMessage 方法传递消息， 然后返回到Handler所在线程，目标Handler收到消息，调用 handleMessage 方法，接收消息，处理消息。

从上面可以看出，在子线程中创建Handler之前，要调用 Looper.prepare() 方法，Handler创建后，还要调用 Looper.loop() 方法。而前面我们在主线程创建Handler却不要这两个步骤，因为系统帮我们做了。

初始化Looper ：

从上可以看出，不能重复创建Looper，每个线程只能创建一个。创建Looper，并保存在 ThreadLocal 。其中ThreadLocal是线程本地存储区（Thread Local Storage，简称TLS），每个线程都有自己的私有的本地存储区域，不同线程之间彼此不能访问对方的TLS区域。

开启Looper

创建Handler ：

发送消息 ：

post方法：

send方法：