Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

H5开发经验小结-待完成 #8

Open
Jsmond2016 opened this issue Jul 4, 2021 · 0 comments
Open

H5开发经验小结-待完成 #8

Jsmond2016 opened this issue Jul 4, 2021 · 0 comments
Labels
TODO 待完成/待完善

Comments

@Jsmond2016
Copy link
Owner

说明:文章待完成部分

  • 实战开发总结
  • 思维导图总结

思维导图地址:https://www.processon.com/view/link/60d49a45e401fd50b99305b1#map

什么是 H5

H5 这个词,可以理解成就是混合 App 模型,只不过它特指混合 App 的前端部分。 因为混合 App 的前端就是 HTML5 网页,所以简称 H5。—— 阮一峰

不同类型H5的特点

H5 应用分为 3 种:

  • Web 应用
  • 混合应用
  • 小程序

Web 应用

美团

Web App 是使用网页做的应用程序,必须在浏览器中使用。

基本介绍

  • 优点:
    • 不占用内存:不需要下载安装,打开浏览器就能使用。
    • 调试和发布方便:对于开发者来说,Web App 写起来比较快,调试容易,不需要应用商店的批准就能发布。
    • 维护成本低:若代码合理,一个前端可以维护多个 Web App
  • 缺点:
    • 原生能力差:浏览器提供的 API(即 Web API)很有限。大部分系统硬件都不能通过网页访问,也无法直接读取硬盘文件,所以 Web App 无法充分利用平台的硬件。
    • 性能受限:网页通过浏览器渲染,性能不如原生 App,不适合做性能要求较高的页面。
    • 临时性入口,用户粘性差。
  • 劣势:
    • 需要打开浏览器才能使用——要求用户必须记住该网页地址才能找到它。
    • 不能从手机的首屏直接进入。
    • 缺乏手机状态栏和锁屏时的通知推送能力。
    • 不支持脱机访问(即断网也能使用)。
  • Chrome 团队开发了新技术:PWA
    • PWA:Progressive Web App,缩写 PWA。渐进式 Web App。
    • 它可以把网站缓存在手机里面,供离线时使用。
    • 在手机首屏生成图标,直接点击进入,并且有通知推送能力。
    • 也不带有浏览器的地址栏和状态栏,跟原生 App 的使用体验非常接近。
  • 使用 PWA 前提:PWA 需要浏览器访问一次网站,才能在首屏生成图标。但它的支持度受限于不同手机端支持度(兼容性问题)

主要技术栈:

  • HTML
  • CSS
  • JavaScript

内部产品代表

  • 意向登记
  • 在线开盘
  • 移动交易

混合应用

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

混合 App 的原生外壳称为"容器",内部隐藏的浏览器,通常使用系统提供的网页渲染控件(即 WebView 控件),也可以自己内置一个浏览器内核。结构上,混合 App 从上到下分成三层:HTML5 网页层、网页引擎层(本质上是一个隔离的浏览器实例)、容器层。

API Bridge

混合 App 里面的网页不同于普通网页,可以调用底层系统所有的 API。奥秘就在于 外层容器提供了 API Bridge,充当底层 API 的中介,允许内部的网页调用底层。

所谓 API Bridge 就是容器在底层接口和网页之间,建立一座桥梁,让双方通信。容器一旦接到网页的请求,就根据请求去调用底层系统的 API,然后再返回结果给网页。API Bridge 往往以 JavaScript 语言提供,方便网页调用,这时又称为 JSbridge。

关系图

  • 优点:H5 所有的优点
    • 开发成本低,可以跨平台,调试方便
    • 维护成本低,功能可复用。
    • 更新速度快,自由、不受限于应用商店。
    • 功能完善,体验更佳:想必 WebApp,多了具备操作原生API的能力。
  • 缺点:
    • 相比原生应用,性能、体验差距明显
    • 不适用交互性强的 app。

对比表格:来源 Hybrid APP基础篇(二)->Native、Hybrid、React Native、Web App方案的分析比较

Native App Web App Hybrid App
原生功能体验 优秀
渲染性能 非常快
是否支持设备底层访问 支持 不支持
网络要求 支持离线 依赖网络
更新复杂度 高(几乎总是通过应用商店更新) 低(服务器端直接更新)
编程语言 Android(Java),iOS(OC/Swift) js+html+css3
社区资源 丰富(Android,iOS单独学习) 丰富(大量前端资源)
上手难度 难(不同平台需要单独学习) 简单(写一次,支持不同平台访问)
开发周期
开发成本 昂贵 便宜
跨平台 不跨平台 所有H5浏览器
APP发布 App Store Web服务器

产品代表

  • LinkedIn、Yelp、Netflix、Wunderlist

小程序

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

当前,各个大厂都有自己的小程序:支付宝小程序,百度小程序,微信小程序等。

H5 开发

App 开发技术方案:

  • 原生开发:安卓——Java技术栈,IOS——Object-C 或 Swift 技术栈。

  • 混合开发:Web 技术栈 + 容器技术栈

    • PhoneGap
    • Cordova 公司正在用的这种
    • Ionic
  • 跨平台技术:

    • React Native 当前还不是特别成熟,最新版本是 0.6x
    • Flutter 已发布 2.0, 不少公司已经在尝试,社区日渐繁荣,未来可期。

对于 H5 中 Web App 的开发,采用 前端三剑客(HTML,CSS,JavaScript)技术方式实现。

DPR 相关

css 中的 1px 并不等于设备的1px

在css中我们一般使用px作为单位,在桌面浏览器中css的1个像素往往都是对应着电脑屏幕的1个物理像素,这可能会造成我们的一个错觉,那就是css中的像素就是设备的物理像素。

但实际情况却并非如此,css中的像素只是一个抽象的单位,在不同的设备或不同的环境中,css中的1px所代表的设备物理像素是不同的。

在早先的移动设备中,屏幕像素密度都比较低,如iphone3,它的分辨率为 320x480,**在iphone3上,一个 css 像素确实是等于一个屏幕物理像素的。**后来随着技术的发展,移动设备的屏幕像素密度越来越高。

从iphone4开始,苹果公司便推出了所谓的Retina屏,分辨率提高了一倍,变成640x960,但屏幕尺寸却没变化,这就意味着同样大小的屏幕上,像素却多了一倍,这时,一个 css 像素是等于两个物理像素的。其他品牌的移动设备也是这个道理。例如安卓设备根据屏幕像素密度可分为ldpi、mdpi、hdpi、xhdpi等不同的等级,分辨率也是五花八门,安卓设备上的一个css像素相当于多少个屏幕物理像素,也因设备的不同而不同,没有一个定论。

还有一个因素也会引起css中px的变化,那就是用户缩放。例如,当用户把页面放大一倍,那么css中1px所代表的物理像素也会增加一倍;反之把页面缩小一倍,css中1px所代表的物理像素也会减少一倍。

在移动端浏览器中以及某些桌面浏览器中,window对象有一个devicePixelRatio属性,它的官方的定义为:

设备物理像素和设备独立像素的比例,也就是 devicePixelRatio = 物理像素 / 独立像素。

css中的px就可以看做是设备的独立像素,所以通过devicePixelRatio,我们可以知道该设备上一个css像素代表多少个物理像素。例如,在Retina屏的iphone上,devicePixelRatio的值为2,也就是说1个css像素相当于2个物理像素。

为什么移动端设计稿总是640px和750px

  • 设计师给我们的 UI 图是根据 **物理像素(px)**来设计的
  • 而设计师不可能针对每一种分辨率的手机都出一个对应的UI图,因此取分辨率相对大的设备作为参考标准,其他设备则向下兼容。
  • 设计师选择了 IPhone 6 ,分辨率为 750 * 1334 的手机作为设计参考标准。而向下兼容,IPhone5 的分辨率为 640 * 1136
  • 这就是为什么设计师的设计稿通常是 640 和 750 的。

移动端常见的布局方案:

viewport 设置

最标准的viewport设置

  • 视口宽度和设备保持一致
  • 视口的默认缩放比例1.0
  • 不允许用户自行缩放
  • 最大允许的缩放比例1.0
  • 最小允许的缩放比例1.0
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">

布局方案

  • 媒体查询:针对不同设备宽度,写一套对应的 css。缺点是:费时费力,在浏览器大小改变时,需要改变的样式太多,那么多套样式代码会很繁琐。
  • 流式布局/百分比布局:使用百分比定义宽高,从而支持不同宽度屏幕进行自适应。缺点如下:
    • 计算困难,如果我们要定义一个元素的宽度和高度,按照设计稿,必须换算成百分比单位。
    • 属性中如果使用百分比,相对父元素的属性并不是唯一的。比如width和height相对于父元素的width和height,而margin、padding不管垂直还是水平方向都相对比父元素的宽度、border-radius则是相对于元素自身等等,造成我们使用百分比单位容易使布局问题变得复杂。
  • flex + px 弹性布局方案:特点,主要针对宽度变化
    • 含义:
    • 优缺点:因为写的是 px,设备宽度更大了,弹性布局也随之放大,但是字体等大小,行高是定死的不会变化
  • vw + vh 相对视口宽高的单位
    • 含义:vw 和 vh 分别是相对于设备 宽度和高度的 1%。
    • 优缺点:
  • rem:font size of the root element,是指相对于根元素的字体大小的单位
    • 默认情况下,1rem 等于 12px
    • 使用 scss 开发时,可以借助 px2rem-loader 等工具的辅助。

项目开发注意问题

  • 准备工作
    • 细看 高保真 UI,将图标 图片传入 Iconfont 仓库
    • 选定移动端 UI 框架
    • 根据 高保真 UI,覆盖 theme.scss 文件,定义好主题色,按钮字体颜色等基础主题样式
  • 确定布局方案,如上述的 流式布局,弹性布局,vw/vh,rem 等。
  • 开发注意问题
    • 弹性布局,不写高度,间距尽可能从内部撑开(使用 padding)
    • 图片和背景图
    • 各种属性的兼容性
  • H5 UI 支持和踩坑

1px 处理?

参考资料




@Jsmond2016 Jsmond2016 added the TODO 待完成/待完善 label Mar 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TODO 待完成/待完善
Projects
None yet
Development

No branches or pull requests

1 participant