IT瘾谷歌推荐

谷歌、Anthropic双重围剿下的OpenAI，正面临「生死抉择」

Sun, 25 Jan 2026 21:17:47 CST

进入到 2026 年，OpenAI 在关注消费级产品（如 ChatGPT、社交应用）之外，开始将一部分重心转向企业级市场。

上周五，我们报道了 OpenAI 正在考虑转变商业模式，不满足于只收软件使用费，还想在客户发财时抽成。详细内容请参考《OpenAI：以后大家用 AI 赚的钱，我可能要抽成》

今日，据外媒 The Information 最新报道，OpenAI 传递出了清晰的战略转型信号，表明其正全方位发力企业端业务，力求为商业客户提供深度支持。

事情是怎样的呢？我们接着往下看。

OpenAI 战略重心转移，进一步押注企业市场

过去的 2025 年，OpenAI 最引人注目的动作大多集中在消费级产品上，包括 GPT‑5 系列模型、Sora 2、ChatGPT Atlas 浏览器等。今年晚些时候，OpenAI 预计还将发布一款由前苹果设计总监 Jony Ive 参与设计的 AI 硬件设备，据悉可能是可穿戴设备。

不过就在上周，OpenAI CEO 奥特曼在旧金山召集了一场由迪士尼 CEO 鲍勃・艾格及其他企业高管参与的聚会，传达出了进一步服务企业用户的意向。

据一位知情人士透露，奥特曼告诉与会者，OpenAI 可以成为满足他们所有 AI 需求的一站式商店，从对话机器人 ChatGPT 到编程工具 Codex，再到自动化工作流模型。

另一位知情人士表示，此次聚会还旨在预热 OpenAI 专门针对大型公司的一项新方案，协助它们进行大规模的 AI 转型，将 AI 整合进客户服务、旧应用代码改写、企业数据组织等各类业务运营中。

此外，这项新方案还旨在统一企业的 AI 使用力度，其中可能包括将 OpenAI 的各种产品打包，以便企业客户更轻松地追踪其开支。不过，相关具体细节尚未披露。

OpenAI 在企业市场展开的更多动作，其背后希望将企业客户从劲敌 Anthropic 手中争取过来。

过去一段时间，Anthropic 的编程和办公自动化工具 Claude Code 以及 Cowork 引起了业界的广泛关注。

去年推出的 Claude Code，具备强大的编写和修改代码的能力。据一家每月在 OpenAI 和 Anthropic 上投入数百万美元的初创公司 CEO 称，对某些客户而言，这比员工用于常规任务和搜索的聊天机器人更能提高生产力。

最新产品 Cowork 掀起了一场打工人的革命。它不再像 Claude Code 一样专门面向程序员，而是把大模型与智能体能力推进到电脑桌面上，可以解决大部分人的工作问题。

相反，OpenAI 的某些产品（如处理电子表格等知识工作的智能体）表现未能达到预期。

就在昨天，奥特曼发推表示：「从下周开始的接下来一个月，我们将会发布很多与 Codex 相关的激动人心的东西。」这预示着 OpenAI 对标 Claude Code 的编程工具即将迎来升级。

OpenAI 也一直在为 ChatGPT 添加协作以及其他更多办公功能，并推出了针对特定行业的垂类产品，比如医疗的 ChatGPT Health。

与此同时，OpenAI 在过去一年还重组了销售模式：由一名销售人员向客户推销多种产品，而非由多名代表分别推销不同的产品。前段时间从 Thinking Machines Lab 挖回来的顶级人才 Barret Zoph 将专门负责面向企业客户的 AI 商业化业务，以期占领更多企业市场。

目前，OpenAI 约 40% 的收入来自企业客户。OpenAI CF Sarah Friar 周三在达沃斯表示，到今年年底，约 50% 的业务将来自企业客户。

生成式 AI 流量：从一家独大到群雄逐鹿

OpenAI 发力企业市场的另一大原因，是其自身生成式 AI 的流量面临着谷歌 Gemini 等其他大模型竞品的紧紧追赶。

今天，有 X 博主发帖称，「谷歌迟早会抢光 OpenAI 的饭碗，而且速度会比人们想象的还要快。奥特曼这下麻烦大了。」

这位博主展示了一张出自 Similarweb 的生成式 AI 流量份额的变化趋势图表，直观地反映出了该领域正从「一家独大」走向「群雄逐鹿」。

我们首先看到，OpenAI 的领先地位正在被蚕食。12 个月前，OpenAI 占据绝对的市场统治地位，份额接近 90%。随着时间推移，其份额持续下降，到现在已经降至 65% 左右。虽然它仍然保持第一，但市场份额一路走低。

其次，谷歌 Gemini 成为最大的挑战者。12 个月前，它的存在感还非常低，但现在的份额已经跃升至第二位，占据了约 20% 的市场。这说明，谷歌正在凭借其强大的生态集成能力迎来爆发式增长，并迅速抢占流量份额。

接着是第二梯队的崛起，包括 DeepSeek、Meta、Claude、Perplexity 和 Grok ，虽然单拎出来份额较小，但它们也在稳步蚕食原本属于 OpenAI 的空间。

最后是更多垂直领域的工具加入竞争，包括 Manus、Huggingface 等，用户有了更多样性的入口选择。

在评论区，还有人指出了更多问题，包括高净值客户的流失，「从客户价值的角度来看，OpenAI 其实处于垫底水平。相比之下，大多数 Claude 用户每个月的开销都在 200 美元左右。」

在同样出自 SimilarWeb 的另一张图表中，展示了 2025 年各大模型厂商的每月独立访客（MUV）的增长数据，以及市场渗透率变化。

其中 ChatGPT 每月独立访客（MUV）增长达 3060 万，渗透率从 1 月的 71% 增长到 11 月的 77.3%；谷歌 Gemini 增长了 1420 万月活，渗透率从 15.1% 跃升至 24.2%，增幅最大；Grok 渗透率也从 0.2% 飙升至 6.7%；Claude 的 MUV （320 万）和渗透率（5.3%）也在稳步增长。

一方面是流量红利消退，一方面要面对谷歌、Anthropic 等强劲的竞争对手，OpenAI 似乎走到了不得不转型的十字路口。

^{参考链接：}

^{https://www.theinformation.com/articles/openai-aims-lure-businesses-anthropic?rc=jn0pp4}

^{https://x.com/venturetwins/status/2014739492389978274}

^{https://x.com/Mayhem4Markets/status/2015172827289161992}

谷歌CEO警告：AI泡沫破裂时，无一家公司能够幸免

Tue, 18 Nov 2025 20:26:00 CST

　谷歌CEO警告：AI泡沫破裂时，无一家公司能够幸免

article.author.display_name

张雅琦

谷歌CEO警告，当下AI热潮含有“非理性”成分，一旦泡沫破裂，没有任何公司能完全幸免。尽管AI被视为最深刻的技术并有望带来长期价值，但当前估值飙升与巨额投入已令人联想到互联网泡沫。谷歌凭借“全栈”技术具备抵御能力，但仍面临能源需求飙升、气候目标推迟及就业冲击等挑战。

谷歌母公司Alphabet的首席执行官Sundar Pichai发出了一个罕见的警告：当前的人工智能热潮中存在“非理性”成分，一旦潜在的泡沫破裂，没有任何公司能够幸免，即便是谷歌也不例外。

在近日接受媒体的专访时，Pichai承认AI投资的增长是一个“非凡的时刻”，但也直言当前的繁荣中存在“非理性”的因素。这一表态正值硅谷内外对AI泡沫的担忧日益加剧之际。近几个月来，AI科技公司的估值一路飙升，企业在该领域的投入也达到了惊人的规模。

当被问及如果AI泡沫破裂，谷歌是否能免受冲击时，Pichai表示，这家科技巨头有能力抵御潜在的风暴，但也发出了警告：“我认为没有公司能够幸免，包括我们。”

在这次内容广泛的专访中，Pichai还谈及了AI带来的巨大能源需求、公司气候目标的延期，以及这场技术革命对就业的深远影响，勾勒出一幅机遇与严峻挑战并存的复杂图景。

AI热潮中的“非理性”时刻

市场对AI的狂热，已让人联想起上世纪90年代末的互联网泡沫。当时，对新技术的乐观情绪将早期互联网公司的估值推至高点，但泡沫最终在2000年初破裂，导致大量公司倒闭、股价崩盘，并冲击了人们的储蓄和养老基金。分析师们对围绕OpenAI进行的约1.4万亿美元的复杂交易表示怀疑，而该公司今年的预期收入不到计划投资额的千分之一。

Pichai关于“非理性”的评论，呼应了前美联储主席格林斯潘（Alan Greenspan）在1996年互联网泡沫破裂前提出的“非理性繁荣”的著名警告。Pichai表示，在这样的投资周期中，行业可能会出现“过度投资”。但他同时认为，“我们可以回顾一下互联网。当时显然有很多过度投资，但我们没有人会质疑互联网的意义是深远的。我预计AI也会是同样的情况。”

这位谷歌掌门人的看法也得到了华尔街的呼应。摩根大通首席执行官戴蒙（Jamie Dimon）上月曾表示，对AI的投资终将获得回报，但投入该行业的部分资金“可能会打水漂”。

尽管Pichai警告“没有公司能够幸免”，但他表示，谷歌拥有独特的“全栈”技术模式，是其抵御风暴的信心来源。

这一模式涵盖了从芯片到数据、再到模型和前沿科学的完整技术链条。具体而言，Alphabet正在开发可与英伟达竞争的AI专用超级芯片；同时，其拥有的YouTube等平台提供了海量数据资源。

AI是人类迄今“最深刻的技术”

Pichai将AI称为人类迄今为止研究的“最深刻的技术”，并预言它将重塑我们所熟知的工作模式。“我们将不得不经历社会的颠覆性变革，”他说，但这也会“创造新的机会”。

他认为，AI将“演变和转变某些工作岗位，人们需要适应”。那些学会适应AI的人“会做得更好”。他强调：

“无论你想成为老师还是医生，所有这些职业都会继续存在，但在这些职业中表现出色的人，将是那些学会如何使用这些新工具的人。”

与此同时，Alphabet也在加大对关键市场的战略布局。该公司已承诺在未来两年向英国投资50亿英镑，用于基础设施和研究。Pichai表示，Alphabet将在英国开展“最先进的”研究工作，其关键的AI部门DeepMind总部就设在伦敦。他还首次表示，谷歌将“随着时间的推移”在英国“训练我们的模型”，此举被英国政府视为巩固其作为仅次于美国和中国的全球第三大AI“超级大国”地位的关键一步。

AI的飞速发展并非没有代价，其巨大的能源需求正成为一个日益严峻的挑战。Pichai警告称，AI的能源需求是“巨大的”，并指出需要采取行动，包括在英国，以开发新的能源并扩大能源基础设施的规模。“你不会希望因为能源问题而限制经济发展，我认为那会带来后果，”他表示。

风险提示及免责条款

市场有风险，投资需谨慎。本文不构成个人投资建议，也未考虑到个别用户特殊的投资目标、财务状况或需要。用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。

喷嚏网官方App :【安卓】在豌豆荚、360手机助手、小米应用商店，搜索：喷嚏阅读；【ios】App store里搜索：喷嚏网官方阅读；

喷嚏网官方网站：http://dapenti.com (海外访问：https://dapenti.com)

每天网络精华尽在【喷嚏图卦】喷嚏网官方新浪围脖

刚刚，谷歌放出Nano Banana六大正宗Prompt玩法，手残党速来

Wed, 03 Sep 2025 16:49:51 CST

最近几天，谷歌 Nano Banana 可是被广大网友玩出了新花样。

比如制作精致可爱的产品照片：

^{来源：https://x.com/azed_ai/status/1962878353784066342}

将 13 张图像合并为单个图像：

^{来源：https://x.com/MrDavids1/status/1960783672665128970}

给人一键换衣：

反正你想到的，想不到的脑洞，都被广大网友挖掘出来了。

但别忘了，这些效果可不是凭空生成的。背后真正的魔法，其实是提示词。网友们正是用一条条巧妙的提示词，把这个模型玩出了无限可能。

就在刚刚，谷歌官方公布了 Nano Banana 六个文本转图像提示：

原文链接：https://x.com/googleaistudio/status/1962957615262224511

根据这些提示，你可以进行以下操作：

文本生成图像：通过简单或复杂的文本描述生成高质量图像。
图像 + 文本生成图像（图像编辑）：提供一张图片，并使用文本提示词添加、删除或修改图像元素，调整风格或颜色。
多图合成与风格迁移：输入多张图片，合成新的场景，或将其中一张的风格迁移到另一张上。
迭代式优化：通过对话逐步优化图像，每次做小调整，直到达到理想效果。
文本渲染：生成包含清晰、布局合理文字的图像，适用于 logo、图表、海报等视觉创作。

谷歌强调，这些指令可以最大限度的发挥 Nano Banana 的图像生成能力。

接下来，我们看看这些提示具体包含的内容：

1、照片级写实场景

对于写实风格的图像，要像摄影师一样思考。prompt 中要提及机位角度、镜头类型、光线以及细节描写，这样可以引导模型生成更逼真的效果。

模板如下：

A photorealistic [shot type] of [subject], [action or expression], set in [environment]. The scene is illuminated by [lighting description], creating a [mood] atmosphere. Captured with a [camera/lens details], emphasizing [key textures and details]. The image should be in a [aspect ratio] format.

下图使用的完整 prompt 为「A photorealistic close-up portrait of an elderly Japanese ceramicist with deep, sun-etched wrinkles and a warm, knowing smile. He is carefully inspecting a freshly glazed tea bowl. The setting is his rustic, sun-drenched workshop. The scene is illuminated by soft, golden hour light streaming through a window, highlighting the fine texture of the clay. Captured with an 85mm portrait lens, resulting in a soft, blurred background (bokeh). The overall mood is serene and masterful. Vertical portrait orientation.」

2、风格化插画与贴纸

在制作贴纸、图标或项目素材时，在 prompt 中明确说明需要的风格；另外，如果需要白色背景，记得在 prompt 中提出来。

模板如下：

A [style] sticker of a [subject], featuring [key characteristics] and a [color palette]. The design should have [line style] and [shading style]. The background must be white.

下图使用的完整 prompt 为「A kawaii-style sticker of a happy red panda wearing a tiny bamboo hat. It's munching on a green bamboo leaf. The design features bold, clean outlines, simple cel-shading, and a vibrant color palette. The background must be white.」

3、图上添加精准的文字

Gemini 擅长渲染文字。此类任务最好在 prompt 中明确说明文字内容、字体风格（用描述性的方式），以及整体设计。

模板如下：

Create a [image type] for [brand/concept] with the text "[text to render]" in a [font style]. The design should be [style description], with a [color scheme].

下图使用的完整 prompt 为「Create a modern, minimalist logo for a coffee shop called 'The Daily Grind'. The text should be in a clean, bold, sans-serif font. The design should feature a simple, stylized icon of a coffee bean seamlessly integrated with the text. The color scheme is black and white. 」

4、产品模型与商业摄影

适合在电商、广告或品牌宣传时制作干净、专业的产品照片。

模板如下：

A high-resolution, studio-lit product photograph of a [product description] on a [background surface/description]. The lighting is a [lighting setup, e.g., three-point softbox setup] to [lighting purpose]. The camera angle is a [angle type] to showcase [specific feature].

Ultra-realistic, with sharp focus on [key detail]. [Aspect ratio].

下图使用的完整 prompt 为「A high-resolution, studio-lit product photograph of a minimalist ceramic coffee mug in matte black, presented on a polished concrete surface. The lighting is a three-point softbox setup designed to create soft, diffused highlights and eliminate harsh shadows. The camera angle is a slightly elevated 45-degree shot to showcase its clean lines. Ultra-realistic, with sharp focus on the steam rising from the coffee. Square image.」

5、极简与留白设计

适合用于创建网站、演示文稿或营销素材的背景，并在其上叠加文字内容。

模板如下：

A minimalist composition featuring a single [subject] positioned in the [bottom-right/top-left/etc.] of the frame. The background is a vast, empty [color] canvas, creating significant negative space. Soft, subtle lighting. [Aspect ratio].

下图使用的完整 prompt 为「A minimalist composition featuring a single, delicate red maple leaf positioned in the bottom-right of the frame. The background is a vast, empty off-white canvas, creating significant negative space for text. Soft, diffused lighting from the top left. Square image.」

6、连续性艺术（漫画分镜 / 分镜头脚本）

通过逐格描绘，创作引人入胜的视觉叙事，适合用于开发分镜头脚本、漫画条幅或任意形式的连续性艺术。重点在于清晰的场景描述。

模板如下：

A single comic book panel in a [art style] style. In the foreground, [character description and action]. In the background, [setting details]. The panel has a [dialogue/caption box] with the text "[Text]". The lighting creates a [mood] mood. [Aspect ratio].

下图使用的完整 prompt 为「A single comic book panel in a gritty, noir art style with high-contrast black and white inks. In the foreground, a detective in a trench coat stands under a flickering streetlamp, rain soaking his shoulders. In the background, the neon sign of a desolate bar reflects in a puddle. A caption box at the top reads "The city was a tough place to keep secrets." The lighting is harsh, creating a dramatic, somber mood. Landscape.」

这一套 prompt 模板学下来，你大概就能掌握使用 Nano Banana 的精髓了。

不过，用户在使用中还有其他困扰，比如「在对已有图像进行编辑时，模型往往会返回一张一模一样的图像。」

另外有人指出了 Nano Banana 在编辑时存在的更多问题，「它在一致性上表现不如 Qwen 和 Kontext Pro，也不够稳定，特别是在持续对话过程中。对于文本转图像，直接用 Imagen 会更好且更可控。」

大家在使用 Nano Banana 的过程中有哪些独到的心得与技巧？欢迎在评论区分享出来。

超谷歌搜索：阿里开源创新大模型搜索引擎 ZeroSearch，成本直降 80% 且能力更强

Fri, 09 May 2025 07:14:52 CST

IT之家 5 月 9 日消息，阿里巴巴昨日在 Github 等平台开源了 ZeroSearch 大模型搜索引擎。这是一种无需与真实搜索引擎交互即可激励大模型搜索能力的强化学习框架。

ZeroSearch 主要利用了大模型在大规模预训练过程中积累的丰富知识，将其转化为一个检索模块，能够根据搜索查询生成相关内容。同时，还可以动态控制生成内容的质量，这是传统搜索引擎所不具备的特殊功能。

研究人员在 NQ、TriviaQA、PopQA、HotpotQA 等 7 大问答数据集上进行了综合评测。结果显示，一个 70 亿参数的监督微调模型使用 ZeroSearch 后，其搜索能力达到了 33.06；140 亿参数的模型则达到了 33.97，超过了谷歌搜索的 32.47。

研究人员通过 SerpAPI 使用谷歌搜索进行约 64,000 次搜索查询的训练，成本约为 586.70 美元（IT之家注：现汇率约合 4238 元人民币）；而在四个 A100GPU 上使用 140 亿参数的大模型进行模拟时，成本仅为70.80 美元（现汇率约合 511 元人民币），意味着成本降低了 87.93% 以上。

参考链接：

论文地址：https://arxiv.org/abs/2505.04588
开源地址：https://github.com/Alibaba-nlp/ZeroSearch
抱抱脸：https://huggingface.co/collections/sunhaonlp/zerosearch-681b4ce012b9b6899832f4d0

真·开放式游戏，谷歌造出首个无限人生模拟游戏Unbounded

Sat, 26 Oct 2024 15:19:07 CST

无限游戏真的实现了。

如果你是一位开放世界或角色扮演游戏的玩家，你一定梦想过一款无限自由的游戏。没有空气墙，没有剧情杀，也没有任何交互限制。

现在，我们的梦想可能真的要开始成真了。

借助大型语言模型和视觉生成模型的力量，谷歌新开发的一个无限制（Unbounded）游戏已经为我们昭示了这一可能性。

^{Unbounded 一作 Jialu Li 的推文}

这个游戏世界是 AI 生成的，并且可随着游戏的推进而无限延展和演进，里面的角色也可根据用户的要求而定制，同时，这个游戏也不存在任何交互规则的限制。一切都是开放的，甚至你的想象力都无法限制它，就像《安德的游戏》中的心智游戏。

^{电影《安德的游戏》中的心智游戏画面}

虽然目前该游戏整体还比较简单，更多的还是进行一种概念验证，但其隐含的可能性却足以引起人们的无限遐想。

谷歌 Unbounded 游戏设计思路的根源可追溯到 1986 年 James P. Carse（詹姆斯・卡斯）的著作《有限与无限的游戏》，其中描绘了两种不同类型的游戏。

在卡斯的定义中，有限游戏是「以获胜为目的的游戏」，它们有边界条件、固定的规则和明确的终点。而无限游戏的「目标是让游戏继续下去」，没有固定的边界条件，规则也会不断演变。

传统的视频游戏基本都是有限游戏，存在计算机编程和计算机图形的限制。举个例子，所有的游戏机制都必须在编程语言中完全预定义，所有图形资产都必须预先设计（模块化程序生成也仍存在结构限制）。这样的游戏只允许一个有限的动作和路径集，有时候这些动作还是预先定义的。它们通常还有预定义的规则、边界条件和获胜条件。

生成模型的发展为游戏带来了全新的可能性。放开脑洞想想，我们甚至可以造出所谓的「生成式无限视频游戏」。

近日，谷歌和北卡罗来纳大学教堂山分校的一篇论文探索了这一可能性，提出了首个交互式生成式无限游戏 Unbounded，其中的游戏行为和输出皆由 AI 模型生成，从而超越了硬编码系统的限制。

论文标题：Unbounded: A Generative Infinite Game of Character Life Simulation
论文地址：https://arxiv.org/pdf/2410.18975
项目地址：https://generative-infinite-game.github.io/

据该团队介绍，Unbounded 的灵感来自《小小电脑人》、《模拟人生》和《拓麻歌子》等沙盒人生模拟和电子宠物游戏。其还整合了《龙与地下城》等桌面角色扮演游戏的元素，此类游戏能提供视频游戏不具备的无限制讲故事体验。

Unbounded 的游戏机制围绕角色模拟和开放式交互，如图 2 所示。

玩家可以将自己的角色插入游戏，定义自己角色的外观和个性。游戏会生成一个世界，这些角色可以在其中探索环境、与物体互动并进行对话。游戏会根据玩家的行为和选择生成新的场景、故事和挑战，从而创造个性化和无限的游戏体验。下图显示了一些生成游戏示例。

具体来说，Unbounded 具有以下功能：

1. 角色个性化：玩家可以将自己的角色插入游戏，定义自己的外观和个性。

2. 游戏环境生成：Unbounded 会生成一个持久的世界，让角色可以探索和互动。

3. 开放式互动：玩家可以使用自然语言指令与角色互动，并且没有预定义的规则来限制互动。

4. 实时生成：该团队强调了游戏速度的重要性，与初级实现相比，实际游戏实现了 5-10 倍的加速，每个新场景的延迟约为一秒。

为了做到这一点，该团队在语言模型和视觉生成方面都做出了一定的技术创新。

方法介绍

Unbounded 是一款由文本 - 图像生成模型和大语言模型驱动的交互式生成无限游戏。

Unbounded 包括：

(1) 个性化自定义角色：用户创建具有可自定义外观和个性的独特角色；

(2) 动态世界创建：系统生成一个持久的交互式游戏世界供探索；

(3) 开放式交互：玩家通过自然语言与角色互动，游戏根据玩家动作动态生成新的场景和故事情节；

(4) 以交互速度生成：游戏以近乎实时的交互性运行，实现接近一秒的刷新率。

潜在一致性模型

Unbounded 的一个关键特性是它能够为完全基于生成模型的游戏提供实时交互。这是通过使用潜在一致性模型 (LCM，latent consistency model) 实现的，该模型只需两个扩散步骤即可生成高分辨率图像。通过利用 LCM，Unbounded 实现了实时文本到图像 (T2I) 生成，这对于提供刷新率接近一秒的交互式游戏体验至关重要。

具有块丢失功能的区域 IP 适配器

Unbounded 的另一个关键特性是在预定义环境中生成角色，并根据用户指令执行不同的操作。

在游戏领域，保持角色和环境的一致性至关重要，目前来看，角色一致性的处理方式上还存在一些挑战。

该研究发现现有方法无法始终如一地满足所有交互速度要求。因此本文提出了一种新颖的区域 IP 适配器（regional IP-Adapter），以便按照文本提示在预定义环境中始终如一地植入角色。

该研究提出了 IP 适配器的改进版本，该版本能够对主体和环境进行双重调节，从而允许在用户指定的环境中生成预定义的角色。与专注于单图像调节的原始 IP 适配器不同，本文方法引入了双重调节和动态区域注入机制，以在生成的图像中同时表示这两个概念。

举例来说，如图 4 所示，给定文本提示「天空下的沙漠，女巫让仙人掌绽放出鲜艳、发着光的花朵」和沙漠环境图像，模型需要知道提示中的角色应该在仙人掌旁边，还需要知道仙人掌、花朵在沙漠环境中生成。

这要求模型正确地 (1) 保留环境 (2) 保留角色 (3) 遵循提示。然而利用 IP 适配器对环境进行编码会极大地损害原始图像的特点（图 8 中的 (2) 和 (3)）。

区域 IP 适配器很好的解决了这个问题。具体来说，本文引入了一种基于动态掩码的方法，该方法利用模型每一层的字符文本嵌入和隐藏状态之间的交叉注意力来实现。如图 4 所示，本文方法将适配器分别应用于与环境和角色相对应的区域，防止环境条件干扰角色的外观，反之亦然。

对于区域 IP 适配器，该研究使用字符文本和隐藏状态之间的交叉注意力的动态掩码。此掩码的质量是分离字符和环境生成的关键。图 5 显示了下采样块的交叉注意力层中字符嵌入和隐藏状态之间的注意力图。可以观察到，注意力并不集中在字符上，而是分散在这些块的整个图像上。这表明扩散模型不会在这些层中分离字符和环境生成，而是专注于基于文本提示的整体图像结构。

具有开放式交互和集成游戏机制的语言模型游戏引擎

该研究构建了一个角色生活模拟游戏，包含两个 LLM 智能体：

一个智能体充当世界模拟模型，负责设置游戏环境、生成叙事和图像描述、跟踪角色状态并模拟角色行为；
第二个智能体充当用户模型，模拟玩家与世界模拟模型的交互。它有三种类型的交互：在当前环境中继续故事、将角色移动到不同的环境中，或与角色互动。在每种交互类别中，用户都可以选择提供角色的个性细节，或者引导角色的行为，从而影响模拟器的叙事生成。

实验及结果

实验中，该研究使用 GPT-4o 收集了一个由 5,000 个（角色图像、环境描述、文本提示）三元组组成的评估数据集。它包括 5 个角色（狗、猫、熊猫、女巫和巫师）、100 个不同的环境和 1,000 个文本提示（每个环境 10 个）。

环境一致性和角色一致性之间的比较

在该实验中，作者主要将带有块丢失的区域 IP 适配器和此前方法进行了比较。

如表 1 所示，本文方法在保持环境一致性和角色一致性方面始终优于以前的方法，同时在保持语义对齐方面也达到了可比的性能。

具体来说，在角色一致性方面，本文方法在 CLIP-I^C 中显著超过 StoryDiffusion，在 DreamSim^C 中超过 StoryDiffusion 0.057。在环境一致性方面，本文方法也是优于其他方法。

图 7 是与其他方法进行了定性比较。区域 IP 适配器采用块丢失技术，始终能够生成具有一致性的图像，而其他方法可能无法包含角色或生成外观不一致的角色。此外，研究还表明，本文方法能够很好地平衡环境一致性和角色一致性，而其他方法可能会生成与条件环境不同的环境。

带有块丢失的动态区域 IP 适配器的有效性

实验证明，带有块丢失的区域 IP 适配器对于按照文本提示将角色放置在环境中至关重要。

如表 2 所示，添加块丢失可同时改善环境和角色的一致性，CLIP-I^E 中增加了 0.291，CLIP-I^C 中增加了 0.264，同时文本提示和生成的图像之间的对齐效果更好。此外，区域 IP 适配器增强了角色一致性和文本对齐效果，同时保持了环境一致性的可比性能。

图 8 给出了定性实验结果。可以看到，基于使用 IP 适配器的环境可以实现优良的环境重建，但角色一致性会受到环境风格的影响。

块丢失技术可提升遵从文本提示词的能力，从而让生成的图像中有正确的角色和环境空间布局。不过角色外观仍会受到周围环境的影响。通过将新提出的区域注入机制与新提出的动态掩码方案相结合，生成的图像可实现强大的角色一致性，同时还能有效地考虑环境条件。

蒸馏专业化 LLM 的有效性

实验表明，该团队的多样化用户 - 模拟器交互数据可以有效地将 Gemma-2B 蒸馏成功能强大的游戏引擎。

如表 3 所示，相比于该团队蒸馏得到的模型，在进行零样本推理时，小型 LLM（即 Gemma-2B、Llama3.2-3B）或稍大一些的 LLM（即 Gemma-7B）的表现会差一些，这说明针对游戏世界和角色动作模拟任务而蒸馏更强大的 LLM 是有效的。

此外，从结果数据上看，这个蒸馏版模型的表现与 GPT-4o 相当，这也足以说明该方法的有效性。该团队还研究了蒸馏数据规模对性能的影响，具体做法就是比较使用 1K 和 5K 数据来蒸馏 Gemma-2B 模型，看结果有何差异。结果没有意外，使用更大的数据集在各个方面都更优。

翻车的不只谷歌？微软必应聊天演示被指存在事实性错误

Wed, 15 Feb 2023 15:52:35 CST

新浪科技讯北京时间2月15日上午消息，几天前，谷歌聊天机器人演示活动现场翻车导致其股价当天暴跌逾7%，但微软的演示活动同样出现了事实性错误。

在微软进行演示时，这项嵌入在必应搜索中的类ChatGPT技术分析了Gap和Lululemon的财报。但业内人士将其给出的答案与财报原文对比后却发现，这款聊天机器人遗漏了一些数据，甚至会杜撰一些内容。

“必应AI在演示过程中给出了一些完全错误的答案，但却没人注意到。”独立搜索引擎研究员德米特里·布里尔顿（Dmitri Brereton）写道，“相反，大家都对必应的宣传欢欣鼓舞。”

布里尔顿发现，除了财务数据上的错误外，微软在演示中针对吸尘器规格和墨西哥旅行计划的回答可能存在事实性错误。布里尔顿最初并不是为了给微软“挑刺”，他只是在细致对比微软和谷歌的答案时意外发现了这些问题。

人工智能专家称这一现象为“幻觉”，也就是说，基于大语言模型生成的工具有杜撰内容的倾向。上周，谷歌推出了一款与之竞争的人工智能工具，演示过程中同样存在事实性错误——但当时的错误很快就被人发现。

这两家公司都在加紧将新型生成式人工智能整合进搜索引擎，希望在ChatGPT引爆行业热潮后向世人展示自己在这方面的优势。ChatGPT是去年11月由创业公司OpenAI推出的，他们已经通过微软融资百亿美元，与之竞争的Stability AI和Hugging Face等创业公司也在融资中获得了数十亿美元的估值。

谷歌与微软对待这项技术的态度差异明显：由于担心声誉风险和安全问题，谷歌迟迟不愿将AIGC（人工智能生成内容）技术整合进搜索引擎，而微软却在上周强调，有可能在短期内向部分公众开放这项技术。

“我认为不能让这项技术躺在实验室里，”纳德拉说，“应该安全地推广出去。”

但在必应AI的演示过程中，的确在公司财报数据上出现了一些问题。

微软营销高管约瑟夫·梅赫蒂（Yusuf Mehdi）在演示过程中访问了Gap的投资者关系网站，然后让必应AI根据这家零售商11月发布的第三季财报总结出“要点”。

“很酷，节约了大量时间。”梅赫蒂说。

下面是微软演示过程的屏幕截图：

以下是这份总结中存在的错误：

-Gap报告的毛利率为37.4%。但在去除与Yeezy有关的费用后，调整后毛利率为38.7%。

-Gap的运营利润率为4.6%，而非5.9%。5.9%这个数据在该公司的财报中根本没有出现。

-调整后摊薄每股收益为0.71美元，而非0.42美元，后者同样在财报中无法找到。Gap的财报包含一个调整后所得税收益，约为0.33美元。

-Gap去年8月下调了全年预期，并在第三季度财报中表示，“第四季度销售额可能同比下滑个位数左右”。由此看来，全年营收应该下滑，而非“较低的两位数增长”。并没有营业利润率或每股收益预期。

Gap2022财年第三季度财报

微软表示，该公司知道这些错误，他们也预计必应AI会犯一些错误。

“我们知道这份报告，并且已经通过分析这一问题来改善体验。”微软发言人说，“我们承认仍然有一些工作要做，并且预计到该系统可能会在预览期间犯一些错误，正因如此，反馈才至关重要，这可以帮助我们学习和改进模型。”

微软随后让必应AI对比了Gap和Lululemon的财报。梅赫蒂希望必应能将两份财报的数据提取出来，制作成一份表格。

“看看效果多么惊人。”他说，“就像这样，一张表格，这个问题的答案有了。可以想象一下，用其他方法需要花多长时间。”

下面是必应AI的结果：

下面是表格中出现的几项错误，从利润率开始：

-Lululemon的毛利率是55.9%，不是58.7%。

-该公司的运营利润率是19%，不是20.7%

-Lululemon的摊薄每股收益为2美元，调整后每股收益为1.62美元，必应显示的摊薄每股收益为1.65美元。

-Gap现金及现金等价物为6790万美元，不是14亿美元。

-Gap库存为30.4亿美元，不是19亿美元。

谷歌向 TikTok 发起挑战，YouTube 短视频作者可获得 45% 的广告收入分成

Wed, 21 Sep 2022 07:06:45 CST

北京时间 9 月 21 日早间消息，谷歌旗下视频平台 YouTube 正试图在短视频市场上追赶 TikTok，为此该公司宣布，将开始向热门短视频创作者提供更大份额的广告收入。

在美国当地时间周二举行的“Made on YouTube，”年度创作者活动上，YouTube 首席产品官尼尔・莫汉（Neal Mohan）表示，从明年开始，该公司将拿出短视频收入的一部分，将其分给高点击量视频的创作者。

莫汉表示：“这是我们第一次大规模地向短视频创作者提供真正的收入分成。”

目前还不清楚这个机会能给短视频创作者带来多少收入，原因是 YouTube 提供的分成相关信息还比较有限。YouTube 表示，该公司每个月都会将短视频的广告收入汇集成一个资金池，并将其中一部分收入分配给创作者（但并未披露具体的百分比），然后 YouTube 将把其中的 45% 支付给创作者。

长期以来，热门视频创作者一直都能在 YouTube 的主网站上通过在视频中投放广告并保留一部分收入来赚钱。早在 2007 年，谷歌就推出了 YouTube 合作伙伴计划（YPP）以实现这一目标。

但到目前为止，通过做短视频在 YouTube 上赚钱的唯一途径是通过该公司去年推出的 1 亿美元的“短视频基金”（Shorts Fund）。

YouTube 周二发布博文称：“从 2023 年初开始，专注于短视频的创作者可以申请加入 YouTube 合作伙伴计划，条件是在 90 天内达到 1000 名订阅者和 1000 万短视频浏览量的门槛。”

莫汉表示：“短视频基金是我们迈出的第一步，但随着短视频领域令人难以置信的增长，这个创作者基金已经跟不上需求了。”

YouTube 感受到了来自 TikTok 的压力，后者为人们提供了一个配乐制作病毒式短视频的渠道，从而获得了越来越多的市场份额。今年第二季度，YouTube 的季度营收增速下降到了自谷歌母公司 Alphabet 于 2019 年第四季度开始公布视频部门销售额以来的最低水平。

Alphabet 表示，该公司正在测试短视频的盈利模式，首席财务官露丝・波拉特（Ruth Porat）此前表示，YouTube 正在受到人们变得越来越青睐短视频这一消费者行为变化所带来的挑战。

在新的短视频收入分成模式中，无论创作者的短视频是否包含受版权保护的音乐，都将获得相同数额的分成，而这就需要 YouTube 支付授权费。

“这可以让我们摆脱所有涉及音乐授权的传统复杂性。”莫汉表示。

一般来说，YouTube 视频创作者有 55% 的收入来自在视频开头或中间播放的广告。在短视频中，广告不会附加到特定的视频上，而是在两个视频之间以及短视频信息流中播放。

莫汉表示，目前 YouTube 短视频的每日浏览量为 300 亿次，每月有 15 亿登录观众观看，与该公司此前在 4 月公布的数据相比持平。

谷歌对Web3的未来持乐观态度

Sun, 08 May 2022 04:16:11 CST

谷歌云团队正组建专项团队，负责为区块链应用程序开发人员构建工具服务，目的自然是把握加密货币与相关项目蓬勃发展的这波大好势头。

谷歌云副总裁Amit Zavery在周五写给员工的邮件中指出，公司希望能让Google Cloud Platform成为区块链领域开发者们的首选方案。

他在邮件中写道，“虽然Web3的探索和推广仍处于早期阶段，但这一市场已经展现出巨大的潜力，不少客户已经要求我们增加对Web3以及加密货币相关技术的支持。”

Web3的先驱们已经建立起一套去中心化的点对点系统，希望能用这些系统建立起下一代互联网。其背后的基本理念直接对现有互联网态势提出挑战，甚至喊出了推翻由亚马逊、谷歌、Meta Platforms等互联网巨头垄断的旧世界这一激进口号。

面对阿里巴巴、亚马逊、微软等云基础设施大厂带来的重重压力，谷歌希望另辟蹊径、为有意编写Web3软件的开发人员提供后端服务。

Zavery在采访中表示，“我们并不想直接参与到由加密货币掀起的这波淘金热当中。我们更倾向于向企业提供技术，帮助他们在当前业务中充分利用Web3的分布式特性。”

作为前甲骨文公司高管，Zavery于2019年正式加盟谷歌云部门。几个月前，谷歌正式任命甲骨文前产品开发总裁Thomas Kurian为云部门的下一届负责人。

在组建Web3工具开发团队的过程中，谷歌还打算采取进一步举措以证明自己的严肃态度。今年1月，随着不可替代代币（NFT）业务的迅猛增长，谷歌云部门也公布了面向客户的数字资产合作计划。谷歌还在认真观察客户如何使用加密货币进行支付。

Zavery解释道，展望未来，谷歌可以设计出一套供其他企业使用的系统、帮助人们更轻松地探索区块链数据，同时简化区块链节点的构建与运行流程、降低交易验证和记录的门槛。他还补充道，谷歌工具还可以运行在其他计算环境中，例如AWS。

但随着投资者与加密货币这类高风险资产保持距离，今年以来即使是成熟度最高的比特币也呈现出价格疲态。截至本周四晚，比特币在年内的价格已经下跌达21%，表现甚至逊于标准普尔500指数（下跌约13%）。

但Zavery认为，区块链应用程序并不会受币圈波动的影响，而是继续进军主流市场，在金融服务、零售等行业中发挥愈发重要的作用。

耐克公司CEO John Donahoe就在今年3月的电话会议上告知分析师，这家鞋业巨头计划建立Web3产品与体验。华纳音乐集团同样对此表现出探索的兴趣。

华纳音乐集团CEO Steve Cooper在今年第一季度财报电话会议上提到，“从数字藏品到音乐版税，Web3为音乐行业勾勒出了令人兴奋的前景，也将帮助我们的艺术家以更有趣、更具创新性的方式对接数百万新粉丝。”

于2019年加入谷歌的前花旗集团高管James Tromans将领导这支新建的产品与工程团队，并直接向Zazvery汇报工作。Zavery还指出，该团队将汇聚起以公司或个人名义参与Web3开发的谷歌内部员工。

目前，谷歌的云计算业务仍落后于亚马逊和微软，但这部分业务的增长速度已经超过了核心广告部门。谷歌母公司Alphabet CFO Ruth Porat上周表示，谷歌云部门也是目前员工人数增长最快的分支。

原文链接： Google’s cloud group forms Web3 team to capitalize on booming popularity of crypto

来自谷歌的开发心得：所有SQL和代码，都没必要藏着掖着

Sat, 19 Feb 2022 02:34:27 CST

至少从工程技术的角度看，你的项目绝没有想象中那么“见不得光”。

谷歌在代码管理上很有特色，他们基于“主干”进行开发，并且将 90% 以上的代码放在名叫 Piper 的单一代码仓库中，由来自世界各国数十个办事处的数万名软件开发人员共享。对于那些开源的、需要外部协作的项目，代码才放在版本管理软件 Git 里，主要是 Android 项目和 Chrome 项目。

整个仓库采用树状结构，每个团队有自己的目录，目录路径就是代码的命名空间。每个目录都有负责人（owner），负责批准该目录的文件变动。

这种方法已经在谷歌运行了 20 年以上。2015 年，谷歌的这个代码库就包含了大约十亿个文件，并且具有约 3500 万次提交的历史。代码一般提交到主干的头部，保证所有用户看到的都是同一份代码的最新版本，支持文件级别的权限控制，99% 的代码对所有用户可见。只有少部分重要的配置文件和机密的关键业务，设有访问限制。所有的读写都有日志，管理员能够查到谁读过这个文件。

与给代码制定各种访问权限的管理方式相比，谷歌的方法带来的好处是很明显的：任何人都可以浏览和使用全公司的代码，大大促进了代码的共享和复用；具有统一的版本和路径，不存在找不到文件的最新版本这样的问题；每次代码变动，很容易撤销或者用预提交测试它所造成的影响…

就连 SQL 的管理，谷歌也在一定程度上遵循了这些原则。本文作者是一名数据工程师，给谷歌当了两年的供应商，在期间发现谷歌的数据工程师对待 SQL 的态度，跟软件工程师们对待代码的态度非常相似。他认为这种态度非常重要，无论大小企业都值得在数据战略中采取这样的心态。我们将作者的文章翻译了出来，通过他的文章，我们将一同了解谷歌这种把 SQL 当成代码的态度有哪些助益，又能给体量较小的组织机构带来哪些启示。

点击查看原文>

谷歌公告：SHA-1 哈希算法被攻破

Fri, 24 Feb 2017 18:38:29 CST

谷歌宣布攻破 SHA-1 技术的研究成果，Git 强依赖 SHA-1 引出 Linus 本人出面回应。作为非战斗人员，面对持续的“高能”安全漏洞如何保护自己？

加密学哈希算法 SHA-1 被誉为密码学的瑞士军刀。哈希算法在我们日常的网络安全、代码仓库安全、甚至是确认文件的完整性方面扮演着重要的角色。哈希函数可以为大量数据生成为很小的信息摘要。依照密码学需满足大规模使用的要求，算法设计使得两个不同内容的消息要得到相同的信息摘要在计算量上难以达成。然而时过境迁，算法设计当初的需求定义会 遭遇基于算法数学基础上的攻击和硬件计算能力提升而产生的风险。

今天，在 SHA-1 首次发布的20年后， Google 宣布了首次可操作的生成冲突的技术。这是 Google 与 CWI Institute 合作 2 年的研究成果。为了证明他们确实掌握了攻击的方法，他们发布了2个 PDF 文件，两个文件的内容是不同的，但经过 SHA-1 算法哈希后却能得到相同的信息摘要。

上图是 Google 发布的证据，两个不同内容（背景蓝色和背景红色）的 PDF 文件，经过 SHA-1 计算后却得到相同的信息摘要。

什么是哈希碰撞

密码学的哈希算法（Hash），例如 MD5 和 SHA-1，就是可以将任意长度的信息映射成固定长度的信息。一个文件 Doc 1 通过哈希算法后会得到 42C1..21 这样的一段信息摘要（digest），只要文件 Doc 1 没有被修改过，通过 相同的哈希算法总是得到相同的信息摘要。另一个文件 Doc 2 因为内容与 Doc 1 不同，通过哈希算法后就会得到不同的信息摘要 3E2A..AE。通过这样的方式，我们就可以用这套算法来保证数据的完整性，保证文件不会被篡改。

哈希碰撞 指的就是算法出现问题的情况，通过某种攻击手段，攻击者可以创造出一个 Bad doc，让它通过哈希算法后却得到与 Good doc 相同的数字摘要 3713..42。也就是说， 有人可以修改信息的内容，而不能被你察觉到。如果攻击者掌握了这套攻击手段，所有依赖哈希算法验证文件是否被篡改的系统都变得不再可靠了。

哪些系统会受影响？

任何依赖 SHA-1 做数字签名的应用程序都将受影响。包括：

数字证书签名
邮件 PGP／GPG 签名
软件发布签名
备份系统
冗余热备份系统
Git
…

Git 高度依赖 SHA-1，由于算法出现漏洞，重要的代码就有被篡改却无法被检查出来的风险。这次算法漏洞公布迫使 Linus 本人发声回应，他的部分观点是：

I doubt the sky is falling for git as a source control management tool. Do we want to migrate to another hash? Yes. Is it "game over" for SHA1 like people want to say? Probably not.

翻译：我不信代码管理软件的天就要塌了。Git 要不要迁移到新的哈希算法呢？要。但 SHA-1 真如人们所说的要完蛋了吗？未必。

不过，Linus 的回应遭到了猛烈抨击，说 Linus 已经年老色衰，判断力不行了。

非技术人员应该怎么保护自己

作为非战斗人员，我们可能平时接触不到这些算法，但我们永远都需要提高安全意识。下面是一些避免自己受伤的几点建议：

不在电脑或手机中安装未知来源的软件
不随意下载和打开未知来源的文档
尽量在软件官网和 App Store 下载软件，不信任软件下载站点和网盘
在不同网站（或 app）使用不同的密码
重要文件离线保存
电脑和手机一定要设定密码，尽量开启全磁盘加密

（完）

Stuff I Learned Yesterday 系列文章与你分享科技、设计、娱乐有关的话题。欢迎关注、打赏和转载。

微信公共号 - 「明学的白板」
我的个人Blog - http://ksmx.me
Twitter - https://twitter.com/wxiluo
新浪微博 - http://weibo.com/wxiluo

谷歌OKR指导手册 (译)

Mon, 04 May 2020 00:00:00 CST

这是一本关于 OKR 迷你小册子，名为《google OKR playbook》，由 www.whatMatters.com 网站发布。该网站由John Doerr 团队经营，而John Doerr 正是 1999年将 OKR 引入谷歌的那个人。

本文仅供大家学习参考，虽然文章较长，但值得一读，欢迎收藏。

文章的末尾有一些 8 道自我测试题，用来验证你的OKR是否在正确的实施。

如果你正实施OKR，可以用它们来验证一下吧～

在实现OKRs方面

没有人比谷歌更有经验

随着公司规模的扩大，它定期发布 OKR 指南和模板。以下摘录主要来自内部资源，并经谷歌许可转载。

（注：这是谷歌对 OKRs 的做法。你的方法可能不同，也应该不同。）

在谷歌，我们喜欢大张旗鼓。我们使用一个称为目标和关键结果（OKRs）的过程来帮助我们沟通、衡量和实现这些崇高的目标。

我们的行动决定了谷歌的未来。正如我们在互联网搜索、Chrome 和 Android 中多次看到的那样，一个由少量员工组成的团队，朝着一个雄心勃勃的共同目标努力，就可以在不到两年的时间里改变整个成熟的行业。

因此，作为谷歌的员工和经理，我们必须有意识地、谨慎地、明智地选择如何分配我们个人与团队成员的时间和精力。OKR 是这种谨慎选择的体现，也是我们协调个人行动，以实现伟大集体目标的手段。

我们使用 OKR 来规划要生产的产品，跟踪它们的进度与计划，并协调人与团队之间的优先级和里程碑。

我们也用 OKRs 帮助大家专注于最重要的目标，并帮助他们避免被紧急但不太重要的目标分散注意力。

OKR是有野心的，它不是逐步增量式的，我们并没有希望一次性就完成所有这些野心。（如果我们真的这样做，那么，我们就不会具有足够的进取性）。

我们用色阶来衡量我们做得有多好：

0.0 -- 0.3 是红色●
0.4 -- 0.6 是黄色●
0.7 -- 1.0 是绿色●

正确的OKR制定方法规则

没有认真实施和管理的OKR，是一种时间上的浪费，是管理上的假大空。与之相反，如果实施得好，OKR将是一种很好的动机激励工具，它能让团队明白什么是真正重要的，哪些地方需要优化，在日常工作中应当如何去进行利弊权衡。

要写出好的OKR可不是一件容易的事，但也不是不可能。请遵循如下这些简单的OKR制定规则：

规则1：O 要回答的是 "What" 的问题，它应当：

表达清楚目的和意图；
挑战且现实可行；
- 必须真实、客观，绝不含糊；
- 旁观者应该能够明确无误地判断出一个O是否达成；
- O的达成应对Google产生明确的价值和意义。

规则2：KR 要回答的是 "How" 的问题，它应当：

- 清晰可衡量，一旦KR达成了，能有力地推动O的完成； - 必须是产出导向，而非动作导向。如果你的KR包含有像"咨询"、"帮助"、"分析"、"参与"这样的词汇，那么它描述的实际上是动作而非结果。与之相反，如果描述的是这些动作对最终用户所带来的影响，例如："在3月7日前公布6个巨细胞的平均潜伏期和最长潜伏期"就是一个合格的KR，而"评估巨细胞潜伏期"则不是。 - 必须能自证其是否已完成。这个证据取消绩效是可轻易获取的和可信赖的，例如，证据可以是变更列表、文档链接、已发布的质量报告等。

规则3：跨团队OKR

在谷歌，很多重要的项目需要多个不同的团队一起协同方能完成。OKR是帮助致力于这种跨团队协同的理想工具。跨团队OKR的责任人应包括所有需要参其中的团队，每个团队都应当将它所负责的跨团队OKR明确无误地写到它自己团队的OKR中去。

举例来说，如果广告开发部、广告SRE部和网络开发部三个部门需协同交付一个新的广告服务，那么这三个团队就应该有一个共同的团队OKR，来描述他们的这项交付工作，指明各个部门在这个项目中所应做出的贡献。

规则4：指令性OKR和挑战性OKR

通常，存在两种类型的 OKR（指令性OKR和挑战性 OKR ），有必要对他们进行区分：

指令性 OKR 指的是那些我们必须承诺达成的OKR，我们必须调度充足的资源在指定时间内确保达成它。

对指令性 OKR 而言，目标分数是 1.0 ；如果得分低于 1.0 必须做出相应的解释，因为这意味着计划上或者执行上存在偏差。

与之相反，挑战性 OKR 则意味着即便在我们对未来一无所知，或者在无法获得必要资源支持的情况下，也依然应该去探索的那些事。挑战性 OKR 承载的是我们改变世界的梦想。

挑战性 OKR 的目标分数是 0.7 分，因为它存在高度的不确定性。

OKR写作常见错误与陷阱

错误1：把指令性 OKR 和挑战性 OKR 混为一谈

把指令性 OKR 当成是挑战性 OKR ，会增加 OKR 达成的风险。团队可能不会去认真对待挑战性 OKR ，确保高优先投入其中以成功交付这些 OKR 。

另外一方面，如果把挑战性 OKR 标记成了指令性 OKR ，就会出现优先级倒置情况，一方面，真正的指令性 OKR 没有资源去完成，而另外一方面，挑战性 OKR 又不能真正的获得必要的资源支持，这会在团队中制造抵触心理。

错误2 ：OKR 只是在例行公事

所制定的 OKR 都是些团队无须做任何改变即可轻而易举完成的工作，而不是团队或者客户真正想要实现的那些事情。

错误3：挑战性 OKR 并不挑战

如果在制定挑战性 OKR 时的基本假设是："假如有额外的人力支撑，或者再幸运一些，那么我们可以做点什么？"，这样制定出来的 OKR 还不能算做是挑战性 OKR 。更好的做法是，在制定挑战性 OKR 时，问我们自己这样一个问题："如果我们解除了绝大多数限制，那么我或者我的客户的世界看起来应该是什么样的？"

对挑战性 OKR 而言，当它最初被制定出来的时候，你并不知道如何才能实现它，这才是挑战性 OKR 的真正要义。但如果你不去理解和描绘这种最终状态，你就必然实现不了，这和知道目标但不知道如何实现它是有本质区别的。

你可以做一个小测试：问你的客户他们真正想要的是什么，然后看看你定出的挑战性 OKR 是否达成或者超越了他们的预期？

错误4：OKR 不敢于挑战

毫无疑问，一个团队的指令性 OKR 会消耗他们大多数可用资源和精力，但不是全部资源和精力。指令性 OKR 和挑战性 OKR 合在一起所消耗的资源量，应当是超出团队目前的可用资源范围的，不然这个团队的 OKR 就全部都只是指令性 OKR ，因为指令性 OKR 是要求必须在现有资源范围内要能全部达成的 OKR 。

如果一个团队只使用部分人力/费用就能达成他们所有的 OKR ，那么这个团队事实上是在浪费资源，或者说团队一把手没有管理好他们的团队成员。这意味着上层管理团队需要重新分配其人力和资源，把它们调配给那些真正可以做得更好的团队。

错误5：低价值O（戏称"没人在意"型 OKR）

OKR 一定要体现清晰的商业价值，否则，就不值得浪费资源去做它们。低价值O（LowValued Objective, 简称 LVO ）指的是那些即使你百分百完成了，得分达到1.0 了，也没有人会真正注意到的 O 。

一个经典（也很有诱惑力）的低价值 O 示例："将 CPU 利用率提升 3 个百分点。"

这个 O 本身对用户和谷歌并不能带来什么帮助。然而，如果将 O 描述成这样："在不改变质量/延迟/...的情况下，将峰值查询所需内核数量减少 3 %，并将多余的内核返回空闲资源池。"则清晰地描述出了经济价值，就是一个好的 O 了。

这里有一个小测试可以帮到你：OKR 能否在没有直接最终用户参与，或者产生经济收益的情况下就得到 1.0 分？如果是，那么你需要重新组织你的 OKR 描述，让它显性地体现有形收益。比如："发布X" 就没有道出成功的标准。更好的描述是："将 X 发布到 90% 以上的集群管理器网元，使集群 Y 容量翻番。" 则是一个不错的 O 。

错误6：KR 不足以支撑 O 的达成

OKR 包含 2 个部分：O 描述的是期望达成的结果，KR 是达成这个结果所要经历的步骤。因而，关键的一点就是，如果所有 KR 的分数都是 1.0 了，那么与之相关的 O的分数也应该是 1.0 。在制定 OKR 时，一个常见的错误是，所有的 KR 都是必要但却非充分的，也即当这些 KR 都完成了，却无法支撑 O 的实现。这个错误很有可能是故意造成的，因为这让团队躺在舒适区，不去做必要的资源/优先级/风险等承诺，这比交付"困难"的 KR 要容易得多。

这一陷阱极其有害，因为它拖延了发现达成 O 所需资源的时机，没有及时暴露 O 不能按计划达成的风险。

可以做一个小测试：如果把所有 KR 的得分都标记成了 1.0 ，是否仍没有达成所希望的目标或意图？如果是，那么请增加 KR ，或者重新组织 KR ，直到 O 下所有KR能完整无误地支撑其达成为止。

OKR查阅、解读和实施：

指令性OKR

要求团队要及时调整其他事项的优先级，以确保这部分 OKR 能按计划 100% 交付，这部分 OKR 的得分须为 1.0。

如果团队不能承诺在指令性 OKR 上达成 1.0分，团队须适当地将这一风险及时进行升级上报。这一点很关键：这种情形下的升级不仅是合适的，而且你必须这么做。无论是因为对 OKR 的分歧、对其优先级的分歧，还是由于无法分配足够的时间/人员/资源而导致无法按承诺达成 OKR ，都应对之进行升级。这让管理层能提前思考应对策略。

推论：这意味着每个 OKR 都会涉及到适度升级，因为它需要基于已有优先级或者承诺做出改变。一个不需要做任何修改的 OKR 只是一个例行性 OKR ，即便以前没有被明确制定成 OKR，它们也不可能是新的 OKR。

不能按时达成 1.0 分的 OKR 都应进行事后回溯。这不是要惩罚哪个团队，而是要弄清楚究竟发生了什么，是计划制定不合理？还是 OKR 执行上出现了问题，找到真正的问题所在，持续提升团队能力，以便未来更好地完成指令性 OKR。

指令性 OKR 的示例有：

- 确保服务达成 SLA（服务水平协议）。 - 发布预先定义好的特性，或者在指定日期提升基础设施系统的性能。 - 以一定成本制造并交付一定数量的服务器。

对挑战性OKR

挑战性 OKR 被设计成需要团队在某季度付出额外的努力才能达成的那些 OKR。挑战性 OKR 的优先级指明了团队成员在完成了指令性 OKR 后，还需要在哪些地方进行额外的时间和精力投入。当团队有多个挑战性 OKR 时，团队应优先完成高优先级挑战性 OKR ，然后再完成次优先级挑战性 OKR......依此类推，以确保资源和精力的聚焦。

挑战性 OKR 及其优先级，同样应该出现在一个团队的 OKR 列表上，直至其完成为止。如有必要，这些 OKR 可以持续多个季度，并不断推进其进展。仅仅因为一件事情进展不佳就将其从 OKR 列表中删除是不对的，这是在掩盖问题而非真正解决问题。

推论：如果另外一个团队既有充足的专家资源也有充足的时间投入，那么把一个挑战性 OKR 转交给这个团队去做会更合适。

团队管理者需要每季度定期评估挑战性 OKR 的资源满足度，履行其职责确保业务的已知需求得以满足。管理者不是要接受所有的资源需求，而是应在团队所有指令性 OKR 完成之后，按目标优先级去进行资源调度。

关注公众号

回复 "OKR" 获取《OKR小测试》，

检测一下你的组织OKR状态吧。

本文首发于 Bob Jiang的博客，转载请联系 Bob Jiang

新官上任后：谷歌史上首次公布YouTube和云计算单独收入

Tue, 04 Feb 2020 09:06:14 CST

对于谷歌母公司Alphabet来说，除了网页搜索、安卓操作系统之外，网络视频YouTube以及云计算也是其他两个极为重要的业务，过去谷歌从未披露过这两个业务的营收。据外媒最新消息，作为史上第一次，谷歌周一在其2019年第四季度收益报告中公布了其YouTube和云计算业务的经营数据。

据国外媒体报道，2019年，YouTube通过视频广告创造了151.5亿美元的收入，仅第四季度就有47.2亿美元。该部门在2018年创造了111.6亿美元的收入，包括当年第四季度的36.1亿美元。对比可以发现，YouTube去年的广告收入同比增长了三分之一，虽然是一项非常老牌的网络视频服务，但是增速仍然保持了高位。

需要指出的是，这一部分收入不包括YouTube的非广告收入，比如“YouTube电视”（互联网电视频道直播服务）的会员费，这些收入囊括在了谷歌的其他收入部分。

谷歌的云计算业务在2019年创造了89.2亿美元的收入，第四季度创造了26.1亿美元。相比之下，2018财年云计算业务的收入为58.4亿美元，当年第四季度为17.1亿美元。两相比较，谷歌云计算业务去年同比增长了近一半。

云计算是谷歌高管并不满意的业务，市场研究公司的报告显示，谷歌云计算的份额仅为个位数，甚至仅相当于行业领先者亚马逊和微软公司的几分之一。

据报道，谷歌高管过去曾经开会，掌门人佩奇差一点决定放弃云计算业务，但是最终决定扩大投资，希望能够在这一市场进入前两名，这意味着至少要超过排名第二位的微软公司。

在公布四季度财报后，谷歌母公司Alphabet的股价下跌约3.5%。

分析师们长期以来一直呼吁谷歌单独报告YouTube的收益，因为它被认为是其网络广告业务的重要组成部分。

如果把YouTube当做一个独立的影视媒体公司，2018年，该公司从广告中获得的收入超过了探索公司（探索频道母公司），后者的年收入为106亿美元，而YouTube为112亿美元。探索公司尚未报告其2019年全年的结果。

谷歌的云计算业务是该公司中一个年轻但快速增长的部分，正在拼命追赶微软和亚马逊。今年7月，谷歌表示，其云计算部门的年收入刚刚达到80亿美元，并计划在未来几年内将其销售额增加两倍。

Alphabet第一次披露YouTube和云计算的业务，或许和该公司最近的高层人事变动有关系。

众所周知的是，之前，谷歌首席执行官皮查伊兼任Alphabet首席执行官，过去的首席执行官佩奇和总裁布林辞去职位，退出了日常管理。皮查伊执掌的谷歌和Alphabet正在呈现出更大的透明度。

另外，包括谷歌在内的美国四大科技巨头（谷歌、苹果、Facebook和亚马逊）正在接受美国政府多个部门的反垄断调查，谷歌业务信息的透明化，也有助于谷歌配合监管机构的调查，减少外界对于谷歌垄断市场的议论。

据悉，一个由来自不同州和地区的50名司法部长组成的联盟之前宣布了他们对谷歌网络广告业务的调查。新的披露让投资者对调查人员可能正在关注的谷歌广告板块的不同部分有了更多的了解。

在过去一年中，行业内掀起了网络视频大涨，更多的互联网公司、好莱坞和电视台正在效仿奈飞公司的模式，进入原创影视视频市场，这让奈飞、亚马逊等视频平台面临更大的竞争压力。

不过，YouTube的商业模式则截然不同，YouTube是全世界最大的网民原创视频网站，视频制作质量不如奈飞的原创影视作品，但是内容规模庞大丰富，仍然占据了不菲的播放时间比例。

根据早前美国派杰公司的一个调查，在美国青少年群体中，奈飞和YouTube各自占到了三分之一的视频播放时长，换言之，两个商业模式截然不同的视频巨头霸占了三分之二的时间份额。

之前，YouTube也曾经“赶时髦”，进入了原创影视领域，投资拍摄美剧等作品，通过会员费获取收入。但是据外媒报道，YouTube在原创影视领域的战略并不成功，目前已经基本放弃，原先制作的一些美剧影视作品已经免费对大众开放，将通过视频广告回笼投资。

谷歌开源Live Transcribe语音识别转文字工具

Sun, 18 Aug 2019 19:33:16 CST

　　谷歌在其开源博客中宣布开源 Android语音识别转录工具——Live Transcribe的语音引擎，它可以将语音或对话实时转录为文字，还能够为听障人士提供帮助。

　　Live Transcribe 是谷歌于今年2月推出的一款Android应用程序，它的语音识别由谷歌最先进的Cloud Speech API提供。但是，依赖于云引入了一些复杂性，不断变化的网络连接、数据成本和延迟等等都带来一些考验。因此，谷歌把它开源出来，希望开发人员在已有的基础上进一步构建和开发。

　　Cloud Speech API目前无法支持无限的音频流，团队采取了一些措施来解决这一难题，例如在达到超时之前关闭并重新启动流式传输请求，这将有效减少会话中丢失的文本量。

　　值得一提的是，Live Transcribe支持超过70种语言，并能够根据语音自动识别语种，其中也包括中文。

　　另外，由于是提供实时语音转录，转录出来的文本会随着语音的输入不断发生变化，降低延迟自然十分必要。该引擎能够大大降低延迟率，这都要归功于它的自定义Opus编码器。

　　 Live Transcribe语音引擎功能

　　Google列出了语音引擎的以下功能（不包括说话人识别）：

　　无限流媒体。

　　支持70多种语言。

　　可以简化网络丢失（在网络和Wi-Fi之间切换时）。文字不会丢失，只会延迟。

　　强大的扩展网络损耗。即使网络已经停电数小时，也会重新连接。当然，没有连接就不能进行语音识别。

　　可以轻松启用和配置Opus，AMR-WB和FLAC编码。

　　包含文本格式库，用于可视化ASR置信度、发言人ID等。

　　可离线模型扩展。

　　内置支持语音检测器，可在延长静音期间用于停止ASR，以节省资金和数据。

　　内置支持扬声器识别，可根据扬声器编号标记或着色文本。

　　英文原文： Bringing Live Transcribe's Speech Engine to Everyone

为什么谷歌的开发人员认为敏捷开发是无稽之谈？

Thu, 15 Aug 2019 00:00:00 CST

本文是 Quora 上的一篇回答，作者是一名前谷歌工程总监，他认为敏捷宣言从较高层次而言，与谷歌工程师对软件开发的看法是很接近的。但如果落实到细节，比如敏捷宣言背后的某些原则，其所代表的主张短迭代和低文档的 Scrum 流程，过于集中于短期思维，不适用于谷歌这样革命性的工程项目。

在 Quora 上有人提出了 " 为什么像谷歌这种公司的开发人员认为敏捷开发是无稽之谈？" 的问题，关于此，作为一名前谷歌工程总监，David Jeske 提供了一些个人见解，以下是 David Jeske 的回答。

对很多人来说，敏捷意味着很多事情。我认为敏捷宣言从较高层次而言，与谷歌工程师对软件开发的看法是很接近的。

个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

然而，一旦把这些高层次的观点落实到细节，这些协定就开始褪色。敏捷有一些很好的想法，但它也存在一些问题元素，即过于集中在短期思维，对于像谷歌这样的公司进行革命性工程项目并不太适用。在不深入细节的情况下，让我们来看看敏捷宣言背后的原则。

让我们从共通点谈起。谷歌的发展风格是敏捷宣言背后的原则中所提到的 激励赋能个体的例证。在这些原则中，最符合硅谷风格，可能本身就是受到硅谷启发的几条原则包括：

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
最好的架构、需求和设计出于自组织的团队。
团队定期反思如何能提高成效，并依此调整自身的行为。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。

这些原则对于聪明的工程师来说几乎是常识。我认为，硅谷打造了一种以赋能和信任个人为中心的文化。

然而，这些原则的其他部分却并不符合谷歌的开发文化。而这些部分实质上造就了短期迭代的 Scrum 流程。它们似乎更适用于特定类型的开发，最显著的是面向咨询或合同的软件编程，在这种情况下，客户是组织的外部人员，因为他们为开发付费，所以客户占主导地位操纵局势，可以在任何时候改变主意：

我们的首要任务是通过持续不断地及早交付有价值的软件来满足客户。
在整个项目中，业务人员和开发人员必须每天一起工作。
不论团队内外，传递信息效果最好效率也最高的方式是面对面交谈。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程对变化进行掌控。
频繁地交付可工作的软件，从几周到几个月不等，倾向于采取较短的周期。

这种短期规划、直接与客户接触和持续迭代的风格，非常适合具有简单核心和大量客户可见特性的软件，这些特性的可用性可以增量方式上升，不太适用于那些只有非常简单的用户接口和大量隐藏的内部复杂性软件，这些软件可能直到相当完整时才具有可用性，或实现客户无法想象的飞跃式解决方案。

像谷歌这样的公司一直在编写革命性软件，这些产品以前从未有人编写，在复杂的子组件编写完成之前，软件是无法工作的。这让我立刻想到了 Bigtable 和 Borg 项目。Bigtable 是一种广泛复制的分布式数据库设计，而 Borg 是最早出现的超大规模集群 / 云管理器之一。这种类型的颠覆性创新需要大量的预先设计时间，并且需要在超过一周的迭代中为编写组件而工作。由于项目的外部接口如此简单，以及内部复杂性如此之高，以至于许多工作对“客户”甚至无法可见的，因此没有办法编撰客户可见的相关用户故事。这种类型的软件需要 8-20 个月的时间向客户交付第一个工作版本。

像 Bigtable 和 Borg 这样的项目是反 scrum 的。它们代表了技术领导者非常长远的考虑。在单独一周的时间里，他们并没有做一些可以满足少量需求的事情，而是为集群软件开发方式的根本性转变打下了基础。这项投资不仅在谷歌获得了令人难以置信的回报，而且影响了整个行业。

其他行业也有类似的情况。从税务会计软件到电脑游戏，有些软件在部分完成后并不适宜交付给终端客户。

如果我被要求重写上面的敏捷原则，使之更符合谷歌风格的开发，它们可能会是下面这个样子：

我们的首要任务是提高客户（和程序员）的生产力和对信息的访问。处理你能找到的最迫切、最常见的问题，并产生最大的网络影响。不要仅仅满足客户的要求，要去深入了解客户，并彻底改变他们的世界。
开发人员应该创建一个谷歌设计文档（一个相当小型的，但是结构化的设计文档），对项目做出解释，这个项目希望实现什么目标，以及为什么不能用其他方法来完成目标。此文档应该分发给所有项目干系人，以便在项目开始之前获得早期反馈。书面记录是必不可少的，因为它确保对项目何时抵达成功以及如何达到目标有一个清晰和一致的理解。
在项目的所有阶段，大型组件的关键设计元素应该在设计文档中得到简明的解释和记录。
飞跃式创新。完成并部署一个飞跃式创新比追求完美更重要。不可能做到完美无暇。相反，要灵活，并计划在技术栈的每一层不断地重新创造和改造。
在合理的情况下，尽可能快地交付工作软件，并非一味地追求尽快交付。在对外交付之前先在内部使用自己的产品。确保产品在交付前达到高质量标准。产品的质量比交付产品所花费的时间更重要。

虽然敏捷宣言从高层次而言有足够的灵活性，可以和以上这些原则配合应用，但是我认为这些重写的原则与主张短迭代和低文档的敏捷 /Scrum 流程还是有很大区别的，而这些主张短迭代的低文档敏捷 /Scrum 流程如今几乎已经成为敏捷开发的同义词。

作者介绍：

David Jeske，计算机工程师，前谷歌工程师总监。

英文原文：

Why do some developers at strong companies like Google consider Agile development to be nonsense?

这一次谷歌很强硬，App 再不支持，两个月后将拒绝上架

Sat, 08 Jun 2019 00:00:00 CST

一. 序

事情是这样的，前几天收到 Google Play 的通知邮件，这才想起来有几款在 Google Play 上架的 App，还没有支持 64 位 CPU 架构。

早在今年一月份，Google 就发布通知，在今年 8 月 1 日开始，上架的 App，除了提供 32 位的版本之外，还需要提供 64 位的版本。

这眼看着离强制升级窗口，只剩下最后两个月的时间，很多第三放来源的 so 支持库，如果没有提供 64 位的版本，还需要同步催促合作方更新。

那今天就来聊聊 Android APK 升级 64 位 CUP 架构的细节，看看你的应用是否需要支持 64 位 CPU 架构，如果要支持，需要做什么？

二. Android CPU 架构细节

2.1 这是强制规范

早在 2015 年 Google 发布 Android 5.0 版本时，就加入了 64 位处理器的支持，当时就提出了以 19 年 8 月为最后的更新支持期限，并在今年又重申了这个强制要求。

只要你的 App 存在国际版，需要上架 Google Play，这个规定都必须准守。

2.2 那些 APK 需要支持 64 位？

那假如你有一个国际化的 App 需要维护，在今年 8 月 1 日之后，更新 Google Play 时，就必须提供 64 位的版本。

那这里说的 64 位版本支持，到底是什么？

如果你的应用，完全是使用 Java 或者 Kotlin 编写代码，不包含任何原生（Native）的支持，那么就表示这个应用已经支持 64 位。

但是应用内使用了任何原生（Native）的支持（so 库），就需要针对这些 so 文件，针对不同的 CPU 架构提供不同的版本的 so 支持。

需要注意的是，有些时候，在我们自身的代码中，确实没有用到原生的支持，但是在 App 中使用的一些第三方库中却包含了。

此时最稳妥的方式，就是针对最终打包生成的 APK 文件进行分析，来判断是否需要提供 64 位架构的支持。

那 CPU 架构是什么？什么又是 ABIs？

在 Android 中，虽然 ARM 的 CPU 架构是主流，但是目前至少支持几类 CPU 架构，ARM 下的 ARMv5/ARMv7/ARMv8，x86 下的 x86/x86_64，以及很不常见的 MIPS 类架构。这里的每一种 CPU 类型对应了一种 API（Application Binary Interface），例如 armeabi-v7a 中的 "armeabi" 指的就是 ARM 这种类型的 ABI，后面的 “v7a” 指的是 ARMv7。

通常我们可以简单的理解：

这三个概念是相通的，通常在技术讨论中，说的是一个东西。

2.3 为什么是强制的？

谷歌之所以会有强制更新的要求，很大一方面原因是因为作为开发者，更新补全 ABIs 的动力并不足。

主要原因来自以下几个方面：

1. APK 体积增大

针对不同 CPU 架构提供对应的 so 库，当然是效率最高的做法。但是这种做法，最直接的影响，就是 APK 文件的增大，有些时候补全这些 so 支持，会导致整个 APK 体积有几 MB 到几十 MB 的增幅。

APK 体积优化，很多公司都将其算做是一个 API 指标，加入一个新特性，导致 APK 体积的增大，在很多时候都是不允许的，为此换技术方案都是常有的事。

从增长的角度来看，越小的 APK，用户下载的意愿就更大，转化率就越高。

但是随着现在流量越来越便宜，近期 iOS 已经将蜂窝数据下载限制从 150MB 放宽至 200MB，针对安装包的体积优化标准，也可以适当的放宽了。

2. 本身有一定的兼容性

应用市场中，很多 APP 其实都只有 armeabi 或者 armeabi-v7a 的支持，而市面上的设备，支持的并不是只有这两种 CPU 架构。

但是这并没有影响在这些设备上运行这些 App，这就是 CPU 架构的兼容性。

不同架构，并不意味着之间一定是不兼容的，在不同版本下，其实提供了两种 ABI 支持，分别是

主要 ABI：与系统本身使用的原生代码一样，最优方案。
辅助 ABI：支持的另一个 ABI 方案，兼容方案。

这种兼容策略就不在这里展开说了，最简单的就是 64 位的 arm64-v8a 在支持本身的 CPU 架构之外，还兼容支持 armeabi-v7a、armeabi；x86_64 同时也兼容支持 X86 和 armeabi。

你看，虽然添加 64 位的支持，可以有效的使用硬件的优势，提升性能，但大部分时候，采用兼容方案，是一种更简单的方式。

3. 没有对应架构的 so 文件

这个原因就比较尴尬了，我们 App 中使用到的原生代码，其实有两种。

一种是我们自己编写的，源码在手，想提供对应的支持，修改配置重新编译一下就解决了。

另一种来自第三方提供的，这种时候我们没有源码，无法做到重新编译，只能和第三方沟通，看能不能提供一个对应 CPU 架构的 so 库。这种情况就非常的不可控了。

例如比较常见的一个 WebView 的替换方案，腾讯 X5 内核，本身就不提供 X86 的库。

官方给的建议是使用 armeabi 或者 armeabi-v7a。

在前文有提到，ABIs 本身是有一些兼容规则的，但是这种兼容规则，是有条件的。

举个例子：64 位的 arm64-v8a 是可以向下兼容的，但是这有个前提，那就是如果你的项目中，有 armeabi-v7a 和 arm64-v8a 两个目录，就需要保证这两个目录下支持的 so 库文件保持一致。

在左边的情况下，如果 arm64-v8a 的手机用到 b.so 时，就会去 arm64-v8a 目录下找，当然是找不到 b.so 文件的，就会直接抛异常，而不会再去 armeabi-v7a 目录下继续寻找。

如果需要提供多套 ABIs 的支持，就需要保证所有 ABI 目录下，对应的 so 文件保持一致。

而在一些特殊的情况下，我们无法提供对应平台的 so 库，例如腾讯 X5 内核这种情况，就需要做个取舍了。

在没有 Google Play 的强制策略下，同时又因为各方考虑，大多数时候我们可能会舍弃其他 ABIs 的支持。但是现在既然强制执行了，腾讯 X5 内核就可能升级以提供 64 位的 so 库，毕竟一边是无法上架，另外一遍是一个 WebView 的内核，谁都知道怎么取舍。

三、支持 64 位架构

3.1 是否包含 64 位库？

介绍了 Android 下 CPU 架构的一些细节，接下来就要开始正题了，如何升级并支持 64 位架构。

从前文中应该了解到，支持对应的 ABIs，反映在项目中，就是存在对应 ABIs 架构的目录，并且目录中有完备的 so 库支持。

Google 并不要求我们支持所有的 64 位架构，但是对于已经支持的每种原生 32 位架构，就必须包含对应的 64 位架构。

例如：

对于 ARM 架构，有 armeabi-v7a（32位）就必须 arm64-v8a（64位）。
对于 x86 架构，有 x86（32位）就必须有 x86_64（64位）

这就要求我们有对应的目录，并且目录中包含对应的 so 文件。APK 中提供了完备的 ABIs 支持，运行的之后，会选取对应的最优支持进行加载和使用。

需要注意的是，有时候我们将 32 位的 so 复制到 64 位中，运行不会出现异常，但是这依然存在隐患。最好的办法是根据不同的架构，编译对应的 so 文件，原则上，我们的目标是确保应用可以在仅支持 64 位架构的环境中正常运行。

3.2 判断是否支持 64 位架构

前面也提到，我们的项目中，可能会引入一些第三方库，导致在不明确的情况下，引入了一些预期之外的 ABIs 库。

通常我们的做法是在 Gradle 中增加 abiFilters 过滤，来确保不会在打包输出的 APK 中存在预期之外的 ABIs 目录和 so 库。

  ndk {   
    //设置支持的SO库架构   
    abiFilters 'armeabi-v7a'    
}

那么我们拿最终打包输出的 APK 文件去分析，是最稳妥的办法。

分析的方法有两种：

1. AS 的 APK 分析器

在 Android Studio 中，从菜单依次选择 Build → Analyze APK…

选择需要分析的 APK 文件，查看其 lib 目录，是否存在预期的 ABIs 目录以及完备的 so 文件。

2. 使用 zipinfo 命令进行分析

得到待分析的 APK 文件，就可以通过 zipinfo + grep 命令，输出其内包含的 so 文件。

  > zipinfo -1 YOUR_APK_FILE.apk | grep \.so$   
    lib/armeabi-v7a/libmain.so   
    lib/armeabi-v7a/libmono.so   
    lib/armeabi-v7a/libunity.so   
    lib/arm64-v8a/libmain.so   
    lib/arm64-v8a/libmono.so   
    lib/arm64-v8a/libunity.so

依然是去看对应目录和 so 文件是否完备。

3.3 在 64 位设备上测试应用

支持 64 位架构是为了让我们利用 CPU 的特性，以提升性能，但是稳定依然是我们首先要保证的，所以在升级之后，就需要进行测试。

要测试 App，最简单的方式是使用 adb 命令安装该应用，可以配合 --abi参数，用以指示要将那些 so 库，安装到设备上，这样我们在这个设备上安装的 App，就会仅包含我们制定的库。

  # 成功安装 APK :   
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk   
Success   
   
# 如果 APK 中不包含 64 位 so 文件:   
> adb install --abi arm64-v8a YOUR_APK_FILE.apk   
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]   
   
# 如果你的设备（手机）不支持 64 位架构   
> adb install --abi arm64-v8a YOUR_APK_FILE.apk   
ABI arm64-v8a not supported on this device

去年上市的手机，大部分都是 64 位架构的，找一款来测试即可。

3.4 分包处理

如果我们的应用只需要在国内分发，当前的策略对我们并不影响，保持原样就好了。但是如果存在国际版，需要上架 Google Play 就一定要重视此次升级。

在 Google Play 上传 APK，是可以根据 CPU 架构上传不同的 APK 的，也就是我们可以针对 32 位上传一个 APK，再上传一个 64 位的 APK。

此时就需要用到 Gradle 的打包技巧了，分别输出几个仅包含对应平台的 APK，以此完成 Google Play 的要求，分别上传 32 位的支持 APK 和 64 位的支持 APK，这样能够 APK 文件不至于增大很多。

  android {   
    ...    
    splits {   
        abi {   
            enable true   
            reset()   
            include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' //select ABIs to build APKs for   
            universalApk true //generate an additional APK that contains all the ABIs   
        }   
    }   
    // map for the version code   
    project.ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, 'mips': 5, 'mips64': 6, 'x86': 8, 'x86_64': 9]   
   
    android.applicationVariants.all { variant ->   
        // assign different version code for each output   
        variant.outputs.each { output ->   
            output.versionCodeOverride =   
                    project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 + android.defaultConfig.versionCode   
        }   
    }   
 }

这里利用 Gradle 的 splite 配置，有兴趣可以直接查阅文档，就不展开讲了。

四. 小结时刻

在本文中，我们借此次 Google Play 的强制支持 64 位架构的事情，讲解了 Android 下 so 库的一些兼容问题。

如果你在 Google Play 上有应用需要更新，别忘了提前准备需要的 so 库，大多数原生支持的第三方库，在此之前其实都已经提供了对应的 64 位架构。我们只需要在最终日期之前，仔细的进行增加 so 文件，以达到适配的效果。

更新完成之后，别忘了测试，本文就到这里，你有什么更新的见解，欢迎在留言区讨论。

本文对你有帮助吗？ 留言、转发、点好看是最大的支持，谢谢！

reference：https://developer.android.com/distribute/best-practices/develop/64-bit

「联机圆桌」推荐我的知识星球，一年 50 个优质问题，上桌联机学习。

公众号后台回复成长『成长』，将会得到我准备的学习资料，也能回复『加群』，一起学习进步；你还能回复『提问』，向我发起提问。

2019高考编程卷：谷歌面试编程题及解题技巧（MIT版）

Fri, 07 Jun 2019 12:33:15 CST

课程链接：http://courses.csail.mit.edu/iap/interview/index.php

本课程重点介绍科技公司在面试时经常出现的计算机科学问题，其中包括时间复杂度、哈希表、二进制树搜索，以及 MIT「算法设计与分析」（MIT 6.046）课程中会出现的内容。但是，大部分时间都会专注于你不会在课堂上学到的内容，例如刁钻的按位逻辑和解决问题的技巧。

面试锦囊

被问到一个问题时，要和面试官展开对话，让对方知道你在思考。例如，你可能会提供一个较慢或能解决部分问题的方案（让他们知道这个方案并不完美），提到一些关于这个问题的观察结果，或者说一下任何有可能对解决问题有帮助的想法。如果你卡住了，面试官通常会给你点提示。

面试期间，你通常会被要求写一个程序。出于某种原因，面试官通常让人在黑板或纸上写，而不是给你一台电脑。所以，有必要在面试之前练一下在板子上写代码，以备不时之需。

以下是编程面试中的一些注意事项：

这些事要做：

如果对问题有哪里不理解或有歧义，一定要问清楚；
让面试官知道你在想什么；
针对问题提出多个解决方案；
与面试官交流想法（如关于数据结构和算法的想法）
如果你卡住了，不要害怕让他们知道，可以礼貌地寻求提示。

这些事不要做：

不要放弃！放弃对你展示自己的问题解决技巧没有任何帮助；
思考期间不要只是安静地坐在那里。面试官要在有限的时间内尽可能多地了解你，不和他们交流无法向他们传递任何信息；
如果你已经知道问题的答案，不要脱口而出！不然他们会觉得你提前看过这个问题并记下了答案。至少要在给出答案之前假装思考一阵儿。

好了，如果你对自己的备考情况很有信心，以下是其中的一些经典问题：

问题 1：硬币难题

假设你有 8 枚大小相同的硬币，但其中 1 枚硬币要比其他 7 枚稍重一点（但你不知道具体是哪一枚）。同时，你还有一个老式天平可以称重，从而得出哪枚硬币稍重（或是否重量相同）。那么，最少要称多少次才能找出那枚稍轻的硬币？

优秀答案：从 8 枚硬币中取出 6 枚，天平左右盘各放 3 枚。结果会出现三种情况：天平左盘 3 枚硬币重于右盘，则较重的 1 枚在左盘；天平右盘的 3 枚硬币重于左盘，则较重的 1 枚在右盘；天平左右盘重量相等，则称剩下的 2 枚硬币，得出稍重的这枚硬币。

不太好的答案：分别取 4 枚硬币放置于天平左右盘，找出较轻的一组（4 枚），将该组硬币继续分为两组放入天平左右盘，找出较轻的一组（2 枚），再次重复此步骤找到最轻的一枚。

问题 2：在数组中进行查找

给定一个已排序的整数数组，如何找出特定整数 x 的位置？

优秀答案：使用二分搜索法。将数组中间的数字与 x 进行比较。如果相同，则找出了 x。如果数组中的数字较大，则需要查看数组后半部分。如果数字较小，则需要查看数组前半部分。通过比较数组中间元素和 x，我们可以重复搜索该数组的前后部分，从而再次将搜索范围缩小 2 倍。我们重复这一过程直至找出 x。这种算法花费的时间为 O(log n)。

不太好的答案：按顺序查看数组的每个数字，与 x 进行比较。这种算法花费的时间为 O(n)。

问题 3：A to I

编写一个函数将字符串转换为整数（这个函数被称为 A to I 或者 atoi()），因为我们要将一个 ASCII 字符串转换为整数。

优秀答案：从头到尾查看整个字符串。如果首个字符为负号，记下来。从 0 开始进行累计求和。每得到一个新数字，总数乘以 10 并加上这个新数字。当计算结束时，返回当前总数，或者如果出现负号，返回该数字的倒数。

凑合的答案：另一种方法也是从头到尾查看整个字符串，再次进行累计求和。记住表示当前你所在数字的数字 x，x 最开始为 1。针对每个字符，将当前数字乘以 x 并添加到累计总数中，同时将 x 乘以 10。当你到达字符串起点时，返回当前总数，或者如果出现负号，返回该数字的倒数。

注意：面试官可能会询问你自身方法的局限性。你应该回答：只有字符串在每个数字前都包含可选负号时，该方法才能生效。同时，你还应提到：如果数字太大，则结果会因为溢值原因而不正确。

问题 4：颠倒字符串中的单词顺序

编写一个函数将字符串中的单词顺序进行颠倒。

答案：交换第一个与倒数第一个、第二个与倒数第二个字符的顺序，以此类推，颠倒整个字符串。之后，查看整个字符串，找出空格，这样就可以发现每个单词的位置。再次交换第一个与倒数第一个、第二个与倒数第二个单词的顺序，以此类推，颠倒你所遇到的每个单词的顺序。

问题 5：最近邻

假设你有一个包含 n 个人信息的数组。每个人分别用一个字符串（他们的名字）和一个数字（他们在数轴上的位置）表示。每个人有三个朋友，即数字和他本人最接近的三个人。请写出一个可以找出每个人的三个朋友的算法。

优秀答案：按每个人数字的升序对数组进行排列。查看每个人前后紧邻的三个人，他们的朋友将出现在这六个人当中。这一算法花费的时间为 O(n log n)，因为将人进行分类也会花费那么多时间。

问题 6：洗牌问题

给定一组不同的整数数组，给出一个算法对这些整数进行随机排序，使每个重排序方法的可能性相等。换句话说，给定一副牌，你要如何洗牌才能确保牌的每种排列方法有相同的可能？

优秀答案：按顺序排列这些元素，用数组中不先于某个元素出现的随机元素与该元素进行交换。需要的时间为 O(n)。

注意，这个问题有多个可能的答案，也有几种看似不错但实际上并不正确的答案。例如，对上面的算法做一个小小的修改，即，将每个元素与数组中的任意一个元素交换并不能确保每种重排顺序等概率出现。这里给出的答案（在作者看来）是最佳答案。如果想了解其他答案，可以在维基百科上搜一下「Shuffling」。

问题 7：单链表中的循环

如何确定单链表是否有循环？

优秀答案：跟踪链表中的两个指针，并在链表的开始处启动它们。在算法的每轮迭代中，将第一个指针往前移一个节点，把第二个指针往前移两个节点。如果两个指针始终相同（不是在算法起点处），那么就有一个循环。如果指针在两个指针相同之前就达到链表的末端，链表中就没有循环。其实，指针不需要一次移动一到两个节点；指针也不需要以不同的速率移动。这个过程需要的时间为 O(n)。这是一个巧妙的回答，面试官会莫名喜欢。

凑合的回答 1：对于你在逐一浏览链表时遇到的每个节点，将指向该节点的指针放入 O(1) 中——查找时间数据结构，如散列集。接下来，当你遇到一个新的节点时，要看看指向那个节点的指针是否已经存在于你的散列集中。这一过程花费的时间为 O(n)，但占用的空间也是 O(n)。

凑合的回答 2：浏览链表中的元素。「Mark」你到达的每个节点。如果在抵达末端之前你到达了一个 mark 过的节点，列表中就有循环，否则就没有循环。这一过程花费的时间也是 O(n)。

注意，这个问题在技术上是不恰当的。一个普通的链表不会有循环。他们的意思是让你决定能否从一个图中的节点到达循环，该图包含最多有一条输出边的节点。

问题 8：计算 2^x

如何快速计算 2^x？

优秀答案：1 << x (1 left‐shifted by x)

问题 9：二叉搜索树

二叉搜索树是一种排序保存项目的数据结构，它由二叉树组成。每个节点都有一个指向两个子节点的指针（可能为 null），一个指向其父节点的可选指针（也可以为 null），以及一个存储在树中的元素（可能是一个字符串或一个整数）。要使二叉搜索树有效，每个节点的元素必须大于其左子树中的每个元素，并且小于其右子树中的每个元素。例如，二叉树可能如下所示：

要检查元素是否出现在二叉搜索树中，只需要遵循父对子之间的相应连接。例如，如果我们想在上面的树中搜索 15，我们从最上方的 17 开始。由于 15<17，我们移动到左边的节点 6。由于 15> 6，我们移动到右边的节点 12；由于 15>12，我们再次移动到正确的节点 15，最终找到了需要的数字。

要将元素加入二叉搜索树，我们就要像搜索元素一样，遵循从父节点到子节点的正确连接。当所需的子项为 null 时，我们将该元素添加为新的子节点。例如，如果我们要在上面的树中添加 14，我们就需要不断往下寻找添加的位置。当我们到达 15，就会看到该节点没有左子节点，因此我们将 14 添加为左子节点。

要从二叉搜索树中删除一个元素，我们首先要找出包含该元素的节点。如果该节点没有子节点，直接删除即可。如果该节点有一个子节点，则用这个子节点替代它。如果该节点有两个子节点，我们通过一种算法确定树中下一个更小或下一个更大的元素。为简单起见，这里就不赘述所使用的算法了。我们将节点中存储的元素设定为该值。之后，我们从树中拼接包含该值的节点。这个过程相对较容易，因为节点最多有一个子节点。例如，为了从树中删除 6，我们首先将节点值更改为 3。之后，我们删除原本值为 3 的节点，并将原本值为 6 的节点的左子节点值设定为 1。

在二叉搜索树上做小小的修改，就可以使用它将键与值关联起来，就像在散列表中一样。我们不需要在每个节点上存储单个值，而是存储一个键值对。该树将根据节点的键进行排序。

面试官有时会问到二叉搜索树的问题。此外，二叉搜索树往往在回答面试问题时也很有用。需要记住的重要一点是，插入、删除和查找需要的时间为 O(log n)，其中 n 是树中的元素数量，因为一个平衡良好的二叉搜索树的高度是 O(log n)。尽管在最糟糕的情况下，一个二叉搜索树的高度可能为 O(n)，「自平衡」二叉搜索树可以周期性地重组一个 BST 来确保其高度为 O(log n)。许多自平衡 BST 保证这些操作花费的时间为 O(log n)。

问题 10：排除 bug

描述一种从程序中找出 bug 的方法。

答案：这个问题有多个可能的答案，也是面试官经常会问的开放性问题。优秀答案可能包括：根据程序的行为判断可能出现 bug 的部分；使用断点和 stepper 逐步执行程序。任何试图找到 bug 源头和缩小 bug 搜索范围的方法都是好答案。

以上是谷歌程序员面试时可能出现的编程题及解题技巧。当然，只是其中很小的一部分。

想要了解更多问题和答案请点击：http://courses.csail.mit.edu/iap/interview/materials.php
MIT《算法设计与分析》课程资料：https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-046j-design-and-analysis-of-algorithms-spring-2015/

最后祝大家取得一个理想的高考成绩！

谷歌助力，快速实现 Java 应用容器化

Tue, 16 Apr 2019 00:00:00 CST

>>> 加入「后端圈」大家庭 (点击加入)<<<

Google 在 2018 年下旬开源了一款新的 Java 工具 Jib，可以轻松地将 Java 应用程序容器化。通过 Jib，我们不需要编写 Dockerfile 或安装 Docker，通过集成到 Maven 或 Gradle 插件，就可以立即将 Java 应用程序容器化。

开源地址： https://github.com/GoogleContainerTools/jib

一、什么是 Jib

Jib 是一个快速而简单的容器镜像构建工具，它作为 Maven 或 Gradle 的一部分运行，不需要编写 Dockerfile 或运行 Docker 守护进程。它从 Maven 或 Gradle 中构建我们的 Docker 镜像, 并只将发生变更的层（而不是整个应用程序）推送到注册表来节省宝贵的构建时间。现在，我们对 Docker 构建流程和 Jib 构建流程进行对比。Docker 构建流程，如下所示。

Jib 构建流程，则是这样的。

二、实战出真知

1. 构建一个简单的 Java 工程

我们编写一个简单的 Java 类。

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World!");
        System.out.println("http://blog.720ui.com");
    }
}

紧接着，我们再创建一个 pom.xml 文件。

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.lianggzone.sample.lib</groupId>
    <artifactId>helloworld-samples</artifactId>
    <version>0.1</version>
    <packaging>jar</packaging>
    <name>helloworld-samples</name>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <jib-maven-plugin.version>1.0.2</jib-maven-plugin.version>
        <maven-compiler-plugin.version>3.8.0</maven-compiler-plugin.version>
    </properties>
    <dependencies>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>${maven-compiler-plugin.version}</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <!-- Jib -->
            <plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>jib-maven-plugin</artifactId>
                <version>${jib-maven-plugin.version}</version>
                <configuration>
                    <from>
                        <image>registry.cn-hangzhou.aliyuncs.com/lianggzone/oracle_java8</image>
                    </from>
                    <to>
                        <image>registry.cn-hangzhou.aliyuncs.com/lianggzone/jib-helloworld:v1</image>
                    </to>
                    <container>
                        <jvmFlags>
                            <jvmFlag>-Xms512m</jvmFlag>
                            <jvmFlag>-Xdebug</jvmFlag>
                        </jvmFlags>
                        <mainClass>com.lianggzone.HelloWorld</mainClass>
                    </container>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>build</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

由于默认访问谷歌的 gcr.io 仓库，而国内访问 gcr.io 不稳定会经常导致网络超时，所以笔者使用了国内的阿里云镜像服务，那么就不需要访问谷歌的仓库了。现在，我们执行 mvn compile jib:build命令进行自动化构建，它会从 <from>拉取镜像，并把生成的镜像上传到 <to>设置的地址。这里，笔者还通过` 设置了一些 JVM 参数。

mvn compile jib:build

此外，如果”登录失败，未授权”，需要通过 docker login登录鉴权一下。此外，更好的做法是，你可以考虑在Maven 中放置凭据。

<settings>
  ...
  <servers>
    ...
        <server>
          <id>registry.cn-hangzhou.aliyuncs.com</id>
          <username>你的阿里云账号</username>
          <password>你的阿里云密码</password>
        </server>
  </servers>
</settings>

最后，执行完成后，我们可以在阿里云镜像仓库获取镜像。

大功告成，现在，我们来验证一把。我们通过 docker pull拉取镜像，并运行。

docker pull registry.cn-hangzhou.aliyuncs.com/lianggzone/jib-helloworld:v1
docker run --name jib-helloworld -it registry.cn-hangzhou.aliyuncs.com/lianggzone/jib-helloworld:v1 /bin/bash

执行结果，如下所示。

2. 构建一个 SpringBoot 的可运行 Jar

我们来一个复杂一些的项目，构建一个 SpringBoot 的项目。关于 SpringBoot 的使用，可以阅读笔者之前的文章： http://blog.720ui.com/columns/springboot_all/。现在，我们首先需要搭建一个工程，并创建一个启动类。

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

同时，需要一个 Web 的接口。

@RestController
public class WebController {
    @RequestMapping("/blog")
    public String index() {
        return "http://blog.720ui.com";
    }
}

紧接着，我们再创建一个 pom.xml 文件。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.2.RELEASE</version>
    </parent>

    <groupId>com.lianggzone.sample.lib</groupId>
    <artifactId>springboot-samples</artifactId>
    <version>0.1</version>
    <packaging>jar</packaging>
    <name>springboot-samples</name>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
    </dependencies>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <jib-maven-plugin.version>1.0.2</jib-maven-plugin.version>
        <maven-compiler-plugin.version>3.8.0</maven-compiler-plugin.version>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>${maven-compiler-plugin.version}</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <!-- Jib -->
            <plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>jib-maven-plugin</artifactId>
                <version>${jib-maven-plugin.version}</version>
                <configuration>
                    <from>
                        <image>registry.cn-hangzhou.aliyuncs.com/lianggzone/oracle_java8</image>
                    </from>
                    <to>
                        <image>registry.cn-hangzhou.aliyuncs.com/lianggzone/jib-springboot:v1</image>
                    </to>
                    <container>
                        <jvmFlags>
                            <jvmFlag>-Xms512m</jvmFlag>
                            <jvmFlag>-Xdebug</jvmFlag>
                        </jvmFlags>
                    </container>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>build</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

现在，我们执行 mvn compile jib:build命令进行自动化构建。执行完成后，我们可以在阿里云镜像仓库获取镜像。

现在，我们再来验证一把。我们通过 docker pull拉取镜像，并运行。

docker pull registry.cn-hangzhou.aliyuncs.com/lianggzone/jib-springboot:v1
docker run -p 8080:8080 --name jib-springboot -it registry.cn-hangzhou.aliyuncs.com/lianggzone/jib-springboot:v1 /bin/bash

执行结果，如下所示。

现在，我们访问 http://localhost:8080/blog，我们可以正常调用 API 接口了。

3. 构建一个 WAR 工程

Jib 还支持 WAR 项目。如果 Maven 项目使用 war-packaging 类型，Jib 将默认使用 distroless Jetty作为基础镜像来部署项目。要使用不同的基础镜像，我们可以自定义 <container><appRoot>， <container> <entrypoint>和 <container> <args>。以下是使用 Tomcat 镜像的案例。

<configuration>
  <from>
    <image>tomcat:8.5-jre8-alpine</image>
  </from>
  <container>
    <appRoot>/usr/local/tomcat/webapps/ROOT</appRoot>
  </container>
</configuration>

谷歌拼音输入法离线包下载

Sat, 13 Apr 2019 12:38:23 CST

由于谷歌拼音输入法无法在中国大陆下载，因此提供文件来源于谷歌官方网站的谷歌拼音输入法离线包（Windows 10/8.1/8/7 64 位）下载。

下载谷歌拼音输入法离线包

谷歌拼音输入法是由谷歌中国实验室开发，于2007年4月2日发布 [2]的汉语拼音输入法。10月25日成为Google的正式产品之一 [3]。

谷歌拼音输入法1.0.15.0版盗用了搜狗拼音输入法的词库 [4]，随后谷歌发布致歉声明。并于2007年4月9日发布1.0.17.0版，称改用了自家的词库。

随后， Google在其博客“Google 黑板报”上发布有两份声明，第一份是对盗用词库表示致歉明白卡 [5]，第二份则称输入法中包含 Google工程师申请的专利。

谷歌拼音输入法在PC端已经停止更新。2018年6月，下载页面完全从网站撤下，而文件则至2019年3月仍未撤下。用户在PC上使用已安装的谷歌拼音输入法无法登录Google账号和使用其自动同步功能。

谷歌浏览器Chrome离线包下载

Sat, 13 Apr 2019 12:31:55 CST

由于谷歌浏览器Chrome无法在中国大陆下载，因此提供文件来源于谷歌官方网站的谷歌浏览器Chrome离线包（Windows 10/8.1/8/7 64 位）下载。

下载谷歌浏览器Chrome离线包

Google Chrome是由 Google开发的免费网页浏览器 ^[9]。Chrome是化学元素“ 铬”的英文名称，过去也用Chrome称呼浏览器的外框 ^[10] ^[11] ^[12] ^[13]。Chrome相应的开放源代码计划名为 Chromium ^[14] ^[15]，而Google Chrome本身是非自由软件，未开放全部源代码 ^[9] ^[16]。

Chrome代码是基于其他开放源代码软件所编写，包括 Apple WebKit和 Mozilla Firefox，并开发出称为“ V8”的高性能 JavaScript引擎 ^[17]。Google Chrome的整体发展目标是提升稳定性、速度和安全性，并创造出简单且有效率的用户界面 ^[18]。 CNET旗下的 Download.com网站评出的2008年6月最佳Windows应用程序，其中Google Chrome排名首位 ^[19]。

据 StatCounter统计，截至2018年第一季度，Google Chrome在全球桌面浏览器的网页浏览器的使用分布为66% ^[20]。

Chrome 50结束了对 Windows XP与 Windows Vista系统的支持 ^[21]，这两个系统上的最后版本为49.0.2623.112 ^[22]

AI项目被谷歌撂挑子美国防部愤而狂挖硅谷AI人才

Mon, 14 Jan 2019 18:56:42 CST

据连线杂志报道，美国军方正竭力在人工智能（AI）领域取得进展。美国国防部的高级官员相信，AI将是确保美国在未来战争中取得胜利的关键。但国防部的内部文件和对高级官员的采访都表明，国防部因为被一家科技巨头抛弃而陷入步履蹒跚的窘境。为摆脱这种困境，美国国防部开始了一场争夺AI人才的大战。

2018年6月份，谷歌宣布退出美国国防部备受争议的Project Maven项目，Project Maven是美国军方首次探索在战争中大规模使用AI的项目。该项目使用谷歌AI软件提高视频分析效率，帮助情报分析师从视频片段中识别出军事目标。10月份，数千名谷歌员工签署了一份请愿书，呼吁公司终止在该项目上与美国军方的合作。

据五名熟悉有关Project Maven内部讨论的消息人士透露，谷歌的撤出让美国国防部内部感到挫败和沮丧，甚至是愤怒。

6月28日，分发给大约50名美国国防部官员的内部备忘录称：“我们无意中卷入了一场关于战略叙述的争论。”这份备忘录指出，美国国防部因谷歌的撤出措手不及，该机构目前正面临AI专家日益疏远它们的窘境，而这些人对军方AI发展计划至关重要。备忘录中警告称:“如果我们不能赢得关键人物的支持，我们就无法有效地与对手竞争。”

Project Maven项目2017年的成本只有7000万美元左右，这是美国国防部当年6000亿美元海量预算中非常少的部分。但谷歌的声明表明，该部门仍在努力应对更大的公共关系和科学挑战。到目前为止，谷歌的回应是试图为其AI研发工作塑造全新的公众形象，并寻求组建由科技公司高管组成的顾问团对国防部的AI政策进行审查。

美国国防部感到焦虑的原因是显而易见的：它希望未来能把AI集成到武器中，这一愿望已经得到了数十亿美元承诺的支持，以及数十亿美元的技术研发资金支持。

AI最终会在战争中扮演什么样的角色还不清楚。许多AI武器将不涉及机器算法的决策，但它们正在朝这方面努力。美国国防部去年8月的一份战略文件提到:“支撑无人系统的技术将使开发和部署自主系统成为可能，这些系统可以独立选择目标，并以致命武力发动攻击。”

美国国防部的官员们表示，开发AI不同于开发其他军事技术。尽管军方很容易就能从大型国防承包商那里获得最前沿的战斗机和炸弹，但AI和机器学习创新的核心却属于硅谷的非国防科技巨头。官员们担心，如果没有他们的帮助，美国军方可能会输掉一场不断升级的全球军备竞赛。在这场竞赛中，AI将扮演越来越重要的角色。

现任美国国防部下属的国防数字服务（DDS）负责人克里斯·林奇(Chris Lynch)在采访中说：“如果决定不参与Project Maven，实际上也未参与讨论AI或机器学习是否将被用于军事行动。”他说，AI正在走向战争，所以问题在于，哪些美国技术专家会去设计它？

林奇表示，AI技术太重要了，即使需要依靠不那么专业的专家，该机构也会继续推进这方面的工作。但林奇补充说：“如果没有行业内最优秀人才的帮助，我们就会雇佣那些能力不算最强的人，首先开发能力或许远不如我们预期的产品。”

谷歌不太可能很快转变态度。在宣布该公司将不再寻求续签Project Maven合同不到一个星期之后，谷歌发布了新的AI指导原则，特别说明该公司不会使用AI“用于帮助开发武器或其他用于直接伤害人类的产品”。自那以来，许多美国国防官员一直抱怨谷歌不爱国，并指责该公司仍在寻求与中国政府合作。中国是美国在AI技术领域的最大竞争对手。

据知情人士透露，Project Maven旨在简化情报分析师的工作，方法是在无人机和其他平台的视频片段中标注目标类型，帮助分析师收集信息，并缩小对潜在目标的关注范围。但这些算法并没有选择目标，也没有下达攻击指令。长期以来，那些担心先进计算技术与新形式致命暴力相结合的人，对这种算法总是有种胆战心惊的感觉。

谷歌的许多人还是以令人担忧的眼光看待这个项目。一位熟悉内部讨论的前谷歌员工表示:“他们立即想到了无人机，然后他们又想到了机器学习和自动目标识别，我认为这个项目开发的AI很快就会升级，让它们能够进行有针对性地杀戮，发动有针对性的战争。”

谷歌只是美国国防部寻求招募的科技巨头之一，其目的是将AI注入现代战争中。其他目标还包括微软和亚马逊。据现任和前任美国国防部官员说，在谷歌2018年6月份宣布退出的消息后，十几家大型防务公司接洽了国防部官员，提出愿意接手这一工作。但硅谷活动人士也表示，军方不能轻易忽视科技工作者的道德疑虑。

上述那位前谷歌员工表示:“那些对股东负责的人、那些希望获得国防部价值数百万美元合同的人，与那些不得不研发这些东西、但又觉得自己在道德上与这些东西格格不入的普通员工之间，存在一种分歧。”为了弥合这一鸿沟，缓和AI工程师的尖锐反对情绪，美国国防部迄今采取了两项举措。

第一项措施于6月底正式启动，目的是建立一个联合AI中心，旨在监督和管理军方的所有AI工作。这个中心将由陆军中将杰克·沙纳汉(Jack Shanahan)负责，他的最后一项主要任务是执行Project Maven。这是个政治上非常精明的决定，它的第一个重大举措是找出一种利用AI帮助军队在自然灾害中组织搜索和救援的方法。

美国国防部AI战略的首席设计师之一布伦丹·迈考德（Brendan McCord）表示：“我们的目标是拯救生命，我们军队的根本作用和使命是维持和平。这是为了阻止战争和保护我们的国家。这是为了提高全球稳定，也是为了最终保护启蒙运动产生的一系列价值观。”

第二项举措是要求由一个由技术专家组成的咨询小组——国防创新委员会，对AI道德进行新的审查。该委员会成员包括前谷歌首席执行官埃里克·施密特(Eric Schmidt)和职业社交网站LinkedIn联合创始人里德·霍夫曼(Reid Hoffman)。

这个委员会旨在为军方使用AI制定指导原则，目前由约书亚·马尔库塞(Joshua Marcuse)管理。马尔库塞曾担任美国国防部长创新问题顾问，现在他是该委员会的执行董事。该顾问团将与AI专家举行公开会议，为期约9个月，同时美国国防部内部的一个小组也在讨论类似问题。然后，防创新委员会将向国防部长詹姆斯·马蒂斯(James Mattis)提出关于AI是否应该被植入武器计划的建议。马尔库塞在采访中说:“这必须是真正意义上的审查，愿意对我们将要做的和不愿做的事情施加些限制，明确界限所在。”

为了确保这场辩论的公正性，马尔库塞表示，国防创新委员会正在寻找对军方在AI领域中所扮演角色持批评态度的人士。他说：“他们有各种各样的担忧，包括有效性、合法性等问题，以及国防部将如何应用这些技术，因为在某些情况下，我们有合法权力侵犯人们的隐私，我们有法律权威实施暴力，我们有合法权力发动战争。”

美国国防部的官员们表示，解决这些担忧至关重要，因为美国在管理AI人才方面与其他国家存在差异。马尔库塞说:“这些人必须选择与我们合作，所以我们需要向他们提供有意义的、可核实的承诺，那就是他们有真正的机会与我们共同工作，让他们能够相信自己是好人，AI技术被用于好的方面。”

尽管马尔库塞愿意讨论未来对AI采用的潜在限制，但他认为国防创新委员会不会试图改变美国国防部依赖AI自动武器的政策。奥巴马政府于2012年制定了这一政策。特朗普政府在2017年5月对其进行了小幅度技术修改，但并未阻止军方在任何武器系统中使用AI。

美国国防部多位官员表示，该机构的政策要求指挥官对任何植入AI的武器系统拥有“适当程度的人类判断控制”，不过这一说法尚未得到进一步解释。然而，这项政策确实要求，在计算机被编程启动致命行动之前，包含它的武器系统必须经过美国国防部三位高级官员的特别审查。到目前为止，还没有进行过这类特别审查。

据一位熟悉细节的前国防部官员透露，2016年底，即奥巴马政府任期即将结束之际，美国国防部重新审视了2012年的政策，并在一份机密报告中决定，不需要进行重大改革。这位前官员说：“没有任何东西被阻止，没有人想要更新指令。”

尽管如此，特朗普政府在内部讨论过，让军方的武器工程师更清楚地知道，该政策并不禁止在武器系统中加入自主权。特朗普政府担心军方的武器工程师不愿将AI应用到他们的设计中。硅谷对Project Maven的争论至少暂时阻止了这种讨论，促使美国国防部领导人首先努力赢得国防创新委员会的支持。

但无论如何，美国国防部打算将更多的AI集成到其武器中。马尔库塞说:“我们不会对一项可能彻底改变战争模式的新技术视而不见，这对美国民众、对我们派往战场的军人以及依赖我们的盟友来说都不公平。”

「不作恶」谷歌的人工智能之路

Fri, 14 Dec 2018 17:12:00 CST

近日，谷歌CEO Sundar Pichai 在国会山众议院司法委员会（House Judiciary Committee）的会议厅接受了长达3.5个小时的议员质询。

这次质询集中在以下几个焦点：中国版谷歌搜索问题、抵制特朗普问题、窃取信息问题。

在国会议员咄咄逼人的质问下，Pichai一一对答。

这次听证会是一系列国会听证会中的最新一次，这些听证会明确了立法者对大型互联网公司权力的担忧。

甚至有国会议员警告说：“谷歌很可能选出下一任总统”。

此前，谷歌由于与五角大楼签署Maven合同而迎来了一场辞职浪潮，该合同所涉及的项目是将人工智能技术应用到无人机镜头分析上去。

谷歌最后决定不续签这份合同，CEO桑达尔·皮查伊（Sundar Pichai）还发布了“人工智能准则”（AI Principles）。

而在昨天，谷歌发表博文称，在能制定出相关政策以阻止备受争议的面部识别技术被滥用之前，该公司将暂不出售采用这种技术的产品，并且积极与其他一些团体合作以确定面部识别技术可能存在的问题。

谷歌现在最大的标签已经是一家以人工智能驱动的科技公司，但是，谷歌的人工智能之路一直是在质疑、辞职和罢工中前进，其“do not be evil（不作恶）”理念似乎在“被遗忘”和“重新拾起”中拉扯。

一、谷歌人工智能的落地之路

谷歌的人工智能之路一直很清晰，就是以人工智能技术为核心，在不同的平台转化为不同的智能产品。

谷歌的研发包罗万象，医疗、自动驾驶、语音助手等每个热门领域都想分一杯羹，从投资到收购，谷歌的人工智能大旗屹立不倒。

自动驾驶

12月5日，谷歌旗下的自动驾驶技术公司Waymo终于在测试10年之后，上线了第一个自动驾驶商业服务——Waymo one。

这一商业化的落地巩固了Waymo自动驾驶全球第一的地位。

根据Waymo公布的消息，该公司首先向用户开放APP使用权，用户使用APP任何时候都可以呼叫Waymo自动驾驶车辆。目前，该服务仅在凤凰城郊区约100英里范围内运营。

和当地的Uber或者Lyft收费差不多，在钱德勒市行驶3英里，费用7美元，合人民币10元/公里。

但是，车内依旧有安全驾驶员，没有实现完全自动驾驶。

之前，谷歌的无人驾驶汽车一直由谷歌旗下秘密研究部门Google X负责，2016年，谷歌成立无人驾驶汽车项目成立 “Waymo”的独立实体公司。

谷歌的无人驾驶研发之路可以说一直很坎坷，早在2009年，谷歌就开始进行自动驾驶实验，这种先发优势让Waymo成为自动驾驶行驶里程最长的公司。

其中在公共道路上的行驶里程超过400万英里，在无人驾驶汽车的实际行驶英里数方面保持领先。

但是，到了2016年，其他例如特斯拉已经售出的约10万辆电动车，这些电动车大多都跑在路上测试、收集无人驾驶数据，Uber也已经开始在匹兹堡试营运无人驾驶出租车队。

谷歌的无人驾驶研发依旧没有实质性进展，其实，这主要是由于谷歌对待无人驾驶技术一直很谨慎。

上个月，Waymo公司CEO John Krafcik在WSJ D.Live技术大会上承认了自动驾驶道路漫长，他说，虽然无人驾驶汽车“真正在这里”，现实中也出现了自动驾驶汽车，但它们还远远没有普及。最主要的原因在于，自动驾驶技术还没有达到在任何天气和任何条件下都能驾驶的最高等级L5。

换句话说，道路场景复杂多变，目前的算法还达不到那么高的要求。

苹果联合创始人Steve Wozniak也说：“道路是由人类建造的，人类是不完美的，而且汽车目前无法解释这一因素。”

语音助手

谷歌是在2016年发布语音助手Google Assistant的，相比苹果的语音助手Siri，谷歌晚了五年，相比亚马逊的语音助手Alexa，谷歌晚了两年。

目前，承载谷歌语音助手的主要是谷歌推出的智能音箱Google Home和智能手机上的语音软件。

谷歌入局智能音箱较晚，去年才推出首款智能音箱设备Google Home，但是，凭借其价格和渠道优势，谷歌智能音箱销量一路稳增，到了今年的第一季度，谷歌的智能音箱出货量首次超越亚马逊。

要知道，从亚马逊推出首款智能音箱以来，一直占据着绝对的市场份额，几乎成为智能音箱的代名词。

根据市场研究机构Canalys的报告，2018年第一季度智能音箱全球出货量接近900万台，与去年同期相比增长210%。

其中，谷歌凭借 Google Home 和Google Home mini 系列出货 320 万台，首次超越亚马逊，亚马逊Echo系列设备出货了250万台。

谷歌的智能音箱在销售额方面增长更快，同比增长483％，2018年第一季度的市场份额达到32%。

而亚马逊的智能音箱销售额同比增长8%，但市场份额从2017年第一季度的接近80%下降到约28%。

到了第三季度，亚马逊重回冠军宝座，Echo系列智能音箱的销量排在第一名，售出630万台。

但是，谷歌紧随其后，Google Home系列智能音箱售出了590万台。

从全球市场份额来看，亚马逊排在第一名，占有31.9%的市场份额，同比增长了1.3%。

而谷歌占有29.8%的市场份额，同比增长了187%。

为什么谷歌的智能音箱可以在这么短的时间内就可以追上亚马逊，除了价格和渠道优势以外，最重要的是相比亚马逊的语音助手Alexa和苹果的语音助手Siri 来说，谷歌的语音助手Google Assistant更加智能。

今年5月，谷歌在美国加州山景城举办的Google I/O开发者大会，大会没有发布任何新品，而是升级了Google Assistant。

谷歌让语音助手可以像人一样思考，Google将这项技术成为Google Duplex，指解决一个我们打电话才能完成的事。

这种技术让语音助手的声音更加自然，接近人的声音，除此之外，它回答问题也更加智能。

谷歌语音助手依赖搜索技术，正在打通智能家居、搜索、地图、线下服务，成为一个新的平台。目前为止，谷歌语音助手接入手机、汽车与智能家庭设备达5亿台，支持30多种语言，进入了80多个国家与地区。

医疗健康

谷歌很重视人工智能在医疗领域的落地应用。

今年11月，谷歌新组建Google Health，并把DeepMind公司的健康业务纳入其中。

谷歌在2014年以6亿美元收购这家在当时只是个小透明的人工智能公司，那时，DeepMind的官网用大大的字体写着“DeepMind很高兴成为Google的一部分”。

到了2015年，DeepMind研发出AlphaGo，打败世界围棋冠军李世石，从此一战成名。

自此，DeepMind的首页没有了Google的字样。

到了明年3月，Google收购DeepMind五周年，DeepMind可以自行决定去留。

再说回谷歌的医疗AI，谷歌CEO Sundar Pichai说：“未来，如果人工智能要重塑医疗保健行业，它就需要遵守医疗保健的相关规定，事实上，我认为AI+医疗将成为未来10到20年间产生最大利益的领域之一。”

2015年，谷歌对企业架构进行调整，成立母公司Alphabet。

Verily、DeepMind和Calico是Alphabet旗下专注于医疗健康的三家子公司。

这三家子公司的医疗保健计划主要是使用AI来解决疾病，从监测、检测到生活方式管理。

Verily是最主要的医疗公司，Alphabet的大部分医疗工作都是在这里完成的。这家子公司专注于通过分析工具、干预措施、研究等手段利用数据改善目前的医疗保健。

目前，Verily专攻眼疾，并且一直在申请与接触和眼植入相关的专利。

Verily一直致力于生产一款可以轻松监控数亿糖尿病患者的血糖水平隐形眼镜，这个项目于2014年启动。

但是，前不久，由于技术挑战难度太高，Verily已经停止研发。

Verilfy首席技术官Brian Otis 说：“我们对葡萄糖感应镜片的临床研究表明，我们测量泪液葡萄糖和血糖浓度之间的相关性，以支持医疗设备的要求，这种一致性不够充分。”

该项目已经证明了智能隐形眼镜的其他用途。这些镜片可用于传输和感应其他数据，可用于构建智能镜片，以解决白内障手术患者的远视并且可以改善视力。

DeepMind从2016年开始涉足医疗健康领域，那一年，DeepMind成立DeepMind Health部门，致力于利用AI向临床护士、医生以及专家教授提供辅助工具。

DeepMind开发了一个名为Streams的应用程序，主要功能是变身人工智能助理护士和助手。目前，Streams应用程序正在英国试用。

除了Streams应用程序外，三年来，DeepMind在医疗领域的研究成果还包括AI检测眼部疾病，扫描头颈癌以及预测肾脏损伤等。

Calico专注于研究与抵御衰老以及与年龄有关的疾病。该子公司使用AI来理解大型数据集，同时，实现实验室流程的自动化。

除此之外，谷歌还专注于糖尿病、心脑血管疾病和帕金森氏症等疾病的监测与管理。

例如，谷歌推出的小型连续葡萄糖监测器（CGM），目前已经提交给FDA批准的Dexcom G6监测系统，可以监测你皮肤下的间质葡萄糖水平。

还有可穿戴设备Study Watch。该设备由研究人员使用来监测参与者的不同生物标记，包括心电图（ECG）和心率监测器。研究人员可以利用它来发现早期异常现象，有助于在疾病发展的早期发现心脏病预测因子。

二、谷歌人工智能的收购之路

自2012年以来，谷歌就频繁收购AI公司为其人工智能铺路。

2013年，谷歌收购了多伦多大学计算机系的创业公司。DNNresearch主营深度学习与神经网络方向。

2014年，谷歌收购Deepmind，这应该是目前最火的人工智能公司，其在游戏、医疗和计算等领域都有不俗的表现。

同年，谷歌收购Dark Blue Labs，这是一家深度学习公司，主要从事数据架构以及算法开发工作，被收购后并入DeepMind。

2016年，谷歌收购Moodstocks，Moodstocks公司是以图像识别技术为主，并推出了智能手机的图像识别应用程序Moodstocks Notes。

除此之外，谷歌还收购了专注于计算机视觉、自然语言处理等一系列AI初创公司近20家，可以看出，谷歌的收购涵盖了人工智能大方向下的各个领域，为谷歌的人工智能发展提供技术支持。

结语

推动谷歌人工智能研发的方向只有两个，一是坚持七大原则：

1、对社会有益；2、避免制造或加强不公平的偏见；3、建立并测试安全性；4、对人负责；5、融入隐私设计原则；6、坚持科学卓越的高标准；7、为符合这些原则的用途提供服务。

二是让AI变得简单易用。

原则是一回事，能不能按原则办事又是另一回事，我们不得不承认谷歌对推动人工智能应用落地做出了很大努力，但是，回顾谷歌近几年的新闻就会发现，谷歌就像是纠结的“天秤座”，既想要认真搞研发又想要马上得到商业回报。

谷歌的人工智能之路，道阻且长。

谷歌最强 NLP 模型 BERT 解读

Tue, 23 Oct 2018 11:44:00 CST

雷锋网 AI 科技评论按：本文是追一科技潘晟锋基于谷歌论文为 AI 科技评论提供的解读稿件。

最近谷歌研究人员通过新的BERT模型在11项NLP任务中夺得STOA结果，这在自然语言处理学界以及工业界都引起了不小的热议。作者通过在33亿文本的语料上训练语言模型，再分别在不同的下游任务上微调，这样的模型在不同的任务均得到了目前为止最好的结果，并且有一些结果相比此前的最佳成绩得到了幅度不小的提升。作者的这一研究其实是今年深度学习在自然语言处理中一个新热点方向的延续，故事还得从更早一点说起。

BERT的“前任”们

早在2015年的时候，微软研究院的何恺明和他的同事们发表了残差网络的论文，第一次通过残差的方式将卷积神经网络推进到了100层以上，并在图像识别的任务上刷新了当时的最高纪录。自那以后起，随着网络不断地加深，效果也在不断提升。然而大量的数据训练出来的大型网络虽然效果更好，但随着网络的加深以及数据集的不断扩大，完全重新训练一个模型所需要的成本也在不断地增加。

因此在计算机视觉处理中，人们越来越多地采用预训练好的大型网络来提取特征，然后再进行后续任务。目前这种处理方式已经是图像处理中很常见的做法了。

相比之下，自然语言处理目前通常会使用预训练的词向量来进行后续任务。但词向量是通过浅层网络进行无监督训练，虽然在词的级别上有着不错的特性，但却缺少对连续文本的内在联系和语言结构的表达能力。因此大家也希望能像图像领域那样，通过大量数据来预训练一个大型的神经网络，然后用它来对文本提取特征去做后续的任务，以期望能得到更好的效果。其实这一方向的研究一直在持续，直到今年的早些时候AllenAI提出的[ELMo](https://arxiv.org/pdf/1802.05365.pdf)由于其在后续任务上的优异表现获得了不小的关注。

在CMRC2018阅读理解比赛中，追一科技的参赛方案就运用了ELMo模型的预训练方式，并做了相应的改进。因为原本的ELMo当中对英文进行了字符级别的编码，但这对中文并不适用。我们在此基础上改进为笔画级别的编码，同时结合原有的词级别编码一起通过双层LSTM变换来进行语言模型预训练。经过实验验证，最后选择了512维的词级别ELMo向量进行后续任务。

在ELMo获得成功以后不久FastAI就推出了[ULMFiT](https://arxiv.org/abs/1801.06146)，其大体思路是在微调时对每一层设置不同的学习率。此后OpenAI又提出了[GPT](https://blog.openai.com/language-unsupervised/)。预训练的语言模型是在百度15亿词文本的语料上进行的，模型参数选择了12层，12head的Transformer结构。然后采用此模型直接在子任务上微调来进行后续任务。

从上面提及的这些论文的结果以及学界和工业界的反馈来看，这种使用大量的语料进行预训练，然后再在预训练好的模型上进行后续任务训练，虽然训练方式各有不同，但在后续任务都有不同程度的提高。

而谷歌提出的BERT就是在OpenAI的GPT的基础上对预训练的目标进行了修改，并用更大的模型以及更多的数据去进行预训练，从而得到了目前为止最好的效果。

Trransformer的编码器结构

BERT的主体结构和创新点

BERT模型沿袭了GPT模型的结构，采用[Transfomer](https://arxiv.org/abs/1706.03762)的编码器作为主体模型结构。Transformer舍弃了RNN的循环式网络结构，完全基于注意力机制来对一段文本进行建模。

Transformer所使用的注意力机制的核心思想是去计算一句话中的每个词对于这句话中所有词的相互关系，然后认为这些词与词之间的相互关系在一定程度上反应了这句话中不同词之间的关联性以及重要程度。因此再利用这些相互关系来调整每个词的重要性（权重）就可以获得每个词新的表达。这个新的表征不但蕴含了该词本身，还蕴含了其他词与这个词的关系，因此和单纯的词向量相比是一个更加全局的表达。

Transformer通过对输入的文本不断进行这样的注意力机制层和普通的非线性层交叠来得到最终的文本表达。

Transformer的注意力层得到的词-词之间关系

GPT则利用了Transformer的结构来进行单向语言模型的训练。所谓的语言模型其实是自然语言处理中的一种基础任务，其目标是给定一个序列文本，预测下一个位置上会出现的词。

模型学习这样的任务过程和我们人学习一门语言的过程有些类似。我们学习语言的时候会不断地练习怎么选用合适的词来造句，对于模型来说也这样。例如：

> 今天天气不错，我们去公园玩吧。

这句话，单向语言模型在学习的时候是从左向右进行学习的，先给模型看到“今天天气”两个词，然后告诉模型下一个要填的词是“不错”。然而单向语言模型有一个欠缺，就是模型学习的时候总是按照句子的一个方向去学的，因此模型学习每个词的时候只看到了上文，并没有看到下文。更加合理的方式应该是让模型同时通过上下文去学习，这个过程有点类似于完形填空题。例如：

>今天天气 { }，我们去公园玩吧。

通过这样的学习，模型能够更好地把握“不错”这个词所出现的上下文语境。

而BERT对GPT的第一个改进就是引入了双向的语言模型任务。

此前其实也有一些研究在语言模型这个任务上使用了双向的方法，例如在ELMo中是通过双向的两层RNN结构对两个方向进行建模，但两个方向的loss计算相互独立。追一科技在文本意图模型中，也加入了通过上下文预测某个词的辅助任务，通过实验发现在做意图分类的同时加入这个辅助任务能够让编码器尽可能的包含输入文本的全局信息，从而提高意图判断的准确率。

而BERT的作者指出这种两个方向相互独立或只有单层的双向编码可能没有发挥最好的效果，我们可能不仅需要双向编码，还应该要加深网络的层数。但加深双向编码网络却会引入一个问题，导致模型最终可以间接地“窥探”到需要预测的词。这个“窥探”的过程可以用下面的图来表示：

从图中可以看到经过两层的双向操作，每个位置上的输出就已经带有了原本这个位置上的词的信息了。这样的“窥探”会导致模型预测词的任务变得失去意义，因为模型已经看到每个位置上是什么词了。

为了解决这个问题，我们可以从预训练的目标入手。我们想要的其实是让模型学会某个词适合出现在怎样的上下文语境当中；反过来说，如果给定了某个上下文语境，我们希望模型能够知道这个地方适合填入怎样的词。从这一点出发，其实我们可以直接去掉这个词，只让模型看上下文，然后来预测这个词。但这样做会丢掉这个词在文本中的位置信息，那么还有一种方式是在这个词的位置上随机地输入某一个词，但如果每次都随机输入可能会让模型难以收敛。

BERT的作者提出了采用MaskLM的方式来训练语言模型

通俗地说就是在输入一句话的时候，随机地选一些要预测的词，然后用一个特殊的符号来代替它们。尽管模型最终还是会看到所有位置上的输入信息，但由于需要预测的词已经被特殊符号代替，所以模型无法事先知道这些位置上是什么词，这样就可以让模型根据所给的标签去学习这些地方该填的词了。

然而这里还有一个问题，就是我们在预训练过程中所使用的这个特殊符号，在后续的任务中是不会出现的。

因此，为了和后续任务保持一致，作者按一定的比例在需要预测的词位置上输入原词或者输入某个随机的词。当然，由于一次输入的文本序列中只有部分的词被用来进行训练，因此BERT在效率上会低于普通的语言模型，作者也指出BERT的收敛需要更多的训练步数。

BERT另外一个创新是在双向语言模型的基础上额外增加了一个句子级别的连续性预测任务。这个任务的目标也很简单，就是预测输入BERT的两端文本是否为连续的文本，作者指出引入这个任务可以更好地让模型学到连续的文本片段之间的关系。在训练的时候，输入模型的第二个片段会以50%的概率从全部文本中随机选取，剩下50%的概率选取第一个片段的后续的文本。

除了模型结构，模型大小和数据量都很重要

以上的描述涵盖了BERT在模型结构和训练目标上的主要创新点，而BERT的成功还有一个很大的原因来自于模型的体量以及训练的数据量。

BERT训练数据采用了英文的开源语料BooksCropus 以及英文维基百科数据，一共有33亿个词。同时BERT模型的标准版本有1亿的参数量，与GPT持平，而BERT的大号版本有3亿多参数量，这应该是目前自然语言处理中最大的预训练模型了。

当然，这么大的模型和这么多的数据，训练的代价也是不菲的。谷歌用了16个自己的TPU集群（一共64块TPU）来训练大号版本的BERT，一共花了4天的时间。对于是否可以复现预训练，作者在 [Reddit](https://www.reddit.com/r/MachineLearning/comments/9nfqxz/r_bert_pretraining_of_deep_bidirectional)上有一个大致的回复，指出OpenAI当时训练GPT用了将近1个月的时间，而如果用同等的硬件条件来训练BERT估计需要1年的时间。不过他们会将已经训练好的模型和代码开源，方便大家训练好的模型上进行后续任务。

虽然训练的代价很大，但是这个研究还是带来了一些思考和启发。例如双向语言模型的运用，多任务对预训练的帮助以及模型深度带来的收益。相信在未来的一段时间，自然语言处理中预训练的神经网络语言模型会得到更多的关注和运用。

论文原文： https://arxiv.org/abs/1810.04805

NLP历史突破！谷歌BERT模型狂破11项纪录，全面超越人类！

Sat, 13 Oct 2018 17:29:13 CST

来源：新智元（AI_era）

（来源：arXiv、知乎；编辑：新智元编辑部）

今天，NLP 领域取得最重大突破！谷歌 AI 团队新发布的 BERT 模型，在机器阅读理解顶级水平测试 SQuAD1.1 中表现出惊人的成绩：全部两个衡量指标上全面超越人类，并且还在 11 种不同 NLP 测试中创出最佳成绩。毋庸置疑，BERT 模型开启了 NLP 的新时代！

今天请记住 BERT 模型这个名字。

谷歌 AI 团队新发布的 BERT 模型，在机器阅读理解顶级水平测试 SQuAD1.1 中表现出惊人的成绩：全部两个衡量指标上全面超越人类！并且还在 11 种不同 NLP 测试中创出最佳成绩，包括将 GLUE 基准推至 80.4％（绝对改进 7.6％），MultiNLI 准确度达到 86.7%（绝对改进率 5.6％）等。

谷歌团队的 Thang Luong 直接定义：BERT 模型开启了 NLP 的新时代！

本文从论文解读、BERT 模型的成绩以及业界的评价三方面做介绍。

硬核阅读：认识 BERT 的新语言表示模型

首先来看下谷歌 AI 团队做的这篇论文（论文地址： https://arxiv.org/abs/1810.04805）。

BERT 的新语言表示模型，它代表 Transformer 的双向编码器表示。与最近的其他语言表示模型不同，BERT 旨在通过联合调节所有层中的上下文来预先训练深度双向表示。因此，预训练的 BERT 表示可以通过一个额外的输出层进行微调，适用于广泛任务的最先进模型的构建，比如问答任务和语言推理，无需针对具体任务做大幅架构修改。

论文作者认为现有的技术严重制约了预训练表示的能力。其主要局限在于标准语言模型是单向的，这使得在模型的预训练中可以使用的架构类型很有限。

在论文中，作者通过提出 BERT：即 Transformer 的双向编码表示来改进基于架构微调的方法。

BERT 提出一种新的预训练目标：遮蔽语言模型（masked language model，MLM），来克服上文提到的单向性局限。MLM 的灵感来自 Cloze 任务（Taylor, 1953）。MLM 随机遮蔽模型输入中的一些 token，目标在于仅基于遮蔽词的语境来预测其原始词汇 id。

与从左到右的语言模型预训练不同，MLM 目标允许表征融合左右两侧的语境，从而预训练一个深度双向 Transformer。除了遮蔽语言模型之外，本文作者还引入了一个“下一句预测”（next sentence prediction）任务，可以和 MLM 共同预训练文本对的表示。

论文的核心：详解 BERT 模型架构

本节介绍 BERT 模型架构和具体实现，并介绍预训练任务，这是这篇论文的核心创新。

模型架构

BERT 的模型架构是基于 Vaswani et al. (2017) 中描述的原始实现 multi-layer bidirectional Transformer 编码器，并在 tensor2tensor 库中发布。由于 Transformer 的使用最近变得无处不在，论文中的实现与原始实现完全相同，因此这里将省略对模型结构的详细描述。

在这项工作中，论文将层数（即 Transformer blocks）表示为L，将隐藏大小表示为H，将 self-attention heads 的数量表示为A。在所有情况下，将 feed-forward/filter 的大小设置为 4H，即 H = 768 时为 3072，H = 1024 时为 4096。论文主要报告了两种模型大小的结果：

- BERT _BASE: L=12, H=768, A=12, Total Parameters=110M

- BERT _LARGE: L=24, H=1024, A=16, Total Parameters=340M

为了进行比较，论文选择 BERT _LARGE，它与 OpenAI GPT 具有相同的模型大小。然而，重要的是，BERT Transformer 使用双向 self-attention，而 GPT Transformer 使用受限制的 self-attention，其中每个 token 只能处理其左侧的上下文。研究团队注意到，在文献中，双向 Transformer 通常被称为“Transformer encoder”，而左侧上下文被称为“Transformer decoder”，因为它可以用于文本生成。BERT，OpenAI GPT 和 ELMo 之间的比较如图 1 所示。

图1：预训练模型架构的差异。BERT 使用双向 Transformer。OpenAI GPT 使用从左到右的 Transformer。ELMo 使用经过独立训练的从左到右和从右到左 LSTM 的串联来生成下游任务的特征。三个模型中，只有 BERT 表示在所有层中共同依赖于左右上下文。

输入表示（input representation）

论文的输入表示（input representation）能够在一个 token 序列中明确地表示单个文本句子或一对文本句子（例如， [Question, Answer]）。对于给定 token，其输入表示通过对相应的 token、segment 和 position embeddings 进行求和来构造。图 2 是输入表示的直观表示：

图2：BERT 输入表示。输入嵌入是 token embeddings, segmentation embeddings 和 position embeddings 的总和。

具体如下：

- 使用 WordPiece 嵌入（Wu et al.， 2016）和 30,000 个 token 的词汇表。用##表示分词。

- 使用学习的 positional embeddings，支持的序列长度最多为 512 个 token。

- 每个序列的第一个 token 始终是特殊分类嵌入（[CLS]）。对应于该 token 的最终隐藏状态（即，Transformer 的输出）被用作分类任务的聚合序列表示。对于非分类任务，将忽略此向量。

- 句子对被打包成一个序列。以两种方式区分句子。首先，用特殊标记（[SEP]）将它们分开。其次，添加一个 learned sentence A 嵌入到第一个句子的每个 token 中，一个 sentence B 嵌入到第二个句子的每个 token 中。

- 对于单个句子输入，只使用 sentence A 嵌入。

关键创新：预训练任务

与 Peters et al. (2018) 和 Radford et al. (2018) 不同，论文不使用传统的从左到右或从右到左的语言模型来预训练 BERT。相反，使用两个新的无监督预测任务对 BERT 进行预训练。

任务1：Masked LM

从直觉上看，研究团队有理由相信，深度双向模型比 left-to-right 模型或 left-to-right and right-to-left 模型的浅层连接更强大。遗憾的是，标准条件语言模型只能从左到右或从右到左进行训练，因为双向条件作用将允许每个单词在多层上下文中间接地“see itself”。

为了训练一个深度双向表示（deep bidirectional representation），研究团队采用了一种简单的方法，即随机屏蔽（masking）部分输入 token，然后只预测那些被屏蔽的 token。论文将这个过程称为“masked LM”(MLM)，尽管在文献中它经常被称为 Cloze 任务(Taylor, 1953)。

在这个例子中，与 masked token 对应的最终隐藏向量被输入到词汇表上的输出 softmax 中，就像在标准 LM 中一样。在团队所有实验中，随机地屏蔽了每个序列中 15% 的 WordPiece token。与去噪的自动编码器（Vincent et al.， 2008）相反，只预测 masked words 而不是重建整个输入。

虽然这确实能让团队获得双向预训练模型，但这种方法有两个缺点。首先，预训练和 finetuning 之间不匹配，因为在 finetuning 期间从未看到[MASK]token。为了解决这个问题，团队并不总是用实际的[MASK]token 替换被“masked”的词汇。相反，训练数据生成器随机选择 15％的 token。例如在这个句子“my dog is hairy”中，它选择的 token 是“hairy”。然后，执行以下过程：

数据生成器将执行以下操作，而不是始终用[MASK]替换所选单词：

- 80％的时间：用[MASK]标记替换单词，例如，my dog is hairy → my dog is [MASK]

- 10％的时间：用一个随机的单词替换该单词，例如，my dog is hairy → my dog is apple

- 10％的时间：保持单词不变，例如，my dog is hairy → my dog is hairy. 这样做的目的是将表示偏向于实际观察到的单词。

Transformer encoder 不知道它将被要求预测哪些单词或哪些单词已被随机单词替换，因此它被迫保持每个输入 token 的分布式上下文表示。此外，因为随机替换只发生在所有 token 的 1.5％（即 15％的 10％），这似乎不会损害模型的语言理解能力。

使用 MLM 的第二个缺点是每个 batch 只预测了 15％的 token，这表明模型可能需要更多的预训练步骤才能收敛。团队证明 MLM 的收敛速度略慢于 left-to-right 的模型（预测每个 token），但 MLM 模型在实验上获得的提升远远超过增加的训练成本。

任务2：下一句预测

许多重要的下游任务，如问答（QA）和自然语言推理（NLI）都是基于理解两个句子之间的关系，这并没有通过语言建模直接获得。

在为了训练一个理解句子的模型关系，预先训练一个二进制化的下一句测任务，这一任务可以从任何单语语料库中生成。具体地说，当选择句子A和B作为预训练样本时，B有 50％的可能是A的下一个句子，也有 50％的可能是来自语料库的随机句子。例如：

Input = [CLS] the man went to [MASK] store [SEP]

he bought a gallon [MASK] milk [SEP]

Label = IsNext

Input = [CLS] the man [MASK] to the store [SEP]

penguin [MASK] are flight ##less birds [SEP]

Label = NotNext

团队完全随机地选择了 NotNext 语句，最终的预训练模型在此任务上实现了 97％-98％的准确率。

实验结果

如前文所述，BERT 在 11 项 NLP 任务中刷新了性能表现记录！在这一节中，团队直观呈现 BERT 在这些任务的实验结果，具体的实验设置和比较请阅读原论文。

图3：我们的面向特定任务的模型是将 BERT 与一个额外的输出层结合而形成的，因此需要从头开始学习最小数量的参数。在这些任务中，（a）和（b）是序列级任务，而（c）和（d）是 token 级任务。在图中，E表示输入嵌入，Ti 表示 tokeni 的上下文表示，[CLS]是用于分类输出的特殊符号，[SEP]是用于分隔非连续 token 序列的特殊符号。

图4：GLUE 测试结果，由 GLUE 评估服务器给出。每个任务下方的数字表示训练样例的数量。“平均”一栏中的数据与 GLUE 官方评分稍有不同，因为我们排除了有问题的 WNLI 集。BERT 和 OpenAI GPT 的结果是单模型、单任务下的数据。所有结果来自 https://gluebenchmark.com/leaderboard 和 https://blog.openai.com/language-unsupervised/

图5：SQuAD 结果。BERT 集成是使用不同预训练检查点和微调种子（fine-tuning seed）的 7x 系统。

图6：CoNLL-2003 命名实体识别结果。超参数由开发集选择，得出的开发和测试分数是使用这些超参数进行五次随机重启的平均值。

超过人类表现，BERT 刷新了 11 项 NLP 任务的性能记录

论文的主要贡献在于：

- 证明了双向预训练对语言表示的重要性。与之前使用的单向语言模型进行预训练不同，BERT 使用遮蔽语言模型来实现预训练的深度双向表示。

- 论文表明，预先训练的表示免去了许多工程任务需要针对特定任务修改体系架构的需求。BERT 是第一个基于微调的表示模型，它在大量的句子级和 token 级任务上实现了最先进的性能，强于许多面向特定任务体系架构的系统。

- BERT 刷新了 11 项 NLP 任务的性能记录。本文还报告了 BERT 的模型简化研究（ablation study），表明模型的双向性是一项重要的新成果。相关代码和预先训练的模型将会公布在 goo.gl/language/bert 上。

BERT 目前已经刷新的 11 项自然语言处理任务的最新记录包括：将 GLUE 基准推至 80.4％（绝对改进 7.6％），MultiNLI 准确度达到 86.7%（绝对改进率 5.6％），将 SQuAD v1.1 问答测试 F1 得分纪录刷新为 93.2 分（绝对提升 1.5 分），超过人类表现 2.0 分。

BERT 模型重要意义：宣告 NLP 范式的改变

北京航空航天大学计算机专业博士吴俣在知乎上写道：BERT 模型的地位类似于 ResNet 在图像，这是里程碑式的工作，宣告着 NLP 范式的改变。以后研究工作估计很多都要使用他初始化，就像之前大家使用 word2vec 一样自然。

BERT 一出，那几个他论文里做实验的数据集全被轰平了，大家洗洗睡了。心疼 swag 一秒钟，出现 3 月，第一篇做这个数据集的算法，在超了 baseline 20 多点的同时也超过人了。

通过 BERT 模型，吴俣有三个认识：

1、Jacob 在细节上是一等一的高手

这个模型的双向和 Elmo 不一样，大部分人对论文作者之一 Jacob 的双向在 novelty 上的 contribution 的大小有误解，我觉得这个细节可能是他比 Elmo 显著提升的原因。Elmo 是拼一个左到右和一个右到左，他这个是训练中直接开一个窗口，用了个有顺序的 cbow。

2、Reddit 对跑一次 BERT 的价格讨论

For TPU pods:

4 TPUs * ~$2/h (preemptible) * 24 h/day * 4 days = $768 (base model)

16 TPUs = ~$3k (large model)

For TPU:

16 tpus * $8/hr * 24 h/day * 4 days = 12k

64 tpus * $8/hr * 24 h/day * 4 days = 50k

For GPU:

"BERT-Large is 24-layer, 1024-hidden and was trained for 40 epochs over a 3.3 billion word corpus. So maybe 1 year to train on 8 P100s? "

3、不幸的是，基本无法复现，所以模型和数据谁更有用也不好说。

BERT 的成功也说明，好的深度学习研究工作的三大条件：数据，计算资源，工程技能点很高的研究员（Jacob 在微软时候，就以单枪匹马搭大系统，而中外闻名）。

本文链接

[译] 谷歌团队的容器运维最佳实践

Thu, 11 Oct 2018 08:00:00 CST

谷歌大神们带你进行容器运维最佳实践

本文介绍了一组使容器更易于运维的最佳实践。这些实践涉及安全性、监控和日志记录等广泛的主题，旨在使应用程序更容易在 Kubernetes Engine 和一般的容器中运行。这里讨论的许多实践都受到 12 因素方法的启发，12 因素方法是一个构建云原生应用程序的优质资源。

使用容器的原生日志记录机制

重要性：高

作为应用程序管理的一部分，日志中包含宝贵的信息，可让人了解应用程序中发生的事件。Docker 和 Kubernetes 致力于简化日志管理。

在传统服务器上，你可能需要将日志写入特定文件并处理日志轮换以避免填满磁盘。如果有高级日志系统，则可以将这些日志转发到远程服务器来集中它们。

通过容器可以将日志写入 stdout 和 stderr，因而容器提供了一种简单且标准化的方式来处理日志。Docker 捕获这些日志行，并允许你使用 docker logs 命令访问它们。作为应用程序开发人员，你不需要实现高级日志记录机制，试试用原生的日志记录机制吧。

平台运营商必须提供一个系统来集中日志并进行搜索，你可以使用 Kubernetes Engine 提供的 fluentd 和 Stackdriver Logging。其他常见方法包括使用 EFK （Elasticsearch，Fluentd，Kibana）栈。

图 1. Kubernetes 中典型的日志管理系统图

JSON 日志

大多数日志管理系统实际上是时序数据库，用于存储时间索引文档。这些文档通常以 JSON 格式提供。在 Stackdriver Logging 和 EFK 中，单个日志行和一些元数据（容器组、容器、节点等相关信息）一起被存储为一个文档。

你可以直接通过将不同字段以 JSON 格式进行日志记录。然后，可以根据这些字段更有效地搜索日志。

例如，考虑将以下日志转换为 JSON 格式：

[2018-01-01 01:01:01] foo - WARNING - foo.bar - There is something wrong.

这是转换后的日志：

{
  "date": "2018-01-01 01:01:01",
  "component": "foo",
  "subcomponent": "foo.bar",
  "level": "WARNING",
  "message": "There is something wrong."
}

通过这种转换，你可以在日志中轻松搜索所有 WARNING 级别日志或 foo.bar 组件中的所有日志。

如果你决定记录 JSON 格式的日志，请注意必须在每一行上加入事件才能正确解析。在实际中，它看起来是下面这样：

{"date":"2018-01-01 01:01:01","component":"foo","subcomponent":"foo.bar","level": "WARNING","message": "There is something wrong."}

如你所见，结果远不如正常的日志可读。如果决定使用此方法，请确保你的团队不会严重依赖手动日志检查。

边车模式的记录聚合器

某些应用程序（如 Tomcat）无法通过简单配置来生成日志。这些应用程序在磁盘上写入不同的日志文件，所以在 Kubernetes 中处理它们的最佳方法是使用边车模式进行日志记录。边车是一个小容器，与应用程序在同一个 pod 中运行。有关边车的更详细信息，请参阅 Kubernetes 官方文档（https://kubernetes.io/docs/concepts/cluster-administration/logging/#sidecar-container-with-a-logging-agent）。

在这种解决方案中，你为应用程序的边车容器添加一个日志代理（在同一 pod 中，）并在两个容器之间共享 emptyDir 卷，可参考 GitHub 上的这个 YAML 示例：https://github.com/kubernetes/contrib/blob/0.7.0/logging/fluentd-sidecar-gcp/logging-sidecar-example.yaml。然后，配置应用程序将日志写入共享卷，接着配置日志代理进行读取，并转发到需要的地方。

在此模式中，因为没有使用 Docker 和 Kubernetes 原生的日志记录机制，所以必须处理日志轮换。如果你的日志代理程序不处理日志轮换，则同一 pod 中的另一个边车容器会处理。

图 2. 日志管理的边车模式

确保容器是无状态且不可变的

重要性：高

如果你是第一次尝试容器，请不要将它们视为传统服务器。比如，你可能想要在正在运行的容器内更新应用程序，或者在出现漏洞时给正在运行的容器打补丁。从根本上说，容器不是以这种方式工作的。它们被设计成了无状态且不可改变。

无状态

无状态意味着任何状态（任何类型的持久数据）都存储在容器之外。这个外部存储可以采取多种形式，具体取决于你的需求：

要存储文件，我们建议使用 Cloud Storage 等对象存储。
要存储用户会话等信息，我们建议使用外部的低延迟键值存储，例如 Redis 或 Memcached。
如果需要块级存储（例如数据库），则可以使用连接到容器的外部磁盘。对于 Kubernetes Engine，我们建议使用持久化磁盘。

通过以上方法将数据从容器本身中移出，这意味着可以随时干净地关闭和销毁容器，而不必担心数据丢失。如果创建了一个新容器来替换旧容器，则只需将新容器连接到同一数据存储区或将其绑定到同一磁盘即可。

不变性

不可变意味着容器在其生命周期内不会被修改：没有更新，没有补丁，没有配置更改。如果必须更新应用程序代码或打补丁，则需要构建新镜像并重新部署。不变性使部署更安全，更可重复。如果需要回滚，只需重新部署旧镜像即可。此方法允许你在每个环境中部署相同的容器镜像，使它们尽可能一致。

为了在不同环境中使用相同的容器镜像，我们建议你外部化容器配置（侦听端口，运行时选项等）。容器通常配置有环境变量或挂载到特定路径上的配置文件。在 Kubernetes 中，你可以使用 Secrets 和 ConfigMaps 作为环境变量或文件将配置注入到容器中。

如果需要更新配置，请使用更新的配置部署新容器（基于相同的镜像）。

图 3. 如何使用挂载到 pod 配置文件中的 ConfigMaps 更新部署中的配置

无状态和不变性的结合是基于容器的基础设施的卖点之一。这种组合允许你自动化部署并提高其频率和可靠性。

避免使用特权容器

重要性：高

在虚拟机或裸机服务器中，你会避免使用 root 用户运行应用程序，原因很简单：如果应用程序受到攻击，攻击者就可以完全访问服务器。出于同样的原因，请避免使用特权容器。特权容器是一个容器，可以访问主机的所有设备，绕过容器的几乎所有安全功能。

如果你认为需要使用特权容器，请考虑以下备选方案：

通过 Kubernetes 的 securityContext 选项或 Docker 的 --cap-add 标志为容器提供特定功能。该 Docker 文档（https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities）同时列出了默认启用和必须明确启用的功能。
如果你的应用程序必须修改主机设置才能运行，请在边车容器或初始化容器中修改这些设置。与你的应用程序不同，这些容器不需要暴露于内部或外部流量，更加独立。
如果需要在 Kubernetes 中修改 sysctls，请使用专用注解。

在 Kubernetes 中，特权容器可以被特定的 Pod 安全策略禁止。Pod 安全策略是集群管理员配置和管理的 Kubernetes 对象，它强制执行对 pod 的特定要求。在 Kubernetes 集群中，你无法创建违反这些要求的 pod。

使应用程序易于监控

重要性：高

与日志一样，监控是应用程序管理的一个组成部分。在许多方面，监控容器化应用的原则与非容器化应用的监控相同。但是，由于容器化的基础架构往往是高度动态的，伴随着频繁创建或删除的容器，你无法每次都去重新配置监控系统。

你可以区分两种主要的监控类型：黑盒监控和白盒监控。黑盒监控是指从外部检查应用程序，你就是最终用户。如果你想要最终提供的服务可用且有效，则黑盒监控非常有用。由于它位于基础设施外部，因此黑盒监控在传统基础设施和容器化基础设施之间没有区别。

白盒监控是指使用某种特权访问检查应用程序，并收集最终用户无法查看的度量指标。由于白盒监控必须检查基础架构的最深层，因此传统基础架构和容器化基础架构的差异很大。

Prometheus 是 Kubernetes 社区中用于白盒监控的一个流行选择，可以自动发现必须监控的容器。Prometheus 以期望的特定格式获取容器组的指标。Stackdriver 能够监控 Kubernetes 集群，应用也可以运行自己的的 Prometheus。

以下是一个 Stackdriver Kubernetes Monitoring 的演示实例：

图 4. Stackdriver Kubernetes Monitoring 中的仪表板

要从 Prometheus 或 Stackdriver Kubernetes Monitoring 中受益，应用程序需要按照 Prometheus 的格式公开指标。你可以按照以下两种方法来做。

HTTP 端点度量

HTTP 端点度量的工作方式与下文提到的公开应用程序的运行状况的端点类似。它通常在 /metrics URI 上公开应用程序的内部指标。响应如下：

http_requests_total{method="post",code="200"} 1027
http_requests_total{method="post",code="400"}    3
http_requests_total{method="get",code="200"} 10892
http_requests_total{method="get",code="400"}    97

在这个例子中，http_requests_total 是度量，method 和 code 是标签，最右边的数字是该指标对于这些标签的值。上图中所示，自启动以来，该应用程序已使用 400 错误码响应了 97 次 HTTP 的 GET 请求。

通过已有的多种语言的 Prometheus 客户端库，可以轻松生成此 HTTP 端点。 OpenCensus 还可以使用此格式（以及许多其他功能）导出指标。不要将此端点暴露给公共网络。

Prometheus 官方文档（https://prometheus.io/docs/introduction/overview/）详细介绍了该主题。你还可以阅读站点可靠性工程的第 6 章，以了解有关白盒（和黑盒）监控的更多信息。

监控中使用边车模式

并非所有应用程序都可以使用 /metrics HTTP 端点进行检测。为了保持标准化监控，我们建议使用边车模式以正确的格式导出指标。

日志聚合边车模式部分介绍如何使用边车容器来管理应用程序日志。你可以使用相同的模式进行监控：边车容器托管监控代理程序，该代理程序将应用程序公开的度量标准转换为全局监控系统可以理解的格式和协议。

考虑一个具体示例：Java 应用程序和 Java Management Extensions（JMX）。许多 Java 应用程序使用 JMX 公开指标。利用 jmx_exporter，你可以不必重写应用程序就公开 Prometheus 格式的指标。jmx_exporter 通过 JMX 从应用程序收集指标，并通过 Prometheus 可以读取的 /metrics 端点公开它们。这种方法还具有限制 JMX 端点暴露的优点，因为它可以用来修改应用程序设置。

图 5. 用于监控的边车模式

暴露应用程序的健康状况

重要性：中等

为了便于在生产中进行管理，应用程序必须将其状态传达给整个系统：应用程序是否正在运行？它健康吗？它准备好接收流量吗？它是如何表现的？

Kubernetes 有两种类型的健康检查：活性探针（liveness probes ）和就绪探针（readiness probes）。如下文所述，每个都有特定的用途。你可以通过多种方式实现这两种方式（包括在容器内运行命令或检查 TCP 端口），但首选方法是使用此最佳实践中描述的 HTTP 端点。

注意：本节中给出的路径只是一种约定。HTTP 端点的实际路径可能因应用程序而异。

活性探针

实现活性探针的推荐方法是让应用程序公开 /health HTTP 端点。在此端点上收到请求后，如果认为健康，应用程序应发送“200 OK”响应。在 Kubernetes 中，健康意味着容器不需要被杀死或重新启动。影响健康的因素因应用程序而异，但通常意味着以下内容：

应用程序正在运行。
它的主要依赖性得到满足（例如，它可以访问其数据库）。

就绪探针

实现就绪探针的推荐方法是让应用程序公开 /ready HTTP 端点。在此端点上收到请求后，如果应用程序已准备好接收流量，则应发送“200 OK”响应。准备接收流量意味着以下内容：

该应用程序是健康的。
完成任何潜在的初始化步骤。
发送到应用程序的任何有效请求都不会导致错误。

Kubernetes 使用就绪探针来编排应用程序的部署。如果更新部署，Kubernetes 将对属于该部署的 pod 进行滚动更新。默认更新策略是一次更新一个 pod：Kubernetes 在更新下一个 pod 之前等待新 pod 准备就绪（如就绪探针所示）。

注意：在许多应用程序中，/health 和 /ready 端点合并为一个 /health 端点，因为它们的健康状态和就绪状态之间没有真正的区别。

避免以 root 身份运行

重要性：中等

容器提供隔离：使用默认设置，Docker 容器内的进程无法访问来自主机或其他并置容器的信息。但是，由于容器共享主机的内核，因此隔离不像虚拟机那样完整。攻击者可以找到未知的漏洞（在 Docker 或 Linux 内核本身中），这些漏洞将允许攻击者从容器中逃脱。如果攻击者确实发现了漏洞并且你的进程在容器内以 root 身份运行，则他们将获得对主机的 root 访问权限。

图 6. 左侧，虚拟机使用虚拟化硬件。右侧，容器中的应用程序使用主机内核。

为避免这种可能性，最佳做法是不在容器内以 root 身份运行进程。你可以使用 PodSecurityPolicy 在 Kubernetes 中强制执行此行为。在 Kubernetes 中创建 pod 时，使用 runAsUser 选项指定正在运行该进程的 Linux 用户。这种方法会覆盖 Dockerfile 中的 USER 指令。

实际上，存在挑战。许多软件包都以 root 身份运行其主进程。如果要避免以 root 用户身份运行，设计你的容器使用未知的非特权用户运行。这种做法通常意味着你必须调整各种文件夹的权限。在容器中，如果按照一个容器一个应用的最佳实践，并且一个应用一个用户（最好不是 root 用户），则授予所有用户对文件夹和文件的读写权限不是问题。

检查容器是否符合此最佳实践的一种简单方法是在本地使用随机用户运行容器并测试是否正常工作。替换 [YOUR_CONTAINER] 为你的容器名称。

docker run --user $（（RANDOM + 1））[YOUR_CONTAINER]

如果容器需要外部卷，则可以配置 fsGroup Kubernetes 选项以将此卷的所有权授予给特定的 Linux 组。此配置解决了外部文件所有权的问题。

如果你的进程由非特权用户运行，则它将无法绑定到 1024 以下的端口。这不是什么大问题，因为你可以配置 Kubernetes 服务将流量从一个端口路由到另一个端口。例如，你可以配置 HTTP 服务器绑定到 8080 端口，并通过 Kubernetes 服务从 80 端口将流量重定向回来。

仔细选择镜像版本

重要性：中等

当你使用 Docker 镜像时，无论是作为 Dockerfile 中的基础镜像，还是作为 Kubernetes 中部署的镜像，你都必须选择正在使用的镜像的标签。

大多数公共和私有镜像都遵循构建容器最佳实践（https://cloud.google.com/solutions/best-practices-for-building-containers#properly_tag_your_images）中所述的标签系统。如果镜像使用语义版本控制的系统，则必须考虑一些标签细节。

最重要的是，“latest”标签可以在镜像之间频繁移动。结果是你无法依赖此标签进行可预测或可重现的构建。例如，采用以下 Dockerfile：

FROM debian:latest

RUN apt-get -y update && \
    apt-get -y install nginx

如果你在不同的时间使用这个 Dockerfile 构建两次镜像，你最终会得到两个不同版本的 Debian 和 NGINX。相反，考虑这个修订版：

FROM debian:9.4

RUN apt-get -y update && \
    apt-get -y install nginx

通过使用更精确的标签，你可以确保生成的镜像始终基于 Debian 的特定子版本。因为特定的 Debian 版本还附带了特定的 NGINX 版本，所以你可以更好地控制正在构建的镜像。

这个结果不仅适用于构建时，也适用于运行时。如果你在 Kubernetes 清单中引用“latest”标签，则无法保证 Kubernetes 将使用的版本。集群的不同节点可能会在不同时刻拉取相同的“latest”标签。如果标签已经在拉动之间的某个点更新，则最终可能会在不同的节点运行不同的镜像（这是因为同时打上了“latest”标签）。

理想情况下，你应始终在 FROM 行中使用不可变标签。此标签允许你重现构建。但是，存在一些安全性权衡：你固定使用的版本越多，安全补丁在镜像中的自动化程度就越低。如果你使用的镜像使用正确的语义版本控制，则补丁版本（即“X.Y.Z”中的“Z”）不应具有向后不兼容的更改：你可以使用“X.Y”标签并自动修复错误。

注意：标签在 Docker 中不是真正不变的。只要镜像的所有者决定更改标签。但是，“X.Y.Z”标签实际上几乎总是不变的。

设想一个名为“SuperSoft”的软件。假设 SuperSoft 的安全过程是通过新的补丁版本来修复漏洞。你想自定义 SuperSoft，并编写了以下 Dockerfile：

FROM supersoft:1.2.3

RUN a-command

一段时间后，供应商发现了一个漏洞，并发布了 SuperSoft 的 1.2.4 版本来解决这个问题。在这种情况下，你可以随时了解 SuperSoft 的补丁并相应地更新 Dockerfile。如果你在 Dockerfile 中使用 FROM supersoft:1.2 进行替换，则会自动拉取新版本。

最后，你必须仔细检查正在使用的每个外部镜像的标签系统，判定你对构建这些镜像的人员的信任程度，并确定要使用的标签。

来自：https://mp.weixin.qq.com/s/FEqVWBQ1LkQAf6sdX7MPng

谷歌财报里最值得关注的是被标注为「其他业务」的云计算和硬件收入

Tue, 24 Apr 2018 11:12:11 CST

虽然北美科技公司目前正处于被「数据」统治的不安情绪中，可能会影响科技公司在数字营销方面的收入，但 Google 母公司 Alphabet 在 2018 年第一季度的利润和收入仍然超过了分析师预期，不过这一程度上得益于云计算和硬件设备等「其他业务」带来的优势。

Alphabet 在财报中透露，该公司在 2018 年第一季度的营收达到 311.46 亿美元（如果不包括通过向合作伙伴支付广告收入分成的方式获取流量的成本的话，该数字应该是 248 亿美元），同比增长 26%；净利润 94.01 亿美元，同比增 73%。不过在该份财报发布后，Alphabet 的股价在盘后还是跌了 0.15%，因为 Alphabet 净利润大幅度增加是因为来自对 Uber 等科技公司所获得的收益，大约有 30.31 亿美元，如果扣除这部分收益，Alphabet 的利润同比增加只有 22%，而增速比去年同期还要下降 5%。

财报中还有更让人感到不安的是 Google 在获取流量方面的成本高达 62.88 亿美元，去年同期为 46.29 亿美元，在广告营收中所占比例为 24%，相比之下去年同期为 22%。Google 的首席财务官 Ruth Porat 在财报电话会议上解释道这是因为在移动端流量获取成本会更高一些。

另外 Google 的资本支出也增加了两倍多，达到了 77 亿美元，这其中包括了购买了纽约切尔西市场大楼的费用，以及在数据中心建设上的持续投资。Pivotal Research Group 分析师 Brian Wieser 在一份报告中认为 Google 在今年的资本支出可能要比 2017 年高很多。

Alphabet 的主要收入来源仍然是广告，为 266.42 亿美元，高于去年同期的 214.11 亿美元，不过由于剑桥分析公司 (Cambridge Analytica) 和 Facebook 的用户信息泄露丑闻时间还没有影响到这一季度的财报，Cowen & Co 的分析师John Blackledge 在最近给客户的报告中表示最近的负面新闻不会在结构上改变在线广告模式。

不够更令人关心的是 Alphabet 旗下另外两个部门的表现，也就是最不起眼的「Google 其他营收」和「其他赌注」(“Google other revenues” and “other bets”)。在「其他营收」中的业务包括最近被划分给 Google 的 Nest 智能家居业务以及云计算、Pixel 手机业务、智能音箱、Google Play 以及 YouTube 订阅定。这一部分营收为 43.54 亿美元，高于去年同期的 32.07 亿美元。

自动驾驶汽车单元 Waymo、互联网服务 Google Fiber 和生命科学部门 Verily 已经被移出了「其他赌博」的项目，该部分业务营收为 1.50 亿美元，高于去年同期的 1.32 亿美元，但运营亏损也高达 5.71 亿美元。

Google 的云究竟怎么样了

在 Google「其他收入」中，云计算收入到底能占多少呢，在上个季度 Google 宣布其云业务收入达到了 10 亿美元，Google CEO Pichai 在财报电话会议上表示在云计算在第一季度「看到了增长的势头 (we saw increasing momentum)」。

Pichai 表示由于云机器学习服务的进一步普及以及 G Suite 生产力软件作为一种服务，该部门正在签署越来越多的协议。尤其是对 G Suite 来说「增长正处于一个转折点」，并正在帮助更多客户进入谷歌云平台。而 Google 云计算相对于其它竞争对手来说优势在于数据分析和机器学习方面的优势，也成为云平台「强劲增长」的重要动力，「安全对于我们来说也是最大的优势」，Pichai 补充道。

不过 Google 云在美国最大的竞争对手亚马逊和微软，以及潜在的中国本土云计算公司阿里云也将很快会发布财报，这三家被成为云计算「3A (AWS, Azure, Alibab Cloud)」的成员在云计算业务上都超过了 Google。尤其是阿里云将会成为 Google 最强劲的对手，目前两家公司正在以超过 100% 的速度迅速抢占全球公共云市场，其增长速度是领头羊亚马逊的近三倍。

Moor Insights & Strategy 的总裁兼首席分析师 Patrick Moorhead 说「我不认为 IaaS 的排名会有显著的变化」。不过，他尤其认为微软可能会有一个「巨大的意外惊喜」。

Pichai 也呼吁 Google 硬件部门有更好的表现。他暗示这是一个长期的发力，需要谷歌来设计新的芯片，以及建立销售和分销系统。但也他表示，Google 需要在一段时间内加大对硬件研发的力度。

Patrick Moorhead 认为 Google 硬件与亚马逊和微软等其他服务公司相比，实际上只是雷达上的一个亮点。该公司有一些非常有才华的员工，它想要获取更多市场份额的话，需要将分销业务扩展到更多的运营商和国家。

Google 的员工人数从去年第四季度增加了4940 人到85050 人，其中包括今年 9 月收购的 HTC 手机业务的 2000人。对于云业务，包括技术和销售的招聘仍在迅速增加。

美国制裁中兴谷歌也成为受害者_科技_腾讯网

Tue, 24 Apr 2018 17:57:25 CST

腾讯科技讯近日，美国政府以中兴通讯未遵守和解协议内容为由，宣布了对中兴的出口禁令。在科技产业全球化的今天，美国制裁中兴，自然也会导致一大批美国公司受到影响。据外媒最新消息，谷歌将成为这次制裁另外的一个“受害者”。

中兴是中国的电信设备制造商和手机厂商，谷歌是全球最大的网页搜索服务商以及手机操作系统开发商。双方貌似交集无多，但是实际上已经建立紧密合作关系。

据美国媒体报道，今年二月份，在巴塞罗那世界移动通信大会上，谷歌高管对外发布了搭载轻量版安卓的一款低价手机。不过在两个月之后，这款手机的前景却陷入了迷雾当中。

上述这款手机的制造商正是中兴通讯，而根据美国政府的制裁令，该手机将无法使用谷歌公司授权的安卓系统（不包括安卓开源代码）。

外媒指出，谷歌正在通过智能手机扩张移动互联网业务，推广移动软件，但是美国对中兴的制裁，将影响到谷歌这一计划。

在移动互联网时代，谷歌和苹果、三星等出现了竞争关系，而包括中兴在内的智能手机行业伙伴对于谷歌来说越来越重要。

在全球智能手机中，八成安装了谷歌开发的安卓系统，不过谷歌并未从开源代码中获得任何收益，谷歌主要通过Play软件商店的授权费、销售分成，以及移动广告中获益，当然，谷歌也将获得海量用户数据。

谷歌需要千方百计从苹果iOS阵营中争抢用户，另外三星电子过去曾经是谷歌的盟友，但是如今也在推广旗下的通信或者办公类软件，谷歌也面临来自三星的竞争。

值得一提的是，在中国市场，根据市场研究公司Canalys的统计，安卓覆盖了86%的智能手机，但是谷歌却几乎没有得到任何利益。在中国发售的智能手机往往安装了来自腾讯、百度等网络巨头的软件和服务。

另外对于谷歌来说，全球的低价安卓手机市场十分关键。比如在美国，四分之一的消费者购买的是不到100美元的低价手机。

美国投资银行摩根士丹利公司预测，去年，谷歌通过移动广告和软件商店分成，一共获得了338亿美元的总收入，占到公司收入的三成。

为了推动低价安卓手机，谷歌推出了轻量版操作系统“安卓GO”，而中兴成为第一家在美国推出搭载这一系统手机的厂商。中兴之前发布了定价80美元的Tempo Go手机，预装了谷歌大量轻量版应用软件。

在美国之外的市场，中国手机厂商TCL、传音，以及芬兰HMD、印度Lava等公司推出了安卓GO手机。据悉，这一系统和官方软件所占用的空间比过去减少了一半，有助于进一步降低低价手机的成本。

近期，中国另外一家电信设备制造商和手机厂商华为，同样受到了美国政府的打压，而华为也准备在非洲地区推出搭载轻量版安卓的手机。

对于谷歌而言，中兴有潜力成为其移动软件和服务的重要推广者。根据市场研究公司统计，去年，中兴在美国智能手机的份额翻了一倍，达到了11.2%。为了实现这一目标，中兴和美国电信运营商建立了伙伴关系，在美国开设了五个研发中心，此外在华盛顿市展开了政策游说工作。

面对来自美国政府的制裁令，中兴未来是否还会继续在美国销售Tempo Go手机，目前还不得而知。

据统计，美国是中兴公司最大的智能手机市场，占到去年手机总销量的一半左右。在中国以外的地区，中兴在手机中搭载了基于安卓开发的MiFavor界面，预装了一些谷歌软件。

分析人士指出，因为开源软件并不包括在制裁范围内，因此中兴未来仍然能够使用某些版本的安卓，但是他们将无法预装谷歌官方应用软件。

分析人士称，美国的制裁令可能无法让中兴现有用户升级安卓系统，从而给用户隐私带来风险。

外媒分析指出，中美此次贸易战也将给谷歌造成不利影响，Canalys公司的一位分析师表示，未来谷歌重返中国市场将变得更难。（综合/晨曦）

谷歌高管：安卓现在和iOS一样安全甚至更好

Sat, 17 Mar 2018 00:00:00 CST

Android安全主管：“虽然存在两个问题，但安卓安全性已经不会比iOS差，只会更好！”

iOS 和 Android 谁更安全？相信即使是 Android 用户都会把自己的选票投给前者，但现在的 Android 安全主管并不这么想，他声称现在谷歌的操作系统安全性已经不会比 iOS 差了，只会更好！

在2017年 Android 安全评估中，谷歌宣布自己在安全性方面已经领先竞争对手，因为在2017年中，Android 系统引入了很多安全保障措施，很多措施甚至引领了行业的发展。

Android 安全主管 David Kleidermacher 明确地告诉 CNBC，现在的 Android 安全性已经能够媲美 iOS 了。不过他言语中还是非常克制的：“不指名道姓地说，现在 Android 系统已经和竞争对手一样安全了，甚至更好。”

不过在 CNBC 的采访中，Kleidermacher 还是承认了 Android 存在的一个问题：当有人发现 Android 的系统漏洞时，谷歌必须把软件更新发送给众多 Android 手机厂商，比如三星和华为，然后敦促他们尽快提供安全更新，但即使如此，这一过程往往需要很长时间，或者有些厂商压根就不会听谷歌的话，安全更新？不存在的！

更重要的是，Android 的开放特性给了用户100%的自由选择权，他们能够从 Google Play 之外的地方下载 App，所以 Android 用户往往会无意下载很多恶意软件。

但是 Kleidermacher 表示，Android 平台的“ Google Play Protect ”能够有效解决这一问题，它不仅能够对 Google Play 的应用进行审查，并且还会对其他平台下载的 App 进行检测，如果发现有害 App，会自动删除它们。所以即使 Android 存在前面那些缺陷，也是可以轻易堵上的。只可惜，这项功能对于我们来说完全起不了作用。

甚至谷歌的报告表明，Android 的开源方法可能比 Apple 的闭源代码更安全。因为作为全球性开源项目，Android 拥有一个开发者社区，大家会协助发现深层漏洞并很快进行处理，和闭源项目相比，这显然更加高效。

欢迎关注威锋网官方微信：威锋网（weiphone_2007) 汇聚最新Apple动态，精选最热科技资讯。

谷歌已完成对HTC手机部门的收购 Pixel 3要起飞

Tue, 30 Jan 2018 19:04:49 CST

还记得去年 Google 收购 HTC 手机研发部门的新闻吗？小半年过去了，今天 Google 终于宣布这一收购案已经完全完成，不过还是要再强调一下，谷歌花费11亿美元收购的，并不是 HTC 的手机品牌，而是一个多达2000人的智能手机研发团队。

这一消息由谷歌硬件副总裁 Rick Osterloh 在其博客中宣布，他表示在 HTC 手机团队的帮助下，“未来几年将致力于为大家带来更优秀、更具创新的产品”。而在吸纳2000多名工程师之后，HTC 在台北的这一部门也成为了谷歌在亚太地区最大的工程中心。

并且大家需要注意，HTC 仍然会继续推出自己品牌的手机，因为据传言，谷歌收购的团队其实之前本来就是负责 Pixel 手机研发的，而 HTC 自己还有其他研发团队。并且 HTC 旗下所有的制造厂、研发中心都得到了保留。正因如此，当时在交易爆出的时候大家都认为这11亿美元是谷歌给 HTC 的“续命钱”。

而在收购完成之后，谷歌的下一代 Pixel 手机也马上浮出了水面，据悉，谷歌硬件部门职员透露，下一代 Pixel 手机将会站在 iPhone 的高度来进行研发，也就是说要拥有自主研发的 SoC。

可别觉得谷歌在吹牛，其实 Pixel 2 就搭载了一款名为 Visual Core 的芯片，为8核心 IPU 设计，能够和 Cortex A53（CPU）、LPDDR4（内存）和 PCIe （闪存）等模块进行数据交换，主要负责一些拍照处理。并且在现在大热的人工智能领域，谷歌也早有 TPU 这样的成功案例。

所以如果谷歌真的推出了自主研发 SoC，不仅下代 Pixel 手机将受益，其他安卓厂商可能也会分一杯羹，因为谷歌一直都是这样一家喜欢“施舍”的公司。

最后，Pixel 3手机计划在2018年秋季推出，不出意外将会预装 Android 9.0 系统。对于 Pixel 系列 Osterloh 是这么说的：“我们不希望让它成为一个小众产品，在五年内，Pixel 系列将会获得巨大的销售额。”

阅读全文

谷歌又有小动作，这边和腾讯合作，那边和华为合作

Sat, 20 Jan 2018 08:20:54 CST

前两天，刚有消息称谷歌将在深圳成立办事处，近日腾讯和谷歌就共同宣布双方达成一项专利交叉许可协议。谷歌方面透露：“我们很高兴能与腾讯达成专利交叉授权许可协议，”谷歌专利负责人Mike Lee表示，“通过这样的协议，科技公司将得以专注于为用户打造更好的产品和服务。”

腾讯方面也做出类似表示，表示这样的合作可以更好的服务于社会和用户。目前尚不清楚签署许可协议涉及的专利与哪些方面有关。

谷歌不但和腾讯有合作，和国内的手机巨头华为也有合作。

日前，谷歌与华为宣布开展一项新的合作，将基于RCS（Rich Communication Services，即融合通信，是指把手机中原有的“通话”、“消息”、“联系人”这3个主要入口，从运营商的层面直接与手机整合，变为新通话、新消息、新联系。）的Android messages应用到华为手机中去。

一年前，谷歌就更新了其“Messenger”（即短信）应用到“Android messages”，这一更新并不是简单的将一款即时通讯应用添加在短信应用中，而是为了进一步地开发RCS奠定基础。

通过Android messages 和RCS消息，华为设备将提供更丰富的本地消息和通信体验。比如说通过WiFi网络发送短信、发送更加丰富的内容、小组聊天和打字指示符等。

谷歌表示，华为将在未来几个月开始整合Android messages，真正应用还需要一段时间。而目前最大的安卓厂商三星则计划开发自己的RCS应用。可以看出，现在单纯的信息已经不能够满足人的需求了，未来的短信功能应该都会逐步整合成RCS消息。

此外，在升级之后华为手机用户还能够使用运营商ViLTE（Video over LTE，类似于VoLTE（Voice over LTE，高清语音通话），是高清视频通话。）和Google Duo直接通过Android消息进行通话。

重磅！谷歌地图已可以正常使用，谷歌将重返中国！

Tue, 09 Jan 2018 18:56:35 CST

作者丨长岭公

来源丨米宅海外（mizhaihaiwai）

喜大普奔！

是的，我要告诉你一个重大消息！重要消息！

谷歌地图可以使用了！可以访问了！终于可以不被百度地图、高德地图绑架了！

网址1：http://ditu.google.cn

网址2：http://www.google.cn/maps/

普通地图模式▼▼▼

卫星地图模式▼▼▼

可惜，搜索还是不能用▼▼▼

点击后，还是转向至www.google.com.hk，但无法正常打开使用搜索。

有人会说，百度地图和高德地图都挺好的啊，是啊，在国内还行，但如果想看海外，百度地图可就远远不行了，比如你要去墨尔本旅游，你想看看租的房子或住的酒店周边有什么吃的，你想看看贾跃亭在洛杉矶的房子啥样子，对不起，你只能靠谷歌地图了。

▼▼▼比如，你想知道你在澳洲黄金海岸订的酒店离冲浪者沙滩有多远？附近哪里有中餐？

▼▼▼比如，某富家公子5年前花了2.5亿在悉尼point piper买的别墅啥样子？在哪里？

那些已经习惯使用谷歌地图的朋友们，你们的痛我懂得，如今，可以心安了。

谷歌回归战略已定！

1 上月在北京成立AI研究中心

谷歌于2017年12月13日宣布将在北京打造一个新的人工智能研究中心，利用北京本土人才资源服务于广为看好的这一技术。

人工智能是谷歌、微软和脸书等的重点研究对象，同时也是这些企业的中国竞争对手例如阿里巴巴、腾讯和百度等的焦点。因涉及汽车自动驾驶、翻译软件和人脸识别系统等，人工智能被广泛认为是未来科技的发展方向。法新社称，虽在中国大陆被禁，但谷歌本次宣布在北京设立人工智能研究中心，是一个强烈信号。

谷歌称：“团队已经聘用了数名中国专家，几个月内将会完成组队。而2015年人工智能科研杂志世界百强当中，43%的内容都是中国作者的心血。中国的优秀人才正在年轻化，人工智能方面的学习和教学已渗入了高中甚至初中。”

谷歌称，该中心将主要聘用中国本土人才。北京从此跻身纽约、多伦多、伦敦和苏黎士，成为硅谷之外谷歌的又一研究中心所在地。

2 昨日领投直播公司：触手

手游直播平台触手2018年1月5日宣布完成D轮融资，由Google领投，现有投资方启明创投、顺为资本以及AlphaXCapital跟投。融资完成后，触手总融资额达到1.2亿美元。

这是Google第二次投资中国创业公司。双方称，Google将帮助触手扩大服务，拓展更多海外观众。

触手成立于2015年，是一家在线电竞直播平台。在一份声明中触手称，公司拥有约800万主播，日活跃主播为25万。平台拥有1000多种游戏，吸引了9000万注册用户。

Google北亚地区企业发展负责人FrankLin表示：“触手打造了一个出色平台，拥有一个专注、快速扩大的内容制作者和消费者群体，并且制定了巧妙的扩张计划。”

“我们很荣幸Google能成为我们的投资者，”触手的创始人曹建根表示，“Google的投资是对我们团队所进行的创新工作的证明，为我们在全球拓展所付诸的努力给予信心与支持。我们期待未来能通过更多形式与Google展开合作。”

分析认为，这是Google意在通过触手直播布局移动电竞和游戏直播，同时寻找进入中国市场的新途径。此前，谷歌参与投资了北京人工智能公司出门问问。

米宅说！

自2010年一别，已有8年！

你的离开，成就了百度，成就了高德，成就了UC神马，成就了360。

你的离开，成就了百度联盟，阿里妈妈，莆田医院，狗皮膏药。

那时候，中国的互联网还是PC时代，还是门户和搜索的时代，新浪搜弧网易互相竞争的同时并不知未来的对手是今日头条。

那时候，微博当红，没有对手，还没有微信、直播、滴滴、摩拜。

那时候，淘宝当红，还没有天猫，刘强东还在追赶，京东还在生死线上，一号店还看不上京东，凡客正红，韩寒代言，筹划上市，并不知危机将至。

8年了，我们已经习惯了使用百度，我们已经习惯了不再使用Gmail。

8年里，我们经历了直播、O2O、APP的风口和陷落，我们经历了微博的没落和价值回归。

时间到了2018年，一切都变了。

互联网已经不再是PC的时代，流量已经不再是门户的天下。

流量已经是智能手机端的天下，微信一家独大，独占一半以上的流量入口。

谷歌即使浑身解数，依然无法攻克微信的城池。

未来是万物互联+人工智能的时代，谷歌重返中国的切入点正是人工智能、正是AI，这恰恰也是中国的薄弱环节，目前中国没有一家人工智能公司可以比肩硅谷。

回来了就好，我们想死你了！

转发告诉你的朋友吧，谷歌回来了，谷歌地图可以使用了！

IT瘾谷歌推荐

谷歌、Anthropic双重围剿下的OpenAI，正面临「生死抉择」

谷歌CEO警告：AI泡沫破裂时，无一家公司能够幸免

刚刚，谷歌放出Nano Banana六大正宗Prompt玩法，手残党速来

超谷歌搜索：阿里开源创新大模型搜索引擎 ZeroSearch，成本直降 80% 且能力更强

真·开放式游戏，谷歌造出首个无限人生模拟游戏Unbounded

翻车的不只谷歌？微软必应聊天演示被指存在事实性错误

谷歌向 TikTok 发起挑战，YouTube 短视频作者可获得 45% 的广告收入分成

谷歌对Web3的未来持乐观态度

来自谷歌的开发心得：所有SQL和代码，都没必要藏着掖着

谷歌公告：SHA-1 哈希算法被攻破

什么是哈希碰撞

哪些系统会受影响？

非技术人员应该怎么保护自己

谷歌OKR指导手册 (译)

正确的OKR制定方法规则

OKR写作常见错误与陷阱

新官上任后：谷歌史上首次公布YouTube和云计算单独收入

谷歌开源Live Transcribe语音识别转文字工具

为什么谷歌的开发人员认为敏捷开发是无稽之谈？

作者介绍：

这一次谷歌很强硬，App 再不支持，两个月后将拒绝上架

一. 序

二. Android CPU 架构细节

2.1 这是强制规范

2.2 那些 APK 需要支持 64 位？

2.3 为什么是强制的？

三、支持 64 位架构

3.1 是否包含 64 位库？

3.2 判断是否支持 64 位架构

3.3 在 64 位设备上测试应用

3.4 分包处理

四. 小结时刻

2019高考编程卷：谷歌面试编程题及解题技巧（MIT版）

谷歌助力，快速实现 Java 应用容器化

一、什么是 Jib

二、实战出真知

1. 构建一个简单的 Java 工程

2. 构建一个 SpringBoot 的可运行 Jar

3. 构建一个 WAR 工程

谷歌拼音输入法离线包下载

下载谷歌拼音输入法离线包

谷歌浏览器Chrome离线包下载

下载谷歌浏览器Chrome离线包

AI项目被谷歌撂挑子 美国防部愤而狂挖硅谷AI人才

「不作恶」谷歌的人工智能之路

谷歌最强 NLP 模型 BERT 解读

NLP历史突破！谷歌BERT模型狂破11项纪录，全面超越人类！

[译] 谷歌团队的容器运维最佳实践

谷歌财报里最值得关注的是被标注为「其他业务」的云计算和硬件收入

Google 的云究竟怎么样了

美国制裁中兴 谷歌也成为受害者_科技_腾讯网

谷歌高管：安卓现在和iOS一样安全 甚至更好

欢迎关注威锋网官方微信：威锋网（weiphone_2007) 汇聚最新Apple动态，精选最热科技资讯。

谷歌已完成对HTC手机部门的收购 Pixel 3要起飞

谷歌又有小动作，这边和腾讯合作，那边和华为合作

重磅！谷歌地图已可以正常使用，谷歌将重返中国！

AI项目被谷歌撂挑子美国防部愤而狂挖硅谷AI人才

美国制裁中兴谷歌也成为受害者_科技_腾讯网

谷歌高管：安卓现在和iOS一样安全甚至更好