前端开发，首屏CSS手机内嵌字幕有什么好处

来源：蜘蛛抓取(WebSpider) 时间：2016-12-13 08:05 标签： 手机内嵌字幕
1，普通pc端开发与移动端开发区别。
普通pc端开发，我理解就是你拿电脑打开的网页都算【这不是废话么】。那么移动端前端开发工程师，说白了就很好理解了，做手机网页的前端开发工程师。这么一比，是不是感觉，移动端开发简单多了？
pc，我们需要考虑什么呢？有点开发经验的同学都知道，ie6-11，firefox，chrome，safari都得兼容的吧。哪个都够你吃一壶的，无论是css还是js。mobile的网页开发，我们需要考虑什么呢？就目前来说，我们只需要考虑webkit内核的浏览器和chrome，uc，qq，小米手机浏览器就好了。。。【后面特意会说这几只国产浏览器哪里屌了】相比较而言，除了经验是0以外，需要兼容的东西还是少了，少了，少了呢。ok，单纯说pc和移动端开发的区别，其实也就是这个，可以简单的概括来说，mobile端的网页开发比pc端的网页开发，更简单一些。【页面小了啊，装的东西少了，css和html写的少了吧】交互简单一些【滑动，触屏，手势，平时看看手机你还能有啥特殊操作？】
so，别被这玩意吓坏了，根据我的经验来看，pc端的前端开发程序员，转mobile开发，一点问题没有，而且上手会很快。够直白的解释了。2，移动端web app开发与套壳开发区别。移动端web app，移动端网页，Hybrid开发【我喜欢叫套壳开发工程师……】，无所谓叫什么，移动端开发无疑就是这3种了。下面一一解释下我的理解。移动端web app是什么呢？简单理解就是页面头部加入了下面这一句话的东西：
&meta&name=&apple-mobile-web-app-capable&&content=&yes&&
这个meta的作用是让普通移动网页被添加到主屏幕后，拥有一些类native的功能，很多同学应该都很熟悉了。就是类似隐藏ios的上下状态栏，实现全屏，禁止弹性拖拽，全屏，修改顶部颜色等。我理解这种模式的网页为web app，当然还有一种类型就是大家平时都访问的那些网站，比如手机taobao，手机美团，手机微博的网页版，大家打开的时候，不是全屏的，但是用起来，开发者把它们伪装的很像这种web app的交互体验而已。
以上2种我觉得可以总结为web app。（如需对比，请参考各大网页！！）之后我来说下套壳的吧。这部分如果没有开发过phonegap或者类似和native连调过webview的同学，可能觉得很陌生，其实不是，这种套壳开发和开发普通的网页没什么区别，只不过资源大部分是file开头的，本地资源，网络资源分为使用js异步接口获取和native获取，再和js的接口交互，类似ios中，可以直接在oc或者swift可以直接在webview中执行js，android同理，但是js想调用native功能怎么办呢？我们这边的做法是有一个负责通讯的iframe，我们通过修改这个iframe的url，来让native来监控一系列特殊的url地址请求，再在native中调用对应的功能，比如摄像头，特殊交互，呼起，或者提供接口数据。数据的提供方式类似jsonp的原理，在执行函数的参数中传回来。理解了这块，其实做套壳的比做普通web app和网页都简单，因为在native的webview中是可以指定是什么版本的webview，用什么内核，拥有什么等级的安全权限等等，ios和android做法不一样，但是原理一致，对于前端开发工程师来说是无差的。而且套壳开发还有个好处就是，因为资源是本地化的，所以可以使用比较重的框架，如angular，react，一些三方框架，因为最终都是通过和native代码捆绑发布的。套壳native的静态前端部分的更新，我们可以使用远程下载静态资源包的方法实现，不发布大版本而修改webview中逻辑的需求，这一点也是大部分公司选择一半native一半h5来开发的原因。都知道ios审核发版很慢。这些就是我知道的一些很通俗的区别了，技术细节就不说了，太多。大家有个概念就好啦。
有了数据，我说一下移动端的统计极值问题，举个例子，我们手机打开一个网页，还没有load完成，切到了后台，这个时候脚本是不会执行的了，过了几小时，几天再回来的数据，我们都能收集到，这部分属于垃圾数据，是需要算平均值的时候去除的。这点和pc不太一样。然后是性能优化建立在均值性能指标上的，我们尽快的提升首屏和win load的时间即可，原则和做法和pc一致，当然，移动端不是资源越合成一个越好，我们的实践是分散成不同的几个资源下载，总时间比较快，比如活动页面，h5小游戏页都是这样。可以统一把资源图拆开加载，然后增加loading即可。----我还在奋力思考和编写中-----今天先到这里了。。。。【这里还有一个点，我想讨论一下是mobile的cache的利用率问题，这个明天我详细说，决定找些权威的数据或者自己做下测试再开始写】6，移动端网页布局方法与pc的差异。主要是css方面，外加如何做到同一url，不同客户端展现不一致的做法，俗称pc和mobile都兼容。还有会说一下rem的相关用法和一段比较经典的rem.js今天有空来更新一下这个rem在移动端布局的一个用法：）（更新）首先，em和rem的概念我简要说一下，em是父元素fontsize的倍数表示，rem则是root即为html的fontsize的倍数表示。比如我html.style.fontSize = 12那么1rem则为12px，0.5rem为6px；好了，概念有了，那么做布局的时候我们怎么用呢，大家应该用过的都知道，移动端的字体默认为16px，那么1rem我想表示为10px的话，我们就需要 10 % 16 = 0.625 即为62.5%，这样就可以比较方便的把设计稿里的px转换成rem单位来做到自适应了。这样无论用户如何设置电脑或者手机的默认字体大小，设置为rem的单位的长度都会随比例变化。这是一种常规做法，其实换个角度我们还可以这样用：我们想象一个设计稿宽度为640，800，1200px等尺寸时，我们如何来快速完成响应式的布局呢？百分比？flex？这些还是有些复杂的。后来发现，栅格等比缩放整个设计稿看起来是个更简单粗暴的方法。而且正好可以利用rem这个比例变化单位。看下这段js：比较好理解，我们首先根据psd的设计稿宽度设置一个基值，然后我们js获取到当前窗口的宽度值，然后把这个设计稿宽度除以100栅格化一下，获得一份的宽度数，之后再用真实窗口的宽度除以这个一份的宽度，拿到就是我们需要给html设置的fontsize的px值。这样我们只需要把对应psd里的px单位除以100，就得到了任何宽度环境下的rem值。当然实际发现有些浏览器这个rem单位是存在bug的，比如比例值不准，那么我们就需要获得这个不准的比例再转换成准的再赋值html的fontsize，可见calcTestDom函数，之后再处理一下旋转屏幕时候的情况，resize时候的情况就好了。这样我们在做一些活动专题页面时，只需要引入这段js，在页头设置一个设计稿宽，然后对着设计稿一顿疯狂的px除100来定位就好了。。比设置成62.5%的方式要更好（1，修复了浏览器bug，2，转换单位更方便直观，px/100即可）7，常见js组件与pc端组件差异。这部分还在想怎么说比较通俗易懂，哪些组件是非常典型得，需要我回去慢慢想想，找几个实际的对比例子。8，一些常见的坑。分享一下内部wiki的经典移动端坑和解决办法。（不会太多，别抱太大期待了。。）9，适配【机型，浏览器】的方法和选择。1，统计说话。2，调试方法。10，测试技巧与pc的差别。几个比较经典的调试方法和工具介绍。&&国之画&&&& &&
版权所有 京ICP备号-2
迷上了代码！

我要回帖

更多关于 手机内嵌字幕 的文章

 

随机推荐