Android Weekly #35 知识工作者就是管理者——虽未管人，但在管事

技术文章

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

1. 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 的过程。《魏略》曰：“亮在荆州，以建安初与颍川石广元、徐元直、汝南孟公威等俱游学，三人务於精熟，而亮独观其大略。”性能优化本身，是一个从统帅诸葛亮逐步变身单兵战神吕布的过程，而你首先必须是统帅。

2. Compose 中的 "ViewPager" 详解 | 开发者说·DTalk ：ViewPager 的功能是可以使视图滑动，就像桌面左右滑动那样。写过 Android 的对它可谓是非常熟悉了，不管是轮播图的使用、亦或是页面之间的切换，都离不开它

3. 浅谈协程:我们可以简单的认为：协程就是用户态的线程，但是上下文切换的时机是靠调用方（写代码的开发人员）自身去控制的。同时，协程和用户态线程非常接近，用户态线程之间的切换不需要陷入内核，但部分操作系统中用户态线程的切换需要内核态线程的辅助。

4. 渲染引擎渲染性能指标设计^[1]:对于应用来说，渲染性能或者动画流畅度主要是看两个指标 —— 帧率和卡顿率。帧率计算比较简单，没有太大争议，而卡顿率的计算，我们一开始是参考 PerfDog 的计算方式，但是研究后觉得跟我们的实际场景有一定差异。

   所以我们在 PerfDog 的基础上对卡顿率的计算进行修正，这个新的卡顿率计算标准：

   1. 可以使用应用内渲染引擎收集的数据进行计算，适合在应用内运行；

   2. 更契合 UI/Web 的渲染场景，更真实反映动画的流畅度和用户对应用卡顿的感知；

5. 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 的同步），当同步失调的时候，比较容易出现掉帧或者吞帧导致的卡顿和抖动现象。

6. TextureView 的血与泪 PART II^[3]:我之前写过一篇文章 TextureView 的血与泪，讲述了在 TextureView 上碰到的各种坑爹事情，和我们的一些解决方案 ，像避免 TextureView 因为流水线调度问题而掉帧的优化方案也用在了我们的 Flutter 渲染性能优化上，并获得了一定的优化效果。不过 TextureView 的坑真的是踩也踩不完，最近又碰到不少相关的问题导致我们开始寻求其它替代 TextureView 的技术方案

7. [Flutter 渲染优化系列] Flutter 渲染性能问题分析^[4]:我在Flutter vs Chromium 动画渲染的对比分析^[5]一文中对 Flutter 和 Web (Chromium) 的各种动画的理论性能优劣进行了分析，其中一个主要结论是，由于惯性滚动处理机制和光栅化机制的不同，Web (Chromium) 的惯性滚动动画性能理论上要远远优于 Flutter。而在一些已经上线的使用 Flutter 的业务中，业务方也持续给我们反馈了这些业务在中低端 Android 手机上存在比较严重的惯性滚动性能问题

8. Android Studio Chipmunk 现已发布：我们非常激动地宣布推出 Android Studio Chipmunk

   声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/Cpp五条/article/detail/248004