1、自定义 Handler 时如何有效地避免内存泄漏问题？
- 自定义的静态handler
- 可以加一个弱引用
- 还有一个主意的就是当你activity被销毁的时候如果还有消息没有发出去 就remove掉吧
- removecallbacksandmessages去清除Message和Runnable 加null 写在生命周的ondestroy()就行
2、哪些情况下会导致oom问题？
- 例如handler 在界面销毁的时候消息还未发送
- file没有关流
- 查询到结果还没有停止
- 内部类持有外部类引用得不到释放
- 不用的对象最好null 让GC回收一下
- 图片资源什么的最好加一个软引用
3、一般什么情况下会导致内存泄漏问题？
- 资源对象没关闭造成的内存泄漏（如 ： Cursor、File 等）
- ListView 的 Adapter 中没有使用缓存的ConvertView
- Bitmap对象不在使用时调用recycle()释放内存
- 集合中对象没清理造成的内存泄漏（特别是 static 修饰的集合）
- 接收器、监听器注册没取消造成的内存泄漏
- Activity 的 Context 造成的泄漏，可以使用ApplicationContext
- Handler 造成的内存泄漏问题（一般由于 Handler 生命周期比其外部类的生命周期长引起的）
4、ANR 出现的场景以及解决方案？
在Android中，应用的响应性被活动管理器（Activity Manager）和窗口管理器（Window Manager）这两个系统服
务所监视。当用户触发了输入事件（如键盘输入，点 击按钮等）,如果应用5秒内没有响应用户的输入事件，那么，
Android会认为该应用无响应，便弹出ANR对话框。而弹出ANR异常，也主要是为了提升用户体验。解决方案是对于耗时的操作，比如访问网络、访问数据库等操作，需要开辟子线程，在子线程处理耗时的操作，主线程主要实现UI的操作
5、谈谈Android中内存优化的方式？
关于内存泄漏，一般像单例模式的使用不当啊、集合的操作不当啊、资源的缺乏有效的回收机制啊、Handler、线程 的使
用不当等等都有可能引发内存泄漏。
- 单例模式引发的内存泄漏：
原因：单例模式里的静态实例持有对象的引用，导致对象无法被回收，常见为持有Activity的引用
优化：改为持有Application的引用，或者不持有使用的时候传递。
- 集合操作不当引发的内存泄漏：
原因：集合只增不减
优化：有对应的删除或卸载操作
- 线程的操作不当引发的内存泄漏：
原因：线程持有对象的引用在后台执行，与对象的生命周期不一致
优化：静态实例+弱引用(WeakReference)方式，使其生命周期一致
- 匿名内部类/非静态内部类操作不当引发的内存泄漏：
原因：内部类持有对象引用，导致无法释放，比如各种回调
优化：保持生命周期一致，改为静态实例+对象的弱引 用方式（WeakReference）
- 常用的资源未关闭回收引发的内存泄漏：
原因：BroadcastReceiver，File，Cursor，IO流，Bitmap等资源使用未关闭
优化：使用后有对应的关闭和卸载机制
- Handler使用不当造成的内存泄漏：
原因：Handler持有Activity的引用，其发送的Message 中持有Handler的引用，当队列处理Message的时间过长会导致
Handler无法被回收优化：静态实例+弱引用(WeakReference)方式内存
6、谈谈布局优化的技巧？
- 降低Overdraw（过度绘制），减少不必要的背景绘制
- 减少嵌套层次及控件个数
- 使用Canvas的clipRect和clipPath方法限制View的绘制区域
- 通过imageDrawable方法进行设置避免ImageView的background和imageDrawable重叠
- 借助ViewStub按需延迟加载
- 选择合适的布局类型
- 熟悉API尽量借助系统现有的属性来实现一些UI效果
7、Android 中的图片优化方案？
1.首先我们可以对图片进行二次采样，从本质上减少图片的内存占用。就是将大图片缩小之后放入到内存中，以实现减
小内存的目的2.其次就是采用三层缓存架构，提高图片的访问速度。三层缓存架构是内存-文件-网络。内存是访问速度最快的部分但是分配的空间有限，所以不可能占用太多。其中内存缓存可以采用LRU算法（最近最少使用算法），来确定要删除内存中的那些图片，保存那 些图片。文件就是将图片保存到本地，可以使SD卡中，也可以是手机内部存储中。网络就是访问网络下载图片，进行图片的加载。
3.常见的png，JPG，webp等格式的图片在设置到UI上之前需要经过解码过程，而图片采用不同的码率，也会造成对 内存的占用不同。
4.最后一点，也是图片优化最重要的一点。重用Bitmap.
5.不使用bitmap要记得实时回收，减小内存的开销
8、AndroidNativeCrash问题如何分析定位？
1.利用breakpad,dump Native崩溃时日志信息
2.利用addr2line跟ndk-strace等工具 根据崩溃日志偏移量定位具体源码位置
3.根据信号提示进行具体处理。
此步骤的难点在于1：
Native Crash的时候整个app的状态是极其不稳定的,很可能由于保存日志（或者上报日志）等操作引起其他异常,所以
此时最好fork一个子进程来保存当前进程的日志
9、谈谈你是如何优化App启动过程的？
1.把application oncreate 中要执行的方法 分为同步和异步, 尽量去延迟执行 或者使用空闲线程去初始化一些方法
2.配置一个启动背景,避免白屏或者黑屏,然后做一个空的Activity这个Activity只做一件事,就是跳转到真的Activity,因为 启动速度 和applicationoncreate的耗时和第一个Activity的绘制有关, 上面都是easy的做法
- 利用 redex工具 优化 dex ,因为 class字节码 分布在不同的dex中,所以启动的时候必须逐个查找一些文件,他们 散列分布在不同的dex中,查找起来耗时又不方便,利用redex把相关的class放在同一个dex包下,避免 同一个dex包被多次查找
- 在attachedbaseContext中 新起一个进程 去加载mutildex 可以加速App启动页的打开(可能在启动页中会等待,但是加速了从launcher到启动页的速度)
10、谈谈代码混淆的步骤？
开启混淆
- 查看项目使用的第三方哪些需要设置混淆
- 保持反射native对应的类和方法不混淆
- 保持自定义类不混淆
- 保持实体类参与序列化的不混淆
- 系统组件等一些固定方法会被系统调用的不混淆
11、谈谈App的电量优化？
优化方案总结
(1)GPS ——使用要谨慎，如精确度不高可用WiFi定位或者基站定位，可用；非要用的话，注意定位数据的复用和定位频率的阈值
(2)Process和Service ——按需启动，用完就退出
(3)网络数据交互 ——减少网络网络请求次数和数据量；WiFi比手机网络省电
(4)CPU ——减少I/O操作（包括数据库操作），减少大量的计算
(5)减少手机硬件交互 ——使用频率优化和选择低功耗模式
12、谈谈如何对WebView进行优化？
1.单/多进程化：webView在独立的进程里面，那么WebView的进程崩溃不会影响到主进程运行；同时WebView的安 全漏洞也很难影响到主进程；如果是多进程的话，可以使用WebView的容器池，有二次秒开的作用； 不过缺点就是需要你做好和WebView的跨进程通讯了
2.网络优化：我们可以让WebView的host和客户端的host 保持一致，那么就达到复用DNS缓存的效果；如果客户端有针
对网络请求进行了优化，那么可以让WebView的全部网络请求托管给客户端3.H5离线包：这个是手Q的H5方案之一，让客户端提前去 下载离线的H5数据包，WebView只需要加载本地H5数据包即
可，这么做不仅可以避免一些http的劫持，而且跳过了WebView的建立TCP连接和H5、CCS等数据下载的过程，直
接开始UI渲染，大大提高了WebView的效率
13、谈谈如何对网络请求进行优化？
1.最开始的是DNS，当我们发起一个网络请求，首先要经过DNS服务，将域名转化为IP地址，为避免DNS解析异常问
题，可以直接使用 IP 建立连接；2.使用 Gzip 压缩 Response 减少数据传输量；使用Protocol Buffer 代替 JSON；
3.请求图片的 url 中可以添加 格式、质量、宽高等参数；使用缩略图、使用 WebP格式图片，大图分片传输；
4.使用网络缓存，使用图片加载框架；
5.监听设备网络状态，根据不同网络状态选择对应情况下 的网络请求策略：网络良好和弱网、离线等情况下分别设计不
同的请求策略，比如 WIFI 下一个请求可以获取几十个数据，甚至可以一次性执行多个请求；而弱网下一个请求获取几个
数据，且文本类型优先，富文本其次，除文本数据外其它类型的数据一开始只显示占位符；离线下事先保存请求数据到
磁盘，在离线时从磁盘加载数据。
