2011~2015，5年时间，断断续续学习了Android。
最近打算在2011年2个月认真学习的基础上，深入学习下。
由于有之前的Android基础，加上N年的Java等变成经验，自我感觉Android应用开发还是比较简单的。
至少相比iOS开发来说。
继续坚持自己的习惯，写点自己的体会，总结自己的经验。
学了又忘了，没啥用啊~
Android打包之后，生成了APK文件。
APK文件其实是个zip文件。
比如，FileExplorer.apk，把后缀改成zip，就成了 FileExplorer.zip。
类似的还有Excel文件，比如FansUnion.xlsx，改后缀FansUnion.zip，解压之后：
_rels
docProps
xl
[Content_Types].xml
有兴趣的可以自己试试哦~
解压之后：
META-INF
--CERT.RSA
--CERT.SF
--MANIFEST.MF（Java打包的程序，基本都有这个文件.最初以为和Java中的一样，后来发现不是的。）
（1）MANIFEST.MF：这是摘要文件。程序遍历Apk包中的所有文件(entry)，对非文件夹非签名文件的文件，逐个用SHA1生成摘要信息，再用Base64进行编码。如果你改变了apk包中的文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是程序就不能成功安装。
说明：如果攻击者修改了程序的内容，有重新生成了新的摘要，那么就可以通过验证，所以这是一个非常简单的验证。
（2）CERT.SF：这是对摘要的签名文件。对前一步生成的MANIFEST.MF，使用SHA1-RSA算法，用开发者的私钥进行签名。在安装时只能使用公钥才能解密它。解密之后，将它与未加密的摘要信息（即，MANIFEST.MF文件）进行对比，如果相符，则表明内容没有被异常修改。
说明：在这一步，即使开发者修改了程序内容，并生成了新的摘要文件，但是攻击者没有开发者的私钥，所以不能生成正确的签名文件（CERT.SF）。系统在对程序进行验证的时候，用开发者公钥对不正确的签名文件进行解密，得到的结果和摘要文件（MANIFEST.MF）对应不起来，所以不能通过检验，不能成功安装文件。
（3）CERT.RSA文件中保存了公钥、所采用的加密算法等信息。
说明：系统对签名文件进行解密，所需要的公钥就是从这个文件里取出来的。
结论：从上面的总结可以看出，META-INFO里面的说那个文件环环相扣，从而保证Android程序的安全性。（只是防止开发者的程序不被攻击者修改，如果开发者的公私钥对对攻击者得到或者开发者开发出攻击程序，Android系统都无法检测出来。）
res（各种XML资源文件）
--drawable
--layout
--等等
这个目录，有个特别的“战略意义”~
上次看一篇Android文章，关于汉化的。汉化Android程序，先把APK文件解压，然后修改res资源文件，最后再次打包，再安装，
这样就汉化了Android程序。我觉得，理论是可行的，目前没有试过。
AndroidManifest.xml（Android项目的标准文件）
classes.dex（Java文件最后生成的，.java->.class->.dex）
resources.arsc(也是资源文件）
只有那些类型为res/animator、res/anim、res/color、res/drawable（非Bitmap文件，即非.png、.9.png、.jpg、.gif文件）、
res/layout、res/menu、res/values和res/xml的资源文件均会从文本格式的XML文件编译成二进制格式的XML文件。
好处应该是效率。
参考资料：
Android签名与认证详细分析之一（CERT.RSA剖析）
http://myeyeofjava.iteye.com/blog/2125348
Android应用程序资源的编译和打包过程分析
http://www.cnblogs.com/mfryf/archive/2013/05/21/3090844.html
小雷FansUnion--一个正在学习Android的程序员