《Androids The Team that Build the Android Operating System》
简介
本书讲述了Android如何从一个无法引起投资者兴趣的相机软件发展成为安装在全球30亿台设备上的移动操作系统的故事。作者花了四年时间，采访了早期Android团队的大部分成员，让这些鲜为人知的精彩故事得以保存下来，并以幽默诙谐的笔风呈现给读者。
作者按照时间顺序讲述了这家初创公司是如何起步的，团队成员是如何走到一起的，以及他们是如何构建出这个操作系统的。这个雄心勃勃的项目从脆弱的低谷开始，这家初创公司最终被谷歌收购，并在激烈的行业竞争中披荆斩棘，成为席卷全球的移动操作系统。
作者介绍
Chet Haase 曾在硅谷多家知名高科技公司历练多年，擅长图形软件开发。2010年，他加入谷歌的安卓团队，在那里编写了这款未来会颠覆世界的操作系统的动画和UI软件。他曾领导安卓的UI工具包团队，担任安卓开发者关系首席倡导者，现在依然是安卓图形团队的工程师
思维导图
-
Android
-
时间线
-
2003.10 安迪·鲁宾创建Android，希望创建一个数字相机的操作系统
-
2005年7月 谷歌收购Android
-
2007年1月9日 iPhone 发布"今天，苹果将彻底重塑手机"
-
2007年11月 Google正式开源Android。SDK发布
-
2008年 SDK 1.0 & G1手机发布
-
• G1并没有在一夜之间取得成功
-
• G1的推出，让设备厂商觉得它是真实的。
-
-
2009年10月17日 Droid手机发布
-
• 是第一款大获成功的Android设备，尤其在美国。
-
• 在技术上，不被Android团队看好，Nexus One才是Andy的亲儿子。
-
• 是产品和市场营销让Droid手机大放光彩
-
-
2010年
-
正式推出仅两年多的Android超越称霸逾十年的诺基亚Symbian系统，成为全球第一大智能手机操作系统。
-
-
2014年
-
Google在开发者大会上宣布过去Android活跃设备超10亿台。
-
-
2017年
-
Android超越Windows，正式成为全球第一大操作系统。
-
-
-
历史脉络
-
相机操作系统
-
起初，Android 想要打造一个数码相机平台，但当时的人们和投资者，对相机并不感兴趣，而是热衷于手机。于是 Android 放弃了原先的想法，开始准备做一个手机操作系统。
* -
Android 虽然没有开发它的相机操作系统，但是现在看来，手机上的相机，已经算是最广泛的相机操作系统了，只是饶了个弯儿。
*
-
-
团队构成
-
早期 Android 团队的员工 70% 都来自于 Be/PalmSource、WebTV / 微软和 Danger。
-
Be（BeOS 操作系统，与微软和苹果公司进行桌面系统竞争，Be 差点被苹果公司收购，但最终选择了乔布斯的 NeXT 电脑公司，最终 Be 被 Palm 收购
-
Palm 将部门剥离出来，成立了一家 PalmSource 公司，后被 ACCESS 收购，很多 Be 前工程师加入了 Google 的 Android 开发团队，占 Android 团队总人数的三分之一
-
WebTV / 微软（被微软收购，早期从微软加入 Android 的人都来自 WebTV 团队，这个团队构建了一个操作系统、一个 UI 工具包、一个用于开发应用程序的编程层，以及为互联网设备设计的应用程序）
-
Danger，Andy 和朋友于 1999 年 12 月创办的。发布过多款手机，取得了一些成就和追捧，但这些手机没能抓住消费者的心，也没能撬开消费者的钱包。
-
早期的团队在很大程度上依赖于他们在过往公司积累的经验。他们带来了已有的合作关系，积累了开发 Android 所需的经验：操作系统、嵌入式设备和开发平台。
-
-
商业模式
-
公司专注于三件事。首先，他们需要一个演示版本来展示自己产品的可能性。接下来，他们需要清楚地表达自己的愿景，并通过推介会来解释这个愿景。最后，他们需要带着演示版本和幻灯片进行路演，向潜在的投资者推销自己的故事
-
路演的ppt
-
它对 PC 和手机市场进行了对比。2004 年，手机的销量已经远远超越了 PC，但手机处理器和内存的性能只与 1998 年的 PC 相当。
-
当时，大多数的手机厂商都使用自研开发的操作系统，而 Android 希望提供世界上第一个完整的开放手机平台解决方案。它将以 Linux 为基础，同时提供其他所有必要的组件，手机厂商只需要用这一个系统就可以推出自己的设备。
-
那么，Android 平台将如何盈利呢？答案是运营商服务。运营商将为 Android 手机用户提供应用程序、联系人和其他基于云计算的数据服务。为了能够提供这些服务，运营商需要向 Android 支付费用。
-
-
-
被Google收购
-
Android 寻找了多家公司进行融资，包括三星、HTC 但结果都不太令人满意，直到遇到 Google。
-
经过三次的会面，Google 决定收购 Android，他们将操作系统免费提供给运营商，没有来自风投公司的施压，也不必向客户和运营商收取专门的服务费。
-
-
-
构建平台-技术决策
-
系统团队
-
内核
-
小故事：“发现”了额外的内存
-
Brian Swetland（内核开发者） 有一个传奇故事：他在G1发布前不久“发现”了额外的内存。他在发布之前提交了一个修复方案，将手机的可用内存从160MB 扩展到192MB，为操作系统和应用程序增加了20%的内存，对于这个内存捉襟见肘的系统来说，这是一个显著的提升。
-
事实是，他知道怎样找到这些内存，因为那是他在一开始就藏好的。内核负责为系统的其他部分分配内存。在将内核带到G1上时，他对配置动了手脚，让报告的内存比实际内存少一些。对于系统的其他部分来说，可用内存实际上比物理内存少了32MB。因为他知道，只要有可用的内存，开发者都会将它们用掉，但如果内存紧张，他们就不得不“抠抠搜搜”。
-
每个人都要确保自己的软件能在这个缩水版的内存上工作，因为他们能用的内存就这么多。在G1 发布之前，他释放了剩余的内存，更多的可用内存意味着可以同时运行更多的应用程序。
-
后来加入团队负责蓝牙开发的Nick Pelly 回忆说，并不是每个人都对这一结果感到高兴：“这引起了很大轰动。浏览器团队不得不在周末加班解决错误的内存预算问题。我记得其中有一个人在 Brian'发现'额外内存时冲进了他的办公室，并大声说了一些脏话。”
-
-
-
驱动程序开发
-
重写了很多的Linux驱动程序，提升了性能
-
-
通信开发
-
在Linux内核基础上加上了唤醒锁的概念，让大部分程序进入休眠状态，而至少保持通话功能
-
-
功耗问题
-
第一件事是在系统中添加工具来了解哪些地方在耗电
-
持久的争论
-
平台控制功耗：如果应用进入后台就强制释放
-
将选择和责任交给开发者，教育开发者正确开发程序
-
-
CPU调速器
-
改变cpu的频率来减少耗电
-
-
-
-
Java
-
选择编程语言
-
JavaScript
-
好用，但是本身设计不完备
-
-
C++
-
高性能，但是内存管理复杂
-
-
Java
-
J2ME 在当时市场比较大
-
开发者生态和工具链
-
-
本来是要同时支持以上三种语言的，但是复杂度太高，只选择了Java
-
-
运行时-Runtime
-
JamVm
-
直接执行java 字节码
-
-
Dalvik
-
转换格式，提升性能，节约内存
-
名字来自于冰岛的一个小镇
-
-
-
Zygote
-
Zygote 创建了一个包含大部分核心平台代码的进程，并几乎预加载和初始化了所有这些代码。每当有应用程序启动时，都会通过分叉（将其复制到一个新进程中）Zygote 进程，让应用程序立即进入即将就绪的状态
-
Zygote 不仅共享代码，还共享图像等。随着平台的发展，Zygote 继续为 Android 提供内存使用效率和启动速度方面的优势。
-
-
-
核心库
-
JDK
-
Bob Lee
-
选择了Apache Harmony
-
-
Josh Bloch - Effective Java作者
-
-
-
图形
-
基本流程
- 应用程序通过调用Canvas API来绘制东西。Canvas API的底层使用了Skia渲染引擎，负责将形状和文本等内容转换成像素。SurfaceFlinger为像素绘制提供了一个缓冲区，或者说表面。SurfaceFlinger调用OpenGL ES，一个可以渲染三角形的底层图形API。OpenGL ES使用PixelFlinger来绘制缓冲区（在GPU成为智能手机的标配后，PixelFlinger被GPU取代）。最后，所有需要绘制到屏幕上的表面（包括前台应用、状态栏和导航栏）都在硬件编配器（Hardware Composer）中被组合在一起，显示在屏幕上，这样用户就可以看到它们。
-
编写虚拟GPU
-
平台思维 & 产品思维
-
在没有GPU的时候，假设将来会普及GPU
-
-
SurfaceFlinger
-
应用程序与OpenGL ES的黏合剂
-
确保应用程序的渲染不会影响其他应用程序的渲染，程序之间是互相隔离的
-
-
硬件编配器-Hardware Composer HWC
-
组合多个进程的窗口图层组合显示在屏幕上
-
-
Skia
-
被google收购，后来成为Android\Flutter\Chrome的渲染引擎
-
-
-
框架
-
Activity
-
概念来自于团队早期PalmSource
-
移动设备的特点：用户每次通常只访问一个应用，专注于一个特定任务
-
生命周期
-
争论
-
基于页面-Activity
-
基于main方法
-
-
-
资源
-
基于平台的思路，未来设备会非常不同
-
好的决策来自经验，而经验来自坏的决策。Android的很多技术决策在后面来看都是正确的，这来自于之前不成功的项目
-
-
Binder机制
-
概念来自于PalmSource公司
-
利用mmap机制实现单次拷贝即可实现IPC
-
反对的声音：
-
Binder的阻塞调用会导致调用方也阻塞，增加了线程开销
-
电话功能中没有使用Binder,而是使用了Unix Socket机制
-
-
-
ContentProvider
-
最初是为了开发联系人应用而开发出的
-
-
日历应用
- 给CEO演示时崩溃了
-
“不是我的数据导致了你的应用崩溃了，而是你的应用在我的数据上栽了跟头。”
-
- 给CEO演示时崩溃了
-
-
UIKit
-
实现语言？
-
SKia: XML + JavaScript
-
代码为核心
-
24小时，将View在Android上显示出来
-
-
-
单线程？多线程？
-
1. 线程安全的UI工具包，可以支持多线程
-
2. 单线程的工具包，好理解，容易实现
-
3. 允许多线程，但是会有bug，不好调试
-
不能使用成员变量
-
-
-
性能
-
invalidate
-
hierarchyviewer工具
-
-
ListView
-
ViewHolder
-
-
merge include ViewStub
-
-
屏幕密度
- G1 首款设备是每英寸160像素ppi
-
定义了dp (与密度无关的像素）
-
- G1 首款设备是每英寸160像素ppi
-
-
-
为什么Android会成功？
-
团队
-
Android 团队从一开始就是由具备合适的技能和驱动力的人组成的。创建一个完整的平台，包括应用、服务和基础设施，是一项巨大的工程，需要能够快速投入工作的人付出巨大的努力。
-
团队的大多数人都拥有合适的经验，这让他们能够快速上手。他们曾在 Be、Danger、PalmSource、WebTV 和微软等公司参与过相关的平台和移动项目，这些经历为他们奠定了相关领域的技术基础，让他们知道如何解决 Android 所面临的问题。
-
-
决策
-
好的团队会做出好的决策。坚实的技术基础和商业决策推动了 Android 的成功发布，并随着逐步释放厂商、开发者和用户的潜力，开启了持续增长的势头。
-
功能：吸引用户的杀手锏
-
■ 通知：Android 的通知服务让整个系统变成一个整体，因为应用程序可以与底层的系统合作，向用户告知他们想知道的信息。
-
■ 多任务：用户可以通过 “返回” 和“最近访问”按钮来轻松快速地切换应用，这预示了移动计算最新的发展趋势，即人们经常会同时运行多个应用来完成任务。
-
■ 安全性：从一开始，团队就意识到移动应用与桌面应用有本质上的不同，并构建了一个将应用彼此隔离的安全机制。安全性从几年前开始变得越来越重要，而 Android 从一开始就提供了安全性基础，并根植于内核和硬件的底层。
-
■ 显示尺寸和密度：团队让应用程序能够在保持正常运行的情况下缩放成不同的显示尺寸和密度，这是支持各种设备和屏幕的关键。
-
-
-
时机
-
Android 的时机有多方面的因素：团队能够多快发布 1.0 版本和更新，什么时候硬件可用并运行得足够快，等等。但最重要的因素可以概括为一个词：竞争。
-
在 iPhone 发布后，厂商迫切需要推出自己的触摸屏产品，以便在不断发展的智能手机市场中参与竞争。因为 iPhone 的生态系统是封闭的，所以其他厂商只能自己去打造一个引人注目的系统
-
当时，时机对硬件性能也有积极的影响。CPU、GPU、内存和显示技术的发展让智能手机的功能变得更加强大。硬件性能的提升不仅使推出新机型成为可能，还使计算硬件成为一个全新的利基市场，摆脱了来自旧 PC 世界平台玩家的束缚。
-
最后一个与时机有关的因素是团队能够快速行动，充分利用他们所获得的机会。首先，在 iPhone 发布时，团队已经将核心 Android 平台开发到了一定程度，几乎已经为急需解决方案的厂商准备好了。此外，团队及时调整方向，抓住了触摸屏的机会，赶在其他可行的解决方案之前将 1.0 版本和 G1 推向市场。
-
-
-
