leozdgao / blog

一些文章

Hi there 👋

Frontend Engineer.

• 🔭 Do some work on multimedia processing with WebAssembly & OpenGL
• 🦀 Rustaceans

blog's Issues

iOS 开发入门基础

应用生命周期

视图声明周期

viewDidLoad 仅在视图创建阶段调用一次，用于执行一些视图初始化的操作。而 viewWillAppear、viewDidAppear、viewWillDisappear、viewDidDisappear 则可能会在视图的生命周期中被频繁调用。当操作系统内存不足时，会调用 didReceiveMemoryWarning 做一些内存释放相关的工作。

三种构建界面的方式

Storyboard

所见即所得（WYSIWYG），无需重新编译代码即可立马看到变化。Storyboard 可以整体设计应用的 UI 界面还进行多页面之间的导航描述，总体能力强与 XIB。但对于动态内容，则无能为力。

XIB

亦是所见即所得（WYSIWYG），但一个 XIB 文件需要对应一个视图控制器，且不具备描述导航的能力。对于动态内容，同样无能为力。

纯代码构建

自由度最高，对于编写静态内容而言，需要的工作量较大，且每次修改需要重新编译才能看到效果。但由于代码实现完全自主，故理论上可以 hold 住一切场景。

基本视图控件与 UIView 的继承关系

几个最新的滚动行为相关的 CSS 样式

最近看到了一些通过 CSS 控制 Web 下的滚动体验的属性，在移动端，Web 体验往往期望 “App 化的”，我们在实现的过程中会倾向于往 App 的体验靠拢，而受浏览器能力或特性的限制，一些效果需要借助 JS 来实现，甚至是需要写一些 Hack 代码来实现。而现在 W3C 标准制定的这些针对滚动体验的属性无疑为无线前端的 Web 开发减少成本的情况下，又带来了更好的用户体验，同时也不需要考虑效果实现过程中的性能问题。

scroll-behavior

说明

定义了当导航（hash）或 CSSOM Scroll API（scrollTo、scrollIntoView）导致的滚动容器位置变化的滚动行为（用户触发的滚动行为不受此属性影响）。

可选值

auto
默认值，滚动容器的滚动位置立刻调整到期望位置。

smooth
滚动容器的滚动位置平滑位移到期望位置，其中滚动的 timing function 由浏览器自己定义。

标准与文档

• MDN
• W3C CSSOM View

有了这个属性，就不需要额外的 JS 代码来实现了。

overscroll-behavior

说明

定义了当滚动容器到达滚动边界（Scroll Limit）后是否触发滚动联结（Scroll Chaining）的行为。

可选值

auto
默认值，当滚动容器到达滚动边界后，继续滚动将会触发滚动联结，带动祖先元素的滚动。

contain
禁用滚动联结，当滚动容器到达滚动边界后，不再带动祖先元素的滚动。

none
同样会禁用滚动联结，同时也会禁止元素自身到达滚动边界后的效果，比如 MD 的光晕效果。

如果我们将此属性应用在 html 或者 body 上，还可以禁用 Chrome for Android 的元素下拉刷新。

body {
  overscroll-behavior: contain;
}

标准与文档

• Google Blog
• W3C CSS Overscroll Behavior

scroll-snap-type

说明

定义了滚动拉拽（Scroll Snap）的行为，当用户的滚动行为结束后，决定子元素是否应用拉拽（Snap）效
果。

可选值

none
默认值，当用户的滚动行为结束后，不会对子元素应用滚动拉拽。

mandatory
当用户滚动行为结束后，对子元素应用滚动拉拽效果。

规范与文档

• W3C CSS Scroll Snap

现代浏览器是如何加速性能的 -- 网络层

49 年前，一个叫 ARPAnet 被创造了出来，它是一个早期的包交换网络（packet switching network），也是第一个实现 TCP/IP 的网络。这个网络建立起了加利福尼亚大学和斯坦福研究院之间的连接。20 年之后，Tim Berners-Lee 提交了 “Mesh” 提案，这个提案后续就是被我们所熟知的万维网（World Wide Web）。在这 49 年间，互联网取得了很大的进展，从最开始的两台计算机之间交换数据包，到目前超过 750 万的服务器，38 亿的互联网用户与 13 亿的网站。

在这篇文章中，我们将试图分析现代浏览器所使用的技术，是在你未察觉的情况下自动提高了性能，我们将特别聚焦到浏览器网络层这里来，我们也会提供一些其他能够帮助你的 Web 应用提升性能的想法。

其实我们对于那些用于展示 13 亿网站的技术已经都比较熟悉了。我们现在在讨论的是浏览器本身，现代浏览器已经被设计成可以快速高效且安全的分发 Web 应用/网站。从进程管理和安全沙箱到 GPU 管道，音视频等等，数以百计的组件运行在不同的层上，Web 浏览器与其说是一个应用软件，更像是一个操作系统。

浏览器的整体性能是被这几大组件决定的：解析、布局、样式计算、JS 和 WebAssembly 执行、渲染，当然，还有网络层（网络协议堆栈）。网络层经常被认为是性能瓶颈，通常确实如此，因为接下来的几步都依赖于网络资源首先需要被拉取下来。如果网络层要更加高效，它将不仅仅只是充当 socket 管理这一个角色。虽然它表面上只做了一个非常简单的资源拉取机制，但背后其实有一套完整的优化准则、API 和服务。

作为一个 Web 开发者，我们不用关心单个的 TCP 或 UDP 包、请求格式、缓存以及其他什么东西，整个过程已经被浏览器接管了，我们只需要专注于应用开发即可。不过我们稍微刘接下 Web 浏览器底层细节又不会死…事实上它还能帮助我们创造出更快更安全的应用。

当用户开始和浏览器交互的时候，大致上发生了这些事：

• 用户在浏览器地址栏输入 URL
• 浏览器从 URL 里得到域名，并向 DNS 请求服务器对应的 IP 地址
• 浏览器向页面所在的远程服务器建立 HTTP