@hairoy
@Leviathann
谢谢回复，一开始我确实是苦恼于 List 怎么没有 TreeMap 这样的根据比较器插入的数据结构。然后网上搜索一下之后无果后放弃了这个方向。
但是现在一想，我实际上还是应该把 TreeMap 来当 List 用，因为这可能是最理想的方式（在插入时确定好顺序，且 Map 有良好的索引规避了 ArrayList 的后移、LinkedList 的查询）。
虽然它可能会带来一些额外的小问题（比如时间戳一致的资源会不会导致覆盖），但这种我自己想办法规避一下就行。

@geelaw 嗯，你这种是一种很科学的方式。我最开始为啥没用这种是我考虑到我的实际需求还有一部分是：每获取到一部分图片、视频就要展示给用户看（因此有并发场景），那这个巨大的 ArrayList 是需要多次排序的有浪费。
但我刚刚突然想到了，这其实是每次排序了一部分，剩下的数据也是增量排序（把新数据放末尾就不会 UI 显示不对），实际上是没多少浪费的计算的。

然后我提问的困惑之一是：假如我在这种情况下硬要 ArrayList 、LinkedList 里二选一，ArrayList 在存在后移操作的情况下性能还是更好么？
然后我思考了一下您的想法，这样理解对不对：在有大量中间插入需求的时候，ArrayList 、LinkedList 的性能其实都很差。所以我们更应该做的是通过其他的方式（比如先插入再统一排序、或者 TreeMap 之类的方式）来规避这个问题，而不是强行比哪个差的方案更好一点。

Android 的整体趋势是越来越少的，那种普通的应用开发（主要配合后端渲染页面）的岗位会越来越少，对应的小中厂的岗位是越来越少的。
目前的行情我觉得是：稳定的需求还在所以对能力足够的资深开发环境还好，但是初级开发的岗位如上是少很多的。
所以我是不推荐新人入行 Android 了，当个人兴趣爱好还行。

算有的吧，我之前写了个摸鱼的小程序给群里朋友们内部玩，功能就是我写好了一个鱼池里面有很多鱼，稀有度不一样，分数文案不一样。每个用户可以每天摸一次。
基本上是一次写好也没 Bug 。因为需求清晰实现也简单，经验丰富一点的程序员问题都不大。

然后后来加了加成功能，可以特定时机触发特殊的效果，又加了限定活动等等，Bug 就多了起来。

程序的实现简单来说分为：需求到程序员的映射，程序员把这个需求到代码的映射，程序员本身对编程的掌控力度。
第一个映射出问题就是需求理解不一致；第二个映射出问题就是我们开发时自己考虑不周全，很常见；第三个就是我们的编程水平体现，但是需求足够简单的话问题其实不多。

所以要是这三方面问题都不大那自然没啥 Bug 。但是一旦迭代起来了，一二三部分都很容易出现问题。

关注登科很久了，在我眼里是一个很有创造力且分享了很多优质内容的博主。
不太理解但也能理解 V2 上那么多人喷，毕竟 V2 的主流情绪非常地极端。但博主在这里的“预览内容”我觉得少了点，让陌生人没啥付费欲望。

我还是挺好奇这类绑定微信账号的投票，有没有啥通用的刷票方案（淘宝也行但是好像搜不到）

@ltkun 硬件上是可以长按直接切换的。我当时就是误触了发现不对，然后想进手机设置看看模式对不对就发现了这个 Bug

我的标准：工作中实际运用到的或者有参考价值的就是合适的；只存在于面试题里会用上的就是造火箭。

上面有人提到是选拔考试，这是没错的，但是楼主的困惑是这个选拔的标准。靠“难题”、“偏题”或者各种底层原理，当然好筛选了，但是这暴露的是面试官自己没有能力去恰到好处地衡量面试者水平，就只能这样筛选了。

在我两三年经验的时候面过一波公司，当时感觉各公司面试官水平差异特别明显。我会的比较杂，但是有一个很牛逼的面试官能针对我各方面的点都提出问题，还能指出一些问题。而也有一些面试官，只会死咬原理，当时有一个地方我理解错了提出了质疑，说出了我的思路问他哪里不对，他就说“是我在面你不是你在面我”。

当然，往好了想，面试者与公司本来就是双向选择，面试官也能体现公司的氛围，既然不习惯说明确实可能不适合。

@ruixue 现在终端对云端服务器的依赖已经接近危险的边缘了，补充一个例子：
我在飞机上用小米降噪蓝牙耳机，开了飞行模式，通过手机都没法调整降噪模式。（虽然我觉得这个纯粹是它代码写的烂，是个 Bug ）

我差不多通勤时间，然后精挑细选后线下买了个雅迪。

1 、电瓶车对通勤的幸福感提升还是很多。相比共享单车快，相比自驾不堵车还没停车费，相比地铁不挤。缺点是很多骑电瓶车的素质不高，各种不遵守规则，体验比较差。

2 、我当初几经挑选后选了雅迪，线下。雅迪主要是朋友推荐，线下是因为我试图线上搜哪个型号靠谱发现没有，且线上的款式和线下差别太大。最后我是附近的雅迪店都去看了下了解了下型号和售价，最后选了一个。

3 、在新国标下，性能基本是过剩的，所以随便选不用在意性能。解限速也不是很方便，我考虑我也不差这点时间放弃了。二手我觉得没必要，毕竟也不是差这几千块钱。

身为一名 Java 或者说 Kotlin 用户，我的观念是这样的：
从需求本质看，我们需要的是对一个函数能清晰地得到它的正确状态下的返回值，和可能的失败情况。

那么，Java 的 try catch 是一个比较好的方案，它能不影响正确状态的返回值，并且错误状态能携带额外信息。

而另一种传统的错误码形式，它的返回更冗余，并且还需要对着看，想附加额外的错误信息并不那么方便。简而言之，表达力不够强。

嗯，所以我认为 Result 是最理想最兼顾的方案。关于这点的讨论可以参考： https://www.zhihu.com/question/330263279

我很乐意等比例降低，给我降低 20% 换成四天工作制。

@nnegier #4 也是 IDEA 的功能，你先输入 Locale.current 然后再输入 . 就有提示了，比如 var 、val 、when 之类的。用这个写 when 是我觉得最方便的

它之前稳定变贵后我就算了笔账改买电瓶车了，体验好了很多。

咋说呢，他们自己喜欢对标公交打车来标榜自己价钱不贵，但实际上看看它 App 的那些垃圾功能，就知道它钱都浪费到哪了。然后起用价不断上涨。

我觉得挺好的，很有意思的社会学观察，感受一个有钱任性的人真正掌控一个大公司、全球的媒体渠道（表述不太准确）时会做哪些，他做这些背后的心理是什么样的。

3 楼说的对，遇到问题的话 GitHub Action 之类的方案解决起来更麻烦。相对来说下个 Android Studio 还好一点，虽然各种版本问题也挺烦的。哪怕是熟练工也时不时被难受一下，因为遇到问题只能 Google 搜然后一个一个尝试方案。

举报本身我认为是没问题的。哪怕是诸多大家讨厌的那种举报翻墙或者 AO3 啥的(肖战的那个)，我觉得举报本身也是没问题。
但是结果是大家所不乐意接受的，那问题出在哪？很显然是上面。

但是上面又不能骂，骂了也会被屏蔽看不到。所以自然骂的都是举报者那边了。

@a0000 #29 这种是不是叫背心

是阿里么？
阿里的 P9 就这水平？我还以为 P9 都是人精，处理问题起来不会把矛盾放大，会两边都安抚一下的