Android Weekly #38 ：Android 13 正式发布

Tips : 由于微信公众号外链限制，大部分文章链接都无法直接访问，推荐大家订阅 NewsLetter 来获得更好的阅读体验，或者访问网页端或者知乎专栏 (点击原文即可)

技术文章

过去一周 Android 相关的技术文章精选，以及过去一周发现的经典文章

1. 从 Kotlin 开发者角度看 Java 缺失的特性 : 虽然 Kotlin 也被编译为 JVM 字节码，但有时候我还是不得不写一些 Java 代码。每次写 Java 代码时，我都不禁想，为什么 Java 代码看起来没有 Kotlin 那么好。我很想念那些可以提高代码可读性、表现力和可维护性的特性。这篇文章并不是要抨击 Java，而是要列出一些我希望也能在 Java 中找到的特性。

2. 最新版发布 | Android 13 现已正式发布至 AOSP！ : 今天，我们将 Android 13 的源代码推送至 Android 开源项目 (AOSP)，并正式发布最新版本的 Android。对于开发者来说，Android 13 聚焦于我们的核心主题，即隐私和安全，以及开发者生产力，帮助您更轻松地为用户构建优良的体验。我们还继续使 Android 成为更适合平板电脑和大屏幕设备的操作系统，为您提供更好的工具，让您得以充分利用世界各地正在广泛使用的 2.7 亿多台此类设备。

3. 升级也要图个明白：8000 字详解 Android 13 正式版的 9 个新变化^[1] : 这篇文章中，我们还是以正式版的体验为参考，梳理 Android 13 值得关注的亮点更新和重要变化。希望不久后手机厂商基于 Android 13 的定制系统正式推送到你手中的设备时，你能有个对比和参考。

4. Android 13 changelog: A deep dive by Mishaal Rahman^[2] : 本文记录了我们在安卓 13 中发现的所有变化，以便开发者可以准备他们的应用程序或设备，而用户可以知道对新版本的期望。尽管谷歌没有公开记录安卓 13 中的许多变化，但我们还是不厌其烦地梳理了安卓开发者文档、AOSP Gerrit 和其他来源，将安卓 13 中的所有新内容整理成了一份全面的变化日志。

   要浏览这篇文章，我们强烈建议使用目录来浏览各部分。目录包括每个章节标题的超链接，所以你可以快速导航到一个特定的章节。如果你在桌面上浏览，你可以通过点击左边侧边栏的链接轻松返回到目录，如果你在移动端浏览，可以通过点击屏幕右下方的箭头返回。

5. Android 13 ：Features and APIs Overview^[3] ：Android 13 为开发者引入了伟大的新功能和 API。下面的章节帮助你了解你的应用程序的功能，并开始使用相关的 API。

   对于新的、修改的和删除的 API 的详细列表，请阅读 API 差异报告。关于新的 API 的细节，请访问 Android API 参考--新的 API 被突出显示，以提高可见度。此外，要了解平台变化可能影响你的应用程序的领域，请务必查看针对 Android 13 的应用程序和所有应用程序的 Android 13 行为变化。

6. Android 13 运行时权限变更一览 ：一篇 Android 13 的运行时权限变更一览，带你全面了解 Android 13 的所有运行时权限变更。

7. Android 筑基导论^[4] : 编程这条路能走多远，能走多久，就看一点：你学不学的明白。想学明白，就得看你会不会学习，所以编程能干多久，你值多少钱，最终看你会不会学习

8. Introducing the MAD Skills series on Performance^[5] : Performance spans every aspect of Android development, and as part of Modern Android Development we’re aiming to make it more approachable and user-friendly. We have also found direct correlations between improved app performance, user satisfaction and business metrics

9. 从 47%到 80%，携程酒店 APP 流畅度提升实践 : APP 性能提升一直是研发团队永恒的主题。在进行 APP 性能优化实践中，除了性能技术方案本身外，还会面临两方面问题：第一，APP 的性能优化，不具有持续性，往往经过一段时间优化实践，效果明显，但是随着后续需求迭代和代码变更，APP 性能很难维持在一个较好的水平上；第二，APP 性能改善提升，缺乏一套科学量化手段进行衡量。

   引⽤管理学⼤师彼得•德鲁克的⼀句话：If you can’t measure it, you can’t improve it，如果你⽆法度量它，你就⽆法改进它。基于此，携程酒店前端 APP 团队进行了深入思考和探索，希望通过量化，治理，监控三方面手段，持续改善 APP 性能和用户体验。

10. 了解 HTTP 看这一篇就够 : HyperTextTransferProtocol 直译为‘超文本传输协议'

    所以对与以上的问题可以有这样的总结：http 是一个在计算机世界里专门在两点之间传递文字、图片、音频、视频等超文本数据的约定和规范。

1. 超文本：指文字、图片、视频、音频等的混合体，比如最熟悉的 html。
2. 传输：http 是一个“双向协议”，传输的是请求方和响应方之间的数据，不限制请求方和响应方之间的角色，传递的过程中可以存在任意“中间人”。
3. 协议：协是两个或多个参与者之间的交流，议是指对参与者之间的约定和规范。所以，http 协议可以理解为作用在计算机之间，使用计算机能够理解的语言确立计算机之间交流通信的规范，以及相关的各种控制和错误处理方式。

11. 全方位带你彻底搞懂 Android 内存泄露 | 案例分析 : 从原理和实战角度分析 Android 内存泄漏

12. Binder 中的 SEAndroid 控制 : Binder 也即 Android 独有的进程间通信方式，在 Android 系统中无处不在。区别于共享内存、socket、管道等其他进程间通信的手段，Binder 的实现较为独特。从本质上讲，Binder 是借由对/dev/binder 的一系列操作实现的，在内核中作为驱动存在，当然其权限控制可以正常借由 Linux 的安全模块实现。同时，由于所有系统服务都需要在 ServiceManager 类中进行注册，考虑 ServiceManager 总揽 Binder 的支配地位，又要对其中的权限控制进行特殊设计。

13. Ftrace function graph 简介 : 本文介绍了 ftrace 的 function graph tracer，通过在函数的调用开始及调用结束分别调用了 prepare_ftrace_return 及 ftrace_return_to_handler 来进行 LR 的修改与恢复。这样可以统计到每一个函数的调用关系与具体执行时间（在开始与结束时分别记录了时间）。该功能可以帮助读者在性能调试的时候识别到性能瓶颈，以便于后期的进一步性能优化调优。

14. 读写信号量 : 文中所讲的有很大一部分都是源码，很细节的东西。如果大家看的云里雾里的，不要怀疑自己。尽管文档是我一字一句写出来的，并且反复回味了非常多遍，但是我在碰到很细节的问题时，仍然要回头再去看文档的描述才能弄清楚原因。对于读写信号量，我的建议如下：

    1.只想了解个大概。可以看下 rwsem 的结构，osq 的概念，搞懂 reader/writer 持锁后，又有 reader/writer 进来持锁以及有乐观自旋任务的情况下，会有哪些可能即可。2.想深入弄懂原理。对着代码好好研究一番。rwsem 还是会复杂一些，弄清除了这个，再看其它锁的实现时，应该会更得心应手了。

15. 超标量处理器 : 处理器（central process unit,简称 CPU）是手机的核心部件，其主要功能是取指令并译码执行。CPU 主要包括控制器和运算器两个部件，它对在手机中的所有硬件资源（如存储器，输入输出单元）进行控制调配，执行运算。在系统中所有软件层的操作，最终都将通过指令集映射为 CPU 的操作，因此，它的性能高低直接影响着用户的体验。

    得益于半导体工艺的进步，架构的演进，CPU 的性能不断地提升。然而，应用程序（APP）的不断发展对处理器性能有了更高的要求，要使得 APP 运行的稳定、流畅，软件工作者要深入理解处理器的微架构，理解指令的执行过程，做出一些更精细化的改善和优化。

16. MediaCodec 在 Android 硬解码的路线 : 随着多媒体产业的发展，手机端对视频解码性能要求越来越高。如果采用 cpu 进行解码，则会占用很多 cpu 资源。现在主流做法是利用手机 gpu 资源进行视频解码。

    Android 系统在 Android4.0(API 16)增加了 MediaCodec，可以支持 app 调用 java 接口，进而使用底层硬件的音视频编解码能力。Android ndk 在 Android 5.0(API21) 提供了对应的 Native 方法。功能大体相同。

    MediaCodec 可以处理编码，也可以处理解码；可以处理音频，也可以处理视频，里面有软解（cpu），也有硬解（gpu）。

17. Flutter 长截屏适配 Miui 系统，一点都不难 : 现有 App 大部分业务场景都是以长列表呈现，为更好满足用户内容分享的诉求，Android 各大厂商都在系统层面提供十分便捷的长截屏能力。然而我们发现 Flutter 长列表页面在部分 Android 手机上无法截长屏，Flutter 官方和社区也没有提供框架层面的长截屏能力。

    闲鱼作为 Flutter 在国内业务落地的代表作，大部分页面都以 Flutter 承接。为了闲鱼用户也能享受厂商系统的长截屏能力，更好的满足商品、社区内容分享的诉求，闲鱼技术团队主动做了分析和适配。

18. Lyft 团队新突破 | 借助 Android Vitals 缩短启动时间，提高用户体验 : Lyft 致力于打造优秀的应用。作为一家网约车公司，Lyft 需要确保为数千万乘客和数十万司机提供时效性强的服务。因为市场规模巨大，应用的每一次运行缓慢、卡顿或崩溃都会浪费数千名用户的时间。即使一个小问题也可能带来不少用户流失。幸运的是，Lyft 的开发团队一直密切关注应用性能，这也帮助他们第一次注意到司机端 Android 应用启动变慢的问题。

    他们要迅速找到问题的根源并提出解决方案，向领导层证明这一投入是值得且合理的。这意味着团队需要回答一些棘手的问题: 新方案瓶颈在哪里、如何影响用户体验以及对团队有多重要。值得庆幸的是，他们有一个强大的工具可以帮助他们找到答案。在 Android Vitals (可以提高 Android 设备应用稳定性和性能的 Google Play 工具) 的帮助下，他们确定了问题所在，也就有了充分理由说服领导层将其提上日程并投入相应的资源。

19. Build a Real-Time Android WhatsApp Clone With Jetpack Compose^[6] : 在社交信息应用程序中，可靠和强大的聊天功能是必不可少的部分。在这篇文章中，你将学习如何使用 Jetpack Compose 和 Stream 的多功能 Compos Chat SDK 建立自己的实时 Android WhatsApp 项目。此外，你还将学习 WhatsApp-Clone-Compose 项目中使用的整体架构、每一层和主题设计。

    在你开始学习之前，我们建议用下面的命令在你的本地设备上克隆 WhatsApp-Clone-Compose，然后用你的 Android Studio 打开该项目:git clone https://github.com/GetStream/WhatsApp-clone-compose.git

20. 货拉拉 iOS 司机端线程治理总结 : 由于在过去几年，货拉拉业务高速发展的同时，作为核心业务入口的司机端，同样在以「快」为第一目标实现业务需求迭代，积累了较多的技术债（各项技术指标与业界优秀的 app 相比都差强人意），并且线上经常会收到司机反馈手机发烫，耗电，crash 等等问题。

    司机使用的手机相比用户来说性能普遍较差，同时司机的在线时长较高（平均 3.5 小时），由于以上客观原因的存在，给司机端性能优化带来了巨大的挑战。

    综上，线程治理专项应运而生，目的就是降低 crash，手机发烫，耗电等问题，尽量给原本并不富裕的内存，雪中送炭。

21. 六万字 | 深入理解 Linux 进程调度 : 什么是调度？调度是 CPU 资源管理器。操作系统的作用之一就是系统资源管理器。CPU 是计算机系统中最重要的资源，当然也要管理。所有进程的运行都需要 CPU，对 CPU 该如何管理呢？对于直接共享型的事物，我们有两种管理方法：一种是时间分割管理，另一种是空间分割管理。由于 CPU 自身的特性，没有空间分割相似性，只有时间分割相似性，所以我们只能对 CPU 进行时间分割管理。对 CPU 进行时间分割管理的具体做法就叫做进程调度。

22. Velocity Based Animation with Compose^[7] : 当涉及到用户体验时，你是否对精细的细节有敏锐的眼光？在实施设计时，你是否试图多走一步，让它更加闪亮？我也是。

    本文将介绍一个在基于触摸的操作系统（如 Android 和 iOS）中很常见的概念，但由于我从未遇到过任何讨论使用这种技术进行简单的 UI 调整的材料，我想它值得有自己的文章。为了本文的目的，我把这个技术称为基于速度的动画。

23. “终于懂了” 系列：组件化框架 ARouter 完全解析（一） 原理详解 : ARouter 确实是专门用于做组件化改造，官方是这么介绍的：一个用于帮助 Android App 进行组件化改造的框架 —— 支持模块间的路由、通信、解耦.本篇就先梳理 ARouter 的实现原理，看看它是如何做到跨组件跳转页面、获取服务。

24. “终于懂了” 系列：组件化框架 ARouter 完全解析（二）APT 技术 : 在上一篇《“终于懂了” 系列：组件化框架 ARouter 完全解析（一） 原理详解》中，详细介绍了 ARouter 的核心原理。其中提到了“帮助类”的概念，也就是在运行时生成 用于帮助填充 WareHouse 路由元信息的类，这里就涉及到了 APT 技术。那么本篇就对这一技术点进行介绍，并详细分析 ARouter 中是如何使用 APT 来生成帮助类的。

25. Maeiee Weekly No.8：给红米 9A 编译 Android 系统^[8] : 本文适合于对 Android 系统感兴趣，但是没有相关经验的同学进行入门。

26. 五万字 | 深入理解 Linux 内存管理 : 内存是计算机最重要的资源之一，内存管理是操作系统最重要的任务之一。内存管理并不是简单地管理一下内存而已，它还直接影响着操作系统的风格以及用户空间编程的模式。可以说内存管理的方式是一个系统刻入 DNA 的秉性。既然内存管理那么重要，那么今天我们就来全面系统地讲一讲 Linux 内存管理。

27. 站在 Google 角度看渲染机制，从 Android 渲染体系设计到 Flutter 渲染体系设计 : 本文将介绍 Android 的渲染机制。主要是带着大家了解 Android 是如何绘制并显示一帧图像的，同时会涉及 Skia 底层渲染的使用，以及关联到 flutter 的 UI 体系设计，感兴趣的可以在阅读的同时使用 Skia 自己搭建一套 flutter UI 体系 进行尝试。在大厂里渲染机制一直都是绕不开的话题，不管是工作中、还是面试中。

28. Hummer 引擎优化系列 - Flutter SurfaceView 动态切换方案 : 因为很多应用在使用 Flutter 上是一种同时使用原生和 Flutter 的混合模式，所以较大概率还是选择了性能较差的 TextureView 而不是 SurfaceView 去规避一些渲染瑕疵的问题。虽然我们在 Hummer 上也针对 TextureView 的一些问题做了性能优化，但是由于 TextureView 和 SurfaceView 在基础渲染机制上存在较大的差异，SurfaceView 对比 TextureView 还是存在很多优势。

    我们也考察了某些业务较为简单的 Flutter 使用场景（FlutterView 全屏，大小位置固定，不需要跟 Native View 做半透明混合），是否存在使用 SurfaceView 的可能。考察的结果是，虽然直接使用 SurfaceView 存在一定的问题，但是如果引擎提供一种可以动态切换 TextureView/SurfaceView 的机制，在绝大部分情况下，是可以使用上 SurfaceView 的。那么问题就回到了我们作为引擎的开发者，是否能够提供一种动态切换的机制，让应用在需要时可以将 FlutterView 内部使用的 TextureView promote 到 SurfaceView，或者将已经 promote 的 SurfaceView 再 fallback 回 TextureView。而且这个 promote/fallback 的过程足够高效，基本无阻塞，不会导致卡顿，并且是无缝切换，不会有闪烁，闪黑，闪白等现象。

    在后续文章中，我们会先从渲染机制的原理说明使用 SurfaceView 的优势，然后再说明我们的 SurfaceView 动态切换方案，和提供给应用的 API。

29. 移动端算法优化|GPU 优化技术-OpenCL kernel 开发 : OpenCL 程序由 host 端运行时 API 调用和 OpenCL kernel 两部分组成，在 《GPU 优化技术-OpenCL 运行时 API 介绍》中我们已经对 host 端运行时 API 做了系统而详细的介绍，接下来我们开始 OpenCL kernel 部分的介绍。

    OpenCL kernel 是运行在设备端的，采用 OpenCL C/C++ 语言进行开发，本文接下来首先给出一个简单的 OpenCL kernel 样例，然后对 OpenCL C 语言的各个部分做详细的说明，最后会给出一个完整的 OpenCL 程序实例，相信通过本文的学习之后大家应该可以在实际工作中使用 OpenCL 来优化程序的性能。

30. Jetpack Compose 到底优秀在哪里？| 开发者说·DTalk : 单纯看官方的介绍或者是网络上的文章，开发者也许已经对 Jetpack Compose 有这么一个印象了: 使用 Jetpack Compose 时我们可以深层次地嵌套布局而不用担心会影响性能。这是 Google 在介绍 Jetpack Compose 时经常拿来和原生 View 体系进行比较的一个特性，也是介绍其优势时的一个着重点，本文就来介绍这一方面的相关知识点，涉及到的内容有:

1. 原生 View 体系下，我们一直强调要减少布局的嵌套层次，那这么做的意义是什么呢；
2. Jetpack Compose 的布局模型
3. Jetpack Compose 如何实现自定义布局
4. Jetpack Compose 是如何避免多次测量的
5. Jetpack Compose 固有特性测量的作用，以及如何进行适配。

31. 通过性能指标学习 Linux Kernel - （上） : 本次圈定的性能指标是调度延迟，那首要的目标就是看看到底什么是调度延迟，调度延迟是保证每一个可运行进程都至少运行一次的时间间隔，翻译一下，是指一个 task 的状态变成了 TASK_RUNNING，然后从进入 CPU 的 runqueue 开始，到真正执行（获得 CPU 的执行权）的这段时间间隔。需要说明的是调度延迟在 Linux Kernel 中实现的时候是分为两种方式的：面向 task 和面向 rq，我们现在关注的是 task 层面。

32. 通过性能指标学习 Linux Kernel - （下） : 上期我们介绍了 atop 和 proc 统计调度延迟的原理，内核还存在很多的基础设施，这些基础设施都是强有⼒的⼯具，我们最终是要落地到 eBPF 中的，在 eBPF 中我个⼈认为关键事件是很关键的⼀环，因为 eBPF 太精准了，⽽它的精准是精准在内核中各个事件上。

33. 系统级 bug 解决分享：腾讯开发工程师刨根问底安卓端滑动异常^[9] : 本文分享的是笔者遇到的一个 Android 端滑动事件异常，从业务层排查到深入源码，从 Input 系统的 framework native 到 base 逐层进行分析。在翻阅 git history 逐个对比差异的过程中，定位到 Android 11 版本上一处有猫腻的提交，再经过一番死磕，最后真相大白，问题得解。并针对 Android 11 的提交进行修复，往 AOSP（Android 开源社区）上进行 commit，得到 google developer 对此问题的回复。写这篇文章的目的除了读者大致了解下 Input 系统，更重要的是为读者提供一种思路，面对系统级的疑难杂症该如何一步一步定位源码，找到深层次的原因。

34. MemoryThrashing：抖音直播解决内存抖动实践 : 直播 OOM 问题比较棘手难以定位，主要体现在涉及的业务很多，从定位到解决花费时间比较久。为了提前触达问题，提高定位的效率，也是对现有工具的补充，提出直播内存抖动解决方案- MemoryThrashing。为什么要提出这个方案 ？

1. 现有的 “MemoryGraph” 工具可以通过抓取的“MemoryGraph” 文件分析 OOM 成因，比如内存泄漏、内存占用过高导致的 OOM 问题，但因为性能开销很大，所以是采样上报且采样率很低，不容易触达问题， 只能定向对已知用户开启才行。期望自研一个工具，在内存增长时可以发现问题，也能用于 OOM 发生后的分析，同时具备性能开销小、全采样的能力；
2. “MemoryGraph” 生成时可能不是内存高位，比如设备内存是 4G，生成的“MemoryGraph” 可能是 1G，会影响 OOM 分析；

35. KeyValueX：消除样板代码，让 Android 项目不再 KV 爆炸 : Key Value 定义几十上百个是常见事，目前有更简便方法么，此为项目中为数不多不受控制之地，指数膨胀，且易埋下一致性隐患。有小伙伴提到 “属性代理”，并推荐了群友 DylanCai 开源库 MMKV-KTX

36. 手机性能优化工具的使用思路比较 : 系统分析优化工程师的工作职责跟 app 工程师有很大的不同，系统工程师需要具备 cover 住整个系统的能力。

    现在的嵌入式系统比如 android 的代码量有几千万行，而且系统架构搞得相当庞大复杂。搞系统性能优化的，嵌入式产品比如手机上随意出现个性能问题，可能都需要从 fwk 层(java 代码)一直搞到内核底层，然后到存储芯片层也需要熟悉(如果是搞存储性能优化的话)。所以系统工程师，尤其是搞性能问题解决优化的，需要调研关注的代码量相当庞大，不止 linux 内核。所以搞系统性能工作的，往往需要借助或者研发一些高效的工具来提升工作效率。好的工具对于性能工程师的工作质量提升是非常重要的。

37. 抖音 Android 性能优化系列：Java 锁优化 : ava 多线程开发中为了保证数据的一致性，引入了同步锁(synchronized)。但是，对锁的过度使用，可能导致卡顿问题，甚至 ANR。Slardar 平台（字节跳动内部 APM 平台，以下简称 Slardar）中搜索 waiting to lock 关键字发现很多锁导致的 ANR，仅 Java 锁异常占到总 ANR 的 3.9%。本文将着重向大家介绍 Slardar 线上锁监控方案的原理与使用方法，以及我们在抖音上发现的锁的经典案例与优化实践。

经验分享 && 推荐阅读

过去一周个人阅读和收藏的非技术文章精选，扩展 Android 之外的知识和视野，不要给自己设限

1. 【第 2703 期】软件架构手册 ：我们将讨论软件领域中的架构是什么、一些主要概念以及当今最流行的架构模式。

   对于每个主题，我都会给出一个简单、初级的理论介绍和代码或者伪代码示例，你可以从中了解每个概念是如何运行的。让我们开始吧！

2. 智能座舱 HMI 设计为什么需要关注人因学？ ：在智能座舱领域，人类和机器的关系可以抽象为下图，当人对机器越不信任，在辅助驾驶过程中会一直担心汽车出现问题，从而产生焦虑感和注意力分散，对变化的响应会越迟钝；当人对机器过度信任，在辅助驾驶过程中会太过依赖汽车的决策，渐渐地注意力分散到其他事情上，两种现象都不是我们希望看到的，因此什么是合理的人机信任以及如何校准人机信任将是设计辅助驾驶时很重要的课题。

3. 趋同 or 博弈？如何定义手机与智能座舱的角色关系？ ：今年 4 月，QuestMobile 发布一组数据，2022 年第一季度移动互联网月人均使用时间长达 162.3 小时，相当于大部分人每天在手机上花费 5 小时以上。

   甚至在汽车驾驶这样的场景下，人们也重度依赖手机，更愿意使用手机进行导航、收听音乐、远程会议等功能。而今天，随着汽车智能座舱技术飞速发展，“手机与智能座舱本身的角色关系如何定义？”成为大家讨论的焦点。

4. 深入浅出 NFT 系列 ：带你了解什么是 NFT

5. AI 绘画会不会抢画师饭碗 : 结论是不会抢饭碗。乐观一点来说，也许还会增加了大米供应。

6. 记录我曾经面试 Facebook（Meta） 的经历^[10] : 作者面试 FaceBook 的经历，不过最后没去，万恶的疫情

7. Google 软件工程之文化篇^[11] : 编程是利用某个编程语言实现某个算法或技术方案从而来解决某类问题，但这类问题规模一般很小，也不太会随着时间产生变化，或者其生命周期也很短，不需要考虑长期维护的问题。但软件工程与编程的区别在于前者需考虑时间与规模带来变化的影响。

   时间的因素使软件工程需要考虑质量的问题，糟糕的质量会产生很多认知负荷，最终难以长期维护。规模的因素使软件工程需要考虑协作的问题，低效的协作可能与沟通方式有关，最终拖垮交付进度。

8. 梁胜博士：写给程序员的话 : 本文为 Rancher Labs CEO 兼创始人梁胜博士应 InfoQ 之邀，为广大程序员专门撰写的个人职业发展心路历程及对程序员职业生涯规划的建议。

9. 从黑猫说起：社区文化到身份社交，Web3 的未来形态^[12] : 从蚊子到黑猫，他和社群的小伙伴们让这些小众项目出圈，也让整个 NFT 行业都看到了小众文化的力量。Adam 喜欢并擅长从文化和社交层面分析 NFT、挖掘 NFT 的潜力，他对 NFT 和 Web3 的认识令人耳目一新。Adam 喜欢通过 Web3 交朋友，也始终是 Web3 式社交最积极的践行者和开拓者， 让众多项目都通过社群实现了本身的价值。

   在这篇访谈中，他会和我们一同解析文化类 NFT，分析黑猫爆火的原因，探讨文化类 NFT 的终极形态。相信能给每位 NFT 玩家带来新的理解，也能帮助大家更早发现 NFT 的价值，获得盈利的机会。

10. 《代码英雄》第五季（1）：成为一个码农^[13] : 代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

11. 闲篇：个人职业选择的三种逻辑 : 最近频频和朋友聊到文科思维和理科思维，很多时候就是人本位和客观规律本位的一个分歧。但我又觉得似乎不止有这两种思考角度，还有一种并不完全人本位的，但也并不完全硬科学的思维逻辑。那就是政治、商业思维。更多关注的是宏观组织延续。

12. Androids: The Missing Pieces, Part I^[14]

13. The Team's Take: Why Android Worked^[15]

有趣的 Weekly

1. Android Weekly-532^[16]
2. Kotlin Weekly #316^[17]
3. onCreate Digest - Issue #122^[18]
4. Android NewLetter #119^[19]: For the past week, our algorithms crawled 1,451 resources over the web. We picked the Top #6 for you (0.41% chance).
5. Graphics Programming weekly - Issue 248^[20]
6. Now in Android #66^[21]
7. 我的周刊（第 053 期）:我的信息周刊，记录这周我看到的有价值的信息，主要针对计算机领域，内容主题极大程度被我个人喜好主导。这个项目核心目的在于记录让自己有印象的信息做一个留存以及共享。
8. 体验碎周报第 108 期（2022.8.15） : 系统的知识来源于对碎片的整理和思考，为了更好地输出系统知识，记录本周我发现的体验设计和思考，为构建系统知识做准备。
9. Android Stack Weekly — Issue #33^[22]

书籍播客推荐

今天要推荐的是播客 ：中东往事 - 一扇新的门

我们从奥斯曼帝国开始，历经她三个世纪的衰落，正是欧洲列强崛起，看英国，法国，意大利，沙俄与奥地利，将她蚕食。困兽犹斗，她怎样在一战之后最终倒下土崩瓦解，分崩离西。我们会去巴尔干半岛，问一问这个欧洲火药桶的前世今生，再到安那托利亚以东，见证亚美尼亚大屠杀的前因后果与整个过程。一路南下，进入圣城麦加，我们会再次见到 TE 劳伦斯，与他一起参加贝都因人的阿拉伯起义。透过哈希姆家族的阿拉伯之梦，却见沙特王朝的崛起。我们会站在凯末尔的身旁，看他如何以少胜多所向披靡，希腊人收复君士坦丁的梦想，却在士麦那的大火中，铸成了一个新的土耳其。

再让我们跳回到塔纳赫中的创世纪，看犹太的神话怎样成为经典，传说中的应许之地，流着什么样的奶与蜜。出埃及记到旦以理，亚历山大到大希律，马加比到提图斯，犹太人怎样失去自己的土地。十字军，黑死病，中世纪，犹太人两千年的大流散，却有着不散的记忆。从哈斯卡拉思想启蒙到复国主义。就在一切尽在掌握时，一战过后，却终看到的是人魔希特勒的崛起，带来的是纳粹妄想的荒诞无稽。二战中犹太人的一幕幕悲剧，二战过后欧洲满目疮痍，我们将看到日不落帝国的日落，与犹太国以色列的建立。

1948 年中东战火再起，从以色列的独立，到纳赛尔的埃及。西奈半岛与戈兰高地，巴解组织的法塔赫到穆兄会的哈马斯。旧狠新仇将巴勒斯坦推向一条不归路，一场场屠戮，一次次暗杀，留下的最终还是一个难破的残局，让我们去认识一种和平，她比战争更需要勇气。

回过头来再进入两伊，我们会去伊拉克与伊朗，从巴格达到波斯，两个古老的中东文明为什么会变成今天这个样子。八年的战火，多少少年死士，手中紧握天堂的钥匙。两伊两伊，再从海湾战争到九一一，萨达姆，霍梅尼，让我们穿越回去，探寻独裁者的成长之路，看一看强权与极端，熟高熟低。

工具推荐

AMA zing Talk

Ask Me Anything. 和有经验的人一对一咨询 : https://amazt.netlify.app/

对于初学编程或者刚入职场的程序员来说，常常有很多对技术和职业发展的困惑。作为有了一点经验的程序员，我们在业余时间乐于通过博客、播客等渠道分享我们对这些问题的理解。但是这些单向的分享对个人而言不一定是有效的解答。

因此我们几个稍有经验的互联网从业者有了做一对一咨询的想法，希望可以通过双向的交流，提供一些可能对你有针对性帮助的经验之谈。

这个网站用于收集一些提供咨询的从业人员，你可以对你感兴趣的人进行预约咨询。

定时打鸡血

NewsLetter

由于微信外链限制，很多文章链接都无法直接访问，推荐大家订阅 NewsLetter 来获得更好的阅读体验，或者访问网页端或者知乎专栏

1. NewsLetter 订阅地址：https://androidweekly.zhubai.love/
2. 本文 NewsLetter 地址(点击原文可直接到达)：https://androidweekly.zhubai.love/posts/2173193677780877312
3. 本文知乎地址：https://zhuanlan.zhihu.com/p/556313446
4. 个人博客地址：https://androidperformance.com/
5. 微信公众号：Android Performance

说明

所有文章来源：微信(公众号、朋友圈、群分享)、掘金、Google 搜索、Medium、Twitter、Github、即刻、竹白、知乎等，欢迎大家推荐或者自荐（微信私聊给我即可）

参考资料

[1]

升级也要图个明白：8000 字详解 Android 13 正式版的 9 个新变化: https://sspai.com/post/75272

[2]

Android 13 changelog: A deep dive by Mishaal Rahman: https://blog.esper.io/android-13-deep-dive/

[3]

Android 13 ：Features and APIs Overview: https://developer.android.google.cn/about/versions/13/features

[4]

Android 筑基导论: https://juejin.cn/post/6870111983933325319

[5]

Introducing the MAD Skills series on Performance: https://medium.com/androiddevelopers/introducing-the-mad-skills-series-on-performance-7dbb26e8b17f

[6]

Build a Real-Time Android WhatsApp Clone With Jetpack Compose: https://proandroiddev.com/build-a-real-time-android-whatsapp-clone-with-jetpack-compose-5a7024981cbc

[7]

Velocity Based Animation with Compose: https://dev.to/jamesmorrissey/velocity-based-animation-with-compose-538g?utm_source=dormosheio&utm_campaign=dormosheio

[8]

Maeiee Weekly No.8：给红米 9A 编译 Android 系统: https://www.maxieewong.com/Maeiee%20Weekly%20No.8%EF%BC%9A%E7%BB%99%E7%BA%A2%E7%B1%B3%209A%20%E7%BC%96%E8%AF%91%20Android%20%E7%B3%BB%E7%BB%9F.html

[9]

系统级 bug 解决分享：腾讯开发工程师刨根问底安卓端滑动异常: https://www.163.com/dy/article/GDU0B40U0518R7MO.html

[10]

记录我曾经面试 Facebook（Meta） 的经历: https://sichengingermay.com/facebook-interview/

[11]

Google 软件工程之文化篇: https://www.bmpi.dev/dev/software-engineering-at-google/culture/

[12]

从黑猫说起：社区文化到身份社交，Web3 的未来形态: https://mirror.xyz/0xdc308260A7BECCb3D0D8d188Bf1c16b68705F7fB/cKjWlZBNye2acjhfAGfV80nJXp3Ldp1gnqfQP07oXU0

[13]

《代码英雄》第五季（1）：成为一个码农: https://linux.cn/article-14133-1.html

[14]

Androids: The Missing Pieces, Part I: https://chethaase.medium.com/why-android-worked-83318dc40fd6

[15]

The Team's Take: Why Android Worked: https://www.chethaase.com/post/the-team-s-take-why-android-worked

[16]

Android Weekly-532: https://androidweekly.net/issues/issue-532

[17]

Kotlin Weekly #316: https://mailchi.mp/kotlinweekly/kotlin-weekly-316

[18]

onCreate Digest - Issue #122: https://www.oncreatedigest.com/issues/oncreate-digest-issue-122-1306484

[19]

Android NewLetter #119: https://dormoshe.io/newsletters/ag/android/119

[20]

Graphics Programming weekly - Issue 248: https://www.jendrikillner.com/post/graphics-programming-weekly-issue-248/

[21]

Now in Android #66: https://medium.com/androiddevelopers/now-in-android-66-9b4ca9dcd532

[22]

Android Stack Weekly — Issue #33: https://medium.com/canopas/android-stack-weekly-issue-33-bd6b6feb27e8