@SoloCompany 1.个人更喜欢 Scala 的设计哲学; 转换基本只有方法返回的是 Java 集合时需要用 scala.collection.JavaConverter 转换一下，或者 import scala.collection.JavaConversion, 将 Java 集合隐式转换为 Scala 集合，这点对开发者不透明感受比较明显之外，其他的时候感觉跟 Java 的互操作性还可以；

2.Android 上 Scala 标准库的体积是个问题，未混淆的情况下， 2.11.8 版本的 scala-library 有 50794 个方法， Dex 中占的体积为 5152 KB ，相比 1.0.5-2 版本的 kotlin-stdlib 有 5703 个方法， Dex 中占的体积为 1011 KB ，所以必须使用 Proguard 和 MultiDex 。我们的应用是因为要引入导航 SDK ， so 库使 APK 变大了约 10 MB 左右，相比之下，混淆过的 Scala 类库 (大部分的类可除去) 占用的体积相对于整个 APK 没有这么明显。当然，体积比较敏感的还是 Kotlin 更小一些；

3.抱歉，不知道的情况下就乱黑了 Kotlin 。只要性能和 Int 上的实用方法兼具，就是极好的。

@nevermind1998 抱歉，我也不是很清楚一般去哪里看。我知道这个问题，是因为我升级到 7.0 后，通知栏出现了很多 XXX 正在运行 这种划不掉的通知， Google 了一下得知的。

最早在 AOSP Issue 里面有讨论：

https://code.google.com/p/android/issues/detail?id=213309&can=1&q=Foreground%20Service&colspec=ID%20Status%20Priority%20Owner%20Summary%20Stars%20Reporter%20Opened

V 站上也有相关的讨论：

『升了 7.1.1 预览版，被国内应用恶心哭了』
https://www.v2ex.com/t/314216

『 Android 7.1 Beta 网络感叹号无法消除, 修改 captive portal server 无效』
https://www.v2ex.com/t/314526

感觉一般的新闻站不会有这种讨论，只是特定的人群会关注吧。

@nevermind1998 他应该指的是 Android 7.1 修复了可以启动前台服务而不显示通知的 Bug 。其实这个 Bug 在部分版本较晚的 Android 7.0 上也已被修复，我的 S7 Edge 的 7.0 就是这样。

@aliuwr 这是个哲学问题。你说的对，如果一开始国产 App 没有唤醒保活什么的， ROM 制作者也不会把 ROM 做成现在这样，那时国产的 App 和国产的 ROM 都会跟国外现在一样。可惜这只是个梦。

现在国产 ROM 杀进程杀的太狠了，其中当属小米和华为最狠，华为是锁屏几秒后杀进程，小米和华为划掉卡片和设置里的 FC 一样，现在 App 针对国产 ROM 基本上只有加入白名单才能存活了...

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 锁的。