【Android高级】一些难点问题简介，很有意思的问题。
Android为什么要设计出Bundle而不是直接使用HashMap来进行数据传递？
* Bundle内部是由ArrayMap实现的，ArrayMap的内部实现是两个数组，一个int数组是存储对象数据对应下标，一个对象数组保存key和value，内部使用二分法对key进行排序，所以在添加、删除、查找数据的时候，都会使用二分法查找，只适合于小数据量操作，如果在数据量比较大的情况下，那么它的性能将退化。而HashMap内部则是数组+链表结构，所以在数据量较少的时候，HashMap的Entry Array比ArrayMap占用更多的内存。因为使用Bundle的场景大多数为小数据量，我没见过在两个Activity之间传递10个以上数据的场景，所以相比之下，在这种情况下使用ArrayMap保存数据，在操作速度和内存占用上都具有优势，因此使用Bundle来传递数据，可以保证更快的速度和更少的内存占用。
* 另外一个原因，则是在Android中如果使用Intent来携带数据的话，需要数据是基本类型或者是可序列化类型，HashMap使用Serializable进行序列化，而Bundle则是使用Parcelable进行序列化。而在Android平台中，更推荐使用Parcelable实现序列化，虽然写法复杂，但是开销更小，所以为了更加快速的进行数据的序列化和反序列化，系统封装了Bundle类，方便我们进行数据的传输。
Android中IPC通信的方式有哪些？使用场景是什么？

谈谈你对Application类的理解
首先，Application在一个Dalvik虚拟机里面只会存在一个实例，那么为什么强调说是一个Dalvik虚拟机，而不是说一个App呢？因为一个App有可能有多个Dalvik虚拟机，也就是传说中的多进程模式。在这种模式下，每一个Dalvik都会存在一个Application实例，他们之间没有关系，在A进程Application里面保存的数据不能在B进程的Application获取，因为他们根本不是一个对象，而且被隔离在了两个进程里面，所以这里强调是一个Dalvik虚拟机，而不是一个App。由于在Context中可以通过getApplicationContext()获取到Application对象，或者是通过Activity.getApplication()、Service.getApplication()获取到Application，所以可以在Application保存全局的数据，供所有的Activity或者是Service使用。使用上面的三种方法获取到的都是一个Application对象，getApplicationContext()是在Context的实现类ContextImpl中具体实现的，而getApplication()是在Activity和Service中单独实现的，所以他们的作用域不同，但是获取到的都是同一个Application对象，因为一个Dalvik虚拟机只有一个Application对象。最后，就是要注意Application的生命周期，他和Dalvik虚拟机生命周期一样长，所以在进行单例或者是静态变量的初始化操作时，一定要用Application作为Context进行初始化，否则会造成内存泄露的发生。
缓存文件可以放在哪里？它们各自的特点是什么？
在Android手机里面，缓存的位置分为两类，一类是Internal Storage，即内部存储，另外一类是External Storage，即外部存储。
内部存储
总是可用的
这里的文件默认是只能被你的app所访问的。
当用户卸载你的app的时候，系统会把internal里面的相关文件都清除干净。
Internal是在你想确保不被用户与其他app所访问的最佳存储区域。
外部存储
并不总是可用的，因为用户可以选择把这部分作为USB存储模式，这样就不可以访问了。
是大家都可以访问的，因此保存到这里的文件是失去访问控制权限的。
当用户卸载你的app时，系统仅仅会删除external根目录（getExternalFilesDir()）下的相关文件。
External是在你不需要严格的访问权限并且你希望这些文件能够被其他app所共享或者是允许用户通过电脑访问时的最佳存储区域。
文件位置
—内部存储
getFileDir() 通过此方法可以获取到你的APP内部存储的文件，路径为/data/data/pacgage_name/files
getCacheDir() 通过此方法可以获取到你的APP内部存储的文件，路径为/data/data/package_name/cache
openFileOutput() 通过此方法，我们可以获取到一个输出流，输出流的保存路径是/data/data/package_name/files ，和getFileDir()的路径一致
—外部存储
——私有存储
Context.getExternalCacheDir()
Context.getExternalFilesDir()
创建的私有文件的地址是/sdcard/Android/date/package_name下面，Android文件夹是隐藏文件夹，用户无法操作。
如果我们想缓存图片等比较耗空间的文件，推荐放在getExternalCacheDir()所在的文件下面，这个文件和getCacheDir()很像，都可以放缓存文件，在APP被卸载的时候，都会被系统删除，而且缓存的内容对其他APP是相对私有的。
——公共存储
你的APP产生的文件不需要隐藏，即对用户是可见的，那么你可以把文件放在外部的公共存储文件下面。这个方法不是Context的方法，而是Environment的两个方法，第一个方法获取到的其实是外部存储的根目录，而第二个方法获取到得则是外部存储的公共目录。其实在访问权限上是没有区别的，不同点是getExternalStoragePublicDirectory()在运行的时候，会需要你带有一个特定的参数来指定这些public的文件类型，以便于与其他public文件进行分类。
Environment.getExternalStorageDirectory()
Environment.getExternalStoragePublicDirectory()
表现
—内部存储
你的app的internal storage 目录是以你的app的包名作为标识存放在Android文件系统的特定目录下[data/data/com.example.xx]。 从技术上讲，如果你设置文件为可读的，那么其他app就可以读取你的internal文件。然而，其他app需要知道你的包名与文件名。若是你没有设置为可读或者可写，其他app是没有办法读写的。因此只要你使用MODE_PRIVATE ，那么这些文件就不可能被其他app所访问。
另外记住一点，内部存储在你的APP卸载的时候，会一块被删除，因此，我们可以在cache目录里面放置我们的图片缓存，而且cache与files的差别在于，如果手机的内部存储空间不够了，会自行选择cache目录进行删除，因此，不要把重要的文件放在cache文件里面，可以放置在files里面，因为这个文件只有在APP被卸载的时候才会被删除。还有要注意的一点是，如果应用程序是更新操作，内部存储不会被删除，区别于被用户手动卸载。
—外部存储
不管你是使用 getExternalStoragePublicDirectory() 来存储可以共享的文件，还是使用 getExternalFilesDir() 来储存那些对于你的app来说是私有的文件，有一点很重要，那就是你要使用那些类似DIRECTORY_PICTURES 的API的常量。那些目录类型参数可以确保那些文件被系统正确的对待。例如，那些以DIRECTORY_RINGTONES 类型保存的文件就会被系统的media scanner认为是ringtone而不是音乐。
清除数据、清除缓存的区别
清除数据主要是清除用户配置，比如SharedPreferences、数据库等等，这些数据都是在程序运行过程中保存的用户配置信息，清除数据后，下次进入程序就和第一次进入程序时一样
缓存是程序运行时的临时存储空间，它可以存放从网络下载的临时图片，从用户的角度出发清除缓存对用户并没有太大的影响，但是清除缓存后用户再次使用该APP时，由于本地缓存已经被清理，所有的数据需要重新从网络上获取。为了在清除缓存的时候能够正常清除与应用相关的缓存，请将缓存文件存放在getCacheDir()或者 getExternalCacheDir()路径下。
应用内切换主题有哪些方案可以实现
这里讨论的只是白天、夜晚主题切换这种场景，不涉及外部资源加载。
现在要给App添加夜晚主题，所以就需要选择一种应用内部更换主题的实现方案，目前来说，比较常见的几种方式如下：
（1）Theme
设置Theme来切换不同主题。
优点：利用系统自带的机制实现，根据标志位setTheme()即可。
缺点：在主题切换界面不重启的情况下，不能自动完成界面主题的刷新。
（2）遍历View
对主题的更换，使用遍历View，然后单独设置更改后的属性即可。
优点：可以即时更新界面，不需要重启Activity
缺点：需要单独添加标志位，来标记需要更换主题的View，需要增加额外工作，另外就是标记的添加，有可能影响原来的代码逻辑。
（3）开源项目
关于Theme的解决方案就不说了，就是在style文件中定义不同的主题即可。
目前开源的几个应用内换肤项目，基本采用的都是遍历View，然后更换属性来完成，下面我们简单分析一下实现机制。
MultipleTheme
Colorful
AndroidChangeSkin
NightOw
JIT与Dalvik
JIT是"Just In Time Compiler"的缩写，就是"即时编译技术"，与Dalvik虚拟机相关。
我们使用Java开发android，在编译打包APK文件时，会经过以下流程
Java编译器将应用中所有Java文件编译为class文件
dx工具将应用编译输出的类文件转换为Dalvik字节码，即dex文件
之后经过签名、对齐等操作变为APK文件。
Dalvik虚拟机可以看做是一个Java VM，他负责解释dex文件为机器码，如果我们不做处理的话，每次执行代码，都需要Dalvik将dex代码翻译为微处理器指令，然后交给系统处理，这样效率不高。为了解决这个问题，Google在2.2版本添加了JIT编译器，当App运行时，每当遇到一个新类，JIT编译器就会对这个类进行编译，经过编译后的代码，会被优化成相当精简的原生型指令码（即native code），这样在下次执行到相同逻辑的时候，速度就会更快。当然使用JIT也不一定加快执行速度，如果大部分代码的执行次数很少，那么编译花费的时间不一定少于执行dex的时间。Google当然也知道这一点，所以JIT不对所有dex代码进行编译，而是只编译执行次数较多的dex为本地机器码。
有一点需要注意，那就是dex字节码翻译成本地机器码是发生在应用程序的运行过程中的，并且应用程序每一次重新运行的时候，都要做重做这个翻译工作，所以这个工作并不是一劳永逸，每次重新打开App，都需要JIT编译。
ART与AOT
AOT是"Ahead Of Time"的缩写，指的就是ART(Anroid RunTime)这种运行方式。
前面介绍过，JIT是运行时编译，这样可以对执行次数频繁的dex代码进行编译和优化，减少以后使用时的翻译时间，虽然可以加快Dalvik运行速度，但是还是有弊病，那就是将dex翻译为本地机器码也要占用时间，所以Google在4.4之后推出了ART，用来替换Dalvik。在4.4版本上，两种运行时环境共存，可以相互切换，但是在5.0+，Dalvik虚拟机则被彻底的丢弃，全部采用ART。ART的策略与Dalvik不同，在ART 环境中，应用在第一次安装的时候，字节码就会预先编译成机器码，使其成为真正的本地应用。之后打开App的时候，不需要额外的翻译工作，直接使用本地机器码运行，因此运行速度提高。
当然ART与Dalvik相比，还是有缺点的。ART需要应用程序在安装时，就把程序代码转换成机器语言，所以这会消耗掉更多的存储空间，但消耗掉空间的增幅通常不会超过应用代码包大小的20%。由于有了一个转码的过程，所以应用安装时间难免会延长。但是这些与更流畅的Android体验相比而言，不值一提。
总结
通过前面背景知识的介绍，我终于可以更简单的介绍这四个名词之间的关系了：
JIT代表运行时编译策略，也可以理解成一种运行时编译器，是为了加快Dalvik虚拟机解释dex速度提出的一种技术方案，来缓存频繁使用的本地机器码
ART和Dalvik都算是一种Android运行时环境，或者叫做虚拟机，用来解释dex类型文件。但是ART是安装时解释，Dalvik是运行时解释
AOT可以理解为一种编译策略，即运行前编译，ART虚拟机的主要特征就是AOT