Clojure 不了解。 Scala 的标准库的集合部分把 Java 的重新发明了一遍，其他新加了一些方便使用的类，如元组让函数可以便捷地返回 2 个值， Source 类让网络请求或文件读取简略为 1 句话。

但它的集合分为可变和不可变两种，不可变集合每次操作都会产生一个新的集合， 然后把原来的集合丢弃掉，占用空间和效率方面会差一点，不可变集合与 Java 中的比较相似， Scala 分别针对它们做效率上的优化，例如不可变集合添加一个元素时，返回的新集合会复用前 n - 1 个元素的空间，不会拷贝一次到新集合里。另外他的集合操作兼顾了 OO 和 FP 两种风格，既有 map, flatMap, filter, collect 等 FP 风格的操作符，也有 OO 风格的 take, takeRight (返回头 n 个或 尾 n 个）等操作符。

另外，不同于 Kotlin 这种因为 Java 原始类型有很多弊端就一刀切的都用 kotlin.* 类不同， Scala 虽然也是 scala.Int ，但他在运行期会尽量是一个 JVM 上的原始 int ，尽量避免装箱以提高性能。同时 Int 可以被隐式转换为一个 RichInt ，提供了很多实用的方法，这是性能与实用性兼顾的例子。

Scala 自己重新写的优势我感觉是不把人当傻子吧，不是限定使用一种方式完成一件事。而是提供很多选择给你自己选，然后分别对每一种进行特定的优化，集合和对待原始类型的态度就是例子。

缺点是可能有运行时开销和体积的 overhead ， Scala 被编译为 Java 字节码，受限于 Scala 在 JVM 上的实现方式，生成的 class 文件众多，每个 class 里面自动生成的方法也比 Java 多很多。另外 Scala 的标准库体积过大。这两点在 Android 上其实很致命（有 ProGuard 会好一点）。

scala-native 看起来很不错，能够在 bare metal 上运行 Scala ，感觉如果成熟的话应该会很厉害。这样 Scala 就有了编写接近底层的一些东西的可能性。

另外 Scala 的集合系统也是一大亮点，支持的函数式操作非常多，远比 Java 8 的 Stream 丰富。

@cuebyte 1.Scala 作为一门特性较多的语言，学习曲线较为陡峭，这是对的。但其实学习一门新的语言，就是期望工作效率的提升能够 cover 掉学习的时间。 Kotlin 的语法与 Java 差别较大，跟 Scala 反而有点像。而 Kotlin 一样需要学习。 2.这是 OO 与 FP 混合语言的必然结果，除非是 Java 纯 OO 或者 Haskell 纯 FP ，否则代码中很难避免命令式与函数式两种编程风格并存。 这点 Kotlin 和 Scala 是一样的。

只是想说用 Kotlin 不如用 Scala ，目前我们用 Scala 开发 Android ， Kotlin 只在 1 个周边工具中用到。项目中用到了很多 Kotlin 不具备的特性。例如 Scala 的隐式转换， Double 被转换为一个自定义的 MyDouble ，里面有一个 dp 方法，将 dp 数转成 px ，我想表达 48 dp 代表多少 px ，只需要像字面上一样在代码中写下『 48 dp 』就可以了，语义非常直观。

判断一个集合是不是空集，其他语言可能没有办法只用一个函数实现，因为 List, Set, Map 没有一个公共的父类或实现相同的接口，但他们都有 isEmpty 方法， Scala 的反射调用可以 def isEmpty(o: {def isEmpty: Boolean}) = o == null || o.isEmpty 只要 o 有一个 isEmpty 方法就可以了，并不要求 o 的类型。

所以说更方便几乎是一定的，因为 Scala 几乎可以说是 Kotlin 的超集， Kotlin 有的 Scala 都有。

Kotlin 的语言设计很多地方看得出借鉴 Scala 、 Swift 的痕迹，例如变量、参数的类型是后置的。

为什么不用 Scala ？个人认为 Kotlin 只是阉割版的 Scala 而已，基本是 Scala 的一个子集。 Kotlin 的优点（代码简洁，与 Java 100% 互操作性, ...）基本 Scala 都有，但 Scala 的很多特性 Kotlin 不具备：隐式转换，反射调用，高阶类型，存在类型，协变 / 逆变， Macro ，模式匹配。

我猜大概是设了一个 deleteIntent ?

Intent i = new Intent(mApp, MainActivity.class);
i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
PendingIntent pi = PendingIntent.getActivity(mApp, requestCode, i, PendingIntent.FLAG_UPDATE_CURRENT);
new Notification.Builder(mApp).setDeleteIntent(pi);

这两种方法是一样的。单进程情况下， Application 只有一个对象， static 也只有一份。多进程情况下，每个 JVM 都有一个 Application 被创建，不同 JVM 中加载的类在内存空间上彼此独立，即使是 static 也是有多份的（因为在不同的虚拟机）。

如果只需要内存缓存的话， static 是可以的，用起来还简单一些。目前 Android 使用的 JVM 并没有类卸载 (class-unloading) 机制，类一旦被加载进来，只要进程不死，是不会卸载掉的。从这点上看， Application 的生命周期和 static 是一样的。

对于后台返回的用户信息，应该是要做持久化的。否则 App 杀掉后，登录信息会丢失。可以用 JSON 化后放入 SP 等方法。

https://gradle.org/gradle-download/
https://services.gradle.org/distributions/gradle-3.2-all.zip
用下载工具下载解压，再指定使用本地的 Gradle.

用一个 HashMap<Integer, Boolean> 存放 adapterPosition 与 checked 的对应关系；
onBindViewHolder 里设置 mCheckBox.setChecked(mMap.get(holder.getAdapterPosition))；
重置时就遍历 Map 全部设置为 true / false ，再 notifyDataSetChanged()。
这样不优雅，期待更好的解决方案。

觉得 Google 的命名方式很好:
private int mResId;
private static int sResId;
private static final int RES_ID;
void method() {
int resId = 0;
}
这样什么类型的变量一眼就可以看出来.

@incompatible 静态方法 Method.invoke(target, args) 中的 target 传入 null 即可。

@ecpay openSUSE 对应的是 Fedora 吧

Scala(逃

1.还原出厂设置只是清除了 data 和 cache ，如果是改错了 /system 下的权限，还原出厂设置是无效的，要刷 ROM ；
2.刷第三方 Recovery 如 TWRP 后，刷非 MIUI 系统 如 CM ，自然没有小米账号的问题。小米 3 应该是没有 BL 锁的。

学原生，少年。如果你要做一个精品 App ，或者用户体验在 90 分以上的 App ，原生是唯一的选择。

https://github.com/googlesamples/android-Camera2Basic/blob/master/Application/src/main/java/com/example/android/camera2basic/Camera2BasicFragment.java 看看这里？

project build.gradle ：

classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'

module build.gradle ：

apply plugin: 'com.neenbedankt.android-apt'

compile 'com.google.dagger:dagger:+'
provided 'org.glassfish:javax.annotation:+'
provided 'com.google.dagger:dagger-compiler:+'

如果启用了 Jack 的话（ jackOptions.enabled = true ）， project build.gradle classpath 中的 apt 要去掉， module build.gradle 中的 apply plugin: 'apt' 也要去掉， dependencies 中的 apt 要改为 annotationProcessor 。

如果没有启用 Jack 编译器，把日志贴上来看看。

@honeycomb 真的，最近碰到这个问题，测了 EMUI 和 MIUI ，他们的系统即使是 6.0 的，权限管理还是采用 4.4 时期他们自己做的那套拦截 API 调用的方式，并不响应 requestPermission 方法（ checkSelfPermission 会直接返回 PERMISSION_GRANTED ），等真正用到权限的代码执行时才会弹框询问。跟 AOSP/CM 和国际品牌手机的系统表现的很不一样，这些是要开发者在调用前就检查并申请的。个人反对这种看似有利于使用者，实则破坏 Android 生态的行为。