开发者论坛

 找回密码
 注册 (请使用非IE浏览器)
查看: 9963|回复: 0

普通pc端开发与移动端开发区别

[复制链接]

0

精华

0

贡献

0

赞扬

帖子
7
软币
94
在线时间
2 小时
注册时间
2019-10-11
发表于 2019-10-12 16:13:10 | 显示全部楼层 |阅读模式
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的作用是让普通移动网页被添加到主屏幕后,拥有一些类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审核发版很慢。 这些就是我知道的一些很通俗的区别了,技术细节就不说了,太多。大家有个概念就好啦。 3,对js和css的使用选择。
这部分我提前预警,这是我自己的看法,不一定是正确的,大家互相讨论。
我的想法是不使用目前那些主流的移动端框架,选择手写。我会说为什么。
比如jq mobile,zepto,backbone,angular,还有类似工具集,underscore,一些动画框架,还有小型的游戏框架,统统其实是不太需要的。
我并不是说他们不好,而是这些对于新手来说,只能是阵痛药,而不是万能药。为什么呢,移动端的优化很大的一个瓶颈就是网络加载速度不一致,有wifi,有3g,有4g,还有2g。代码量在移动端开发是很大的一个考察点。
我们反观这些框架:zepto最先说,你用它做什么?动画?选择器?事件委派?基于zepto的插件?可能大部分人就是用个选择器吧。但是移动端的原生选择器方法应有尽用,原生的完全够用,包括事件和委派,一共写起来不超过10几行的东西,引入一个框架不值得。再说mvc的框架,如果不使用离线存储,我是反正不敢想没wifi的情况下体验如何,外加移动端真的是否需要分层这种处理不说,主要还是看业务场景。
套壳的那种上面说了,框架随便用,因为足够复杂,但是普通移动端开发,我个人是不推荐使用的,可以直接上原生的来写,最多来一个模块化工具。我下面就说说自己是怎么做的吧。
手机端对ES5的特性已经全部都支持的很好了,参考:
xiaojue/ES-shim · GitHub
这里的api特性,只实现了一部分,但是其实平时对数据的处理,对象的处理,已经完全足够。我不说优缺点,我只说,移动端这些都是纯天然的而已。
然后是我们对手势的处理,zepto中有几个很有用的事件,swipe,swipeLeft,right,up,down,一类的,还有tap,我们可以看下zepto的源码:
zepto/touch.js at master · madrobby/zepto · GitHub
我们真的所有场景都需要所有的功能么,tap,doubletap,有多少人用了。。用到的时候,也是非常好实现的功能。我推荐直接手写,或者自己写一个swipe的基类,也不会比zepto的touch.js多太多,而好处是我们可以让它贯穿我们的项目,作为一个base类使用,当然我不是喷zepto多余,它很多代码做了兼容处理,但是就目前我们的业务来说,我们只需要考虑webkit,只需要考虑几个特定国产浏览器,因为这是统计数据说了算。
没了框架,我们就不能写代码了么?移动端开发,我觉得更考验的是前端的基本功,只要基本功扎实,其实都是很简单的需求,正因为都是自己一行一行写的,遇到诡异问题就更好解决,而不再需要纠结于,到底是我做错了,还是框架错了这个问题。
我不止一次的修改过iscroll的源码来适应和“满足”我们的测试。。。比如ios下用了iscroll,a标签无法点击跳转,很多人遇到过吧,不看文档你还真是一时不知道怎么解决,iscroll由于禁止了页面原生的滚动,很多本来很简单得东西复杂化了,而我们需要的是什么?一个下托刷新?一个惯性滚动特效?开什么玩笑,原生的也没几行啊。。。对于一个写了多年pc端的前端来说我相信徒手写个下托刷新禁止页面惯性反弹的代码,应该不复杂吧?这里给个思路,比如我们检测touchmove的位置快到达页面【或者容器】底部的时候,阻止touchmove,做容器或者页面translate移动,再在下部埋一个loading,touchend之后再做缓动回复,应该普通前端都能做到。

http://www.45zq.cn/portal/article/index/id/196.html

回复

使用道具 举报

Archiver|手机版|小黑屋|开发者网 ( 苏ICP备08004430号-2 )
版权所有:南京韵文教育信息咨询有限公司

GMT+8, 2022-7-4 13:28

Powered by Discuz! X3.4

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表