Android面试题笔记（二）

Handler面试笔记

1. 什么是Handler
   Handler通过发送和处理Message和Runnable对象来关联相应线程的MessageQueue
   1. 可以让对应的Message和Runnable在未来的某个时间点进行相应处理
   2. 让自己想要处理的耗时操作放在子线程，让更新UI的操作放在主线程
2. Handler的使用方法
   1. post(runnable)
   2. sendMessage(message)
      
      
3. Handler引起的内存泄露以及解决办法
   原因：静态内部类持有外部类的匿名引用，导致外部Activity无法释放

解决办法：Handler内部持有外部Activity的弱引用，并把Handler改为静态内部类，mHandler.removeCallback()

AsyncTask

• 什么是AsyncTask
  它本质上就是一个封装了线程池和Handler的异步框架
• AsyncTask的使用方法
  三个参数、五个方法

OKhttp

ANR

• 什么是ANR
  Application Not Responding
• 造成ANR的主要原因
  • 主线程被IO操作阻塞
  • 主线程存在耗时的计算
• Android中哪些操作是在主线程呢？
  • Activity的所有生命周期回调都是执行在主线程的
  • Service默认是执行在主线程
  • BroadcastReceiver的onReceive回调是执行在主线程的
  • 没有使用子线程的Looper的Handler的handleMessage，post(runnable)是执行在主线程的
  • AsyncTask的回调中除了doInBackground，其他都是执行在主线程
• 如何解决ANR
  * 使用AsyncTask处理耗时IO操作
  * 使用Thread或者HandlerThread提高优先级
  * 使用handler来处理工作线程的耗时任务
  * Activity的onCreate和onResume回调中尽量避免耗时的代码

OOM

• 什么是oom？
  • 当前占用的内存加上我们申请的内存资源超过了Dalvik虚拟机的最大内存限制就会抛出的out of memory异常
• 内存溢出、内存抖动、内存泄露
• 避免在onDraw方法里执行对象的创建
• 谨慎使用多进程

bitmap

• recycle
• LRU
• 计算inSampleSize
• 缩略图
• 三级缓存

UI卡顿

• 60fps->16ms
• overdraw
• UI卡顿原因分析
  • 人为在UI线程中做轻微耗时操作，导致UI线程卡顿
  • 布局Layout过于复杂，无法在16ms内完成渲染
  • 同一时间动画执行的次数过多，导致CPU或GPU负载过重
  • View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重
  • View频繁的出发measure Layout ，导致measure Layout累计耗时过多及整个View频繁的重新渲染
  • 内存频繁出发GC，导致暂时阻塞渲染操作
  • 冗余资源以及逻辑等导致加载和执行缓慢
  • ANR
• UI卡顿总结
  • 布局优化
  • 列表及Adapter优化
  • 背景和图片等内存分配优化
  • 避免ANR

内存泄露

1. Java内存的分配策略
   • 静态存储区
   • 栈区
   • 堆区
2. Java中的内存泄露
   • 内存泄露是指无用对象（不再使用的对象）持续占用内存或无用对象的内存得不到及时释放，从而造成的内存空间浪费称为内存泄露
3. Android内存泄露
   • 单例
   • 匿名内部类
   • handler
   • 避免使用static变量
   • 资源未关闭造成的内存泄露
   • AsyncTask造成的内存泄露

内存管理

 * 内存优化方法
    * 当Service完成任务后，尽量停止它
    * 在Ui不可见的时候，释放掉一些只有UI使用的资源
    * 在系统内存紧张的时候，尽可能多的释放掉一些非重要资源
    * 避免滥用Bitmap导致的内存浪费
    * 使用针对内存优化过的数据容器
    * 避免使用依赖注入的框架
    * 使用zip对齐的APK
    * 使用多进程

冷启动优化

• 冷启动是什么
  冷启动就是启动进程前，系统中没有该应用的任何进程信息
  热启动：用户使用返回键退出应用，然后马上又重新启动应用
• 冷启动时间的计算
  这个时间值从应用启动（创建进程）开始计算，到完成视图的第一次绘制（即Activity内容对用户可见）为止。
• 冷启动流程
  Zygote进程中fork创建出一个新的进程
  创建和初始化Application类、创建MainActivity类
  inflate布局、当onCreate、onStart、onResume方法都走完
  contentView的measure、Layout、draw显示在界面上
• 冷启动流程总结
  Application的构造器方法–》attachBaseContext（）–》onCreate（）–》Activity的构造方法–》onCreate（）–》配置主题中背景等属性–》onStart（）–》onResume（）–》测量布局绘制显示在界面上
• 如何对冷启动时间进行优化
  1. 减少onCreate（）方法的工作量
  2. 不要让Application参与业务的操作
  3. 不要在Application进行耗时操作
  4. 不要以静态变量的方式在Application中保存数据
  5. 布局、mainThread

其他优化

1. Android中不用静态变量存储数据
   1. 静态变量等数据由于进程已经被杀死而被初始化
   2. 使用其他数据传输方式：文件、sp、contentProvider
2. sharePreference问题
   1. 不能跨进程同步
   2. 存储sharepreference的文件过大问题
3. 内存对象序列化
   序列化：将对象的状态信息转换为可以存储或传输的形式的过程
   1. Serializeable是Java的序列化方式，Parcelable是Android特有的序列化方式
   2. 在使用内存的时候，Parcelable比Serializeable性能高
   3. Serializeable在序列化的时候会产生大量的临时变量，从而引起频繁的GC
   4. Parcelable不能使用在要将数据存储在磁盘上的情况

MVC、MVP、MVVM

1. MVC

   • M: 业务逻辑处理
   • V：处理数据的显示部分
   • C：Activity处理用户交互问题

2. MVC特点

   • 耦合性低
   • 可扩展性好
   • 模块职责划分明确

3. MVC总结

   1. 利用MVC设计模式，使得项目有了很好的可扩展和维护性
   2. Controller（控制器）是一个中间桥梁的作用
   3. 什么时候适合使用MVC设计模式？-----项目比较大的时候

4. MVP定义

   1. M:依然是业务逻辑和实体模型
   2. V：对应于Activity，负责View的绘制以及与用户交互
   3. P：负责完成View与Modle间的交互
      对比
      

• MVVM
  因为我看的资料是四年前的，那时候Android开发领域MVVM还不流行所以一笔带过，关于MVVM的内容我会在其他文章中详细整理
  

2. View：对应于Activity和XML，负责View的绘制以及与用户交互
3. Model：实体模型
4. ViewModel：负责完成View与Model间的交互，负责业务逻辑

Android插件化

• 插件化来由
• 插件化要解决的问题
  1. 动态加载APK
  2. 资源加载
  3. 代码加载

Android热更新

• 热更新流程
  1. 线上检测到严重的crash
  2. 拉出bugfix分支并在分支上修复问题
  3. jenkins构建和补丁生成
  4. app通过推送或主动拉取补丁文件
  5. 将bugfix代码合到master上
• 主流热更新框架
  • Dexposed
  • AndFix
  • Nuwa
• Android类加载机制
  • DexClassloader
  • PathClassloader
• 热修复机制：
  1. dexElements
  2. ClassLoader会遍历这个数组

进程保活

• Android进程的优先级
  Foreground process 》Visible process 》Service process 》background process 》Empty process
• Android进程的回收策略
  1. Low memory killer：通过一些比较复杂的评分机制，对进程进行打分，然后将分数高的进程判定为bad进程，杀死并释放内存
  2. OOM_ODJ:判别进程的优先级
  • 进程保活
    因为我看的资料是4年前的 有些进程保活方法已经落后了 后面我会在其他文章中专门整理进程保活方案。