Activity 泄漏
Activity 泄漏通常是内存泄漏的一种。为什么会泄漏呢?如果你持有一个未使用的 Activity 的引用,其实也就持有了 Activity 的布局,自然也就包含了所有的 View。最棘手的是持有静态引用。别忘了,Activity 和 Fragment 都有自己的生命周期。一旦我们持有了静态引用,Activity 和 Fragment 就不会被垃圾回收器清理掉了。这就是为什么静态引用很危险。
staticActivity = mFragment.getActivity()
泄漏 Listener 也是经常会发生的事情。比如说,我有下面的代码。
LeakActivity
继承自
Activity
,我们有一个单例:
NastyManager
,当我们通过
addListener(this)
将 Activity 作为 Listener 和 NastyManager 绑定起来的时候,不好的事情就发生了
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
NastyManager.getInstance().addListener(this);
}
修复这样的 Bug,其实相当简单,就是在你的 Acitivity 被销毁的时候,将他和 NastyManager
取消掉绑定
@Override
public void onDestroy() {
super.onDestroy();
NastyManager.getInstance().removeListener(this);
}
Handle使用这样的方式
private static class MyHandler extends Handler {
private final WeakReference<MainActivity> mActivity;
// ...
public MyHandler(MainActivity activity) {
mActivity = new WeakReference<MainActivity>(activity);
//...
}
@Override
public void handleMessage(Message msg) {
}
大 JSON
在 UI 线程不做解析 Json 的事情,用 Google 的 GSON 来做反序列化的操作。
对于巨大的 JSON 解析,建议用更快的 Jackson 以及 ig-json-parser,这两个工具在 JSON 的解析上做的非常漂亮。从公司的反馈结果来看 ig-json-parser 的效率是最高的。
Looper.myLooper() == Looper.getMainLooper()
是可以帮助你确定你是否在主线程的代码。
如何优化滑动速度? (16:56)
- UI 线程只做 UI 更新。
- 理解并发 API。
- 开始使用优秀的第三方库。
- 使用 Loader 加载数据库数据
之所以要用第三方库,是因为你自己去完善一个复杂功能是需要花时间的。如果你打算专注在自己的功能性的 App 上,那么用库吧。
并发 APIs
如何让 App 快速响应请求是个很重要。开发者们,甚至包括我,经常忘记 Service 的方法是在 UI 线程执行的。请考虑使用 IntentService
,AsyncTask
,Executors
,Handler
和 Loopers
。
我们来盘点下这些的区别:
IntentService
我在之前的公司,我用 IntentService 来执行上传功能。IntentService 是一个单线程,一次一个任务的工作流。我们没有很复杂的任务系统。如果你有大型复杂的任务,而且这个任务不需要跟 UI 打交道,那么考虑用 IntentService 吧。
AsyncTask
如果你的任务需要更新 UI,那么考虑用 AsyncTask 吧,AsyncTask 虽然相对容易,但是有些坑得留意。当你旋转手机的时候,Activity 会被关闭,然后重启。不然可能造成内存泄露。
Executor Framework
这是 Java 6 自带的并发方案。默认是存在一个由系统管理的线程池,你可以通过 callback,future 来控制和管理。这根 MapRedues 发难有点像,面对复杂的任务,你希望能够把他们拆分交给多个线程来处理。Executor 的框架就很能胜任这种场景。