下次自动登录
现在的位置:
& 综合 & 正文
新版Eclipse中关联查看Android 源代码和android-support-v4源代码
之前有一些博客介绍了如何在Eclipse中关联查看Android的，但是那些博客已经比较久，而且现在国内几乎登不上Android官网，下载Android源比较麻烦。故提供更新版的在Eclipse中关联Android源代码和android-support-v4源代码的方法。
这里提供Android 4.4.2源代码在csdn的下载地址：
http://download.csdn.net/detail/llp
下载完之后，解压得到如下目录：
将上面的所有压缩文件解压之后的到如下目录：
这就是源代码了。
打开Eclipse，任选一个工程，右键，选择下方的 Properties ， 点击 Java Build Path ，点击 Libraries ，点击 Android 4.x.x（根据个人SDK版本而定），点击 android.jar ，里面有个 Source attachment: 选择该项，并点击右边的 Add External Class Folder...，
在弹出的文件选择框中，选中刚刚解压生成的包含如下图片目录的 名字为android-17 的文件夹
点击OK即完成了Android源代码的关联。
查看方法：按住 Ctrl 按键，再点击某一个类型变量或函数，比如按下 Ctrl 并点击 Button ，可以查看 Button的源代码，如下：
将下来说说如何关联 android-support-v4源代码
android官网下载的ADT中已经包含了该源代码，在 SDK目录下，\sdk\extras\android\support\v4
其中的src 文件就是源代码。
首先还是选中一个工程，点击Properties ， 点击 Java Build Path 点击 Libraries，选中右边的 Add External
JARs ，在弹出来的文件选择框中选中该目录\sdk\extras\android\support\v4 下的
android-support-v4.jar 包，结果如下：
点击该包，可以看到里面有个 Source attachment:
双击该选项，在弹出来的文件选择框中选中 该目录F:\adt-bundle-windows-x86-\sdk\extras\android\support\v4 下 的src 文件夹，点击OK即完成关联。
查看方法和上面查看源代码的方法一样。比如我们打开查找某一个java文件，输入 cur 时可以看到如下：已经出现了
android-support-v4源代码中的CursorAdapter.java 文件。
&&&&推荐文章:
【上篇】【下篇】【Android Support】（5）
v4 包从 2011 年开始引入，包含 ViewPager、FragmentActivity 等我们常用的功能。
从24.2.0 之后，为了提高效率，此库拆分成多个模块。出于向后兼容的考虑，如果您在 Gradle 脚本中依赖了 support-v4，您的 APK 将包含所有的 v4 模块。不过，要减少 APK 大小，我们建议仅依赖需要的特定模块。目前v4包拆分为 5 个子的 Module，每个 Module 可以被单独引用。
1、子Module介绍
(1) support-compat
兼容一些 Framework API。如 Context.getDrawable() 和 View.performAccessibilityAction()。
Gradle依赖如下所示：
com.android.support:support-compat:24.2.0
(2) support-core-utils
提供一系列核心的工具，如 AsyncTaskLoader 和 PermissionChecker。
Gradle依赖如下所示：
com.android.support:support-core-utils:24.2.0
(3) support-core-ui
提供一系列核心的 UI，如 ViewPager、 NestedScrollView。
Gradle依赖如下所示：
com.android.support:support-core-ui:24.2.0
(4) support-media-compat
android.media 兼容库，包括 MediaBrowser 和 MediaSession。
Gradle依赖如下所示：
com.android.support:support-media-compat:24.2.0
(5) support-fragment
fragment 的兼容库
Gradle依赖如下所示：
com.android.support:support-fragment:24.2.0
2、子 Module 间依赖关系
PS：其中 support-annotations 为一些注解的声明库，如我们比较常用的 RequiresApi、UiThread、NonNull。
从中可以看出 support-fragment 依赖于所有其他子 Module，而 support-v4 包含所有 Module，所以现在引入
compile 'com.android.support:support-fragment:24.2.0'
compile 'com.android.support:support-v4:24.2.0'
的效果是一样的。
support-v4 拆分的好处第一眼看来便是能减少应用大小，因为你不需要引用完整的 support-v4 包，只需要引用子的 Module 即可。
比如我只用了 AsyncTaskLoader，只需要引用 support-core-utils 即可，只有 90k 哎，比原来的 1.3M 降了一个数量级多，应用减少了 1M 多哎，然而真的这样吗？
(1) support-compat 过大
大家知道 AAR 的大小是不包含它的依赖大小的，所以 support-core-utils 90k大小仅表示自己的代码和资源总大小。
从上面的依赖关系可以看出它们都依赖 support-compat，而 support-compat 有 602k，它依赖的 support-annotations 还有 21k，这样引用 support-core-utils 实际增大大小约为 700k+。这样比 1.3M 还是少了一半，也是不错，然而还没有结束。
(2) support-v4 触角太深
v4 包从 2011 年开始出来，由于 ViewPager、FragmentActivity 等类，v4 被大量其他包引用，早已子孙遍全球，比如 v7 兼容包 appcompat-v7 就依赖 v4。
我们可以尝试通过 exclude module 可以把 v7 中 v4 去掉，然并卵，v7 依赖 FragmentActivity 这个类，而 FragmentActivity 位于 v4 的 support-fragment 中，所以依赖变成这样：
compile ('com.android.support:appcompat-v7:24.2.0') {
exclude module: 'support-v4'
compile 'com.android.support:support-fragment:24.2.0'上面介绍过现在 com.android.support:support-fragment 与 com.android.support:support-v4 已经几乎无异，所以对于依赖 v7 的 App 来说这次的 v4 拆分不能带来任何依赖包体积的精简。
初步看来 data-binding 也依赖与 support-v4。
这样看来 v4 包的拆分是否是 Google 的自娱自乐，对于开发者全无好处呢？我看并不是。
1 这个拆分本身对于 V4 包项目来说是好事
各模块划清各自功能边界，充分解耦。
2 减小apk体积
灵活选择自己需要的module
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：9430次
排名：千里之外
原创：61篇
(2)(12)(11)(15)(18)(4)(4)(3)(1)}