4

《深入理解Android:Wi-Fi,NFC和GPS》章节连载[节选]--附录(和审稿专家的讨论与思考)

 3 years ago
source link: https://blog.csdn.net/Innost/article/details/20280565
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

《深入理解Android:Wi-Fi,NFC和GPS》章节连载[节选]--附录(和审稿专家的讨论与思考)

首先感谢各位兄弟姐妹们的耐心等待。本书预计在3月中旬上市发售。从今天开始,我将在博客中连载此书的一些内容。注意,此处连载的是未经出版社编辑的原始稿件,所以样子会有些非专业。

附录为笔者和审稿专家之一的吴劲良先生关于本书定位、学习方法等方面的讨论。相信这些讨论内容能引起读者的共鸣。

附录的内容来自笔者和吴劲良先生的几份讨论邮件,此处略有修改。

[-->笔者发给吴劲良先生的邮件]

我有几个问题想和你深层次讨论下,就是关于这本书的定位:

我先说说我的看法:

1)对于初学者(就是完全没有wifi,nfc,gps经验的人),这本书肯定是入门书,但是它的难度比普通意义上认为的入门书难。

2)对于中级学者,这些人定位在1-2年或者那些有过实际改bug的经验,但是缺乏全局理解的人,那么这本书也合适。不过,可能有部分内容对他们来说比较简单。另外,关于NFC和GPS的知识,从我们统计的情况来看,NFC和GPS的问题非常少。从面试情况来看,对NFC芯片的datasheet的了解(GPS应该是没有这方面公开的资料)也很重要。不过本书没有考虑NFC,GPS以及Wi-Fi HAL层的内容。一方面我感觉Wi-Fi驱动层和协议结合非常紧密,有点钻研精神的读者在本书基础上,再加上一些驱动经验就可以搞定。而NFC HAL层未来发展趋势可能会和wpa_supplicant一样,即不会出现NXP,Broadcom这样太过特定的内容。GPS一般不太可能让外人看到驱动的代码了吧?我专门看过QC开源项目Codeaurora[①]中GPS的HAL代码。它是C/S架构的,只有Client端内容,而且都是简单的发些命令,然后接收回复,没有核心的东西。

3)对于高级学者,例如那些经验和理论知识都比较到位的人,那这本书唯一的优势可能就是当做参考书来看了,不过内容相对会浅显点。

另外,昨天和Eva沟通后,觉得本书没有太多实际经验,确实如此。我自己定位这本书还是想打通整个知识面,实际经验的话,需要理论联系实践。现在很多工程师只有实践,没有理论,或者理论关注较少。另一方面,如果专门讲实践,这种书反而价值不高,因为可操作性太低。它不像网管类的书籍,一步一步跟着做就行了。

这是我对本书定位的一些看法,吴兄,你能否从一线工程师,培养新人等多个方面讲下你的感受么?不足之处也提出来哈。

最后,写完这本书后,我感觉在Wi-Fi、NFC和GPS这几块,核心都是芯片厂商做好了,我们唯一可做的就是改改bug,攒足实战经验,似乎可发挥的地方非常少(NFC CE模式还有很多发挥空间,尤其是安全交付解决方案之类的)。吴兄,对这个问题又怎么看呢?

诚挚欢迎吴兄的金玉良言!

[-->吴劲良先生的回复]

1)正如邓兄说提到,这本书对不同知识深度的学者而言,会有各自的收获,可引初学者入门,可给中级学者问题分析的线索,可给高级学者一个知识思索的机会(对比自己的理解和补充下知识),书就起抛砖引玉的作用,不同的读者收中收获多少还得看个人,多思考的读者还可以从书中学习到邓兄分析问题的思路、会反思如何提升自己的搜索的技巧。

2)这本书是理论分析为主,没具体问题的解答,但是我觉得够了。这不是一本Q&A的书,WiFi、NFC、GPS这三大部分,Android涉及的主干支知识都有,读者可以做选择性的深入分析,各个人对知识点的追求都不一样,很难满足所有人的需求,就个人而言,我会对android Wi-Fi的休眠策略、Location的网络定位感兴趣,这跟实际工作遇到的问题相关。

3)“NFC和GPS问题非常少”,这会跟功能模块是否被广泛使用和应用的广度有关,被使用多了可能会暴露多些问题,应用场景多也会促使功能的开发,自然会引出新问题。GPS HAL的代码各厂家都不提供,Broadcom、MTK、RDA均只是提供so,有可能是涉及到核心技术,估计是一些Command的实现,GPS一般是UART接口,UART只负责上层与模组的数据通讯。

4)对于负责无线模组的新人,我对他们工作的安排是:先做功能的验证测试,让他从测试中加深对功能点的理解,知道哪些点是容易出问题;然后会给一些已经调试ok的模组让其单独去调试,目的是熟悉调试一个模块需要做哪些工作;最后会渐渐的让其承担一些实际任务。学习的安排是:学习NL802.11,USB、SDIO、UART和I2C等模组接口驱动的分析,然后会从内核往Android学习,如:Wi-Fi driver->netd->wpa_supplicant->HAL->framework,Android会安排一些核心知识点的学习,主要是理清工作的机制。最终是希望新人在头脑有有一幅Android网络结构图,并能将其画出来。

5)由于需要先确保相关的外围模组能配合主控使用,这也决定平常无线工作的重点会在模组的移植调试上,涉及的内核驱动的调试较多,现在android做得越来越完善,大问题很少,小问题还是有,但解起来还好(Android4.4上Wi-Fi目前测试出原生代码有几个bug,较严重的一个是在关闭Wi-Fi时没关闭supplicant创建的socket,每次打开Wi-Fi时又创建,socket打开个数累积超过65536时,后续操作将失败)。

6)无线模块Wi-Fi、BT、NFC和GPS,核心的技术是在芯片厂,而且是在芯片设计中,driver的编写只是其中的很小一部分,即使是相对复杂的Wi-Fi Driver,投入两三个人,花两个月的时间把driver写出来是完全没问题。这个我也认同发挥的地方很少,除非是从应用角度去开发新的功能或做一些功能创新。但从工作的角度看,要把这些无线模块支持好,也不是不容易,调一款新的Wi-Fi就像在弄一个小系统,需要把系统调稳,没有bug并可以达到量产的标准,这往往会耗上一两个月的时间。虽然发挥的地方是少,但当前看这方便的技术人员的需求还是挺大的。


[①]https://www.codeaurora.org/,上面可下载高通参考设计(QC Reference Design)的代码。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK