音乐播放器分析——目录及总结

目录

音乐播放器代码解释

音乐播放器-manifest分析

音乐播放器-引导界面的实现

SplashScreen代码分析

音乐播放器-MainContentActivity简析

音乐播放器-DAO之MusicUtils

音乐播放器-DAO

音乐播放器-MainFragment分析1

音乐播放器-MainFragment分析2

音乐播放器-MainFragment分析3

音乐播放器-MainFragment分析4

音乐播放器-MainFragment分析5

音乐播放器-MainFragment分析6

音乐播放器-Activities

音乐播放器-MenuFragment

总结

读代码

如何阅读别人的代码，知乎上面有许多好的帖子，这就是一例，里面每个回答都很精辟，甚至无需整理就是一个很完美的回答，很少有重复的观点。这些方法是通用的方法，在面向对象语言里面，如果能够熟练掌握设计模式，当所读的代码用到该设计模式的时候可以直接套用自己以前理解的思维模型，这样就更方便了。

正如第二个帖子说的那样，好代码和烂代码的阅读方式是不一样的，不同人写不同的代码的命名风格也会不一样，如果在源代码里面有不同的命名风格，甚至命名根本不能做到让人望名知义，那这样的代码阅读的效率会比普通代码少了一个数量级。

总结起来，源代码的阅读方式如下：

Top-Bottom & Bottom-Top

了解功能业务

从启动入口开始读

读文档，写注释(注释就是“笔记”咯)

等

本分析博客的分析过程是由MVC所启发的，于是就先分析了数据层，再分析UI，当然也是从启动入口开始读的，遇到某一个方法的时候不仅仅看方法内怎么实现，同时也关注该方法都在哪里调用过，也就是Top-Bottom & Bottom-Top，在读一个项目的时候我们肯定是要反复的使用它，就比如该app，装在手机上到处点点，知道触发控件是哪个，比如在使用SlidingDrawer的时候，并不是点击handle的时候启动的，handle是负责退出的。如果能画出真个业务流程当然也是不错的选择。最开始的时候也写过一个SplashScreen的测试用例，这样有助于巩固已经了解的知识。

读架构

许久之前，我一直苦恼自己对于1k行以上的代码有种畏惧感（该app的xml+java文件有1-2w行），尽管听说过架构这个词语，不是很了解，现在回过头来才发现写程序之前应该先搞清楚架构。由于开始所接触的代码的架构都比较简单，所以容易忽略这个问题。

读数据模型

随着计算机计算速度的飞涨，制约软件的运行的就只剩下数据，所有的代码无非是做些数据的处理罢了，了解过底层的人都知道，cpu有2个输入流，一个是指令流一个是数据流。其实指令本身不就是数据吗，怪不得大数据近年来一直吵得火热，把数据分析处理模型单列出来是早晚的事情。

在这里假设没有数据连调试就很困难，数据是基本的。其实该app的数据层并不麻烦，在db和model包（省略了com.longdw.music）下,有该数据模型，除此之外，歌词也是数据，也有歌词的model，不过歌词没有存在数据库文件里面。至于sharepreference就不多说了。

读Manager

该app共有6个Activity，1个Service，若干个动态BroadcastReceiver，其中5个Activity看下就明白了，BroadcastReceiver就不多说了，ServiceManager在Application里面就使用了，以后每次用到service都通过aidl从ServiceConnection里面获取service的引用。

为什么会有多篇blog介绍MainManifest呢，在MainContentActivity里面通过getSupportfragmentManager().begintransaction().replace()方法里面设置的Fragment，而该Fragment的onCreateView直接就包含了所有的控件，只不过有的不显示设置了View.GONE,于是如何对这些控件进行操作呢？，这就引出了各个控件的Manager。值得着重的是，从主界面的5个gridview item里面进入音乐列表并不是都是2次或者1次的，但最终进去的都是同一个Manager，这里巧妙的使用了2个ViewPager，并在一个方法通过8个switch_case进行设置。不得不佩服作者的设计。

每次缔造UIManager都用到了Activity和主View的引用，由此可见这在android项目中使用是多么的频繁。

其他

也许其他应用不是这么写的，不是通过Manager管理UI，不是使用透明的ViewPager等，但android上面提到的读代码的方法，架构基本就明晰了。