Tony Bai » 思考

AI 是让你忘掉如何编程的最快方式

bigwhite — Thu, 01 Jan 2026 00:26:30 +0000

本文永久链接 – https://tonybai.com/2026/01/01/ai-is-the-fastest-way-to-forget-how-to-code

大家好，我是Tony Bai。

在 Copilot、Cursor、Claude Code等普及的这两年，编程似乎变得前所未有的轻松。

Tab 键一按，十行代码倾泻而出；回车一敲，整个函数自动补全；一个Prompt发出，一个项目的框架代码便完成了。那种多巴胺分泌的快感是真实的，效率提升的数据也是真实的。我们仿佛一夜之间都变成了“十倍工程师”。

但在这种虚幻的快感背后，一种隐秘的焦虑正在资深开发者群体中蔓延：离开 AI 提示词，你还能流畅地写出一个复杂的递归，或者手撸一个带有完整错误处理的 HTTP Client 吗？

最近，我在技术社区看到一段发人深省的论述，它像一盆冷水，浇在了在这个狂热的 AI 时代：

“AI is the fastest way to forget how to code and how to think.”
（AI 是让你忘掉如何编程、忘掉如何思考的最快方式。）

这句话听起来很刺耳，但很真实。

如果我们习惯了让 AI 替我们思考，我们的大脑正在经历一场无声的“认知肌肉萎缩”。在 AI 时代，写下每一行代码依然重要。这不是一种复古的情怀，而是关乎我们职业生存的“认知保留”。

警惕“GPS 效应”：你是在驾驶，还是在被运送？

心理学中有一个著名的“GPS 效应”：习惯了使用导航的人，海马体（负责空间记忆的脑区）活跃度会降低，久而久之，他们会逐渐丧失方向感，甚至在自家小区门口也会迷路。

编程也是一样。

学习和成长的本质，发生在“挣扎”的过程中。

当你为了设计一个类结构而绞尽脑汁，当你为了修复一个“竞态条件”而彻夜排查，你的大脑正在构建复杂的神经连接，正在建立对系统的“心智模型”。

如果你跳过了这个“挣扎”的过程，直接向 AI 索要答案：

AI 变成了“代笔者（Author）”：它替你构建了心智模型。
你变成了“消费者（Consumer）”：你只负责 Copy & Paste。

结果是：代码虽然跑通了，但你对系统组件之间的连接、潜在的边缘情况（Edge Cases）一无所知。你不再是代码的“作者”，你只是代码的“搬运工”。

一旦 AI 遇到它没见过的深水区，或者系统出现了一个隐蔽的 Bug，你会发现自己束手无策——因为你从未真正拥有过这段代码。

重构契约：把 AI 当做“磨刀石”，而非“枪手”

那么，我们要因噎废食，扔掉 AI 吗？当然不。

关键在于重构你与 AI 的协作契约。

核心原则只有一条：

Use AI as a Reviewer, a Rubber Duck, a Teacher. Not as an Author.
（把它当作审查者、橡胶鸭、导师。绝不要把它当作代笔者。）

如果 AI 在替你思考，你在退步；如果 AI 在逼迫你思考得更深，你在进步。

以下是基于这个原则的 4 个深度思考工作流：

1. 解释意图，而非索要实现

不要直接丢一句“帮我写个鉴权中间件”。

试着这样做： 你自己写出核心逻辑，然后对 AI 说：

“这是我写的鉴权逻辑。请解释我为什么在这里使用了 Context 传递用户信息？这种写法符合 Go 语言的惯用范式吗？有没有更好的风格？”

收益： 强迫自己理清思路，利用 AI 验证你的设计直觉。

2. 索要权衡(trade off)，而非标准答案

不要问“在这个场景下我该用 Redis 还是 Memcached？”

试着这样做：

“我倾向于使用 Redis，因为我们需要持久化。但在这个高并发场景下，使用 Redis 会带来哪些潜在的性能瓶颈或运维风险？请列出 Trade-offs。”

收益： AI 不再是给你喂饭，而是在陪你进行架构评审（Architecture Review）。

3. 寻找盲区，挑战假设

当你写完一段代码，觉得完美无缺时，把它扔给 AI：

“这段代码在什么极端输入下会崩溃（Edge Cases）？我是否遗漏了某些并发安全问题？请像一个最挑剔的 Tech Lead 一样 Review 它。”

收益： 利用 AI 广博的知识库，填补你的认知盲区。

4. 生成测试，而非生产代码

这是一个最高阶的玩法。你自己写业务代码，让 AI 写测试用例。

“这是我实现的订单状态机。请为它编写一套覆盖率 100% 的单元测试，特别是针对状态回滚的异常场景。”

收益： 如果 AI 生成的测试跑通了，说明你的逻辑是自洽的；如果跑不通，或者 AI 根本理解不了你的代码，说明你没想清楚。

小结：不要温和地走进那个良夜

在 AI 时代，能够熟练调用 API 生成代码的人多如牛毛。

但能够独立构建复杂系统心智模型，并能驾驭 AI 进行深度架构推演的人，将变得极度稀缺。

Writing code matters.

写代码的过程，强迫你思考，强迫你大脑建立连接，强迫你理解系统是如何像齿轮一样咬合的。

请继续亲自写下那些核心的、关键的代码。

把 AI 当作你的磨刀石，让你的思维在与它的碰撞中变得更加锋利，而不是让它锈蚀你的大脑。

深度实战：构建“以人为本”的 AI 工作流

道理大家都懂，但在高压的项目交付期，我们很容易滑向“让 AI 全自动生成”的舒适区。

如何建立一套强制性的工作流，既利用 AI 的效率，又保留人类的深度思考？

如何在 Spec 文档中通过“伪代码”保留思考过程？
如何配置 Claude Code，让它默认扮演 Reviewer 而不是 Coder？
如何利用 SDD (Spec-Driven Development) 迫使自己在 Coding 前先进行完整的思维推演？

如果你想掌握这套“不降智、反内卷”的高阶开发心法，欢迎关注我的极客时间专栏《AI原生开发工作流实战》。

在这个专栏里，我不教你如何偷懒，我教你如何进化。我们将一起探索，如何在 AI 的加持下，成为更强大的Software Engineer，而不是更快的Typist。

扫描下方卡片，开启你的认知升级之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

Go 的“简单”幻象：易于上手，难于精通

bigwhite — Fri, 07 Nov 2025 06:28:23 +0000

本文永久链接 – https://tonybai.com/2025/11/07/go-simple-illusion-easy-to-learn-hard-to-master

大家好，我是Tony Bai。

“Go 语言看起来如此简单，我的这种假设是错的吗？”

近日，一位刚接触 Go 几个月的新手在reddit golang论坛发出了这样一个真诚的提问。他感觉 Go “超级简单”，并好奇自己是否因为初学者的身份，而忽略了语言中那些“疯狂的复杂性”。

这个问题，立刻引发了社区关注。数百条评论从四面八方涌来，汇成了一场关于 Go 语言简单性本质的深度辩论。最终，社区的集体智慧凝聚成一个经典而又充满辩证性的共识：Go 的简单，是刻意为之的设计；而通往精通之路，则隐藏在简约表象之下的深邃之处。

本文将带你深入探索这座“简单”的冰山，从其光彩照人的水上部分，一直潜入其复杂深邃的水下世界。

“蜜月期”——为什么 Go 语言感觉如此简单？

对于初学者而言，Go 带来的“简单”感受是真实且强烈的。这并非巧合，而是源于 Go 设计者们一系列深思熟虑的“减法”哲学。

极简的语法与关键字

“25 个关键字，宝贝！” 一位评论者这样感叹道。Go 有意地限制了语言的表面积，仅保留了构建大型系统所必需的核心元素。它只有一个循环结构 for，没有 while、do-while 或 foreach 的变体。这种极简主义，让学习者可以快速掌握语言的全貌，而不必记忆大量特殊语法。

“所见即所得”的代码

一位来自 Java/Python 背景的开发者分享道：“Go 给你的玩具可能更少，但至少你可以相信，它们不会在调试时反咬你一口。” Go 缺乏猴子补丁 (monkey patching)、复杂的继承体系和隐式的魔法，这意味着代码的行为更加可预测。“代码读起来就像它实际运行的样子，即便这意味着多写几行。”

“电池自带”的强大标准库

“标准库太棒了，” 社区普遍赞同，“你需要花些时间才能理解，在不引入单个依赖的情况下，你能做多少事情。” 从 HTTP 服务器到密码学工具，Go 的标准库提供了构建现代网络服务所需 90% 的功能，让初学者可以立即开始构建有价值的应用，而无需在茫茫的第三方库中选择和配置。

幻象的破灭——“简单”背后的隐藏复杂性

当“蜜月期”结束，开发者开始构建更复杂的真实世界系统时，Go 的另一面便会逐渐显现。这份复杂性，并非来自语言本身，而是源于 Go 为了维持简单性，而将复杂性“转移”到的地方。

并发：Go 的“光荣与荆棘”

这是社区中被提及次数最多的“深水区”。Go 通过 goroutine 和 channel，将并发编程的门槛降到了前所未有的低度。然而，这种易用性也隐藏着巨大的风险。

“理解并发作为一个概念可能会很复杂，但 Go 让实现它变得简单。”

但“实现简单”不等于“用对简单”。

Goroutine 泄露：新手很容易创建出无人“负责”的 goroutine，导致其在后台永久运行，悄无声息地消耗内存和 CPU。
竞态条件 (Race Conditions)：尽管 Go 提供了强大的竞态检测器 (-race)，但理解和避免数据竞争，需要对内存模型和同步原语（如 sync.Mutex）有深刻的理解。
Channel 的滥用：“我数不清有多少次，人们到处使用 goroutine 和 channel，然后好奇为什么他们的项目变得如此之慢。” Channel 是强大的工具，但错误地使用无缓冲 channel、忘记关闭 channel、或用它来解决本该用互斥锁解决的问题，都会导致死锁、性能下降和难以调试的 bug。

精通并发，是区分 Go 新手与专家的第一道分水岭。

运维复杂性

Go 的设计哲学，在某些方面将应用程序的韧性责任，从语言运行时“推”给了基础设施。这为 Go 程序带来了一种独特的运维复杂性。

最典型的例子就是 panic 的处理。

在某些语言中（如 Java），一个未捕获的异常通常只会导致单个线程死亡，而整个应用程序进程会默认继续运行。
但在 Go 中，一个未被 recover 的 panic 会导致整个程序（进程）立即崩溃退出。Go 语言本身不提供自动重启或进程守护的能力，它将这种“灾难恢复”的职责，明确地交给了程序的运行环境。

这意味着，构建一个高可用的 Go 服务，你必须依赖外部系统。正如一位资深开发者在讨论中指出的那样：

“像 panic 这样的东西，要求你在一个编排器（如 K8s/ECS 等）下运行你的生产系统。”

这种设计选择，对于新手来说可能是一个认知上的巨大跳跃。他们必须明白，Go 程序的健壮性，并不仅仅是代码层面的 if err != nil，更是在基础设施层面，通过配置进程管理器（如 systemd）或容器编排器（如 Kubernetes）的健康检查和自动重启策略来共同保证的。

Go 将自己定位为一个用于构建云原生应用的“零件”，而非一个大包大揽的“一体机”。这种对运维环境的隐性依赖，正是其简单性背后的一种深刻权衡。

“魔鬼在细节中”：切片、接口与错误处理

Go 的一些核心特性，虽然表面简单，但其底层机制却充满了需要深入理解的“微妙之处”。

切片 (Slices)：新手常常会对其“共享底层数组”的行为感到困惑，不经意间写出因 append 操作导致意外数据修改的 bug。
接口 (Interfaces)：nil 接口与“值为 nil 的接口”之间的区别，是无数 Gopher 都曾踩过的经典“坑”。
错误处理的冗长：if err != nil 虽然明确，但在 LLM 辅助编码时代到来之前，这种冗长曾是许多开发者的抱怨之源。现在，新的挑战变成了如何确保依赖 AI 的新手，能真正理解他们生成的每一行错误处理代码。

精通之路——从“知道”到“理解”

那么，如何跨越从“简单”到“精通”的鸿沟？社区的智慧为我们指明了方向。

接受 Go 的哲学

Go 是一门“刻意设计的简单语言”。它的目标，是让大型团队能够编写出风格统一、易于阅读和维护的代码。这意味着，你需要接受它的“冗长”，理解它为何抵制某些“高级”特性，并学会在其提供的“约束”下优雅地解决问题。

刻意练习核心概念

不要满足于 API 的表面用法。花时间去：

画图理解并发模式：亲自绘制 goroutine 如何通过 channel 通信，理解扇入 (fan-in)、扇出 (fan-out) 等模式。
实验切片的底层行为：编写小程序来观察 append 何时会触发底层数组的重新分配。
深入标准库源码：阅读 net/http 或 context 包的源码，是理解 Go 设计哲学的最佳途径。

拥抱“造轮子”

“你经常需要‘自己动手造轮子’(roll your own)”，一位开发者评论道。这在 Go 的世界里并非贬义。Go 强大的标准库为你提供了高质量的“零件”，鼓励你根据自己的具体需求，组合出最适合的“轮子”，而不是像其他生态那样，总是先去寻找一个庞大、臃肿的“现成汽车”。

小结：“简单”是起点，而非终点

回到最初的问题：Go 语言真的简单吗？

是的，Go 的入口极其简单。 它拥有平缓的学习曲线，让有经验的程序员可以在一周内上手，让新手也能在短时间内构建出有用的程序。

但精通 Go 绝不简单。 它的真正深度，不在于复杂的语法，而在于理解其并发模型背后的权衡、标准库设计的精妙、以及在简约哲学约束下构建复杂系统的工程智慧。

正如一位评论者所引用的那句古老格言：“一分钟学会，一辈子精通。” 虽说“一辈子”有些夸张，但这或许是对 Go 语言简单性与复杂性辩证关系的最佳诠释。Go 的“简单”，为你打开了一扇通往高效、可靠软件工程的大门，但门后的风景，需要你用持续的学习和深刻的思考，去亲自探索和领悟。

资料链接：https://www.reddit.com/r/golang/comments/1oj9jb6/golang_seems_so_simple_am_i_wrong_to_assume_that/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

写作即思考：AI 时代，开发者为什么要警惕“思考外包”？

bigwhite — Fri, 25 Jul 2025 05:16:34 +0000

本文永久链接 – https://tonybai.com/2025/07/25/writing-is-thinking

大家好，我是Tony Bai。

最近，全球顶级的科学期刊《自然》(Nature) 发表了一篇社论，标题仅有三个词：“Writing is thinking” (写作即思考)。

这篇社论探讨的是大语言模型时代人类生成的科学写作的价值，其核心观点，对于我们技术领域的开发者、工程师和内容创作者来说，不啻为一记振聋发聩的警示。它在 AI 浪潮席卷一切的今天，迫使我们重新审视一个被我们日渐忽视，却又至关重要的行为——我们自己的思考过程。

开发者版本的“写作即思考”

对开发者而言，“写作”的形式多种多样：
* 编写一份详尽的技术设计文档 (Design Doc / RFC)。
* 撰写一篇分享经验的技术博客。
* 甚至，是构建一个结构清晰、逻辑严谨的复杂软件模块。

这些行为的本质，都和《自然》社论的观点一致：它不仅仅是“报告结果”，更是一个强迫我们将脑中混乱、非线性的想法，梳理成结构化、有意图的叙事的过程。

当你无法用清晰的语言（或代码）写下来时，通常意味着你对这个问题还没有想清楚。这个“写”的过程，本身就是发现逻辑漏洞、提炼核心思想、明确最终影响力的思考过程。正如社论所引述的科学依据：书写行为本身，就能增强大脑的连接性，并对学习和记忆产生积极影响。

AI 带来的“隐形危机”：思考外包

现在，强大的 LLM 出现了。我们似乎可以轻易地“外包”掉这个艰苦的思考过程。

“帮我生成一份关于XX系统的微服务架构设计文档。”
“为我刚才的 Go 函数编写一份详细的单元测试。”

AI 瞬间就能产出看似完美的“结果”。但在这个过程中，我们失去了什么？

效率的假象： AI 会产生幻觉。你可能需要花费更多的心力去验证、修正和编辑一份由 AI 生成的、你并不完全理解的复杂文档或代码，其成本甚至可能超过从零开始亲自撰写。
思想的归属： 社论提出了一个尖锐的问题——如果“写作即思考”，那么当你在阅读一篇由 LLM 生成的论文时，你读到的究竟是研究者的思想，还是 LLM 的“思想”？同理，当你的同事向你展示一份由 AI 生成的设计文档时，这背后真的有他深入的思考和权衡吗？
核心能力的侵蚀： 这是最危险的一点。我们跳过了最宝贵的思考整理过程，直接获取了“结果”，却失去了将知识和经验内化为自身能力的宝贵“过程”。我们放弃了锻炼自己核心思维能力的机会。

从“外包者”到“放大器”：AI 的正确使用姿势

那么，我们应该抵制 AI 吗？当然不。《自然》的社论也明确指出，AI 是一个极其有价值的辅助工具。问题的关键，不在于用不用，而在于怎么用。

我们应该警惕成为一个“思考外包者”，转而努力成为一个“思考放大器”的使用者。

这意味着，永远由人类掌握“思考”的主导权，而在特定的、非核心思考的环节，利用 AI 来提升效率。以下是一些高效的“放大器”模式：

语法与可读性优化器： “这是我写的一段技术描述，请帮我润色，使其更易于理解，并修正语法错误。”
信息检索与综述助理： “帮我总结一下最近关于 QUIC 协议的三篇关键论文的核心观点。”
头脑风暴伙伴： “我正在设计一个高可用的缓存系统，请帮我列出可能需要考虑的 10 个潜在故障点。”
“破冰”与“思路转换”工具： “我对于如何向非技术人员解释‘幂等性’感到卡壳，请提供三种不同的比喻或解释方式。”

在这些场景中，AI 是你的研究助理、语法老师、灵感催化剂，但绝不是替你完成核心思考的“枪手”。

未来已来：从“代码实现者”到“思想叙事者”

这场关于“写作与思考”的讨论，最终引向了一个更宏大的问题：当 AI 越来越擅长“写作”（即编码实现）时，我们人类工程师的不可替代价值到底在哪里？

答案或许就在《自然》社论的结尾：“将整个写作过程外包给 LLM，会剥夺我们反思和塑造引人入胜的叙事的机会”。

未来工程师的核心竞争力，正在从单纯的技术实现，向上游转移。以下三项“元技能”将变得至关重要：

深度反思能力: 对技术领域、业务场景进行深刻的洞察和反思，理解“为什么”远比“怎么做”更重要。
创造性任务处理能力: 定义正确的问题，做出关键的架构取舍，进行富有创造力的系统设计。
思想叙事能力: 能够将复杂的技术决策、系统设计，用清晰、有说服力的“故事”（设计文档、技术演讲、甚至代码结构本身）讲述出来，影响和说服他人。

你看，这三项无法被 AI 替代的核心能力，恰恰都是通过“写作即思考”这个艰苦而宝贵的过程来培养和强化的。

小结：别让 AI 替你思考

AI 是一场革命性的技术浪潮，它正在重塑我们的工作方式。但我们必须保持清醒：AI 是我们手中的工具，而不是我们大脑的替代品。

我们可以，也应该，让 AI 成为我们强大的“副驾驶”，帮我们处理繁琐的事务，为我们提供新的视角。但方向盘，必须始终握在我们自己手中，谨慎和正确使用带有深度思考和推理功能的AI大模型。

因为我们写下的每一行代码，每一份文档，不仅仅是交付物，更是我们思考过程的凝结与沉淀。这个过程，才是我们作为工程师，最宝贵的财富。

资料链接：https://www.nature.com/articles/s44222-025-00323-4

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

探讨Docker容器中修改系统变量的方法

bigwhite — Tue, 14 Oct 2014 13:56:12 +0000

探讨完Docker对共享内存状态持久化的支持状况后，我将遗留产品build到一个pre-production image中，测试启动是否OK。很显然，我过于乐观了，Docker之路并不平坦。我收到了shmget报出的EINVAL错误码，提示参数非法。 shmget的manual对EINVAL错误码的说明如下：

EINVAL：
A new segment was to be created and size < SHMMIN or size > SHMMAX, or no new segment was to be created, a segment with given key existed, but size is greater than the size of that segment.

显然我们要创建的shared memory的size很可能大于SHMMAX这个系统变量了。那么一个从base image创建出的容器中的系统变量到底是什么值呢？我们来查看一下，我们基于"centos:centos6"启动一个Docker容器，并检查其中的系统变量值设置：

$ sudo docker run -it "centos:centos6" /bin/bash
bash-4.1# cat /proc/sys/kernel/shmmax
33554432
bash-4.1# sysctl -a|grep shmmax
kernel.shmmax = 33554432

可以看出默认情况下，当前容器中root账号看到的shmmax值我33554432，我的程序要创建的shm size的确要大于这个值，报出EINVAL错误也就无可厚非了。我尝试按照物理机上的方法临时修改一下该值：

bash-4.1# echo 68719476736 > /proc/sys/kernel/shmmax
bash: /proc/sys/kernel/shmmax: Read-only file system

/proc/sys/kernel/shmmax居然是只读的，无法修改。

我又尝试修改/etc/sysctl.conf这个持久化系统变量的地方，但打开/etc/sysctl.conf文件，我发现我又错了，这个文件中shmmax的值如下：

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736

/etc/sysctl.conf文件中的系统变量shmmax的值是68719476736，而系统当前的实际值则是33554432，难道是/etc /sysctl.conf中的值没有生效，于是我手工重新加载一次该文件：

-bash-4.1# sysctl -p
error: "Read-only file system" setting key "net.ipv4.ip_forward"
error: "Read-only file system" setting key "net.ipv4.conf.default.rp_filter"
error: "Read-only file system" setting key "net.ipv4.conf.default.accept_source_route"
error: "Read-only file system" setting key "kernel.sysrq"
error: "Read-only file system" setting key "kernel.core_uses_pid"
error: "net.ipv4.tcp_syncookies" is an unknown key
error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
error: "net.bridge.bridge-nf-call-iptables" is an unknown key
error: "net.bridge.bridge-nf-call-arptables" is an unknown key
error: "Read-only file system" setting key "kernel.msgmnb"
error: "Read-only file system" setting key "kernel.msgmax"
error: "Read-only file system" setting key "kernel.shmmax"
error: "Read-only file system" setting key "kernel.shmall"

我得到了和之前类似的错误结果：只读文件系统，无法修改。于是乎两个问题萦绕在我的面前：
1、为什么容器内当前系统变量值与sysctl.conf中的不一致？
2、为什么无法修改当前系统变量值?

在翻阅了Stackoverflow, github docker issues后，我得到了的答案如下：

1、Docker的base image做的很精简，甚至都没有init进程，原本在OS启动时执行生效系统变量的过程(sysctl -p)也给省略了，导致这些系统变量依旧保留着kernel默认值。以CentOs为例，在linux kernel boot后，init都会执行/etc/rc.d/rc.sysinit，后者会加载/etc/sysctl.conf中的系统变量值。下面是 CentOs5.6中的rc.sysinit代码摘录：

… …
# Configure kernel parameters
update_boot_stage RCkernelparam
sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1
… …

2、Docker容器中的系统变量在non-priviledged模式下目前(我使用的时docker 1.2.0版本)就无法修改，这和resolv.conf、hosts等文件映射到宿主机对应的文件有不同。

$ mount -l
…. ….
/dev/mapper/ubuntu–Server–14–vg-root on /etc/resolv.conf type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/mapper/ubuntu–Server–14–vg-root on /etc/hostname type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/mapper/ubuntu–Server–14–vg-root on /etc/hosts type ext4 (rw,relatime,errors=remount-ro,data=ordered)
… …

那么我们该如何修改系统变量值来满足遗留产品的需求呢？

一、使用–privileged选项

我们使用–privileged这个特权选项来启动一个基于centos:centos6的新容器，看看是否能对shmmax这样的系统变量值进行修改：

$ sudo docker run -it –privileged "centos:centos6" /bin/bash
bash-4.1# cat /proc/sys/kernel/shmmax
33554432
bash-4.1# echo 68719476736 > /proc/sys/kernel/shmmax
bash-4.1# cat /proc/sys/kernel/shmmax
68719476736
bash-4.1# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
… …
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296

可以看出，通过–privileged选项，容器获得了额外的特权，并且可以对系统变量的值进行修改了。不过这样的修改是不能保存在容器里的，我们stop 容器，再重启该容器就能看出来：

$ sudo docker start 3e22d65a7845
$ sudo docker attach 3e22d65a7845
bash-4.1# cat /proc/sys/kernel/shmmax
33554432

shmmax的值在容器重启后又变回了原先的那个默认值。不过重启后的容器依旧具有privileged的特权，我们还可以重新手工执行命令对系统变量进行修改：

bash-4.1# echo 68719476736 > /proc/sys/kernel/shmmax
bash-4.1# cat /proc/sys/kernel/shmmax
68719476736

但即便这样，也无法满足我们的需求，我们总不能每次都在容器中手工执行系统变量值修改的操作吧。privileged选项的能力能否带到 image中呢？答案是目前还不能，我们无法在build image时通过privileged选项修改系统变量值。

这样一来，我们能做的只有把产品启动与系统变量值修改放在一个脚本中了，并将该脚本作为docker 容器的cmd命令来执行，比如我们构建一个Dockerfile：

FROM centos:centos6
MAINTAINER Tony Bai
RUN yum install python-setuptools -y
RUN easy_install supervisor
RUN mkdir -p /var/log/supervisor
COPY ./supervisord.conf /etc/supervisord.conf
COPY ./start.sh /bin/start.sh
RUN chmod +x /bin/start.sh
CMD ["/bin/start.sh]

//start.sh
sysctl -p
/usr/bin/supervisord

这样，start.sh在supervisord启动前将系统变量值重新加载，而supervisord后续启动的程序就可以看到这些新系统变量的值了。不过别忘了利用这个image启动容器时要加上–priviledged选项，否则容器启动就会失败。

二、使用phusion/baseimage

前面说过/etc/sysctl.conf中的值没有生效是因为docker官方提供的centos:centos6把init进程的初始化过程给精简掉了。phusion/baseimage是目前docker registery上仅次于ubuntu和centos两个之后的base image，其提供了/sbin/my_init这个init进程，用于在container充当init进程的角色。那么my_init是否可以用于执行sysctl -p呢？我们试验一下：

我们先pull这个base image下来：sudo docker pull phusion/baseimage。pull成功后，我们先基于“phusion/baseimage”启动一个容器做一些explore工作：

$ sudo docker run -i -t "phusion/baseimage"
*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh…
No SSH host key available. Generating one…
Creating SSH2 RSA key; this may take some time …
Creating SSH2 DSA key; this may take some time …
Creating SSH2 ECDSA key; this may take some time …
Creating SSH2 ED25519 key; this may take some time …
invoke-rc.d: policy-rc.d denied execution of restart.
*** Running /etc/rc.local…
*** Booting runit daemon…
*** Runit started as PID 100

通过nsenter进去，查看一下/sbin/my_init的源码，我们发现这是一个python脚本，不过从头到尾浏览一遍，没有发现sysctl加载/etc/sysctl.conf系统变量的操作。

不过，phusion文档中说my_init可以在初始化过程中执行/etc/my_init.d下的脚本。那是不是我们将一个执行sysctl -p的脚本放入/etc/my_init.d下就可以实现我们的目的了呢？试试。

我们编写一个脚本：load_sys_varibles.sh

#!/bin/sh
sysctl -p > init.txt

下面是制作image的Dockerfile:

FROM phusion/baseimage:latest
MAINTAINER Tony Bai
RUN echo "kernel.shmmax = 68719476736" >> /etc/sysctl.conf
RUN mkdir -p /etc/my_init.d
ADD load_sys_varibles.sh /etc/my_init.d/load_sys_varibles.sh
RUN chmod +x /etc/my_init.d/load_sys_varibles.sh
CMD ["/sbin/my_init"]

phusion/baseimage是基于ubuntu的OS，其sysctl.conf默认情况下没啥内容，所以我们在Dockerfile中向这个文件写入我们需要的系统变量值。构建image并启动容器：

$ sudo docker build -t "myphusion:v1" ./
Sending build context to Docker daemon 13.12 MB
Sending build context to Docker daemon
Step 0 : FROM phusion/baseimage:latest
—> cf39b476aeec
Step 1 : MAINTAINER Tony Bai
—> Using cache
—> d0e9b51a3e4f
Step 2 : RUN echo "kernel.shmmax = 68719476736" >> /etc/sysctl.conf
—> Using cache
—> 2c800687cc83
Step 3 : RUN mkdir -p /etc/my_init.d
—> Using cache
—> fe366eea5eb4
Step 4 : ADD load_sys_varibles.sh /etc/my_init.d/load_sys_varibles.sh
—> a641bb595fb9
Removing intermediate container c381b9f001c2
Step 5 : RUN chmod +x /etc/my_init.d/load_sys_varibles.sh
—> Running in 764866552f25
—> eae3d7f1eac5
Removing intermediate container 764866552f25
Step 6 : CMD ["/sbin/my_init"]
—> Running in 9ab8d0b717a7
—> 8be4e7b6b174
Removing intermediate container 9ab8d0b717a7
Successfully built 8be4e7b6b174

$ sudo docker run -it "myphusion:v1"
*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh…
No SSH host key available. Generating one…
Creating SSH2 RSA key; this may take some time …
Creating SSH2 DSA key; this may take some time …
Creating SSH2 ECDSA key; this may take some time …
Creating SSH2 ED25519 key; this may take some time …
invoke-rc.d: policy-rc.d denied execution of restart.
*** Running /etc/my_init.d/load_sys_varibles.sh…
sysctl: setting key "kernel.shmmax": Read-only file system
*** /etc/my_init.d/load_sys_varibles.sh failed with status 255

*** Killing all processes…

唉，还是老问题！即便是在my_init中执行，依旧无法逾越Read-only file system，查看Phusion/baseimage的Dockerfile才知道，它也是From ubuntu:14.04的，根不变，上层再怎么折腾也没用。

换一种容器run方法吧，加上–privileged：

$ sudo docker run -it –privileged "myphusion:v1"
*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh…
No SSH host key available. Generating one…
Creating SSH2 RSA key; this may take some time …
Creating SSH2 DSA key; this may take some time …
Creating SSH2 ECDSA key; this may take some time …
Creating SSH2 ED25519 key; this may take some time …
invoke-rc.d: policy-rc.d denied execution of restart.
*** Running /etc/my_init.d/load_sys_varibles.sh…
*** Running /etc/rc.local…
*** Booting runit daemon…
*** Runit started as PID 102

这回灵光了。enter到容器里看看设置的值是否生效了：

root@9e399f46372a:~#cat /proc/sys/kernel/shmmax
68719476736

结果如预期。这样来看phusion/baseimage算是为sysctl -p加载系统变量值提供了一个便利，但依旧无法脱离–privileged，且依旧无法在image中持久化这个设置。

在Docker github的issue中有人提出建议在Dockerfile中加入类似RUNP这样的带有特权的指令语法，但不知何时才能在Docker中加入这一功能。

总而言之，基于目前docker官网提供的base image，我们很难找到特别理想的修改系统变量值的方法，除非自己制作base image，这个还没尝试过，待后续继续研究。

探讨docker容器对共享内存的支持情况

bigwhite — Sat, 11 Oct 2014 21:23:34 +0000

我们的遗留系统广泛使用了性能最佳的IPC方式 – 共享内存，而且用到了两种共享内存的实现方式：System V共享内存(shmget、shmat、shmdt)以及Mmap映射Regular File。System V共享内存支持一定程度上的内存数据持久化，即当程序创建共享内存对象后，如果不显式删除或物理主机重启，该IPC对象会一直保留，其中的数据也不会丢失；mmap映射Regular File的方式支持内存数据持久化到文件中，即便物理主机重启，这部分数据依旧不会丢失，除非显式删除文件。这两个共享内存机制，尤其是其持久化的特性是我们的系统所依赖的。但是在Docker容器中，这两种共享内存机制依旧能被很好的支持吗？我们通过试验来分析一下。

一、System V共享内存

一个启动的Docker容器就是一个拥有了自己的内核名字空间的进程，其pid、net、ipc、mnt、uts、user等均与其他进程隔离，对于运行于该容器内的程序而言，它仿佛会觉得它独占了一台“主机”。对于这类“主机”，我们首先来测试一下其中的system v共享内存是否依旧能像物理主机上一样，在程序退出后依旧能保持持久化？在容器退出后能保持么？

我们先来写两个测试程序，一个用于创建system v共享内存，并写入一些数据，另外一个程序则映射该共享内存并尝试读出内存中的数据。由于Golang目前仍未提供对System V共享内存的高级封装接口，通过syscall包的Syscall调用又太繁琐，因此我们直接使用C代码与Go代码结合的方式实现这两个测试程序。之前写过一篇名为《Go与C语言互操作》的博文，看不懂下面代码的朋友，可以先阅读一下这篇文章。

//systemv_shm_wr.go
package main

//#include
//#include
//#include
//#include
//
//#define SHMSZ     27
//
//int shm_wr() {
//    char c;
//    int shmid;
//    key_t key;
//    char *shm, *s;
//
//    key = 5678;
//
//    if ((shmid = shmget(key, SHMSZ, IPC_CREAT | 0666)) < 0) {
//        return -1;
//    }
//
//    if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) {
//        return -2;
//    }
//
//    s = shm;
//    for (c = 'a'; c <= 'z'; c++)
//        *s++ = c;
//    s = NULL;
//
//    return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_wr()
        if i != 0 {
                fmt.Println("SystemV Share Memory Create and Write Error:", i)
                return
        }
        fmt.Println("SystemV Share Memory Create and Write Ok")
}

//systemv_shm_rd.go

package main

//#include
//#include
//#include
//#include
//
//#define SHMSZ     27
//
//int shm_rd() {
//    char c;
//    int shmid;
//    key_t key;
//    char *shm, *s;
//
//    key = 5678;
//
//    if ((shmid = shmget(key, SHMSZ, 0666)) < 0) {
//        return -1;
//    }
//
//    if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) {
//        return -2;
//    }
//
//    s = shm;
//
//    int i = 0;
//    for (i = 0; i < SHMSZ-1; i++)
//        printf("%c ", *(s+i));
//    printf("\n");
//    s = NULL;
//
//    return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_rd()
        if i != 0 {
                fmt.Println("SystemV Share Memory Create and Read Error:", i)
                return
        }
        fmt.Println("SystemV Share Memory Create and Read Ok")
}

我们通过go build构建上面两个程序，得到两个测试用可执行程序：systemv_shm_wr和systemv_shm_rd。下面我们来构建我们的测试用docker image，Dockerfile内容如下：

FROM centos:centos6
MAINTAINER Tony Bai
COPY ./systemv_shm_wr /bin/
COPY ./systemv_shm_rd /bin/

构建Docker image：“shmemtest:v1”：

$ sudo docker build -t="shmemtest:v1" ./
Sending build context to Docker daemon 16.81 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
—> 68edf809afe7
Step 1 : MAINTAINER Tony Bai
—> Using cache
—> c617b456934a
Step 2 : COPY ./systemv_shm_wr /bin/
—> ea59fb767573
Removing intermediate container 4ce91720897b
Step 3 : COPY ./systemv_shm_rd /bin/
—> 1ceb207b1009
Removing intermediate container 7ace7ad53a3f
Successfully built 1ceb207b1009

启动一个基于该image的容器：
$ sudo docker run -it "shmemtest:v1" /bin/bash

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0a2f37bee6eb shmemtest:v1 "/bin/bash" 28 seconds ago Up 28 seconds elegant_hawking

进入容器，先后执行systemv_shm_wr和systemv_shm_rd，我们得到如下结果：

bash-4.1# systemv_shm_wr
SystemV Share Memory Create and Write Ok
bash-4.1# systemv_shm_rd
a b c d e f g h i j k l m n o p q r s t u v w x y z
SystemV Share Memory Create and Read Ok

在容器运行过程中，SystemV共享内存对象是可以持久化的。systemv_shm_wr退出后，数据依旧得以保留。我们接下来尝试一下重启container后是否还能读出数据：

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0a2f37bee6eb shmemtest:v1 "/bin/bash" 8 minutes ago Up 8 minutes elegant_hawking
$ sudo docker stop 0a2f37bee6eb
0a2f37bee6eb
$ sudo docker start 0a2f37bee6eb
0a2f37bee6eb
$ sudo docker attach 0a2f37bee6eb
bash-4.1# systemv_shm_rd
SystemV Share Memory Create and Read Error: -1

程序返回-1，显然在shmget时就出错了，系统已经没有了key为"5678"的这个共享内存IPC对象了。也就是说当容器stop时，就好比我们的物理主机关机，docker将该容器对应的共享内存IPC对象删除了。

从原理上分析，似乎我们也能得出此结论：毕竟Docker container是通过kernel namespace隔离的，容器中的进程在IPC资源申请时需要加入namespace信息。打个比方，如果我们启动容器的进程pid(物理主机视角)是 1234，那么这容器内进程申请的共享内存IPC资源（比如key=5678）的标识应该类似于“1234:5678”这样的形式。重启容器后，Docker Daemon无法给该容器分配与上次启动相同的pid，因此pid发生了变化，之前容器中的"1234:5678"保留下来也是毫无意义的，还无端占用系统资源。因此，System V IPC在Docker容器中的运用与物理机有不同，这方面要小心，目前似乎没有很好的方法，也许以后Docker会加入全局IPC，这个我们只能等待。

二、Mmap映射共享内存

接下来我们探讨mmap共享内存在容器中的支持情况。mmap常见的有两类共享内存映射方式，一种映射到/dev/zero，另外一种则是映射到 Regular Fiile。前者在程序退出后数据自动释放，后者则保留在映射的文件中。后者对我们更有意义，这次测试的也是后者。

同样，我们也先来编写两个测试程序。

//mmap_shm_wr.go
package main

//#include
//#include
//#include
//#include
//
//#define SHMSZ     27
//
//int shm_wr()
//{
//      char c;
//      char *shm = NULL;
//      char *s = NULL;
//      int fd;
//      if ((fd = open("./shm.txt", O_RDWR|O_CREAT, S_IRUSR|S_IWUSR)) == -1) {
//              return -1;
//      }
//
//      lseek(fd, 500, SEEK_CUR);
//      write(fd, "\0", 1);
//      lseek(fd, 0, SEEK_SET);
//
//      shm = (char*)mmap(shm, SHMSZ, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
//      if (!shm) {
//              return -2;
//
//      }
//
//      close(fd);
//      s = shm;
//      for (c = 'a'; c <= 'z'; c++) {
//              *(s+(int)(c – 'a')) = c;
//      }
//      return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_wr()
        if i != 0 {
                fmt.Println("Mmap Share Memory Create and Write Error:", i)
                return
        }
        fmt.Println("Mmap Share Memory Create and Write Ok")
}

//mmap_shm_rd.go
package main

//#include
//#include
//#include
//#include
//
//#define SHMSZ     27
//
//int shm_rd()
//{
//      char c;
//      char *shm = NULL;
//      char *s = NULL;
//      int fd;
//      if ((fd = open("./shm.txt", O_RDONLY)) == -1) {
//              return -1;
//      }
//
//      shm = (char*)mmap(shm, SHMSZ, PROT_READ, MAP_SHARED, fd, 0);
//      if (!shm) {
//              return -2;
//      }
//
//      close(fd);
//      s = shm;
//      int i = 0;
//      for (i = 0; i < SHMSZ – 1; i++) {
//              printf("%c ", *(s + i));
//      }
//      printf("\n");
//
//      return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_rd()
        if i != 0 {
                fmt.Println("Mmap Share Memory Read Error:", i)
                return
        }
        fmt.Println("Mmap Share Memory Read Ok")
}

我们通过go build构建上面两个程序，得到两个测试用可执行程序：mmap_shm_wr和mmap_shm_rd。下面我们来构建我们的测试用docker image，Dockerfile内容如下：

FROM centos:centos6
MAINTAINER Tony Bai
COPY ./mmap_shm_wr /bin/
COPY ./mmap_shm_rd /bin/

构建Docker image：“shmemtest:v2”：

$ sudo docker build -t="shmemtest:v2" ./
Sending build context to Docker daemon 16.81 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
—> 68edf809afe7
Step 1 : MAINTAINER Tony Bai
—> Using cache
—> c617b456934a
Step 2 : COPY ./mmap_shm_wr /bin/
—> Using cache
—> 01e2f6bc7606
Step 3 : COPY ./mmap_shm_rd /bin/
—> 0de95503c851
Removing intermediate container 0c472e92809f
Successfully built 0de95503c851

启动一个基于该image的容器：
$ sudo docker run -it "shmemtest:v2" /bin/bash

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1182f9eca367 shmemtest:v2 "/bin/bash" 11 seconds ago Up 11 seconds distracted_elion

进入容器，先后执行mmap_shm_wr和mmap_shm_rd，我们得到如下结果：

bash-4.1# mmap_shm_wr
Mmap Share Memory Create and Write Ok
bash-4.1# mmap_shm_rd
a b c d e f g h i j k l m n o p q r s t u v w x y z
Mmap Share Memory Read Ok

我们接下来尝试一下重启container后是否还能读出数据：

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1182f9eca367 shmemtest:v2 "/bin/bash" About a minute ago Up About a minute distracted_elion
$ sudo docker stop 1182f9eca367
1182f9eca367
$ sudo docker start 1182f9eca367
1182f9eca367
$ sudo docker attach 1182f9eca367

bash-4.1# mmap_shm_rd
a b c d e f g h i j k l m n o p q r s t u v w x y z
Mmap Share Memory Read Ok

通过执行结果可以看出，通过mmap映射文件方式，共享内存的数据即便在容器重启后依旧可以得到保留。从原理上看，shm.txt是容器内的一个文件，该文件存储在容器的可写文件系统layer中，从物理主机上看，其位置在/var/lib/docker/aufs/mnt /container_full_id/下，即便容器重启，该文件也不会被删除，而是作为容器文件系统的一部分：

$ sudo docker inspect -f '{{.Id}}' 1182f9eca367
1182f9eca36756219537f9a1c7cd1b62c6439930cc54bc69e87915c5dc8f7b97
$ sudo ls /var/lib/docker/aufs/mnt/1182f9eca36756219537f9a1c7cd1b62c6439930cc54bc69e87915c5dc8f7b97
bin dev etc home lib lib64 lost+found media mnt opt proc root sbin selinux shm.txt srv sys tmp usr var

docker容器内服务程序的优雅退出

bigwhite — Thu, 09 Oct 2014 13:58:49 +0000

近期在试验如何将我们的产品部署到docker容器中去，这其中涉及到一个技术环节，那就是如何让docker容器退出时其内部运行的服务程序也可以优雅的退出。所谓优雅退出，指的就是程序在退出前有清理资源（比如关闭文件描述符、关闭socket），保存必要中间状态，持久化内存数据（比如将内存中的数据flush到文件中）的机会。docker作为目前最火的轻量级虚拟化技术，其在后台服务领域的应用是极其广泛的，其设计者在程序优雅退出方面是有考虑的。下面我们由简单到复杂逐一考量一下。

一、优雅退出的原理

对于服务程序而言，一般都是以daemon形式运行在后台的。通知这些服务程序退出需要使用到系统的signal机制。一般服务程序都会监听某个特定的退出signal，比如SIGINT、SIGTERM等（通过kill -l命令你可以查看到几十种signal）。当我们使用kill + 进程号时，系统会默认发送一个SIGTERM给相应的进程。该进程通过signal handler响应这一信号，并在这个handler中完成相应的“优雅退出”操作。

与“优雅退出”对立的是“暴力退出”，也就是我们常说的使用kill -9，也就是kill -s SIGKILL + 进程号，这个行为不会给目标进程任何时间空隙，而是直接将进程杀死，无论进程当前在做何种操作。这种操作常常导致“不一致”状态的出现。SIGKILL这个信号比较特殊，进程无法有效监听该信号，无法有效针对该信号设置handler，无法改变其信号的默认处理行为。

二、测试用“服务程序”

为了测试docker容器对优雅退出的支持，我们编写如下“服务程序”用于放在docker容器中运行：

//dockerapp1.go

package main

import "fmt"
import "time"
import "os"
import "os/signal"
import "syscall"

type signalHandler func(s os.Signal, arg interface{})

type signalSet struct {
m map[os.Signal]signalHandler
}

func signalSetNew() *signalSet {
        ss := new(signalSet)
        ss.m = make(map[os.Signal]signalHandler)
        return ss
}

func (set *signalSet) register(s os.Signal, handler signalHandler) {
        if _, found := set.m[s]; !found {
                set.m[s] = handler
        }
}

func (set *signalSet) handle(sig os.Signal, arg interface{}) (err error) {
        if _, found := set.m[sig]; found {
                set.m[sig](sig, arg)
                return nil
        } else {
                return fmt.Errorf("No handler available for signal %v", sig)
        }

panic("won't reach here")
}

func main() {
go sysSignalHandleDemo()
time.Sleep(time.Hour) // make the main goroutine wait!
}

func sysSignalHandleDemo() {
        ss := signalSetNew()
        handler := func(s os.Signal, arg interface{}) {
                fmt.Printf("handle signal: %v\n", s)
                if s == syscall.SIGTERM {
                        fmt.Printf("signal termiate received, app exit normally\n")
                        os.Exit(0)
                }
        }

        ss.register(syscall.SIGINT, handler)
        ss.register(syscall.SIGUSR1, handler)
        ss.register(syscall.SIGUSR2, handler)
        ss.register(syscall.SIGTERM, handler)

        for {
                c := make(chan os.Signal)
                var sigs []os.Signal
                for sig := range ss.m {
                        sigs = append(sigs, sig)
                }
                signal.Notify(c)
                sig := <-c

                err := ss.handle(sig, nil)
                if err != nil {
                        fmt.Printf("unknown signal received: %v, app exit unexpectedly\n", sig)
                        os.Exit(1)
                }
        }
}

关于Go语言对系统Signal的处理，可以参考《Go中的系统Signal处理》一文。

三、制作测试用docker image

在《 Ubuntu Server 14.04安装docker》一文中，我们完成了在ubuntu 14.04上安装docker的步骤。要制作测试用docker image，我们首先需要pull一个base image。我们以CentOS6.5为例：

在Ubuntu 14.04上执行：
sudo docker pull centos:centos6

docker会自动从官方仓库下载一个制作好的docker image。下载成功后，我们可以run一下试试，像这样：

$> sudo docker run -t -i centos:centos6 /bin/bash

我们查看一下CentOS6的小版本：
$> cat /etc/centos-release
CentOS release 6.5 (Final)

这是一个极其精简的CentOS，各种工具均未安装：
bash-4.1# telnet
bash: telnet: command not found
bash-4.1# ssh
bash: ssh: command not found
bash-4.1# ftp
bash: ftp: command not found
bash-4.1# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

如果你要安装一些必要的工具，可以直接使用yum install，默认的base image已经将yum配置好了，可以直接使用。如果通过公司代理访问外部网络，别忘了先export http_proxy。另外docker直接使用宿主机的/etc/resolv.conf作为容器的DNS，我们也无需额外设置DNS。

接下来，我们就制作我们的第一个测试用image。安装官方推荐的Best Practice，我们使用Dockerfile来bulid一个测试用image。步骤如下：

- 建立~/ImagesFactory目录
- 将构建好的dockerapp1拷贝到~/ImagesFactory目录下
- 进入~/ImagesFactory目录，创建Dockerfile文件，Dockerfile内容如下：

FROM centos:centos6
MAINTAINER Tony Bai
COPY ./dockerapp1 /bin
CMD /bin/dockerapp1

- 执行docker build，结果如下：

$ sudo docker build -t="test:v1" ./
Sending build context to Docker daemon 7.496 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
—> 68edf809afe7
Step 1 : MAINTAINER Tony Bai
—> Using cache
—> c617b456934a
Step 2 : COPY ./dockerapp1 /bin
2014/10/09 16:05:25 lchown /var/lib/docker/aufs/mnt/fb0e864d3f07ca17ef8b6b69f034728e1f1158fd3f9c83fa48243054b2f26958/bin/dockerapp1: not a directory

居然build失败，提示什么not a directory。于是各种Search，终于发现问题所在，原来是“COPY ./dockerapp1 /bin”这条命令错了，少了个“/”，将" /bin"改为“/bin/”就OK了，Docker真是奇怪啊，这块明显应该做得更兼容些。新的Dockerfile如下：

FROM centos:centos6
MAINTAINER Tony Bai
COPY ./dockerapp1 /bin/
CMD /bin/dockerapp1

构建结果如下：

$ sudo docker build -t="test:v1" ./
Sending build context to Docker daemon 7.496 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
—> 68edf809afe7
Step 1 : MAINTAINER Tony Bai
—> Using cache
—> c617b456934a
Step 2 : COPY ./dockerapp1 /bin/
—> 20c3783c42ab
Removing intermediate container cab639ab4321
Step 3 : CMD /bin/dockerapp1
—> Running in 31875d3c37f9
—> 21a720a808a7
Removing intermediate container 31875d3c37f9
Successfully built 21a720a808a7

$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
test v1 21a720a808a7 59 seconds ago 214.6 MB

四、第一个测试容器

我们基于image "test:v1"启动一个测试容器：

$ sudo docker run -d "test:v1"
daf3ae88fec23a31cde9f6b9a3f40057953c87b56cca982143616f738a84dcba

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
daf3ae88fec2 test:v1 "/bin/sh -c /bin/doc 17 seconds ago Up 16 seconds condescending_sammet

通过docker run命令，我们基于image"test:v1"启动了一个容器。通过docker ps命令可以看到容器成功启动，容器id：daf3ae88fec2，别名为：condescending_sammet。

根据Dockerfile我们知道，容器启动后将执行"/bin/dockerapp1"这个程序，dockerapp1退出，容器即退出。 run命令的"-d"选项表示容器将以daemon的形式运行，我们在前台无法看到容器的输出。那么我们怎么查看容器的输出呢？我们可以通过 docker logs + 容器id的方式查看容器内应用的标准输出或标准错误。我们也可以进入容器来查看。

进入容器有多种方法，比如用sudo docker attach daf3ae88fec2。attach后，就好比将daemon方式运行的容器拿到了前台，你可以Ctrl + C一下，可以看到如下dockerapp1的输出:

^Chandle signal: interrupt

另外一种方式是利用nsenter工具进入我们容器的namespace空间。ubuntu 14.04下可以通过如下方式安装该工具：

$ wget https://www.kernel.org/pub/linux/utils/util-linux/v2.24/util-linux-2.24.tar.gz; tar xzvf util-linux-2.24.tar.gz
$ cd util-linux-2.24
$ ./configure –without-ncurses && make nsenter
$ sudo cp nsenter /usr/local/bin

安装后，我们通过如下方式即可进入上面的容器：

$ echo $(sudo docker inspect –format "{{ .State.Pid }}" daf3ae88fec2)
5494
$ sudo nsenter –target 5494 –mount –uts –ipc –net –pid
-bash-4.1# ps -ef
UID        PID PPID C STIME TTY          TIME CMD
root         1     0 0 09:20 ?        00:00:00 /bin/dockerapp1
root        16     0 0 09:32 ?        00:00:00 -bash
root        27    16 0 09:32 ?        00:00:00 ps -ef
-bash-4.1#

进入容器后通过ps命令可以看到正在运行的dockerapp1程序。在容器内，我们可以通过kill来测试dockerapp1的运行情况：

-bash-4.1# kill -s SIGINT 1

通过前面的attach窗口，我们可以看到dockerapp1输出:

handle signal: interrupt

如果你发送SIGTERM信号，那么dockerapp1将终止运行，容器也就停止了。

-bash-4.1# kill 1

attach窗口显示：

signal termiate received, app exit normally

我们可以看到容器启动后默认执行的时Dockerfile中的CMD命令，如果Dockerfile中有多行CMD命令，Docker在启动容器时只会执行最后一条CMD命令。如果在docker run中指定了命令，docker则会执行命令行中的命令而不会执行dockerapp1，比如：

$ sudo docker run -t -i "test:v1" /bin/bash
bash-4.1#

这里我们看到直接执行的时bash，dockerapp1并未执行。

五、docker stop的行为

我们先来看看docker stop的manual：

$ sudo docker stop –help
Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...]
Stop a running container by sending SIGTERM and then SIGKILL after a grace period
-t, –time=10 Number of seconds to wait for the container to stop before killing it. Default is 10 seconds.

可以看出当我们执行docker stop时，docker会首先向容器内的当前主程序发送一个SIGTERM信号，用于容器内程序的退出。如果容器在收到SIGTERM后没有马上退出，那么stop命令会在等待一段时间（默认是10s）后，再向容器发送SIGKILL信号，将容器杀死，变为退出状态。

我们来验证一下docker stop的行为。启动刚才那个容器：

$ sudo docker start daf3ae88fec2
daf3ae88fec2

attach到容器daf3ae88fec2
$ sudo docker attach daf3ae88fec2

新打开一个窗口，执行docker stop命令：
$ sudo docker stop daf3ae88fec2
daf3ae88fec2

可以看到attach窗口输出：
handle signal: terminated
signal termiate received, app exit normally

通过docker ps查看，发现容器已经退出。

也许通过上面的例子还不能直观的展示stop命令的两阶段行为，因为dockerapp1收到SIGTERM后直接就退出了，stop命令无需等待容器慢慢退出，也无需发送SIGKILL。我们改造一下dockerapp1这个程序。

我们复制一下dockerapp1.go为dockerapp2.go，编辑dockerapp2.go，将handler中对SIGTERM的处理注释掉，其他不变：

handler := func(s os.Signal, arg interface{}) {
                fmt.Printf("handle signal: %v\n", s)
                /*
                if s == syscall.SIGTERM {
                        fmt.Printf("signal termiate received, app exit normally\n")
                        os.Exit(0)
                }
                */
        }

我们使用dockerapp2来构建一个新image：test:v2，将Dockerfile中得dockerapp1换成 dockerapp2即可。

$ sudo docker build -t="test:v2" ./
Sending build context to Docker daemon 9.369 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
—> 68edf809afe7
Step 1 : MAINTAINER Tony Bai
—> Using cache
—> c617b456934a
Step 2 : COPY ./dockerapp2 /bin/
—> 27cd613a9bd7
Removing intermediate container 07c760b6223b
Step 3 : CMD /bin/dockerapp2
—> Running in 1aac086452a7
—> 82eb876fefd2
Removing intermediate container 1aac086452a7
Successfully built 82eb876fefd2

利用image "test:v2"创建一个容器来测试stop。

$ sudo docker run -d "test:v2"
29f3ec1af3c355458cbbd802a5e8a53da28e9f51a56ce822c7bba2a772edceac

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
29f3ec1af3c3 test:v2 "/bin/sh -c /bin/doc 7 seconds ago Up 6 seconds romantic_feynman

Attach到这个容器并观察，在另外一个窗口stop该container。我们在attach窗口只看到如下输出：

handle signal: terminated

stop命令的执行没有立即返回，而是等待容器退出。等待10s后，容器退出，stop命令执行结束。从这个例子我们可以明显看出stop的两阶段行为。

如果我们以sudo docker run -i -t "test:v1" /bin/bash形式启动容器，那stop命令会将SIGTERM发送给bash这个程序，即使你通过nsenter进入容器，启动了dockerapp1，dockerapp1也不会收到SIGTERM，dockerapp1会随着容器的退出而被强行终止，就像被 kill -9了一样。

六、多进程容器服务程序

上面无论是dockerapp1还是dockerapp2，都是一个单进程服务程序。如果我们在容器内执行一个多进程程序，我们该如何优雅退出呢？我们先来编写一个多进程的服务程序dockerapp3：

在dockerapp1.go的基础上对main和sysSignalHandleDemo进行修改形成dockerapp3.go，修改后这两个函数的代码如下：

//dockerapp3.go
… …

func main() {
go sysSignalHandleDemo()

        pid, _, err := syscall.RawSyscall(syscall.SYS_FORK, 0, 0, 0)
        if err != 0 {
                fmt.Printf("err fork process, err: %v\n", err)
                return
        }

        if pid == 0 {
                fmt.Printf("i am in child process, pid = %v\n", syscall.Getpid())
                time.Sleep(time.Hour) // make the child process wait
        }
        fmt.Printf("i am parent process, pid = %v\n", syscall.Getpid())
        fmt.Printf("fork ok, childpid = %v\n", pid)
        time.Sleep(time.Hour) // make the main goroutine wait!
}

func sysSignalHandleDemo() {
        ss := signalSetNew()
        handler := func(s os.Signal, arg interface{}) {
                fmt.Printf("%v: handle signal: %v\n", syscall.Getpid(), s)
                if s == syscall.SIGTERM {
                        fmt.Printf("%v: signal termiate received, app exit normally\n", syscall.Getpid())
                        os.Exit(0)
                }
        }

        ss.register(syscall.SIGINT, handler)
        ss.register(syscall.SIGUSR1, handler)
        ss.register(syscall.SIGUSR2, handler)
        ss.register(syscall.SIGTERM, handler)

                err := ss.handle(sig, nil)
                if err != nil {
                        fmt.Printf("%v: unknown signal received: %v, app exit unexpectedly\n", syscall.Getpid(), sig)
                        os.Exit(1)
                }
        }
}

dockerapp3利用fork创建了一个子进程，这样dockerapp3实际上是两个进程在运行，各自有自己的signal监听 goroutine，goroutine的处理逻辑是相同的。注意：由于Windows和Mac OS X不具备fork语义，因此在这两个平台上运行dockerapp3不会得到预期结果。

利用dockerapp3，我们创建image "test:v3":

$ sudo docker build -t="test:v3" ./
[sudo] password for tonybai:
Sending build context to Docker daemon 11.24 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
—> 68edf809afe7
Step 1 : MAINTAINER Tony Bai
—> Using cache
—> c617b456934a
Step 2 : COPY ./dockerapp3 /bin/
—> 6ccf97065853
Removing intermediate container 6d85fe241939
Step 3 : CMD /bin/dockerapp3
—> Running in 75d76380992a
—> c9e7bf361ed7
Removing intermediate container 75d76380992a
Successfully built c9e7bf361ed7

启动基于test:v3 image的容器：

$ sudo docker run -d "test:v3"
781cecb4b3628cb33e1b104ea57e506ad5cb4a44243256ebd1192af86834bae6
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
781cecb4b362 test:v3 "/bin/sh -c /bin/doc 5 seconds ago Up 4 seconds insane_bohr

通过docker logs查看dockerapp3的输出：

$ sudo docker logs 781cecb4b362
i am parent process, pid = 1
fork ok, childpid = 13
i am in child process, pid = 13

可以看出主进程pid为1，子进程pid为13。我们通过stop停止该容器：

$ sudo docker stop 781cecb4b362
781cecb4b362

再次通过docker logs查看：

$ sudo docker logs 781cecb4b362
i am parent process, pid = 1
fork ok, childpid = 13
i am in child process, pid = 13
1: handle signal: terminated
1: signal termiate received, app exit normally

我们可以看到主进程收到了stop发来的SIGTERM并退出，主进程的退出导致容器退出，导致子进程13也无法生存，并且没有优雅退出。而在非容器状态下，子进程是可以被init进程接管的。

因此对于docker容器内运行的多进程程序，stop命令只会将SIGTERM发送给容器主进程，要想让其他进程也能优雅退出，需要在主进程与其他进程间建立一种通信机制。在主进程退出前，等待其他子进程退出。待所有其他进程退出后，主进程再退出，容器停止。这样才能保证服务程序的优雅退出。

七、容器内启动多个服务程序

虽说docker best practice建议一个container内只放置一个服务程序，但对已有的一些遗留系统，在架构没有做出重构之前，很可能会有在一个 container中部署两个以上服务程序的情况和需求。而docker Dockerfile只允许执行一个CMD，这种情况下，我们就需要借助类似supervisor这样的进程监控管理程序来启动和管理container 内的多个程序了。

下面我们来自制作一个基于centos:centos6的安装了supervisord以及两个服务程序的image。我们将dockerapp1拷贝一份，并将拷贝命名为dockerapp1-brother。下面是我们的Dockerfile：

FROM centos:centos6
MAINTAINER Tony Bai
RUN yum install python-setuptools -y
RUN easy_install supervisor
RUN mkdir -p /var/log/supervisor
COPY ./supervisord.conf /etc/supervisord.conf
COPY ./dockerapp1 /bin/
COPY ./dockerapp1-brother /bin/
CMD ["/usr/bin/supervisord"]

supervisord的配置文件supervisord.conf内容如下：

; supervisor config file

[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod=0700 ; sockef file mode (default 0700)

[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log/supervisor ; ('AUTO' child log dir, default $TEMP)

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket

[supervisord]
nodaemon=false

[program:dockerapp1]
command=/bin/dockerapp1
stdout_logfile=/tmp/dockerapp1.log
stopsignal=TERM
stopwaitsecs=10

[program:dockerapp1-brother]
command=/bin/dockerapp1-brother
stdout_logfile=/tmp/dockerapp1-brother.log
stopsignal=QUIT
stopwaitsecs=10

开始build镜像：
    $> sudo docker build -t="test:supervisor-v1" ./
    … …
    Successfully built d006b9ad10eb

基于该镜像，启动一个容器：
$> sudo docker run -d "test:supervisor-v1"
05ded2b898c90059d4c9b5c6ccc8603b6848ae767360c42bd9b36ff87fb4b9df

执行ps命令查看镜像id：
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

怎么回事？Container没有启动起来？

$ sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
05ded2b898c9 test:supervisor-v1 "/usr/bin/supervisor 22 seconds ago Exited (0) 21 seconds ago hungry_engelbart

通过ps -a查看，container启动是成功了，但是成功退出了。于是尝试查看一下log：

sudo docker logs 05ded2b898c9
/usr/lib/python2.6/site-packages/supervisor-3.1.2-py2.6.egg/supervisor/options.py:296: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
'Supervisord is running as root and it is searching '

似乎是supervisord转为daemon程序，容器主进程退出了，容器随之终止了。

看来容器内的supervisord不能以daemon形式运行，应该以前台形式run。修改一下supervisord.conf中得配置：

将
[supervisord]
nodaemon=false

改为

[supervisord]
nodaemon=true

重新制作镜像:

$ sudo docker build -t="test:supervisor-v2" ./
Sending build context to Docker daemon 13.12 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
—> 68edf809afe7
Step 1 : MAINTAINER Tony Bai
—> Using cache
—> c617b456934a
Step 2 : RUN yum install python-setuptools -y
—> Using cache
—> e09c66a1ea8c
Step 3 : RUN easy_install supervisor
—> Using cache
—> 9c8797e8c27e
Step 4 : RUN mkdir -p /var/log/supervisor
—> Using cache
—> 9bfc67f8517d
Step 5 : COPY ./supervisord.conf /etc/supervisord.conf
—> 8c514f998363
Removing intermediate container 4a185856e6ed
Step 6 : COPY ./dockerapp1 /bin/
—> 0317bd4914d3
Removing intermediate container ac5738380854
Step 7 : COPY ./dockerapp1-brother /bin/
—> d89711888bdf
Removing intermediate container eadc9444e716
Step 8 : CMD ["/usr/bin/supervisord"]
—> Running in aaa042ac3914
—> 9655256bbfed
Removing intermediate container aaa042ac3914
Successfully built 9655256bbfed

有了前面的铺垫，这次build image瞬间完成。启动容器，查看容器启动状态，查看容器内supervisord的运行日志如下：

$ sudo docker run -d "test:supervisor-v2"
61916f1c82338b28ced101b6bde119e4afb7c7fa349b4332ed51a43a4586b1b9

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
61916f1c8233 test:supervisor-v2 "/usr/bin/supervisor 16 seconds ago Up 16 seconds prickly_einstein

$ sudo docker logs 8eb3e9892e66

/usr/lib/python2.6/site-packages/supervisor-3.1.2-py2.6.egg/supervisor/options.py:296: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
'Supervisord is running as root and it is searching '
2014-10-09 14:36:02,334 CRIT Supervisor running as root (no user in config file)
2014-10-09 14:36:02,349 INFO RPC interface 'supervisor' initialized
2014-10-09 14:36:02,349 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2014-10-09 14:36:02,349 INFO supervisord started with pid 1
2014-10-09 14:36:03,354 INFO spawned: 'dockerapp1' with pid 14
2014-10-09 14:36:03,363 INFO spawned: 'dockerapp1-brother' with pid 15
2014-10-09 14:36:04,368 INFO success: dockerapp1 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2014-10-09 14:36:04,369 INFO success: dockerapp1-brother entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

可以看到supervisord已经将dockerapp1和dockerapp1-brother启动起来了。

现在我们尝试停止容器，我们预期是supervisord在退出前通知dockerapp1和dockerapp1-brother先退出，我们可以通过查看容器内的/tmp/dockerapp1.log和/tmp/dockerapp1-brother.log来确认supervisord是否做了通知。

$ sudo docker stop 61916f1c8233
61916f1c8233

$ sudo docker logs 61916f1c8233
… …
2014-10-09 14:37:52,253 WARN received SIGTERM indicating exit request
2014-10-09 14:37:52,254 INFO waiting for dockerapp1, dockerapp1-brother to die
2014-10-09 14:37:52,254 INFO stopped: dockerapp1-brother (exit status 0)
2014-10-09 14:37:52,256 INFO stopped: dockerapp1 (exit status 0)

通过容器的log，我们看出supervisord是等待两个程序退出后才退出的，不过我们还是要看看两个程序的输出日志以最终确认。重新启动容器，通过nsenter进入到容器中。

-bash-4.1# vi /tmp/dockerapp1.log

handle signal: terminated
signal termiate received, app exit normally

-bash-4.1# vi /tmp/dockerapp1-brother.log

handle signal: terminated
signal termiate received, app exit normally

两个程序的标准输出日志证实了我们的预期。

BTW，在物理机上测试supervisord以daemon形式运行，当kill掉supervisord时，supervisord是不会通知其监控和管理的程序退出的。只有在以non-daemon形式运行时，supervisord才会在退出前先通知下面的程序退出。如果在一段时间内下面程序没有退出，supervisord在退出前会kill -9强制杀死这些程序的进程。

最后要说的时，在验证一些想法时，没有必要build image，我们可以直接将本地文件copy到容器中，下面是一个例子，我们将dockerapp1和dockerapp1-brother拷贝到镜像中：
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4d8982bfccc7 centos:centos6 "/bin/bash" 26 minutes ago Up 26 minutes sharp_thompson
$ sudo docker inspect -f '{{.Id}}' 4d8982bfccc7
4d8982bfccc79dea762b41f8a6f669bda1ec73c8881b6ca76e7a7917c62972c4
$ sudo cp dockerapp1 /var/lib/docker/aufs/mnt/4d8982bfccc79dea762b41f8a6f669bda1ec73c8881b6ca76e7a7917c62972c4/bin/dockerapp1
$ sudo cp dockerapp1-brother /var/lib/docker/aufs/mnt/4d8982bfccc79dea762b41f8a6f669bda1ec73c8881b6ca76e7a7917c62972c4/bin/dockerapp1-brother

Golang Channel用法简编

bigwhite — Mon, 29 Sep 2014 09:02:43 +0000

在进入正式内容前，我这里先顺便转发一则消息，那就是Golang 1.3.2已经正式发布了。国内的golangtc已经镜像了golang.org的安装包下载页面，国内go程序员与爱好者们可以到"Golang中国"，即golangtc.com去下载go 1.3.2版本。

Go这门语言也许你还不甚了解，甚至是完全不知道，这也有情可原，毕竟Go在TIOBE编程语言排行榜上位列30开外。但近期使用Golang 实现的一杀手级应用 Docker你却不该不知道。docker目前火得是一塌糊涂啊。你去国内外各大技术站点用眼轻瞥一下，如果没有涉及到“docker”字样新闻的站点建议你以后就不要再去访问了^_^。Docker是啥、怎么用以及基础实践可以参加国内一位仁兄的经验之作：《 Docker – 从入门到实践》。

据我了解，目前国内试水Go语言开发后台系统的大公司与初创公司日益增多，比如七牛、京东、小米，盛大，金山，东软，搜狗等，在这里我们可以看到一些公司的Go语言应用列表，并且目前这个列表似乎依旧在丰富中。国内Go语言的推广与布道也再稳步推进中，不过目前来看多以Go入门与基础为主题，Go idioms、tips或Best Practice的Share并不多见，想必国内的先行者、布道师们还在韬光养晦，积攒经验，等到时机来临再厚积薄发。另外国内似乎还没有一个针对Go的布道平台，比如Golang技术大会之类的的平台。

在国外，虽然Go也刚刚起步，但在Golang share的广度和深度方面显然更进一步。Go的国际会议目前还不多，除了Golang老东家Google在自己的各种大会上留给Golang展示自己的机会外，由 Gopher Academy 发起的GopherCon 会议也于今年第一次举行，并放出诸多高质量资料，在这里可以下载。欧洲的Go语言大会.dotgo也即将开幕，估计后续这两个大会将撑起Golang技术分享的旗帜。

言归正传，这里要写的东西并非原创，自己的Go仅仅算是入门级别，工程经验、Best Practice等还谈不上有多少，因此这里主要是针对GopherCon2014上的“舶来品”的学习心得。来自CloudFlare的工程师John Graham-Cumming谈了关于 Channel的实践经验，这里针对其分享的内容，记录一些学习体会和理解，并结合一些外延知识，也可以算是一种学习笔记吧，仅供参考。

一、Golang并发基础理论

Golang在并发设计方面参考了C.A.R Hoare的CSP，即Communicating Sequential Processes并发模型理论。但就像John Graham-Cumming所说的那样，多数Golang程序员或爱好者仅仅停留在“知道”这一层次，理解CSP理论的并不多，毕竟多数程序员是搞工程的。不过要想系统学习CSP的人可以从这里下载到CSP论文的最新版本。

维基百科中概要罗列了CSP模型与另外一种并发模型Actor模型的区别：

Actor模型广义上讲与CSP模型很相似。但两种模型就提供的原语而言，又有一些根本上的不同之处：
    – CSP模型处理过程是匿名的，而Actor模型中的Actor则具有身份标识。
    – CSP模型的消息传递在收发消息进程间包含了一个交会点，即发送方只能在接收方准备好接收消息时才能发送消息。相反，actor模型中的消息传递是异步的，即消息的发送和接收无需在同一时间进行，发送方可以在接收方准备好接收消息前将消息发送出去。这两种方案可以认为是彼此对偶的。在某种意义下，基于交会点的系统可以通过构造带缓冲的通信的方式来模拟异步消息系统。而异步系统可以通过构造带消息/应答协议的方式来同步发送方和接收方来模拟交会点似的通信方式。
    – CSP使用显式的Channel用于消息传递，而Actor模型则将消息发送给命名的目的Actor。这两种方法可以被认为是对偶的。某种意义下，进程可以从一个实际上拥有身份标识的channel接收消息，而通过将actors构造成类Channel的行为模式也可以打破actors之间的名字耦合。

二、Go Channel基本操作语法

Go Channel的基本操作语法如下：

c := make(chan bool) //创建一个无缓冲的bool型Channel 
c <- x        //向一个Channel发送一个值
<- c          //从一个Channel中接收一个值
x = <- c      //从Channel c接收一个值并将其存储到x中
x, ok = <- c //从Channel接收一个值，如果channel关闭了或没有数据，那么ok将被置为false

不带缓冲的Channel兼具通信和同步两种特性，颇受青睐。

三、Channel用作信号(Signal)的场景

1、等待一个事件(Event)

等待一个事件，有时候通过close一个Channel就足够了。例如：

//testwaitevent1.go
package main

import "fmt"

func main() {
        fmt.Println("Begin doing something!")
        c := make(chan bool)
        go func() {
                fmt.Println("Doing something…")
                close(c)
        }()
        <-c
        fmt.Println("Done!")
}

这里main goroutine通过"<-c"来等待sub goroutine中的“完成事件”，sub goroutine通过close channel促发这一事件。当然也可以通过向Channel写入一个bool值的方式来作为事件通知。main goroutine在channel c上没有任何数据可读的情况下会阻塞等待。

关于输出结果：

根据《Go memory model》中关于close channel与recv from channel的order的定义：The closing of a channel happens before a receive that returns a zero value because the channel is closed.

我们可以很容易判断出上面程序的输出结果：

Begin doing something!
Doing something…
Done!

如果将close(c)换成c<-true，则根据《Go memory model》中的定义：A receive from an unbuffered channel happens before the send on that channel completes.
"<-c"要先于"c<-true"完成，但也不影响日志的输出顺序，输出结果仍为上面三行。

2、协同多个Goroutines

同上，close channel还可以用于协同多个Goroutines，比如下面这个例子，我们创建了100个Worker Goroutine，这些Goroutine在被创建出来后都阻塞在"<-start"上，直到我们在main goroutine中给出开工的信号："close(start)"，这些goroutines才开始真正的并发运行起来。

//testwaitevent2.go
package main

import "fmt"

func worker(start chan bool, index int) {
<-start
fmt.Println("This is Worker:", index)
}

func main() {
        start := make(chan bool)
        for i := 1; i <= 100; i++ {
                go worker(start, i)
        }
        close(start)
        select {} //deadlock we expected
}

3、Select

【select的基本操作】
select是Go语言特有的操作，使用select我们可以同时在多个channel上进行发送/接收操作。下面是select的基本操作。

select {
case x := <- somechan:
// … 使用x进行一些操作

case y, ok := <- someOtherchan:
// … 使用y进行一些操作，
// 检查ok值判断someOtherchan是否已经关闭

case outputChan <- z:
// … z值被成功发送到Channel上时

default:
// … 上面case均无法通信时，执行此分支
}

【惯用法：for/select】

我们在使用select时很少只是对其进行一次evaluation，我们常常将其与for {}结合在一起使用，并选择适当时机从for{}中退出。

for {
        select {
        case x := <- somechan:
            // … 使用x进行一些操作

        case y, ok := <- someOtherchan:
            // … 使用y进行一些操作，
            // 检查ok值判断someOtherchan是否已经关闭

case outputChan <- z:
// … z值被成功发送到Channel上时

        default:
            // … 上面case均无法通信时，执行此分支
        }
}

【终结workers】

下面是一个常见的终结sub worker goroutines的方法，每个worker goroutine通过select监视一个die channel来及时获取main goroutine的退出通知。

//testterminateworker1.go
package main

import (
"fmt"
"time"
)

func worker(die chan bool, index int) {
    fmt.Println("Begin: This is Worker:", index)
    for {
        select {
        //case xx：
            //做事的分支
        case <-die:
            fmt.Println("Done: This is Worker:", index)
            return
        }
    }
}

func main() {
die := make(chan bool)

    for i := 1; i <= 100; i++ {
        go worker(die, i)
    }

    time.Sleep(time.Second * 5)
    close(die)
    select {} //deadlock we expected
}

【终结验证】

有时候终结一个worker后，main goroutine想确认worker routine是否真正退出了，可采用下面这种方法：

//testterminateworker2.go
package main

import (
"fmt"
//"time"
)

func worker(die chan bool) {
    fmt.Println("Begin: This is Worker")
    for {
        select {
        //case xx：
        //做事的分支
        case <-die:
            fmt.Println("Done: This is Worker")
            die <- true
            return
        }
    }
}

func main() {
die := make(chan bool)

go worker(die)

    die <- true
    <-die
    fmt.Println("Worker goroutine has been terminated")
}

【关闭的Channel永远不会阻塞】

下面演示在一个已经关闭了的channel上读写的结果：

//testoperateonclosedchannel.go
package main

import "fmt"

func main() {
        cb := make(chan bool)
        close(cb)
        x := <-cb
        fmt.Printf("%#v\n", x)

x, ok := <-cb
fmt.Printf("%#v %#v\n", x, ok)

        ci := make(chan int)
        close(ci)
        y := <-ci
        fmt.Printf("%#v\n", y)

cb <- true
}

$go run testoperateonclosedchannel.go
false
false false
0
panic: runtime error: send on closed channel

可以看到在一个已经close的unbuffered channel上执行读操作，回返回channel对应类型的零值，比如bool型channel返回false，int型channel返回0。但向close的channel写则会触发panic。不过无论读写都不会导致阻塞。

【关闭带缓存的channel】

将unbuffered channel换成buffered channel会怎样？我们看下面例子：

//testclosedbufferedchannel.go
package main

import "fmt"

func main() {
        c := make(chan int, 3)
        c <- 15
        c <- 34
        c <- 65
        close(c)
        fmt.Printf("%d\n", <-c)
        fmt.Printf("%d\n", <-c)
        fmt.Printf("%d\n", <-c)
        fmt.Printf("%d\n", <-c)

c <- 1
}

$go run testclosedbufferedchannel.go
15
34
65
0
panic: runtime error: send on closed channel

可以看出带缓冲的channel略有不同。尽管已经close了，但我们依旧可以从中读出关闭前写入的3个值。第四次读取时，则会返回该channel类型的零值。向这类channel写入操作也会触发panic。

【range】

Golang中的range常常和channel并肩作战，它被用来从channel中读取所有值。下面是一个简单的实例：

//testrange.go
package main

import "fmt"

func generator(strings chan string) {
        strings <- "Five hour's New York jet lag"
        strings <- "and Cayce Pollard wakes in Camden Town"
        strings <- "to the dire and ever-decreasing circles"
        strings <- "of disrupted circadian rhythm."
        close(strings)
}

func main() {
        strings := make(chan string)
        go generator(strings)
        for s := range strings {
                fmt.Printf("%s\n", s)
        }
        fmt.Printf("\n")
}

四、隐藏状态

下面通过一个例子来演示一下channel如何用来隐藏状态：

1、例子：唯一的ID服务

//testuniqueid.go
package main

import "fmt"

func newUniqueIDService() <-chan string {
        id := make(chan string)
        go func() {
                var counter int64 = 0
                for {
                        id <- fmt.Sprintf("%x", counter)
                        counter += 1
                }
        }()
        return id
}
func main() {
        id := newUniqueIDService()
        for i := 0; i < 10; i++ {
                fmt.Println(<-id)
        }
}

$ go run testuniqueid.go
0
1
2
3
4
5
6
7
8
9

newUniqueIDService通过一个channel与main goroutine关联，main goroutine无需知道uniqueid实现的细节以及当前状态，只需通过channel获得最新id即可。

五、默认情况

我想这里John Graham-Cumming主要是想告诉我们select的default分支的实践用法。

1、select for non-blocking receive

idle:= make(chan []byte, 5) //用一个带缓冲的channel构造一个简单的队列

select {
case b = <-idle:  //尝试从idle队列中读取
    …
default: //队列空，分配一个新的buffer
        makes += 1
        b = make([]byte, size)
}

2、select for non-blocking send

idle:= make(chan []byte, 5) //用一个带缓冲的channel构造一个简单的队列

select {
case idle <- b: //尝试向队列中插入一个buffer
//…
default: //队列满？

}

六、Nil Channels

1、nil channels阻塞

对一个没有初始化的channel进行读写操作都将发生阻塞，例子如下：

package main

func main() {
var c chan int
<-c
}

$go run testnilchannel.go
fatal error: all goroutines are asleep – deadlock!

package main

func main() {
var c chan int
c <- 1
}

$go run testnilchannel.go
fatal error: all goroutines are asleep – deadlock!

2、nil channel在select中很有用

看下面这个例子：

//testnilchannel_bad.go
package main

import "fmt"
import "time"

func main() {
        var c1, c2 chan int = make(chan int), make(chan int)
        go func() {
                time.Sleep(time.Second * 5)
                c1 <- 5
                close(c1)
        }()

        go func() {
                time.Sleep(time.Second * 7)
                c2 <- 7
                close(c2)
        }()

        for {
                select {
                case x := <-c1:
                        fmt.Println(x)
                case x := <-c2:
                        fmt.Println(x)
                }
        }
        fmt.Println("over")
}

我们原本期望程序交替输出5和7两个数字，但实际的输出结果却是：

5
0
0
0
… … 0死循环

再仔细分析代码，原来select每次按case顺序evaluate：
    – 前5s，select一直阻塞；
    – 第5s，c1返回一个5后被close了，“case x := <-c1”这个分支返回，select输出5，并重新select
    – 下一轮select又从“case x := <-c1”这个分支开始evaluate，由于c1被close，按照前面的知识，close的channel不会阻塞，我们会读出这个 channel对应类型的零值，这里就是0；select再次输出0；这时即便c2有值返回，程序也不会走到c2这个分支
    – 依次类推，程序无限循环的输出0

我们利用nil channel来改进这个程序，以实现我们的意图，代码如下：

//testnilchannel.go
package main

import "fmt"
import "time"

        go func() {
                time.Sleep(time.Second * 7)
                c2 <- 7
                close(c2)
        }()

        for {
                select {
                case x, ok := <-c1:
                        if !ok {
                                c1 = nil
                        } else {
                                fmt.Println(x)
                        }
                case x, ok := <-c2:
                        if !ok {
                                c2 = nil
                        } else {
                                fmt.Println(x)
                        }
                }
                if c1 == nil && c2 == nil {
                        break
                }
        }
        fmt.Println("over")
}

$go run testnilchannel.go
5
7
over

可以看出：通过将已经关闭的channel置为nil，下次select将会阻塞在该channel上，使得select继续下面的分支evaluation。

七、Timers

1、超时机制Timeout

带超时机制的select是常规的tip，下面是示例代码，实现30s的超时select：

func worker(start chan bool) {
        timeout := time.After(30 * time.Second)
        for {
                select {
                     // … do some stuff
                case <- timeout:
                    return
                }
        }
}

2、心跳HeartBeart

与timeout实现类似，下面是一个简单的心跳select实现：

func worker(start chan bool) {
        heartbeat := time.Tick(30 * time.Second)
        for {
                select {
                     // … do some stuff
                case <- heartbeat:
                    //… do heartbeat stuff
                }
        }
}

Cocos2d-x集成Amazon内购和GameCircle服务

bigwhite — Mon, 04 Aug 2014 10:30:59 +0000

由于种种原因，这篇文章已经拖延了N多时间了。今天花了些时间把如何在Cocos2d-x(我用的版本是2.2.2)游戏中集成Amazon的内购和GameCircle服务(仅适用于Android版本)整理一下，发出来，作备忘。

之前在做“手指足球世界杯2014”时，想给这款小游戏加上内购(In-App Purchasing)和积分榜(ScoreBoard)功能。说到Android手机游戏的内购，人们第一时间想到的就是Google Play，不过悲催的是，Google Play在国内各种无法访问，行货机也不预装，其相关Service的测试十分困难，翻看了一些集成Google Game Service的文章，其过程坎坷之程度让人望而却步。于是我将目光转而投向了Amazon Game Service。亚马逊的游戏服务起步要晚些，成熟性肯定不如Google，但在国内来说也不失为另一个不错的选择，Google虽好，但访问不了有啥法。但似乎国内同行使用Amazon游戏服务的并不多，度娘上相关中文资料甚少。但从Amazon发布的数据来看，其市场正在逐步扩大，并紧紧跟随 Google Play的脚步。

之前用kindle paperwhite时在amazon.com上注册了一个国际帐号，这次正好用这个。不过你要使用Amazon的Game Service，普通Amazon帐号是不行的。你要升级为Amazon的Developer。申请Developer帐号的过程还是蛮繁琐的，要提交一堆资料，具体细节我大致忘的差不多了，这里就不说了。按照Amazon网站的提示一步一步做就是了。

有了帐号后，你可以下载Amazon的Game SDK了，这个包有近50M大小，本地解压后可以看到其提供的Android SDK种类：

AmazonSDK/Android$ ls
Ads AmazonInsights DeviceMessaging GameCircle InAppPurchasing LoginWithAmazon Maps MobileAssociates README.txt

Ads我之前用的是Google Admob，这里就不再用Amazon的了，我需要的是这里的InAppPurchasing和GameCircle。我们接下来一个一个来说。

* Amazon InAppPurchasing

Amazon支持三种内购类型：Consumables、Entitlements和Subscriptions：
    Consumables就像游戏中的红心、金币等，用户可以多次购买，每次可以买多个，并根据游戏规则，每次消耗若干个以达到某种游戏目的；在哪台设备上购买，就只能在哪台设备上使用。
    Entitlements是某种授权协议，一个用户只需购买一次，即可长期使用某种特权功能，并与设备无关，可在多个设备下授权使用。比如鳄鱼洗澡游戏中购买高级关卡等。
    Subscriptions有订阅的意思，需要某种Entitlements或某种访问权，在一定时间段内绑定有效，到期后自动renew，比如某种杂志的阅读权等。

我只想给游戏增加一些红心功能，一颗红心，可以让游戏者有一次续命的机会，因此我需要实现Consumables型内购。Amazon SDK中提供了Consumeables类内购的Android范例AmazonSDK/Android/InAppPurchasing/samples/SampleIAPConsumablesApp。我们可以参考这个例子来实现我的"红心内购"。

1、添加依赖的jar包
在你的游戏proj中添加内购功能所依赖的Amazon SDK jar包，包括AmazonInsights-android-sdk-2.1.26.jar、in-app-purchasing-1.0.3.jar 和login-with-amazon-sdk.jar。

2、添加源文件
参照例子，将AppPurchasingObserver.java、AppPurchasingObserverListener.java和MySKU.java拷贝到你的与XXActivity.java同级目录下。

    3、初始化Amazon IAP

    在你的XXActivity类中添加如下方法：

public PurchaseDataStorage purchaseDataStorage;

private void setupIAPOnCreate() {
purchaseDataStorage = new PurchaseDataStorage(this);

        AppPurchasingObserver purchasingObserver
              = new AppPurchasingObserver(this, purchaseDataStorage);
        purchasingObserver.setListener(this);

        Log.i(TAG, "onCreate: registering AppPurchasingObserver");
        PurchasingManager.registerObserver(purchasingObserver);
    }

    protected void onCreate(Bundle savedInstanceState){
        … …
        setupIAPOnCreate();
    }

        protected void onResume() {
        super.onResume();

        Log.i(TAG, "onResume: call initiateGetUserIdRequest");
        PurchasingManager.initiateGetUserIdRequest();

        Log.i(TAG, "onResume: call initiateItemDataRequest for skus: "
                        + MySKU.getAll());
        PurchasingManager.initiateItemDataRequest(MySKU.getAll());
    }

4、添加购买方法

在Cocos2d-x的某个Scene或Layer中实现的购买方法事件的callback，后者通过Jni调用Java静态方法：

    void BuyHeartScene::buyHearts(int number) {
#if (CC_TARGET_PLATFORM == CC_PLATFORM_ANDROID)
    JniMethodInfo t;
    if (JniHelper::getStaticMethodInfo(t, "net/iwobi/game/flickworldcup/FlickWorldCupActivity",
                "onBuyHeartClick", "(I)V")) {
        t.env->CallStaticVoidMethod(t.classID, t.methodID, number);
        if (t.env->ExceptionOccurred()) {
            t.env->ExceptionDescribe();
            t.env->ExceptionClear();
            return;
        }
        t.env->DeleteLocalRef(t.classID);
    }
#endif
    }

该Java方法的实现如下(我这里有五种商品ONEHEART到FIVEHEART)：

    public static void onBuyHeartClick(int type) {
        String requestId;

        switch (type) {
            case 1:
                requestId = PurchasingManager.initiatePurchaseRequest(MySKU.ONEHEART.getSku());
                break;
            case 2:
                requestId = PurchasingManager.initiatePurchaseRequest(MySKU.TWOHEART.getSku());
                break;
            case 3:
                requestId = PurchasingManager.initiatePurchaseRequest(MySKU.THREEHEART.getSku());
                break;
            case 4:
                requestId = PurchasingManager.initiatePurchaseRequest(MySKU.FOURHEART.getSku());
                break;
            case 5:
                requestId = PurchasingManager.initiatePurchaseRequest(MySKU.FIVEHEART.getSku());
                break;
            default:
                requestId = PurchasingManager.initiatePurchaseRequest(MySKU.ONEHEART.getSku());
                break;
        }

        PurchaseData purchaseData = ((FlickWorldCupActivity)context).purchaseDataStorage
                .newPurchaseData(requestId);
        Log.i(TAG, "onBuyHeartClick: requestId (" + requestId
                + ") requestState (" + purchaseData.getRequestState() + ")");
    }

5、修改各种回调方法

将SampleIAPConsumablesApp/src/com/amazon/sample/iap/consumable /MainActivity.java中的onPurchase为前缀名的方法以及onGetUserIdResponseSuccessful挪到你的 Activity源文件中。这些方法绝大部分是不需要修改的，除非你不喜欢例子中日志输出的格式，或是想用toast之类的提示方式改造各种 callback的结果显示方式。

这里我主要修改了一个方法：onPurchaseResponseSuccess。该方法在购买成功后被调用，我们在这个事件发生时更新Scene或Layer的显示(updateHeartInScene)。

    @Override
    public void onPurchaseResponseSuccess(String userId, String sku,
            String purchaseToken) {
        Log.i(TAG, "onPurchaseResponseSuccess: for userId (" + userId
                + ") sku (" + sku + ")");
        SKUData skuData = purchaseDataStorage.getSKUData(sku);
        if (skuData == null)
            return;

        if (MySKU.ONEHEART.getSku().equals(skuData.getSKU())) {
            updateHeartInScene(1);
        }

        if (MySKU.TWOHEART.getSku().equals(skuData.getSKU())) {
            updateHeartInScene(2);
        }

        if (MySKU.THREEHEART.getSku().equals(skuData.getSKU())) {
            updateHeartInScene(3);
        }

        if (MySKU.FOURHEART.getSku().equals(skuData.getSKU())) {
            updateHeartInScene(4);
        }

        if (MySKU.FIVEHEART.getSku().equals(skuData.getSKU())) {
            updateHeartInScene(5);
        }
    }

6、AndroidManifest.xml和其他Java文件

AppPurchasingObserver.java和AppPurchasingObserverListener.java你可以原封不动的使用。MySKU.java可以根据你的内购项目做改造：

public enum MySKU {

    ONEHEART("net.iwobi.game.flickworldcup.iap.consumable.oneheart", 1),
    TWOHEART("net.iwobi.game.flickworldcup.iap.consumable.twoheart", 1),
    THREEHEART("net.iwobi.game.flickworldcup.iap.consumable.threeheart", 1),
    FOURHEART("net.iwobi.game.flickworldcup.iap.consumable.fourheart", 1),
    FIVEHEART("net.iwobi.game.flickworldcup.iap.consumable.fiveheart", 1);

    private String sku;
    private int quantity;

    private MySKU(String sku, int quantity) {
        this.sku = sku;
        this.quantity = quantity;
    }

    public static MySKU valueForSKU(String sku) {
        if (ONEHEART.getSku().equals(sku)) {
            return ONEHEART;
        }

        if (TWOHEART.getSku().equals(sku)) {
            return TWOHEART;
        }

        if (THREEHEART.getSku().equals(sku)) {
            return THREEHEART;
        }

        if (FOURHEART.getSku().equals(sku)) {
            return FOURHEART;
        }

        if (FIVEHEART.getSku().equals(sku)) {
            return FIVEHEART;
        }

        return null;
    }

    public String getSku() {
        return sku;
    }

    public int getQuantity() {
        return quantity;
    }

    private static Set SKUS = new HashSet();
    static {
        SKUS.add(ONEHEART.getSku());
        SKUS.add(TWOHEART.getSku());
        SKUS.add(THREEHEART.getSku());
        SKUS.add(FOURHEART.getSku());
        SKUS.add(FIVEHEART.getSku());
    }

    public static Set getAll() {
        return SKUS;
    }

}

AndroidManifest.xml中在application标签下添加如下配置：


                                    android:name="com.amazon.inapp.purchasing.NOTIFY"
                    android:permission="com.amazon.inapp.purchasing.Permission.NOTIFY" />


有了以上代码，我们的内购就可以运行起来了。

* 内购测试

使用Amazon In-app Purchasing API一个最大好处就是测试简单。Amazon提供一个本地测试程序Amazon App Tester（安装到Android模拟器中），可以模拟内购Server，SDK自动判断当前场景，如果是测试，你的集成了内购SDK的游戏将连接本地测试程序完成内购流程。通过在本地测试程序中设置模拟不同的内购流程，我们可以轻松完成测试。

你需要给Amazon App Tester提供一个名为amazon.sdktester.json的文件，这样Amazon App Tester可以知道你的游戏有哪些内购项目，并模拟出这些内购项目。这个json文件可以自行编辑，也可以在Amazon deveoper网站上生成下载。

我直接将内购项目添加到我的Amazon帐号的游戏应用下面，一共五个，添加成功后，下载json文件。将该文件放在模拟器的/mnt/sdcard下，绝对路径为/mnt/sdcard/amazon.sdktester.json。

之后，启动App Tester，再启动你的游戏，点击内购项目，看看是否能购买成功。

* 内购上线

按照Amazon官方说法，SDK会自动区分测试场景和正式场景，因此通过App Tester测试的游戏在发布后，理论上内购是没有问题的。不过我上线后还是遇到了问题，即点击购买某个项目后，游戏没有任何反应，等了若干分钟都是这样。我将这个问题反馈给Amazon Support，得到的答复居然是游戏代码没有问题，他们测试了若干中机型，都可以打开内购页面，并进行内购。只是有时内购页面打开有些延迟，但都能打开。看到这里，我猜是否又是大陆网络的问题呢！不管它了，至少通过Amazon Support的回复可以证明我的代码是ok的。只能希望美国人民多多购买我的内购项目了^_^。

* Amazon游戏圈

想给游戏增加成就榜和成就提交功能，如果自己实现服务端，显然麻烦，工作量大不说，还得维护一个Server。但市面上提供这类服务的游戏平台不多。 Google Play的游戏Service提供这种服务，不过还是上面提到的原因，我与Google的这个服务无缘啊。Amazon Game SDK后期推出了GameCircle服务。

GameCircle目前提供achievements, leaderboards和Whispersync三种特性：
    achievements就是奖励机制，帮助游戏提高玩家粘性。
    leaderboards类似于积分榜，可以用于提交玩家积分以及显示玩家的全球排名。
    Whispersync是一种数据游戏同步服务，同步玩家进度，保寸玩家个性化数据等。

这里我要用到的是leaderboards。

1、建立GameCircle
使用游戏圈前，你需要在Amazon官方的Amazon Apps & Services Developer Console下创建属于你的Game Circle，然后创建一个LeaderBoard，设置LeaderBoard属性。SDK中提供了GameCircle的Demo：AmazonSDK/Android/GameCircle。

2、导入jar包，设置AndroidManifest.xml
要想使用GameCircle，我们需要导入相应的SDK jar包：gamecirclesdk.jar。

在AndroidManifest.xml中，需要在application标签下添加以下配置：

                            android:name="com.amazon.ags.html5.overlay.GameCircleUserInterface"
            android:hardwareAccelerated="false"
            android:theme="@style/GCOverlay" >

                    android:name="com.amazon.identity.auth.device.authorization.AuthorizationActivity"
            android:allowTaskReparenting="true"
            android:launchMode="singleTask"
            android:theme="@android:style/Theme.NoDisplay" >

                                    android:host="net.iwobi.game.flickworldcup"
                    android:scheme="amzn" />


                    android:name="com.amazon.ags.html5.overlay.GameCircleAlertUserInterface"
            android:hardwareAccelerated="false"
            android:theme="@style/GCAlert" >

                    android:name="com.amazon.identity.auth.device.authorization.PackageIntentReceiver"
            android:enabled="true" >

        这些配置中需要的res，可以从AmazonSDK/Android/GameCircle/GameCircleSDK/res/中找到并copy到你的project中。

3、初始化GameCircle

GameCircleSDK这个Demo中没有提供太多源码，src目录下是空的。因此我们只能参考Amazon Developer站点上页面上的说明一步步的添加和调整我们的代码了。

在你的XXActivity类中，我们添加如下方法：

    //reference to the agsClient
    public AmazonGamesClient agsClient;

    AmazonGamesCallback callback = new AmazonGamesCallback() {
            @Override
            public void onServiceNotReady(AmazonGamesStatus status) {
                Message msg = new Message();
                switch (status) {
                // The SDK failed to initialize correctly.
                case CANNOT_INITIALIZE:
                    Log.i(TAG, "onServiceNotReady: CANNOT_INITIALIZE");
                    msg.obj = "Can not initialize Amazon Game Services";
                    break;

                // The SDK is in the process of initializing.
                case INITIALIZING:
                    Log.i(TAG, "onServiceNotReady: INITIALIZING");
                    msg.obj = "Initializing Amazon Game Services";
                    break;

                // The device not registered with an account
                case NOT_AUTHENTICATED:
                    Log.i(TAG, "onServiceNotReady: NOT_AUTHENTICATED");
                    msg.obj = "The Device does not registered with an account";
                    break;

                // The game is not authorized to use this service.
                case NOT_AUTHORIZED:
                    Log.i(TAG, "onServiceNotReady: NOT_AUTHORIZED");
                    msg.obj = "Not authorized to use Amazon Game Services";
                    break;
                }

                //unable to use service
                msg.what = 21;
                notifyHandler.sendMessage(msg);
            }
            @Override
            public void onServiceReady(AmazonGamesClient amazonGamesClient) {
                agsClient = amazonGamesClient;

                //ready to use GameCircle
                if (agsClient != null)
                    Log.i(TAG, "on AmazonGamesCallback: call onServiceReady, agsClient init ok");
                else
                    Log.i(TAG, "on AmazonGamesCallback: call onServiceReady, agsClient init failed");
            }
    };

    //list of features your game uses (in this example, achievements and leaderboards)
    EnumSet myGameFeatures = EnumSet.of(
            AmazonGamesFeature.Leaderboards);

    protected void onResume() {
        super.onResume();

        … …
        AmazonGamesClient.initialize(this, callback, myGameFeatures);
    }

      public void onPause() {
        super.onPause();
        if (agsClient != null) {
            agsClient.release();
        }
    }

    4、提交成就积分

当玩家结束游戏时，可以选择将此次的高分上传到leaderboards上。游戏中应对积分提交的代码也在XXActivity中。

    public static void onSubmitScoreToLeaderBoard(int score) {
        if (((FlickWorldCupActivity)context).agsClient == null) {
            Message msg = new Message();
            msg.what = 21;
            msg.obj = "Unable to use Amazon Game Services";
            notifyHandler.sendMessage(msg);
            return;
        }

        LeaderboardsClient lbClient = ((FlickWorldCupActivity)context).agsClient.getLeaderboardsClient();
        AGResponseHandle handle = lbClient.submitScore("FlickWorldCupTopScore", score);

        // Optional callback to receive notification of success/failure.
        handle.setCallback(new AGResponseCallback() {

            @Override
            public void onComplete(SubmitScoreResponse result) {
                if (result.isError()) {
                    // Add optional error handling here. Not strictly required
                    // since retries and on-device request caching are automatic.
                    Message msg = new Message();
                    msg.what = 22;
                    msg.obj = "Submit Score to LeaderBoard Failed!";
                    notifyHandler.sendMessage(msg);
                } else {
                    // Continue game flow.
                    Message msg = new Message();
                    msg.what = 23;
                    msg.obj = "Submit Score to LeaderBoard OK!";
                    notifyHandler.sendMessage(msg);
                }
            }
        });
    }

如果仅是查看积分排行，可以用下面这个方法：

    public static void onShowLeaderBoardOverlay() {
        if (((FlickWorldCupActivity)context).agsClient == null) {
            Message msg = new Message();
            msg.what = 21;
            msg.obj = "Unable to use Amazon Game Services";
            notifyHandler.sendMessage(msg);
            return;
        }

        LeaderboardsClient lbClient = ((FlickWorldCupActivity)context).agsClient.getLeaderboardsClient();
        AGResponseHandle handle = lbClient.showLeaderboardOverlay("FlickWorldCupTopScore");

        handle.setCallback(new AGResponseCallback() {

            @Override
            public void onComplete(RequestResponse result) {
                if (result.isError()) {
                    // Add optional error handling here. Not strictly required
                    // since retries and on-device request caching are automatic.
                    Log.i(TAG, "onShowLeaderBoardOverlay – onComplete: Show LeaderBoard Request Failed!");
                }
            }
        });
    }

* 游戏圈上线

游戏圈无法在本地进行测试，只能在真实的游戏圈中测试代码是否ok。不过Amazon的游戏圈提供了管理功能，在测试后发布前可将游戏圈 leaderboard的值reset。游戏圈leaderboard发布后，你就可以使用leaderboard了。游戏圈功能在国内访问是没有任何问题的，查看积分榜，提交分数到积分榜都很顺畅。

* 小结

Amazon游戏SDK在国内的应用估计比较小众，大家可能更多的选择用Google Play提供的服务或是AppStore的，但Amazon毕竟为游戏开发者提供了一个选择（而且是完全免费的哦），另外Amazon的Support对提交问题的反馈较为及时(无论是mail还是forum上的提问)，基本24小时内就会有答复。各种设施的发布也比较快，有时候3-4个小时即可生效。

目前Amazon Game SDK的资料多为英文，且集中在Amazon官方站点以及官方维护的support论坛中。遇到问题，亚马逊的论坛是第一选择。

Cocos2d-x屏幕适配之Sprite绘制原理

bigwhite — Mon, 12 May 2014 17:04:14 +0000

手机(智能终端)游戏绝大多数为全屏(Full Screen)显示，这样开发人员在制作游戏时势必要考虑不同手机(智能终端）屏幕大小、宽高比的不同给游戏画面带来的影响，并且要将这种影响降低到最小，努力使用不同终端的游戏玩家拥有几乎相同的游戏画面体验。为此各种游戏引擎在屏幕适配方面都给出了自己的方案，Cocos2d-x也不例外。在Cocos2d-x官网Wiki上特地撰写了一篇讲解Cocos2d-x多屏幕适配原理的文章“Detailed explanation of Cocos2d-x Multi-resolution adaptation”。

这里我们以Cocos2d-x引擎（基于2.2.2版本）自带的Sample项目HelloCpp(cocos2d-x-2.2.2/samples/Cpp/HelloCpp）为例，直观的看看这个方案带来的好处。首先，我们对HelloCpp项目做些许改造：
    – 注释掉AppDelegate.cpp中applicationDidFinishLaunching下的pEGLView->setDesignResolutionSize(designResolutionSize.width, designResolutionSize.height, kResolutionNoBorder);
    – 仅使用Resource/iphone下的资源，即仅searchPath.push_back(smallResource.directory)；这里我们有一张480×320分辨率大小PNG文件。
    – 通过改变proj.linux/main.cpp中的eglView->setFrameSize(960, 640);来改变屏幕参数。（用linux工程模拟甚为方便，编译和运行占用资源小，极为迅捷，效果与Android平台是等效的）

我们对比一下以下三种条件下的游戏Demo显示结果：
    1) 屏幕大小480×320，未做任何屏幕适配工作，不调用pEGLView->setDesignResolutionSize。
    2) 屏幕大小960×640，未做任何屏幕适配工作，不调用pEGLView->setDesignResolutionSize。
    3) 屏幕大小同为960×640，按照上面Cocos2d-x屏幕适配指南Wiki中的做法，调用pEGLView->setDesignResolutionSize(480, 320);

如我们所料，我们得到三个截然不同的结果。

第一种情况，我们所得到的游戏屏幕截图如下：

第二种情况，我们所得到的游戏屏幕截图如下：

第三种情况，我们所得到的游戏屏幕截图如下：

第一种情况是最理想的情况，屏幕大小与背景图片大小相同，如我们所愿，屏幕与背景图片吻合的天衣无缝。
第二种情况显然是模拟我们初次遇到问题的场景。屏幕Size扩大为原先的二倍，在资源没有变化的情况下，我们发现480×320大小的背景图片没有铺满屏幕，仅仅是居中显示，并在四周露出较多”黑边“，这显然不是我们想要的。
第三种情况，也就是我们按照官方屏幕适配方案调整后得到的结果，在资源依旧不变的情况下，我们得到了相对令人满意的结果：背景图片恰如其分的铺满整个屏幕，比例正确。这样我们用一套资源就可以同时适配两个屏幕了：480×320、960×640。这两种终端的玩家至少不会对我们的游戏心生抱怨之情^_^。

当然在遇到第二种情况的时候，你也大可再准备一套新资源，比如一张960×640的背景图片。在480×320手机上，使用480×320的图片；在960×640的手机上，使用960×640的背景图片。但这种方法的弊端至少有三：
    – 包大了：游戏的安装包Size急剧变大。
    – 活儿多了：因适配屏幕种类太多而制作大量的图片。
    – 新屏幕出来咋办：如果某个厂家突然于某天出品一款手机，其分辨率与以往市面上的所有手机均不同，那你的游戏因没有对应的资源，肯定无法很好适配该手机，导致较差用户体验。

为此，适配屏幕唯一的出路似乎只有按照官方推荐的方案进行了，当然适当结合有限种类的资源也许可以更好的提升游戏体验。

如果仅仅从游戏制作角度来看，我们找到了可以适配屏幕的方法就可以了，没有必要刨根问底。甚至当有人问起来：为何 setDesignResolutionSize后，背景图片就可以充满屏幕了呢？我们可以回答：“引擎对精灵进行了缩放，就是这样”。但对于上面的背景精灵来说，真的是我们理解的普通意义上的“精灵缩放(Scale)吗？本着“知其然，也要知其所以然”的精神，这里对引擎如何对 Sprite进行绘制进行了一番研究，我还真发现了一些与我之前理解差异较大的“深奥”原理，这里与大家一起分享一下。

一、绘制参数初始化

我们还是从代码开始，了解一下引擎绘制参数的初始化工作是如何做的、在哪里做的，为后续的分析做些铺垫。这里以Cocos2d-x 2.2.2 Android平台为例。关于Cocos2d-x 2.2.2 Android平台的引擎粗线条启动流程分析，可以参考《Hello，Cocos2d-x》这篇文章。看完这篇文章，你就会知道我们这次应该从Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeInit开始。

// samples/Cpp/HelloCpp/proj.android/jni/hellocpp/main.cpp
void Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeInit(
               JNIEnv* env, jobject thiz, jint w, jint h)
{
    if (!CCDirector::sharedDirector()->getOpenGLView())
    {
        CCEGLView *view = CCEGLView::sharedOpenGLView();
        view->setFrameSize(w, h);

        AppDelegate *pAppDelegate = new AppDelegate();
        CCApplication::sharedApplication()->run();
    }
    … …
}

这里是引擎部分初始化的起点:CCDirector和CCEGLView先后完成创建与初始化。接下来我们分别看一下这两个过程，我们主要关注与绘制参数设置相关的内容：

bool CCDirector::init(void)
{
setDefaultValues();

… …
m_obWinSizeInPoints = CCSizeZero;

m_pobOpenGLView = NULL;

    m_fContentScaleFactor = 1.0f;
    … …
    return true;
}

void CCDirector::setDefaultValues(void)
{
    CCConfiguration *conf =
     CCConfiguration::sharedConfiguration();
    … …
    // GL projection
    const char *projection =
        conf->getCString("cocos2d.x.gl.projection",
   "3d");
    if( strcmp(projection, "3d") == 0 )
        m_eProjection = kCCDirectorProjection3D;
    … …
}

由于conf中没有配置“cocos2d.x.gl.projection”，因此projection使用了 getCString传入的默认值："3d"，m_eProjection则被赋值为kCCDirectorProjection3D。

CCEGLView的创建更为简单：

CCEGLView::CCEGLView()
{
initExtensions();
}

但背后真正发挥关键作用的是其父类CCEGLViewProtocol。

CCEGLViewProtocol::CCEGLViewProtocol()
: m_pDelegate(NULL)
, m_fScaleX(1.0f)
, m_fScaleY(1.0f)
, m_eResolutionPolicy(kResolutionUnKnown)
{
}

这里我们看到了三个重要的字段：m_fScaleX、m_fScaleY以及m_eResolutionPolicy，这三个字段对于后续屏幕适配起到至关重要的作用。

nativeInit中的view->SetFrameSize(w, h)用于设置的屏幕物理分辨率，如果你的手机是960×640分辨率的，那FrameSize就是960×640。

void CCEGLViewProtocol::setFrameSize(float width,
                                     float height)
{
    m_obDesignResolutionSize
      = m_obScreenSize
      = CCSizeMake(width, height);
}
初始情况下，CCEGLViewProtocol将“设计分辨率”m_obDesignResolutionSize也设置为与 FrameSize or m_obScreenSize同等大小。

我们回到游戏逻辑层代码AppDelegate.cpp，我们知道游戏逻辑的入口在这里，最初的参数初始化是在为Director设置 GLView实例时进行的：

bool AppDelegate::applicationDidFinishLaunching() {
    // initialize director
    CCDirector* pDirector = CCDirector::sharedDirector();
    CCEGLView* pEGLView = CCEGLView::sharedOpenGLView();

    pDirector->setOpenGLView(pEGLView);
    CCSize frameSize = pEGLView->getFrameSize();
    … …
}

void CCDirector::setOpenGLView(CCEGLView *pobOpenGLView)
{
m_pobOpenGLView = pobOpenGLView;

        // set size
        m_obWinSizeInPoints =
           m_pobOpenGLView->getDesignResolutionSize();
        … …

        if (m_pobOpenGLView)
        {
            setGLDefaultValues();
        }

        CHECK_GL_ERROR_DEBUG();
        … …
    }
}

由于尚未调用setDesignResolutionSize，因此m_obWinSizeInPoints的值与FrameSize大小相同。

setGLDefaultValues最为关键，这是我们第一次遇到该函数，该方法用于初始化一些OpenGL的参数，建立好后续 OpenGL操作时所需要的各种数据结构。

void CCDirector::setGLDefaultValues(void)
{
    … …
    setAlphaBlending(true);
    setDepthTest(false);
    setProjection(m_eProjection);
    // set other opengl default values
    glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
}

glClearColor(0.0f, 0.0f, 0.0f, 1.0f);设置初始颜色为黑色，alpha为1.0f，即完全不透明。setProjection是实际上绘制参数设置的核心。

void CCDirector::setProjection(ccDirectorProjection kProjection)
{
CCSize size = m_obWinSizeInPoints;

    setViewport();

    switch (kProjection)
    {
    case kCCDirectorProjection3D:
        {
            float zeye = this->getZEye();

kmMat4 matrixPerspective, matrixLookup;

kmGLMatrixMode(KM_GL_PROJECTION);
kmGLLoadIdentity();

… …

            // issue #1334
            kmMat4PerspectiveProjection( &matrixPerspective,
   60,
                  (GLfloat)size.width/size.height,
   0.1f, zeye*2);

kmGLMultMatrix(&matrixPerspective);

            kmGLMatrixMode(KM_GL_MODELVIEW);
            kmGLLoadIdentity();
            kmVec3 eye, center, up;
            kmVec3Fill( &eye, size.width/2,
                   size.height/2, zeye );
            kmVec3Fill( ¢er, size.width/2,
                   size.height/2, 0.0f );
            kmVec3Fill( &up, 0.0f, 1.0f, 0.0f);
            kmMat4LookAt(&matrixLookup, &eye,
                         ¢er, &up);
            kmGLMultMatrix(&matrixLookup);
        }
        break;
        … …
    }

m_eProjection = kProjection;
ccSetProjectionMatrixDirty();
}

由于前面m_eProjection已经被赋值为kCCDirectorProjection3D，因此我们只分析 kCCDirectorProjection3D这个case分支。该函数大致进行设置的顺序是：设置视口变换（ViewPort)、设置投影变换矩阵和设置模型视图变换矩阵。我们分别来看：

* 设置视口(ViewPort)

void CCDirector::setViewport()
{
    if (m_pobOpenGLView)
    {
        m_pobOpenGLView->setViewPortInPoints(0, 0,
              m_obWinSizeInPoints.width,
              m_obWinSizeInPoints.height);
    }
}

void CCEGLViewProtocol::setViewPortInPoints(float x ,
   float y , float w , float h)
{
    glViewport((GLint)(x * m_fScaleX
               + m_obViewPortRect.origin.x),
               (GLint)(y * m_fScaleY
               + m_obViewPortRect.origin.y),
               (GLsizei)(w * m_fScaleX),
               (GLsizei)(h * m_fScaleY));
}

这是我们遇到的第一个OpenGL概念：设置视口变换，关于视口变换究竟起到什么作用，后续会细说。

* 设置“投影变换”矩阵参数

kmMat4PerspectiveProjection( &matrixPerspective, 60,
(GLfloat)size.width/size.height, 0.1f, zeye*2);
kmGLMultMatrix(&matrixPerspective);

* 设置“模型视图变换”矩阵参数

kmVec3 eye, center, up;
kmVec3Fill( &eye, size.width/2,
             size.height/2, zeye );
kmVec3Fill( ¢er, size.width/2,
             size.height/2, 0.0f );
kmVec3Fill( &up, 0.0f, 1.0f, 0.0f);
kmMat4LookAt(&matrixLookup, &eye,
             ¢er, &up);

至此，引擎的绘制参数初始化设置就OK了，在你调用setDesignResolutionSize之前，这些参数不会被改变。

二、kazmath

Cocos2d-x引擎最底层采用OpenGL ES 2.0进行图形绘制，这样要想搞清楚前面的问题缘由，对OpenGL那一套技术体系至少要有一些直观认识才行。在这之前，我们还要先了解一些 Cocos2d-x深度使用的kazmath库。根据《Cocos2d-x高级开发教程》书中说: “因为在Cocos2d-x 2.0采用的OpenGL ES 2.0中，而那些OpenGL ES 1.0函数已经不可使用了。但OpenGL ES 2.0已经放弃了固定的渲染流水线，取而代之的是自定义的各种着色器，在这种情况下变换操作通常需要由开发者来维护。所幸引擎也引入了一套第三方库 Kazmath，它使得我们几乎可以按照原来OpenGL ES 1.0所采用的方式进行开发”。

至此，我们大致知道了Kazmath库是用来辅助我们按照OpenGL ES 1.0的方式管理变换矩阵以及做变换操作的，接下来我们一起来看看kazmath库的结构吧：

//cocos2d-x-2.2.2/cocos2dx/kazmath/src/GL/matrix.c

km_mat4_stack modelview_matrix_stack;
km_mat4_stack projection_matrix_stack;
km_mat4_stack texture_matrix_stack;
km_mat4_stack* current_stack = NULL;
static unsigned char initialized = 0;

以上是Cocos2d-x整个引擎生命周期内会用到的与opengl变换矩阵相关的一些全局变量。

kazmath声明了三个变换矩阵的栈，modelview_matrix_stack（模型视图矩阵栈）、 projection_matrix_stack（投影矩阵栈）以及texture_matrix_stack（纹理矩阵栈）。不过Cocos2d-x引擎只用到了前两个变化矩阵栈。current_stack指向当前所使用的那个变换矩阵栈。

这些栈的初始化在lazyInitialize中：

void lazyInitialize()
{

if (!initialized) {
kmMat4 identity; //Temporary identity matrix

        //Initialize all 3 stacks
        //modelview_matrix_stack =
            (km_mat4_stack*) malloc(sizeof(km_mat4_stack));
        km_mat4_stack_initialize(&modelview_matrix_stack);

        //projection_matrix_stack =
            (km_mat4_stack*) malloc(sizeof(km_mat4_stack));
        km_mat4_stack_initialize(&projection_matrix_stack);

        //texture_matrix_stack =
            (km_mat4_stack*) malloc(sizeof(km_mat4_stack));
        km_mat4_stack_initialize(&texture_matrix_stack);

current_stack = &modelview_matrix_stack;
initialized = 1;

kmMat4Identity(&identity);

        //Make sure that each stack has the identity matrix
        km_mat4_stack_push(&modelview_matrix_stack, &identity);
        km_mat4_stack_push(&projection_matrix_stack, &identity);
        km_mat4_stack_push(&texture_matrix_stack, &identity);
    }
}

kmMat4Identify用于初始化“单位矩阵(Indentify Matrix)”，所谓"单位矩阵"，指的是对脚线上元素都为1的矩阵。从kmMat4Identify的实现，我们也可以看出这一点：

kmMat4* const kmMat4Identity(kmMat4* pOut)
{
    memset(pOut->mat, 0, sizeof(float) * 16);
    pOut->mat[0] = pOut->mat[5]
   = pOut->mat[10]
     = pOut->mat[15] = 1.0f;
    return pOut;
}

最后，lazyInitialize函数将单位矩阵分别圧入（km_mat4_stack_push）不同的matrix stack。

再回顾一下CCDirector::setProjection，该函数通过kazmath先后设置了 projection_matrix_stack和modelview_matrix_stack的top元素。

   kmGLMatrixMode(KM_GL_PROJECTION);
   kmGLLoadIdentity();
   kmMat4PerspectiveProjection( &matrixPerspective, 60,
     (GLfloat)size.width/size.height, 0.1f, zeye*2);
   kmGLMultMatrix(&matrixPerspective);

   kmGLMatrixMode(KM_GL_MODELVIEW);
   kmGLLoadIdentity();
   kmVec3 eye, center, up;
   kmVec3Fill( &eye, size.width/2,
               size.height/2, zeye );
   kmVec3Fill( ¢er, size.width/2,
               size.height/2, 0.0f );
   kmVec3Fill( &up, 0.0f, 1.0f, 0.0f);
   kmMat4LookAt(&matrixLookup, &eye,
               ¢er, &up);
   kmGLMultMatrix(&matrixLookup);

三、精灵绘制

由《Hello，Cocos2d-x》一文我们知道，一旦引擎初始化完毕，就开始了每帧图像的绘制工作，Render Thread在一个“死循环”中反复调用CCDirector的drawScene方法（CCDisplayLinkDirector::mainLoop中调用了drawScene）：

void CCDirector::drawScene(void)
{
    … …
    glClear(GL_COLOR_BUFFER_BIT
           | GL_DEPTH_BUFFER_BIT);
    … …
    kmGLPushMatrix();

    // draw the scene
    if (m_pRunningScene)
    {
        m_pRunningScene->visit();
    }
    … …
    kmGLPopMatrix();
    … …
}

Cocos2d-x采用“渲染树”的方式进行绘制，即先从场景(Scene)的顶层根节点开始，深度优先的递归绘制Child Node。而整个绘制的顶层节点是CCScene。绘制从m_pRunningScene->visit()真正开始。visit是Scene、 Layer、Sprite的共同父类CCNode实现的方法：

void CCNode::visit()
{
    if (!m_bVisible)
    {
        return;
    }
    kmGLPushMatrix();
    … …
    this->transform();
    … …

    if(m_pChildren &&
       m_pChildren->count() > 0)
    {
        sortAllChildren();
        // draw children zOrder < 0
        … ..
        // self draw
        this->draw();

        // draw other children nodes
        … …
    } else {
        this->draw();
    }
    … …
    kmGLPopMatrix();
}

Visit大致做了这么几件事：
    – 向当前OpenGL变换矩阵栈Push元素
    – 用当前OpenGL变换矩阵栈栈顶元素的变换参数做节点变换
    – 递归绘制zOrder < 0 的子节点
    – 绘制自己
    – 递归绘制其他子节点
    – 从当前OpenGL变换矩阵栈Pop元素

如果你想知道为什么父节点缩放(Scale)、旋转(Rotate)、扭曲(Skew)后，子节点也会跟着父节点同样缩放(Scale)、旋转(Rotate)、扭曲？其原理就在这里的transform方法中：

void CCNode::transform()
{
kmMat4 transfrom4x4;

    // Convert 3×3 into 4×4 matrix
    CCAffineTransform tmpAffine
       = this->nodeToParentTransform();
    CGAffineToGL(&tmpAffine,
   transfrom4x4.mat);

// Update Z vertex manually
transfrom4x4.mat[14] = m_fVertexZ;

kmGLMultMatrix( &transfrom4x4 );
… …
}

在进入tranform以前，Cocos2d-x做了啥？对了，kmGLPushMatrix()：

void kmGLPushMatrix(void)
{
kmMat4 top;

lazyInitialize();

    //Duplicate the top of the stack (i.e the current matrix)
    kmMat4Assign(&top, current_stack->top);
    km_mat4_stack_push(current_stack, &top);
}

在引擎初始化后，我们的current_stack是模型视图矩阵栈modelview_matrix_stack。所有设置的初始参数都保存在该栈的栈顶元素中。在每次Node绘制前，Node都会创建自己的变换矩阵，但这个矩阵不是凭空创造的，从kmGLPushMatrix 可以看出，在当前Node将新创建的矩阵元素圧栈前，它复制了原栈顶元素，也就携带有父节点所有的初始变换信息，也就是说在 km_mat4_stack_push后，栈顶放置的元素其实是原栈顶元素的复制品，而后续所有操作都是基于这个复制品的。这样一来，如果父节点做了缩放或旋转或扭曲，那这些信息都会作为初始信息作为子节点变换的基础，后续子节点自身的变换参数也都是在这个基础上做出的，最终的矩阵是transform方法中的kmGLMultMatrix后得出的。真正的矩阵变换计算都在nodeToParentTransform 中，不过要想看懂这个函数，需要对OpenGL有更深入的了解才行，这里略过^_^。

真正绘制Node的方法是CCNode::draw的override方法。CCNode::draw是一个空函数，各个子类 override该方法进行各自的绘制。以CCSprite::draw为例：

void CCSprite::draw(void)
{
CC_NODE_DRAW_SETUP();

ccGLBlendFunc( m_sBlendFunc.src, m_sBlendFunc.dst );

ccGLBindTexture2D( m_pobTexture->getName() );
ccGLEnableVertexAttribs( kCCVertexAttribFlag_PosColorTex );

#define kQuadSize sizeof(m_sQuad.bl)
long offset = (long)&m_sQuad;

    // vertex
    int diff = offsetof( ccV3F_C4B_T2F, vertices);
    glVertexAttribPointer(kCCVertexAttrib_Position, 3,
     GL_FLOAT, GL_FALSE, kQuadSize, (void*) (offset + diff));

    // texCoods
    diff = offsetof( ccV3F_C4B_T2F, texCoords);
    glVertexAttribPointer(kCCVertexAttrib_TexCoords, 2,
GL_FLOAT, GL_FALSE, kQuadSize, (void*)(offset + diff));

    // color
    diff = offsetof( ccV3F_C4B_T2F, colors);
    glVertexAttribPointer(kCCVertexAttrib_Color, 4,
           GL_UNSIGNED_BYTE, GL_TRUE,
           kQuadSize, (void*)(offset + diff));

glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
… …
}

这里的draw是一个典型的OpenGL绘制工序。CC_NODE_DRAW_SETUP()将之前的经过若干准备而得到的最终各类变换矩阵整合并传给OpenGL：

/** @def CC_NODE_DRAW_SETUP
Helpful macro that setups the GL server state,
the correct GL program and sets the Model View
Projection matrix
@since v2.0
*/
#define CC_NODE_DRAW_SETUP() \
do { \
    ccGLEnable(m_eGLServerState); \
    CCAssert(getShaderProgram(), "No shader program set for this node"); \
    { \
        getShaderProgram()->use(); \
        getShaderProgram()->setUniformsForBuiltins(); \
    } \
} while(0)

void CCGLProgram::setUniformsForBuiltins()
{
    kmMat4 matrixP;
    kmMat4 matrixMV;
    kmMat4 matrixMVP;

kmGLGetMatrix(KM_GL_PROJECTION, &matrixP);
kmGLGetMatrix(KM_GL_MODELVIEW, &matrixMV);

kmMat4Multiply(&matrixMVP, &matrixP, &matrixMV);

    setUniformLocationWithMatrix4fv(m_uUniforms[kCCUniformPMatrix],
matrixP.mat, 1);
    setUniformLocationWithMatrix4fv(m_uUniforms[kCCUniformMVMatrix],
matrixMV.mat, 1);
    setUniformLocationWithMatrix4fv(m_uUniforms[kCCUniformMVPMatrix],
matrixMVP.mat, 1);
    … …
}

经过计算顶点、绑定纹理等步骤后，最终由glDrawArrays完成Node绘制。

四、m_fScaleX和m_fScaleY都是1.0，背景精灵为何被放大？

根据上面的分析，我们了解到“子节点将跟随父节点的缩放而缩放”。据此，我们来分析一下前面提到的屏幕适配例子中的第三种情况，即屏幕大小为 960×640，按照Cocos2d-x屏幕适配指南Wiki中的做法，调用 pEGLView->setDesignResolutionSize(480, 320)。在该情况中，我们得到的结果是480×320大小的背景图片充满了大小为960×640的屏幕窗口，这给我们的直观印象就是背景图片被放大了一倍。下面我们就尝试用上面的分析来解释一下这个现象。

在这个例子中，渲染树结构如下：
   CCScene
        – CCLayer
            – CCSprite – 背景图精灵

按照之前的理论，背景图精灵自身或父类应该有缩放的设置，比如m_fScaleX = 2.0之类的设置，于是我在代码中输出了Scene、Layer以及Sprite的m_fScaleX和m_fScaleY值。但出乎预料的是，这些 Node子类的两个轴向缩放值都保持了默认值，即1.0f。在代码里翻了半天，也的确没有找到改写Scene、Layer或Sprite Scale的地方。又一想：代码中调用了setDesignResolutionSize，这样CCEGLView的m_fScaleX = m_fScaleY = 2.0f，难道是CCEGLView的m_fScale传递给了CCScene等Node子类，但事实总是残酷的，代表这一联系的代码也始终未被我所找到，看来继续纠结m_fScale的值设置是无法搞清楚真正原因，应该换换思路了。这里背景图的放大不应该是Node scale值设置的问题，也就是说关键环节不应该在绘制流程，而是在之前的OpenGL变换矩阵参数设置，看来不再深入学习点OpenGL知识，这个问题就很难搞定了，于是开始翻看《OpenGL编程指南7th》（号称OpenGL红宝书）和《OpenGL超级宝典》（号称OpenGL蓝宝书）。虽然我的阅读是粗粒度的，但还是收获到了一些答案。

五、OpenGL基础

OpenGL是帮助我们将三维世界的物体转换到二维屏幕上的一组接口。在新技术尚未出现之前，我们的屏幕永远是二维的，即便是现在的3D电影也是双眼视角二维图像叠加的结果。我们知道“将大象装进冰箱总共分三步”，将一个三维模型转换到二维屏幕上，OpenGL也规定了相对流水线般的步骤。

OpenGL三维图形的显示流程

三维图形显示流程中，涉及到OpenGL的一个重要操作，那就是“变换(Transformation)”，主要的变换包括模型视图变换（model-view transformation）、投影变换(projection transformation)以及视口变换(ViewPort transformation)。我们经常用相机模拟来对比OpenGL解决这一问题的过程以及相关概念。

回顾一下我们自己用相机拍照的步骤吧。

第零步，选景。景就是所谓的三维模型或三维物体，或简称模型(Model)，就是我们要显示到屏幕上的物体；
第一步，确定相机位置。让相机以一定的距离、高度、角度对准模型。在这里，相机的位置变换，对应OpenGL的“视图变换或叫视点变换 (View Transformation)”。在这一步里（对应上面图中的第二步），我们还可以调整三维物体的相对位置、角度与相机的距离，这就是模型变换（Modeling Transformation），两种变换达成的效果是相同的，因此总称模型视图变换(Model-View Transformation)。
第二步，选镜头，并调焦。确定图像投影在胶片上的范围以及景深等。这一步叫投影变换（Projection Transformation）。
第三步，冲洗照片。拍摄好的图像放在底片上，但我们需要选择冲洗后最终是放在6寸相纸还是20寸相纸上，显然在不同大小相纸上，图像的显示效果不同（比如大小）。这个过程叫视口变换（Viewport Transformation）。

三维空间的物体都是用三维坐标描述的，谈到坐标就离不开坐标系，OpenGL中的坐标系就有多种，我们最常用的就是世界坐标系。

世界坐标系是以屏幕中心为原点(0, 0, 0)，你面对屏幕，你的右边是x正轴，上面是y正轴，屏幕指向你的为z正轴。无论如何变换，世界坐标系都不动。我们在Cocos2d-x中设置初始参数时，参数的单位多为世界坐标系中的单位。

视点变换时会涉及到视点坐标系，但这个变换由opengl接口来负责，我们不用过多关心。

绘图坐标系（局部坐标系），当前绘图坐标系是绘制物体时的坐标系。程序刚初始化时，世界坐标系和当前绘图坐标系是重合的，当用 glTranslatef()等变换函数做移动和旋转时，都是改变的当前绘图坐标系，改变的位置都是当前绘图坐标系相对自己的x,y,z轴所做的改变，改变以后，再绘图时，都是在当前绘图坐标系进行绘图，所有的函数参数也都是相对当前绘图坐标系来讲的。

屏幕坐标系，即终端屏幕上的坐标系，与世界坐标系有不同，它以屏幕左上角的点为原点，向右是x正轴，向下是y正轴，屏幕指向你的为z正轴。

注意视口(Viewport)的设置是以实际屏幕坐标定义了窗口中的区域，长度宽度都是以实际像素为单位。当然引擎在精灵绘图时用的是绘图坐标系，我们理解原点在左下角即可。

六、Cocos2d-x各种变换矩阵的初始参数设置

前面说过，Cocos2d-x在CCDirector::setProjection中完成了对变换矩阵的初始参数设置，我们逐一来看看这些设置对模型映射后的二维图像有何影响，这也是理解篇头几个问题的关键环节。

* 投影变换

前面提到过，投影变换相当于调节相机镜头。OpenGL中提供了两种投影方式，一种是正射投影，另一种是透视投影。Cocos2d-x使用的是透视投影（Perspective Projection)。透视投影是实际人们观察事物的真实反馈，即离视点近的物体大，离视点远的物体小，远到极点即为消失，成为灭点。Cocos2d- x使用的是kmMat4PerspectiveProjection，对应OpenGL中的gluPerspective，该方法创建一个对称透视视景体 (View Volumn)，见下图：

gluPerspective的函数原型如下：void gluPerspective(GLdouble fovy,GLdouble aspect,GLdouble zNear, GLdouble zFar);

    参数fovy定义视野在X-Z平面的角度，范围是[0.0, 180.0]，也就是上图中的“视角”；
    参数aspect是投影平面宽度与高度的比率；
    参数zNear和Far分别是近远裁剪面沿Z负轴到视点的距离，它们总为正值。

Cocos2d-x中是这么设置投影变换矩阵的：

float zeye = this->getZEye();
kmMat4PerspectiveProjection( &matrixPerspective, 60, (GLfloat)size.width/size.height, 0.1f, zeye*2);

float CCDirector::getZEye(void)
{
return (m_obWinSizeInPoints.height / 1.1566f);
}

从参数上来看，
    视角 = 60度
    宽高比 = 设计分辨率的宽高比，
    近平面 = 距离视点0.1f，几乎与视点重合
    远平面 = 距离视点zeye * 2距离。
    视点位置 = 设计分辨率.height / 1.1566f

投影是用来对模型进行截取的，只有在投影变换所建立的平头截体（Frustum，投影的近、远两个截面以及其他四个面构成的立体体）内的模型部分才会被最终映射和显示。我们用下面的图来直观了解一下各个参数在三维空间的概念吧。

显然引擎如此设置投影矩阵的参数是有考虑的：
首先就是投影平头截体的宽高比 = 设计分辨率的宽高比，这样设置使得一切符合设计分辨率宽高比的模型都可以被理想截取。
其次，视角60度，zEye的在Z轴正方向距离世界原点的距离 = (m_obWinSizeInPoints.height / 1.1566f),这里的1.1566f是怎么来的呢？我们沿着X轴负方向向zy平面投影，得到下图：

看这个图，让我想起了初中几何，通过60度的视角，我们可以推断由eye、XZ截断上平面与Y轴的交点、XZ截断下平面与Y轴的交点组成一个等边三角形，现在我们已知在Zy平面投影中视点与原点的距离为m_obWinSizeInPoints.height / 1.1566f, 我们还知道夹角是60度，我们求一下投影在(z=0，XY平面)的截面高度h。

cos30 = (m_obWinSizeInPoints.height / 1.1566f)/ h
h = (m_obWinSizeInPoints.height / 1.1566f)/cos30 = m_obWinSizeInPoints.height;

我们计算出来的结果是 h = m_obWinSizeInPoints.height = 设计分辨率中的高度分量。这意味这什么呢？Cocos2d-x是2D游戏渲染引擎，针对该引擎的模型的z坐标都是0，因此模型实际上就在xy平面内，也就是说eye与原点的距离恰好就是eye与模型的距离，而模型可显示区域的最大高度也就是h，即m_obWinSizeInPoints.height。这个结论会在后续问题分析时发挥作用。

注意虽然这里知道eye在Z轴正方向距离世界原点的距离，但eye的(x, y)坐标在投影设置后依旧无法确认，我们需要在设置模型视图变换时得到eye的(x, y)坐标。

* 视图变换

    kmGLMatrixMode(KM_GL_MODELVIEW);
    kmGLLoadIdentity();
    kmVec3 eye, center, up;
    kmVec3Fill( &eye, size.width/2, size.height/2, zeye );
    kmVec3Fill( ¢er, size.width/2, size.height/2, 0.0f );
    kmVec3Fill( &up, 0.0f, 1.0f, 0.0f);
    kmMat4LookAt(&matrixLookup, &eye, ¢er, &up);
    kmGLMultMatrix(&matrixLookup);

OpenGL原生的视图变换参数设置方法是gluLookAt，在kazmath中对应的方法为kmMat4LookAt。gluLookAt的函数原型是：

    void gluLookAt(GLdouble eyex, GLdouble exey, GLdouble eyez,
       GLdouble centrex, GLdouble centrey, GLdouble centrez,
       GLdouble upx, GLdouble upy, GLdouble upz);

eye的坐标(eyex, eyey, eyez), Cocos2d-x中是这么设置的kmVec3Fill( &eye, size.width/2, size.height/2, zeye )。可以看出eye在xy平面的投影恰好是以屏幕分辨率构成的矩形的中心。

centre坐标，表示的是视线方向，该方向矢量是由eye坐标、centre坐标共同构成的，由eye指向center。Cocos2d-x的设置 kmVec3Fill( ¢er, size.width/2, size.height/2, 0.0f )。x, y坐标与eye的相同，因此视线平行于Z轴。

最后的up参数可以理解为头顶方向，这里设置为Y轴方向。

可以看出，eye就在投影区的中心，由于投影区的高度为size.height(投影变换时分析得到的)，这样根据投影矩阵设置的宽高比，得出该投影区的宽度也恰为size.width。

七、再分析

有了以上关于Cocos2d-x引擎的了解，我们再回过头来用OpenGL的变换原理对篇头的三种情况做分析。

1) 屏幕大小480×320，未做任何屏幕适配工作，不调用pEGLView->setDesignResolutionSize。结果：背景图充满窗口。

    在这种情况下，各个OpenGL变换矩阵参数值如下：
        eye视点坐标(240, 160, 320/1.1566f);
        投影变换矩阵在xy平面的截面区域恰好是480×320；
        背景图锚点位置(240, 160, 0)；

在这种情况下，截面区域恰与背景图重合，显示在屏幕上后，背景图恰充满窗口，见下图：

2) 屏幕大小960×640，未做任何屏幕适配工作，不调用pEGLView->setDesignResolutionSize。结果：背景图未充满窗口，四周有较大黑边。

    在这种情况下，各个OpenGL变换矩阵参数值如下：
        eye视点坐标(480, 320, 480/1.1566f);
        投影变换矩阵在xy平面的截面区域是960×640；
        而背景图锚点位置(480, 320, 0)；

    因此背景图(480×320)未能完整充满截面区域(960×640)，背景图周围将有较大黑边，见下图：

3) 屏幕大小同为960×640，按照上面Cocos2d-x屏幕适配指南Wiki中的做法，调用pEGLView->setDesignResolutionSize(480, 320)。结果：背景图放大为原来2倍，充满屏幕窗口。

    在这种情况下，各个OpenGL变换矩阵参数值如下：
        eye视点坐标(240, 160, 320/1.1566f);
        投影变换矩阵在xy平面的截面区域是480×320；
        而背景图锚点位置(240, 160, 0)；

在这种情况下，截面区域恰与背景图重合。但这里需要注意的是现在屏幕是960×640，而截面区域仅仅是480×320，为何映射后，背景图充满屏幕了呢？这里就不能不提到视口的作用了。

前面说过视口相当于相片，现在我们拍摄出的图片是480×320的，但我们选择的底片Viewport却是960×640的，怎么办，在视口转换时，OpenGL自动将480×320的图片映射到960×640的底片上，相当于对图像进行的放大。而960×640的视口恰好与屏幕窗口大小一致且坐标重叠，于是我们就在屏幕上看到了一个铺满屏幕的背景图，见下图：

4) 我们再来说两个有关视口的例子

    以第三种情况为基础，我们修改一下引擎代码，看看视口的作用。

    我们手工将CCDirector::setViewport()中的：
        m_pobOpenGLView->setViewPortInPoints(0, 0, m_obWinSizeInPoints.width, m_obWinSizeInPoints.height);
    改为：
        m_pobOpenGLView->setViewPortInPoints(0, 0, m_obWinSizeInPoints.width/2, m_obWinSizeInPoints.height/2);

这样修改后，Viewport从point(0,0), rect (960×640)变成了point(0,0), rect (480×320)。也就是说用照相机拍出的景物大小是480×320，底片也是480×320，但屏幕是960×640，我们可以将屏幕理解为相框，把一张480×320的照片，放到960×640大小的相框里，相片只能占据相框的四分之一。这个例子的最终屏幕显示结果见下图：

    前面的例子中背景图片size均小于屏幕大小，我们再来举一个资源图片大于屏幕大小的例子，看看经过一系列变换会得到什么样的结果。

    首先将CCDirector::setViewport()中的代码恢复原先状态。然后我们准备一张1024×768(>屏幕的960×640)的背景图片"HelloWorld-1024×768.jpg"，修改HelloWorldScene.cpp，将：
    CCSprite* pSprite = CCSprite::create("HelloWorld.png");
    修改为：
    CCSprite* pSprite = CCSprite::create("HelloWorld-1024×768.png");

注释掉AppDelegate.cpp中的pEGLView->setDesignResolutionSize调用，这样更直观。

这样修改后，各参数如下：
        eye视点坐标(480, 320, 640/1.1566f);
        投影变换矩阵在xy平面的截面区域是960×640；
        而背景图锚点位置(480, 320, 0)；
        Viewport point(0,0), rect (960×640)

    由于背景资源图片太大(1024×768)，大于我们的投影截面区域960×640，因此模型真正能显示的部分仅仅是投影截面区域中的那960×640范围内的图片。于是显示结果如下：

矩阵变换过程如下：

投影截面区域与视口区域重叠，这里就不再赘述了。

八、CCDirector::m_fContentScaleFactor

决定图像在屏幕上的最终显示结果的因素还有一个，那就是CCDirector::m_fContentScaleFactor。在最初的HelloCpp例子中，我们能看到这样的代码：

    if (frameSize.height > mediumResource.size.height)
    {
        searchPath.push_back(largeResource.directory);
        pDirector->setContentScaleFactor(
          MIN(largeResource.size.height/designResolutionSize.height,
              largeResource.size.width/designResolutionSize.width));
    }
    … …

可以看出这个contentScaleFactor存储的是资源分辨率与设计分辨率的比值。我们还是用例子来看看该元素对显示的影响。我们在第一种情况的基础上验证。

第一种情况：屏幕480×320，未调用setDesignResolutionSize，资源大小480×320。结果：图片充满屏幕。

现在我们增加并使用一个新资源：HelloWorld-960×640.png，这个图片大小960×640，是屏幕大小的二倍，根据上面的分析，我们很容易猜测到最终结果是：只有图片中央区域(480×320)可以显示出来，其余部分被投影矩阵截掉。

现在我们使用setContentScaleFactor，在AppDelegate.cpp中做如下调用：

pDirector->setContentScaleFactor(MIN(960/480, 640/320));

这样我们得到的m_fContentScaleFactor = 2。而我们编译运行后得到的结果是：图片铺满整个屏幕。为什么会这样呢？

我们在代码中搜索contentScaleFactor，我们找到一些宏和调用：

#define CC_CONTENT_SCALE_FACTOR() CCDirector::sharedDirector()->getContentScaleFactor()

CCSize CCTexture2D::getContentSize()
{

    CCSize ret;
    ret.width = m_tContentSize.width / CC_CONTENT_SCALE_FACTOR();
    ret.height = m_tContentSize.height / CC_CONTENT_SCALE_FACTOR();

return ret;
}

#define CC_RECT_PIXELS_TO_POINTS(__rect_in_pixels__)                                                                        \
    CCRectMake( (__rect_in_pixels__).origin.x / CC_CONTENT_SCALE_FACTOR(), (__rect_in_pixels__).origin.y / CC_CONTENT_SCALE_FACTOR(),    \
            (__rect_in_pixels__).size.width / CC_CONTENT_SCALE_FACTOR(), (__rect_in_pixels__).size.height / CC_CONTENT_SCALE_FACTOR() )
… …

bool CCSprite::initWithTexture(CCTexture2D *pTexture)
{
CCAssert(pTexture != NULL, "Invalid texture for sprite");

CCRect rect = CCRectZero;
rect.size = pTexture->getContentSize();

return initWithTexture(pTexture, rect);
}

这些代码都在告诉我们，如果m_fContentScaleFactor = 2，那代码会对Sprite的纹理进行缩放，让上面得到的数据是经过contentScaleFactor变换的，我们可以认为我们所用的实际资源大小是原资源的1/m_fContentScaleFactor即可。

Cocos2d-x 3.0rc0集成Google AdMob SDK

bigwhite — Wed, 30 Apr 2014 18:23:16 +0000

话说Cocos2d-x 3.0上一周迫不及待地发布了正式版，本是一件值得庆幸的事情。但由于不可解决的技术问题，引擎无奈将Android平台的NativeActivity 实现重新回退到了Cocos2d-x 2.2.x版本的实现方案。由于之前已经将 GameDemo移植到了Cocos2d-x 3.0rc0版，直观感受到了NativeActivity方案带来的游戏操作体验上的提升（触屏事件的响应），因此心里总是“挂念”引擎的 NativeActivity方案。按照Cocos2d-x官方人士的说法，只要NDK的问题修复，NativeActivity还是未来引擎在 Android平台上的第一选择。我的理解，将来Cocos2d-x的某个版本中还会恢复NativeActivity的实现方案。

上次只是将GameDemo的核心逻辑移植到了Cocos2d-x 3.0rc0上，但一些外部SDK集成尚未做完，这两天闲遐时开始着手研究如何做，而首先要移植的就是Google AdMob SDK。关于Cocos2d-x 3.0rc0集成Google AdMob SDK，网上已经有了技术方案原型，最初应该是一个外国开发者提出的方案，后来被CocoaChina cocos2d-x社区版主翻译成了中文教程，这里基本上也是参考的这个方案，只是做了局部细化和进一步说明，希望能帮助大家进一步解惑。

一、功能说明

GameDemo游戏分为三个场景：WelcomeScene、GameScene以及EndScene。集成AdMob SDK的功能要求如下：

    – 当游戏进入到WelcomeScene时，AdMob SDK完成初始化，发出Ad Request，当收到Ad的时候才会在屏幕上方显示带有Ad的窗口；
    – 当点击Start进入到GameScene时，隐藏Ad窗口，以不干扰玩家的游戏操作为优先；
    – 当游戏Over进入到EndScene的时候，恢复显示Ad窗口；
    – 当玩家点击“Retry”回到GameScene时，隐藏Ad窗口。

二、方案原理

这个方案就是通过android.widget.PopupWindow实现广告窗口悬浮在当前窗口之上。按照Android官方Doc中的说明，PopupWindow用于实现一个弹出框，它可以使用任意布局的View作为其内容，这个弹出框是悬浮在当前activity之上的。

至于PopupWindow为何能显示在当前Activity之上，可以查看PopupWindow的源码，大致思路就是PopupWindow通过 new时传入的context(当前Activity)获得了当前WindowManager，并将AdView作为子View添加到该窗口中。这里简要列出一些关键源码，大家可粗略理解一下：

    public PopupWindow(Context context, AttributeSet attrs,
         int defStyleAttr, int defStyleRes) {
        mContext = context;
        mWindowManager = (WindowManager)context
               .getSystemService(Context.WINDOW_SERVICE);
        …. …
    }

    public void setContentView(View contentView) {
        if (isShowing()) {
            return;
        }

mContentView = contentView;

        if (mContext == null && mContentView != null) {
            mContext = mContentView.getContext();
        }

        if (mWindowManager == null && mContentView != null) {
            mWindowManager = (WindowManager) mContext
                  .getSystemService(Context.WINDOW_SERVICE);
        }
    }

    public void showAtLocation(View parent, int gravity, int x, int y) {
        showAtLocation(parent.getWindowToken(), gravity, x, y);
    }

    public void showAtLocation(IBinder token, int gravity, int x, int y) {
        if (isShowing() || mContentView == null) {
            return;
        }

unregisterForScrollChanged();

mIsShowing = true;
mIsDropdown = false;

        WindowManager.LayoutParams p = createPopupLayout(token);
        p.windowAnimations = computeAnimationResource();

        preparePopup(p);
        if (gravity == Gravity.NO_GRAVITY) {
            gravity = Gravity.TOP | Gravity.START;
        }
        p.gravity = gravity;
        p.x = x;
        p.y = y;
        if (mHeightMode < 0) p.height = mLastHeight = mHeightMode;
        if (mWidthMode < 0) p.width = mLastWidth = mWidthMode;
        invokePopup(p);
    }

    private void invokePopup(WindowManager.LayoutParams p) {
        if (mContext != null) {
            p.packageName = mContext.getPackageName();
        }
        mPopupView.setFitsSystemWindows(mLayoutInsetDecor);
        setLayoutDirectionFromAnchor();
        mWindowManager.addView(mPopupView, p);
    }

UI线程负责更新窗口，因此popupWindow的创建与操作都应该通过runOnUiThread传递给UI线程执行。

游戏逻辑的C++层代码通过Jni控制PopupWindow的Show和dismiss。别忘了C++层的代码是在渲染线程执行的哦，这也是为何要用handler和runOnUIThread的原因。

在Cocos2d-x 2.2.2版本集成AdMob时，AdMob只是在收到ad后才显示出广告Banner，但是在cocos2d-x 3.0rc0中，当广告加载未成功时，android.widget.PopupWindow会显示一个小黑框，特难看，因此我们需要自己来控制。

三、集成步骤

【AdMob准备】

到Google AdMob注册一个帐号，如果你有Google帐号，那直接开通AdMob（需填写更加详细的信息）。
下载Google AdMob SDK，之前一直用GoogleAdMobAdsSdk-6.4.1.jar，这里还以这个版本为例。但Google官方已经不推荐这个版本了，你可以下载Google Play Services版本的Mobile Ads API，但代码与这里会稍有不同。将下载的jar包放到GameDemo/proj.android/libs中。

【修改AndroidManifest.xml】

在标签里添加：

权限方面至少包含如下两个：

【Java层代码集成】

我们只需要修改GameDemoActivity.java这个文件。

import android.app.NativeActivity;
import android.os.Bundle;
import android.util.Log;

import android.os.Handler;
import android.os.Message;
import android.view.Gravity;
import android.view.View;
import android.view.Gravity;
import android.view.ViewGroup.LayoutParams;
import android.view.ViewGroup.MarginLayoutParams;
import android.view.WindowManager;
import android.widget.LinearLayout;

import android.widget.PopupWindow;
import com.google.ads.AdRequest;
import com.google.ads.AdSize;
import com.google.ads.AdView;
import com.google.ads.AdListener;
import com.google.ads.Ad;

public class GameDemoActivity extends NativeActivity{
private static GameDemoActivity context;

    private AdView adView;
    private PopupWindow popUpWindow;
    private LinearLayout popupWindowLayout;
    private LinearLayout mainActivityLayout;
    private boolean hasAdReceived;

    private static Handler adHandler = new Handler() {
        public void handleMessage(Message msg) {
            if (!context.hasAdReceived)
                return;

            switch (msg.what) {
                case 0:
                    if (View.VISIBLE ==
                        context.adView.getVisibility()) {
                        context.adView.setVisibility(View.GONE);
                        context.popUpWindow.dismiss();
                    }
                    break;
                case 1:
                    if (View.VISIBLE !=
                        context.adView.getVisibility()) {
                        context.adView.setVisibility(View.VISIBLE);
                        context.popUpWindow.showAtLocation(
                           context.mainActivityLayout, Gravity.TOP, 0, 0);
                    }
                    break;
            }
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
        context = this;
        adView = new AdView(this, AdSize.BANNER, "a1533d6de900e31");
        adView.setAdListener(new AdmobListener());
        //初始时，广告View隐藏起来
        adView.setVisibility(View.GONE);
    }

    public static void setupAds(){
        context.initAdPopupWindow();
    }

    public void initAdPopupWindow() {
        if (adView != null) {
            context.runOnUiThread(new Runnable() {
                 @Override
                 public void run() {
                     MarginLayoutParams params = new MarginLayoutParams(
                                     LayoutParams.WRAP_CONTENT,
                                     LayoutParams.WRAP_CONTENT);
                     params.setMargins(0, 0, 0, 0);

                     popupWindowLayout = new LinearLayout(context);
                     popupWindowLayout.setPadding(-5, -5, -5, -5);
                     popupWindowLayout.setOrientation(LinearLayout.VERTICAL);
                     popupWindowLayout.addView(adView, params);

                     popUpWindow = new PopupWindow(context);
                     popUpWindow.setWidth(320);
                     popUpWindow.setHeight(50);
                     popUpWindow.setWindowLayoutMode(LayoutParams.WRAP_CONTENT,
                                               LayoutParams.WRAP_CONTENT);
                     popUpWindow.setClippingEnabled(false);
                     popUpWindow.setContentView(popupWindowLayout);

mainActivityLayout = new LinearLayout(context);
context.setContentView(mainActivityLayout, params);

context.hasAdReceived = false;

                     AdRequest adRequest = new AdRequest();
                     //测试Admob时使用测试Device，发布版需要去掉这行代码
                     adRequest.addTestDevice("CCE4220B2509A406B515E7C9A205AEE1");
                     context.adView.loadAd(adRequest);

                     popUpWindow.update();
                }
            });
        }
    }

    //GoogleAdMobAdsSdk-6.4.1版本中的AdListener是interface，因此
    //我们需要override所有接口，但只有onReceiveAd是我们关心的。
    private class AdmobListener implements AdListener {
        @Override
        public void onReceiveAd(Ad ad) {
            //只有第一次成功接收Ad后，我们后续才显示广告窗口，否则
            //popupWindow会显示为一个小黑框，特难看。
            Log.d("GameDemo", "onReceiveAd");
            if (!hasAdReceived){
                hasAdReceived = true;
            }
        }

        @Override
        public void onFailedToReceiveAd(Ad ad,
                            AdRequest.ErrorCode error) {
            Log.d("GameDemo",
              "failed to receive ad (" + error+ ")");
        }

        @Override
        public void onPresentScreen(Ad ad) {
            Log.d("GameDemo", "onPresentScreen");
        }

        @Override
        public void onDismissScreen(Ad ad) {
            Log.d("GameDemo", "onDismisScreen");
        }

        @Override
        public void onLeaveApplication(Ad ad) {
            Log.d("GameDemo", "onLeaveApp");
        }
    }

    public static void setAdVisible(boolean b) {
       Message msg = new Message();
        if (b) {
            msg.what = 1;
        } else {
            msg.what = 0;
        }
        adHandler.sendMessage(msg);
    }
}

【C++层代码集成】

在AppDelegate.cpp中添加setupAds方法：

void AppDelegate::setupAds()
{
#if (CC_TARGET_PLATFORM == CC_PLATFORM_ANDROID)
    JniMethodInfo t;
    if (JniHelper::getStaticMethodInfo(t, "com/tonybai/game/GameDemoActivity", "setupAds", "()V")) {
        t.env->CallStaticVoidMethod(t.classID, t.methodID);
        if (t.env->ExceptionOccurred()) {
            t.env->ExceptionDescribe();
            t.env->ExceptionClear();
            return;
        }
        t.env->DeleteLocalRef(t.classID);
    }
#endif
}

在WelcomeScene的init方法中调用setupAds：

bool WelcomeScene::init()
{
    bool bRet = false;
    do {
       … …
       AppDelegate *app = (AppDelegate*)Application::getInstance();
       app->setupAds();

bRet=true;
} while(0);

return bRet;
}

在点击Start按钮时，隐藏Ad：

void WelcomeScene::menuStartCallback(Ref* pSender)
{
AppDelegate *app = (AppDelegate*)Application::getInstance();

    app->setAdVisible(false);
    GameScene *gameScene = GameScene::create();
    Director::getInstance()->replaceScene(gameScene);
}

集成步骤到此就结束了，编译ok就可以部署到模拟器上运行测试一番了。

四、使用Cocos2d-x 3.0rc0引擎遇到的两个问题

【问题1】用cocos2d-x 3.0rc0的cocos编译高版本引擎生成的工程遇到的问题

cocos2d-x 3.0rc0生成的proj.android/build-cfg.json与高版本(rc1～正式版) cocos生成的工程的build-cfg.json稍有不同，用cocos2d-x 3.0rc0版cocos编译高版本cocos生成的project，会提示build_android组件无法找到“copy_to_assets”。因此需要手动修改proj.android/build-cfg.json，将其中的：

    "copy_resources": [
        {
            "from": "../Resources",
            "to": ""
        }
    ],

改为：

   "copy_to_assets" :[
            "../Resources/"
            ],

【问题2】 W/dalvikvm(1194): dvmFindClassByName rejecting 'org/cocos2dx/lib/Cocos2dxHelper'

使用cocos2d-x 3.0rc0编译的项目，总是出现如下问题，但似乎这个错误还不影响程序的运行：

04-29 09:44:34.968: D/JniHelper(1194): JniHelper::setJavaVM(0xb8835730), pthread_self() = B897B518
04-29 09:44:34.968: W/dalvikvm(1194): dvmFindClassByName rejecting 'org/cocos2dx/lib/Cocos2dxHelper'

Google了一下，这个问题很多童鞋都遇到了，但给出的solution却不甚令我满意，于是我就求甚解的细致挖掘了一下，终于找到了一个让我还算满意的答案。我们分析一下这两条日志，rejecting那条日志总是伴随setJavaVM后面出现的。可引擎什么时候setJavaVM了呢？显然是在 native_app_glue创建的子进程中，引擎需要attachCurrentThread，获得JniEnv时才做的。于是我们打开cocos2d-x-3.0rc0/cocos/2d/platform/android/nativeactivity.cpp一看究竟。

在nativeactivity.cpp中有两处"org/cocos2dx/lib/Cocos2dxHelper"，我们先看engine_handle_cmd中的那处：

static void engine_handle_cmd(struct android_app* app, int32_t cmd)
{
        …. ….
        case APP_CMD_INIT_WINDOW:
            LOG_RENDER_DEBUG("android_main : APP_CMD_INIT_WINDOW");
            // The window is being shown, get it ready.
            if (engine->app->window != NULL) {
                cocos_dimensions d = engine_init_display(engine);
                if ((d.w > 0) &&
                    (d.h > 0)) {
                    cocos2d::JniHelper::setJavaVM(app->activity->vm);
                    cocos2d::JniHelper::setClassLoaderFrom(app->activity->clazz);

                    // call Cocos2dxHelper.init()
                    cocos2d::JniMethodInfo ccxhelperInit;
                    if (!cocos2d::JniHelper::getStaticMethodInfo(ccxhelperInit,
                                                                 "org/cocos2dx/lib/Cocos2dxHelper",
                                                                 "init",
                                                                 "(Landroid/app/Activity;)V")) {
                        LOGI("cocos2d::JniHelper::getStaticMethodInfo(ccxhelperInit) FAILED");
                    }
                    ccxhelperInit.env->CallStaticVoidMethod(ccxhelperInit.classID,
                                                            ccxhelperInit.methodID,
                                                            app->activity->clazz);

                    cocos_init(d, app);
                }
                engine->animating = 1;
                engine_draw_frame(engine);
            }
            break;
    … …
}

初步可以断定，那两条日志就是执行到这里输出的，但为何dvmFindClassByName方法会rejecting “org/cocos2dx/lib/Cocos2dxHelper”这个类名呢？我们还得翻看dalvik虚拟机源码：

/dalvik/vm/native/InternalNative.cpp

/*
* Find a class by name, initializing it if requested.
*/
ClassObject* dvmFindClassByName(StringObject* nameObj, Object* loader,
        bool doInit)
{
    ClassObject* clazz = NULL;
    char* name = NULL;
    char* descriptor = NULL;
    if (nameObj == NULL) {
        dvmThrowNullPointerException("name == null");
        goto bail;
    }
    name = dvmCreateCstrFromString(nameObj);
    /*
     * We need to validate and convert the name (from x.y.z to x/y/z). This
     * is especially handy for array types, since we want to avoid
     * auto-generating bogus array classes.
     */
    if (!dexIsValidClassName(name, true)) {
        ALOGW("dvmFindClassByName rejecting '%s'", name);
        dvmThrowClassNotFoundException(name);
        goto bail;
    }
    … …
}

我们的确找到了输出rejecting日志的地方，通过注释我们可以看到这个方法是用来验证名字对象，并将x.y.z形式的名字转换成x/y/z的。但引擎中传入的就是“x/y/z”格式，因此这个方法输出了错误日志。我尝试将上面engine_handle_cmd中的"org/cocos2dx/lib/Cocos2dxHelper"改成"org.cocos2dx.lib.Cocos2dxHelper"，错误日志果然消失了。

不过目前仍不能解释一点：为何在其他位置，比如在前面的AppDelegate::setupAds中，使用x/y/z格式的jni调用参数却没有输出错误日志！难道两个位置dalvik虚拟机使用的是不同的名字对象查找和加载方法？这个目前尚无定论。