做手机的一点体会
整个android系统是一个完整的生态系统，谷歌提供开放的android平台，下游有各种生产硬件的厂家提供各种手机的硬件，像富士康这样的工厂提供手机的代加工，
然后是高通这样的公司提供手机的核心芯片和自己的解决方案，然后网上做手机的公司，相当于是做一个大的"集成"，做手机的公司需要从各种运营商那里拿到订单，然后根据
运营商的需求来做手机，运营商卖好了手机，和手机公司之间分成，或者是 手机公司通过其他的渠道售卖自己的手机，功能要么是全网通，兼容各个运营商，要么是兼容某一个
运营商。相比之下，运营商卖手机肯定是占了很大的一部分。在运营商的上头，就是市场需求，即每一个普通的用户需求，用户对手机的需求（低端 中端 高端），用户对于运营商的选择（联通， 移动还是电信）等等。 这样就形成了一个完整的生态圈。 当然这个生态圈，不止有中国市场，更有北美，欧洲，非洲，日本等等市场。 就我知道的， TCL接过的北美T-mobile运营商的业务，诸如此类，其他的就不细说了。
例如 笔者曾经供职的公司就是 做手机的公司，客户是 大牌手机公司的 第三方公司，例如 是 SOMC TCL 等等品牌公司的第三方公司。为什么运营商不肯把业务交给他们呢？很显然，实力不到嘛，运营商哪能放心地把这么大一块肥肉给你吃呢，再说了，你也吃不下嘛。于是，这类公司，就是 对上要 和运营商接洽，针对运营商的需求，例如：界面设计，稳定性，新功能开发，双卡双待等等新功能，在android源码的基础上进行新功能的开发，开发完了之后，再针对运营商的需求，和测试用例，针对不过的测试用例，逐个解BUG，对下要和高通这样的厂商接洽，在解BUG中遇到的问题，追查到底层，涉及芯片内部的工作等等（因为底层核心代码，高通肯定是不会对外开放的），需要将问题发生的情况提case给高通，帮助一起解决。这样的公司起了一个衔接的作用，而且接活也很容易，上下都可以赚，而且各个运营商的需求大同小异，基本上一个项目做完了，你负责的那一块，例如telephony, bt ,wifi，该改的代码上一个项目已经改过了，现在重新拿过来复用一下就行了，基本出现的BUG也是类似，上一个项目分析过这个问题，现在同样的问题再次出现，也是看看就会的。
还有一个原因就是：谷歌对于android系统的不断升级，笔者刚毕业的时候，android版本最新的还是4.4 现在已经到O了，每一次升级系统，连带着整个生态圈大地震，可以说android系统的升级是整个生态圈齿轮转动的原动力。每一次升级，市面上所有的手机都要跟着升级。
或者是 硬件 或者高通这样的厂商开发了新的平台，例如：硬件可以做的更省电，摄像头可以 做的更小，拍照更清晰，新技术的出现导致硬件价格下降， 新的解决方案可以弥补之前存在的问题等等诸如此类。
总之一句话：硬件和软件的升级 带动整个生态圈向前发展，并且衍生出除了智能手机以外的其他范畴，例如：可穿戴设备，机器人，自动化，车载等等。
说完了生态圈，笔者再来写一写作为一个普通的移动终端开发者的一些体会。
笔者是做android软件开发，专门负责系统里的某一个模块，从最上层的app,到最底层的硬件都有涉及。
平时使用的工具：ubuntu系统，git+repo+gerrit+opengrok+cmweb+bugzilla+jenkins+jira eclipse android studio 使用的语言 java C++ C shell脚本 arm汇编指令 gdb调试等等
简记为一句话就是 测试给我提BUG 我分析BUG，给出解决方案（1.BUG需要提patch解决 2.BUG本身是work as design,就是这么设计的 3.BUG是其他模块导致的，直接踢给别人 4.BUG是由自己之前的改动导致的 5.BUG之前解决了，现在又重新复现了 6.BUG和某一个或几个其他的BUG是同一个问题，原因相同，可以合并 7.BUG是由于高通等等没有及时给出反馈，目前等待中的 等等） 然后测试关闭BUG
平时做的最多的就是提patch 去修复问题，一个完整的patch（组）应该是下面这样
找到问题发生的根本原因，root cause,给出自己的patch,做代码修改，这个改动首先是保证修复当前的问题，编译能通过，这个改动进库后不会引入新的问题，不会破坏其他的模块，代码格式遵循android编码规范，下面逐一说明：
修复当前的问题：这个是最基本的，如果它不能彻底修复当前的问题，或者它进库后BUG的发生概率明显降低，或者问题很难解决，仅仅是为了避开这个问题而做的改动，只能算是临时的workaround, 注意：workaround在平时解决问题也是经常用到的，尤其是 发布前期，或者短时间没有好的解决方案 或者是其他模块没有完成，暂且避开编译问题等等。
编译能通过：这个非常重要，因为android开发是一个多人协作开发的项目。就我现在知道的 就 二三十人开发，遇到编译不过的问题，稍微分析一下就知道是谁的问题了，可以给他提醒，让他马上更改，让编译通过。 但是笔者之前接的活是大牌公司，核心开发团队在日本东京，测试团队在东京和大陆，BUG解决团队在大陆北京（包括衍生的其他大陆城市），部分开发团队在 伦敦， 整个完整的开发和测试在不同的国家和不同的城市，其中时差相隔，用的是同一套系统，发布版本都是自动化编译，并且有不同的分支。 举个例子：我作为其中一个普通的开发者，如果我提了一个编译不能通过的patch入库了，会导致什么问题。自动发布版本的编译系统不能编译出版本，当天所有人在jenkins上想验证自己的patch是否有问题，所有起的jenkins都编译失败而停止了，第二天，所有负责开发的人员来到公司，想验证自己patch的 在jenkins上无法编译，所有的测试想在最新的版本上测试自己的case却因为无新版本发布，他们一整天都无所事事。一个人的失误导致 不同国家不同城市的人 在接下来的1天或者2天都不能按时完成工作。
关于编译能通过：我上面用了一个patch(组)， 尤其是patch组，例如你在frameworks层做了改动，在hal层有一个改动和这个是一起的 那么这两个改动要同时进库。或者 为了降低耦合性， 在同一个project下为了修复一个问题，提了多个patch,它们也是要一起进库。
改动进库后不会引入新的问题，不会破坏其他的模块：改动进库后，不会导致本模块有新的问题产生，同时与本模块相连的其他模块也不会有新的问题发生。笔者曾经遇到过一件事：其他模块的人为了解决一个问题，在手机进入飞行模式后，彻底禁用了手机SIM卡，结果这个傻帽导致我这边在飞行模式下想读取SIM下的信息失败了。
代码遵循android编码规范：这个也很重要，好的格式可以让人一眼就看出了改动的部分。尤其是在gerrit上查看时。具体如下：commit message写的尽可能详细，通常写法如下：标题简短的一句话说明修复了什么问题，可以包含模块的名字。内容分为三个部分：一、描述问题，问题发生的场景带来的后果 二、当前这个改动是怎么解决这个问题的 三、列出这个问题的BUG号及来历（例如从其他的patch cherry-pick而来的）。内容部分：命名，括号，空格，代码缩进（一律不用TAB键，而用4个空格），空行等等，总之保持同源码一样的风格，头文件 包名按照字母顺序从上到下，不该加的空行 空格一行一个都别加。
好记性不如烂笔头，经常做笔记。
最后一点 解决问题的思路：
1.所有的分析都是基于代码和log 不要凭空猜测和捏造
2.对于和其他模块相关的，发现是自己的问题，就不要推给别人，更不要自己做了改动影响别人，推给别人的问题一定要基于log有自己的分析，有理有据
3.在解决某一个问题时，发现除了这个问题，还有异常的log，也要分析异常的log，不要测试没有报出来，就了事
4.解决BUG的最好方式就是从源头上根治，就是新添加的代码不要影响原有的功能
5.实在解决不了的问题，最简单的办法就是做回退测试，找到差异的patch, 进而找出原因
6.除了自己负责的部分，与自己相关的部分也要熟悉
7.多与其他人交流，不要自己闷在那里对着log毫无头绪
8.按照上述 提一个好的patch(组)，除了自己严格要求自己，还要将相关的人加进来review你的代码和patch
9.很多其他的模块的patch 自己可以review别人的代码，来提高自己
10.生活永远比工作重要，不要为了解BUG而熬到深夜