内存

避免内存泄漏

内存泄漏的常见情况

不恰当的static引用。

内部类引起的外部类泄漏

内部类AsyncTask、Handler、Runnable持有context对象：

是否可以修改为静态内部类？

在Activity onDestroy的时候，是否可以remove task，remove callback?

是否可以使用Application 的context？

使用WeakReference代替Activity context。

对context的长时间的持有

没有成对出现的注册事件

广播的register, unRegister

call back, listener的add, remove

servcie的bind 与 unBind

JNI层的内存泄漏

未及时清理的资源

流的关闭

cursor的关闭

Bitmap的recyle

查询内存泄漏的工具

MAT

存活的object的数量是否符合期望的。

是否存在不应该存活的对象。

不同时间差对比，是否具有较大数量的差距。

使用OQL(对象查询语言)查询关注的对象个数。

根据引用到的GC root找到未释放的对象。

LeakCanary：比较傻瓜式，略过

图片方面

对大图片进行采样

服务器端提供大图片的缩略图，不同的网络环境取不同清晰度的图片资源。

使用WeakReference 持有图片

使用TingPNG优化图片资源

使用FlyWeight，cache有效复用数据

Message里的MessagePool的复用，String Pool，图片cache。

避免创建、gc的开销。（大多数情况，垃圾回收会使用所有线程暂停）

多份重复的数据，最多只有一份实例。

全局，唯一，长期存在的实例使用单例

使用Fragment，动态添加组件，用到时加载，不用时remove掉相关组件，同一时间，特定区域只有一份fragment。

响应系统的号召 Activity,Service,Application 的onLowMemory清理不必要可恢复的内存。

参考 http://blog.csdn.net/time_hunter/article/details/53107191

使用WeakReference 持有图片、context等资源。

使用恰当的数据结构

耗电

避免过度重绘

避免不断的唤起应用

避免小而频繁的请求

使用alarm代替timer

其他策略

秒表程序：当从秒表界面程序挂起时，不需要一直计算秒表数据，只要在pause时，存储一些数据与状态，onresuse时通过计算，便可以得出数据。

流畅 & UI

特别注意的场景

冷启动减少用户等待：

避免在Actiity的onCreate,onStart, Application的onCreate做过多耗时的事情

左右滑动

当左右滑动过程中，加载数据可能引起卡顿，可以延迟进行加载，如滑动结束的时候。

即时响应：点击按钮，立即执行动作。点击back key立即终结。

避免loading圈卡顿

页面加载：避免布局上的跳跃（下图中箭头的出现引起了布局的变化）

线程优先级

UI线程提高优先级

其他线程(如统计，后台任务相关）酌情降低优先级。

可视者优先加载

Launcher（桌面App）会优先加载Workspace 当前所在的screen的app item，再去加载左右两侧screen的布局。

避免频繁的刷新

下载游戏时，游戏的进度在不断的变化。可能每秒中引起10来次刷新，可以通过收集这些刷新事件，比如0-0.8秒内的所有刷新统一放在0.8秒时进行一次刷新。

使用部分刷新

游戏状态的更新，可以只刷新变化的区域，也就是第二个游戏的进度条部分。

不需刷新整个卡片View。

不需刷新第二个游戏进度条之外的任何区域，包括游戏的icon，因为这些区域没有变化。

更不需刷新上下卡片的任何区域。

拆分大的ListView item为可复用的小item。

大个的item具有更大的创建负荷（上下滑动时，可能会有一顿一顿的卡顿，时快时慢）。

大个的item可能需要消耗更多的资源( 大的item如果只露出一小部分，那么其他未显示出来的item，也会发生数据方面的请求。)

更小的复用组件，意味更多的复用机会。

列表item加载一些icon logo时，滑动时不进行加载。

通过MessageQueue.IdleHandler监听主线程空闲时，加载图片相关。

避免过度重绘

宽而广的布局优于窄而深的布局结构

使用ViewStub动态加载布局

实现原理参考 http://blog.csdn.net/time_hunter/article/details/53585818

inclue标签，merge标签

工具:

BlockCanary

可以设定参数检测主线程中事件的处理耗时情况。

参考 http://blog.zhaiyifan.cn/2016/01/16/BlockCanaryTransparentPerformanceMonitor/?utm_source=tuicool&utm_medium=referral

参考 http://blog.csdn.net/time_hunter/article/details/53164641

StrictMode

TraceView

代码

代码重构

参考 http://blog.csdn.net/time_hunter/article/details/53144070

包大小

图片资源大小

使用TinyPng工具，可在不影响视觉效果的情况下，缩减图片尺寸。

官网 https://tinypng.com/

参考 http://blog.csdn.net/fuchaosz/article/details/51829662

酌情使用.9图

使用WebP格式图片

官网：https://developers.google.com/speed/webp/

转化工具：腾讯智图 http://zhitu.isux.us/

更多参考: http://dev.qq.com/topic/582939577ef9c5b708556b0d

清理无用的资源

Android Lint 搜索无用的资源。

模块插件化

代码重构 : 通过封装、继承、泛型、模版方法、反射封装代码

网络请求方面

对于体积大的数据，使用GZip压缩。

判断header的Expires字段来存储响应数据，避免重新加载数据

(下拉刷新，使用此字段判断服务器是否需要发出新请求)。

对于特定时间取的数据，使用参数随机数，避免同一时间客户端发出的大量请求。

（如：每天7点获取天气信息，可以在前后20分钟内提前获取，避免都集中到7点时突然发生大规模的请求）

Android(安卓)app 优化

内存

避免内存泄漏

内存泄漏的常见情况

查询内存泄漏的工具

图片方面

使用FlyWeight，cache有效复用数据

全局，唯一，长期存在的实例使用单例

使用Fragment，动态添加组件，用到时加载，不用时remove掉相关组件，同一时间，特定区域只有一份fragment。

响应系统的号召 Activity,Service,Application 的onLowMemory清理不必要可恢复的内存。

使用WeakReference 持有图片、context等资源。

使用恰当的数据结构

耗电

避免过度重绘

避免不断的唤起应用

避免小而频繁的请求

使用alarm代替timer

其他策略

流畅 & UI

特别注意的场景

冷启动减少用户等待：

左右滑动

即时响应：点击按钮，立即执行动作。点击back key立即终结。

避免loading圈卡顿

页面加载：避免布局上的跳跃（下图中箭头的出现引起了布局的变化）

线程优先级

可视者优先加载

避免频繁的刷新

使用部分刷新

游戏状态的更新，可以只刷新变化的区域，也就是 第二个游戏的进度条部分。

拆分大的ListView item为可复用的小item。

列表item加载一些icon logo时，滑动时不进行加载。

通过MessageQueue.IdleHandler监听主线程空闲时，加载图片相关。

避免过度重绘

宽而广的布局优于窄而深的布局结构

使用ViewStub动态加载布局

inclue标签，merge标签

工具:

BlockCanary

StrictMode

TraceView

代码

代码重构

包大小

图片资源大小

使用WebP格式图片

清理无用的资源

模块插件化

代码重构 : 通过封装、继承、泛型、模版方法、反射封装代码

网络请求方面

对于体积大的数据，使用GZip压缩。

判断header的Expires字段来存储响应数据，避免重新加载数据

对于特定时间取的数据，使用参数随机数，避免同一时间客户端发出的大量请求。

更多相关文章

随机推荐

游戏状态的更新，可以只刷新变化的区域，也就是第二个游戏的进度条部分。