写在前面的话
仅以此系列献给喜欢我CSDN的小伙伴们
申明
此文禁止转载，谢谢合作
序言
在开头说这会是一个系列，那就说明我有非常多话要说。从最简单的介绍到问题的提出。解决方式的构思以及整个系统的架构实现測试都会在这个系列里一一说明。假设你还在迷茫该怎么去深入一个问题，一点点解决，那我尽力会通过这个系列让你有一点点感悟。假设你已经一览众山小，那么请给我多多提出建议。
无论你是何种程度的程序猿，我的目的仅仅有一个。这是写给大家看的东西。
会用最简单最直白的方式表达。假设你不理解，一定是我的问题。你能够及时告诉我，我会努力把全部问题描写叙述的简单易懂。
在安卓平台，重打包问题是Android多年的顽疾。基本上大部分的恶意软件的流入是通过重打包。
假设你对移动端不了解，或者对这个问题不熟悉，那么你可能会问什么是重打包？
我们能够举个简单的样例。你从不同的平台下载了两个看似一模一样的APP，可是当中有一个APP可能除了正常的功能外也许还秘密的在后台不被人发现的进行着某些活动。
比方说点击明明点击某个确定button。可是附带的发送了一条短信到移动服务商定制了某些服务。而且在后台拦截了服务商发来的提示短信。
你本来以为一切都是正常的。可是某天查话费的时候，突然发现话费少了一大笔。没有收到不论什么服务商的通知，总哑巴吃黄连有苦说不出的感觉。
上面这个样例是重打包的典型案例。
以下是一些重打包经常使用的手段列举：
1.在原始的APP中增加了广告，这是最简单的一种手段
2. 改动了原始的APP，在保证了其用户体验全然同样的情况下以及不被用户发现的情况下偷偷添加了某些功能
3. 直接重写而且模仿了整个APP，而且添加了一些对应的功能。
看完这些有人会问这种问题？你怎么识别出原始的APP和重打包的APP，你怎么知道不是作者本人改动的而是其它人改动的。
对于这个问题我们须要了解一点Android的APP是怎么公布到我们的市场上去的。
每一个app的开发人员要把自己的APP公布到网上让大家都能使用它必须申请一个账号而且缴纳一定的费用便能够将自己的APP上传到想要的市场上去。
当然。比較正式的官网会做一些安全监測，保护用户的安全。
可是这个措施不是总有效的。
其次，Android的开发人员众多，每天添加的APP数目是惊人的
最后。Android的APP是非常easy被反编译破解的。
这些问题的存在导致了重打包这个顽疾能够长期存在。
既然存在了这么久一定会有一些解决的方法，那如今都有些什么解决的方法？
最早出现的解决的方法就是依据代码的特征。
逻辑是这种，重打包一定实现了原始APP没有实现的功能，我仅仅要检測出这些多余的代码就能够看出这个APP有没有经过重打包但是如今的问题是，重代码的角度出发来解决这个问题，面临的最重要的挑战操作码的数量巨大，必定会产生庞大的计算复杂度。加上要检測如此众多的APP，必定会捉襟见肘。
这个时候有人会说，为了扩大影响范围，一般重打包软件的制作者会选择一些受欢迎的APP来进行处理。这样感染的速度最快。我们在检測的时候比方说仅仅针对前10000万个。建立一个原始APP的数据库。通过签名对照非常easy就能够找到重打包的APP
事实真的是这种，依据签名比較来实现真的靠谱么。
这样就能够避免计算复杂度了么。
想想怎么去找到10000个APP中的原始APP。重google play 上下载的能够算是原创的么。第三方市场为数如此众多，真的能够有效的降低时间复杂度么。
有什么的新方案么？
这就是今天以及以后我将要解决的问题。——基于资源来检測
你也许可能会问？这样靠谱么？
首先我们先来解决一个问题？在Android中什么是资源
在Android中，一个Activity能够看成资源，service。receiver。provider这些组件都能够看成资源。一张图片，一个字符串。id, xml文件这些都能够看成资源。而且就算如今的一些加固技术仍不能改变一些资源。这就确保了我们检測的可靠性。
既然理论上是可行。这样从资源这个比代码更加宏观的角度来看问题。把问题分割的更大，时间复杂度就降下来了。其次。更加可靠。
思路是这样，我们把APP分解。由于我们能够通过Intent来得到这个APP之间组件的调用关系。
一个Activity从慷慨向上来看就是有一个个的组件构成的，组件的调用关系能够通过intent非常快的确认。每个APP都被我们拆分成一个个的图。其次，我们把每个节点细化，比方一个Activity上可能有一些组件。组件可能绑定了相关的事件。
听着有点晕，看看以下这图，也许我们可能就会比較easy理解：
我们要实现的就是能够有效识别新添加的组件A7，或者是在原始的APP上新添加的某个事件。比方向上文所说的那样。能够识别出改变了的button功能。
在未来的这个系列中我们就一点点来说明怎么通过资源来解决重打包问题。