本文由 Lin Shen 译自 Common questions on AsyncTask,原文作者 Colt McAnlis, 转载请务必注明出处!

关于 AsyncTask 的常见问题

我在 Google 工作最喜欢的一点,就是把一些比较复杂的概念,分解成一小部分一小部分,这样就可以确保每一位工程师都能清楚地理解。在我最近的《Android 性能优化典范》视频中,我提到了一个表面上看上去很直观,但是它的一些属性可能会带来一些万万没想到的负面影响的东西,我是说,毫无悬念,这货就是 关于 AsyncTask:

我在这个视频里强调了一些开发者之前在使用 AsyncTask 时可能并不会注意到的事项。多亏了我们有一些非常棒的 android 开发者交流社区,能让我们看到大家反馈的一些问题:

让我们来挖掘其中的一些问题,看看能不能深入展开讨论一下:

Continue →

Project Home

https://github.com/shawnlinboy/android-OverscrollViewPager/

Description

最近项目里接到一个需求,效果如下:

简而言之,需要在 ViewPager 滑到最左或者最右的时候,仍然支持可滑动。

具体就是根据是在 ViewPager 最右边向右滑了,还是在最左边向左滑了,做出响应。这就要求对 ViewPager 的 overscroll 行为做出监听。

网上也有一些类似的轮子,但是我感觉做得真心复杂,而且都是为了实现轮播的,所以可扩展性并不强。因此我这里要做的,就是对 ViewPager 的overscroll 行为做出简单的监听并封装。剩下的,交给开发者自己去 do whatever you want 就好。

原理很简单,对手势做出监听即可。所以也算是对ViewPager 的overscroll 行为监听的另一种实现思路吧。

使用上,只需要把 ViewPager 替换成我这个就好,adapter 不需要改,也没必要改。因为我只会告诉你,你的 ViewPager 是否到头了,然后是哪边到头向哪边滑了,剩下的是你的 //TODO

欢迎各路大神对它进行拓展并发起 pr。

Demo

今天下班前被组里的小伙伴问了一个问题:

如果一个工程需要定义两个 flavor,每个 flavor 需要用一份单独的 AndroidManifest.xml,应该怎么配置?

这个问题,熟悉 gradle 的同学应该是能轻松搞定的。我们知道,gradle 在编译 apk 的时候支持给每个不同的 flavor 指定 src、res、甚至 AndroidManifest.xml 文件都没有问题。

首先我们定义两个 flavor:

1
2
3
4
productFlavors {
normal {}
meizu {}
}

为了让两个 flavor 分别取不同的 AndroidManifest.xml,我们在 src 下面建立一个叫 meizu 的文件夹,里面单独放置这个 flavor 要用的清单文件,就像这样:

然后我们配置 sorceSets 闭包:

1
2
3
4
5
6
7
8
sourceSets {
main {
manifest.srcFile 'src/main/AndroidManifest.xml'
}
meizu {
manifest.srcFile 'src/meizu/AndroidManifest.xml'
}
}

src/meizu/AndroidManifest.xmlsrc/main/AndroidManifest.xml的区别在于,前者删掉了 SecondActivity 的 action,理论上,如果我们编译 meizu flavor,那么在点击按钮之后,因为采用了 action 的方式来启动 activity,会因为 action 找不到导致失效。然而结果是这样吗?大家可以试一下。

结果是我们依然可以很顺利地跳到 SecondActivity…

为什么?

这就需要大家了解 gradle 在编译时,对 manifest 采用的 merge 策略。

引用一下 Ezio Shiki知乎上的一段回答:

Manifest可以通过Merge的方式合并多个Manifest源。通常来说,有三种类型manifest文件需要被merge到最终的结果apk,下面是按照优先权排序:productFlavors和buildTypes中所指定的manifest文件应用主manifest文件库manifest文件简单来说,manifest的merge会将每个元素及其子元素的节点和属性进行合并。

例如:

1
2
3
<activity
android:name=”com.foo.bar.ActivityOne”
android:theme=”@theme1”/>

1
2
3
<activity
android:name=”com.foo.bar.ActivityOne”
android:screenOrientation=”landscape/>

合并会成为

1
2
3
4
<activity
android:name=”com.foo.bar.ActivityOne”
android:theme=”@theme1”
android:screenOrientation=”landscape/>

不过

1
2
3
<activity
android:name=”com.foo.bar.ActivityOne”
android:theme=”@theme1”/>

1
2
3
4
<activity
android:name=”com.foo.bar.ActivityOne”
android:theme=”@theme2”
android:screenOrientation=”landscape/>

合并会产生一个冲突,因为都有theme,而theme的属性不同。

要了解manifest合并的更高级应用,查看Manifest Merger

所以,看明白了吗?简单来说,AndroidManifest.xml 文件在 gradle 打包编译的时候,不是你指定哪个,它就100%去用哪个的。

  • 首先,你的 main 里面必须要有一份基本的,不可以因为要分 flavor 就把 main 里面的删掉,否则会直接编不过
  • 接着,你要知道 Manifest 的 merge 关系,从你的 flavor 到 main,它是一层层合并的,合并的规则上面已经提到了。
  • 最后,如果我有一个 Activity,或者 Service,或者 Receiver,真的要用另一份 AndroiManifest.xml 里的怎么办?

关于这个问题,官方文档给出了我们答案:

tools:node markers

没错,我们可以使用 tools:node replace 来解决我们的问题。现在来修改一下 src/meizu/AndroidManifest.xml,在 SecondActivity 的声明里加上,如下图所示:

再编译一下这个 flavor,点击按钮,可以看到报错了。

现在已经没有对应的 Activity 来解析这个 action 了,也就是说我们为 meizu 这个 flavor 指定的 AndroidManifest.xml 总算“生效”了。

Demo 地址:https://github.com/shawnlinboy/Android-MultiFlavors

参考文章:

https://www.zhihu.com/question/22842123/answer/55675046

http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger#TOC-tools:node-markers

http://my.oschina.net/fallenpanda/blog/373183

Copyright © 2013 - Shen Lin - Powered by Hexo
- Ported theme GreyShade -