以下是从事软件开发以来收藏的资料/书籍/网站, 欢迎推荐~
Code这本书正是从零开始解释了计算机内部是如何工作的, 看了两遍, 感觉都很过瘾, 值得学习在讲虚拟化的第二篇QNX系统时，提到在QNX中设备的虚拟化有直通(pass-through)、半虚拟化(para-virtulization)、全虚拟化(full-virtualization)等几种形式，而像串口、网络设备、块设备等通常都是基于半虚拟化的形式实现的。在半虚拟化的实现方案中，virtio是最常见的一种。简单来说，virtio是虚拟化设备的中间抽象层，为设备的虚拟化提供了一个统一的框架与接口，增加了跨平台时代码的复用性。
QNX最初是Gordon Bell与Dan Dodge两人在1980年代初期创建的一个实时微内核操作系统(RTOS(Real-Time Operating System), 后来被黑莓(BlackBerry)公司收购，因此也叫做Blackberry QNX系统。QNX被世人熟知还是因为其高安全性、QNX hypervisor等特性在汽车领域的广泛应用。
这两年汽车领域在智能与域融合的推动下，开始兴起了各种虚拟化(Virtualization)的座舱解决方案，尤其以黑莓公司的QNX虚拟化方案应用最为广泛。说起来，虚拟化并不是什么新的概念，操作系统诞生之初就有了类似的原型: 对于一个分时的操作系统，通过在不同进程之间切换状态，给每个用户都制造一种完全使用整个机器的感觉，实则是操作系统通过进程之间的资源分时复用实现的结果。简单来说，虚拟化就是一种资源隔离与抽象的方案，通过对CPU、Memory、I/O设备增加中间层的访问控制，以达到与访问物理资源同等的效果。
投屏是指将某个终端的音视频或者其他内容通过有线或者无线的形式投射到其他终端上的一种协议。目前常见的投屏协议有DLNA/Airplay/Mirracast/Chromecast:
DNS(Domain Name System)即域名解析系统，是网络访问时用于将域名解析成对应IP地址的一种分布式网络服务。比如，要访问www.google.com这个域名，Android系统会首先发送一个UDP请求到标准的53端口系统的域名解析服务器，拿到对应的IP地址后才会与服务端建立连接。除了标准的DNS服务外，目前还有HttpDNS(DNS over Https, DoH)以及基于TSL的DNS服务(DNS over TLS， DoT)。
那么，Android中DNS解析的大致框架是怎么的？整个DNS解析的流程又是怎么样的？ 在看具体实现细节之前，我们不妨思考一下几个问题，想一想，如果我们自己从零开始为Android设计一个DNS系统，应该怎么做？
Those who cannot remember the past are condemned to repeat it
George Santayana
最近有同学在Android S(12)上遇到了一个奇怪的网络问题，说自己的audio HAL服务尝试通过以太网创建socket与其他局域网的节点通讯时，总是提示Operation Not Permitted。原先怀疑是Selinux的问题，但是目前在开发版本中selinux是完全关闭的；从问题发生的现象看，只有属于audioserver这个UID的进程才有问题，其他的如system/root的进程则没有问题。
据此，我们可以推断，audioserver这个UID的进程没有相关权限，所以导致无法使用局域网的网络。记得在早前的Android版本中，很多网络系统调用会通过netd代理进行权限检查，比如socket/connect/bind等系统调用都会先通过netdClient这个库的接口进行权限检查，而后才真正进行系统调用。
Work on stuff that matters:
- work on something that matters to you more than money
- create more value than you capture
- take the long view.
Tim O’Reilly
这两天质量的同学反馈说iperf测试时结果很差，跟实际的千兆带宽差别很大。确认了半天，发现内核的各项参数都已经完全按照千兆的目标速率进行配置了，那为什么还是会出现TCP/UDP带宽不足的问题？ 记得当时优化参数时，自己摸底测试的TCP结果挺好的，都达到了预期的900Mbps以上，看起来最近有什么修改导致了这个测试结果差异。
偶然的一个机会查看内核配置时，发现最近有人打开了trace功能，看起来很可能是这个修改导致了网络性能的下降了。拿早前未开启trace功能的版本一对比，果真是trace功能影响了TCP的带宽。
