Viewport :字面意思为视图窗口,在移动 web 开发中使用.表示将设备浏览器宽度虚拟成一个特定的值(或计算得出),这样利于移动 web 站点跨设备显示效果基本一致. 基本写法: <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, minimum-scale=1,target-densitydpi=medium-dpi"> 测试获取…

在 PC 端,视口指的是浏览器的可视区域,其宽度和浏览器窗口的宽度保持一致.在 CSS 标准文档中,视口也被称为初始包含块,它是所有 CSS 百分比宽度推算的根源,给 CSS 布局限制了一个最大宽度. 而移动端则较为复杂,它涉及到三个视口:布局视口(Layout Viewport).视觉视口(Visual Viewport)和理想视口(Ideal Viewport). 本文主要讨论移动端中的视口. 1. 基本概念 1.1 两种像素 像素是计算机屏幕中显示特定颜色的最小区域.屏幕中的像素越多,同一…

H5 端 rem 适配方案与 viewport 适配 rem rem 是 CSS3 新增的一个相对单位(root em,根 em) 只根据当前页面 HTML 页面的 font-size 设置,如果根目录的 font-size 为 18px,则 1rem=18px 媒体查询设置 @media screen and (min-width: 320px) { html { font-size: 32px; } } @media screen and (min-width: 375px) { html…

TYPESDK 服务端设计思路与架构之一:应用场景分析 作为一个渠道SDK统一接入框架,TYPESDK从一开始,所面对的需求场景就是多款游戏,通过一个统一的SDK服务端,能够同时接入几十个甚至几百个各种渠道的SDK.而且这些渠道接口的具体接入字段和接入逻辑,每个月以至每周,都可能发生或大或小的变动.在这样一个复杂的应用场景下,我们应该如何设计一个足够强大而又足够灵活的SDK服务端呢? 首先我们需要厘清,在整个应用场景中,TYPESDK所处的位置,以及它所需要实现的核心功能. 图1 如图1所示,T…

通过前几天写的两篇博客(浅谈移动端三大viewport和移动端em和rem区别),我们现在来总结一下如何实现一个最佳方案. 之前在第二篇博客中提到过我们可以使用媒体查询来针对不同设备及做适配,如下图 但是这个可能不会太精准,比如我的设备布局viewport可能是370px,这样只能使用320这一版本.而事实上,他们的viewport并不相同,所以他们的布局也得不一样.也就是说我们如果用css媒体查询只能说是可以用,但不是最佳实践.其实通过看某些牛逼的移动端网站,可以看到他们的共同点,他们都是使用…

本文系个人理解,可能有误差,仅供参考,谨慎采纳! 布局视口: 系统自带 一般大于屏幕宽度 理想宽度:  设置页面的viewport 的一个宽度,使不同的手机的布局视口宽度尽量接近可视窗口的值: 可视视口:即屏幕宽度 第一种情况:不显示地设置viewport:  若代码中网页宽度小于设备默认值 按 默认,大于设备默认则viewport的宽度变为网页的最大值. 那么width的默认为手机厂商自定义的 布局视口layout viewport  宽度有980 1024等等,如: 手机宽度为980, 1)…

在前一篇文中,我们对一个聚合SDK服务端所需要实现的功能作了简单的分析.通过两个主要场景的功能流程图,我们可以看到,作为多款游戏要适配多个渠道的统一请求转发中心,TYPESDK服务端主要需要实现的功能有以下几个要点: l  接收请求和返回响应,通常是HTTP的请求响应. l  获取配置信息. n  识别游戏,根据请求中的信息,获取到具体游戏的相关配置. n  识别渠道,根据请求中的信息,获取针对具体渠道的配置. n  根据请求中的信息,获取特定游戏在渠道上的参数 l  处理请求逻辑,根据请求种类…

有了前文几个步骤的分析和设计,TYPESDK的信息交互流程已经可以正常工作了,但是,这个流程还没有考虑到支付这样的过程中,至关重要的信息安全问题. 在整个交互过程中,游戏服务端,SDK服务端,渠道服务端都属于安全区域,这部分发生的数据交互,基本是可以信任的,只需要作相对简单的处理工作:而客户端,包括游戏客户端,SDK客户端都属于危险区域,在这部分产生的数据和请求,都有可能受到外部的拦截和篡改.因此,我们需要在流程上加以预防和控制. 图1 从示意图1可以看出.针对三类不同安全性的数据流,我们的处理…

经过前两篇文字的分析与设计,我们已经可以搭建出一个能够支持多游戏多渠道的聚合SDK服务端,但这只是理想化状态下的一个简化模型.如果接入渠道的逻辑都是按照理想化的简化过程来构建,那么对于支付的请求,我们可以简化成这样几步: 游戏客户端创建订单. 游戏客户端(通过TYPESDK客户端)调用渠道lib库中相应接口,发起支付. 用户在弹出的支付窗口完成支付. TYPESDK服务端等待渠道服务端的回调,收到回调后通知游戏服务端. 游戏服务端执行发货动作. 但是显然这个简化流程在实际上线时是不够满足需求的,…

2014年,移动APP的热度丝毫没有减退,怎么为您的移动端app设计良好的服务器端接口(API)呢? 下面谈谈我个人的一些想法. 2014年,移动APP的热度丝毫没有减退,并没有像桌面软件被WEB网站那样所取代,不但如此,越来越多的传统应用.网站也都开始制作自己的移动APP,也就是我们常说的IOS客户端.Android客户端. 这仿佛又回到了多年前的CS架构,那时候我们用VB.VC.Delphi在Windows平台上快速开发各种应用程序. 不同的是,如今的移动端APP基本上都是联网从服务器端获取…