Maeiee Weekly No.4
文章
- 《干货 | 携程酒店Flutter性能优化实践》
- 性能指标
- FPS:每秒传输帧数 (Frames Per Second)
- TTI:从页面加载开始到页面处于完全可交互状态 (Time To Interactive)
- Performance View
- 一个柱一帧,绘制时长
- 蓝色:满足 60fps
- 橙色:不满足 60fps
- Enhance tracing 模式:看到长耗时方法、Widget build
- 帧绘制耗时前三
- UI 绘制:widget build、layout、paint,CPU 时间
- 光栅化:GPU 时间
- vsync ahead:vsync 信号与 widget build 之间延迟
- 优化方法1:控制 setState次数,减小 Provider 范围
- 减少不必要 UI 绘制:控制 build 次数
- 通过 shouldRebuild 限制
- 缩小范围:改变 Widget 树层级
- Consumer、Selector 缩小范围
- 减少不必要 UI 绘制:控制 build 次数
- 预构建 Widget(AnimatedBuilder)
- const widget
- final:一次赋值,不能改变
- const:常量值,确定的值,编译时确定
- const widget:编译阶段已经确定
- 性能开销小
- 耗时计算放入 Isolate
- Dart 单线程:耗时运算阻塞 UI 线程
- 注:有坑,内存不足 DartVM 会自动清 Isolate
- 懒加载
- ListView.builder
- PageView.builder
- GridView.builder
- 判断 item 是否在屏幕内才绘制
- Column、Row 一次性绘制,重复结构需避免
- 分帧渲染
- 错峰加载:Widget 树按照优先级分批绘制
- 原理:空容器占位,听从调度
- GPU 性能定位
- checkerboardOffscreenLayers
- 多视图叠加用到 Canvas 里的savaLayer 方法
- 半透明场景,GPU 开销大
- MaterialApp 设为 checkerboardOffscreenLayers true
- 分析器自动检测多视图叠加
- 使用 saveLayer 的 widget 变成棋盘格
- checkerboardRasterCacheImages
- 另一类非常消耗性能的操作是,渲染图像
- 多层次的缓存快照,这样Widget 重建无需重新绘制静态图像
- 在界面重绘时频繁闪烁的图像(即没有静态缓存)
- 把需要静态缓存的图像加到 RepaintBoundary 中
- 可以确定 Widget 树的重绘边界
- 自动将其缓存,避免重复刷新
- checkerboardOffscreenLayers
- 内存泄露
- 原理:Expando
- 常见内存泄露场景:
- 通过 Channel 调用 Native,Native 不给返回值,导致 Future、及页面泄露
- 订阅没有释放:Timer、EventBus 等
- 性能指标
- 《Flutter 2022 路线图》
- 开发体验
- 最关注,打造开发者喜爱的 SDK
- 提供解决常见问题的 Widgets、Plugins
- 迭代开发工具链、lint、文档实例
- Web 端 HotReload,Dart-to-JS 堆栈跟踪
- 桌面端
- 计划桌面支持实现 Stable
- 逐个平台发布:Windows、Linux、macOS
- 扩大回归测试套件
- 通过测试,不破坏现有代码前提下演进
- 带来更强的信心
- Web
- 提升性能、插件质量
- 辅助功能
- 浏览器间一致性
- 使 Flutter 程序更容易嵌入 HTML 页面
- 框架(Framework)
- Material 组件库升级到 Material3
- 跨组件文本选择
- 提升文本编辑体验
- iPadOS 手写支持
- 跨平台菜单框架
- 引擎
- 支持单 isolate 内渲染多个 window
- Dart
- 引入一个核心特性
- 可能:metaprogramming
- 引入小语言体色和嗯
- 可能:改进包导入语法
- 扩展编译工具链:
- 支持编译到 Wasm,取决于 WasmGC 的标准化
- 引入一个核心特性
- 卡顿:
- 2021 年解决了大量卡顿问题
- 需要重新思考对 shader 的使用,重写图形底层
- 2022 iOS 会迁到新底层
- 引入其他性能改进,如新 DisplayList 系统
- 放弃对 32位 iOS 的支持
- 开发体验
- 《WebAssembly生态及关键技术综述》
- WebAssembly 字节码和内存模型规范
- 安全隔离
- 高效、体积小
- 跨平台,可移植二进制
- 多语言支持
- WebAssembly 背景
- 大型软件:不同开发语言协作问题
- 统一的集成方式和接口
- 交互过程中引入额外损耗(内存、性能)
- 统一的部署、运行方式:安全、隔离、跨平台
- 开发者使用多种编程语言,技术栈负担
- 大型软件:不同开发语言协作问题
- 场景:
- JS、Python:热点模块用 WebAssembly 实现提高性能
- Rust:编译成 WebAssembly 提供给 JS、Python,降低开发者门槛
- C++:编译成 WebAssembly 沙箱运行,更安全,开箱即用
- WebAssembly 开发生态
- C/C++
- WebAssembly 作为 LLVM 默认支持的后端
- Clang 将 C/C++ 直接生成 WebAssembly
- Emscripten
- 提供了常用的 C/C++ 库( sys-libs )
- Binaryen:进一步优化,生成 JavaScript API
- Rust
- Rust 编译器仅仅是一个编译器前端
- Cargo、wasm-bindgen 编译
- Go:TinyGo 是基于 LLVM 后端实现的 Go 编译器
- Java:
- TeaVM:
- Java 字节码的静态编译器(AOT)
- 生成的 JavaScript 和 WebAssembly 可以在浏览器中运行
- TeaVM 不需要源代码,只需要编译好的类文件
- Bytecoder:
- 将 JVM 字节码解析并转换为中间表示
- 再由 LLVM 转 WebAssembly
- CheerpJ:基于 LLVM 的 Java 字节码到 WebAssemlby/Javascript 的 AOT 编译器。
- JWebAssembly:Java 字节码编译为 WebAssembly
- TeaVM:
- Javascript/TypeScript/AssemblyScript
- Assemblyscript
- 面向 WebAssembly 标准的严格类型化的 TypeScript 变体
- 通过 Binaryen 后端编译为 WebAssembly
- XScript:TypeScript 语法兼容的静态编译型语言
- ts2wasm:TypeScript 编译生成 WebAssembly
- Assemblyscript
- C/C++
- WebAssembly Runtimes
- wasmtime:非 Web 环境执行 WebAssembly 和 WASI 平台绑定
- 目前仅在 x86_64 上保证可用并且性能比 llvm 要差很多
- 其他平台的支持还在进行
- wasmer:
- 提供能够在从桌面到云、边缘和物联网设备等随处可运行的超轻量级容器。
- 最大的好处是"开箱即用"
- WasmEdge
- 主要应用于"应该使用 Docker 而 Docker 用不起来的地方"
- wamr
- 适合资源极其有限的小型嵌入式设备
- V8:也能够运行 WASM 模块
- wasmtime:非 Web 环境执行 WebAssembly 和 WASI 平台绑定
- WebAssembly 字节码和内存模型规范
- 《‘AWS vs K8s’ is the new ‘Windows vs Linux’》
- 少数人虚度光阴在折腾 Linux
- 为啥不用 Windows,要啥有啥?
- 答案多种多样,都有特殊的理由证明这种努力是合理的
- 折腾 Kubernetes 就像折腾 Linux 的人
- 难搞:不是开箱机用,API 还老变
- Kubernetes 的开源质量远远高于大多数项目,但是的确不好上手
- 每隔几个月还有新技术出现,生态迭代非常快
- 为啥不用 AWS,要啥有啥?
- 名言:knative 俱乐部的第一条规则是你不能解释什么是 knative
- AWS 相当于 Windows
- 跟 Windows 一样,AWS 是最终的产品
- 服务是稳定且固定的,API 可靠
- 汽车比喻
- 大多数人希望又一辆不需要经常修理的汽车
- 有的人喜欢维护汽车
- 有的公司保留机械师维护车队,因为大规模自己修更便宜
- AWS 和 Kubernetes
- AWS 没有看到 Kubernetes 的意义
- 尽管有 EKS,但是不令人满意
- AWS 的人不理解,为什么有了 ECS 还需要 EKS
- AWS 的竞争对手:私人数据中心
- 私有云失败的原因
- 企业无法正确管理弹性需求
- 如果你想改造企业的 IT,就从财务开始。如果你不知道为什么要从财务开始,你肯定会失败。
- 少数人虚度光阴在折腾 Linux
- 《Why I quit Android Development after 10 years and what I plan to do now》
- 原作者十年 Android 开发,经历架构变迁
- 带领 Android 开发团队,最近四五年接触后端
- 厌倦了写 UI
- 厌倦了跟 UI/UX 开会
- 花费了大量时间,解释为什么某个需求做不了
- 厌倦了写业务
- 完全由设计师和产品经理主导
- 业务逻辑,缺少工程化
- 跳不出 Android API
- 步入夕阳的 Android 开发(吐槽)
- 不想再花好几天,就为了卡片的边框
- 讨论好几天,为了使用单选还是复选按钮
- 不想再学习新的库处理生命周期和导航,未来 12 个月内再次被替换
- 转后端
- 开发每秒服务上千用户的系统很迷人
- 未来路线图:
- k8s 认证,成为云大师
- 学数据库工作原理
- 研究 DevOps
- 找回了开发的乐趣,新的神秘性和复杂工程问题
- Android 开发的前途
- 客户端开发很难向上走(架构师、经理)
- 眼界、技术栈太窄
- 《Install K3S on Arch Linux with, firewalld, LetsEncrypt, and Traefik》
- k8s/k3s 目前不支持 nftables
- k3s 在 AUR 源里,服务名 k3s
- 《K8s 还是 K3s?This is a question》
- Kubernetes,由 Google 设计得高可用可扩展平台
- Rancher Labs
- Rancher 开源企业级 k8s 管理平台
- k3s 轻量级 Kubernetes 发行版
- k3s
- Kubernetes 打包到 60MB 二进制
- 资源要求更少
- 通过 CNCF 认证的 Kubernetes 发行版
- 可以让 Pod 在 master 和节点上运行
- k8s vs k3s: 差异解析
- 轻量级Kubernetes k3s初探
- 场景
- 廉价硬件部署
- 持续集成
- 《KUBERNETES IN ARCH LINUX》
- archwiki Kubernetes
- 设置一个“单节点”集群
- 学到一招:使用 lxd 创建一个 Arch 容器,作为 Playground
- kubernetes 分为 3 个包:
- kubernetes-control-plane:control planes/master nodes
- kubernetes-node:worker nodes
- kubernetes-tools:诸如 kubectl 的工具
- Container Runtimes
- 《一文看懂 Container Runtime》
- 采用 containerd
- kubeadm 初始化 kubernetes cluster