面试总结

转载请标明出处:
http://blog.csdn.net/hai_qing_xu_kong/article/details/51244924
本文出自：【顾林海的博客】

前言

今天去饿了么面试，总体来说很失望，没搞明白对方所问这些问题的重点在哪里（当时脑袋一片空白），个人觉得面试官自己也描述不清楚，那么下面是自己回去后总结的问题以及自己深思熟虑后想到的一些知识点。之前自己也面试过很多Android开发者，但与今天面试的可能不太一样，关注点不一样，以前换做是我的话，主要问一些功能实现。（PS：本人不善言谈，其次并不是不懂，而是有些东西在心里，但就是不知道如何用语言来表达，或许这也是我这次面试失败的原因）

65K限制问题

65K限制问题说白了在日常开发中没有碰到过，所属部门不同担任的责任也不尽相同，现在网上解决方案比较多，像multidex之类的，或者在Project.proterty中加“dex.force.jumbo=true”配置（2.3系统的机器上很容易出现INSTALL_FAILED_DEXOPT异常），为什么会产出65K以及2.3系统的问题，我想底下的答案已经是很好的阐述了：

1、Android系统中，一个Dex文件中存储方法id用的是short类型数据，所以导致你的dex中方法不能超过65k
2、在2.3系统之前，虚拟机内存只分配了5M

面对65K的问题单纯从Android系统的结构上来看，只可远观，也就是无法从应用层去修改数据类型，抛开市面上的一些解决方案来说，怎样尽量避免65K这个天花板呢？面对这个天花板我们只能这样做：

1、去除无用的jar包，比如第三方的jar包，一些功能能自己拆分出来的，尽量不要使用完整的jar包。
2、可以将属性设置成public，从而去掉get/set放。
注意：这些只是临时解决方案，面对一些大公司并不适用。

通过上面的一些预防措施，最后这个天花板还是到来时，这时我们就要请出当前一些主流的解决方案

一种是微信代表的，也就是将功能做成插件，进行动态加载；还有一种就是facebook为代表的分包方案，将一个dex文件进行分割，最后进行动态的加载dex文件。
这两种方案代表核心思想都是一样的，但分包方案是将功能拆分成多个dex文件，那么本身的应用体积并没有什么改变，但插件化方案不但能解决天花板问题，还能使应用体积减小。

关于分包机制与插件化可以参照以下两篇文章：

彻底解决Android 应用方法数不能超过65K的问题

实现Android 动态加载APK（Fragment or Activity实现）

HashMap

在很早以前使用HashMap，那时用的还给出了一个performance警告，今天被面试到这个HashMap时，不由的想到了之前碰到的这个警告，单从警告上看是建议你使用SparseArray，查看相关资料，SparseArray指的是稀疏数组，它是Android提供的一个工具类，为什么叫稀疏数组，查看源码其实和List一样，只是内部做了矩阵压缩，减少存储空间，节约内存，值得指出的是它的查找算法采用的是二分法，从而提高了查找效率。

使用HashMap更占内存，除了使用上面的SparseArray之外，查阅网上资料，我们还可以使用ArrayMap,它内部使用两个数组进行工作，其中一个数组记录key hash过后的顺序列表，另外一个数组按key的顺序记录Key-Value值，当获取某个value的时候，ArrayMap会计算输入key转换过后的hash值，然后对hash数组使用二分查找法寻找到对应的index，然后我们可以通过这个index在另外一个数组中直接访问到需要的键值对。如果在第二个数组键值对中的key和前面输入的查询key不一致，那么就认为是发生了碰撞冲突。为了解决这个问题，我们会以该key为中心点，分别上下展开，逐个去对比查找，直到找到匹配的值，随着数组中的对象越来越多，查找访问单个对象的花费也会跟着增长，这是在内存占用与访问时间之间做权衡交换。

ArrayMap的使用场景：

对象个数的数量级最好是千以内
数据组织形式包含Map结构

如何优化界面

当我听到面试官问这个问题时，其实我内心是拒绝的，因为我压根不明白面试官问的重心点在哪里。

验证一个界面是否卡顿，归根到底还是采用了多层次重叠试图，导致大量的性能问题，为此我们可以通过手机设置的开发者选项，打开Show GPU Overdraw的选项，观察UI上的Overdraw情况。

蓝色，淡绿，淡红，深红代表了4种不同程度的Overdraw情况，我们的目标就是尽量减少红色Overdraw，看到更多的蓝色区域。

其次可以去除一些layout文件非必须的background。

优化步骤如下：
移除Window默认的Background
移除XML布局文件中非必需的Background
按需显示占位背景图片

平时通过自定义View时重新onDraw方法,Android系统无法检测在onDraw里面具体会执行什么操作，系统无法监控并自动优化，我们可以通过canvas.clipRect()来帮助系统识别那些可见的区域。同时clipRect方法还可以帮助节约CPU与GPU资源，在clipRect区域之外的绘制指令都不会被执行，那些部分内容在矩形区域内的组件，仍然会得到绘制。

除了clipRect方法之外，我们还可以使用canvas.quickreject()来判断是否没和某个矩形相交，从而跳过那些非矩形区域内的绘制操作。

一些性能上的优化可以参看以下文章：

Android性能优化之渲染篇

对于布局嵌套优化，可以使用include标签重用layout、使用ViewStub实现View的延迟加载。

Volley与okhttp区别

关于这个问题，先来个总体的介绍。

OkHttp：

OkHttp是一个现代，快速，高效的Http client，支持HTTP/2以及SPDY，它为你做了很多的事情。纵观一眼OkHttp为你实现的诸多技术如连接池，gziping，缓存等就知道网络相关的操作是多么复杂了。OkHttp扮演着传输层的角色。
OkHttp使用Okio来大大简化数据的访问与存储，Okio是一个增强 java.io 和 java.nio的库 。
OkHttp和Okio都是Square团队开发的。
OkHttp是一个现代，快速，高效的Http client，支持HTTP/2以及SPDY，扮演着传输层的角色。

Volley：

Volley是一个简化网络任务的库。他负责处理请求，加载，缓存，线程，同步等问题。它可以处理JSON，图片，缓存，文本源，支持一定程度的自定义。
Volley是为RPC网络操作而设计的，适用于短时操作。
Volley默认在Froyo上使用Apache Http stack作为其传输层，在Gingerbread及之后的版本上使用HttpURLConnection stack作为传输层。原因是在不同的安卓版本中这两种http stack各自存在一些问题。
Volley可以轻松设置OkHttp作为其传输层。
Volley是谷歌开发的。

MVC、MVP、MVVM

面试过程被问到分层处理，常用的是MVC，MVP与MVVM没用到过，抱着对MVP与MVVM敬畏的心，查阅相关资料，自己也通过案例演示了一遍。

先看看常用的MVC：

采用MVC模式的好处是便于UI界面部分的显示和业务逻辑，数据处理分开。M层：适合做一些业务逻辑处理，比如数据库存取操作，网络操作，复杂的算法，耗时的任务等都在model层处理。 V层：应用层中处理数据显示的部分，XML布局可以视为V层，显示Model层的数据结果。 C层：在Android中，Activity处理用户交互问题，因此可以认为Activity是控制器，Activity读取V视图层的数据，控制用户输入，并向Model发送数据请求（发起网络请求等）。

PS：上面所提到的Volley网络请求框架其实也是遵循着MVC框架的。

为什么会推出MVP框架，使用MVC导致了Activity承担的任务和逻辑处理太多，职责不清晰。

MVP：

MPV 是从经典的MVC模式演变过来的，其基本思路都是相通的。其中M是model模型，提供业务数据；P和MVC中的C担当的角色相似，是Presenter控制者，进行逻辑处理。V是View视图，显示数据。MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。

以下是MVC的框架图：

以下是MVP的框架图：

从上面的框架图可以看出MVC和MVP最大的区别就是 Model和View之间的关系。在MVC框架中，View是可以直接读取Model模型中的数据的，Model模型数据发生改变是会通知View数据显示发生相应的改变。而在MVP中Model和View之间的没有任何联系，是两个完全独立的模块，当Model模型发生数据改变时，通过Presenter通知View视图发生相应的UI改变。因此，个人觉得：MVP才是正真的视图和模型完全分离，也就是Model模型进行业务数据处理和View视图显示没有任何关联。

MVVM：

目前流行的第三方框架RoboAndroid可以支持MVVM模型。这个各位看官请自行查找相关说明。

写在最后的话

我自认为自己不是高手，所以我每天不停的查阅资料，学习各方面知识。个人觉得自己属于创业型开发者，独自开发一款产品，抗压比较强，Android这条路还长，面对这条充满荆棘的路，唯有抱着对编程的热爱坚持下去。