360前端星——0412笔记（结束撒花）

小程序，大世界

简介

解决了什么问题

• H5
  • 开发速度快
  • 各平台一致性较好
  • 执行时具有较长的白屏时间
• APP
  • 开发成本大
  • 体验更好
• 小程序：在上述两者之间找到了平衡
  • 降低了开发成本
  • 各个平台可以使用统一的技术栈

www.ruanyifeng.com/blog/2019/1…

按照开发技术，App 可以分成三大类。

• 原生应用（native application，简称 native App）

  • 原生 App 是专门为特定手机平台开发的应用程序 ，无法在其他平台运行。一个手机软件如果要同时支持苹果手机和安卓手机，就需要为它们各写一个原生 App。
  • 原生 App 使用与手机操作系统相同的语言。iOS 的原生 App 使用 Objective-C 语言或 Swift 语言，安卓使用 Java 语言或 Kotlin 语言。由于跟底层系统的语言和技术模型一致，所以原生 App 的性能和用户体验都很好。
  • 优点主要是两个：（1）较好的性能和体验；（2）可以使用系统的所有硬件和软件 API，比如 GPS、摄像头、麦克风、加速计、通知推送等等，能充分发挥系统的潜力。
  • 缺点主要是成本，每个手机平台都要建立一个独立的开发团队，大公司一般都有 iOS 和安卓两个开发团队。原生 App 使用底层操作系统的语言，都是很重的编译型语言，开发和调试成本相对较高，时间周期长。原生 App 必须下载安装才能使用，只要升级版本，就必须重新下载安装。用户往往不愿意更新版本，厂商被迫不得不长期支持很久以前的旧版本。

• Web 应用（web application，简称 Web App）

  • Web App 是使用网页做的应用程序，必须在浏览器中使用。
  • Web App 主要使用网页技术，即 HTML、JavaScript 和 CSS。
  • 优点是：（1）不需要下载安装，打开浏览器就能使用，而且总是使用最新版本；（2）对于开发者来说，Web App 写起来比较快，调试容易，不需要应用商店的批准就能发布。
  • 主要缺点有两个。首先，浏览器提供的 API（即 Web API）很有限（目前只有相机、GPS、电池等少数几个），大部分系统硬件都不能通过网页访问，也无法直接读取硬盘文件，所以 Web App 无法充分利用平台的硬件。第二个缺点是，网页通过浏览器渲染，性能不如原生 App，不适合做性能要求较高的页面。

• 混合应用（hybrid application，简称 hybrid App）

  • 混合 App （hybrid App）顾名思义就是原生 App 与 Web App 的结合。它的壳是原生 App，但是里面放的是网页。 可以理解成，混合 App 里面隐藏了一个浏览器，用户看到的实际上是这个隐藏浏览器渲染出来的网页。

  • 优点：

    • （1）跨平台

      Web 技术是跨平台的，开发者只写一次页面，就能支持多个平台。也就是说，混合 App 只需要一个团队就够了，开发成本较低。

    • （2）灵活性

      混合 App 的灵活性大，很容易集成多种功能。一方面，混合 App 很容易加载外部的 H5 页面，实现 App 的插件结构；另一方面，Web 页面可以方便地调用外部的 Web 服务。

    • （3）开发方便

      Web 页面的调试和构建，远比原生控件简单省时。页面的更新也容易，只要在服务器上发布新版本，触发容器内更新就可以了。另外，Web 开发人员也比较容易招聘，传统的前端程序员可以承担开发任务。

  • 主要缺点是，由于存在网页引擎的中间层，所以性能比较欠缺，不仅不如原生 App，而且由于 WebView 不是全功能浏览器，可能比 Web App 都要慢一些。另一个缺点是，由于页面跨平台，就无法使用只有特定平台提供的功能，导致体验不如纯的原生 App。举例来说，早期的时候，安卓有物理的后退按钮，iPhone 没有，页面设计不得不考虑这一点。

这三类 App 的技术模型都不一样，各有优缺点。企业一般会选择其中一种作为主要技术栈，构建自己的手机 App。

H5 这个词，可以理解成就是混合 App 模型，只不过它特指混合 App 的前端部分。 因为混合 App 的前端就是 HTML5 网页，所以简称 H5。这个词是国内独有的，基本上都是前端程序员在用，国外不用这个词，就直接叫混合 App。

所谓小程序，可以看作是针对特定容器的 H5 开发。微信本身是一个容器，开放自己的接口（JSbridge），外部开发者使用规定的语法，编写页面，容器可以动态加载这些页面。

小程序对于微信官方的好处是，扩展了功能和应用场景，吸引外部开发者加入，繁荣了生态。对于外部开发者的好处是，有了流量入口，可以直接调用微信的各种功能（比如支付）。

小程序技术栈

• HTML/CSS/JavaScript
• NodeJS
• 移动适配
• HTTP协议/HTTPS
• OAuth2认证方案
• GIT

类似小程序的技术

• Cordova： 通过webview渲染， 通过插件调⽤系统服务
• PWA： Service Worker和Push API
• React Native/Weex： JavaScript通过JavaScriptCore等执行， 并 通过Bridges和Native组件交互
• Flutter： Dart直接与独立系统的UI库进行交互

小程序技术架构

• 文件结构及其含义
  • .json 后缀的 JSON 配置文件
    • 小程序文件配置app.json
      • pages：描述当前页面路径
      • window：顶部背景颜色、问自定义等
    • 微信开发者工具配置project.config.json
    • 个性化page，每个page的json
    • 指导搜索引擎检索sitemap.json
  • .wxml 后缀的 WXML 模板文件
    • 本质是HTML模版
    • 有特定的标签
    • 接管⼀些简单的逻辑判断，数据模板等
    • JS不直接操作DOM， 只负责set数据
    • MVVM模式
  • .wxss 后缀的 WXSS 样式文件
    • 提供rpx单位
      • 屏幕宽度与750的比值
    • 精简的CSS
    • 提供全局和局部的CSS
  • .js 后缀的 JS 脚本逻辑文件
    • 负责逻辑交互
    • APP 、 Page、 Component三个构造函数
    • 可调⽤系统API
• 双线程模型
  • 渲染层采用webview
  • 逻辑层采用JsCore
  • 任何数据传递都是线程间的通信，存在一定的延时

• ⽣命周期

界面渲染的整体流程

1、在渲染层将wxml文件与wxss文件转化成js对象也就是虚拟DOM

2、在逻辑层将虚拟的DOM对象配合生成真实的DOM树，再交给渲染层渲染

3、当数据变化时，逻辑层提供更新数据，js对象发生改变，用diff算法进行比较

4、将更新的内容反馈到真实的DOM树中，更新页面

• 组件
  • 用于快速界面搭建
  • 官方、原生、自定义
• 其他
  • 插件机制
  • 云端函数
  • 小游戏

开发发布流程

• 开发者在小程序平台注册小程序， 以获得APPID
• 初始化代码并完成代码仓库配置
• 开发代码并调试
• 上传并发布

小程序的发展

• 多端同构框架
  • 意义： ⼀次编写适配多端， ⼀次迭代各端同步
  • 利⽤Web的优点， 以及对各个平台进⾏动态适配
  • 如 uni-app，兼容Vue语法
  • 入口是分开的，页面公用
• ⾃动化
  • 控制小程序跳转到指定页面
  • 获取小程序页面数据
  • 获取小程序页面元素状态
  • 触发小程序元素绑定事件
  • 往 AppService 注⼊代码⽚段
  • 调⽤ wx 对象上任意接⼝
• 硬件框架
• 云IDE
• W3C小程序⼯作组

Web前端点播直播入门

什么是视频

• 格式与内容

  • 文件扩展名约等于媒体封装格式
  • 媒体封装格式不等于音视频编码格式（标准&打包）
  • 文件内容：
    • 头信息，格式、分辨率等
    • 索引信息
    • 视频数据
    • 音频数据
    • 附加增强数据，自定义信息

• 视频数据

  • 显示器颜色呈现基于RGB(红绿蓝)颜色空间模型
  • 视频领域大多基于YUV颜色空间做抽样存储
    • 减少存储压力
  • 帧内预测&帧间预测复用进一步有效的压缩数据
  • P帧(前向预测帧)、B帧(双向预测帧)、I帧(参考帧)
  • 基于通用标准集N多技术于一身

• 音频数据

  • 声音：不同振幅&频率而产生的机械波；数字形式是一维波形
  • 对自然中连续的声波采样，做数字化PCM存储
  • 扬声器还原PCM(脉冲编码调制)数字信号为模拟音频信号
  • 音频压缩基本算法：预测、变换
  • 基于通用标准集N多技术于一身 --- 音频编码器 AAC、MP3...

• 传输协议

  • 传统场景

    • 流媒体(直播)

      • HLS：苹果为利用现有CDN设施而发明的"流媒体"协议
      • HTTP(S)-FLV：基于HTTP的流媒体协议
        • 浏览器上不一定支持
      • RTMP、RTP/RTSP、TS、MMS...

    • 点播传输

      • HTTP(S)：通过Range方式或参数方式完成Seek

  • Web端

    • HTTP(S)、webSocket(S)、P2P

• 播放器原理

  • 解协议(加载数据)
  • 解封装(解复用)
    • 按照不同容器类型
  • 解码
    • 还原的过程
  • 渲染

好玩的Web端API

• 媒体兼容判断
  • 创建video标签，通过canPlayType判断是否支持
• 交互式视频
  • 通过按钮控制视频进度的跳转
• 播放本地视频文件
  • 基于FileReader，获得result，作为video的src
• 播放硬件资源
  • getUserMedia调用摄像头或麦克风
  • 将返回的视频流赋值给video的srcObject
• 实现视频录制
  • MediaRecoder
• 基于MediaSource播放JS拉取的媒体数据
  • 基于XHR
  • 创建动态媒体源，并关联到video元素上

Web端点播直播&播放方案

• 点播直播的区别
  • 应用流程
    • 点播：创作者 => 上传服务器 => 转码 => 存储 <=> CDN分发 <=> 观众
      • 已经录制好的内容
    • 直播：创作者 => 推流 <=> 存储 <=> 转码 <=> CDN分发 <=> 观众
      • 实时的，通过采集设备
  • 媒体类型的选择
    • HTTP(S)-MP4 点播服务
    • HTTP(S)-FLV 点播、直播
    • HTTP(S)-HLS 点播、直播(高延迟)
• 播放器解决方案
  • 原生浏览器支持的
    • 原生Video播放
  • 原生浏览器不支持的
    1. 协议或容器类型不支持
       • JS解协议下载数据、解容器、重新封装，然后通过MSE给Video解码、渲染播放
    2. 解码器不支持
       • JS下载数据，WASM 解容器、解码，通过 WebGL&WebAudio 渲染播放
    3. 有解密需求的
       • 参考前两条，在解容器之后对每帧数据启用解密逻辑

前端代码的自我修养

• 代码规范

  • yarn global add eslint
    • 依赖配置文件，对标准进行配置
  • 质量问题
    • no-fallthrough
  • 风格问题
    • max-depth
    • 难以维护

• 格式

  • 很多框架也会使用eslint
  • .eslintrc.js
  • package.json
  • .prettierrc
    • 实现代码风格的统一

• 流程化

  • git flow
  • 所有开发工作在分支上进行

• 提交代码

  • git commit message规范

    • 工具：yarn global add commitizen cz-conventional-changelog standard-version

      commitizen init cz-conventional-changelog --yarn --dev --exact

    • 自动生成change log

  • 合并提交

    • git rebase -i $GIT_LOG_VERSION$
    • 尽量不要在远程分支上使用这个命令，合并别人分支的时候不合适

技术翻译：进阶的直梯

• 翻译的类型
  • 文学翻译：小说、诗歌
  • 非文学翻译：商业、技术类
    • 出现错误会导致比较严重的问题
• 技术翻译的意义
  • 新技术思想
    • 订阅技术类中英文书刊
  • 掌握标准和工具
    • Web标准、开发框架的文档
  • 名声与报酬
• 技术翻译的标准
  • 准确、地道、简洁
• 技术翻译的方法
  • 消化吸收原文
  • 翻译意思，而不是字面
• 技术翻译要坚持技术驱动