目录

31，如何切换 fragement,不重新实例化？
32，Context泄漏；
33，SurfaceView和View的区别是什么?
34，ListView卡顿的原因与性能优化；
35，Android严苛模式StrictMode使用详解；
36，activity视图层结构；
37，Activity的启动模式；

31，如何切换 fragement,不重新实例化？

正确的切换方式是add()，切换时hide()，add()另一个Fragment；再次切换时，只需hide()当前，show()另一个。

【转发】
多个Fragment切换不重新实例化

32，Context泄漏：

使用Context的时候，小心内存泄露，防止内存泄露，注意一下几个方面：

• 不要让生命周期长的对象引用activity context，即保证引用activity的对象要与activity本身生命周期是一样的。

• 对于生命周期长的对象，可以使用application，context。

• 避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化。

33，SurfaceView和View的区别是什么?

• SurfaceView中采用了双缓存技术，在单独的线程中更新界面；

• View在UI线程中更新界面；

34，ListView卡顿的原因与性能优化：

卡顿的原因

• Adapter的getView方法里面convertView没有使用setTag和getTag方式；

• 在getView方法里面ViewHolder初始化后的赋值或者是多个控件的显示状态和背景的显示没有优化好，抑或是里面含有复杂的计算和耗时操作；

• 在getView方法里面 inflate的row 嵌套太深（布局过于复杂）或者是布局里面有大图片或者背景所致；

• Adapter多余或者不合理的notifySetDataChanged；

• listview 被多层嵌套，多次的onMessure导致卡顿，如果多层嵌套无法避免，建议把listview的高和宽设置为fill_parent. 如果是代码继承的listview，那么也请你别忘记为你的继承类添加上LayoutPrams，注意高和宽都是fill_parent的;

【转发】
ListView卡顿原因分析

性能优化

• 在adapter中的getView方法中尽量少使用逻辑；

• 尽最大可能避免GC；

• 滑动的时候不加载图片；

• 将ListView的scrollingCache和animateCache设置为false；

• item的布局层级越烧越好；

• 使用ViewHolder；

【转发】
提高ListView性能的技巧

优化措施

• 重用converView： 通过复用converview来减少不必要的view的创建，另外Infalte操作会把xml文件实例化成相应的View实例，属于IO操作，是耗时操作。

• 减少findViewById()操作： 将xml文件中的元素封装成viewholder静态类，通过converview的setTag和getTag方法将view与相应的holder对象绑定在一起，避免不必要的findviewbyid操作

• 避免在 getView 方法中做耗时的操作: 例如加载本地 Image 需要载入内存以及解析 Bitmap ，都是比较耗时的操作，如果用户快速滑动listview，会因为getview逻辑过于复杂耗时而造成滑动卡顿现象。用户滑动时候不要加载图片，待滑动完成再加载，可以使用这个第三方库glide

• Item的布局层次结构尽量简单，避免布局太深或者不必要的重绘

• 尽量能保证 Adapter 的 hasStableIds() 返回 true 这样在 notifyDataSetChanged() 的时候，如果item内容并没有变化，ListView 将不会重新绘制这个 View，达到优化的目的

• 在一些场景中，ScollView内会包含多个ListView，可以把listview的高度写死固定下来。 由于ScollView在快速滑动过程中需要大量计算每一个listview的高度，阻塞了UI线程导致卡顿现象出现，如果我们每一个item的高度都是均匀的，可以通过计算把listview的高度确定下来，避免卡顿现象出现

• 使用 RecycleView 代替listview： 每个item内容的变动，listview都需要去调用notifyDataSetChanged来更新全部的item，太浪费性能了。RecycleView可以实现当个item的局部刷新，并且引入了增加和删除的动态效果，在性能上和定制上都有很大的改善

• ListView 中元素避免半透明： 半透明绘制需要大量乘法计算，在滑动时不停重绘会造成大量的计算，在比较差的机子上会比较卡。 在设计上能不半透明就不不半透明。实在要弄就把在滑动的时候把半透明设置成不透明，滑动完再重新设置成半透明。

• 尽量开启硬件加速： 硬件加速提升巨大，避免使用一些不支持的函数导致含泪关闭某个地方的硬件加速。当然这一条不只是对 ListView。

35，Android严苛模式StrictMode使用详解：

严苛模式主要检测两大问题，一个是线程策略，即TreadPolicy，另一个是VM策略，即VmPolicy。

ThreadPolicy线程策略检测

• 线程策略检测的内容有
• 自定义的耗时调用 使用detectCustomSlowCalls()开启
• 磁盘读取操作 使用detectDiskReads()开启
• 磁盘写入操作 使用detectDiskWrites()开启
• 网络操作 使用detectNetwork()开启

VmPolicy虚拟机策略检测

• Activity泄露 使用detectActivityLeaks()开启
• 未关闭的Closable对象泄露 使用detectLeakedClosableObjects()开启
• 泄露的Sqlite对象 使用detectLeakedSqlLiteObjects()开启
• 检测实例数量 使用setClassInstanceLimit()开启

【转发】
严苛模式StrictMode

36，activity视图层结构：

activity 层级

【转发】
activity视图层结构

37，Activity的启动模式:

Activity的启动模式一种有四种，分别如下：
standard
singleTop
singleTask
singleInstance

• standard：无论栈中有没有该对象的实例，都会被创建；

  
  standard

• singleTop：只要被创建的Activity不位于栈的顶部，该活动就会被创建入栈。如果将要被创建的Activity位于栈的顶部，该活动的实例就不会被创建；

  
  singeTop

• singleTask：如果从MainActivty跳转到SecondActivity, 如果再从SecondActivty跳转到MainActivity, 在单任务模式下MainActivity已经在栈中，就会把它之前的Activity出栈，使其处于在栈顶活跃的位置；

  
  singleTask

• singleInstance：被设置成singleInstance的Activity将会放入另一个栈中，因为这样为了便于共用；

  
  singleInstance