Android Weekly Issue #241

January 22nd, 2017
Android Weekly Issue #241
本期内容包括: 经典导航模式Master/Detail的设计和实现; APK的大小讨论和增量下载大小的预估工具; Model-View-Intent模式的讨论和实现; 分多个modules对build时间的影响; 测试中能够利用的一些Android特有的接缝设计(manifest, build config, resource).

ARTICLES & TUTORIALS

Case Study. Master/Detail Pattern Revisited

Master/Detail是一种经典的导航流, master屏包含一个list, detail显示某一项的详细信息. Android Doc.

作者讲了他适配多种屏幕(包括平板)的设计, 以及简单的实现.

Tracking app update sizes

以前作者有一系列的文章讲过apk的组成以及如何减少apk的大小.

事实上app的大小可以分下面四种:

提交到Google Play的APK文件大小.
初始的下载大小.
在设备上的安装大小.
更新下载大小.

之前的一些文章可能都在讨论如何减少初始的大小, 但是大多数情况用户可能只安装你的应用一次, 之后就只是从Play Store更新, 所以应用的更新大小也是很重要的.

事实上Android Studio(2.2+)改善了打包apk的机制, (apk packaging), 使得每一个build都尽可能地相似, 这样Play Store就能计算出一个较小的delta更新. 另外, Play Store也引入了新的算法, 比如最近的File-By-File patching, 同样也有效减小了更新的大小.

所以我们要注意的就是不要介入和干扰当前Android Studio和Play Store的这些优化, 比如不要用自定义的ZIP加密设置来自己压缩APK. 也不要用Zopfli来再次压缩APK.

Play Store上会显示应用的下载大小, 如果用户已经安装了, 则显示的是更新大小.

对于开发者来说, 如果能在发布前知道这些信息就更好了, 所以作者他们开源了这个库: apk-patch-size-estimator

这是一个命令行的工具, 可以集成到CI里, 也可以手动比较两个apk文件.

这个工具实现了当前Play Store的算法, 可以帮你估计出初始的apk下载大小和更新下载大小.

(注意下载大小和apk文件大小不同因为Play Store可能会做进一步压缩.)

同样, Android Studio中也有一个图形化的 APK Analyzer工具, 可以做apk的比较, 让你看到到底是哪一部分的尺寸增长了.

Reactive Apps with Model-View-Intent - Part 2

上一篇文章讨论了一个好的Model层可以解决很多问题. 这篇来介绍Model-View-Intent模式.

Model-View-Intent模式

Model-View-Intent模式是在一个JavaScript的framework cycle.js中提出的.

view-model-intent

intent(): 这个方法接收用户输入, 然后输出将会作为参数传给model().
model(): 接收intent()的输出作为自己的输入, 来操纵Model, 这个方法的输出是一个新的Model(状态变化). 所以它不应该更新一个已经存在的Model. 因为我们想要不可变性. 注意这里是唯一一个允许创建新Model的地方.
view(): 接收model()方法返回的model作为输入, 然后将其展示出来.

用RxJava连接

我们希望数据流是单向的, 于是我们用了RxJava, 它很适合这种基于事件的编程, 在这里主要是UI事件.

作者之后举了一个实现的例子, 在这个例子中他们的Model层用了ViewState后缀. SearchInteractor用来执行搜索, 返回的结果是Observable<SearchViewState>.

这个模式中定义的View接口里包含了render()方法, 根据传入的状态model显示UI; 这个View接口其实还包含了intent()的方法, 返回的是一个Observable, UI中用了RxBinding.

最后一步就是, 如何将View的intent和业务逻辑联系起来呢? 这里用到了一个额外的组件: Presenter.

这个Presenter看起来像这样:

public class SearchPresenter extends MviBasePresenter<SearchView, SearchViewState> {
  private final SearchInteractor searchInteractor;

  @Override protected void bindIntents() {
    Observable<SearchViewState> search =
        intent(SearchView::searchIntent)
            .switchMap(searchInteractor::search) // I have used flatMap() in the video above, but switchMap() makes more sense here
            .observeOn(AndroidSchedulers.mainThread());

    subscribeViewState(search, SearchView::render);
  }
}

MviBasePresenter是mosby中的一个类.
这个类做的事情就是当View第一次attach到Prensenter上时, 调用bindIntent()方法将来自view的intent绑定到业务逻辑上, 只有第一次会绑定, 当View再次attach时不会发生.

而subscribeViewState()方法则处理了定于管理, 避免内存泄露(具体原因见原文).

How modularization affects build time of an Android application

一个Android应用至少有一个application module, build这个module之后得到一个.apk文件.

application module之间不能相互依赖, 它只能依赖于library, build library module的结果是得到一个.aar(Android Archive Library)文件.

build的过程可以粗略分为5个阶段:

1.准备依赖.
2.Merge资源和manifest.
3.编译. 从annotation processors开始, 把源码编译成字节码.
4.后处理. 所有以transform开头的gradle tasks都属于这个阶段. 其中最重要的是transformClassesWithMultidexlist和transformClassesWithDex, 它们生成了.dex文件.
5.打包发布. 对library来说是生成.aar, 对application来说是生成.apk.

我们都知道gradle只有在输入变化了的情况下才会重跑task. 而且如果一个module没有变化, 也不会被重新build, 那么就出现了一种假设: 多个module应用的增量build要比单个module的快, 因为只有被改变了的module才会重新编译.

作者想验证这种假设是否正确.
他用的工具就是:

./gradle assembleDebug --profile

做了一系列实验之后证明这个假设还是有道理的.

实验过程中的一些发现:

1.当应用被拆分为多个modules之后, 改变application module中的代码, build时间会减少; 但是library中的代码, build时间反而会增加. 这是因为library build的时候debug和release的tasks都执行了(并不知道为什么).

当library module被这样添加的时候:

dependencies {
    compile project(path: ':app2')
    compile project(path: ':app3')
}

不管app当前的build type是什么, app永远依赖的是library的release版本.

这是一个Gradle当前的限制. 参见Library-Publication.

幸运的是, 我们可以改变这一行为:
首先在library中添加:

android {
    defaultConfig {
        defaultPublishConfig 'release'
        publishNonDefault true
    }
}

让它也可以发布debug版.
在app中依赖的时候:

dependencies {
    debugCompile project(path: ':app2', configuration: "debug")
    releaseCompile project(path: ':app2', configuration: "release")

    debugCompile project(path: ':app3', configuration: "debug")
    releaseCompile project(path: ':app3', configuration: "release")
}

这样debug和release都只依赖各自对应版本的library了.

2.不管我们改动的是library中的代码还是application中的代码, application module永远都会被重新编译, 所以减小app module的尺寸很有意义.

3.上面这些都是library之间互相独立的情况, 如果library之间还有相互依赖, 那么build时间也会变长.

4.如果应用超出了DEX的方法数限制, 用了multidex, 也会增加build时间, Android 5.0开始使用了一个叫做ART的runtime, 在这方面有一些优化, 可以减少build时间, 所以我们可以在开发的时候设置最小API是21: Optimize multidex in development builds.

Exploiting Android Seams for Testing and Flexibility

如何让Android应用代码可测试? 答案是创建一些接缝. 这篇文章中, 作者将一些Android特有的接缝, 来让我们的应用更加灵活和易测.

Manifest接缝

使用Merge rule markers可以方便地更改manifest.

比如在build variant是mock的时候, 由于我们在src/mock/AndroidManifest.xml里这样写:

<!-- src/mock/AndroidManifest.xml -->
<activity
  android:name=".StubConfigActivity">
  <intent-filter>
    <action android:name="android.intent.action.MAIN"/>
    <category android:name="android.intent.category.LAUNCHER"/>
  </intent-filter>
</activity>
<activity
  android:name=".MainActivity">
  <intent-filter tools:node="remove">
    <action android:name="android.intent.action.MAIN"/>
    <category android:name="android.intent.category.LAUNCHER"/>
  </intent-filter>
</activity>

所以在build mock的时候, 启动Activity会被替换成上面这个StubConfigActivity.

还有更多的可能值得探索, 比如你可以替换filter的内容, 从而改变默认intent启动的Activity.

BuildConfig接缝

在gradle中可以根据不同的build variant来定义BuildConfig中的变量值.

默认情况下BuildConfig中会包含一些有用的变量比如DEBUG和FLAVOR.

我们可以创建更多额外的变量:

productFlavors {
  mock {
    buildConfigField('Boolean', 'MOCK', "true")
  }
}

一个简单的应用case是我们可以定义不同的base url:

defaultConfig {
  buildConfigField('String', 'API_BASE', '\"api.awesomecompany.com\"')
}
productFlavors {
  sandbox {
    buildConfigField('String', 'API_BASE', '\"localhost:8080\"')
  }
}

Resource接缝

不同build variants的资源就像manifest一样, 最后会被merged. 但是对于资源我们没有markers可以控制它们如何merge.

我们可以利用默认的merge行为: Resource merging.

优先级是这样的:

build variant > build type > product flavor > main source set > library dependencies

所以我们可以把默认的资源放在main里, 然后在特定的build variant再创建一份覆盖它们.

Android Weekly Notes Issue #241