作者的思路真的是不错。实际效果还没用过，但是从理论上来说，只要是非系统级的 Xposed 插件（即非对系统进行修改），应该都是可以直接拿来用的。但是这样方式应该是比较容易被 Anti （相比较原始 Xposed 而言），进程名什么的，能够察觉的点比较多。因此对于一个国民级应用，例如微信这样的，如果其不想，基本上不太能在 VirtualApp 里运行。

我感觉现在事实标准就是 Spring，而 Java EE 已经是比较边缘的名义标准，但几乎没什么用。

@flyingHagan 可逆加密 == 明文
我感觉你说的是信息摘要算法。
按这么说，那不是一竿子把对称密钥 /非对称密钥算法都给打翻了？

信息摘要算法从来都不是用来加密的。不可逆算哪门子的加密，原来的信息都没了，这加密毫无意义。

没有哪里好，每个人的选择不同而已。听歌本来就是为了放松的，没必要为自己找理由，或者找出点优越感来。
喜欢 QQ 就用 QQ 音乐，喜欢虾米就用虾米，喜欢网易就用网易。
哪来那么多理由呢？

从没用过，但是碰到过一个海信的小哥，听他说起过(那位小哥说海信正在搞这个墨水屏)：

首先墨水屏最大刷新率很低，那位小哥说是不到 20Hz，因此对于画面变化比较丰富的场景其实几乎不可用，给人的闪烁感觉很强烈。

其次，墨水屏（几乎？）不用电，这个不了解，那位小哥告诉我墨水屏不同于一般的显示屏，本身并不发光，依靠反射光显示，因此对人眼比较友好。

最后，墨水屏似乎只有黑白。

所以，可能适用场景并不丰富。低刷新率与黑白比较大的限制的目标应用场景。

最大的冲突点是免费。

人家没广告，也不限流量，你还不用给钱。那人家干嘛搞这么一个服务呢。是爱？是责任？还是信仰？

但凡只要愿意花一点钱，这个题就解了。

所以哪里买到的是这种有活动的商品呢？
https://utc.sprite.com.cn/prize/Index 最后导航到 JD，但是京东描述页上并没有说明产品的包装

https://item.taobao.com/item.htm?id=555537893117

大概你需要的是这种？可以尝试搜搜看，“可移动 桌”

”但是别摆明了一杆子打死一群人。还是有很多人付出了汗水，值得尊重“

部分赞同吧。

从鸡汤的角度看，没毛病。

可是...对面是万恶的资本家，资本家根本不在乎你是否付出了汗水，他在乎的是，你是否给他创造了收益。如果没有创造收益，这个汗水将毫无意义对于资本家而言。

淘宝曾经尝试举报过一次，其实没有用。

淘宝，甚至整个阿里系的逻辑是，需要消费者举证商品系假冒、存在质量问题，如消费者无法举证则维权不成立。由此导致商家售假成本极低，最坏的结果是承担往返运费几十块钱而已，与其售假的收益相比，可以认为是九牛一毛。

相对于商家，至少我认为消费者是相对弱势，为何需要弱势群体承担举证责任？当然，这可能有点 [我弱我有理] 的意思了。但是反过来说，如果商品确系正品、无质量问题，商家应该更容易举证，进货凭证等都可以辅助证明，而消费者需要承担高昂的维权成本。试想，如果商家连最基本的进货凭证都没有，商品来源都无法提供，又怎么可能商品是所谓的正品呢？

虽然我也觉得这个修改功能比较鸡肋，但是可能京东有自己的考虑。

一个比较典型的原因就是京东会根据收获地址就近仓库发货。如果修改了省份、地市，与其相关的仓库需要取消订单，并且通知更改地址后所属的订单发货。在限定省份、地市，不变后，整个配送流程只需要变更最后一公里的落地配送站。

因此，京东的初衷也许就是希望用户在这种情况下，直接取消订单，然后重新下订单？

https://i.loli.net/2018/02/26/5a92e1354217a.jpg

如果是 Plus 会员 585 - 80，基本上接近历史最低价 499 了。如果没有优惠券，买就很不合算了。

另外我这里是可以领取这个优惠券的。

@Suclogger 感谢送上。

检查一下，在退出之前是否 tomcat 占用了大量资源？如果是的话，可能是由于系统资源不足导致系统杀进程，所以 tomcat 没有任何提示。

之前碰到过一个实习生写的，文件句柄只管开，没有关，然后跑着跑着，tomcat 就被系统杀掉了，也是没有任何提示。

感觉 Kotlin 虽然很多都是语法糖，但是糖很好吃呀。写起来也比 Java 简洁很多。

我现在是不论个人还是公司项目。不论 Android 还是传统 Java 项目，只要是新开的，都是 Kotlin。反正是兼容 Java 的，学习成本也很低。别人不愿意用 Kotlin，Java 反正也是一样可以用。

.....这就是响应式布局而已。与你的浏览器的宽高有关。无所谓桌面与移动端的区别。

你在电脑上用浏览器打开，然后把浏览器宽度缩小，也能看到像手机上那么的界面了。连页面都不用刷新。

仅此而已。

新年快乐。我要去登机了。

app_process 是以当前用户 fork 出来的，因此权限等同于当前进程。所以不存在你说的情况。这和 linux 的权限机制是一样的。

例如 alipay 通过网络下载回来一个 dex，然后运行，这个 dex 的权限至多与 alipay 一样，不会更多。同样这个 dex 也在 alipay 的虚拟机内，不过其可以申请作为一个独立进程运行，但这与动态加载无关，且作为独立进程运行也是与父进程一样的权限。android 本身就支持这种操作，只需要在 AndroidManifest 中指定 process 参数即可。

同理，如果你在 adb shell 下手动使用 app_process 启动一个 dex，则该程序的权限与你 shell 权限一致（若你 shell 下是 root 权限，则启动的应用也具有 root 权限）。例如黑域，就是利用这种方式，启动一个 shell 权限的 daemon，以获得普通应用程序以外的权限。但这是需要人工干预的，应用程序并不能自己获得额外的权限。

以上是建立在 Android 权限体系的情况，如果有存在系统级的越权漏洞，那么以上都不存在了。如果存在这样的漏洞，说什么也白搭，用户侧根本无能为力，只能坐等 Google 或者 OEM 修复。

@fengleidongxi V2EX 不就是根据 request headers 来判断设备类型的么？有啥黑科技？我这试了试改变这个值就返回的不同页面。