1,布局优化:
(1)减少层级
(2)尽量使用LinearLayout代替RelativeLayout。LinearLayout和FrameLayout效率高于RelativeLayout,但是,当涉及嵌套时,嵌套是最慢的,此时建议使用RelativeLayout。
(3)建议使用<include>
<include android:id="+id/new_title"
android:layout_width="match_parent"
android:layout_height="match_parent"
layout="@layout/title" />
<include>的布局中可以使用<merge>标签代替<LinearLayout>来减少嵌套,提高效率。
(4)根据需要加载的布局建议使用<ViewStub>
<ViewStub android:layout_width="match_parent" android:layout_height="wrap_content" android:id="@+id/stub_view" android:inflatedId="@+id/panel_import" android:layout="@layout/include_layout"/>
总结:
* RelativeLayout的子view调两次onMeasure,LinearLayout有weight时的子view调两次onMeasure
* RelativeLayout和子view的高度不同时,会有效率问题,尽量用padding代替margin
* 尽量用LinearLayout和FrameLayout代替RelativeLayout
* 使用组合控件好于两个独立控件,例如,文本旁边有图片,用DrawableLeft好于TextView和ImageView(HierarchyViewer查看绘制时间)
* 未必100%出现的界面用ViewStub进行懒加载,优于加载后gone掉
* GPU过渡绘制测试--设置--开发者选项--调试GPU过渡绘制
* 内存,cpu,gpu测试Android Studio--Android Monitor--Monitors
* Android Studio -- Analyze -- Inspect Code -- /Code cleanup
* 内存泄露检测--LeakCanary, GT
2,内存泄露
(1)静态变量导致
private static Context sCtx;
@Override
protected void onCreate(Bundle saveInstanceState) {
....
sCtx = this;
}
导致Activity无法正常销毁。
(2)单例模式引起
--1-- 例如:注册监听没有解注册,Activity无法释放
--2-- 单例模式如果需要传入上下文对象Context,那么应该传入Application的Context,
如果传入Activity的Context,单例存在则Activity不能被回收,会有内存泄露隐患。
解决方法可以将new Singleton(context)改为new Singleton(context.getApplicationContext())即可,这样便和传入的Activity没关系了。
--3-- // 将Handler改成静态内部类,LeakAty是extends Activity的外部类
handler = new MyHandler(this);
fetchDate();
private static class MyHandler extends Handler {
// 需要引用的activity的地方改成弱引用
private WeakReference<LeakAty> atyInstance;
public MyHandler(LeakAty aty) {
this.atyInstance = new WeakReference<LeakAty>(aty);
}
@override
public void handleMessage(Message msg) {
super.handleMessage(msg);
LeakAty aty = atyInstance == null? null: atyInstance.get();
// activity释放了,则不处理消息
if (aty == null || aty.isFinishing()) {
return;
}
aty.tvResult.setText("fetch data success");
}
}
private void fetchDate() {
handler.sendEmptyMessage(0);
}
// activity 退出时,移除回调
@override
protected void onDestroy() {
super.onDestroy();
handler.removeCallbacksAndMessages(null);
}
(3)属性动画
ObjectAnimator animator ;
应该在onDestroy() {
animator.cancel();
}
(4)内部类
private static Leak mLeak;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_second);
mLeak = new Leak();
}
class Leak {
}
mLeak是存储在静态区的静态变量,而Leak是内部类,其持有外部类Activity的引用。这样就导致Activity需要被销毁时,由于被mLeak所持有,所以系统不会对其进行GC,这样就造成了内存泄漏。
总结:
1.static变量引起的内存泄漏
因为static变量的生命周期是在类加载时开始 类卸载时结束,也就是说static变量是在程序进程死亡时才释放,如果在static变量中 引用了Activity 那么 这个Activity由于被引用,便会随static变量的生命周期一样,一直无法被释放,造成内存泄漏。
解决办法:
在Activity被静态变量引用时,使用 getApplicationContext 因为Application生命周期从程序开始到结束,和static变量的一样。
2.线程造成的内存泄漏
类似于上述例子中的情况,线程执行时间很长,及时Activity跳出还会执行,因为线程或者Runnable是Acticvity内部类,因此握有Activity的实例(因为创建内部类必须依靠外部类),因此造成Activity无法释放。
AsyncTask 有线程池,问题更严重
解决办法:
1.合理安排线程执行的时间,控制线程在Activity结束前结束。
2.将内部类改为静态内部类,并使用弱引用WeakReference来保存Activity实例 因为弱引用 只要GC发现了 就会回收它 ,因此可尽快回收
3.BitMap占用过多内存
bitmap的解析需要占用内存,但是内存只提供8M的空间给BitMap,如果图片过多,并且没有及时 recycle bitmap 那么就会造成内存溢出。
解决办法:
及时recycle 压缩图片之后加载图片
4.资源未被及时关闭造成的内存泄漏
比如一些Cursor 没有及时close 会保存有Activity的引用,导致内存泄漏
解决办法:
在onDestory方法中及时 close即可
5.Handler的使用造成的内存泄漏
由于在Handler的使用中,handler会发送message对象到 MessageQueue中 然后 Looper会轮询MessageQueue 然后取出Message执行,但是如果一个Message长时间没被取出执行,那么由于 Message中有 Handler的引用,而 Handler 一般来说也是内部类对象,Message引用 Handler ,Handler引用 Activity 这样 使得 Activity无法回收。
解决办法:
依旧使用 静态内部类+弱引用的方式 可解决
6.带参数的单例
如果我们在在调用Singleton的getInstance()方法时传入了Activity。那么当instance没有释放时,这个Activity会一直存在。因此造成内存泄露。
解决方法:
可以将new Singleton(context)改为new Singleton(context.getApplicationContext())即可,这样便和传入的Activity没关系了。
3,ANR
Activity 在5秒内没有完成无法响应会ANR,BoardcastReceiver在10秒内未完成也会ANR。
adb pull /data/anr/traces.txt .
分析traces文件。
4,ListView和Bitmap待续
5,线程池待续
其他:
(1)避免大量创建对象,(2)尽量少用枚举,(3)常量使用static final修饰,
(4)尽量用Android特有的数据结构,SparseArray和Pair,(5)适当使用软引用和弱引用,
(6)采用内存缓存和磁盘缓存,(7)采用静态内部类