面试挫折录-第2集

1.个人规划

这个问题经常被问到，今天面试又被问到了，就是你的目标是什么？职业规划是什么？
这个问题感觉自己没回答好，我想我的规划应该是这样的。一年内成为一名中级安卓开发工程师，将谷歌安卓开发文档的内容全部吃透http://www.android-doc.com/training/，在github上发布一个自己设计开发的框架工具，在主流应用商店上线一款APP；三年内成为一名高级安卓开发工程师，阅读一定量的安卓系统源码；五年内精通C与C++，能运用H5与JS、PHP制作一款成熟的WEB端APP，向着全栈工程师方面发展;最终目标，成为一名系统级别的架构师。

2.你在做项目时遇到了什么问题

这道题几乎是必问的，就是自己做APP时遇到了什么印象特别深刻的难题，难题是怎么解决的，这种问题只能是靠自己做项目时的经验来解决了，应该多把自己的作品研究下，或者在开发时就把难题用笔记记起来，这样才不会显得手足无措。

3.异步任务的执行顺序

这一题我好像回答了没有特定的顺序，完全是靠CPU自主分配时间片，刚搜了一下，好像我答非所问了！异步任务指的应该就是AsyncTask这个类，我印象中最多只有5个异步任务同时存在，找了许久的答案，终于看到一个跟执行顺序相关的了。
通过AsyncTask.execute()执行
1. <1.6 ：在1.6(Donut)之前: 在第一版的AsyncTask，任务是串行调度。一个任务执行完成另一个才能执行。由于串行执行任务，使用多个AsyncTask可能会带来有些问题。
所以这并不是一个很好的处理异步（尤其是需要将结果作用于UI试图）操作的方法
2. 1.6 – 2.3： 所有的任务并发执行，这会导致一种情况，就是其中一条任务执行出问题了，会引起其他任务出现错误.
3. 3.0以上 ：AsyncTask又修改为了顺序执行，并且新添加了一个函数 executeOnExecutor(Executor)，如果您需要并行执行，则只需要调用该函数，并把参数设置为并行执行即可。
并行执行asyncTask.executeOnExecutor(Executors.newFixedThreadPool(7), “”);
AsyncTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR)你也可以采用这个系统提供的线程池来处理你的任务
默认这个线程池是并发处理任务的，也就是不按顺序来.核心为5条,最大128条。
总结:就是3.0以上的版本异步任务是有默认的执行顺序的，先添加先执行，但也可以把它设置为并发执行，并发执行意思就是无顺序，靠CPU自行调度。

4.内存泄漏与内存溢出

这道题目也是老生常谈了，出现频率也是挺高的呢。

• 内存泄漏: Memory Leak，内存泄漏是指分配出去的内存没有被回收回来，由于失去了对该内存区域的控制，因而造成了资源的浪费。Java中一般不会产生内存泄漏，因为有垃圾回收器自动回收垃圾，但这也不绝对，当我们new了对象，并保存了其引用，但是后面一直没用它，而垃圾回收器又不会去回收它，这就会造成内存泄漏。
  以发生的方式来分类，内存泄漏可以分为4类：
  
  1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
  2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
  3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
  4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
  5. 从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到
• 内存溢出: Out of Memory,内存溢出是指程序所需要的内存超过了系统所能分配的内存（包括动态扩展）的上限。
  众所周知，每个Android应用程序在运行时都有一定的内存限制，限制大小一般为16MB或24MB（视平台而定）。因此在开发应用时需要特别关注自身的内存使用量，而一般最耗内存量的资源，一般是图片、音频文件、视频文件等多媒体资源；由于Android系统对音频、视频等资源做了边解析便播放的处理，使用时并不会把整个文件加载到内存中，一般不会出现内存溢出（简称OOM）的错误。目前碰到的OOM场景，无外乎以下几种情形，(1)显示单张图片，图片文件体积达到3000*4000级别的时候；(2)在ListView或Gallery等控件中一次性加载大量图片时。另外要注意的是内存泄漏也可能会引起内存溢出，当泄漏的内存超过程序内存最大上限时就会发生OOM。

5.加载的图片过多时如何处理

由于今天面试的公司是一家做在线商场的，要加载许多的商品图片，所以这个问题对于此类应用来说是非常重要的，网上找到一个比较全面的答案。

内存限制是Android对应用的一个系统级限制，作为应用层开发人员，没有办法彻底去消灭这个限制，但是可以通过一些手段去合理使用内存，从而规避这个问题。以下是个人总结的一些常用方法：

(1)缓存图像到内存，采用软引用缓存到内存，而不是在每次使用的时候都从新加载到内存；现在常用的方法是用Lrucache,这个类的作用是设定一个缓存的大小，当缓存超过这个大小时就会释放掉以前存储的内容。这个类非常适合用来缓存图片，它的主要算法原理是把最近使用的对象用强引用存储在 LinkedHashMap 中，并且把最近最少使用的对象在缓存值达到预设定值之前从内存中移除。这样也可以提高图片的再次加载速度与滑动的流畅度。

private LruCache<String, Bitmap> mMemoryCache;  
@Override  
protected void onCreate(Bundle savedInstanceState) {  
    // 获取到可用内存的最大值，使用内存超出这个值会引起OutOfMemory异常。  
    // LruCache通过构造函数传入缓存值，以KB为单位。  
    int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);  
    // 使用最大可用内存值的1/8作为缓存的大小。  
    int cacheSize = maxMemory / 8;  
    mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {  
        @Override  
        protected int sizeOf(String key, Bitmap bitmap) {  
            // 重写此方法来衡量每张图片的大小，默认返回图片数量。  
            return bitmap.getByteCount() / 1024;  
        }  
    };  
}  
public void addBitmapToMemoryCache(String key, Bitmap bitmap) {  
    if (getBitmapFromMemCache(key) == null) {  
        mMemoryCache.put(key, bitmap);  
    }  
}  
public Bitmap getBitmapFromMemCache(String key) {  
    return mMemoryCache.get(key);  
}

(2)调整图像大小，可以先得到图片大小，然后进行压缩，手机屏幕尺寸有限，分配给图像的显示区域本身就更小，有时图像大小可以做适当调整；BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于创建Bitmap对象，我们应该根据图片的来源选择合适的方法。比如SD卡中的图片可以使用decodeFile方法，网络上的图片可以使用decodeStream方法，资源文件中的图片可以使用decodeResource方法。这些方法会尝试为已经构建的 bitmap分配内存，这时就会很容易导致OOM出现。为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就可以让解析方法禁止为bitmap分配内存，返回值也不再是一个Bitmap对象，而是 null。虽然Bitmap是null了，但是BitmapFactory.Options的outWidth、outHeight和 outMimeType属性都会被赋值。这个技巧让我们可以在加载图片之前就获取到图片的长宽值和MIME类型，从而根据情况对图片进行压缩。

(3)采用低内存占用量的编码方式，比如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省内存；

(4)及时回收图像，如果引用了大量Bitmap对象，而应用又不需要同时显示所有图片，可以将暂时用不到的Bitmap对象及时回收掉；

(5)自定义堆内存分配大小，优化Dalvik虚拟机的堆内存分配；对于Android平台来说，其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法: 代码如下：

private final static floatTARGET_HEAP_UTILIZATION = 0.75f;

在程序onCreate时就可以调用

VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);即可

（6）自定义我们的应用需要多大的内存

private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;

//设置最小heap内存为6MB大小

VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);

6.Https为什么比Http安全

一、什么是HTTPS
在说HTTPS之前先说说什么是HTTP，HTTP就是我们平时浏览网页时候使用的一种协议。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定义在RFC 6101中，之后IETF对SSL 3.0进行了升级，于是出现了TLS（Transport Layer Security） 1.0，定义在RFC 2246。实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在浏览器所支持，因此SSL依然是HTTPS的代名词，但无论是TLS还是SSL都是上个世纪的事情，SSL最后一个版本是3.0，今后TLS将会继承SSL优良血统继续为我们进行加密服务。目前TLS的版本是1.2，定义在RFC 5246中，暂时还没有被广泛的使用。
对历史感兴趣的朋友可以参考详尽的叙述。
二、HTTPS到底安全吗？
这个答案是肯定的，很安全。谷歌公司已经行动起来要大力推广HTTPS的使用，在未来几周，谷歌将对全球所有本地域名都启用HTTPS，用户只要在搜索前用Google帐号登录，之后所有的搜索操作都将使用TLS协议加密，见此处
三、HTTPS的工作原理
HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的简单描述如下：
1. 浏览器将自己支持的一套加密规则发送给网站。
2. 网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
3. 获得网站证书之后浏览器要做以下工作：
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
4.网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。
5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256
其中非对称加密算法用于在握手过程中加密生成的密码，对称加密算法用于对真正传输的数据进行加密，而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。
TLS握手过程中如果有任何错误，都会使加密连接断开，从而阻止了隐私信息的传输。正是由于HTTPS非常的安全，攻击者无法从中找到下手的地方，于是更多的是采用了假证书的手法来欺骗客户端，从而获取明文的信息，但是这些手段都可以被识别出来。