移动互联网终端

最近小伙伴说她的下个项目是移动端的，她说她没搞过移动端的东西以后要多问问我这个菜鸡，然后脑子里一下子冒出来之前困扰我很久的适配问题，突然想起来还没做记录，趁我代码还没删我先在这里记录一手，万一下个项目我又碰到移动端了也免得忘了又到处去问度娘（遥远的七八个月之后，北漂小菜不想呆在北京啦，哭唧唧） 因为iphoneX这个该死的刘海屏，竟然是放了个刘海遮住界面的一部分，这就很气，你写出来的界面的上面就会被刘海给遮住，如果有个按钮啥的点也点不动 解决办法就是把整个界面抠出来，然后再把整体界面往下移单位个刘海的高度的距离 <meta name="viewport" content="width=device-width,initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0,user-scalable=no,view-fit=cover"/> 这里面的view-fit = cover就是点睛之笔，相当于把整个界面抠出来 但是抠归扣，本来安卓跟iphoneX以下的机子的界面就是整个平铺的，你不能影响其他的界面吧，因此适配之所以叫做适配，是因为只对要适配的机子生效咯 于是在你的界面里放一个旨在iphoneX情况下才生效的样式： @media only screen and (device-width: 375px) and (device

概述 最近心血来潮，想仿造一下易企秀，做一个新的编辑器。主要是3年前那个编辑器有些自动化方面和动画性能方面的缺陷吧，人生不能有遗憾就早早动手吧。选择易企秀，而不是互动大师，主要是因为易企秀的技术难度比较低，编辑器的核心部分，如果全职开发，估计一个月就做完了。如果是互动大师，业余时间开发根本估计核心部分都够呛。核心部分包括拖拉拽，组件生命周期，场景增删改，工程增删改，完善的组件事件通信机制，撤销恢复还有动画编辑。 有兴趣的朋友可以进 github 看看。里面有在线演示的地址。该项目还在持续开发中，轻拍，别打脸。 拖拉拽的核心原理 不同的编辑器，不管怎么样，拖拉拽的业务逻辑一定要自己写，这是血的教训。两年前，接手一家公司的编辑器，那个编辑器的核心部分是用某个开源项目的，性能有问题，核心元数据的数据结构也有问题。重构了几次，才契合当时公司的业务。 性能优化 拖拉拽，其实难的是性能处理，尤其是移动端。要是一个场景里面几百个组件，移动端就很痛苦了。 首先必须使用事件委托，因为事件具有冒泡机制，因此我们可以利用冒泡的原理，把事件加到父级上，触发执行效果。这样做的好处当然就是提高性能了。 假如没有使用事件委托，那么100个组件，每个组件1个旋转点，8个缩放点，1个移动点，那么就要添加800个mousedown事件。如果使用事件委托，就只要一个mousedown事件就好。 原理是用户点击页面的时候

常见方式： 1. 固定宽度(320)做法：这样前端倒是爽了，可是大页面两边有留白，小页面图标文字又会缩的很小，用户体验极其不好。 2. 流式布局：其实就是用%，这样宽度倒还差不多，高度怎么搞？所以这种布局一般都是宽度自适应高度写死，显的很不协调，另外对设计也有很大的限制，另外还有兼容性方面的问题。 3. 响应式布局：说白了就是利用CSS3中的Media Query（媒介查询），喊的很火，谁用谁知道，简直累死人不要命。 4. 设置viewport进行缩放：以320 宽度为基准，进行缩放，最大缩放为320*1.3 = 416，基本缩放到416都就可以兼容iphone6 plus的屏幕了。<meta name="viewport" content="width=320,maximum-scale=1.3,user-scalable=no"> 5. 利用vh、vw适配：兼容性太差。 rem是什么 rem是一个相对根元素html字体大小的单位，所以它的大小是由html的fontSize大小决定的，假如我把html的fontSize设置为10px，此时的1rem就等于10px，假如我把html的fontSize设置为100px，此时的1rem就等于100px，这也正是我们能用rem做移动端适配的根本原因，就是通过不同屏幕下改变根元素fontSize的大小

随着互联网的深入发展，前端开发工程师一跃成为市场上非常抢手的人才。很多同学，包括以前做UI的、Java的、或者对于IT完全零基础的同学都想学习前端。下图是网上流传甚广的一张前端学习思维导图，很多初学者表示看到这些密密麻麻的知识点就已经晕了。确实，前端是一门涵盖面很广的学科。但是想学前端的你也不用慌张，内容虽多但有迹可循，只要循序渐进就不怕学不好前端！ 那么前端开发到底需要学什么？应该怎么学？接下来小编教你如何从零基础学习前端。 一、前端开发入门 在入门阶段，你首先要学会最基本的技能：根据UI的设计稿，实现HTML的静态页面制作。这就要求你得掌握HTML、CSS页面布局排版、样式美化等技能。 在这个阶段你需要学习： 1、HTML+CSS基础 掌握HTML的标签使用、排版技巧、CSS的布局定位、样式美化、浏览器兼容性。 2、JavaScript基础 掌握JS的基本语法、条件、语句、循环等，学会常用算法，增强逻辑性。 3、常用的前端工具 比如Webstrom、Sublime、Dreamweaver等。掌握其快捷键设置等技巧，可快速提高开发调试效率。 这个阶段的学习难度相对不高，学完这些之后，我们已经能完成静态页面的制作。当然，这只是入门，如果你想用这些技能找工作的话还是比较困难的。 二、前端开发初级 在接下来的这一个阶段，我们的目标是达到前端开发行业的基本要求

今年2019年，又有一大批社交产品发布，迎来垂直社交的第二春。许多老社区站长也热血沸腾。 然而情怀依旧在，社区论坛的时代却已经不复当年，现在的市场格局已经不再像当时那样。多年前流量聚集在PC端，DZ靠PC端的论坛系统一统江湖。随后被腾讯收购。随后项目停止更新，官方社区停止维护。 纵观现在的格局，大众社区已经难有机会。垂直领域也已经有大量的竞争对手。也许还有很多站长朋友艰难维持PC社区的热度，但也难以遏制用户不断流失的趋势。 不是用户变心了，而是时代变了，方法变了。 ▼1.什么是全渠道的运营？ 现在用户可选择的终端多。除了传统的PC，还有移动端的各大终端，且移动端和PC端的比例已经呈现9:1的格局。也就是10个用户里，就有9个是移动端的用户。PC端只占1成。 随之而来的问题就是，我们需要变更运营策略，把重心放到移动端。 然而移动端的终端众多。目前存在的平台有：H5（公众号），APP和各家小程序。 H5端的兼容性最佳，可以运行在大部分的环境下，且由于其优秀的跨端性，甚至可以以接入到各大app当中。也可以接入公众号。公众号方面已经错过红利时期，目前消息到达和推送打开率都不断走低。 APP目前主流的平台有ios和安卓。Ios由于审核门槛高，对部分站长的网站内容不友好，很难上架。纵然使用企业签名，仍然要打游击战。安卓端由于比较去中心化。难以集中管理，所以相对来说更自由。 小程序方面：

1.5.1 什么是插件 移动端要求的是快速开发，所以我们经常会借助于一些插件来帮我完成操作，那么什么是插件呢？ JS 插件 ：是 js 文件，它遵循一定规范编写，方便程序展示效果，拥有特定功能且方便调用。如轮播图和瀑布流插件。 特点：它一般是为了解决某个问题而专门存在，其功能单一，并且比较小。 我们以前写的animate.js 也算一个最简单的插件 fastclick 插件解决 300ms 延迟。 GitHub官网地址： https:// github.com/ftlabs/fastclick 1.5.2 插件的使用 引入 js 插件文件。 按照规定语法使用。 fastclick 插件解决 300ms 延迟。 GitHub官网地址： https://github.com/ftlabs/fastclick if ('addEventListener' in document) { document.addEventListener('DOMContentLoaded', function() { FastClick.attach(document.body); }, false); } 1.5.3 Swiper 插件的使用 中文官网地址： https://www.swiper.com.cn/ 引入插件相关文件。 按照规定语法使用 1.5.4 其他移动端常见插件：lsuperslide

BootStrap常用组件 PS:所有的代码必须写在<class="container/container-fluid">容器当中 常用组件包含内容: 字体图标 下拉菜单 按钮组 输入框俎 导航 分页 标签和徽章 页头 缩率图 进度条 进度条示例： var $d1 = $("#d1"); var width = 0; var theID = setInterval(setValue, 200); function setValue() { if (width === 100) { clearInterval(theID); } else { width++; $d1.css("width", width+"%").text(width+"%"); } } 响应式开发 为什么要进行响应式开发？ 随着移动设备的流行，网页设计必须要考虑到移动端的设计。同一个网站为了兼容PC端和移动端显示，就需要进行响应式开发。 什么是响应式？ 利用媒体查询，让同一个网站兼容不同的终端（PC端、移动端）呈现不同的页面布局。 用到的技术： CSS3@media查询 用于查询设备是否符合某一特定条件，这些特定条件包括屏幕尺寸、是否可触摸、屏幕精度、横屏竖屏等信息。 常见属性： device-width, device-height 屏幕宽、高 width,height 渲染窗口宽、高 orientation

现在的移动应用中消息推送已经成为不可或缺的功能了，这样可以增加与用户的交互。 使用消息推送的方法有很多，原理大致是：移动端与消息服务器保持一个长连接，一旦服务器有消息就推给客户端，客户端收到消息做相应的处理。 消息推送 参考的实现方式： 1、XMPP协议实现的openfire可以作为消息服务器。客户端也有asmack封装好了xmpp协议。openfire提供了一套IM所需的所有功能，而且支持插件形式的二次开发。 2、开源项目androidpn，也是实现了XMPP协议。 3、JPush极光推送。等一系列第三方的推送平台。 各自的优缺点： 1、openfire提供了IM的所有功能，功能非常强大，但是移动端如果只想集成消息推送的话，openfire就显得很是笨重。而且openfire的二次开发资料很少，一般需针对公司的业务开发，使用公司自己的数据库。服务器端开发成本高，周期长。openfire的并发连接好像也只有5000左右（做的比较好的情况下，一般都达不到这个数）。移动客户端也要根据xmpp协议与openfire服务器进行交互来完成消息推送。所以客户端的开发周期也长。 2、androidpn也是实现的XMPP，但是只实现了核心的功能，也需要针对公司的业务进行二次开发。基本和openfire的缺点差不多。 3、JPush集成非常简单，客户端和服务端都不需要进行二次开发

订阅号就像是会自动更新的收藏夹，或者是订阅邮件整理后的手机版。特点就是会推送到指定的用户群，缺点也是只会推送到指定的用户群。比起收藏夹和订阅邮件，订阅号的另一个优点就是可以分享到朋友圈，却只能分享到朋友圈，如果不够吸引的话，分分钟就会刷屏掉。毕竟“首页”太短。所以说订阅号不算是好的传播工具。 什么是好的传播工具？我也在问自己这个问题。 我们要推广，要传播，最基本的这个工具要有传播的能力：他能被轻松的分享到其他的平台，能被收藏或者记录下来。而订阅号只能分享到朋友圈，能收藏到微信，却不能被搜索引擎记住，也就是说用户通过搜索是找不到你的订阅号以及你订阅号的内容的； 第二，好的传播工具应该有大的覆盖面.也就是有机会将你的内容呈现给未知的用户和读者。新闻的头条，博客的首页，微博的推荐微博。潜在用户或读者有机会找到你，你也有机会展示你自己，不然这个平台就会极端化，名气大的人会更火，小众的就很难被发现。这样就缺乏可持续性。而订阅号或者服务号只是给关注给你的用户看，分享到朋友圈，用户首页的有效长度完全是由他手机的屏幕长度和他朋友发内容的长度决定的，没准他几个微信朋友做微商的，你的内容就悲剧了，而且你的好友圈不等于是关注你订阅号的人，你需要经营这两个号。 第三点，我认为就是内容自动筛选的能力，而且这个投票权在用户。因为用户喜欢的，才更有可能是其他用户喜欢的。现在无论是问答，博客

移动端适配，是我们在开发中经常会遇到的，这里面可能会遇到非常多的问题： 1px问题 UI图完美适配方案 iPhoneX适配方案 横屏适配 高清屏图片模糊问题 ... 上面这些问题可能我们在开发中已经知道如何解决，但是问题产生的原理，以及解决方案的原理可能会模糊不清。在解决这些问题的过程中，我们往往会遇到非常多的概念：像素、分辨率、PPI、DPI、DP、DIP、DPR、视口等等。 本文将从移动端适配的基础概念出发，探究移动端适配各种问题的解决方案和实现原理。 一、英寸 一般用英寸描述屏幕的物理大小，如电脑显示器的17、22，手机显示器的4.8、5.7等使用的单位都是英寸。 英寸和厘米的换算：1英寸 = 2.54 厘米 二、物理像素 2.1 像素 像素即一个小方块，它具有特定的位置和颜色。 图片、电子屏幕（手机、电脑）就是由无数个具有特定颜色和特定位置的小方块拼接而成。 像素可以作为图片或电子屏幕的最小组成单位。 2.2 物理像素 到电商网站购买手机，都会看一看手机的参数，以apple的官网上对手机分辨率的描述为例： iPhone XS Max 和 iPhone SE的分辨率分别为2688 x 1242和1136 x 640。表示手机分别在垂直和水平上所具有的像素点数。 这里描述的就是屏幕实际的物理像素，即一个屏幕具体由多少个像素点组成。 屏幕从工厂出来那天起