正文

Android编程从hello world到真实崩溃排查通过代码分析理解activity生命周期和内存泄漏避免新手踩坑

/0 浏览量
1008

说实话，我第一次看到Android Studio那个绿色的机器人图标时，以为写代码就像搭积木一样简单。结果呢？第一个项目跑起来的那一刻，屏幕黑屏，Logcat里全是红色的字，我盯着看了半小时，完全不知道自己在哪一步搞砸了。后来才慢慢明白，Android开发的坑，不是挖出来的，是趟出来的。

今天我不给你讲那些枯燥的理论，就咱们像朋友聊天一样，把你从一个只会打印”Hello World”的新手，一路带看到能独立排查崩溃、理解Activity生命周期、甚至避开内存泄漏这些高级坑位。整个过程我会穿插真实的代码示例，就像我之前踩过的坑一样，咱们一起看看怎么绕过去。

从Hello World开始：别急着复制粘贴

你还记得你第一次写Android代码的样子吗？创建项目，选Empty Activity，然后看着MainActivity.java里那几行代码，心里满是期待。

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        
        TextView textView = findViewById(R.id.textView);
        textView.setText("Hello World!");
    }
}

看起来很简单对吧？但你知道吗，这里面的每一行都有讲究。onCreate这个方法，是Activity生命周期的起点，也是很多新手最容易误解的地方。

我之前有个朋友，他在onCreate里写了个网络请求，结果每次切回前台，数据都会重新加载，用户体验极差。为什么？因为他没理解onCreate只会在Activity首次创建时调用，而不会在每次显示时调用。

Activity生命周期：不是背下来就能懂的

生命周期这个词，新手教程里讲得最多，但也最容易让人困惑。教科书式的那种讲法，就是画个图，告诉你onCreate、onStart、onResume、onPause、onStop、onDestroy这几个方法什么时候调用。

但说实话，你不真遇到事儿，根本记不住。

我有一次面试被问到一个问题：”如果用户在播放视频时收到电话，Activity的生命周期会怎么走？”我当时愣了三秒，因为我不确定 onPause 和 onStop 谁先谁后。后来我自己做了个测试，在log里打印每个方法的调用，才发现原来 onPause 先于 onStop 被调用。

public class MainActivity extends AppCompatActivity {
    private static final String TAG = "LifecycleDemo";
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.d(TAG, "onCreate called");
        setContentView(R.layout.activity_main);
    }
    
    @Override
    protected void onStart() {
        super.onStart();
        Log.d(TAG, "onStart called");
    }
    
    @Override
    protected void onResume() {
        super.onResume();
        Log.d(TAG, "onResume called");
    }
    
    @Override
    protected void onPause() {
        super.onPause();
        Log.d(TAG, "onPause called");
    }
    
    @Override
    protected void onStop() {
        super.onStop();
        Log.d(TAG, "onStop called");
    }
    
    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.d(TAG, "onDestroy called");
    }
}

运行这个代码，你试着按一下Home键，再按返回键，看看logcat里的输出。你会发现，生命周期其实没那么复杂，就是几个状态的切换而已。

但真正重要的是，你要理解这些状态切换背后的原因。比如，为什么 onPause 比 onStop 先调用？因为 onPause 是当Activity失去焦点时调用，比如弹出一个对话框，这时候Activity还在屏幕上，只是不再是前台了。而 onStop 是当Activity完全不可见时才调用。

崩溃排查：Logcat不是敌人，是帮手

新手最怕看到Logcat里红色的错误信息，但我想告诉你，这些红色其实是你最好的朋友。我第一次看到崩溃日志时，感觉就像医生拿着体检报告说你有病了一样，心里咯噔一下。但后来我发现，学会读这些日志，比盲目调试快多了。

举个真实的例子。有一次我在开发一个图片加载功能，用户滑动列表时，应用突然崩溃了。Logcat里显示：

Fatal Exception: java.lang.NullPointerException
Attempt to invoke virtual method 'void android.widget.ImageView.setImageBitmap(android.graphics.Bitmap)' on a null object reference
at com.example.myapp.ImageAdapter.onBindViewHolder(ImageAdapter.java:45)

看到这个错误，有经验的人一眼就能看出问题：ImageView是null。但新手可能会蒙圈，为什么ImageView会是null？是不是我没绑数据？是不是布局文件写错了？

其实，这类问题通常是因为View ID在编译时找不到，或者在bindViewHolder时ViewHolder还没创建完成。解决办法很简单，检查布局文件里的ID是否正确，然后在代码里确保View已经初始化。

public class ImageAdapter extends RecyclerView.Adapter<ImageAdapter.ViewHolder> {
    
    private static class ViewHolder extends RecyclerView.ViewHolder {
        ImageView imageView;
        
        ViewHolder(View itemView) {
            super(itemView);
            imageView = itemView.findViewById(R.id.image_view);
            if (imageView == null) {
                throw new IllegalStateException("ImageView not found in layout");
            }
        }
    }
    
    @Override
    public void onBindViewHolder(@NonNull ViewHolder holder, int position) {
        // 这里就不会因为null而崩溃了
        holder.imageView.setImageResource(images[position]);
    }
}

你看，加了个简单的检查，就能避免很多尴尬的崩溃。

内存泄漏：看不见的杀手

如果说崩溃是明刀明枪的战斗，那内存泄漏就是阴沟里的老鼠，悄无声息地啃食你的应用性能。

新手最容易犯的内存泄漏错误，就是持有Activity的引用。比如，你在Activity里创建了一个单例，然后在单例里引用了这个Activity。结果就是，即使你退出了这个Activity，它也无法被垃圾回收，因为单例还拿着它的引用。

public class SingletonHelper {
    private static SingletonHelper instance;
    private Activity activity;
    
    public static SingletonHelper getInstance(Activity activity) {
        if (instance == null) {
            instance = new SingletonHelper();
        }
        instance.activity = activity; // 这就是问题所在
        return instance;
    }
    
    public void doSomething() {
        // 使用 activity
        activity.finish();
    }
}

这段代码看起来没问题，但实际上，每次调用getInstance，都会把Activity的引用存进单例。等用户退出Activity，这个Activity就再也回收不了了，直到整个进程被杀死。

解决办法是用WeakReference：

public class SingletonHelper {
    private static SingletonHelper instance;
    private WeakReference<Activity> activityRef;
    
    public static SingletonHelper getInstance(Activity activity) {
        if (instance == null) {
            instance = new SingletonHelper();
        }
        instance.activityRef = new WeakReference<>(activity);
        return instance;
    }
    
    public void doSomething() {
        Activity activity = activityRef.get();
        if (activity != null && !activity.isFinishing()) {
            activity.finish();
        }
    }
}

这样，当Activity被销毁时，WeakReference不会阻止它被回收，内存泄漏的问题就解决了。

实战：从Hello World到真实项目

让我给你讲一个我朋友的故事。他刚开始做Android开发时，做了一个简单的笔记应用。功能很简单，就是添加笔记、查看笔记。但有一天，用户反馈说，用了一段时间后，应用变得很卡，甚至频繁崩溃。

他一开始以为是代码写得不好，就到处重构，但问题依然存在。后来我用Android Studio的Memory Profiler帮他分析，发现内存占用一直在上涨，从不下降。这就是典型的内存泄漏。

经过排查，他发现他在一个Fragment里用Handler发送了消息，但一直没有移除回调。这样即使Fragment被销毁，Handler还在持有Fragment的引用，导致内存无法回收。

public class NoteFragment extends Fragment {
    private Handler handler = new Handler(Looper.getMainLooper()) {
        @Override
        public void handleMessage(Message msg) {
            // 处理消息
        }
    };
    
    @Override
    public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) {
        super.onViewCreated(view, savedInstanceState);
        // 发送消息
        handler.sendEmptyMessageDelayed(1, 1000);
    }
    
    @Override
    public void onDestroyView() {
        super.onDestroyView();
        handler.removeCallbacksAndMessages(null); // 记得移除！
    }
}

你看，一个小小的疏忽，就会导致大问题。所以，养成好习惯很重要，特别是在处理Handler、线程、监听器这些容易持有引用的地方。

避坑指南：新手最容易踩的五个坑

  1. 不要在非主线程更新UI。Android规定，所有UI操作必须在主线程进行。如果你在其他线程更新UI，应用会直接崩溃。解决办法是使用Handler、View.post或者LiveData。

  2. 不要在onDestroy里做耗时操作。onDestroy是Activity被销毁时的最后一步，如果在这里做耗时操作，会拖慢整个应用的退出速度，甚至导致ANR（Application Not Responding）。

  3. 不要忽略生命周期。很多新手在onCreate里启动服务或者注册广播，但忘记在onDestroy里停止或注销。这会导致内存泄漏，甚至应用行为异常。

  4. 不要过度使用全局变量。全局变量虽然方便，但容易导致状态混乱和内存泄漏。尽量使用生命周期感知的组件，如ViewModel或LiveData。

  5. 不要忽视Lint警告。Android Studio的Lint工具会帮你发现潜在的问题，比如内存泄漏、性能问题等。不要总是忽略它们，仔细看看，可能会避免很多麻烦。

总结：从崩溃中学会成长

回过头看，我从那个只会打印”Hello World”的新手，到现在能独立排查崩溃、理解内存泄漏，其实就走了这么几条路：多写代码、多看日志、多思考为什么。

Android开发的确有很多坑，但每个坑都是一次学习的机会。当你真正理解了Activity的生命周期，学会了读崩溃日志，掌握了避免内存泄漏的技巧，你会发现，这些曾经让你头疼的问题，其实都变成了你能力的一部分。

所以，别怕崩溃，别怕错误。每一个崩溃日志，都是你在成长路上的一座灯塔。加油吧，未来的Android开发者！

-- 展开阅读全文 --