企业官网建设流程全解析

简介：本资源是一套面向Android开发初学者与进阶者的音乐播放器实战源码合集，涵盖9个功能各异的播放器项目，解决音频播放、后台服务控制、多线程下载、断点续传、在线流媒体播放等核心开发痛点，适用于课程设计、毕业项目及技术能力提升场景。压缩包共2253个文件，总大小83.21MB，包含341个C/C++头文件（h）、242个XML布局与配置文件、165个Java源码、462个编译后class文件、554个PNG图标资源，以及SDL/FFmpeg底层适配代码（c/cc/m）、AIDL跨进程通信接口（aidl）、APK安装包与PDF文档等，结构完整、模块清晰，便于分层学习与源码调试。已有4074人学习下载，读者可直接复用Service后台播放架构、异步加载专辑图方案、边下边播逻辑及多线程下载管理器等成熟实现，快速构建具备生产级功能的音乐应用。

1. 项目概述：9个真实可运行的Android音乐播放器源码，到底值不值得花时间深挖？

“Android实例源码-音乐播放器类安卓源代码（9例）.zip”——这个标题在安卓开发初学者和自学转岗人群中反复出现，尤其在CSDN、GitHub镜像站、技术论坛资源帖里高频刷屏。它不是某个商业产品的SDK，也不是某家大厂开源的完整App，而是一组2015–2018年间由高校教师、培训机构讲师和早期独立开发者整理的教学级工程集合。我第一次接触它是在带实习生做毕业设计时，当时手头只有Android Studio 2.3 + API 23（Android 6.0），没有Jetpack Compose，没有Media3，连ExoPlayer都还没成为官方推荐方案。这9个工程，每一个我都从头编译、调试、反编译、重写关键模块，前后耗时近三个月。它们的价值，不在于“能跑”，而在于精准卡在安卓多媒体开发演进的关键断层线上：既保留了原始MediaPlayer API的底层逻辑，又暴露了早期Service+BroadcastReceiver架构的致命缺陷；既有基于AssetManager加载本地音频的朴素方案，也有尝试ContentProvider共享媒体库的过渡形态；甚至包含一个用SurfaceView硬解H.264+AAC封装视频的“伪音乐播放器”——它根本没播声音，只渲染波形图，但恰恰是理解AudioTrack与OpenGL ES协同机制的绝佳入口。

这9个工程覆盖了本地文件播放（MP3/WAV）、SD卡扫描、后台服务控制、通知栏快捷操作、耳机按键响应、简易均衡器UI、歌词同步滚动、播放列表持久化、以及一个带基础蓝牙A2DP支持的变体。它们不是玩具Demo，而是当年真实教学场景中“学生能抄、老师能讲、面试官能问”的最小可行闭环。比如第3个工程（MusicPlayerServiceDemo）里，startForeground()调用前漏掉NotificationChannel创建，导致Android 8.0+直接崩溃——这个坑，我在2019年帮三个不同公司的新人填过。再比如第7个工程（LyricPlayer）中，用TextPaint.getTextBounds()计算单行歌词宽度时未考虑getFontMetrics()的baseline偏移，导致滚动错位——这种细节，官方文档从不提，但真机上一跑就露馅。所以，如果你正准备安卓开发面试、想补全多媒体模块知识链、或需要快速搭建一个轻量级音频控制基座，这9个源码不是“过时资料”，而是一套自带错误注释的活体教科书。它不教你最新语法，但教会你为什么MediaPlayer要被弃用、为什么MediaSessionCompat必须配合Notification使用、为什么AudioFocus管理比想象中更复杂。下面，我们就逐层拆解这9个工程背后的技术脉络、实操陷阱和现代迁移路径。

2. 整体架构设计与选型逻辑：为什么是这9个，而不是1个或90个？

2.1 九宫格式教学结构：覆盖安卓音频开发的“能力坐标系”

这9个工程绝非随意堆砌，而是按功能维度+架构演进双轴精心排布。横轴是核心能力模块（播放控制、后台服务、UI交互、系统集成），纵轴是API演进阶段（原生MediaPlayer → Service封装 → MediaSession过渡 → Jetpack兼容层）。我把它画成一张能力坐标表，实际开发中每个工程都占据唯一坐标点：

这个结构设计意图非常明确：用最小工程量覆盖最大知识断层。比如工程3和工程4组合，就完整呈现了“后台播放”这一需求在Android 5.0到12.0之间的三段式演进——从单纯startService，到强制前台服务+Notification，再到MediaSession+MediaStyle Notification。学生不必读完9个，只要对比工程3（API 21）和工程4（API 26），就能直观理解Google为何强制推行MediaSession。再如工程5（耳机按键）和工程9（蓝牙），表面是输入设备，实则暗含Android音频焦点（AudioFocus）管理的完整链条：按键事件触发requestAudioFocus()，蓝牙连接状态变更触发abandonAudioFocus()，而工程6的均衡器则依赖AudioManager获取当前焦点状态。这种设计，让学习者在改代码时自然建立系统级认知，而非孤立记忆API。

2.2 为什么放弃现代方案？历史包袱即教学价值

有人会质疑：都2024年了，为什么还要研究这些“古董”？因为现代方案（Media3 + Jetpack Compose）的抽象层，恰恰掩盖了最该被理解的底层契约。举个典型例子：Media3的Player接口定义了play(),pause(),seekTo()，但没告诉你seekTo()内部如何与AudioTrack的write()缓冲区对齐；MediaSession自动处理通知栏，却隐藏了Notification.Builder必须设置setSmallIcon()和setContentIntent()才能避免Android 8.0+崩溃的硬性要求。而这9个工程，每一个崩溃点都是教学锚点。工程3在Android 8.0模拟器上必崩，报错java.lang.IllegalArgumentException: Invalid notification (no valid small icon)——这个错误逼你去查NotificationCompat.Builder源码，发现setSmallIcon()是build()前的强制校验项；工程5在Android 10真机上耳机键失灵，日志显示BroadcastReceiver not registered，引导你深入Context.registerReceiver()的生命周期约束。这些“缺陷”，是官方文档不会写的实战常识，却是面试官最爱问的“你遇到过最棘手的兼容性问题是什么”。

更关键的是，大量存量企业App仍运行在这套旧架构上。我去年审计过三家金融类App，其后台音乐播放模块仍基于工程3的Service模型，只做了最低限度的Android 12适配（加了foregroundServiceType）。原因很现实：重构成本远高于打补丁。当你接手维护时，面对的不是Media3的优雅接口，而是startService()后一堆Handler.sendMessage()的胶水代码。这9个工程，就是你的“考古工具包”，帮你快速定位onStartCommand()里哪个if分支控制着蓝牙重连逻辑，或者onDestroy()里哪行unregisterReceiver()漏写了导致内存泄漏。

2.3 工程间依赖关系：不是孤立样本，而是演进脚手架

这9个工程存在隐式依赖链，按编号顺序阅读，相当于经历一次微型架构升级。工程1是起点：纯Activity内嵌MediaPlayer，所有逻辑写在onCreate()里。工程2在此基础上增加ContentResolver扫描，但数据仍存于Activity成员变量，未解耦。工程3将播放逻辑抽离为Service，但Service与Activity通信仍用sendBroadcast()——这就是工程4优化的靶子：用LocalBroadcastManager替代全局广播，降低耦合。工程5引入耳机键，但监听逻辑散落在Activity和Service中，直到工程6才用AudioManager统一管理焦点，为工程7的歌词同步提供时间基准。这种渐进式设计，让学习者自然理解“为什么需要MVC分层”、“为什么EventBus比广播更安全”。特别值得注意的是，工程8的播放列表持久化，其SharedPreferences键名全部以music_player_开头，且工程9的蓝牙模块复用该键名存储已配对设备列表——这暴露了真实开发中的常见失误：缺乏统一配置中心，导致不同模块用相同Key覆盖数据。我在带团队时，曾因此引发过支付音频提示音被播放列表覆盖的线上事故。这种“错误示范”，比任何理论讲解都更有警示力。

3. 核心模块深度解析：从MediaPlayer到MediaSession的十年变迁

3.1 播放引擎：MediaPlayer的荣光与枷锁

所有9个工程的播放核心，都始于android.media.MediaPlayer。这不是选择，而是时代限定。在Android 4.1（API 16）之前，这是唯一官方音频播放API。我们以工程1为例，看它的初始化流程：

// 工程1 MusicPlayerActivity.java 片段 private void initMediaPlayer() { mediaPlayer = new MediaPlayer(); // 关键：必须在setDataSource前调用setAudioStreamType mediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC); try { // 直接传入FileDescriptor，绕过Uri权限问题（Android 6.0前） FileInputStream fis = new FileInputStream("/sdcard/music/song.mp3"); mediaPlayer.setDataSource(fis.getFD()); fis.close(); mediaPlayer.prepare(); // 同步阻塞，易ANR mediaPlayer.setOnCompletionListener(this); } catch (IOException e) { Log.e("MusicPlayer", "Prepare failed", e); // 注意：此处无finally块，fis可能未关闭！ } }

这段代码藏着三个关键教学点：
第一，setAudioStreamType()的不可省略性。很多新手以为STREAM_MUSIC是默认值，实则MediaPlayer构造后streamType为STREAM_VOICE_CALL，若不显式设置，播放时系统会错误路由到听筒而非扬声器。这在工程1的真机测试中极易复现——插着耳机却没声音，拔掉耳机才响。
第二，prepare()的同步阻塞风险。工程1用prepare()而非prepareAsync()，导致UI线程卡死。当加载大文件（>50MB）时，ANR概率极高。工程2开始改用prepareAsync()+OnPreparedListener，但未处理onPrepared()回调时机——它可能在onCreate()完成前触发，导致findViewById()返回null。这个坑，在工程2的onPrepared()里有注释：“// TODO: check view null”，至今未修复。
第三，资源泄漏隐患。FileInputStream在catch块中未关闭，mediaPlayer对象也未在onDestroy()中release()。这在工程1连续播放10首歌后，Logcat会出现"Leaked MediaPlayer object"警告。而工程3的Service版本，因onDestroy()未调用mediaPlayer.release()，导致后台播放时内存持续增长，最终OOM。

MediaPlayer的真正枷锁，在于状态机的脆弱性。它的6个状态（Idle, Initialized, Prepared, Started, Paused, Stopped）必须严格遵循转换规则。工程4的Notification控制按钮，点击暂停时调用mediaPlayer.pause()，但若此时MediaPlayer处于Prepared状态（刚加载完未播放），pause()会抛IllegalStateException。解决方案不是加try-catch，而是用isPlaying()判断状态——但isPlaying()在Prepared状态返回false，Started状态返回true，这要求开发者必须维护一个独立的状态标志位。这正是工程6引入AudioManager管理焦点的深层原因：用系统级音频焦点状态，替代MediaPlayer的内部状态机。

3.2 后台服务：从Started Service到Foreground Service的生死线

工程3是这9个中最具“时代感”的工程，它用Started Service实现后台播放，代码简洁得令人心疼：

// 工程3 MusicService.java 片段 public class MusicService extends Service { private MediaPlayer mediaPlayer; @Override public int onStartCommand(Intent intent, int flags, int startId) { String action = intent.getAction(); if ("PLAY".equals(action)) { if (!mediaPlayer.isPlaying()) { mediaPlayer.start(); } } else if ("PAUSE".equals(action)) { if (mediaPlayer.isPlaying()) { mediaPlayer.pause(); } } return START_STICKY; // 关键：保证Service崩溃后重启 } @Override public void onDestroy() { if (mediaPlayer != null) { mediaPlayer.release(); mediaPlayer = null; } super.onDestroy(); } }

START_STICKY是它的灵魂，也是它的诅咒。在Android 4.x时代，这是保证音乐不停的关键；但在Android 5.0+，系统会主动杀死长时间后台Service，START_STICKY仅表示“如果内存充足，可重启”。工程3在Android 7.0模拟器上，播放30分钟后必然被杀。解决方案是工程4引入的startForeground()：

// 巇程4 NotificationHelper.java 片段 private void startForegroundService() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { // Android 8.0+ 必须创建NotificationChannel NotificationChannel channel = new NotificationChannel( "music_channel", "Music Player", NotificationManager.IMPORTANCE_LOW); notificationManager.createNotificationChannel(channel); // 注意：channelID必须与NotificationBuilder一致 notification = new NotificationCompat.Builder(this, "music_channel") .setContentTitle("Music Player") .setContentText("Playing...") .setSmallIcon(R.drawable.ic_notification) .build(); } else { notification = new NotificationCompat.Builder(this) .setContentTitle("Music Player") .setContentText("Playing...") .setSmallIcon(R.drawable.ic_notification) .build(); } startForeground(1, notification); // ID=1，必须非零 }

这里有两个致命细节：
NotificationChannel的创建时机。必须在startForeground()前调用createNotificationChannel()，且channelID（"music_channel"）必须与NotificationCompat.Builder构造函数第二个参数完全一致。工程4最初漏掉createNotificationChannel()，导致Android 8.0+直接崩溃IllegalArgumentException: Channel undefined。
startForeground()的ID参数。必须是非零整数，ID=0会导致startForeground()静默失败，Service降级为普通后台Service，很快被杀。这个ID还用于后续更新通知，工程4用notificationManager.notify(1, newNotification)保持ID一致。

到了Android 9.0，Google进一步收紧：startForeground()必须在onStartCommand()的10秒内调用，否则抛ForegroundServiceStartNotAllowedException。这迫使工程4在onStartCommand()开头就调用startForegroundService()，而非等播放开始后再调。这种演进，清晰展示了安卓后台策略从“尽力而为”到“强制约束”的转变逻辑。

3.3 系统集成：AudioFocus与MediaSession的协同逻辑

工程5和工程6共同构建了音频焦点管理的完整链路。耳机按键事件（ACTION_HEADSET_PLUG）本身不控制播放，而是触发AudioManager.requestAudioFocus()，这才是真正的播放开关。工程5的代码：

// 工程5 HeadsetReceiver.java 片段 @Override public void onReceive(Context context, Intent intent) { if (Intent.ACTION_HEADSET_PLUG.equals(intent.getAction())) { int state = intent.getIntExtra("state", 0); if (state == 1) { // 插入 AudioManager audioManager = (AudioManager) context.getSystemService(Context.AUDIO_SERVICE); int result = audioManager.requestAudioFocus( focusChangeListener, AudioManager.STREAM_MUSIC, AudioManager.AUDIOFOCUS_GAIN); if (result == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) { // 开始播放 startPlayback(); } } } }

focusChangeListener是关键回调：

private AudioManager.OnAudioFocusChangeListener focusChangeListener = new AudioManager.OnAudioFocusChangeListener() { @Override public void onAudioFocusChange(int focusChange) { switch (focusChange) { case AudioManager.AUDIOFOCUS_GAIN: // 获得焦点，恢复播放 if (mediaPlayer != null && !mediaPlayer.isPlaying()) { mediaPlayer.start(); } break; case AudioManager.AUDIOFOCUS_LOSS: // 永久失去焦点，停止播放 if (mediaPlayer != null && mediaPlayer.isPlaying()) { mediaPlayer.pause(); } break; case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT: // 暂时失去焦点（如来电），暂停 if (mediaPlayer != null && mediaPlayer.isPlaying()) { mediaPlayer.pause(); } break; } } };

这个设计暴露了两个核心矛盾：
第一，AUDIOFOCUS_LOSS与AUDIOFOCUS_LOSS_TRANSIENT的语义混淆。LOST表示其他App永久占用音频流（如导航App），应暂停并释放资源；TRANSIENT表示临时抢占（如短信提示音），应暂停但保持MediaPlayer状态。工程5未区分二者，一律pause()，导致微信语音通话结束后音乐无法自动恢复。正确做法是TRANSIENT时记录当前位置，LOST时stop()并reset()。
第二，焦点请求的“竞态条件”。多个组件（耳机键、蓝牙、通知栏按钮）可能同时调用requestAudioFocus()，而AudioManager不保证回调顺序。工程6引入MediaSession后，用MediaSession.setActive(true)自动处理焦点获取与释放，但MediaSession的setCallback()必须在setActive()前注册，否则回调不生效——这个顺序陷阱，在工程6的onCreate()里有注释：“// MUST setCallback before setActive!”。

MediaSession的真正价值，在于统一系统入口。工程4的Notification、工程5的耳机键、工程9的蓝牙，最终都通过MediaSession的Callback接收指令：

// 工程6 MediaSessionCallback.java 片段 private final MediaSessionCompat.Callback mediaCallback = new MediaSessionCompat.Callback() { @Override public void onPlay() { // 统一播放入口，不再分散在各处 if (mediaPlayer != null && !mediaPlayer.isPlaying()) { mediaPlayer.start(); } } @Override public void onPause() { if (mediaPlayer != null && mediaPlayer.isPlaying()) { mediaPlayer.pause(); } } @Override public void onSkipToNext() { // 下一首，触发播放列表更新 playNextSong(); } };

MediaSession将原本散落在BroadcastReceiver、Service、Activity中的控制逻辑，收束到单一回调中。这不仅是代码整洁，更是系统级契约的履行：当用户在锁屏界面点击播放按钮，系统通过MediaSession向你的App发送onPlay()，而非广播。这种设计，让工程6成为9个中唯一能通过Android CTS（兼容性测试套件）媒体模块验证的工程。

4. 实操过程与关键环节实现：从编译到真机调试的全流程避坑指南

4.1 环境搭建：Android Studio版本与SDK的精确匹配

这9个工程诞生于Android Studio 1.5–2.3时代，直接导入最新版AS（如2023.2）必然失败。我实测的最佳匹配方案如下：

具体操作步骤：

1. 下载Android Studio 2.3（官网存档版），安装时取消勾选“Android SDK”，避免自动安装新版SDK。
2. 手动下载SDK 22/25/26/27平台包：访问https://dl.google.com/android/repository/，下载对应platforms;android-XX压缩包，解压到Android/Sdk/platforms/目录。
3. 在gradle.properties中添加：

   # 强制使用旧版build-tools android.useDeprecatedNdk=true # 解决AS 2.3的Gradle插件冲突 android.enableD8=false

4. 修改build.gradle（Module: app）：

   android { compileSdkVersion 26 // 对应Target SDK buildToolsVersion "26.0.2" // 必须与SDK版本匹配 defaultConfig { applicationId "com.example.musicplayer" minSdkVersion 16 targetSdkVersion 26 // 关键：targetSdkVersion决定行为 versionCode 1 versionName "1.0" } } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) // 支持库版本必须与compileSdkVersion一致 compile 'com.android.support:appcompat-v7:26.1.0' compile 'com.android.support:support-v4:26.1.0' }

提示：targetSdkVersion是核心开关。设为25时，startForeground()无需NotificationChannel；设为26+则必须创建。工程3若强行升targetSdkVersion到28，不加Channel会直接崩溃，这是验证兼容性策略的最快方式。

4.2 真机调试：权限、存储与蓝牙的三重关卡

在Pixel 3a（Android 11）上调试工程9（蓝牙播放器）时，我遭遇了三重障碍，每个都代表一类典型问题：

第一关：存储权限。工程2的SD卡扫描使用Environment.getExternalStorageDirectory()，在Android 10+被废弃。解决方案不是简单加requestLegacyExternalStorage=true（仅限targetSdkVersion≤29），而是重构为MediaStore查询：

// 替换工程2的原始扫描代码 String[] projection = { MediaStore.Audio.Media._ID, MediaStore.Audio.Media.TITLE, MediaStore.Audio.Media.DATA, MediaStore.Audio.Media.DURATION }; Cursor cursor = getContentResolver().query( MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, projection, null, null, null); while (cursor.moveToNext()) { String title = cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.TITLE)); String path = cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.DATA)); // 注意：path在Android 10+可能是content:// URI，需用ContentResolver.openInputStream() }

第二关：蓝牙权限。工程9在Android 12+需同时申请BLUETOOTH_CONNECT和BLUETOOTH_SCAN，且必须在AndroidManifest.xml中声明：

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" /> <uses-permission android:name="android.permission.BLUETOOTH_SCAN" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <!-- 注意：ACCESS_FINE_LOCATION是BLUETOOTH_SCAN的前置条件 -->

但仅声明不够，还需运行时请求：

// 工程9 BluetoothHelper.java if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) { if (ContextCompat.checkSelfPermission(this, Manifest.permission.BLUETOOTH_CONNECT) != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.BLUETOOTH_CONNECT}, REQUEST_CODE_BLUETOOTH); } }

第三关：AudioFocus焦点抢占。在调试工程5时，我发现微信语音通话结束后音乐不恢复。根源在于AUDIOFOCUS_LOSS_TRANSIENT回调中，工程5只pause()，未保存播放位置。修复方案：

private int lastPosition = 0; @Override public void onAudioFocusChange(int focusChange) { switch (focusChange) { case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT: if (mediaPlayer.isPlaying()) { lastPosition = mediaPlayer.getCurrentPosition(); mediaPlayer.pause(); } break; case AudioManager.AUDIOFOCUS_GAIN: if (mediaPlayer != null) { mediaPlayer.seekTo(lastPosition); // 恢复到暂停位置 mediaPlayer.start(); } break; } }

注意：getCurrentPosition()在pause()后立即调用可能返回0，应在pause()前获取。这个细节，是工程5未注释的隐藏坑。

4.3 UI与交互：歌词同步与通知栏的像素级调试

工程7的歌词同步，是9个工程中最考验“时间精度”的模块。其核心逻辑是：

// 工程7 LyricView.java private void updateLyricDisplay() { long currentPosition = mediaPlayer.getCurrentPosition(); // 遍历歌词时间戳数组，找到当前行 for (int i = 0; i < timeStamps.length; i++) { if (currentPosition >= timeStamps[i] && (i == timeStamps.length - 1 || currentPosition < timeStamps[i + 1])) { // 设置当前行高亮 setHighlightedLine(i); // 滚动到可视区域 smoothScrollTo(0, getLineTop(i) - getHeight() / 2); break; } } }

问题在于getCurrentPosition()的返回值是毫秒级，但timeStamps数组是LRC文件解析的整数秒（如[0, 10000, 20000]），导致快进时currentPosition=15000，却找不到匹配项（15000≥10000成立，但15000<20000也成立，循环提前退出）。实测解决方案是用二分查找替代线性遍历，并增加容错范围：

private int findCurrentLine(long currentPosition) { int left = 0, right = timeStamps.length - 1; while (left <= right) { int mid = (left + right) / 2; if (currentPosition >= timeStamps[mid] && (mid == timeStamps.length - 1 || currentPosition < timeStamps[mid + 1])) { return mid; } else if (currentPosition < timeStamps[mid]) { right = mid - 1; } else { left = mid + 1; } } // 容错：返回最接近的行 return Math.max(0, Math.min(timeStamps.length - 1, left)); }

通知栏（工程4）的调试，则聚焦在RemoteViews的布局兼容性。RemoteViews不支持ConstraintLayout，必须用LinearLayout或RelativeLayout。工程4的notification_layout.xml：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="64dp" android:orientation="horizontal"> <ImageView android:id="@+id/iv_play" android:layout_width="48dp" android:layout_height="48dp" android:src="@drawable/ic_play" /> <TextView android:id="@+id/tv_title" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_weight="1" android:text="Song Title" android:layout_gravity="center_vertical" /> </LinearLayout>

关键点：android:layout_gravity="center_vertical"确保文本垂直居中，android:layout_weight="1"分配剩余空间。若用ConstraintLayout，RemoteViews会静默忽略约束，导致控件重叠。

5. 常见问题与排查技巧实录：9个工程踩过的37个坑汇总

5.1 编译期问题：Gradle与依赖的连锁反应

5.2 运行时崩溃：状态机与生命周期的致命交锋

5.3 功能异常：音频焦点与系统集成的隐性故障

5.4 性能与体验：ANR与内存泄漏的

本文还有配套的精品资源，点击获取