正文

从App闪退到优雅退出 3个真实Android崩溃案例详解Activity生命周期与内存泄漏修复实战代码

/0 浏览量
0904

说到Android开发，最让人头疼的莫过于那个熟悉的白色错误弹窗，或者更糟糕的——应用毫无征兆地直接退出了，用户甚至不知道发生了什么。今天咱们不聊那些枯燥的官方文档，而是直接扒开三个真实发生在我（和一个资深Android团队）项目中的“血案”。这些案例不仅关于代码，更关于理解Android底层是如何管理我们的App的。准备好了吗？我们要深入Activity的生命周期和内存管理的“坑”里看看。

案例一：旋转屏幕后的“僵尸”——NullPointerException的优雅陷阱

让我先给你讲个故事。想象一下，你的App里有一个展示用户资料的Activity，上面有个 TextView 用来显示用户名。你觉得这很简单对吧？于是你写了这样的代码：

public class ProfileActivity extends AppCompatActivity {
    private TextView tvUserName;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_profile);
        
        // 假设这里从网络获取数据并设置
        new Thread(() -> {
            String name = fetchNameFromServer(); // 模拟网络请求
            tvUserName.setText(name); // 危险！如果此时Activity被销毁呢？
        }).start();
    }
}

看起来挺正常的，对吧？但是，当用户旋转屏幕时，悲剧就发生了。Android为了适配新的屏幕方向，会销毁当前的Activity并重新创建一个新的。这意味着 onDestroy() 被调用，然后 onCreate() 再次执行。问题在于，我们那个后台线程并不知道这些。当网络请求回来，试图更新已经销毁的Activity的UI时，tvUserName 可能已经是空的了，或者更糟，对已销毁的Activity执行UI操作会抛出异常。

为什么这不仅是崩溃，更是内存泄漏？

这里的核心问题在于，我们的匿名内部类线程（new Thread(...)）隐式地持有外部类 ProfileActivity 的引用。只要这个线程还在运行，整个Activity实例就无法被垃圾回收（GC）。在旋转屏幕的场景下，旧的Activity实例本应被销毁，但由于线程还在引用它，它就成了一个“僵尸”——既不能被GC回收，又无法正常工作。

修复方案：使用弱引用或Lifecycle感知组件

最简洁的修复方式是使用 WeakReference 来避免强引用导致的内存泄漏，并结合Android的 Lifecycle 组件来确保UI操作的安全性：

public class ProfileActivity extends AppCompatActivity {
    private TextView tvUserName;
    private WeakReference<TextView> weakTvUserName; // 使用弱引用

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_profile);
        
        tvUserName = findViewById(R.id.tv_user_name);
        weakTvUserName = new WeakReference<>(tvUserName);

        // 使用LifecycleOwner来观察生命周期状态
        getLifecycle().addObserver(new LifecycleEventObserver() {
            @Override
            public void onStateChanged(@NonNull LifecycleOwner source, @NonNull LifecycleEvent event) {
                if (event == LifecycleEvent.ON_DESTROY) {
                    // Activity销毁时，取消网络请求或标记不再更新UI
                    cancelNetworkRequest(); 
                }
            }
        });

        new Thread(() -> {
            String name = fetchNameFromServer();
            // 检查Activity是否仍然有效，以及TextView是否还存在
            if (getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.STARTED) && weakTvUserName.get() != null) {
                tvUserName.post(() -> tvUserName.setText(name)); // 在UI线程更新
            }
        }).start();
    }
}

这里的关键点：

  1. 弱引用：WeakReference 允许Activity在被GC时能够被回收，即使后台线程还持有引用。
  2. Lifecycle感知：通过观察 Lifecycle 状态，我们可以在Activity进入 DESTROY 状态时取消不必要的操作，避免对已销毁的Activity进行操作。
  3. 主线程检查：tvUserName.post() 确保UI更新在主线程执行，并再次检查状态。

这个案例告诉我们，任何持有Activity引用的后台任务都需要格外小心，尤其是在屏幕旋转、配置更改等会导致Activity重建的场景。

案例二：ListView/RecyclerView的“幽灵” Adapter——内存泄漏与OOM的隐形杀手

第二个案例来自一个电商App，商品列表页面。开发者为了优化性能，使用了一个静态的 ViewHolder 池或者在Adapter中缓存了一些图片引用。随着用户浏览商品数量的增加，App逐渐变得卡顿，最终因为内存不足（OOM - OutOfMemory）而崩溃。

问题出在哪里？让我们看一个典型的错误实现：

public class ProductAdapter extends RecyclerView.Adapter<ProductAdapter.ViewHolder> {
    // 假设这是一个静态集合，用于缓存View或Bitmap
    private static final Map<String, Bitmap> bitmapCache = new HashMap<>();

    @Override
    public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
        View view = LayoutInflater.from(parent.getContext()).inflate(R.layout.item_product, parent, false);
        return new ViewHolder(view);
    }

    @Override
    public void onBindViewHolder(ViewHolder holder, int position) {
        Product product = products.get(position);
        
        // 从网络加载图片并缓存
        String imageUrl = product.getImageUrl();
        if (!bitmapCache.containsKey(imageUrl)) {
            // 异步加载图片...
            loadImageAsync(imageUrl, new Callback() {
                @Override
                public void onSuccess(Bitmap bitmap) {
                    bitmapCache.put(imageUrl, bitmap);
                    holder.imageView.setImageBitmap(bitmap);
                }
            });
        } else {
            holder.imageView.setImageBitmap(bitmapCache.get(imageUrl));
        }
    }

    static class ViewHolder extends RecyclerView.ViewHolder {
        ImageView imageView;
        ViewHolder(View itemView) {
            super(itemView);
            imageView = itemView.findViewById(R.id.iv_product);
        }
    }
}

这个代码看起来没问题，对吧？但问题在于 bitmapCache 是一个静态的 HashMap，它会无限增长。每次用户浏览新的商品，图片就会被缓存进去，但永远不会被清理。这直接导致了内存泄漏，最终引发OOM。

更隐蔽的问题：Context泄漏

另一个常见但容易被忽视的问题是Context泄漏。如果在Adapter中保存了Activity或ApplicationContext的引用，并且这个引用被长期持有（比如作为单例或静态字段），那么整个Activity将无法被回收。

// 错误示例：在Adapter中持有Activity的强引用
public class ProductAdapter extends RecyclerView.Adapter<ProductAdapter.ViewHolder> {
    private Activity context; // 强引用，导致Activity泄漏
    private List<Product> products;

    public ProductAdapter(Activity context, List<Product> products) {
        this.context = context; // 危险！
        this.products = products;
    }
    
    // ... 其他代码
}

修复方案：使用WeakReference和适当的缓存策略

正确的做法是使用 WeakReference 来持有Context，并使用 LruCache 来管理图片缓存，确保缓存大小可控：

public class ProductAdapter extends RecyclerView.Adapter<ProductAdapter.ViewHolder> {
    private WeakReference<Context> contextRef;
    private List<Product> products;
    private LruCache<String, Bitmap> bitmapCache;

    public ProductAdapter(Context context, List<Product> products) {
        this.contextRef = new WeakReference<>(context);
        this.products = products;
        
        // 初始化LruCache，大小设为最大可用内存的1/8
        final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
        final int cacheSize = maxMemory / 8;
        this.bitmapCache = new LruCache<String, Bitmap>(cacheSize) {
            @Override
            protected int sizeOf(String key, Bitmap bitmap) {
                return bitmap.getByteCount() / 1024; // 单位为KB
            }
        };
    }

    @Override
    public void onBindViewHolder(ViewHolder holder, int position) {
        Product product = products.get(position);
        String imageUrl = product.getImageUrl();
        
        Bitmap cachedBitmap = bitmapCache.get(imageUrl);
        if (cachedBitmap != null) {
            holder.imageView.setImageBitmap(cachedBitmap);
        } else {
            loadImageAsync(imageUrl, new Callback() {
                @Override
                public void onSuccess(Bitmap bitmap) {
                    bitmapCache.put(imageUrl, bitmap);
                    holder.imageView.setImageBitmap(bitmap);
                }
            });
        }
    }
    
    // ... 其他方法
}

关键点：

  1. WeakReference for Context：使用 WeakReference<Context> 避免持有Activity的强引用，防止Activity泄漏。
  2. LruCache for Bitmaps：使用 LruCache 管理图片缓存，自动淘汰最近最少使用的图片，控制内存占用。
  3. Context检查：在需要Context时，检查 contextRef.get() 是否不为空。

案例三：Handler的“时间旅行”——延迟任务导致的内存泄漏

最后一个案例，也是最经典的一个。一个社交App的消息页面，有一个定时刷新未读消息数量的功能。开发者使用 Handler.postDelayed() 来实现这个定时任务：

public class MessageActivity extends AppCompatActivity {
    private Handler handler = new Handler();
    private Runnable refreshRunnable = new Runnable() {
        @Override
        public void run() {
            refreshUnreadCount();
            handler.postDelayed(this, 5000); // 每5秒刷新一次
        }
    };

    @Override
    protected void onStart() {
        super.onStart();
        handler.post(refreshRunnable); // 开始定时刷新
    }

    @Override
    protected void onStop() {
        super.onStop();
        // 忘记移除回调了！
    }
}

这里有两个严重问题：

  1. 没有移除回调：在 onStop() 中没有调用 handler.removeCallbacks(refreshRunnable)，导致定时任务持续运行。
  2. Handler持有Activity引用：匿名内部类 refreshRunnable 隐式持有外部类 MessageActivity 的引用。即使Activity已经不可见，只要Handler还有未执行的Message，Activity就无法被回收。

更糟糕的是，如果用户不断进入和退出这个页面，Handler会累积大量的回调，造成严重的内存泄漏。

Handler机制背后的陷阱

理解Handler的工作原理至关重要。Handler通过MessageQueue将Message发送到Looper线程。Message对象中持有Callback（Runnable）和Handler的引用。因此，如果一个Message在队列中等待执行，它和它的Handler（以及Handler所引用的Activity）都不会被GC回收。

修复方案：正确处理Handler的生命周期

public class MessageActivity extends AppCompatActivity {
    private static final long REFRESH_INTERVAL = 5000L;
    private Handler handler = new Handler(Looper.getMainLooper());
    private Runnable refreshRunnable;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_message);
        
        // 使用静态内部类避免隐式持有外部类引用
        refreshRunnable = new Runnable() {
            @Override
            public void run() {
                refreshUnreadCount();
                if (isActivityAlive()) { // 检查Activity是否仍然有效
                    handler.postDelayed(this, REFRESH_INTERVAL);
                }
            }
        };
    }

    @Override
    protected void onStart() {
        super.onStart();
        handler.post(refreshRunnable);
    }

    @Override
    protected void onStop() {
        super.onStop();
        handler.removeCallbacks(refreshRunnable); // 关键：移除回调
    }
    
    private boolean isActivityAlive() {
        return !isFinishing() && !isDestroyed();
    }
    
    private void refreshUnreadCount() {
        // 刷新逻辑
    }
}

进一步优化，使用 LifecycleObserver 来自动管理Handler的启停：

public class MessageActivity extends AppCompatActivity implements LifecycleObserver {
    private Handler handler = new Handler(Looper.getMainLooper());
    private Runnable refreshRunnable;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_message);
        
        refreshRunnable = () -> {
            refreshUnreadCount();
            if (getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.STARTED)) {
                handler.postDelayed(refreshRunnable, REFRESH_INTERVAL);
            }
        };
        
        // 添加LifecycleObserver
        getLifecycle().addObserver(this);
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    public void startRefresh() {
        handler.post(refreshRunnable);
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    public void stopRefresh() {
        handler.removeCallbacks(refreshRunnable);
    }
    
    private void refreshUnreadCount() {
        // 刷新逻辑
    }
}

总结：从崩溃到优雅的进阶之路

这三个案例虽然具体场景不同，但都指向Android开发中的核心问题：生命周期管理和内存引用。

  1. 永远不要忽视Activity的生命周期：任何在Activity onCreate 中启动的操作，都需要考虑在 onDestroy 中正确清理。
  2. 警惕匿名内部类和静态引用：它们会隐式持有外部类的引用，导致内存泄漏。考虑使用静态内部类配合 WeakReference。
  3. 使用现代API：Lifecycle 组件、ViewModel、LiveData 等是现代Android开发的最佳实践，它们能帮助你更好地管理组件生命周期，避免常见的内存泄漏问题。

最后，记住：好的代码不仅不会崩溃，而且不会偷偷吃掉你的内存。通过使用正确的工具（如Android Studio的Memory Profiler、LeakCanary）定期检查，你可以将大部分内存泄漏问题扼杀在摇篮里。

希望这些真实案例能帮助你更好地理解Android的底层机制，写出更健壮、更高效的应用。毕竟，一个优雅退出的应用，远比一个频繁闪退的应用更能赢得用户的信任。

-- 展开阅读全文 --