Kotlin 实战翻译 —— 仿微信图片选择开源库ImagePicker

2017.10.27补充

在用Kotlin写项目的时候由于不能使用生成成员变量的快捷键，导致我写findViewById浪费了好多时间，后来才发现Kotlin对Android有更好的支持，可以完全不用写findViewById，连变量都不用自己声明，简直比ButterKnift都好用！
首先要在项目的build.gradle添加依赖：

buildscript {
    ext.kotlin_version = '1.1.51'
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:2.3.3'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
        classpath "org.jetbrains.kotlin:kotlin-android-extensions:$kotlin_version"//这个~
    }
}

其次在module的build.gradle中添加：

apply plugin: 'com.android.library'
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'//这个~

然后就可以在Activity等中直接使用布局中的id了，会提示你导包，这时候会有两个包让你选，一个R文件的，另一个就是我们需要的：
import kotlinx.android.synthetic.main.你的布局名字.*
例如这个textview：

在activity中可以直接使用id作为成员变量去使用

btn_preview.text = ""

虽然在java规范对成员变量的命名是驼峰式，但是我个人认为这里的控件使用：控件名缩写_功能名，的方式命名更好，能够一眼就知道这是一个控件，区别去其他的成员变量。

正文

自看了Kotlin的教程后，总感觉简短的示例代码并不能熟练掌握Kotlin，而直接从公司项目练手又又太过风险了。
正巧项目中用到的一个仿微信图片选择库ImagePicker出现了进图片预览界面crash的bug（android.os.TransactionTooLargeException），查找github发现作者已经声明不维护这个库了，issues中也有人提出类似的问题，但并没有解决。于是只能自给自足了，定位到问题是intent的extra数据过大导致了，其实就是从Grid界面到预览界面时会把手机中的所有图片信息，通过intent传递过去，而如果手机中的图片数量超过1200张，就会出现数据过大的crash。既然找到了问题的原因就有思路了，数据量过大，那我们就减少数据量，不管总的图片数量是多少，每次最多只传递1000张就不会过大了嘛～后来发现微信也是这样处理的，当图片数量过多时，只会取1108张图片，解决思路完全一致，只是最大的图片张数肯定是经过测试的一个最大值。
好像扯远了。。。其实就是既然作者不维护这个库了，那我就自己来维护，顺便通过用Kotlin重新实现来熟悉代码逻辑，并做一些能力内的优化工作。

ImagePicker原作者的库
我用Kotlin实现的ImagePicker
有没有人会说这不就是把代码clone下来，然后用as的Kotlin插件的”Convert Java File to Kotlin File "转一下不就ok了嘛。那不是自欺欺人嘛，既然是Kotlin的实战练习，当然是重新自己写啦，才能起到练习熟练的效果嘛。还有一点原因是我并不会按原java代码原模原样翻译，而是会对部分代码和调用方式做修改。

开始翻译了，首先是第一个界面ImageGridActivity

分析一下有哪些主要逻辑功能：获取手机中的图片，网格布局显示图片，可以切换图片的文件夹，选择图片，进入预览界面，完成图片选择。

• 获取手机中的图片

通过CursorLoader来实现的，原作者封装了一个ImageDataSource方便调用，关键代码：

//获取LoaderManager
LoaderManager loaderManager = activity.getSupportLoaderManager();

//注册 第三个参数为LoaderManager.LoaderCallbacks
loaderManager.initLoader(LOADER_CATEGORY, bundle, this);

//实现LoaderCallbacks的方法
public Loader onCreateLoader(int id, Bundle args)//创建Loader
public void onLoadFinished(Loader loader, Cursor data) //当Lodaer加载到数据时
public void onLoaderReset(Loader loader)//重启Loader时调用，一般无用

这个类就是翻译，修改仅仅是将initLoader单独抽到一个方法中

public ImageDataSource(FragmentActivity activity, String path, OnImagesLoadedListener loadedListener) {
        this.activity = activity;
        this.loadedListener = loadedListener;

        LoaderManager loaderManager = activity.getSupportLoaderManager();
        if (path == null) {
            loaderManager.initLoader(LOADER_ALL, null, this);//加载所有的图片
        } else {
            //加载指定目录的图片
            Bundle bundle = new Bundle();
            bundle.putString("path", path);
            loaderManager.initLoader(LOADER_CATEGORY, bundle, this);
        }
    }

Kotlin

class ImageDataSource(private val activity: FragmentActivity) : LoaderManager.LoaderCallbacks {
    
    fun loadImage(loadedListener: OnImagesLoadedListener) {
        loadImage(null, loadedListener)
    }

    /**
     * @param path           指定扫描的文件夹目录，可以为 null，表示扫描所有图片
     * @param loadedListener 图片加载完成的监听
     */
    fun loadImage(path: String?, loadedListener: OnImagesLoadedListener) {
        this.loadedListener = loadedListener

        val loaderManager = activity.supportLoaderManager
        val bundle = Bundle()
        if (path == null) {
            loaderManager.initLoader(LOADER_ALL, bundle, this)//加载所有的图片
        } else {
            //加载指定目录的图片
            bundle.putString("path", path)
            loaderManager.initLoader(LOADER_CATEGORY, bundle, this)
        }
    }

这样做的目的是让调用者明确做了哪些操作，第一种使用时new ImageDataSource(this, null, this); ,第二种使用时mageDataSource(this).loadImage(this)，第一种只知道new了一个对象，但是具体做了什么还得点进入看才知道，第二种就能明确知道我是创建了一个对象，并且还加载了图片。
这边还有一个Kotlin的小坑，java中loaderManager.initLoader(LOADER_ALL, null, this)可以传入null，但是Kotlin的NULL值检测机制导致这里只能传非null值，否则会报错，因此我只能传入一个空的bundle对象。

cursorLoader这边也一个小坑，当手机旋转屏幕，activity销毁重建，重走生命周期的时候，onLoadFinished(Loader loader, Cursor data)方法中的cursor还是第一次的对象，里面的值已经被取掉了,因此没有数据，甚至还会crash。原作者的处理方式是在Manifest文件中对应的activity添加android:configChanges="orientation|screenSize"属性，表示旋转屏幕不重走生命周期。实际上这个问题的本质是initLoader有个对应的destroyLoader方法，没有执行该方法的话，下次init相同id的loader时，还是会复用之前的loader，直接将上次的结果对象作为新的结果给出，可以看api源码当info != null的情况：

public  Loader initLoader(int id, Bundle args, LoaderManager.LoaderCallbacks callback) {
        if (mCreatingLoader) {
            throw new IllegalStateException("Called while creating a loader");
        }

        LoaderInfo info = mLoaders.get(id);

        if (DEBUG) Log.v(TAG, "initLoader in " + this + ": args=" + args);

        if (info == null) {
            // Loader doesn't already exist; create.
            info = createAndInstallLoader(id, args,  (LoaderManager.LoaderCallbacks