Android 2017.7.11 面试总结

最新推荐文章于 2024-11-08 13:58:32 发布

一洼世界

最新推荐文章于 2024-11-08 13:58:32 发布

阅读量246

点赞数

分类专栏： Android-面试文章标签： android

本文链接：https://blog.csdn.net/u010829149/article/details/77935358

版权

Android-面试专栏收录该内容

1 篇文章 0 订阅

订阅专栏

2017.7.11 面试总结

1. volley 的缓存和okhttp对比。

1.okhttp结合retrofit的http
2.okhttp结合retrofit 的线程池
3.interceptor 
4.okio来简化数据的访问和存储。
5.链条委托机制

配置Okhttp的Cache
配置请求头中的cache-control或者统一处理所有请求的请求头
云端配合设置响应头或者自己写拦截器修改响应头中cache-control

volley的话：2.3以上使用的是HttpUrlconnnection 2.3以下使用的httpclient、下载文件不行。缺点是不支持同步，这点会限制开发模式

**为什么文件的下载不行？问题13**

结合retrofit的时候:

  Interceptor ：
             1可以设置Log拦截器，
             2缓存机制(有网／无网的缓存策略)
             3.公共参数 
             4.头信息 
             5.超时重连，

*优化网络的策略：*
    1.连接复用节省连接建立时间，如开启keep-alive
    2.不用域名，用IP直连省去DNS解析过程，根据域名得到IP地址
    3.Gzip 减少体积

2. ThreadPoolExecutor的线程优点等

    1.降低资源
    2.提高响应速度
    3.提高线程的可管理型。
    设置队列的长度，不燃会OOM，设置了队列的长度，会有任务得不到处理，这里构建阻塞线程池。

3. Intentservice的什么时候销毁

     不会销毁。只有等unbind的时候才会。

4. Bindservice能销毁吗，怎么不让他销毁

    onStartCommand() 方法返回整型数来描述系统应该如何在服务终止的情况下继续运行服务.
onStartCommand有三种返回值：
    START_STICKY：sticky的意思是“粘性的”。使用这个返回值时，我们启动的服务跟应用程序"粘"在一起，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务。当再次启动服务时，传入的第一个参数将为null;
    START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务。
    START_REDELIVER_INTENT：重传Intent。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入

*上面startService()和bindService()两种模式是完全独立的。你可以绑定一个已经通过startService()方法启动的服务*。例如：一个后台播放音乐服务可以通过startService(intend)对象来播放音乐。可能用户在播放过程中要执行一些操作比如获取歌曲的一些信息，此时activity可以通过调用bindServices()方法与Service建立连接。这种情况下，stopServices()方法实际上不会停止服务，直到最后一次绑定关闭

5. Glide，picasso的区别：

  1. jar大小。glide 440KB    ， picasso。121KB
  2. Glide 就会非常智能的同 Activity和Fragment 的生命周期集成。
  3. 缓存策略：
    picasso: 只缓存完整的大小到本地。view大小改变，在原尺寸就行改变 resize。
    glide：需要缓存不同大小的尺寸同一张图片，先下载，改变图片大小，适应imageview的要求，然后缓存。
  4. 内存的使用：rgb-565，picasso。argb-8888，glide所占内存比较小。Picasso 是缓存的 full size 图片的大小，再去修改适配View大小，而 Glide 是加载已经改变大小后的图片，显而易见使用的memory会小很多
  5. 加载图片的时间 
    下载的：Picasso 是直接把图加载到内存中，而 Glide 则需要改变图片大小再加载到内存
    缓存的：因为Picasso 从缓存中拿到的图片，还要先去 resize 后，然后设定给 imageView
  6. GIF 支持：Glide 支持 GI

6. A，B，C，D 怎么返回B界面问题10解决
7. 项目最近遇到的难点
8. saveInstance的保存位置，onrestoreinstance的位置

 都存储在Bundle中，系统回收Activity调用了onDestroy()，但调用了onDestroy()并不表示出栈，返回栈中还有Activity的部分信息，返回键和finish()才会导致出栈。系统回收Activity后，返回栈中还有该Activity的部分信息，所以按返回键还可以回到该Activity只是需要重新生成，此时Bundle对象还在。屏幕方向切换属于这种情况

9. Okhttp缓存的位置。如何设置缓存。 interceptor能做什么

 缓存在本地 自定义  参考第一

10. Flag: newtask. cleartop 的使用场景

    因为standard模式的Activity默认会进入启动它的Activity所属的任务栈中，但是由于非Activity类型的context（ApplicationContext）并没有所谓的任务栈，所以就出现问题了。需要指定Activity为FLAG_ACTIVITY_NEW_TASK标记位，这样启动的时候，就会为它创建一个新的任务栈了_

    clear_top : 解决问题6的答案，在D中直接Intent B ,addFlag(“…flag-activity-clear-top”), 为了防止B销毁重新创建，   加上intent.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP);  即可

11. Ibeacon蓝牙是怎么调用的。

   基于Bluetooth Low Energy（BLE）低功耗蓝牙传输技术，iBeacon基站不断向四周发送蓝牙信号，当智能设备进入设定区域时，就能够收到信号。只要满足iBeacon技术标准的都可以使用，所以Android也能够支持iBeacon。

    蓝牙推送信notification
    传输距离增大（超过100米—10厘米内）、安全和稳定性提高
    无需配对. 蓝牙的广播频道
    程序可以后台唤醒

    32位广播数据格式：
    **Major：相当于群组号  **
     **Minor：相当于识别群组里单个的Beacon**
    **TX Power：用于测量设备离Beacon的距离**
蓝牙
    1.BluetoothAdapter
    2.附近信号强度的集合判断
    3.根据32位广播数据格式进行判断，业务逻辑处理Notification信息, 以及界面信息替换。

*12. 广播如何设置权限

receiver清单文件中创建permission
LocalBroadcastManager 来发送只在程序内部传递的广播，从而提升广播的性能

13. Volley为什么对于下载效率低？

Volley的request response 都是把数据放数据放在byte数组里面，不支持输入输出流，把数据放在数组中。如果大文件多了，数组就会非常的大且多，消耗内存，没有像返回stream具备可操作性，不可能把整don个文件缓存到内存中之后再缓存到文件里面，

14. retrofit的中的总结：

Retrofit采用了 外观模式 统一调用创建网络请求接口实例和网络请求参数配置的方法，具体细节是：
    •   动态创建网络请求接口的实例（代理模式 - 动态代理）
    •   创建 serviceMethod 对象（建造者模式 & 单例模式（缓存机制））
    •   对 serviceMethod 对象进行网络请求参数配置：通过解析网络请求接口方法的参数、返回值和注解类型，从Retrofit对象中获取对应的网络请求的url地址、网络请求执行器、网络请求适配器 & 数据转换器。（策略模式）
    •   对 serviceMethod 对象加入线程切换的操作，便于接收数据后通过Handler从子线程切换到主线程从而对返回数据结果进行处理（装饰模式）
    •   最终创建并返回一个OkHttpCall类型的网络请求对象

15. 加载大图BItmapFactory的操作：

BitmapFactory加载图片的方式： decodeFile decodeStream decodeResource

<1> 获取网络图片的尺寸参数：
     inJustDecodeBounds=true. 不加再到内存就可以获得网络图片的宽高。
<2>  决策： 加载原尺寸还是压缩完再加载。
     图片压缩，BitmapFactory.Options 的inSimpleSize=4的值压缩4倍。
     根据传入options、需要的宽高计算合适的inSimpleSize
<3> 之后再解析一次图片，使用新获取到的inSampleSize值，并把inJustDecodeBounds设置为false，就可以得到压缩后的图片了
<4> 使用

内存缓冲技术 LRUcache。 过去使用软引用、弱引用对象。Android2.3开始倾向回收这些。不可靠了。
缓存大小需要你去决定。太大OOM太小频繁释放加载。