发布日期：浏览次数：7单位简介：小米公司由雷军创办，共计七名创始人，分别为创始人、董事长兼CEO雷军，联合创始人总裁林斌，联合创始及副总裁黎万强、周光平、黄江吉、刘德、洪锋。　　2010年底汀" />
当前位置： &
& [全国]小米科技2017校园招聘
[全国]小米科技2017校园招聘
专业标签：
小米科技2017校园招聘
浏览次数：7
小米公司由雷军创办，共计七名创始人，分别为创始人、董事长兼CEO雷军，联合创始人总裁林斌，联合创始及副总裁黎万强、周光平、黄江吉、刘德、洪锋。
　　2010年底推出手机实名社区米聊，在推出半年内注册用户突破300万。此外，小米公司还推出手机操作系统MIUI，今年6月底MIUI社区活跃用户达30万。日，小米公司通过媒体沟通会正式发布小米手机。米聊、MIUI、小米手机是小米科技的三大核心产品。
不畏探索 Nice to MI you
——小米2017校园招聘火热进行中
一、招聘说明
招聘流程：网申——宣讲——笔试（仅软件研发类职位）——面试——offer
网申条件：2017届应届毕业生
网申时间：9月5日至9月21日
笔试时间：9月23日晚7:00-9:00
特别说明：-之前已经投递过简历的同学无需重复投递，
-笔试试卷以第一投递职位为准
二、招聘类别：
软件研发类：软件研发 / 软件测试
机器学习/算法/自然语言/数据/Android/IOS/PHP/Java/C/C
/前端/测试开发/运维
硬件研发类：硬件研发 / 硬件测试
系统软件工程师/射频/天线/基带/结构/PCB/触控/显示/图像调试/图像测试/连接器/设计/供应链/质量/认证/商务/手机测试
产品设计类：产品经理 / 运营 / 设计师
产品经理/产品运营/交互设计师/视觉设计师
综合管理类：管理培训生
供应链管理/产品管理/项目管理/市场管理/运营管理
宣讲及相关职位信息请持续关注小米官网：http://scc.pku.edu.cn/hr.xiaomi.com
三、小米各团队介绍：
小米手机部负责小米公司核心业务手机的研发设计、供应链管理, 汇聚了业内顶尖人才, 拥有开放高效的工作环境, 配备专业实验室, 致力于为亿万用户打造高性能的智能手机. 小米是中国最具影响力的手机厂商之一, 成立六年以来, 小米已经成为全球第三大手机厂商, 小米手机出货量连续六个季度居中国第一.
小米云平台目前团队200人 , 涵盖MiCloud（小米云服务）, 存储与计算平台, 搜索推荐, 大数据, 人工智能, 消息系统, 账号系统, 生态云，安全，运维等方向. 目前活跃用户超过1亿, 小米云服务已经存储了超过500亿张用户照片, 数据量超过100PB, 未来可能会突破1000PB; 文件存储10P, 结构化数据3万亿条, 日常平均服务请求达到800万次/秒, 服务小米内部130多个业务以及生态链公司23家; MiPush设备连接量过3亿. 随着手机出货量及用户规模的持续增长, 未来的技术挑战及产品优化空间巨大. 其中团队有多位开源社区 Committer.
AI实验室是小米所有智能业务的核心, 是小米的业务大脑, 承担着大部分小米业务的相关决策工作. 小米AI实验室已建立机器学习基础平台, 并利用深度学习、强化学习等方法解决数据管理、用户画像、语音识别、自然语言处理、图像计算、搜索推荐等实际问题, 还负责在小米公司内部推广机器学习及智能化的工作. 小米AI以业务切入研究, 用研究推进业务, 紧跟业界潮流和步伐, 将人工智能界最新最酷的理念真正在工业界推广和实现.
小米VR是小米内部超炫酷的团队, 是小米将技术转化成产品的最前沿阵地, 所涉及的领域包括计算机图形, 图像处理技术, 光学-屏幕一体成像技术, 手势捕捉, 空间定位技术, 三维重建, 声学等, 跨越操作系统、硬件、软件应用以及服务端多个层面的研发, 将最新最炫的体验带给用户.
小米网作为小米官方的网上商店, 短短5年发展速度惊人, 目前已成为国内第三大电商平台. 用户可一站式购买小米全品类产品, 享受安心、便捷的网购体验. 小米网具有完备的电商体系、物流体系和客服体系, 其实力雄厚的技术和营销团队也在不断挑战, 尝试在交易/支付/供应链支持/配送/用户售后服务/营销等领域建立更强大的核心竞争优势.
MIUI经过6年的迭代已更新至最新的MIUI8, 围绕核心应用, 应用分发, 浏览器, O2O,视频, 阅读, 音乐, Push, 安全, 数据广告, 支付, 金融打造的移动生态逐步建设完善, 影响着2亿用户的日常使用. MIUI用户是最活跃的移动互联网人群, 目前已有21款小米应用的日活跃用户超过千万. 我们将继续致力于通过与用户的深度沟通, 采用敏捷的开发模式, 结合人工智能在语音识别, 计算机视觉等方面的进展打造下一代智能化应用, 建立人与手机最自然便捷的沟通方式.
小米支付为小米生态圈打造交易闭环的核心业务. 依托于小米手机 MIUI, 小米是业界唯一有能力实现软硬结合移动支付战略的平台. 截止2016年初, 已实现日交易超过20万笔, NFC城市公交领先全球,
NFC闪付接入银行数处于行业第一梯队. 旗下第三方支付公司捷付睿通, 持有移动电话支付, 互联网支付, 银行卡收单（全国）三块牌照.
小米商业产品部以小米移动生态发起者角色打造的广告平台，服务于小米应用商店, 浏览器, 一点资讯, 小米电视等全线软硬件几十个业务的变现. 基于高并发系统架构 海量数据处理 大规模机器学习的实际应用, 支持应用游戏下载, 信息流, 搜索, 开屏, 视频贴片, 电视画报等十余种主流和创新的移动广告形式. 专注于移动原生广告, 多屏互动, 以及基于2亿MIUI用户画像的精准投放. 当前流量日曝光过十亿次，2016年收入目标数十亿.
小米金融背靠庞大的小米生态圈, 利用小米海量数据, 线上线下立体渠道, 稳步打造小米全链条金融服务, 涉及消费类个人贷款, 征信, 投资理财等服务. 小米金融团队是由金融及互联网各路大咖组成的精英团队, 相信在不远的将来, 小米金融将成为国民级金融服务平台.
智能家居战略包含小米智能家庭平台和米家产品两部分, MIOT通过提供嵌入式软硬件开发组件,云服务, 基于MIUI的设备虚拟化服务, 统一入口, 实时设备接入服务及大数据分析平台, 大大推进设备智能化落地速度, 同时为各类智能硬件厂商提供全面共赢的系统化解决方案. 目前米家APP安装用户超过5000万, 日活超过500万; 接入在线设备总数近4000万; 米家品牌智能硬件联网率超过80%.
小米路由器总销量突破700万台, 已成为中国智能路由器品类第一. 小米路由器具有独立操作系统、有较强运算能力, 甚至可以实现电脑大部分功能, 小米路由器不仅是家庭网络枢纽, 也是屈指可数的平台级产品, 已联合腾讯、百度、迅雷、爱奇艺等团队共同开发出大量高质量的应用服务, 目前可触发的连接的设备超过8500万台, 具备极大的想象空间.
互娱作为小米公司核心业务之一, 由小米游戏、小米直播、小米电竞三大业务组成, 旨在向米粉和全网用户提供“最好玩”的互联网娱乐服务. 其中, 小米游戏主要承担手游联运及发行业务, 已发展成行业极具市场竞争力的业务模块. 自2015年起, 小米游戏中心便成为最大的安卓游戏分发平台之一, 年分发量超过14.5亿. 截止2016年8月, 小米互娱已连续发行《西游降魔篇3D》、《COK列王的纷争》、《老九门》等多款深受用户喜爱的精品手游. 正在推广的旗舰级3D大作——《剑侠世界》手游, 也于近期创下500万人预约的行业纪录, 为2016年下半年最令玩家期待的手游大作. 正在快速成长的小米直播, 瞄准的则是时下最具创造力的移动直播业务. 在这个年轻、激情、战斗力爆表的团队中, 你将与各界名人、明星一起搭档, 策划出一期又一期激动人心的直播节目. 另外, 蓄势待发的小米电竞则是专为米粉推出的游戏竞技赛事, 并订制出《小米枪战》、《小米超神》、《小米战神》三款分别涵盖FPS类、MOBA类和格斗类的竞技手游. 未来, 小米电竞将围绕这些产品, 通过竞技游戏联赛, 与千万玩家共同营造热爱竞技、热爱游戏的大家庭.
小米电视团队专注于前沿智能电视领域, 小米电视、小米盒子等产品均在短时间内迅速成为影响整个中国消费电子市场的明星产品, 并保持着千万级的日活跃用户. 小米电视在影视, 体育等内容领域, 将持续以聚合开放的模式打造出一个完整的内容生态, 为用户提供更优的跨屏体验.
四、宣讲行程
宣讲会现场有神秘大奖抽取，期待同学们的到来~
大连理工大学
19:00-21:00
科技园报告厅
哈尔滨工业大学
19:00-21:00
19:00-21:00
华中科技大学
19:00-21:00
研究生活动中心
西安交通大学
19:00-21:00
西安电子科技大学
19:00-21:00
本部（北校区）
阶梯教室114
中国科学技术大学
18:30-20:30
西区活动中心二楼学术报告厅
19:00-21:00
安中楼报告厅
19:00-21:00
电子科技大学
19:00-21:00
清水河校区
电科院报告厅
19:00-21:00
北京邮电大学
14:00-16:00
19:00-21:00
大学城校区
请进入投递简历
职位专业分类：
相关专业最新招聘信息
热门招聘信息
　　　　　
　　　　　
名企校园招聘如何提高一个研发团队的“代码速度”？
阿里妹导读：Code Velocity（代码速度），体现了一个研发团队快速响应业务需求的能力。如果做得好，代码从commit到上线可能平均只需要两三天时间，甚至连紧急发布都不怎么需要了。
今天，蚂蚁金服国际事业群技术风险部研究员南门，将和大家聊聊Code Velocity，希望能在团队效率问题方面，为你带来一些启发。
什么是代码速度（Code Velocity）？
Code Velocity的定义是：一段代码变更，从git里的commit time，到在生产环境里运行，中间经过了多少时间。换句话说，代码从写完开始，多快能到达生产环境。
举个例子，C公司的一个团队，他们今天的code velocity一般在是2-4周左右：
他们的一个典型的迭代周期是4周???：第一周系分测分，第二、三周coding、testing、修bug，第三周末或第四周初合并回master、部署集成测试环境、跑回归、上预发、上生产环境。在这样的迭代节奏和“分支开发、主干发布” ??? 的模式里，从commit time到进生产环境，平均是2周左右。
他们还有一些比较长周期的项目。例如，有几个项目是四月中上旬拉的分支，一直到五月下旬才合回master，六月初发布上线。从四月上旬到五月下旬，这几个项目分支里的代码没有合回master过。这几个项目的code velocity就比较长，平均是4周左右。
为什么要度量和提高Code Velocity？
Code velocity体现的是一个研发团队快速响应业务需求的能力。
以上文C公司这个团队今天的快速响应、交付的能力水平，在两周一次发布窗口的节奏里，大部分时候可能已经够了，但一旦遇到各种意外，就捉襟见肘了，例如：临时封网，需求变更，项目因故延期等。
快速响应、快速交付的能力要有一定的“储备”，这就好像足球运动员要有体能储备：要想赢下加时赛，就要有踢两个加时赛的体能。研发团队要能在两周一次发布窗口的节奏里游刃有余，就要有一周一发甚至一周两发的能力。况且，可以预见在不远的将来，两周一次的发布窗口也嫌太久了，业务压力会倒逼一周一发成为常态。那时候，这个团队就要有“天天发”的能力，才能游刃有余。
研发团队的code velocity和他们拿到的业务结果之间的关系，就像饭店上菜时间长短和生意火不火之间的关系一样，两者是相关的，但不是强因果关系：
有些饭店上菜挺快的，但生意不火。不能就因此说“上菜时间长短”不重要。
有些饭店，上菜很慢，但生意也还是很火。也不能因此就说“上菜时间长短”不重要。
一家饭店要火，还要看地段、装潢、菜单、原料、厨子、服务员、宣传等。
除了快速响应业务需求以外，提高code velocity还能帮助开发和测试同学降低项目并发、减少上下文切换、提高幸福感。在两周一次发布窗口的节奏下，很多时候研发同学把一个需求写完、测完，要等其他需求，等集成环境测试，再回来搞一波，然后到了生产环境发布再回来搞一波。事情是不连续的，开发测试其实是被打断的。Code velocity提高了以后，开发测试有连续性，写完了测完了的代码就发走了，研发同学也不用身上同时背着一串项目了。
为什么Code Velocity快不起来?
仔细想想，一段代码从git commit到生产环境，这个过程中时间大部分是花在等待上的：等着和其他代码一起发布上线。之所以会要把很多代码合到一起，每两周发一次，是出于cost vs. benefit的权衡：
每次常规发布，不管payload（即发布的代码量）有多大，有些固定工作是逃不掉的：
首先，由于采取了“分支开发、主干发布”的模式，代码要从各个项目分支和迭代分支合并回master，要解决冲突，确保合并时没有漏代码。
然后，要对master里的代码跑一次全量的回归：准备环境、部署代码和配置、执行回归测试用例、分析结果。这个过程做一遍，短则半天一天，长则两三天甚至更长。如果发现问题，需要修bug，这个过程还要再重复。
与此同时，有些团队还要写发布计划，详细列出发布的步骤：要改哪些配置，各个系统的发布顺序是什么，回滚的步骤是什么，等等。发布计；划写好了还要评审。
最后，要走一遍发布流程：先上预发，上去以后QA要做预发验证；上生产环境，按照发布计划一步步做，蓝绿切流的过程中要让各个系统的owner确认OK，再继续蓝绿切流。整个发布过程需要很多人的协同。
在某些项目中，把代码拆成小块分多次发布会增加开发的难度和工作量。
例如，X系统的API增加了一个新参数，要求Y系统在调用这个API的时候必须要传这个参数。如果两个系统上的代码变更一起发（而且是蓝绿发布），就比较简单。但如果把这个工作拆解成小块，开发工作就变复杂了：X的API新增的这个参数必须先做成optional的，等Y那边的代码改好发上线了以后，再把X的这个新参数改成required。
另外，在有些实际项目中，实际情况比上面举的这个例子更复杂，并不是那么容易一眼就能看出来怎么拆解的。
如何提高Code Velocity？
要提高code velocity，就要对上面提到的这些原因对症下药，提升四个关键能力：
能频繁地把代码合回master
非常强大的跑回归的能力
一键部署乃至无人值守发布的能力
把大项目拆成小项目做的能力
提高code velocity，要实现质的飞跃，第一个能力“能频繁的把代码合回master”是关键抓手。把这个能力建设好了，提升code velocity的四个关键能力中的三个就具备了，因为“能频繁地把代码合回master”有三个前置条件：
实行了代码门禁
有非常强大的跑回归的能力（即上面四个关键能力的第二个）
把大项目拆成小项目做的能力（即上面四个关键能力的第四个）
代码门禁（Gated Checkin）
代码门禁能够确保每一个进入主分支???的commit都达到了一定的质量标准，例如：编译必须通过，单元测试和接口测试必须通过，新代码的覆盖率不能低于某个水平，静态代码扫描必须通过，等等。其实今天很多公司已经有post-checkin的CI在跑这些检查项了。代码门禁看似平淡无奇，无非就是把这些检查项从post-checkin挪到了pre-checkin。但别小看这一挪，它的效果，不亚于把“当月业绩决定本月提成”改成“当月业绩决定下月提成”的效果。
代码门禁是很典型的“测试左移”的做法，和我们对质量的基本规律的认知也是一致的：问题发现得越早，修复起来代价越小。实施了代码门禁后，能确保主分支常年处于良好状态。代码门禁实施起来也很容易，很多开源和商用的CI/CD平台都支持，例如GitLab+Jenkins。
只要做得好，代码门禁是不会降低工程师的日常效率的。“做得好”的标准是：
执行时间：一般能接受的是10-20分钟，95%的情况下不应超过30分钟，否则体感就不好了。
False negative率：也就是说，代码门禁如果失败，有多少比例是因为代码（包括测试用例代码）本身的确有问题，有多少是因为代码门禁的infrastructure的问题（比如，底层机器的资源和稳定性）。一般来说，要把false negative率控制在5%以下。False negative率如果达到20%-30%（也就是说，五次失败里面就有一次失败是跟提交的代码变更无关的），团队里面就会开始怨声载道了。
非常强大的跑回归的能力
有了强大的回归能力，就能在代码频繁的合并回master的情况下，仍然保持master分支处于可发布状态或者接近可发布的状态，有了强大的回归能力，我们甚至可以把一小部分的回归放到代码门禁里面去跑，那将会进一步有助于保持master分支处于可发布状态。
回归能力的强大体现在以下几方面：
无人值守：准备环境、部署代码和配置、执行测试、拿回结果，整个过程都必须没有任何人的参与。
频次：跑回归不嫌多，最理想的是每次CI都跑回归，那样发现问题更早、定位问题更精确。
覆盖率：主要是业务覆盖率???。
稳定性：很高的通过率，很低的噪音率，结果非常repeatable。
执行时间：也许6小时和4小时看上去没有什么大差别，其实是有本质区别的。如果回归跑一遍要6小时，那么“改代码-跑回归-看结果”这个过程一天只能干两轮；但如果回归一遍只要4小时，那么这个过程一天就能干三轮。如果能再缩短到2小时，一天就能干六七轮。
这几方面的回归能力相互之间是相辅相成的，能够形成正循环，产生“飞轮效应”：
回归的运行，只有真正做到了无人值守，才有可能长期高频次运行。
高频次的运行，可以充分暴露各种稳定性问题，提高回归的稳定性。
缩短执行时间，一方面可以缩短“反馈弧”，加速各种稳定性问题的修复，另一方面可以提高测试环境的“周转率”，在不增加硬件成本的前提下实现更高频次的回归。
提高了稳定性，可以缩短用于分析回归结果的时间。如果一个有5,000个用例的回归用例集只有90%的通过率，那每次跑完回归有500个失败的用例需要分析
? ??。但如果通过率有99%，那就只有50个用例需要分析了。
强大的回归能力的背后需要的支撑能力是：
优质的测试环境：要在预算允许的范围内，确保测试环境的稳定和资源充沛，这样才能支撑起回归的稳定性和高频次执行。
配置代码化（configuration-as-code）的能力。今天常见的web-based centralized配置变更管理模式不足以支持高频词、高并发的回归运行模式。实现了配置代码化，才能实现快速的环境部署，以及在不同的环境之间用不同的配置跑回归。配置代码化并不是简单地把配置写在config文件里面，和代码一起打包发布。配置代码化是对这种config文件做法的否定之否定：配置可以在git里面修改；配置也可以在配置管理系统里面直接修改，变更会回沉到git里面。部署的时候，部署工具会把git里面的配置值以增量的方式推到配置管理系统里面。
把大项目拆成小项目做的能力
如前所述，把代码拆成小块分多次发布，的确是会增加开发的工作量的。有不少开发同学不理解为什么要这样做。增加了这些工作量，能让我们的研发模式更加敏捷。这个代价是值得付出的，这些额外的时间是值得花的。
大项目拆成小项目做的一些常见套路包括：
分两部走：先向下兼容，再去掉兼容性。这就是前文举的那个例子：X系统的API增加了一个新参数，要求Y系统在调用这个API的时候必须要传这个参数。拆成小项目的拆解方法是：首先，X的API新增的这个参数做成optional的，把X发布上线。然后等Y那边的代码改好发上线了以后，再把X的这个新参数改成required，再发布一次X。或者，也可以用一个feature flag来控制这个新参数是否required。
Feature flag：有了feature flag，新功能的代码写了一半也没关系，可以把feature flag关掉，就算代码发上线了也不会被执行到。有时候，有些新功能所需要的代码变更是改动在老代码里面的。这样的代码变更无法用feature flag来屏蔽。但这也没关系，因为我们有强大的回归能力，能尽我们所能确信这些的代码变更至少不会break老功能、不会在发上线后造成故障。Anyway, 哪怕不是为了把大项目拆成小项目，feature flag也是需要的。Feature flag、白名单等都是很常见的continuous delivery手段。
Capability probing：很多新功能涉及整条链路上各个系统的改造。现在往往上游系统的发布依赖于下游系统的发布。解耦这种依赖关系的一种方法是让每个系统都通过一个统一的API接口来暴露自己当前的能力。这样，上游系统可以判断下游系统当前是否支持某个新功能所需要的能力Foo（例如，某种支付渠道），根据结果走不同的code path。
按域独立发布也是一种很成熟的拆分的方法。按域独立发布，实现域和域之间的解耦，能减少每次发布的系统的数量，降低发布风险，增加发布的灵活度。
大项目拆成小项目，还需要有比较强的需求拆分的能力：能够把一个全链路级别的需求文档拆分成域级别、系统级别的需求，这样每个域、每个系统可以“分而治之”。
Code Velocity和质量、线上稳定性的关系
从上面的分析可以看出来，提高code velocity并不是以牺牲质量为代价的。上面这些提高code velocity的手段，并没有cut corner，并没有降低质量标准，并没有比今天少执行任何测试。即便是频繁的把代码合回master，即便是把大项目拆成小项目做，该运行的各种验证和测试还是继续运行。而且，为了要提高code velocity，实行了代码门禁，建设了强大的跑回归的能力，反而是对质量有提高作用的。
提高code velocity也并不会降低线上稳定性。把大项目拆成小项目做、更加频繁的发布小块代码，能够降低单次发布的风险；发布中如果出了问题，因为payload小，排查和回滚也更方便。另外，在投入资源提高code velocity的同时，我们不会降低对故障发现能力、止血能力、应急能力、监控核对等能力的投入。提高code velocity不会导致线上技术风险防控体系变弱。
如果一个团队的“能频繁的把代码合回master”的能力做得足够好了，就可以完全抛弃项目分支和迭代分支，每一个commit都直接checkin进master，而且master分支每天都有若干个可以发布的版本???，每个版本都可以用一个不同的release分支来保存。这就是所谓的“主干开发、分支发布”（Trunk-based Development）模式了。
到那时候，就有做到“天天发”的能力了。那时候，代码从commit到上线可能平均只需要两三天时间。那时候，因为有了“天天发”的能力，甚至连紧急发布都不怎么需要了。
如果你希望加入蚂蚁金服国际事业群，可以随时与我们直接联系。Java开发、测试开发、SRE工程师和工具开发等岗位虚位以待，有兴趣的童鞋可发简历至：
intl_hire_account@service.alipay.com
1.一般会有两个为期四周的迭代并行，每个迭代有自己的目标发布窗口。发布窗口一般是每两周一次。
2.“分支开发、主干发布”的开发模式来自于A successful Git branching model。但这种模式在实践中是有不少问题的（参见A succesful Git branching model considered harmful）。更好的模式是“主干开发、分支发布”（aka. Trunk-based Development)
3.主分支可以是master，也可以是项目分支或者迭代分支。
4.单元测试和接口测试看代码覆盖率，回归测试看业务覆盖率。这在行业内的一部分开发和测试之间已经形成共识了。
5.当然，我们可以用技术的手段使得分析500个失败的用例变得更容易。但这并不应该成为我们不去提高通过率的理由。
6.版本：对于“大库模式”(monolithic repo)来说就是一个commit，对于“小库模式”来说就是每个repo的一个commit构成的一个“截面”。
每天一篇技术文章，
看不过瘾？
关注“阿里巴巴机器智能”微信公众号
发现更多AI干货。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点探秘小米盒子mini版成功的原因之明星研发团队（一）|小米盒子|mini|成功_新浪新闻
　　自从小米盒子mini版推出以来，广受用户好评，市场销量节节升高。谁都明白，每一个产品不可能随随便便成功，产品成功的背后凝聚了整个团队的心血。小米盒子mini版就是有着这样一个明星研发团队，每个人各司其职，齐心协力，尽职尽责，将事情做到极致。下面就来领略一下小米盒子mini版幕后英雄们的风采。
　　不止变小，而是重新发明机顶盒
　　—— 小米科技合伙人 王川
　　小米盒子mini版的真正意义并不在于变小，而是站在用户的角度重新“发明”机顶盒。打破了很多传统规则，摒弃了电源适配器， 采用电源直插设计，整机只有一个接口和一跟HDMI线，在提升易用性的同时，也带来了令人惊艳的美感。
　　如何将用户体验做好?
　　—— 小米盒子负责人 戴青松
　　没有高科技产品带来的复杂感，小米盒子mini版的设计有三大特点：第一是简单，我们反复地推敲用户从拿到盒子到安装完成、开始使用的整个过程，最后决定只做一个插口，连接起来就能用，老人孩子都能很容易的安装设置，没有高科技产品带来的陌生感;第二是非常便携，带它去旅行、出差，跟拿起手机出门一样，没有额外的东西，不会感觉到别扭;第三是融入，只占一个插线孔的位置，可以轻松地插在墙上或者放在电视机的后面，你几乎会忘记它的存在。
　　用做手机的工艺去做盒子
　　—— 主板工程师 常江
　　如何将电源、主板放在不足上一代盒子四分之一的面积内?小米盒子mini版(小米小盒子)的面积不足上一代盒子四分之一，空间非常紧张。为了实用性，把电源插片转轴做在了盒子内部，使得原本狭小的空间又被占去三分之一，还得把主板、电源板和散热片一起放入，其中主板作为整个硬件信息处理的核心，在如此小的板级设计中把CPU、DDR内存、eMMC闪存、WiFi/蓝牙等282个元器件都放进去，是极其困难的，另外为了保证WiFi天线处理性能，需要屏蔽外界和系统本身的辐射干扰，又增加3个屏蔽罩更是难上加难;同时为了确保品质，我们坚持使用6层板，而不是采用相对低廉的4层板。为此我们选择了极小的0201元器件，多数大小仅0.3毫米左右，同时在加工厂的大力支持下，我们一起不断挑战生产极限，最终成功完成任务，几乎可以说我们是在用手机的工艺做盒子。
　　软硬兼施，从硬件到软件全方位降温
　　—— 结构散热工程师 马立奇/贺孟华
　　系统软件散热工程师 王爱军
　　应用软件工程师 江波
　　没有散热孔，如何在密闭的狭小空间内达到良好的散热效果?反复尝试后发现增大铝制散热片的面积是有效的解决方案小米盒子mini版(小米小盒子)是一个极小的密闭空间，内部有主板和电源板两个热源同时发热，在没有散热孔的情况下解决散热极其困难。为此，我们尝试了很多方案，比如传导速度快的石墨材料、将热能转化为红外线往外辐射的纳米碳涂层以及导热铜箔加上散热器，但都达不到好的散热效果。通过实验发现，传统铝制散热片的面积越大，散热效果越好，它可以将CPU释放的热量充分吸收，然后导出壳体，从而达到使CPU及外壳共同降温的效果。于是在不影响天线性能的前提下，在有限的空间内将铝制散热片尽量做大，将其高度从最初的17mm增加到了30mm，最终在结构散热方面，达到了比较理想的降温效果。
　　本稿件所含文字、图片和音视频资料，版权均属齐鲁晚报所有，任何媒体、网站或个人未经授权不得转载，违者将依法追究责任。
更多猛料！欢迎扫描下方二维码关注新浪新闻官方微信(xinlang-xinwen)。
澳大利亚政坛连年震荡，这次继陆克文之后，又迎来了一位“知华”“亲华”的总理——特恩布尔。此前与安倍眉来眼去的阿博特黯然下台，离开会场时，未置一词。日本媒体不禁担忧日澳关系的走向，中国舆论则对特恩布尔报以极大的热情。不过这位总理真的会大幅提升中澳关系吗？
就算购买汽油为实(官方未提供发票等证据)，也不能坐实他要自焚，因为两者并不存在必然联系。据其侄子张勇讲，张纪民家中有浇水用的抽水机和农用车，这些器械都要用汽油，难道他就不是为了生产买汽油？
以军训为教育的开端，是教育界向强权低头的起点。在和平年代，身体上的军训应该废除，代之以理论上的国防和军事战略教育，我们需要的是继往开来的创新创业者，而不是一群唯唯诺诺只会说“是”不敢说“不”的奴才。
对于由蓝转绿，星云大师披露自己是71年党龄的国民党党员：我至今年近九十，做了近八十年和尚，七十一年的国民党党员，我不忘初心，不会改变做和尚与党员的身份”。