@543400
总之强烈不推荐 TLC
随着数据变冷(一个单元存了数据，长期没有改动)，闪存的浮动栅缓慢的漏电会让这个单元的数据越来越难读出来。

这个问题和 P/E 寿命一样，在 TLC 最显著， MLC 次之， SLC 最不明显
同样的颗粒(850evo 和 50pro)，当作 TLC 用只有 2000P/E ，当作 MLC 用能有 5000P/E


在一般的 benchmark 三星的表现是很好的，但是 V2EX 上有人认为评测用的测试套件无法反映长期的性能衰退(比如脏数据，或者上面提到的数据变冷)

所以
如 @bin456789 所说
”这四个只有 370 是 mlc ，还能挑？“


http://www.anandtech.com/show/8792/transcend-ssd370-128gb-256gb-512gb-review/3
370 的性能确实比 850evo 好，那么有理由比更低档的(用了平面 TLC 的)750evo 好
而且 TBW 指标也不错

http://www.datarespons.com/wp-content/uploads/2015/05/Product-Sheet_SSD370-SSD340-SSD320_V10.pdf



比如这个测试用的 1TB 的 850pro ，它的 TBW 只有 300TB ，但是用 SMART 的 wearing level 指标
可以得到超出 6000P/E 的水平(wearing level 指标接近 7PB 时才掉光)
http://packet.company/blog

试了一下
它开始用 6.0 的权限机制了(target API 设到了 23)
然后开启时申请三个权限：

1 ，定位
2 ， external storage
3 ，用以获取 IMEI 的手机信息

看样子对于需要同时满足
1 ，使用支付宝
2 ，支付宝不能获取不必要信息(自然就是上述 1/2/3)
的用户，得这么对付它：

做一个 xposed 插件(比如请求在 Xprivacy 里增加这个功能)，劫持用于检测系统是否给权限的 API
ContextCompat.checkSelfPermission()
让它总是返回 true

我很好奇它在 iOS 敢这样（不给定位、通讯录就不运行）做吗？

@Jobin0528

Android 自带一个叫 DexClassLoader 的类，允许一个应用动态加载 dex
(上架 Google Play 的应用则不被允许做这样的动作，因为违反‘不得从 Google Play 以外的来源获取 /运行二进制代码’)

而对于 Android Runtime
动态加载 dex 意味着在加载时需要生成对应的 odex 文件(包含了原始的 dex 信息和编译成二进制代码的 oat 信息，所以比 dalvik 生成的 odex 慢得多， dalvik 版 odex 只是为了更快运行 dex 而做的以空间换时间的优化)

所以相同的硬件(比方说 Nexus5)，在安装应用 /OTA 后第一次启动系统显示正在优化(实际上就是在生成 odex)时， Android 4.4 比 5.0/5.1/6.0 都要快
Google 说它在 5.1 的时候对 dex2oat 做了改进，能进行多线程编译，从而减小编译时间

而负责编译 oat 的是 dex2oat


如 @VVSE 所说

@Paranoid
@learnshare
@chinvo

有礼貌的提问者在这个场合，如果感到对自己的英语没信心，而使用中文提出 issue 时，会说明这件事，并且尽最大努力，想办法让别人能看得懂

而实际上，这个 issue 的提出者给人的感觉是肆无忌惮的，想说什么就说什么(显得有些没教养)，那么后面来个吐槽，希望其使用英语并不奇怪。

@dsdshcym
在公开场合的缺乏教养的行为被丢到了 V2EX 围观


@regist
问题是在这个 issuelist 上，提交 issue 的这个人并没有高人一等
既然和别人是平等的，还要这么做，就像前面说的，被各种围观

算得上危害公共安全

@Havee
你这样说的是最好的
因为动物 /宠物没有人权，它造成的后果要由主人承担

@Troevil
おっしゃることがぜんぜん分かりませんでした
ここにほんごを使ってください

@xspoco Chrome Apps & Extensions Developer Tool

google 官方有一个应用可以审查所有扩展的行为

@apibits 那就用 9 楼打电话的策略吧

@dong3580 因为他们就是运营商自己

@xingwing
抱歉，是我弄错了，看成了“保留现有的以虚拟机形式存在的 win7 ”

可以的，虚拟机可以导出为 ovf 格式存档

@Seymer
亚马逊在 kindle 有这种意义上的合法后门的
如果你不喜欢，可以破解 kindle 的这个功能

问题是这么做就 kindle 本身没有问题
但在购买了书，再退款后，又保留了电子书本体，有退货时，只退款不退货的嫌疑

就像
@yoyoyoyo 说的，亚马逊的电子书没有出售拷贝的所有权，只是出售了使用权，导致亚马逊有权在退货后直接从 kindle 收回；而从技术上说，亚马逊控制了 kindle 上的固件 /系统，因此题主对此无能为力。

实际上， Google Play 与 Apple App Store,也有这样的后门
但到目前来说，这两个公司还没有出现过擅自主动删除用户设备上的内容

阿里小号的问题是阿里自己就会发广告短信，移动有一个小号业务，但不能接收验证码这种 106x 开头的号码的短信

@apibits
这个域名认识的，去工信部投诉过，没解决

m.apk.67mo.com

临时有个办法，换成 DNSPOD/阿里巴巴的公共 DNS ，不一定有用

这个事情出现以后
微软和苹果都对自己的软件做了更新，解决了 Office 2016 崩溃的问题
此外，世上没有"Office 2015"