大概率出个 iPad air mini 吧，极小概率会有 iPad pro mini

自己能搞清楚自己的长板和短板就好，销售 /售前所需要的技能和开发差别挺大， 如果分析下来觉得自己适合做销售，也有兴趣，那就转呗。

之前还种草过这个搭载 HBM2 的 5600M，看来还是用着 2018 款安心等 arm 版吧

要遇到合适的平台啊，不然可能一辈子都不会有那个意外收获

@laoyur 语言环境中有儿化音的朋友看到了也难受。。。
儿化音更多在口语中体现，写出来就别扭了。

还是先尽可能了解回去的具体情况，大家对于回家的定义一般是钱少事少离家近，工作清闲不背锅，如果属实我觉得是 OK 的，如果回去做背锅侠就得好好掂量掂量了。。。

前途堪忧？

PendingIntent sentPI = PendingIntent.getBroadcast(context, 0, new Intent(SENT), 0);

这个 new Intent(SENT)可以调用 putExtra 方法存一些数据，可以试试呢
然后在 onReceive 通过 arg1.getExtra 取到对应的值，不知道是否可行

代码里面直接 killProcess ？

挺好，吸取教训，还好没说出什么敏感内容。
不过这老板。。感觉段位也不高的样子，听了你同事的报告直接就会上原话说出来。。。

不想透露的信息就空着，如果对方追问就含糊的说一下，对方要是细问，那就反问他问那么细的目的

梦回贴吧的感觉

把大佬的回答直接粘过来吧

作者：RednaxelaFX
链接： https://www.zhihu.com/question/52900051/answer/132583244
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

假定题主说的是下面三个层面的调优的头两种情况：
1.对 VM 的配置参数调优（例如 GC 参数）
2.对应用程序自身的代码调优
3.对 VM 自身的实现调优

(2)的话无论什么语言什么环境都好，追求性能的人肯定都有在做。Java 和.NET 都有好用的 profiler 可以帮助这方面的调查和调优。有时候参数调优还不够的地方，也只能自己改自己的应用代码来解决问题了。请看一个经典案例： https://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector

(3)的话，CLR 还没开源的时候，也无从调起。倒是有不少人给 Mono 贡献改进性能的 patch，也算是广义上“.NET”的 VM 实现层面调优吧。在 CoreCLR 开源后，也有不少人给 CoreCLR 贡献各种 patch 呢，包括“调优”。.NET 码农们以前时不时会中招的一种地方是程序进入 GC 的耗时（ time-to-GC ），也就是从 CLR 说“我要开始做 GC 了”到“真正开始做 GC”之间的耗时。这里主要开销来自请求所有应用线程暂停（ SuspendEE ），这些线程要多久才完成对该请求的响应。听说过这个过程中会发生“250ms 的倍数的等待时间”不？请跳传送门： http://blogs.microsoft.co.il/sasha/2009/07/31/garbage-collection-thread-suspension-delay-250ms-multiples/ 像这种问题就是不进到 VM 内部做修改的话无法解决的。

(1)的话，其实就算当年 CLR 还没开源的时候，CLR 也是有调优参数可以配置的呢。最经典的就是选择试用 Workstation GC （ WKS GC ）或者 Server GC （ SVR GC ）。见过<gcServer>参数不？后来可以配置使用 Concurrent GC 、Background Workstation GC 、Background Server GC 等。用户还可以在代码里通过 GCSettings.LatencyMode 属性来影响 GC 的行为。看，调优参数列表之一： https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/?redirectedfrom=MSDN

不过 CLR 跟 HotSpot VM 在配置上有一个显著的区别，就是 CLR 不需要用户指定一个“GC 堆的最大大小”。这跟 CLR 的 GC 堆的基础设计思路有关系。HotSpot VM 的 GC 堆一定要使用连续的虚拟地址空间。VM 在启动的时候会一口气 reserve GC 所需要的整个地址空间，然后再按需 commit 。-Xmx 会参与到 GC 堆最大大小的计算中。CLR 的 GC 堆则是分段式的（ segemented ），GC 堆所用的空间会一个个 segment 分配，用满了一个再去分配一个新的； segment 不需要在连续的地址空间上。这样 GC 堆可以按需自动增长或者缩减，可以一直增长到耗尽虚拟地址空间或者达到配额。CLR 这种分段式 GC 堆的好处是，在 Windows 上，特别是 32 位 Windows 上，虚拟地址空间中用户程序可以用的部分是比较零碎的，想要用到尽就不能对“连续的地址空间”有太多要求，这种条件下 CLR 跑在 Windows 上就可以充分利用资源。而且这样一来，用户就不用头疼实现想好要配置多大的堆给 CLR 用了。反正它需要用多少会自己去增长。这用户体验就比绞尽脑汁想个好-Xmx 要爽。这种做法的坏处…怎能没有坏处呢。坏处也有若干。其中一个就是在这样的堆上实现的分代式 GC 的 write barrier 效率会比 HotSpot 那种用连续地址空间的要差一些。而且 segmented heap 实现起来也稍微复杂一些。

帮顶~

嗯哼？欧开？

航空总医院的口腔，去过几次还蛮不错的，虽然不是三甲。

《算法》中关于红黑树部分的内容我之前也看的很困惑，因为旋转的逻辑和别的地方看到的不太一样，比如 https://www.cs.usfca.edu/~galles/visualization/Algorithms.html 这个可视化算法的网站，后来干脆放弃《算法》，转向别的资料了。

根据目前 appstore 里常见应用适配 ipad 的情况反推，不是。

cpu 跑分或者拷机呗，纯运算应该不涉及 ssd