技术文章
过去一周 Android 相关的技术文章精选，以及过去一周发现的经典文章
Linux 内核性能剖析的方法学和主要工具 ：计算机科学的先驱 Donald Knuth（高德纳）曾经说过：“过早的优化是万恶之源”，更详细的原文如下：“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.”它向我们揭示了一个道理，我们应该首先定位到那 3%真正成为瓶颈的代码，而忽略 97%那些“small efficiencies”，所谓“将军赶路，不打小鬼”，这是我们进行一切性能优化的前提。因此，剖析(profiling)，成为了性能优化中最重要的环节之一。
系统的性能优化不太是一个通过 review 几千万行代码，发现问题，然后更正问题优化的过程。而更多是一个通过某些剖析手段，把系统当成黑盒子，暴露数据，top-down 地看这个系统，在发掘问题后，再深入到白盒 down-top 的过程。《魏略》曰：“亮在荆州，以建安初与颍川石广元、徐元直、汝南孟公威等俱游学，三人务於精熟，而亮独观其大略。”性能优化本身，是一个从统帅诸葛亮逐步变身单兵战神吕布的过程，而你首先必须是统帅。
Compose 中的 "ViewPager" 详解 | 开发者说·DTalk ：ViewPager 的功能是可以使视图滑动，就像桌面左右滑动那样。写过 Android 的对它可谓是非常熟悉了，不管是轮播图的使用、亦或是页面之间的切换，都离不开它
浅谈协程:我们可以简单的认为：协程就是用户态的线程，但是上下文切换的时机是靠调用方（写代码的开发人员）自身去控制的。同时，协程和用户态线程非常接近，用户态线程之间的切换不需要陷入内核，但部分操作系统中用户态线程的切换需要内核态线程的辅助。
渲染引擎渲染性能指标设计[1]:对于应用来说，渲染性能或者动画流畅度主要是看两个指标 —— 帧率和卡顿率。帧率计算比较简单，没有太大争议，而卡顿率的计算，我们一开始是参考 PerfDog 的计算方式，但是研究后觉得跟我们的实际场景有一定差异。
所以我们在 PerfDog 的基础上对卡顿率的计算进行修正，这个新的卡顿率计算标准：
可以使用应用内渲染引擎收集的数据进行计算，适合在应用内运行；
更契合 UI/Web 的渲染场景，更真实反映动画的流畅度和用户对应用卡顿的感知；
TextureView 的血与泪（完整修订版）[2]:越来越多的应用需要使用自己的绘制引擎进行复杂内容的绘制，比如需要使用 GL 绘制 3D 的内容，或者绘制复杂的文档，图表时不希望阻塞 UI 线程，或者部分内容是通过类似 Flutter 这样的第三方 UI Toolkit 进行绘制。通常这部分内容会通过 SurfaceView 或者 TextureView 呈现在 UI 界面上。
一般来说 SurfaceView 能够提供更好的性能，但是因为 SurfaceView 本身的输出不是通过 Android 的 UI Renderer（HWUI），而是直接走系统的窗口合成器 SurfaceFlinger，所以无法实现对普通 View 的完全兼容。包括不支持 transform 动画，不支持半透明混合，移动，大小改变，隐藏/显示等时机会出现各种瑕疵等等，总的来说 SurfaceView 只适用于有限的场景。
TextureView 正是为了解决 SurfaceView 这些的问题而诞生，在使用上它基本可以无缝替换 SurfaceView，并且因为 TextureView 跟普通 View 一样是通过 UI Renderer 绘制到当前 Activity 的窗口上，所以它跟普通 View 基本上是完全兼容的，不存在 SurfaceView 的种种问题。
但同时正是因为 TextureView 需要通过 UI Renderer 输出，也导致了新的问题的出现。除了性能比较 SurfaceView 会有明显下降外（低端机，高 GPU 负荷场景可能存在 15% 左右的帧率下降），另外因为需要在三个线程之间进行写读同步（包括 CPU 和 GPU 的同步），当同步失调的时候，比较容易出现掉帧或者吞帧导致的卡顿和抖动现象。
TextureView 的血与泪 PART II[3]:我之前写过一篇文章 TextureView 的血与泪，讲述了在 TextureView 上碰到的各种坑爹事情，和我们的一些解决方案 ，像避免 TextureView 因为流水线调度问题而掉帧的优化方案也用在了我们的 Flutter 渲染性能优化上，并获得了一定的优化效果。不过 TextureView 的坑真的是踩也踩不完，最近又碰到不少相关的问题导致我们开始寻求其它替代 TextureView 的技术方案
[Flutter 渲染优化系列] Flutter 渲染性能问题分析[4]:我在Flutter vs Chromium 动画渲染的对比分析[5]一文中对 Flutter 和 Web (Chromium) 的各种动画的理论性能优劣进行了分析，其中一个主要结论是，由于惯性滚动处理机制和光栅化机制的不同，Web (Chromium) 的惯性滚动动画性能理论上要远远优于 Flutter。而在一些已经上线的使用 Flutter 的业务中，业务方也持续给我们反馈了这些业务在中低端 Android 手机上存在比较严重的惯性滚动性能问题
Android Studio Chipmunk 现已发布：我们非常激动地宣布推出 Android Studio Chipmunk 🐿 稳定版: 构建 Android 应用的官方 IDE！虽然此版本并未对功能做过多改动，但里面包含了最新的 IntelliJ 更新，而且我们还投入了更多的时间来提升质量和稳定性。仅在此版本中，我们便解决了超过 175 个质量问题。
Why should we use Use Case classes in our Android Projects?[6]：对于那些想开发 Android 项目的人来说，有多种项目架构选择。清洁架构就是其中之一。如你所知，当一个项目希望用 Clean Architecture 设计时，预计相关项目会提供一些架构原则。其中一个提到的原则是将你项目的业务逻辑转移到用例类中。那么，这些用例类是什么，它们有什么作用，以及为什么我们要在我们的项目中使用它们？
Android S 原生系统内存泄露问题案例：Android 里面内存泄漏问题最突出的就是 Activity 的泄漏，而泄漏的根源大多在于因为生命周期较长的对象去引用生命周期较短的 Activity 实例，也就会造成在 Activity 生命周期结束后，还被引用导致无法被系统回收释放。Activity 导致内存泄漏有两种情况：
本文主要讲的是最近发现的系统级 shouldShowRequestPermissionRationale 方法使用导致的内存泄漏问题
应用级：应用程序代码实现的 activity 没有很好的管理其生命周期，导致 Activity 退出后仍然被引用。
系统级：Android 系统级实现的对 activity 管理不太友好，被应用调用导致内存泄漏。
Android 逆向总结[7]：使用 DDMS、jdb 、插桩等方法来进行 Android 逆向
Flutter 高延迟渲染流水线调度：我们在 Flutter 渲染性能问题分析一文中分析了 Flutter 渲染性能，特别是惯性滚动性能的问题和原因。而通过高延迟渲染流水线调度，我们重构了 Flutter 渲染流水线的调度逻辑，通过更深的流水线深度来增加输出的吞吐量，使得输出更平稳连续。这也是目前若干优化尝试中效果最好的一种：
在这篇文章中，我会对高延迟渲染流水线调度机制进行解析，和说明为什么它会起到性能优化的效果。
在手机性能差，滚动速度快，帧率低的情况下有非常明显的性能提升，同时卡顿率也有明显改善（原本帧率在 35~45 这个范围，大约提升 10 帧约 20~30% 左右）；
手机性能较好，或者滚动速度较慢，原本帧率还可以的情况下，也有一定幅度的性能提升（原本帧率在 45~50 这个范围，大约提升 4~5 帧约 10% 左右，原本帧率超过 50 的，大约提升 1~2 帧约 2~5% 左右）；
在 Android 中使用 eBPF：开篇：若干年前，我还在做 Android 客户端性能优化的时候，读到了 OpenResty 作者章亦春老师的文章：动态追踪技术漫谈[1]，当时被深深地震撼到了，原来通过使用各种高级的调试技术，解决问题竟然可以做到如此精准而优雅。
然而当我真正要解决 Android 系统上应用程序的性能问题时，才发现理想很丰满现实很骨感——手头趁手的工具几乎没有。文章中提到的内核态追踪技术 SystemTap / DTrace 在 Android 系统上压根不存在，用户态的追踪技术开销大到可怕：TraceView 开启后程序性能直接下降十倍不止，Systrace 当时功能半残废，使用起来还需要自己插桩；simpleperf 能使，但就是有点 simple……到最后，真正要解决问题的时候，还是靠经验、二分法和 inline hook；为了定位 Android 虚拟机的性能问题，我甚至还自己造了个 ART HOOK 的轮子[2]。
然而，时间来到 2022 年，世界已焕然一新：eBPF 这种革命性的技术改变了一切。
在 Android 中使用 eBPF：环境搭建：在 Android 中使用 eBPF：开篇 我们提到，eBPF 在 Android 上有着广泛的用途。但实际上，虽然它在服务端现在红得发紫，但在 Android 上的应用却鲜为人知；并且，由于 eBPF 运行在内核，它对运行环境还有着一定的要求。
大家可以使用 eadb 来搭建 eBPF 的开发环境；虽然最终我们会选择使用 CO-RE 技术编写 eBPF 程序，但是，eadb 提供的这个环境，可以让你快速上手，特别是 BCC 提供的一些工具已经足够你解决不少问题了；通过里面的 bpftrace，很多功能可能一行代码就能搞定，在开发阶段验证原型还是很有用的。它的使用方法很简单，直接看 github 的 README 就可以了，项目的地址在这里：https://github.com/tiann/eadb
移动应用性能工具探索之路（安卓篇）：随着 PerfDog 收费，之前无人问津的自研的性能工具突然变成了一件举足轻重的事。但当有用户开始使用后，没有经过考验的工具就暴露出了很多问题，这些问题让我意识到，这个工具不仅仅是只要能获取性能这么简单。在随后的对这个产品不断深耕的过程中，我积累了很多知识，也获得了一些感悟，接下来，我将会把我的经验分享给大家。
《DRM 专栏》| 从应用程序谈起:DRM 是 Linux 目前主流的图形显示框架，相比 FB 架构，DRM 更能适应当前日益更新的显示硬件。比如 FB 原生不支持多层合成，不支持 VSYNC，不支持 DMA-BUF，不支持异步更新，不支持 fence 机制等等，而这些功能 DRM 原生都支持。同时 DRM 可以统一管理 GPU 和 Display 驱动，使得软件架构更为统一，方便管理和维护。
深入理解 Android 系统资源异常之文件描述符异常篇:本文的目标是帮助大家深入理解 Android 系统资源异常之文件描述符异常，对于文件描述符异常的通用检测机制，当前包括 fdtrack 和 fdsan 两种机制展开剖析
货拉拉 Android 稳定性治理分享[8]:App Crash 对于用户来讲是一种最糟糕的体验，它会导致流程中断、app 口碑变差、app 卸载、用户流失、订单流失等。相关数据显示，当 Android App 的崩溃率超过 0.4%的时候，活跃用户有明显下降态势。根据统计 2021 年初我们的 Crash 率为 5%，大量的研发时间用于定位和解决用户反馈、用户投诉，crash 治理刻不容缓。通过去年的大量实践治理，我们 app 的 Crash 率降低并且稳定在 0.02%，在此做一些总结和分享，希望能为其他团队提供经验和启发。
内存管理 - 物理内存[9]:本篇从我自己的角度来写对物理内存管理的理解。由于 Linux 引入了虚拟内存的概念，应用程序对物理内存的访问都是由内核模块来接管的，因此带着以下问题，逐步揭开相关的细节：
内核是使用什么地址访问物理内存的？
物理内存为何需要分区？
伙伴系统和 SLAB 系统 有何区别？
言简意赅 Android 架构设计与挑选[10]:谈到 Android 架构，相信谁都能说上两句。从 MVC，MVP，MVVM，再到时下兴起 MVI，架构设计层出不穷。如何为项目选择合适架构，也成常备课题。由于架构并非空穴来风，每一种设计都有其存在依据。故今天我们一起探寻 “架构演化” 来龙去脉，相信阅读后你会豁然开朗。
GPU 渲染管线和硬件架构浅谈:本文简述了 GPU 的渲染管线和硬件架构，对一些常见问题进行了讨论和分析。特此分享出来，与君共勉。当然，由于本人并未从事过硬件开发的工作，文中有错漏之处在所难免，欢迎批评指正。另外本文内容量很大，总结下来有以下几点核心内容：（1）移动平台渲染管线 TBDR 的介绍; （2）GPU 缓存体系的介绍；（3）Warp 的执行机制；（4）常见的如 AlphaTest 或者分支对性能的影响。
内存如何记录方法调用和返回过程:我们在写代码的时候有没有思考过 方法如何调用、方法执行完之后如何返回、内存如何记录方法调用过程。而这也是今天这篇文章重点内容。
方法调用和返回过程涉及到了，虚拟机栈、程序计数器、局部变量表、操作数栈、方法返回地址、动态链接等等内容，涉及到知识点很多，同时这些内容也是高频面试题，所以我将拆分成多篇文章，针对每个知识点去做详细的分析。而今天这篇文章我们重点去看内存是如何记录方法调用和返回过程。
如何设计一门计算机编程语言:计算机编程语言顾名思义，是用来和计算机进行沟通的语言。计算机编程语言伴随着计算机的发明，作为计算机领域各种软件的基础，不断推动着计算机技术的发展。本文中，将主要关注设计开发一种计算机编程语言，对于其他类似的语言，比如 MarkDown、数据查询语言、数据交换语言等不涉及。计算机编程语言自从诞生以来，不断发展，很多已经逐渐消失在历史的长河中，当前(2022 年)最流行的几门语言包括(排名不分先后)：Python、Java、Javascript、C++、Kotlin、R、PHP、Go、C、Swift、C#等。使用计算机编程语言可能是本文读者在日常工作和生活中经常做的一件事情，那么计算机编程语言是如何设计的呢？设计和实现一门计算机编程语言复杂吗？我们什么时候有必要设计一门计算机编程语言呢？如何实现一门计算机编程语言呢？希望这篇文章能够解答上面的疑惑。
抖音功耗优化实践:功耗优化是应用体验优化的一个重要课题，高功耗会引发用户的电量焦虑，也会导致糟糕的发热体验，从而降低了用户的使用意愿。而功耗又是涉及整机的长时间多场景的综合性复杂指标，影响因素很多。不论是功耗的量化拆解，还是异常问题的监控，以及主动的功耗优化对于开发人员来说都是很有挑战性的。
本文结合抖音的功耗优化实践中产出了一些实验结论，优化思路，从功耗的基础知识，功耗组成，功耗分析，功耗优化等几个方面，对 Android 应用的功耗优化做一个总结沉淀。
iOS Rendering 渲染全解析[11]:希望通过这篇文章从头到尾梳理一下 iOS 中涉及到渲染原理相关的内容，会先从计算机渲染原理讲起，慢慢说道 iOS 的渲染原理和框架，最后再深入探讨一下离屏渲染。
编程语言是如何实现并发的之并发模型篇[12]:在操作系统篇中介绍了从操作系统的视角中不同编程语言实现并发的共同的一些概念。本文将会介绍常见的并发模型及不同编程语言是如何实现的。
编程语言是如何实现并发的之操作系统篇[13]:本文并不是研究操作系统是怎么实现并发的，但在搞清楚编程语言是怎么实现并发处理之前，很有必要提前对操作系统支持并发提供的一些重要特性做一个全面的介绍。操作系统为了支持多任务处理，提供了进程管理与调度，同时在 I/O 上提供了多种访问文件或网络的系统调用方式。
编程语言是如何实现泛型的[14]:Go 为什么要引入泛型？又为什么会花费如此长的时间？带着这个疑问让我们来看看编程语言中泛型的魔力吧。
性能深度分析之 SystemTrace[15]:App 中大多数的性能指标都和时间相关，如启动速度，列表滑动 FPS，页面打开耗时等等。为了优化这些指标，我们需要了解时间都消耗在哪里.不妨试试 System Trace
一起看 I/O | Jetpack 组件的新特性：Android Jetpack 是开启现代 Android 开发 (Modern Android Development，即 MAD) 之门的钥匙，它是一个包含超过 100 个库、工具及指南的套件，以帮助开发者遵循最佳实践、减少模板代码，以及编写在不同 Android 版本和设备上表现一致的代码，从而使您可以专注于在应用中实现独特的功能。
Android 13 适配指南:2022 的 Google I/O 发布了 Android 13 beta 2 和 Android 13 Beta 1 国内厂商的设备支持列表，虽然按照惯例， Android 13 应该是年末才发布正式版，但是相信有的开发者已经收到了平台的 Android13 的适配要求，所以本篇也是结合 Oppo 的 Android 13 应用兼容性适配指导 和官方提供的一些文档内容做一个整理测试。
LLVM Pass 其零：新的 Pass 机制[16]：本文从以下几个点来对比分析这两类的不同并且着重看一下新的机制的实现
Pass 的类结构是怎样的
Pass 的编写方式
Pass 的注册方式（这里只提及 LLVM 本身的 Pass）
Pass 元信息的获取方式
LLVM Pass 其一：PassManager[17]：上一期我们讲到了每个 Pass 基本的结构，这期我们从 PassManager 开始讲述 Pass 从创建到执行的整个流程，以及涉及到的种种问题
LLVM Pass 其二：Analysis 与 AnalysisManager:在第一期的时候我们就提到过，新的 Pass 与 LegacyPass 的其中一个不同在于将 Analysis 单独分离了出来，那么本期我们从一个 Analysis 的写法开始写起。
Systrace 线程 CPU 运行状态分析技巧 - Runnable 篇：本文介绍 Runnable 状态切换原理与对应的排查与优化思路。在 Systrace 中显示为蓝色，表示线程处于 Runnable，等待被 CPU 调度执行。
Systrace 线程 CPU 运行状态分析技巧 - Running 篇：本文是 Systrace 线程 CPU 运行状态分析技巧系列的第二篇，主要分析了 Systrace 中 cpu 的 Running 状态出现的原因和 Running 过长时的一些优化思路。
Systrace 线程 CPU 运行状态分析技巧 - Sleep 和 Uninterruptible Sleep 篇：本文是 Systrace 线程 CPU 运行状态分析技巧系列的第三篇，本文主要讲了使用 Systrace 分析 CPU 状态时遇到的 Sleep 与 Uninterruptible Sleep 状态的原因排查方法与优化方法，这两个状态导致性能变差概率非常高，而且排查起来也比较费劲，网上也没有系统化的文档。
Android 子线程 UI 操作真的不可以？:对于 Android 子线程不能操作 UI 的更深入理解：控制 View 绘制的线程和通知 View 更新的线程必须是同一线程，也即 UI 线程一致。
京东 App MCube 动态化实践:在京东 App 里，消费者购物的关键环节包括搜索、商品详情页、购物车、结算下单到订单等，在整个购物链路中属于价值非常高的部分，因此被称为黄金流程（以下简称黄流）。而随着业务的高速发展，为了用更快的响应速度、更少的研发人力、更好的用户体验承接业务需求，“动态化+跨端”自然而然进入我们视野。在此基础上，我们结合黄流业务对于性能和稳定性要求极高的特性，输出了一套原生动态化方案，代号“MCube”，截止到目前，已在 App 内多个业务模块上线。
dex 文件格式介绍:dex（Dalvik Executable）是 Android 平台源代码文件（java，kotlin）经过编译、重构、重排、压缩、混淆后的字节码文件，是对传统的 class 文件再处理。dex 更适合于资源有限的嵌入式设备使用，和 class 文件比，dex 明显的优势主要表现在下面两个方面
体积更小，dex 在 class 的基础上，将多个 class 文件特征进行统一处理，通过重排，压缩，和 class 文件比，体积明显变小
IO 量明显减少，dex 将大量 class 文件整合成一个文件，在程序执行的过程中可以一次载入，避免多次小文件的 IO 读取。
Google I/O : Jetpack Compose 中常见的性能问题[18]:本文主要介绍如何编写和配置应用程序以获得最佳性能，并指出了一些要避免的问题。
Dutter | 前车之鉴：聊聊钉钉 Flutter 落地桌面端踩过的“坑”:本文主要介绍一下钉钉 Flutter 业务灰度过程中，在桌面端遇到并处理过的几个 FlutterEngine 层面的 Bug
Adreno Memory[19]:本文介绍了高通的 Adreno memory 相关的知识
抖音 Android 包体积优化探索：从 Class 字节码入手精简 DEX 体积:众所周知，应用安装包的体积会十分影响用户的应用下载速度和安装速度。这其中最主要的组成部分便是 DEX 文件，它们都是由 Java/Kotlin 代码编译而成。过去的两年中，抖音的 DEX 的个数从 8 个涨到了 21 个，DEX 的总大小从 26M 涨到了 48M，增长十分迅猛。诚然，随着抖音的快速发展，业务复杂度的提高，代码量级一定是在增加的，但如何在业务无感的情况下，对代码进行通用优化，也是我们一个很重要的优化方向。
抖音 Android 包体积优化探索：资源二进制格式的极致精简：目前，安卓端对于包体积的优化方案已经多如过江之鲫，我们系列的上一篇文章介绍了 Class 字节码的优化，本期我们将关注点聚焦到资源文件上，从资源二进制文件的全新角度，拓展出包体积优化的新思路。
哔哩哔哩 Android 编译优化：哔哩哔哩的安卓项目的工程结构是 Monorepo(单仓)变种，也就是所有的代码都在一个工程结构下编译。我们认为 Monorepo(单仓)是一个非常适合我们的开发模式，主要是因为其提供的原子提交，可见性，参与度，切片的稳定性等等优点，这些都是我们选择 Monorepo 的原因。但是因为权限管控，ijkplayer 等双端通用工程的原因，还是拆开了多个 git 仓库。通过 git 权限的方式来拆分了工程结构，然后通过 Gradle Plugin 的形式进行了多工程的组合，在 CI 打包环境上让工程具备 Monorepo 的能力。
分析 Android 耗电原理后，飞书是这样做耗电治理的：飞书最近在进行耗电治理的专项优化，本篇文章将分析 Android 系统的耗电原理，分享飞书的耗电治理规划。
抖音 Android 性能优化系列：Java OOM 优化之 NativeBitmap 方案:作为 Android 开发者，相信大家都碰到过 Java OOM 问题，导致 OOM 的原因可能是应用存在内存泄漏，也可能是因为手机的 heapsize 比较小不能满足复杂应用对内存资源的大量需求。对于 Java 内存泄漏治理，业界已经有比较成熟的方案，这里不做介绍，本文主要针对第二点尝试进行分析和优化。
理解和消除 App 中的卡死:卡死问题是导致用户体验的最大问题之一，当用户遭遇卡死时很可能就退后台杀进程了，这会导致非常高的用户流失率。所以一旦涉及到卡死，一定是需要较高优先级解决的。
通过本文的学习，在我们知道理解原理、善用工具的情况下，分析并解决卡死问题就变得容易起来。同时希望本文也能起到抛砖引玉的作用，毕竟真实的卡死情况更加复杂，还有很多需要进一步探索的地方。最重要的是能理解导致卡死的原理，以及学会解决卡死问题的基本思路，遇到问题才能迎刃而解。
Compose 渲染性能到底怎么样?:去年曾经写过一篇文章调研 Compose 的性能：相比 XML , Compose 性能到底怎么样？不过这篇文章主要是从包体积，页面首次打开时间来分析 Compose 的性能，而 Compose 作为一个 UI 框架，相信大家更关注它的渲染性能比如 FPS，本文主要就是从 FPS 的角度来分析 Compose 的性能 本文主要包括以下内容:
如何测量Compose的FPS
Compose列表渲染性能分析
Compose粒子动画渲染性能分析
Mutex 内核同步机制详解:在 linux 内核中，互斥量（mutex，即 mutual exclusion）是一种保证串行化的睡眠锁机制。和 spinlock 的语义类似，都是允许一个执行线索进入临界区，不同的是当无法获得锁的时候，spinlock 原地自旋，而 mutex 则是选择挂起当前线程，进入阻塞状态。正因为如此，mutex 无法在中断上下文使用
Software Engineering - The Soft Parts[20]：今天，我将与大家分享我在谷歌浏览器的第一个 10 年里学到的一些软件工程 "软技能"，我是谷歌浏览器的高级员工工程经理。在我工作 10 周年之际，我想反思一些一直伴随着我的教训。我希望这些经验对你的职业生涯有所帮助。成为一名优秀的工程师是为了收集经验。每个项目，即使是小项目，都是为你的工具箱添加新技术和工具的机会。当你把在一个项目中学到的技术与在另一个项目中学到的工具结合起来解决问题时，就会产生更大的价值。这一切都会增加。
经验分享 && 推荐阅读
过去一周个人阅读和收藏的非技术文章精选，扩展 Android 之外的知识和视野，不要给自己设限
从技术难题中学习：之前写过一篇如何学习一门技术[1]的文章，介绍了我在学习新技术的一些经验。不过这种按计划的学习方式效率可能并不高，真正高效的学习方式是在解决问题中实践所学的知识。作为工程技术人员，在项目中遇到问题的概率是高的，这给了我们机会去不断提升自己的能力边界。
解决难题是一种非常高效的主动学习方式。难题是一面镜子，能反映我们的知识盲区。在解决难题的过程中，不仅可以解决知识盲区，还能提升解决问题的能力，甚至能得到更厉害的人的帮助，也有可能收获影响力。
The Method that I Used to Improve My English Initially[21]：我在一家几乎没有人讲中文的公司工作了一年多。在闲聊中，当大多数同事得知我从未在英语环境中工作或在国外学习时，似乎相当惊讶。这也说明了一件事，就是哑巴英语在中国很突出。
这些天，我在中国的一些朋友来请我分享如何提高我的英语。我的英语还是很烂，很多人在没有国外工作和学习经验的情况下，英语就很出色，我也不敢说自己能教。不过，我还是决定分享一下我最初提高英语的方法，希望这个帖子能帮助想在生活中有所改变的小伙伴们找到练习英语的入口 😄。
如何进行技术面试（面试官视角）[22]：我参加过几十场技术面试，其中作为面试官的次数要远多于候选人。
说起来在我第一次做面试官之前，并没有人教过我应该怎么做，我则一直将面试视作通过一小时左右的沟通，对候选人形成一个整体的印象，最后给出一个主观的评价的过程。在这么多次的面试中，我也总结出了一些经验可以和大家分享
大环境不好的情况下如何 🐶 着[23]：大概是今年 4 月份给团队同学的一个分享，归档于博客，来聊聊作为一个国内的开发工程师，如何在大环境不好的情况 🐶 着变强。
程序员的软技能 - 代码之外的生存指南[24]：tisoga 大佬的内部分享 PPT，介绍了一些程序员需要具备的一些软技能，Github 地址（有对应的 PDF 可以下载）：https://github.com/forrestchang/programmer-soft-skills
过去 10 年美国人的生活为何如此愚蠢？：本文作者乔纳森·海特（Jonathan Haidt）为美国社会心理学家，在道德心理学、商业伦理以及复杂社会系统方面均有深刻的洞见（国内出版过他的《象与骑象人：幸福的假设》和《正义之心：为什么人们总是坚持“我对你错”》）。仔细阅读完今天这篇长文，你会发现一条清晰的叙事线索：本世纪初基于互联网而诞生的社交媒体，是如何一步步依靠技术底层逻辑从分享/共享走向分化/分裂的。
虽然作者的叙事着重于美国意识形态下的互联网媒体社会，但某种意义上，这也是一个全球的普遍现状——互联网正在加剧放大、叠加人们的对立情绪，引发更多的恶意与仇恨，进而增加冗余的沟通成本，影响公权机构的政策制定。
英文原文链接：https://www.theatlantic.com/magazine/archive/2022/05/social-media-democracy-trust-babel/629369/ ，感兴趣的可以去读一下
互联网是人类历史的一段弯路吗？：我们当下所面临的一切“问题”，都会成为不久之后的“需求”，然后在下一个时代成为产品、解决方案与推动社会发展的新增长点。
互联网与中国后现代性呓语：本文的核心目标是试图解释：为什么作为整体性的人类社会仍在进步，而个体却越发地难以从中受益，或越发难以感受到这种受益？
本文的最后一节“总论：中国现代性的得与失”中，我试着回答了这个问题。如果你对以上四个命题没有兴趣，也可以直接阅读这一节获得本文的概要。但这将使得那段论述变得空洞无力，因而我不建议这样做。
波谷:波谷是什么？已挤去所有泡沫，已陷入极端恐惧，比如 2008 年的次贷金融危机、2018 年的中美贸易战。极端恐惧之下的极端保守值，却在持续增长，雄辩证明真实价值也在持续增长。
Web 3 三问:在网上看到一套很有意思的提问，据称是来自某互联网巨头公司的战略管理人员，全都有关于 Web 3：
有什么场景是在 Web 2 不能完成，必须在 Web 3 能完成的？
如果有，那这个场景下的 Web 3 产品有多少人需要？
这个场景下，Web 3 的产品解决问题的效率会更好吗？
为什么字节跳动还在轰炸式招聘？: 文章里面有一个有趣的数字：业界传闻字节跳动员工的平均在职时间是 7 个月，根据一些员工的观察，这个平均在职时间大差不差。
没有望向彼处[25]：他的文字太好了，既淳朴又精致。每个字都简单素净，不跳出农民的世界，而连起的词句和段落却又明亮深刻，直指人心。
2022 年我的 Mac 软件折腾之旅[26]：何为差生文具多，看完这个你就清楚了.
出国求职的中年程序员：工作状态朝九晚五，37 岁在日本还是年轻人：一批不想被淘汰的大龄程序员，开始考虑出国找机会。为缓解职场焦虑，一些大龄程序员正在进行一场海外迁徙。
知识工作者的普世智慧：知识工作者即需要大量自主思考、判断、决策的工作者，与之对应的概念是体力工作者。这是彼得·德鲁克（a.k.a 现代管理学祖师爷）提出的概念，事实上，老爷子的意思是知识工作者就是管理者——虽未管人，但在管事。
肉身翻墙新加坡安顿指南[27]：本文主要讲的是如何来到新加坡工作之后，需要做的一些事情。阅读本文你能获得到在新加坡落地之后，需要做的一些必须的 事项例如租房，办理银行卡等，防止大家踩坑。
面试随想[28]：借这篇文章分享一下自己在第一次社招中的一些感悟吧：
希望大家永远记住，找工作的时候，双方都是平等对立的，不要跪着找工作。
哪怕面试不通过，也不能说明什么问题，只能说你跟那个团队不够 match，或者你没有准备好这场面试，仅此而已。
永远谨记：Fake it till you make it.
2021 年终总结[29]：每当年终提笔，总会想写很多，洋洋洒洒写上一大段后还得一再精简，以防废话连篇，似乎多抒发一些，才能让自己拥有足够的安全感。
重读暗时间
重读《暗时间》：如何写「更健康更长久」的文字（1）[30]
重读《暗时间》：如何写「更健康更长久」的文字（2）[31]
重读《暗时间》：如何写「更健康更长久」的文字（3）[32]
重读《暗时间》：如何写「更健康更长久」的文字（4）[33]
Weekly
Android Weekly-524[34]
Android Weekly-525[35]
Kotlin Weekly #309[36]
onCreate Digest - Issue #115[37]
NEWSLETTER #111[38]
Graphics Programming weekly - Issue 241[39]
泛工具产品深度分析 #1 独立产品周刊[40]:这个专题每期会对几款特定类型的产品做一些深度分析，主要是我对一些产品的观察和分析。主要关注产品的市场/品类/定位/趋势/变现模式/推广玩法等，覆盖国内外移动应用，可能也会做一些 Web 端的产品分析。为独立创造者提供独立见解，帮助你发现新产品方向，启动和完善你的项目。
体验碎周报第 101 期（2022.6.27）:系统的知识来源于对碎片的整理和思考，为了更好地输出系统知识，记录本周我发现的体验设计和思考，为构建系统知识做准备。
书籍推荐
性能之巅(第二版)
作者 Brendan Gregg
计算性能和云计算方面的行业专家。Netflix 的高级性能架构师，从事性能设计、评估、分析和调整工作。多本技术图书的作者，包括《BPF 之巅》，他获得了 USENIX LISA 系统管理杰出成就奖。他还担任过内核工程师、性能负责人和专业技术培训师，并曾担任 USENIX LISA 2018 会议的项目联合主席。他开发了可用于多个操作系统的性能工具，以及包括火焰图在内的性能分析的可视化工具与方法。
只有广泛的系统运行原理做为支持储备，再结合性能分析工具分析问题，才能做到准确定位问题根因。否则就是大家经常说的「性能优化流氓」，你说什么是什么，别人也没法证伪。反复折磨测试同学复测，没测出来之后，这个问题也就不了了之了 这本书就可以让你看了之后，能和性能优化流氓拜拜手腕
京东购买地址：https://item.jd.com/13199661.html 介绍文章：https://mp.weixin.qq.com/s/T1tu53gCIsdIVEoz4q59-A
本文 NewsLetter 地址
由于微信外链限制，很多文章链接都无法直接访问，推荐大家订阅 NewsLetter 来获得更好的阅读体验，或者访问网页端或者知乎专栏
订阅地址：https://androidweekly.zhubai.love/
本文 NewsLetter 地址：https://androidweekly.zhubai.love/posts/2155412560139071488
本文知乎地址：https://zhuanlan.zhihu.com/p/537133477
参考资料
[1]
渲染引擎渲染性能指标设计: https://zhuanlan.zhihu.com/p/462983174
[2]TextureView 的血与泪（完整修订版）: https://zhuanlan.zhihu.com/p/147322501
[3]TextureView 的血与泪 PART II: https://zhuanlan.zhihu.com/p/363426469
[4][Flutter 渲染优化系列] Flutter 渲染性能问题分析: https://zhuanlan.zhihu.com/p/354631257
[5]Flutter vs Chromium 动画渲染的对比分析: https://zhuanlan.zhihu.com/p/323269086
[6]Why should we use Use Case classes in our Android Projects?: https://medium.com/huawei-developers/why-should-we-use-use-case-classes-in-our-android-projects-142de0f952fd
[7]Android 逆向总结: https://www.yuque.com/docs/share/60b54ad1-c77a-4cdc-95c8-c6a93e424a9f
[8]货拉拉 Android 稳定性治理分享: https://juejin.cn/post/7100743641953468452
[9]内存管理 - 物理内存: https://www.cyningsun.com/06-15-2021/memory-management-physical-memory.html
[10]言简意赅 Android 架构设计与挑选: https://juejin.cn/post/7106042518457810952
[11]iOS Rendering 渲染全解析: https://juejin.cn/post/6844904162765832206
[12]编程语言是如何实现并发的之并发模型篇: https://www.bmpi.dev/dev/deep-in-program-language/how-to-implement-concurrency/concurrency-model/
[13]编程语言是如何实现并发的之操作系统篇: https://www.bmpi.dev/dev/deep-in-program-language/how-to-implement-concurrency/os-scheduling/
[14]编程语言是如何实现泛型的: https://www.bmpi.dev/dev/deep-in-program-language/how-to-implement-generics/
[15]性能深度分析之 SystemTrace: https://blog.csdn.net/Hello_Hwc/article/details/104738309
[16]LLVM Pass 其零：新的 Pass 机制: https://homura.live/2022/06/19/llvm-pass-0/
[17]LLVM Pass 其一：PassManager: https://homura.live/2022/06/26/llvm-pass-1/
[18]Google I/O : Jetpack Compose 中常见的性能问题: https://juejin.cn/post/7097066597222711327
[19]Adreno Memory: https://www.yuque.com/docs/share/5d84c6f6-c06b-4015-9eb0-2e718bce54c2
[20]Software Engineering - The Soft Parts: https://addyosmani.com/blog/software-engineering-soft-parts/
[21]The Method that I Used to Improve My English Initially: https://ironfeet.me/the-method-that-i-used-to-improve-my-english-initially-en/
[22]如何进行技术面试（面试官视角）: https://jysperm.me/2022/05/technical-interview-tips/
[23]大环境不好的情况下如何 🐶 着: https://tw93.fun/2022-07-01/gou.html
[24]程序员的软技能 - 代码之外的生存指南: https://programmer-soft-skills.vercel.app/1
[25]没有望向彼处: https://book.douban.com/review/14465472/
[26]2022 年我的 Mac 软件折腾之旅: https://tw93.fun/2022-06-25/mac.html
[27]肉身翻墙新加坡安顿指南: https://vim0.com/post/singapore_3_month/
[28]面试随想: https://www.tsaiggo.life/posts/thinking-in-interview/
[29]2021 年终总结: https://hijiangtao.github.io/2021/12/29/Letter-to-2021/
[30]重读《暗时间》：如何写「更健康更长久」的文字（1）: http://newsletter.hardwaylab.com/issues/1-1171299?utm_campaign=%E7%AC%A8%E6%96%B9%E6%B3%95%E5%AE%9E%E9%AA%8C%E5%AE%A4%E6%9D%A5%E4%BF%A1&utm_medium=email&utm_source=Revue%20newsletter
[31]重读《暗时间》：如何写「更健康更长久」的文字（2）: http://newsletter.hardwaylab.com/issues/2-1175931?utm_campaign=%E7%AC%A8%E6%96%B9%E6%B3%95%E5%AE%9E%E9%AA%8C%E5%AE%A4%E6%9D%A5%E4%BF%A1&utm_medium=email&utm_source=Revue%20newsletter
[32]重读《暗时间》：如何写「更健康更长久」的文字（3）: http://newsletter.hardwaylab.com/issues/3-1181012?utm_campaign=%E7%AC%A8%E6%96%B9%E6%B3%95%E5%AE%9E%E9%AA%8C%E5%AE%A4%E6%9D%A5%E4%BF%A1&utm_medium=email&utm_source=Revue%20newsletter
[33]重读《暗时间》：如何写「更健康更长久」的文字（4）: http://newsletter.hardwaylab.com/issues/4-1186264?utm_campaign=Issue&utm_content=view_in_browser&utm_medium=email&utm_source=%E7%AC%A8%E6%96%B9%E6%B3%95%E5%AE%9E%E9%AA%8C%E5%AE%A4%E6%9D%A5%E4%BF%A1
[34]Android Weekly-524: https://androidweekly.net/issues/issue-524
[35]Android Weekly-525: https://androidweekly.net/issues/issue-525
[36]Kotlin Weekly #309: https://mailchi.mp/kotlinweekly/kotlin-weekly-309
[37]onCreate Digest - Issue #115: https://www.oncreatedigest.com/issues/oncreate-digest-issue-115-1237523
[38]NEWSLETTER #111: https://dormoshe.io/newsletters/ag/android/111
[39]Graphics Programming weekly - Issue 241: https://www.jendrikillner.com/post/graphics-programming-weekly-issue-241/
[40]泛工具产品深度分析 #1 独立产品周刊: https://www.decohack.com/Post/653
661
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
