项目开发中，我们的 App 这个 Module 定义了3个 buildType：

1
2
3
4
5
6
7
8
9
10
11

buildTypes {
    release {
        buildConfigField("Integer", "HOST_TYPE", '0')
    }
    debug {
        buildConfigField("Integer", "HOST_TYPE", '1')
    }
    beta {
        buildConfigField("Integer", "HOST_TYPE", '2')
    }
}

之前有一个关于 MVP 的疑惑：1个 Presenter 能否对应多个 View？，在我的这篇文章中有写过。现在回过头来仔细想想，感觉有点不对劲：1个 Presenter 为什么会有对应多个 View 的需求呢？那篇文章中的使用场景是：

我有 A B C 三个页面，我有一个 Presenter，用来处理一个数据类型的增删改查，但是界面上，A界面只需要查询，B界面只需要删除，C界面只需要增和改。

我们都知道，Presenter 是用来抽离 Activity 或 Fragment 中的业务代码的，何为业务代码？就是这个页面涉及到的业务逻辑。关于数据的增删改查，那是 M 应该做的事，而绝不是 Presenter 该去处理的。 所以，Presenter 应当只对应一个 View，如果有界面复用 Presenter 的情况，那我们得考虑为什么会有这种情况呢？复用 Presenter 代表着业务逻辑是一致的，不同的页面理当有着不同的业务逻辑。当然，这里说的业务是简单，最小颗粒化的业务，如果一个页面十分复杂，Presenter 中集合了大量业务代码，那么在某些小的页面是有可能复用 Presenter 中的部分业务代码的。所以这种情况下，Presenter 会对应多个 View，那么这个场景使用上篇文章中的做法是可以的：复用 Presenter，将 View 抽离，利用继承实现多个界面的定制需求，但不会是上篇文章中的那种使用场景。

写过几个星期的 Kotlin 代码了，再也不用 findViewById 了，使用起来稍微简洁一点。今天小结一下，基础用法就不多说了，直接写几点我感触较深的。

空安全

当使用Java开发的时候，我们的代码大多是防御性的。如果我们不想遇到 NullPointerException，我们就需要在使用它之前不停地去判断它是否为 null。Kotlin，则是空安全的，我们可以通过一个安全调用操作符 (写做 ? )来明确地指定一个对象是否能为空。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// 这里不能通过编译. Artist 不能是 null
var notNullArtist: Artist = null
// Artist 可以是 null
var artist: Artist? = null
// 无法编译, artist可能是 null,我们需要进行处理
artist.print()
// 只要在artist != null时才会打印
artist?.print()
// 智能转换. 如果我们在之前进行了空检查,则不需要使用安全调用操作符调用
if (artist != null) {
  artist.print()
}
// 只有在确保 artist 不是 null 的情况下才能这么调用，否则它会抛出异常
artist!!.print()
// 使用 Elvis操作符 来给定一个在是 null 的情况下的替代值
val name = artist?.name ?: "empty"

1. A ?: B 等价于 if(A == null) B
2. A?.B ?: C 等价于 if(A != null) A.B else C

最近写过一个界面，涉及到排序。

用到了 Collections 中的 sort 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Collections.sort(mData, new Comparator<BookMemberReport>() {
    @Override
    public int compare(BookMemberReport lhs, BookMemberReport rhs) {
        if (sortFlag == SORT_FLAG_SALE_DESCENDING) {
            return (int) (rhs.saleAmount - lhs.saleAmount);
        } else if (sortFlag == SORT_FLAG_SALE_ASCENDING) {
            return (int) (lhs.saleAmount - rhs.saleAmount);
        } else if (sortFlag == SORT_FLAG_COUNT_DESCENDING) {
            return rhs.orderCount - lhs.orderCount;
        } else if (sortFlag == SORT_FLAG_COUNT_ASCENDING) {
            return lhs.orderCount - rhs.orderCount;
        }
        return 0;
    }
});

项目开发，引进了一个新的三方库，导致之前能运行的代码出现问题，错误堆栈：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

FATAL EXCEPTION: main
Process: com.lijia.app.catering.dev, PID: 29387
java.lang.NoClassDefFoundError: android.support.v4.animation.AnimatorCompatHelper
    at android.support.v7.widget.DefaultItemAnimator.resetAnimation(DefaultItemAnimator.java:514)
    at android.support.v7.widget.DefaultItemAnimator.animateAdd(DefaultItemAnimator.java:217)
    at android.support.v7.widget.SimpleItemAnimator.animateAppearance(SimpleItemAnimator.java:114)
    at android.support.v7.widget.RecyclerView.animateAppearance(RecyclerView.java:3243)
    at android.support.v7.widget.RecyclerView.access$800(RecyclerView.java:147)
    at android.support.v7.widget.RecyclerView$4.processAppeared(RecyclerView.java:436)
    at android.support.v7.widget.ViewInfoStore.process(ViewInfoStore.java:249)
    at android.support.v7.widget.RecyclerView.dispatchLayoutStep3(RecyclerView.java:3098)
    at android.support.v7.widget.RecyclerView.dispatchLayout(RecyclerView.java:2917)
    at android.support.v7.widget.RecyclerView.onLayout(RecyclerView.java:3283)
    at android.view.View.layout(View.java)
    at android.view.ViewGroup.layout(ViewGroup.java)
    at android.widget.LinearLayout.setChildFrame(LinearLayout.java)
    at android.widget.LinearLayout.layoutVertical(LinearLayout.java)
    at android.widget.LinearLayout.onLayout(LinearLayout.java)
    ...

最近随着 Google 的大力推荐，越来越多开发者开始使用 Kotlin 了。其实我对 Kotlin 的并没有很特别的感觉，它就类似于 Swift 相比于 OC，大量的语法糖着实能使写代码的效率变高，但是是否能左右 Android 开发的现状还未可知。我接触 Kotlin 的主要原因是：业务代码太无聊啦。相信很多开发者都跟我有同样的感触，在一个公司待久了，技术框架摸透之后，后面的开发就基本是纯业务开发了，写界面，写业务代码，对于技术提升没有什么实质的帮助，就是真正的码农。为了改变这一现状，我不断在新需求中使用一些新的技术，比如 RxJava、Retrofit 等等，说是新技术其实也不新了，都出来都很久了，只是自己在项目中没有用到，接触得不多。在新需求中引入这些技术，可以边开发边学习，解决写业务代码的无聊，还能拓宽视野，学习新知识。虽然不一定会成为主流，但学习一下总是没问题的，因此开始接触 Kotlin。这篇文章主要先讲讲 Kotlin 的配置。

Kotlin 插件

最新的 Android Studio 已默认装了 Kotlin 插件了，在旧版本可自己手动安装 Kotlin 插件。

习惯了用 LinearLayout、RelativeLayout 等布局，但是在某些界面的优化上这些布局很难做到。说下我项目中的实际例子：

一件商品有品名、数量、单价、金额等几条属性，要显示在一行。 注意，图中金额属性没有显示全，但这不是本文要写的内容。当文本过长显示不下，这是个历史难题。 本文要讲述的是如何利用约束布局来优化界面的显示。
看到图中，我们通长使用 LinearLayout 的 weight 属性，给每一列设置一个 weight，相信大多数人都是这么做的，就像这样：

之前的一篇文章Retrofit初识尝试用了下 Retrofit。说来惭愧，到现在才写这篇文章。由于项目中没有使用的缘故，一直停留在了解的程度。最近自己学习做了个Gank客户端，一点点学习当前主流的技术，今天研究了下 Retrofit 的源码，颇有感触，便记录下来。

使用

关于正常的使用，参考之前的那篇文章。这里再写一下结合 RxJava 的使用。

1. 定义接口：

   1 2 3 4 5 6 7 8

   public interface GankService { @GET("day/{year}/{month}/{day}") Observable<GankDailyResult> getDailyData(@Path("year") int year, @Path("month") int month, @Path("day") int day); @GET("data/{type}/{count}/{page}") Observable<GankCategoryResult> getCategoryData(@Path("type") String type, @Path("count") int count, @Path("page") int page); }

2. 初始化 Retrofit，生成代理对象：

   1 2 3 4 5 6 7 8

   Retrofit retrofit = new Retrofit.Builder() .baseUrl(BASE_GANK_URL) .addConverterFactory(GsonConverterFactory.create()) .addCallAdapterFactory(RxJava2CallAdapterFactory.create()) .client(okHttpClient.build()) .build(); mService = retrofit.create(GankService.class);

3. 调用接口：

   1 2 3 4 5 6 7 8 9 10 11 12

   GankRequestManager.getInstance().getCategory(type, PAGE_SIZE, mPage) .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(new Consumer<GankCategoryResult>() { @Override public void accept(GankCategoryResult gankCategoryResult) throws Exception { mPage++; if (mView != null) { mView.showList(type, gankCategoryResult.results); } } });

最近做收银机上的软件，之前都是用无线调试，有个功能需要要测一下断网的情况，然后断网后无线调试就不能用了。然后接上 USB，通过 Android Studio 能看到设备但无法使用。

然后通过 adb devices 能看到设备，但是提示权限不允许，并且提示到官网来解决。

跟到网站中可以看到

如果您在 Ubuntu Linux 上开发，则需要为想要在开发中使用的每一种设备类型添加一个包含 USB 配置的 udev 规则文件。

这个便是问题所在了，跟着描述进行操作后面便可以使用 USB 调试了。

之前写过一篇Gradle多版本管理，主要是通过productFlavors来控制产品版本。这篇文章将结合buildTypes来说一下多版本管理。
在正常开发中，我们一般会有至少 2 个环境：Debug、Release，即测试环境和生产环境。显然这 2 个环境要用 2 套不同的数据，那么在我们的 App 里必然就需要有个地方来控制这个环境。当然，我们可以在 Debug 的时候用 Debug 环境，然后当要发版时手动改成 Release 环境，但是这很麻烦，很难排除忘记修改的情况，那么等待重新编译将是个很漫长的过程。其实Gradle可以很好的解决这个问题：利用 buildTypes 来控制编译类型。
buildTypes 默认会有 debug、release 2 个类型，当然我们还可以添加自己的。比如有个beta环境，用于外网测试。当对接一些三方平台的接口时，有的只能用外网，那么只能整一套外网的测试环境了，比如美团外卖。好，现在假设我们有 debug、beta、release 3 个 buildTypes，然后 pad、phone、custom ３个 productFlavors，接下来就是针对这些环境做配置了：