放假狂魔小学生 放假狂魔小学生
TIAWTCTW,JCOM.
关注数: 96 粉丝数: 278 发帖数: 13,283 关注贴吧数: 33
撸了个16A02的平面图 初步估算，16A02站立面积235.35平方米，座位356个，按6人站1平方米定员计算，结果为235.35*6+356=1768人。 实际定员基本跟标准6A比较接近了。
按照里程来描一下示范区线的三条支线 此次公开了示范区线的三条支线： 1、单元1：芳乐路-虹桥，7.8km，与图中芳乐路-天山西路-虹桥火车站的路线里程完全一致； 2、单元2：会展中心-芳乐路，4km，可能为联络线拉入沪杭外环线，按图中描如图，在国展中心东侧设站； 3、单元3：上海西-芳乐路，3.44km，为沪杭外环线的北向联络线（里程完全一致），可以直接进上海西和新客站。 2和3共同构成了沪杭外环线的全向联络线，上可去新客站，下可去松江和上海南，中可以去天山西路和虹桥。
原来申通还寻思过23和25在徐家汇贯通的线位 论文出处：《上海市域铁路机场联络线与国铁共同停靠车站旅客组织方案研究》 我一看左上角华漕那里是23，就一愣，以为是给25换了个名字，结果没想到顺着线走下来，竟然能一直走到闵行开发区仔细一看，竟然是23在徐家汇贯通25了。 注意这里23是一直沿着25的线位通到华漕的，如果2325贯通，并且26成真的话，这个换乘就有点东西了啊 不得不说真的大胆 尝试列一下23和25在徐家汇这样操作贯通后的换乘： 闵行开发区：嘉闵南（可能的线位之一） 东川路：5 紫竹高新区：15 华泾路：19 龙瑞路：26 龙漕路：3、12 上海体育场：4、11 徐家汇：1、9、11 吴中路：15 金汇路：26 紫藤路：10 沪星路：嘉闵线 徐泾东：2、13（13可能在25贯通后只开到芳乐路）、17 芳乐路：13、示范区线、未来的东西快线 在GE上描了一下可能的走法 徐家汇宇宙中心地位+114514
21号线，两港快线，浦东机场四期一起开工 来源浦东发布。都被21开工的消息给淹没了，两港快线和浦东机场四期也一起开工了。 不知道23什么状态，可能也是这几天了。
申通运能统计，附京广深蓉四个有8A编组的城市的现状运能 上海运能镇楼
21-12-30【沪苏通二期】四团枢纽单元规划公示 单元规划如图
四团枢纽又近了一步 单元规划镇楼
总结下14和18开通后的上海地铁最高运能 直接上图：14是200秒一趟，18是180秒一趟，15增能到220秒一趟。 3和4共线段120秒一趟，但是3和4交错运行。
【无责任摸】用visio摸了个YY的上海远景市域轨道交通线网 直接发图，只标了两线交点，不同的线路用不同颜色区分，不考虑具体的换乘或者跨线细节。
【示范区线】描了一下站点，全程估计大概30分钟吧 一楼GE镇楼
【代TSTO发】固体燃气超燃冲压发动机截面推测 不多说，直接上图
跑不起来啊
各国弹道导弹氵（二次打磨版） 这次跟航空航天港的TATP大佬重新把五常洲际导弹的表格打磨了一遍，这里面因为射程受PBV等因素影响不是确切数字，就仅以三级关机速度推算的基础射程作为下限，更高的数字就暂用加号来代替。
养鸡在公众号提到的《下一代预警机主要发展特征研究》全文 360km的指标只是其中一部分，其他的内容更有意思。
《先进米波雷达》一书中F-35和F-22在米波频段下的RCS 出自吴建旗的《先进米波雷达》第二章，米波频段的目标特性，文中对F-22和F-35的RCS进行建模，具体数据可以参照正文。
【全文转载】C919没自主产权？民航科普汇集兼顾讨论这次事件始末 原文标题：C919没自主产权？民航科普汇集给喷子上课 兼顾讨论这次事件始末！ http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Flt.cjdby.net%2Fforum.php%3Fmod%3Dviewthread%26tid%3D2611553&urlrefer=efea425d148fc8eabe86615ac3603963 转载已获原贴作者leeone许可：leeone在超大有多篇民航大飞机相关科普楼主在此同样推荐阅读。
我们来讨论一下，如何正确且生动的用艺术方法表现超视距空战 我们把谁家武器射程XXX，谁家航母用XXX等等这些问题先放一放，在这里向大家抛出个问题 众所周知，因为超视距空战两方相距几十公里甚至上百公里，将两者放到同一个镜头中是不可能的。而且超视距空战还涉及多个领域看不见的战斗（比如电子战等），如果真实的表现超视距空战，很有可能就变成了驾驶舱的录像：雷达显示屏变化——按按钮——拉杆——按按钮——boom！这样的结果。。。所以历代的影视/游戏/动画等作品中大多放弃了对超视距空战的刻画，即使再先进的机体一样是要狗斗 不得不说，这相当程度的加深了普通大众对空战的误解，明明技术已经进步到超视距空战时代，但是在各种作品上看到的仍然是咬六点的狗斗，那么应当如何正确生动的表现超视距空战呢？大家可以来聊聊想法
山东舰的机库宽度应该没变，跟辽宁一样还是26m 这个图里找到了一个参照物：后排挂的11面信号旗 按照国家标准，最大的一号旗宽度1.8m，长度2.1m，对照前排战士身高可知这个旗确实是一号旗 挨个量像素可以大致得出每两面信号旗之间的间距和信号旗与墙的间距为旗子宽度的0.3倍左右，也即0.5-0.6m之间 所以机库的总的宽度大约为1.8*11+0.5~0.6*12=25.8~26.5m之间，应该还是26m。。。
统计下海军各舰艇的下水到服役时间 002：从下水到服役用时965天 055：101从下水到服役928天，按照这个日期推算，2023年前所有的8条055都会服役 052D：目前已服役的13条平均用时870天，按照这个日期推算，同样2023年前所有的25条052D都会服役 052C：6条052C平均用时907天 054A：30条054A平均用时390天 056A/056：50条056+056A平均用时403天，按照这个日期推算，2021年以前目前已下水的72条056系列即可全部服役 071：已经服役的6条071平均用时373天，按照这个日期推算，今年8条071即可全部服役
尝试比较054AP和加尔各答 054A虽然比不了，但是卖给巴基斯坦的高配054AP还是可以比一比的，而且这俩属于现实的对手，非常有比较价值
对钢铁机机做的反舰导弹尺寸稍微做了一些修正 顺便把毛子几个大家伙也做进来了 吹一波YJ-12，体积只有4吨的3M80的四分之一，3吨的布拉莫斯的三分之一，0.85吨的YJ83的1.5倍 CJ-10,YJ-18,YJ-12,Y-11,PL-20(?)的重量确切数字仍然成谜，就不放重量数字了，自个估
【整活】075的航空作战能力初步预估 之前在超大整的活，现在整理了下一些新增的讨论发到重吧下面开始，可能发的有点慢
075的GE终于更新了 飞行甲板量出来的长度是230m，宽度36.5m，算上舰尾的平台，从最前端到尾门是237m。 舰岛长度66m，与山东舰岛长度基本相同。
蹭个F15和J16的冷度，发个自己N年前在超大的关于F15E的实战挂载 这是帖子的链接 http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Flt.cjdby.net%2Fthread-2312965-1-1.html&urlrefer=0f681c50dcd2483c4a9214d51e715f0d 首先F-15E的挂点如图，一共25个。这几个蓝色挂点可以挂对空武器：这几个红色的挂点可以挂对地武器：从前面看就是这样：因为原贴的配置太多了，楼下发几个典型配置，详细的挂载可以直接看原贴。
这是大宝贝的图啊 今年10.7，一看左下角排的这12发圆筒，每个好像都长12-13m的样子
如果以F-14作为原作来形容原作和同人的关系 那么这些应该怎么填？ 我先抛个砖： 原作：F-14 官方续作：F/A-18 其他世界观：Su-33 二次创作：伊朗F-14 现代理念重新创作的官方精神续作：NATF 对原作精神完美理解的同人：（这个我没想好是写Mig-31还是写J-20，好像写哪个都挺有道理） 下面四个暂时想不出来写哪个，大家一起来讨论讨论 新时代粉丝的同人： 网络上的要素再创作： OOC同人： 不知道哪来的大手子：
iPhone 6s通过工信部官网验证，确认A9是1.8GHz双核CPU 这次通过认证的是两网通的6s（A1700）与6s plus（A1699）首先上工信部的链接： http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fshouji.tenaa.com.cn%2FMobile%2FMobileDetail.aspx%3Fcode%3DwYX43Sz3OXR0w8odTKE4e4ApJEToK3q4&urlrefer=9ea100cabc13a2400b021184274e169a 在“高级功能”下可见CPU主频与CPU核心数分别为1.8GHz和2 RAM显示4MB 可能是因为SRAM识别的原因
发个8K的YTB VIDEO，手中持梯的可以感受下流不流畅 首先上视频地址： http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DsLprVF6d7Ug&urlrefer=dd37cb4e2b7b6ace1991cbfd8ef835ca 楼主铁通巨慢到现在还没加载了5秒呢 不过chrome解码这5秒还挺流畅的（我用的设备是艹到4.2G的X5650） 所以大痂谁网比较快的 反馈下原画的播放效果吧 目前YTB少有的8K视频之一
我来个系统性的发梦 好无聊 贴点发梦的结果吧 本人对发梦的准确性概不负责 全当装逼了 A9： CPU比A8提升40-60% GB3单线程在2100-2600分，多线程在4000-4600分 SPECINT2K单线程在2000-2400分之间 GPU低估计比A8提升1.5倍或者更多 绝对性能接近或者超过K1 曼哈顿达到或者超过30fps GPU高估计比A8提升2倍以上 绝对性能接近或者超过A8X 曼哈顿达到或者超过40fps A9X： CPU比A8X提升40-60% GB3单线程在2400-3000之间，多线程在6000-7500之间 SPECINT2K单线程在2200-2800之间 GPU低估计比A8X提升1.4倍 绝对性能接近X1 曼哈顿达到或者超过54fps GPU高估计比A8X提升2倍以上 绝对性能超过X1 曼哈顿接近或者超过65fps 对A9和A9X的功耗估计： CPU功耗总体应与A8/A8X持平 GPU功耗如采用低估计 会低于A8/A8X的1.3W/2.6W 如采用二代finfet则功耗明显低于A8/A8X GPU功耗如采用高估计 应当高于A8/A8X的1.3/2.6W 如采用二代finfet则功耗可能与A8/A8X持平 发梦完毕。一旦发梦不准确，本人概不负责。但是本人保留发梦准确后持发梦结果装逼的权利。
你们谁来装个逼
wp发帖测试 ~~~
上路了 现在躺在卧铺上 手机只有一个塞班了 那台剁手给我妈用了 现在重新成为了非智能机用户
我发现我好久没发帖了 让我很惆怅啊
闷声装大逼 半夜起来装个逼
好无聊 怎么没人装逼
挖到了几个A8X的数据，内存和闪存的 根据ifixit对Air2拆解得出的。 首先内存型号是两颗elpida F8164A3MD-GD，这是个64bit LPDDR3-1600的DRAM。 那也就是说 A8X的带宽等效于128bit LPDDR3-1600，那也就是25.6GBps。GeekBench的RAM跑分也大致吻合。 另外NAND是SK Hynix的E2NAND 3.0，型号是 H2JTEG8VD1BMR。具体资料还没找到。不过E2NAND是SK Hynix和Anobit合作开发的。主要就是ECC与可靠性的提升。Anobit现在已经被水果收购。另外Anobit独有通过MSP将闪存寿命提升20倍的黑科技，不知道现在有没有在移动端推广。 三核CPU和6650就不说了。
Air2基本确定是2GB RAM了 伏笔们快买买买 首先上连接：http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.iphonebenchmark.net%2Fmemmark_chart.html&urlrefer=28528399a2285cbffc24737fc5d48489 鼠标移到某一设备上就能看到认出来的内存容量，挪到iPad5,4上就是1987MB。 passmark官网今天晒出了Air2的跑分，虽然说passmark本身是个挺古老的软件了，不过内存容量这个还是能认对的。不过虽然容量上来了，这个分数是怎么回事呢
奔腾d 07年的老u 不用了才敢开的
我真心疼 说好的欧洲杯和美洲杯没有了
【自己翻译】深入了解Android L的ART from AnandTech 之前发在通吧了，发回来供基佬们讨论 原文翻译自Anandtech：http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fanandtech.com%2Fprint%2F8231%2Fa-closer-look-at-android-runtime-art-in-android-l&urlrefer=86f61f306cdb37c5479430df11cc6c81 自己翻译。如果有术语错误，请以原文为准。请谅解。 深入了解Android L的ART最近的I/O大会之后，google终于正式公开了它对Android新的运行环境的计划。Android RunTime，简称ART，用于执行Android上的Java代码的虚拟机，是取代Dalvik的继任者。我们已经在去年秋季上市的KitKat上对它稍有了解，但是对于它的术语和技术细节，Google并未言之过多。 对比其它的移动平台，比如iOS，Windows或者Tizen，它们都运行着针对特定硬件架构编译的本地代码，但绝大多数Android软件都基于通用的代码语言，将编译代码生成的ByteCode转化为设备自身的本机指令。 从最早的Android版本开始，Dalvik从一个不太复杂的虚拟机起步。但是随着时间推移，Google开始意识到让其性能跟上业界硬件脚步的重要性。Google在Android 2.2中加入了JIT编译器，加入了多线程功能，并且想逐步优化改进。 但是，在最近几年中，整个生态系统已经超过了Dalvik的发展过程，所以Google需要建立一个能够为以后打下坚实基础，能够适应今天与未来的八核处理器，大容量存储和大内存的新的虚拟机。 所以ART诞生了。 架构首先，ART的设计完全兼容Dalvik已有的字节码格dex(Dalvik executable)。所以从开发者的角度，在从Dalvik转移至ART的过程中，完全无需担心兼容性的问题并且代码无需任何改动。 ART带来最大的改变，就是用AOT(Ahead of time，运行前编译)取代了JIT(Just In Time，运行时编译)。ART将之前需要在每次应用运行时进行的编译，变成了只做一次。在之后所有的执行中，都会执行这一次编译完成的字节码。 当然，这些本地的转换使得应用程序会耗费更多存储空间，并且这个新的方案只有像现在这样Android设备的可用存储空间大幅提升了之后，才成为了可能。 这个转变使得以前很多无法实现的优化成为了可能：因为代码只被优化和编译一遍，所以将它优化到位是很重要的。Google宣称现在已经可以达到一个更高的针对整个程序代码的优化层次，而以前的JIT编译器只能进行本地方法块的优化。一般对代码检测异常的部分被大量的移除，并且方法和接口调用得到了显著的提速。新的"dex2oat"完成以上过程，取代以往Dalvik使用的"dexopt"。ART中也不需要odex文件(optimized dex，优化的dex)，被ELF文件取代。 因为ART编译一个ELF可执行文件，所以内核现在可以处理代码分页——这将带来更好的内存管理与更少的内存使用。我很好奇KSM(Kernel same-page merging)会带来什么样的效果，这是绝对值得关注的。 对于电池续航，它的作用也是非常明显的——因为在应用运行时无需进行JIT的工作，直接减少了CPU的使用，降低功耗。 所有这一切带来的唯一坏处，就是一次编译需要更多时间。设备与应用的第一次启动时间，相比Dalvik都会明显变长。Google指出时间不会拉的太长，他们预期最终的正式版甚至会比Dalvik速度更快。相比Dalvik，ART的性能提升是显著的。如上图，基本上运行在虚拟机上的代码，都有了2倍的性能提升。 Google指出诸如Chessbench这样提升3倍的应用，更能代表真实情况下，Android L正式版所带来的提升。 垃圾回收(Garbage Collection, GC)：理论与实践 Android的虚拟机依靠自动内存管理的模式，它作为Java编程范式的基础从一开始，就是Android的一部分。对自动内存管理这个概念不甚熟悉的人来说，一个比较通俗的解释就是，一个程序员既不手动申请物理内存，也不手动释放它。它不同于以手动管理内存为常态的底层编程。当然，自动管理的好处就是开发者无须担心内存管理问题，坏处就是开发者无法控制，无法自己进行优化。 Android与Dalvik深受Dalvik的GC方案之苦。每次当某一程序需要分配内存并且堆(heap, 一块应用专属的内存空间)无法分配的时候，GC将会启动。 GC的工作是仔细检查堆，枚举所有应用分配的对象，逐一标记仍在使用的对象，并且释放掉剩余的未标记对象。 在Dalvik中，这导致以下两种暂停——一种因枚举过程产生，另一种因标记产生。在这里，暂停指的是为了保证应用的完整性，该应用所有线程所有的代码执行都会停止。如果暂停过长，这将导致在渲染的过程中掉帧，这就是Android卡顿的来源。 Google宣称在Nexus 5上，这样的暂停平均耗时54ms，这导致了每次GC启动时，都会带来至少4帧的掉帧。 在我自己的体验与调查中，这个数字因具体程序不同而差异巨大。比如，官方的FIFA app就是一个十分鲜明的例子，GC进行的十分狂野如下： 07-01 15:56:14.275: D/dalvikvm(30615): GC_FOR_ALLOC freed 4442K, 25% free 20183K/26856K, paused 24ms, total 24ms 07-01 15:56:16.785: I/dalvikvm-heap(30615): Grow heap (frag case) to 38.179MB for 8294416-byte allocation 07-01 15:56:17.225: I/dalvikvm-heap(30615): Grow heap (frag case) to 48.279MB for 7361296-byte allocation 07-01 15:56:17.625: I/Choreographer(30615): Skipped 35 frames! The application may be doing too much work on its main thread. 07-01 15:56:19.035: D/dalvikvm(30615): GC_CONCURRENT freed 35838K, 43% free 51351K/89052K, paused 3ms+5ms, total 106ms 07-01 15:56:19.035: D/dalvikvm(30615): WAIT_FOR_CONCURRENT_GC blocked 96ms 07-01 15:56:19.815: D/dalvikvm(30615): GC_CONCURRENT freed 7078K, 42% free 52464K/89052K, paused 14ms+4ms, total 96ms 07-01 15:56:19.815: D/dalvikvm(30615): WAIT_FOR_CONCURRENT_GC blocked 74ms 07-01 15:56:20.035: I/Choreographer(30615): Skipped 141 frames! The application may be doing too much work on its main thread. 07-01 15:56:20.275: D/dalvikvm(30615): GC_FOR_ALLOC freed 4774K, 45% free 49801K/89052K, paused 168ms, total 168ms 07-01 15:56:20.295: I/dalvikvm-heap(30615): Grow heap (frag case) to 56.900MB for 4665616-byte allocation 07-01 15:56:21.315: D/dalvikvm(30615): GC_FOR_ALLOC freed 1359K, 42% free 55045K/93612K, paused 95ms, total 95ms 07-01 15:56:21.965: D/dalvikvm(30615): GC_CONCURRENT freed 6376K, 40% free 56861K/93612K, paused 16ms+8ms, total 126ms 07-01 15:56:21.965: D/dalvikvm(30615): WAIT_FOR_CONCURRENT_GC blocked 111ms 07-01 15:56:21.965: D/dalvikvm(30615): WAIT_FOR_CONCURRENT_GC blocked 97ms 07-01 15:56:22.085: I/Choreographer(30615): Skipped 38 frames! The application may be doing too much work on its main thread. 07-01 15:56:22.195: D/dalvikvm(30615): GC_FOR_ALLOC freed 1539K, 40% free 56833K/93612K, paused 87ms, total 87ms 07-01 15:56:22.195: I/dalvikvm-heap(30615): Grow heap (frag case) to 60.588MB for 1331732-byte allocation 07-01 15:56:22.475: D/dalvikvm(30615): GC_FOR_ALLOC freed 308K, 39% free 59497K/96216K, paused 84ms, total 84ms 07-01 15:56:22.815: D/dalvikvm(30615): GC_FOR_ALLOC freed 287K, 38% free 60878K/97516K, paused 95ms, total 95ms 以上是这个程序运行之后几秒内的日志。垃圾回收器一共被唤醒9次，导致程序冻结603ms，总共掉帧214帧。内存分配的请求导致的暂停，在Log中都以“GC_FOR_ALLOC”标记。 而ART承诺的垃圾回收性能的提升是极其巨大的。以下是ART在执行前面同样任务的对比： 07-01 16:00:44.531: I/art(198): Explicit concurrent mark sweep GC freed 700(30KB) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 186us total 12.763ms 07-01 16:00:44.545: I/art(198): Explicit concurrent mark sweep GC freed 7(240B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 198us total 9.465ms 07-01 16:00:44.554: I/art(198): Explicit concurrent mark sweep GC freed 5(160B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 224us total 9.045ms 07-01 16:00:44.690: I/art(801): Explicit concurrent mark sweep GC freed 65595(3MB) AllocSpace objects, 9(4MB) LOS objects, 810% free, 38MB/58MB, paused 1.195ms total 87.219ms 07-01 16:00:46.517: I/art(29197): Background partial concurrent mark sweep GC freed 74626(3MB) AllocSpace objects, 39(4MB) LOS objects, 1496% free, 25MB/32MB, paused 4.422ms total 1.371747s 07-01 16:00:48.534: I/Choreographer(29197): Skipped 30 frames! The application may be doing too much work on its main thread. 07-01 16:00:48.566: I/art(29197): Background sticky concurrent mark sweep GC freed 70319(3MB) AllocSpace objects, 59(5MB) LOS objects, 825% free, 49MB/56MB, paused 6.139ms total 52.868ms 07-01 16:00:49.282: I/Choreographer(29197): Skipped 33 frames! The application may be doing too much work on its main thread. 07-01 16:00:49.652: I/art(1287): Heap transition to ProcessStateJankImperceptible took 45.636146ms saved at least 723KB 07-01 16:00:49.660: I/art(1256): Heap transition to ProcessStateJankImperceptible took 52.650677ms saved at least 966KB ART与Dalvik的差别不能再大——ART在同样的情况下，停顿了12.364ms，前台调用4次GC，后台调用2次。在应用运行的全程中，内存的占用也并无增长，而在Dalvik中，内存的占用增加了4次。掉帧也减少到了63帧。 显然这是一个对于一个烂应用能发生的最坏的场景，在ART的情况下，程序依然会有些许的掉帧，但是坏的编程习惯——比如重载UI线程是Android更需要面对的问题。 ART减轻了以前垃圾回收器的很多负担，使执行过程中的暂停不再必要，第二类暂停也通过在暂停之前尽可能完成工作而极大减少——一种被叫做Packard预清除的技术得以应用，而暂停本身在一个简单的检查与校验的过程中完成。Google宣称他们做到了将暂停时间减小到了3ms，是相对Dalvik GC的极大提升。同时，不同于堆的“大对象空间”，Large Object Space，简称LOS，被引入，它依旧在应用程序内存中，它被用于更好的处理大的对象，比如图片。这些大的简单的对象如果使堆变得碎片化，将产生很严重的问题，导致在回收对象时更多的GC调用。在更加智能的内存分配方案下，GC调用频率大幅减少，同时内存的碎片化程度也有显著的降低。 另一个比较好的例子是Hangout的app，在Dalvik中，我们看到这样几次GC调用导致的暂停： 07-01 06:37:13.481: D/dalvikvm(7403): GC_EXPLICIT freed 2315K, 46% free 18483K/34016K, paused 3ms+4ms, total 40ms 07-01 06:37:13.901: D/dalvikvm(9871): GC_CONCURRENT freed 3779K, 22% free 21193K/26856K, paused 3ms+3ms, total 36ms 07-01 06:37:14.041: D/dalvikvm(9871): GC_FOR_ALLOC freed 368K, 21% free 21451K/26856K, paused 25ms, total 25ms 07-01 06:37:14.041: I/dalvikvm-heap(9871): Grow heap (frag case) to 24.907MB for 147472-byte allocation 07-01 06:37:14.071: D/dalvikvm(9871): GC_FOR_ALLOC freed 4K, 20% free 22167K/27596K, paused 25ms, total 25ms 07-01 06:37:14.111: D/dalvikvm(9871): GC_FOR_ALLOC freed 9K, 19% free 23892K/29372K, paused 27ms, total 28ms 我们可以看到所有GC调用的示例，明确的和并发的GC调用是GC通用的清理与维护的调用。for_alloc的调用是内存分配器试图分配内存但是发现并不匹配，于是GC启动以获得更多空间。在中间，我们看到了堆因为碎片化尺寸增加，而且不能装入大对象。总的暂停时间一共90ms。作为对比，以下是Android L预览版中的情况： 07-01 06:35:19.718: I/art(10844): Heap transition to ProcessStateJankPerceptible took 17.989063ms saved at least -138KB 07-01 06:35:24.171: I/art(1256): Heap transition to ProcessStateJankImperceptible took 42.936250ms saved at least 258KB 07-01 06:35:24.806: I/art(801): Explicit concurrent mark sweep GC freed 85790(3MB) AllocSpace objects, 4(10MB) LOS objects, 850% free, 35MB/56MB, paused 961us total 83.110ms 我们不是特别确定这样的记录代表什么，但是我们认为它们是重新为堆指定尺寸的过程。唯一的一次GC调用是在应用完成启动之后，耗时961us。我们没在这次GC之前看到任何类似的调用。比较有趣的事LOS的统计。我们看到LOS中有4个10MB的大对象，以前它们都会被分配在程序的堆中，但现在它们在分配的时候被忽略了，这成功的避免了GC的重复调用与可能拖慢Dalvik速度的碎片化内存。 内存分配系统自身也有提升。当ART自身提供相对Dalvik的25%速度提升时，Google并不是特别满意，并且引入了Linux内核中一个新的内存分配器，替换了当前使用的malloc分配器。 新的分配器叫rosalloc，全称是Rows of slots Allocator，为多线程Java应用程序设计。新的分配器有一个更加细粒度的结构，可以锁定独立的对象。在线程本地区域中的小对象也可以被一起锁定。 这使得分配速度的提升也极其巨大，多达10倍。 垃圾回收算法自身也被修订，用于提升用户体验与避免程序的中断。这些算法尚未完工，而Google最近只是发布了一个新的专用的算法，Moving Garbage collector，主要目的是整理后台程序堆的碎片。 64位支持 ART基于模块化的设计，面向不同的目标架构。因此，它面向目前最常见的架构提供了编译器后端，比如ARM，X86和MIPS，以及ARM64，x86-64和仍未实现的MIPS64。 当我们在iPhone5s的评测中讨论切换至64bit的优劣时，我们已经讨论得很深入了，主要的好处是在完全兼容已有32bit应用的同时，提升了可用的地址空间，提升了性能，以及极大提升的加密解密性能。 Google与Apple的一个很大的区别，至少是在虚拟机应用上，是Google使用了引用压缩避免通常64bit导致的内存膨胀，虚拟机依旧使用了32bit的引用。Google展示了部分跑分以对比ARM和x86切换至64bit的性能。x86的跑分在Intel的Bay Trail上执行，在不同的RenderScript跑分上展示了2-4.5倍的性能。在ARM这边，相比32bit提升的加密性能由A57/A53系统来展示。它们都不代表真实的使用情况，所以作为性能的预测并无意义。 然而Google也拿出了一些比较有趣的数字。Google内建的Panorama，我们可以看到32bit到64bit有着13-19%的性能提升。我们也可以看到，在64bit下，Cortex-A53的提升更为显著。 Google声称当前Play商店中85%的应用已经准备好立即切换至64bit——这意味着只有15%的应用含有部分本地代码需要开发者进行对64bit架构针对性的编译，在以往切换至64bit的过程中，Google也算是很成功的。 结语 从很多方面来说，Google已经给出了性能的巨大提升，并且解决了很多阻碍Android发展的短板。 ART补足了很多在运行非本地应用与内存管理过程中的缺陷。作为一名开发者，我无法要求更多。以前我必须通过机智的算法与特别的编程技巧解决的诸多性能问题，现在都不再是一个硬伤了。 这也意味着Android终于可以在应用程序的流畅性与性能上，与iOS有所一拼了。这是消费者的大胜利。 Google保证未来依旧会不断改进ART，而且现在的它已经与6个月前刚发布时有了很大的区别。而6个月之后Android L最终上市的时候，它也一定不会与现在完全一致。未来很光明，我已经等不及要看看Google还会拿ART做些什么了。
【自翻】深入了解Android L的ART from AnandTech 原文翻译自Anandtech：http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fanandtech.com%2Fprint%2F8231%2Fa-closer-look-at-android-runtime-art-in-android-l&urlrefer=86f61f306cdb37c5479430df11cc6c81 自己翻译。如果有术语错误，请以原文为准。请谅解。 深入了解Android L的ART最近的I/O大会之后，google终于正式公开了它对Android新的运行环境的计划。Android RunTime，简称ART，用于执行Android上的Java代码的虚拟机，是取代Dalvik的继任者。我们已经在去年秋季上市的KitKat上对它稍有了解，但是对于它的术语和技术细节，Google并未言之过多。 对比其它的移动平台，比如iOS，Windows或者Tizen，它们都运行着针对特定硬件架构编译的本地代码，但绝大多数Android软件都基于通用的代码语言，将编译代码生成的ByteCode转化为设备自身的本机指令。 从最早的Android版本开始，Dalvik从一个不太复杂的虚拟机起步。但是随着时间推移，Google开始意识到让其性能跟上业界硬件脚步的重要性。Google在Android 2.2中加入了JIT编译器，加入了多线程功能，并且想逐步优化改进。 但是，在最近几年中，整个生态系统已经超过了Dalvik的发展过程，所以Google需要建立一个能够为以后打下坚实基础，能够适应今天与未来的八核处理器，大容量存储和大内存的新的虚拟机。 所以ART诞生了。 架构首先，ART的设计完全兼容Dalvik已有的字节码格dex(Dalvik executable)。所以从开发者的角度，在从Dalvik转移至ART的过程中，完全无需担心兼容性的问题并且代码无需任何改动。 ART带来最大的改变，就是用AOT(Ahead of time，运行前编译)取代了JIT(Just In Time，运行时编译)。ART将之前需要在每次应用运行时进行的编译，变成了只做一次。在之后所有的执行中，都会执行这一次编译完成的字节码。 当然，这些本地的转换使得应用程序会耗费更多存储空间，并且这个新的方案只有像现在这样Android设备的可用存储空间大幅提升了之后，才成为了可能。 这个转变使得以前很多无法实现的优化成为了可能：因为代码只被优化和编译一遍，所以将它优化到位是很重要的。Google宣称现在已经可以达到一个更高的针对整个程序代码的优化层次，而以前的JIT编译器只能进行本地方法块的优化。一般对代码检测异常的部分被大量的移除，并且方法和接口调用得到了显著的提速。新的"dex2oat"完成以上过程，取代以往Dalvik使用的"dexopt"。ART中也不需要odex文件(optimized dex，优化的dex)，被ELF文件取代。 因为ART编译一个ELF可执行文件，所以内核现在可以处理代码分页——这将带来更好的内存管理与更少的内存使用。我很好奇KSM(Kernel same-page merging)会带来什么样的效果，这是绝对值得关注的。 对于电池续航，它的作用也是非常明显的——因为在应用运行时无需进行JIT的工作，直接减少了CPU的使用，降低功耗。 所有这一切带来的唯一坏处，就是一次编译需要更多时间。设备与应用的第一次启动时间，相比Dalvik都会明显变长。Google指出时间不会拉的太长，他们预期最终的正式版甚至会比Dalvik速度更快。相比Dalvik，ART的性能提升是显著的。如上图，基本上运行在虚拟机上的代码，都有了2倍的性能提升。 Google指出诸如Chessbench这样提升3倍的应用，更能代表真实情况下，Android L正式版所带来的提升。 垃圾回收(Garbage Collection, GC)：理论与实践 Android的虚拟机依靠自动内存管理的模式，它作为Java编程范式的基础从一开始，就是Android的一部分。对自动内存管理这个概念不甚熟悉的人来说，一个比较通俗的解释就是，一个程序员既不手动申请物理内存，也不手动释放它。它不同于以手动管理内存为常态的底层编程。当然，自动管理的好处就是开发者无须担心内存管理问题，坏处就是开发者无法控制，无法自己进行优化。 Android与Dalvik深受Dalvik的GC方案之苦。每次当某一程序需要分配内存并且堆(heap, 一块应用专属的内存空间)无法分配的时候，GC将会启动。 GC的工作是仔细检查堆，枚举所有应用分配的对象，逐一标记仍在使用的对象，并且释放掉剩余的未标记对象。 在Dalvik中，这导致以下两种暂停——一种因枚举过程产生，另一种因标记产生。在这里，暂停指的是为了保证应用的完整性，该应用所有线程所有的代码执行都会停止。如果暂停过长，这将导致在渲染的过程中掉帧，这就是Android卡顿的来源。 Google宣称在Nexus 5上，这样的暂停平均耗时54ms，这导致了每次GC启动时，都会带来至少4帧的掉帧。 在我自己的体验与调查中，这个数字因具体程序不同而差异巨大。比如，官方的FIFA app就是一个十分鲜明的例子，GC进行的十分狂野如下： 07-01 15:56:14.275: D/dalvikvm(30615): GC_FOR_ALLOC freed 4442K, 25% free 20183K/26856K, paused 24ms, total 24ms 07-01 15:56:16.785: I/dalvikvm-heap(30615): Grow heap (frag case) to 38.179MB for 8294416-byte allocation 07-01 15:56:17.225: I/dalvikvm-heap(30615): Grow heap (frag case) to 48.279MB for 7361296-byte allocation 07-01 15:56:17.625: I/Choreographer(30615): Skipped 35 frames! The application may be doing too much work on its main thread. 07-01 15:56:19.035: D/dalvikvm(30615): GC_CONCURRENT freed 35838K, 43% free 51351K/89052K, paused 3ms+5ms, total 106ms 07-01 15:56:19.035: D/dalvikvm(30615): WAIT_FOR_CONCURRENT_GC blocked 96ms 07-01 15:56:19.815: D/dalvikvm(30615): GC_CONCURRENT freed 7078K, 42% free 52464K/89052K, paused 14ms+4ms, total 96ms 07-01 15:56:19.815: D/dalvikvm(30615): WAIT_FOR_CONCURRENT_GC blocked 74ms 07-01 15:56:20.035: I/Choreographer(30615): Skipped 141 frames! The application may be doing too much work on its main thread. 07-01 15:56:20.275: D/dalvikvm(30615): GC_FOR_ALLOC freed 4774K, 45% free 49801K/89052K, paused 168ms, total 168ms 07-01 15:56:20.295: I/dalvikvm-heap(30615): Grow heap (frag case) to 56.900MB for 4665616-byte allocation 07-01 15:56:21.315: D/dalvikvm(30615): GC_FOR_ALLOC freed 1359K, 42% free 55045K/93612K, paused 95ms, total 95ms 07-01 15:56:21.965: D/dalvikvm(30615): GC_CONCURRENT freed 6376K, 40% free 56861K/93612K, paused 16ms+8ms, total 126ms 07-01 15:56:21.965: D/dalvikvm(30615): WAIT_FOR_CONCURRENT_GC blocked 111ms 07-01 15:56:21.965: D/dalvikvm(30615): WAIT_FOR_CONCURRENT_GC blocked 97ms 07-01 15:56:22.085: I/Choreographer(30615): Skipped 38 frames! The application may be doing too much work on its main thread. 07-01 15:56:22.195: D/dalvikvm(30615): GC_FOR_ALLOC freed 1539K, 40% free 56833K/93612K, paused 87ms, total 87ms 07-01 15:56:22.195: I/dalvikvm-heap(30615): Grow heap (frag case) to 60.588MB for 1331732-byte allocation 07-01 15:56:22.475: D/dalvikvm(30615): GC_FOR_ALLOC freed 308K, 39% free 59497K/96216K, paused 84ms, total 84ms 07-01 15:56:22.815: D/dalvikvm(30615): GC_FOR_ALLOC freed 287K, 38% free 60878K/97516K, paused 95ms, total 95ms 以上是这个程序运行之后几秒内的日志。垃圾回收器一共被唤醒9次，导致程序冻结603ms，总共掉帧214帧。内存分配的请求导致的暂停，在Log中都以“GC_FOR_ALLOC”标记。 而ART承诺的垃圾回收性能的提升是极其巨大的。以下是ART在执行前面同样任务的对比： 07-01 16:00:44.531: I/art(198): Explicit concurrent mark sweep GC freed 700(30KB) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 186us total 12.763ms 07-01 16:00:44.545: I/art(198): Explicit concurrent mark sweep GC freed 7(240B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 198us total 9.465ms 07-01 16:00:44.554: I/art(198): Explicit concurrent mark sweep GC freed 5(160B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 224us total 9.045ms 07-01 16:00:44.690: I/art(801): Explicit concurrent mark sweep GC freed 65595(3MB) AllocSpace objects, 9(4MB) LOS objects, 810% free, 38MB/58MB, paused 1.195ms total 87.219ms 07-01 16:00:46.517: I/art(29197): Background partial concurrent mark sweep GC freed 74626(3MB) AllocSpace objects, 39(4MB) LOS objects, 1496% free, 25MB/32MB, paused 4.422ms total 1.371747s 07-01 16:00:48.534: I/Choreographer(29197): Skipped 30 frames! The application may be doing too much work on its main thread. 07-01 16:00:48.566: I/art(29197): Background sticky concurrent mark sweep GC freed 70319(3MB) AllocSpace objects, 59(5MB) LOS objects, 825% free, 49MB/56MB, paused 6.139ms total 52.868ms 07-01 16:00:49.282: I/Choreographer(29197): Skipped 33 frames! The application may be doing too much work on its main thread. 07-01 16:00:49.652: I/art(1287): Heap transition to ProcessStateJankImperceptible took 45.636146ms saved at least 723KB 07-01 16:00:49.660: I/art(1256): Heap transition to ProcessStateJankImperceptible took 52.650677ms saved at least 966KB ART与Dalvik的差别不能再大——ART在同样的情况下，停顿了12.364ms，前台调用4次GC，后台调用2次。在应用运行的全程中，内存的占用也并无增长，而在Dalvik中，内存的占用增加了4次。掉帧也减少到了63帧。 显然这是一个对于一个烂应用能发生的最坏的场景，在ART的情况下，程序依然会有些许的掉帧，但是坏的编程习惯——比如重载UI线程是Android更需要面对的问题。 ART减轻了以前垃圾回收器的很多负担，使执行过程中的暂停不再必要，第二类暂停也通过在暂停之前尽可能完成工作而极大减少——一种被叫做Packard预清除的技术得以应用，而暂停本身在一个简单的检查与校验的过程中完成。Google宣称他们做到了将暂停时间减小到了3ms，是相对Dalvik GC的极大提升。同时，不同于堆的“大对象空间”，Large Object Space，简称LOS，被引入，它依旧在应用程序内存中，它被用于更好的处理大的对象，比如图片。这些大的简单的对象如果使堆变得碎片化，将产生很严重的问题，导致在回收对象时更多的GC调用。在更加智能的内存分配方案下，GC调用频率大幅减少，同时内存的碎片化程度也有显著的降低。 另一个比较好的例子是Hangout的app，在Dalvik中，我们看到这样几次GC调用导致的暂停： 07-01 06:37:13.481: D/dalvikvm(7403): GC_EXPLICIT freed 2315K, 46% free 18483K/34016K, paused 3ms+4ms, total 40ms 07-01 06:37:13.901: D/dalvikvm(9871): GC_CONCURRENT freed 3779K, 22% free 21193K/26856K, paused 3ms+3ms, total 36ms 07-01 06:37:14.041: D/dalvikvm(9871): GC_FOR_ALLOC freed 368K, 21% free 21451K/26856K, paused 25ms, total 25ms 07-01 06:37:14.041: I/dalvikvm-heap(9871): Grow heap (frag case) to 24.907MB for 147472-byte allocation 07-01 06:37:14.071: D/dalvikvm(9871): GC_FOR_ALLOC freed 4K, 20% free 22167K/27596K, paused 25ms, total 25ms 07-01 06:37:14.111: D/dalvikvm(9871): GC_FOR_ALLOC freed 9K, 19% free 23892K/29372K, paused 27ms, total 28ms 我们可以看到所有GC调用的示例，明确的和并发的GC调用是GC通用的清理与维护的调用。for_alloc的调用是内存分配器试图分配内存但是发现并不匹配，于是GC启动以获得更多空间。在中间，我们看到了堆因为碎片化尺寸增加，而且不能装入大对象。总的暂停时间一共90ms。作为对比，以下是Android L预览版中的情况： 07-01 06:35:19.718: I/art(10844): Heap transition to ProcessStateJankPerceptible took 17.989063ms saved at least -138KB 07-01 06:35:24.171: I/art(1256): Heap transition to ProcessStateJankImperceptible took 42.936250ms saved at least 258KB 07-01 06:35:24.806: I/art(801): Explicit concurrent mark sweep GC freed 85790(3MB) AllocSpace objects, 4(10MB) LOS objects, 850% free, 35MB/56MB, paused 961us total 83.110ms 我们不是特别确定这样的记录代表什么，但是我们认为它们是重新为堆指定尺寸的过程。唯一的一次GC调用是在应用完成启动之后，耗时961us。我们没在这次GC之前看到任何类似的调用。比较有趣的事LOS的统计。我们看到LOS中有4个10MB的大对象，以前它们都会被分配在程序的堆中，但现在它们在分配的时候被忽略了，这成功的避免了GC的重复调用与可能拖慢Dalvik速度的碎片化内存。 内存分配系统自身也有提升。当ART自身提供相对Dalvik的25%速度提升时，Google并不是特别满意，并且引入了Linux内核中一个新的内存分配器，替换了当前使用的malloc分配器。 新的分配器叫rosalloc，全称是Rows of slots Allocator，为多线程Java应用程序设计。新的分配器有一个更加细粒度的结构，可以锁定独立的对象。在线程本地区域中的小对象也可以被一起锁定。 这使得分配速度的提升也极其巨大，多达10倍。 垃圾回收算法自身也被修订，用于提升用户体验与避免程序的中断。这些算法尚未完工，而Google最近只是发布了一个新的专用的算法，Moving Garbage collector，主要目的是整理后台程序堆的碎片。 64位支持 ART基于模块化的设计，面向不同的目标架构。因此，它面向目前最常见的架构提供了编译器后端，比如ARM，X86和MIPS，以及ARM64，x86-64和仍未实现的MIPS64。 当我们在iPhone5s的评测中讨论切换至64bit的优劣时，我们已经讨论得很深入了，主要的好处是在完全兼容已有32bit应用的同时，提升了可用的地址空间，提升了性能，以及极大提升的加密解密性能。 Google与Apple的一个很大的区别，至少是在虚拟机应用上，是Google使用了引用压缩避免通常64bit导致的内存膨胀，虚拟机依旧使用了32bit的引用。Google展示了部分跑分以对比ARM和x86切换至64bit的性能。x86的跑分在Intel的Bay Trail上执行，在不同的RenderScript跑分上展示了2-4.5倍的性能。在ARM这边，相比32bit提升的加密性能由A57/A53系统来展示。它们都不代表真实的使用情况，所以作为性能的预测并无意义。 然而Google也拿出了一些比较有趣的数字。Google内建的Panorama，我们可以看到32bit到64bit有着13-19%的性能提升。我们也可以看到，在64bit下，Cortex-A53的提升更为显著。 Google声称当前Play商店中85%的应用已经准备好立即切换至64bit——这意味着只有15%的应用含有部分本地代码需要开发者进行对64bit架构针对性的编译，在以往切换至64bit的过程中，Google也算是很成功的。 结语 从很多方面来说，Google已经给出了性能的巨大提升，并且解决了很多阻碍Android发展的短板。 ART补足了很多在运行非本地应用与内存管理过程中的缺陷。作为一名开发者，我无法要求更多。以前我必须通过机智的算法与特别的编程技巧解决的诸多性能问题，现在都不再是一个硬伤了。 这也意味着Android终于可以在应用程序的流畅性与性能上，与iOS有所一拼了。这是消费者的大胜利。 Google保证未来依旧会不断改进ART，而且现在的它已经与6个月前刚发布时有了很大的区别。而6个月之后Android L最终上市的时候，它也一定不会与现在完全一致。未来很光明，我已经等不及要看看Google还会拿ART做些什么了。
啦啦啦转正啦~~~~~~液！！！！！！ 亲爱的吧友，你好！很高兴地告诉你，你已经顺利通过管理员评估考核，成为正式吧主。请再次认真阅读并遵守吧主制度 http://tieba.baidu.com/tb/system.html， 为了你更好的成长，请您常去【吧主大学】看看http://daxue.tieba.baidu.com/，这里有最权威的贴吧管理课程、最棒的吧主管理经验以及贴吧最in的吧主！再次祝贺你成为正式吧主，加入贴吧建设的大队伍中！感谢你对贴吧的一片热忱和贡献，以及一直以来对我们的信任和支持，我们会和你一起加油的！百度贴吧管理组上
痛 实习期究竟过没过 还发不出表情么
我现在很惆怅 吧主考核能不能过
刚才是谁作死把我给封了 你们不造吧主可以自己解封自己么，封我的站粗来，你已经死了
来，我们讨论下本吧的头像和签名档问题 你们都来说说用啥图，要没主意的话我就用我原来那个头像了啊
【本帖置顶】各位吧务请注意，千万不要手贱把自己给封了 如图。@Devil丶s灬Den @qwerty1319 @囚心岛_ @那赛dynames @斗帝维德 我批准你们当85，不是叫你们封自己封着玩的，可是不怕一万就怕万一，还是提醒各位吧务大人，千万别封自己封着玩，我知道这吧人少，咱们可以多拉点人，但是通过封自己来体验当权限封人的感觉，我还是不推荐…… 立个规矩：每位85手贱封了自己的话，给3次吧主解封的机会，再多了，你就等第二天解封吧
置顶帖你们能点进去么 为啥被抽了
尼玛一吧全都是权限狗 会员名就叫权限狗好了
拿到权限！ @Devil丶s灬Den @斗帝维德 @qwerty1319 现在是实习吧主，除了不能上23吧主之外其余跟正式吧主一样的权限快去点小吧的申请啊
尼玛发言还不够10贴 太蛋疼了
本吧第一贴，楼主我来了
其实吧 知乎举报不成功的 多半是因为0回复0关注 比如我 举报个评论人家管理员回复的就很快，你看，说是【不友善内容】人家2h就帮我删了 我虽然也有砖栏 但是想一想还是槽点太多写不出什么内容反驳 就算吧里集思广益写出来一份 贴出来。。。我的砖栏也没人关注一篇文挂了4个月至今点击率为0想必贴到我专栏里也只能把那哥们拉过来打嘴炮然后拉黑，也形不成更大影响力就先把那逗比晾那吧。 同时一点题外话说一下，不会太长： 互联网上本来没有什么高低贵贱之分，用整体的印象去代个别的情况，这就是耍流氓。没错。无论是[知乎用户=装逼]还是[贴吧用户=脑残水军]这两种印象都是耍流氓。说到最后就是看谁的嘴炮更响骂的字更脏而已。 这样的讨论没意义。 去翻一下 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fzhi.hu%2F3YAA&urlrefer=088f066cb3d46c716272c70e3f3234c7 下面的评论串，@78基佬 们都很有礼貌，至少大家都是就事论事讨论的。而那个逗比的回复，一句不和就妊娠攻击 确实咱们说到底不在意别人拉不拉黑咱们，不过因为大环境复杂了，现在利shui益jun相关方越来越多，基佬们在别的地方摆事实讲道理也难免被喷。就事论事讨论可以，妊娠攻击就只能激化矛盾了。 写到这我忘了我发这贴想说啥了写个78基佬防被扣帽子注意事项吧。 1 时间线上别空。我知道大家都是在贴吧水逼不怎么上逼乎，不过平时就点几个赞 关注几个问题还是不费劲的，找几个冷门问题关注下，不至于总是收到通知多了一堆回答还没几个有干货的挺烦。 2 关注几个用户个话题。这个就不说了。逼乎用户对0关注的用户都挺敏感的，基本上都是直接扣水军帽子了，挺神经质的，基佬们别太在意实在嫌逼格太高自己无法接近的话，咱们78基佬可以自己抱团啊，你看一片烂文炸出多少78基佬？ 3 有理有节。人家说贴吧脑残水军五毛，别骂，咱们如果有理有节不脑残摆事实讲道理就是对他们最大的打脸。毕竟78也是摆事实讲道理文明理性讨论的地方。【谁跟我说78有嘴炮？在78打嘴炮的通通要吸进淋比才行！】 4 妊娠攻击的言论 举报到底。就像我这张图一样。 我不会吐槽那个逗比。因为大家都吐过了我都找不到槽点了。 以上。手机打的有点乱，见谅。
【我也成用啥坏啥了】这些年 陪我走过的碎屏 碎屏镇楼 基佬们可以猜猜哪个屏幕是原装的
【自己翻译】Anandtech关于IMG的下一代光线追踪GPU架构：Wizard 首先说明，以下都是楼主的无责任翻译，我无法保证文中任何术语翻译的绝对准确，同时，本文不代表译者观点。 为了方便对照，贴完中文后我会贴原文，图我就只贴一遍了。如有异议，请以英文原文为准。 anandtech关于PowerVR 6XT Rogue的介绍与本文有关，地址是：http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.anandtech.com%2Fshow%2F7793%2Fimaginations-powervr-rogue-architecture-exposed&urlrefer=84a00c2e0700922cac2c4a87407a69bd 原文废话很多，大家凑合着看。 在这周旧金山召开的2014Game Developer Conference（游戏开发者大会）中，尽管这不是一个硬件的展会，但是我们仍然在桌面与移动领域见到了不少与游戏有关的硬件。移动领域今年看起来也会相当繁忙。 Khronos在这周一（已经是半个月以前的事了）的展览中已经发布了OpenGLES 3.1，随后也有一大波发布会紧随其后。 也许其中最具开创性的就是IMG的发布会了。IMG在2014年的GDC中，发布了他们最新的GPU架构，Wizard。这是个前所未有的新GPU架构。【以上基本都是废话】首先，我们要知道，Wizard是什么？ 简短地说，Wizard是IMG一直迫切想要推出的支持光线追踪的消费级GPU架构。 对于GPU，光线追踪并不陌生——它一直可以通过Shader不那么高效地实现，但是有了Wizard，IMG决定迈出更大的步伐。为此，IMG从2010年就已经开始发力，包括建立了OpenRLAPI（其中的R=ray，光线）和发布了独立的光线追踪卡。现在，他们已经准备好迈出下一步，向他们的消费级GPU架构中加入独立的光线追踪单元。 这些的结果就是Wizard GPU架构。基本上，Wizard可以理解为IMG已经发布了的PowerVR 6XT系列Rogue架构的一个扩展，以Rogue为基础，在这之上增加额外的光线追踪单元。这样做出来的GPU，在不损失传统像素渲染性能的前提下，还具有了光线追踪的能力。【这段也基本上都是废话】
半夜没事，把M8的正面P了一下，P掉了logo看看效果 如图，电容LOGO没了，logo被我挪到了boooooooooomsound的扬声器上，屏幕自然也变大了。这个是本来的google play版本，个人更喜欢银色的设计
作为能用党，深夜来讨论下能用党的续航标准 以下为楼主半夜脑洞大开之作，如有雷同请勿对号入座 说到手机的续航，基佬们是有人欢喜有人剁手，楼主作为一个相机瞅个亮，音质听个响，系统能有个反应就可以了的能用党，跟基佬们娱乐下，说说关于续航的底♂线吧。 视频，如果我在看b站新番，好歹得撑过1集吧？总不能我看个鱿鱼干没等到ed出来就没电吧？总不能我发个弹幕字还没打完就没电吧？ 所以，在满电的状态下，以能瞅见的亮度看完一集24分钟左右的新番，这就是我对视频的续航底线，看完了没电没关系，充满电了还能看下一集，但是没看完一集，就自动关机了，这个让人接受不能。 再说说上网。基佬们上个网，无论是刷个空间还是上个贴吧还是发个微博朋友圈，或者是高端大气一点的吧友说了，我也逛个知乎啦，上个qoura什么的，你总得能看完你的那些动态吧？ 有的基佬好友挺多，看完要费点时间的，没关系。刷贴吧总不能我还没打完挽尊就自动关机了吧？刷个网页总不能在我还看着进度条往前走呢就没电了吧？我上空间看个图总不能图没出来手机先跪了吧？ 所以，这就是我对上网的续航的底线：网页，能有时间看完，在看完网页后没电，谁管你？充就是了。看贴吧，至少能给我点回帖的时间，刷微博，至少能给我把图加载出来，这就足够了。 有的基佬说了，我要聊QQ啊，那么快没电，怎么办啊？那我就要说了，说话的时候，不要扯那些有的没的，捡重点说！没用的话不说不就可以了？这样一来，时间长了，大家都会觉得你是个稳重而谨慎的人，慢慢都会高看你的。 还有的基佬说了，我跟人是打电话啊，怎么办啊？万一续航不给力咋整？ 这我就得说你了电话也是交流，你得学会把话说的言简意赅，比如我给你举个例子： 我给人打电话：“喂，我电话快没电了，咱们见面再说。” 你看，这就言简意赅，既保证了不耽误正事，又用电话把该说的说到了，多好？ 不过这是有前提的，就是电话的电量，得能撑到让你把“我没电了”这句话说完。 所以，这就是我对手机通话续航的底线。超过这个底线的手机，能用？ 好，上面说完了基佬们最常用的三块功能，也就是视频上网和通话。 什么？你说游戏？好好好我们继续。 在讨论游戏之前，请别忘了我们是能用党。是连flappybird这种游戏卡了都能忍的能用党。咱们得先把这个话说开。 好，作为一个能用党，你的电池能撑到玩过50根管，这个游戏基本上就能玩了。其实50根管有点多了，那就1根管吧。别嫌少，万一你看着那个缺口就要飞过去结果没电了，请想象下那个时候你得有多想砸手机吧。所以玩游戏的底线，就是玩像素鸟至少能撑到过第一根管吧。 很好，我们现在基本上已经提到了手机使用的时候的方方面面。至于待机什么的，无所谓啦，反正晚上睡觉都能插电，也不会有手机没电了闹钟没叫起来的情况发生，所以这个其实对于能用党来说都是可以接受的啦。 以上基本说完了能用党对续航的一些标准。基佬们如有雷同可不要对号入座哦
假如，你的报价单里有什么机器是支持联通4g的？ rt，谢谢假如了
GS5拿到工信部认证，看看工信部拟物画风下真实的GS5 今天，我们在工信部发现上述四款设备全部拿到了入网许可，因此我们才能确认SM-G9098并不是移动定制版的Galaxy S5。而三大运营商定制版的Galaxy S5在细节方面也和我们此前猜测的有一定出入。 具体配置方面，三大定制版均采用了骁龙801四核2.5GHz处理器，搭载5.1英寸1080p分辨率Super AMOLED显示屏，内置2GB内存和16GB机身存储空间，最大支持64GB micro SD卡扩展，提供一颗1600万像素后置摄像头和一颗200万像素前置摄像头，运行Android 4.4.2操作系统。 具体网络支持方面，电信版SM-G9009D支持cdma2000/CDMA 1X/GSM双卡双待双通，在国际及港澳台漫游时候则能够支持WCDMA网络。 移动版SM-G9008V支持TD-LTE/TD-SCDMA/GSM网络制式，在国际漫游以及港澳台漫游时候则能够支持LTE FDD/WCDMA网络。 联通版SM-G9006V支持TD-LTE/WCDMA/GSM制式，国际漫游以及港澳台漫游时候支持LTE FDD网络。 另外需要注意的是仅电信版支持双卡双待，移动/联通版均不支持双卡双待功能（至少工信部是这么说的），想要联通双卡版的朋友们这次估计要失望了。但移动五模版绝对可以说是神器，期待未来有大神能将其网络锁成功破解。 另外从外观上来看，联通版是最干净的，没有任何运营商标志，而移动版和电信版后壳上均有运营商Logo。 首先是移动版个联通版
关于这次的爆吧 大吧如果中招了的话会撤小吧 小吧中招了会封禁其他小吧 达成连锁效应 如果已经中招了的吧务，请尽快退出浏览器账号登陆，并清空所有浏览器缓存和cookies。 @姬贤雅 @御剑检察官 @Jackoconne
1 下一页