JasonWang's Blog

以下是从事软件开发以来收藏的资料/书籍/网站, 欢迎推荐~

基础

• Linux C一站式学习: 收藏已久, 值得一看
• Code: The Hidden Language of Computer Hardware and Software: 最开始学单片机时就对CPU是如何执行代码, 如何解析代码并正常运营感到疑惑, Code这本书正是从零开始解释了计算机内部是如何工作的, 看了两遍, 感觉都很过瘾, 值得学习
• Computer Systems: A Programmer’s Perspective: 从计算机基础原理讲起, 阐述了计算机的原理, 内存/网络都有涵盖, 想进入软件行业的入门比读书之一; 平时也可以作为参考书籍不时翻一翻.

投屏是指将某个终端的音视频或者其他内容通过有线或者无线的形式投射到其他终端上的一种协议。目前常见的投屏协议有DLNA/Airplay/Mirracast/Chromecast:

• DLNA(Digital Living Network Alliance): DNLA是由英特尔、索尼、微软等消费电子巨头在2003年建立的一个文件共享协议，目前很多的电视都会支持DLNA协议，用于手机与电视之间共享视频与图片等资源。
• Airplay: Airplay是苹果公司开发的一个私有的投屏协议，实际包含了视频投屏与屏幕镜像等几个功能(音视频数据流包括交互控制协议都有是加密的)，可以用于播放音频、视频，也可以把本地的图片投屏到电视上进行浏览。目前国内很多支持Airplay的投屏协议都是基于秘钥破解进行开发的。

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的带宽。

创造力 = 能力 × 热情 × 思维方式

• “能力”是指努力学到的知识、经验和技能
• “热情”是指工作时所有的激情和渴望成功等因素
• “思维方式”则指对待工作的心态、精神状态和价值偏好

一个人和一个企业能够取得多大成就，就看三个因素的乘积

稻盛和夫

这是Linux网络优化系列的第四篇文章，也是最后一篇了。最近有点忙，没有抽出时间来梳理这些知识点, 看了下文章历史，这个优化系列文章前后持续了大半年时间，今天总算达成了目标*_*。

背景

自从互联网诞生以来, 音视频(Audio/Video, AV)在网络上传输已经是稀松平常的事情. 那么, 为什么还需要一个新的基于以太网的协议来传输AV数据了? 传统的音视频传输都是点对点单向连接, 比如音频通常使用I2S或SPDIF/AES; 视频则使用SDI或者HDMI, 这种专用的单向连接在多设备情况下往往容易出现杂乱无章的连接线束:

最近开发投屏功能，需要对H.264视频数据流进行解码，然后显示出来。Android原生的MediaCodec虽然使用了硬件解码，但是延迟较大（超过300ms），无法满足要求。于是研究了下如何基于FFMPEG来做视频流的软解码。这里对整个过程做简要的总结，看下如何在Android Studio中完成FFMPEG的视频解码:

• 简单介绍下FFMPEG框架
• 如何利用交叉编译生成所需要的FFMPEG共享库, 以及如何进行Android Studio的配置
• FFMPEG解码H264的大致调用流程