熟悉房地产开发流程Hybird App开发模式  配合后台设计接口 这2句话是什么意思具体说明一下

Object-C(2)
Hybird-后台接口和后台管理界面
由于线上乐刻客户端 App 第一次打开平台 H5 需要几秒的加载时间,这个体验对用户来说并不友好,为了让用户跳转 H5 和跳转到原生一样的用户体验,就需要把 H5 相关的离线资源包下发给客户端,客户端就可以使用离线资源来代替实际网络请求,节省用户等待时间和流量消耗。这里就需要后台来负责离线资源包的管理和下发。
offlineResourceInfo 接口参数:
//"appVersion": "2.4.0", 可以去掉,因为请求头会包含
"resourceversionList": [{
"name": "m",
"version": "1.0.0"
"name": "coach",
"version": "1.0.0"
"name": "activity",
"version": "1.0.0"
offlineResourceInfo 接口返回结构体:
"resourceList": [{
"name": "m",
"version": "1.0.1",
"url": "/resource/m/m_update_1.0.0_1.0.1.zip",
"md5": "a4d7feecbcae8e2ccba3b5ba90aa8a83",
"isfull": false
"name": "coach",
"version": "1.0.1",
"/resource/coach/coach_full_1.0.1.zip",
"md5": "a4d7feecbcae8e2ccba3b5ba90aa8a83",
"isfull": true
参数说明:
"name": 模块名
"version": 升级版本
"url": 资源包下载地址
"md5": 资源包 md5
"isfull": 是否是全量升级包
添加升级资源包
资源包需上传到七牛空间 offlineh5, 路径为 /upgrade/[模块名]/activity.full_1.0.0.zip
添加降级资源包
资源包需上传到七牛空间 offlineh5, 路径为 /degrade/[模块名]/activity.full_1.0.0.zip
App 第一次请求时, resourceVersionList 为空,服务器需要返回所有模块最新的全量资源。
App 升级逻辑
App 后续请求都会带上本地最新的resourceVersionList,服务器遍历resourceVersionList,并和服务器上配置的所有升级模块最新版本进行比较,
如果升级模块版本与 App 本地版本相隔一个版本,就下发增量包。
如果升级模块版本比 App 本地版本相隔多个版本(跨版本),就下发全量包。
如果某个模块不要升级资源包,后台接口就不需要返回该模块的信息。
App 降级逻辑
App 后续请求都会带上本地最新的resourceVersionList,服务器遍历version list,并和服务器上配置的所有降级模块源版本进行比较,
如果降级模块源版本与 App 本地版本相同,就下发降级包。
当降级逻辑和升级逻辑同时满足条件时,只启用降级逻辑。
&&相关文章推荐
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:5523次
排名:千里之外
转载:21篇
(3)(2)(5)(5)(3)(1)(7)(3)问题对人有帮助,内容完整,我也想知道答案
问题没有实际价值,缺少关键内容,没有改进余地
如题:我先来简单说下自己的理解吧,如有错误希望童鞋们可以指出!
hybrid模式开发APP,其实就是我们平时在移动端(浏览器端)构造的单页面应用,只是将这SPA嵌套到了安卓或者IOS的webview中去(当然中间会有ionic等类似中间件的打包)。
由于webapp虽然在跨平台上表现的很不错,但是在一些稍微低端的安卓机下用户体验不是很好,卡顿现比较的严重。
其实hybrid模式开发APP也可以不使用单页面应用,但是在页面跳转的时候网速较差会出现白屏,等比较影响用户体验的事情发生,所以大家大多会采用SPA应用的模式,而angular,vue等比较成熟MVVM框架就成为了首选。
好,基于上面的理解,现在如果给我一个hybrid模式的APP我就会采用SPA的单页面应用模式去处理。例如现在我们有一个新闻列表,默认一开始会渲染十条新闻,在下拉的时候会去ajax请求后台,渲染列表。
以上是我对于混合模式开发APP的一些理解,那么问题来了。通常情况下,我们都会请求后端给的接口去得到相应的数据。但是在hybrid模式下的APP呢,今天听一个人给我说是我(前端)不发起请求,而是去调用ios/安卓的(类似于接口的东西),然后由navtive原生向后端发起请求,得到相应的东西。
如果按照这么来,确定不是在逗我?这样我的单页面应用怎么做,本人没有做过hybrid模式的APP,最近想研究一下,但是在这个问题上就卡住了。
希望有大神可以回答一下我的问题,例如,现在在一个混合模式的APP下,有一个商品列表,默认加载20个,在下拉的时候会去请求得到数据,然后渲染。那么这个请求是怎么发出的?我们在模块里ajax?还是我们在模块内ajax,然后ionic这类中间件会帮我们处理好了?还是说怎么做?
答案对人有帮助,有参考价值
答案没帮助,是错误的答案,答非所问
没必要用原生来发起请求,个人认为一般用原生发起请求是在原生的插件中使用,而普通的 hybrid 模式中,比如你说的 ionic,你封装一下 angular 的 $http 服务就够用了。
另外其实个人认为,react native、weex 的模式在当下要优于传统的 hybird 模式,题主可以尝试一下。我就是从 hybird 迁移到 react native 的,性能、稳定性和体验上都提升蛮大的。
答案对人有帮助,有参考价值
答案没帮助,是错误的答案,答非所问
根据你的描述,你在webview中所使用的SPA应用是基于服务器的,不会存在请求的问题。如果是基于本地的,才会存在请求的问题(ajax跨域),可以用jsonp请求、原生请求、服务器允许跨域等方法来解决。基于服务器的SPA在性能上弱于本地。
我来说说我们的解决方法,SPA基于本地(APP打包时内置初版的SPA),请求走的原生,数据从服务器获取(和原生APP是一个模式,只是页面和逻辑代码是用html和js实现罢了)。由于页面是本地的,所以加载速度比从服务器加载快了不是一点半点。当业务有更新的时候,只需从服务器下载压缩包,解压更新本地文件就可以了。这样在不进行APP大版本更新的情况下可以做到业务动态更新。
同步到新浪微博
分享到微博?
Hi,欢迎来到 SegmentFault 技术社区!⊙▽⊙ 在这里,你可以提出编程相关的疑惑,关注感兴趣的问题,对认可的回答投赞同票;大家会帮你解决编程的问题,和你探讨技术更新,为你的回答投上赞同票。
明天提醒我
关闭理由:
删除理由:
忽略理由:
推广(招聘、广告、SEO 等)方面的内容
与已有问题重复(请编辑该提问指向已有相同问题)
答非所问,不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因(请补充说明)
我要该,理由是:Hybrid App 开发模式 - 推酷
Hybrid App 开发模式
开发移动App主要有三种模式:Native、 Hybrid和Web App。各种开发模式的优缺点这里就不讨论了,有很多科技博客都做过专题报道。需要注意的一点是在选择开发模式的时候,要根据你的项目类型(图片类?视频类?新闻类?等),产品业务和人员技术储备等做权衡。
本文主要介绍Hybrid App的开发模式,Hybrid开发模式就是既有Native开发也有Web app的开发。那我们怎么去确定App中某个功能模块使用Native还是Web开发?它们之间如果需要接口通信又该如何去实现呢?又该如何更好的去维护Hybrid App产品呢?
1、Native or Web开发模块
当我们选择用Hybrid模式开发App时,应先熟悉项目整个框架和App各个模块。然后将通用的,对性能要求不是那么高的App界面可抽出来作为web界面开发,Native直接调用。一般Hybrid App开发,App界面之间的跳转关系由Native实现并完成,web界面主要作为内容填充到Android和iOS的浏览器控件中。拉手网之前Android客户端就是采用这种模式,Native搭一个App框架壳,里面展示内容和网络请求全部由web实现。由于客户端浏览器控件版本不同,web界面加载,渲染和缓存机制等原因,这种模式开发的App整体在图文比较多的情况下体验就不太好,甚至可能会出现意想不到的奇葩问题。
建议图文列表,涉及到视频等多并发和界面元素比较负责或具有很强的动画特效的情况优先考虑Native开发。
这方面在Android尤其有必要,Android 4.4之前的浏览器控件WebView基于缺省的WebKit内核,它不同于Chromium所使用的Webkit内核;而在4.4之后(包括4.4)的WebView的实现被替换成Chromium WebKit内核。当我们想让App尽可能的在低版本也能运行良好时,就需要不断做兼容性开发和测试了,除非自己在App里面打包编译最新WebView源码,类似开发一个浏览器。
2、Native & web 通信
Native调用js方法
Android和iOS都提供了API直接调用:
webview.loadUrl(&javascript:functionName(\&& + argument + &\&)&);
别忘了设置
webview.getSettings().setJavaScriptEnabled(true);&&
[webView stringByEvaluatingJavaScriptFromString:@&alert('hello world!')&];
js调用Native方法。
Android实现js调用native方法一般是先编写供js调用的类,然后通过添加javascripteInterface的方法,如
webView.addJavascriptInterface(pandoInterface, &pando&);
将java对象pandoInterface生成js对象pando,然后直接window.pando就可以调用pandoInterface对象里面的方法。需要注意的是供js调用的pandoInterface对象里面的java方法需手动加上@JavascriptInterface注解,这个是Google为解决安全问题引入的。
iOS实现js调用Native方法相对繁琐一点。主要是iOS原生并没有提供js直接调用native的方式,只能通过UIWebView相关的UIWebViewDelegate协议的方法来做拦截,并在这个方法中,根据url的协议或特征字符串来做调用方法或触发事件等工作。当js需要调用Native方法时,js创建一个隐藏的iframe设置或改变其src就会触发Native拦截url事件。
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
NSURL *url = [request URL];
if ([[url scheme] isEqualToString:@&someFunction&) {
//调用原生方法
return NO;
return YES;
不知道大家发现没有,以上两种方法都只是实现了js调用Native方法,但是都没有实现js函数回调,将Native方法返回结果传递给js。
微信开放了很多jsApi接口,供大家直接调用微信Native的功能。通过jsApi接口和文档我们会发现里面实现了Native方法执行结果回调给js。这种Hybrid App开发模式很好的利用了Native高性能,多并发的优势,将网络请求,扫码等复杂的逻辑或者web不可能实现的功能由Native完成,而web只是做了界面显示效果。将微信Android安装包解压之后,在assets/jsapi目录下有个80多kb的wxjs.js文件,里面实现了微信jsApi逻辑jsbridge。下面主要简单介绍一下这种jsbridge实现原理。
jsbridge核心难点在于如何在Native方法执行完之后将返回接口给js,并且让js能理解传过来的参数所表达的意思。针对这,我们可以在js调用Native方法之间,将js一次调用Native的唯一标示符identifier和期望Native调用完后执行的回调函数存储在Map里面,将identifier和其他参数传递给Native,native执行完成后,将identifier和执行结果作为参数调用js函数,在js函数里面解析参数,得到identifier,然后在Map里查询对应的回调函数,将native执行结果作为参数传递进去调用。有点绕,但是巧妙的利用消息传递机制,实现js调用Native进行回调函数调用,同理,Native调用js函数将返回结果给Native调用也是可以的。
Android在实现jsbridge时,早期方法也是需要iOS那样,先给web界面创建iframe,然后通过js改变iframe src,Native方法通过shouldOverrideUrlLoading(WebView view, String url)拦截url处理。但是在Android 4.2.2系统上,这个方法在iframe src改变是,是不会触发的。目前建议大家通过拦截js alert弹框做处理。
public boolean onJsAlert(WebView view, String url, String message,
JsResult result) {
LogUtils.i(&url:& + url+&\n message:& + message);
String msg = URLDecoder.decode(message, &utf-8&);
if (msg.startsWith(BridgeUtil.PANDO_RETURN_DATA)) { // 如果是返回数据
handlerReturnData(message);
result.cancel();
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
return super.onJsAlert(view, url, message, result);
注意,onJsAlert方法拦截做处理后一定要result.cancel();不然web界面就会出现点击没反应的情况。
3、Hybrid App维护
Hybrid App涉及到html、css和js等web资源文件,当web和Native之间有相互调用时,两者之间任何一方接口变动都会导致App出现bug。
考虑类似微信方案,将jsbridge文件或者部分常用web资源随App打包发布,降低维护成本,也不用担心在网络不好的情况下加载不了web界面,在接口升级之前发布出去的App肯定也是稳定可用的,当然这个也要考虑安全性问题,毕竟你的web界面源码通过反编译代码可以得到。
所有web资源统一从服务器获取。由于web资源在服务器,所以可以随时动态更改web界面,发现bug也不用发布App,直接在线接口升级。但是要维护web资源,使得每个发布出去的每个版本的App在加载web资源时都可用。
Hybrid App开发一路走来踩过不少坑,欢迎大家多批评指点,多交流。@~~@
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置: 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致4595人阅读
Android(1)
&&&&之前一直在做JAVA的项目,最近要开发移动端,对App的开发刚开始的时候是没有任何概念的,有接触也就是玩手机用过的N多App,这算是真正意义山的第一次和App握手相识!
App,你知道多少?
&&&&目前主流的应用程序有三大类:
一、 什么是Native App?
&&&&Native App即原生应用,即我们一般所称的客户端,是针对不同手机系统单独开发的本地应用,如需使用需要先下载到手机并安装,下载Native App的最常见方法是访问应用程序商店,如苹果的App Store、安卓市场、Google Play等。在技术实现上一般采用针对操作系统的特定语言进行编写,如:使用Objective-c开发IOS应用,使用Java+Android开发android应用。
运行效率高
可调用各种设备资源
人力成本高
发布速度慢(AppStore确认的时间很长)
更新版本的问题(用户就是不更新!)
实现图文混排等功能拥有各种坑!
二、 什么是Web App?
&&&&Web App又叫Web应用,简单的说就是一个触屏版的网站。Web应用完全用HTML、JavaScript和CSS等Web技术开发,通过移动设备的浏览器来访问,缺点是这些基于浏览器的应用无法调用系统API来实现一些高级功能,也不适合高性能要求的场合。WebApp的核心思路:
常见Web App框架对比:
开发成本低,使用现有的Web开发技术即可
适用范围广,覆盖所有智能手机,跨平台和终端
方便、快捷地部署,无需用户安装
用户总能访问到最新版本,迭代更新容易
可被搜索引擎收录并带来流量
浏览体验短期内还无法超越原生应用
不支持离线模式(HTML5将会解决这个问题)
消息推送不够及时
调用本地文件系统的能力弱
较差的和较慢的性能体验(大部分需要链接互联网)
支持图形和动画效果较差
不适用于应用商店及没有靠下载应用盈利机会
限制用户使用功能(比如,相机、GPS等)
Web APP 的开发基于Html5语言。而Html5语言本身又有着不可避免的局限性。正是这些局限性的存在,使得Web App在体验中要逊于Native App。具体的首先因素及设计要点大家可以去参考《》
三、 什么是Hybrid App?
&&&&Hybrid App又叫混合应用,是一种介于Native App、Web App之间的App,它虽然看上去是一个Native App,但只是一个UI WebView,里面访问的是一个Web App。Hybrid App实质是伪造一个浏览器的apk/ipa原生程序,并运行了一个Web APP。Hybrid App兼具“Native App良好用户交互体验的优势”和“Web App跨平台开发的优势”。它可以使web开发人员可以几乎零成本的转型成移动应用开发者,并且相同的代码只需针对不同平台进行编译就能实现在多平台的分发,而相较于Web App,开发者可以通过包装好的接口,调用大部分常用的系统API。
综合了开发效率和运行效率
发版本更方便
运行效率中等(切换等交互效果)
需要写一点原生代码(至少2个平台)
四、 Web App、Hybrid App、Native App比较
条件\应用程序
Hybrid App
Native App
Store或market认可
网页语言HTML5+JS
网页或原生语言
原生语言ObjectC、java、net等
&&&&从上面的表格中可以看出,没有哪一种开发方法总是提供所有的优点。每一种开发方法有天生的局限性,没有哪一种方法能够满足现代移动企业的所有要求、应对复杂情况。选择一种合适的方法取决于企业的具体要求,可能取决于诸多因素,比如预算、时间表、内部资源、目标市场、所需的应用程序功能、IT基础设施及其他许多方面。但是有一点很清楚:如今的大多数公司显然在两个方面之间作取舍:一是用户体验和应用程序功能,另一是开发成本和产品上市时间。问题就变成了选择一种合适的开发方法,能兼顾企业的要求和其在预算和产品上市时间方面的限制。
参考文章:
码字很辛苦,转载请注明出处:—-《》
&&相关文章推荐
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:340426次
积分:7798
积分:7798
排名:第2716名
原创:164篇
评论:2206条
阅读:8437
文章:14篇
阅读:15784
文章:10篇
阅读:7898
阅读:23908
阅读:10234
文章:21篇
阅读:31060
阅读:10464
阅读:19200
(1)(1)(5)(2)(3)(2)(2)(4)(16)(4)(3)(4)(4)(4)(4)(4)(4)(4)(4)(5)(4)(5)(3)(2)(4)(3)(4)(4)(3)(3)(3)(3)(4)(3)(4)(4)(4)(3)(4)(2)(4)(3)(1)(4)(1)(2)(2)简单的聊一聊我开发了4年之久的Hybrid App(混合模式移动应用)平台开发,目前一直在持续开发与维护,支持无编程快速开发!
其本意也不是要吹捧前端有多么强大,只是用自己的实际项目阐述下对于前端开发一个更深层次的见解
PS:这不是单一的APP应用,这是一个可以快速批量制作app的一套跨平台解决方案
因为我经常在家同步更新,所以在上放了一份,并非开源,仅参考学习,请勿乱传播,谢谢配合(当然,没有API,没有文档,估计ES6看起来也够呛)呵呵
开始我们先了解下目前前端的三个大的方向定位:
传统的web方向
webApp方向
nodejs方向(这里不讨论)
传统的web开发就不提了,前端开发者都是从这个过程走过来的。随着移动端的迅猛发展,近几年前端这个职业也被抄的火热,移动web的兼容早期估计也是蛋碎了一批人了,我也是深受其害,还好电子产品更新换代的速度挺快的。所以不管是PC还是移动端,web页面至始至终都是通过浏览器打开的,那么这样的开发来说我们还是的可以笼统的定义为传统的web开发者
自从Iphone和Android这两个牛逼的手机操作系统发布以来,在互联网界从此就多了一个新的名词-Web App(意为基于WEB形式的应用程序)。我们在iOS上开发APP,需要通过Objective-C那样精细复杂的语言去开发,这对广大的开发者而言是个不小的难题。值得庆幸的是,开发者们也可以通过开发Web APP来达到曲线救国的目的。也就是说,可以通过HTML、 CSS或者JavaScript来进行Web APP的开发。其实Web APP说白了就是一个针对Iphone、Android优化后的web站点,它使用的技术无非就是HTML或HTML5、CSS3、JavaScript,服务端技术JAVA、PHP、ASP,但是web APP的开发还是有一个的根本问题,因为底层毕竟还是html css js这些技术那么是无法操控跟系统相关的功能的,比如我想调节设备声音,我想调用本地的文件等等,那么这时候出了一个新的解决方案& - Hybrid App(混合模式移动应用)
Hybird的典型代表就是PhoneGap开发框架,后来被土豪Adobe收购了,简单的说PhoneGap在支持web app开发的同时还能通过它的手段:类似原生语言一样调用其自己的系统接口,其实现也是很恶心的通过截取消息,大家可以百度查找相关资料
关于Web App与Native App的好坏这里不做讨论,存在即使道理,Hybrid的存在总有它的价值
web App优势
那么相比Native开发web App开发最大的优势:快速!
布局可能是最头疼的问题之一,移动设备的尺寸那真叫一个&丰富&,要兼容各种尺寸会搞的你焦头烂额的。在PC端我们常用的手段就是固定布局、弹性布局。但是在移动端我们可以使用更新的技术,响应式布局媒体查询等等,但是根据我个人的经验:外部采用自适应布局模式,在不同设备上可以自行缩放,中等布局可以采用em rem, 具体的图片可以采用px,但是在我项目中最终采用是计算缩放比,让所有的元素按照绝对尺寸进行缩放布局
说着说着就会离开话题很远了,那么web App的的缺点其实是比较明显的,性能相对原生的的体验会差,至于差多少要看应用的具体设计了。比如我就做一个翻页的效果,这样来说Native 与Hybrid是看不出区别的,但是如果是做一个植物打僵尸,这样对比就比较明显了,所以基于目前Hybird的发开还是有很大的局限性的,我记得早2年淘宝的客户端就是基于web app开发的,有一段时间在安卓上的体验非常差
web App的开发快速便捷,但是性能比Native还是差强人意,在系统接口的调用上也很薄弱,不管是web App还是Native都不是什么新技术了,项目在选择开发的时候都会有各种考虑,到底是短平快的快餐式发开,还是高大上的原生编写,那么怎么才能平衡这些优劣,就要看各自项目的取舍了
那么问题来了,web App如何才能最恰到好处的利用起来?
无编程开发
如果我们想通过一个产品引导一个产业我想目前是很难了,马云的时代不是每个人都能抓住的。如果一个不行,那么十个百个千个呢?我们做成一个系列产品形成的产业链?是否可以打通一个行业的缺口呢?这个未知,人生就是有了未知才会有精彩,正是因为这个未知才让我们有了这个动力去追逐这个梦想。
一个应用开发的成本是非常大了,耗时耗力,稍微复杂点的应用都要牵涉到几个部门的协调,按照目前的的开发周期,我想一个成型的应用从设计开发到检测到上架,少说也要1个月吧,而且还是一个团队合作之后的开发周期,基于这种开发成本考虑就算是通过web App开发的方式也不能达到产业链的效果。那么我们就会萌生一种新的想法,可不可以不写代码就能做应用了?基于这样的设想我们的项目的原型就出来了,基于PhoneGap的无编程快速应用开发
这是目前公司几个系列项目,都是基于无编程的实现,之前还有几个项目不过已经流产了,就不提了
这里3个方向的项目都是属于加壳,其实底层的东西都是同一个实现,只是在不同的项目中被各种不同的合理利用,之前我在慕课网上的介绍写到,我有几百个苹果的应用展现,还真不是呵呵,确实是有(这个链接里面进去看看)。那么这些应用其实都是HTML5+CSS3+JS实现的,就是现在比较火热的Hybrid混合应用
什么是无编程?
这是项目的的一个核心,不需要直接编程就能实现做出各种精美,复杂的应用,而且是几乎跨是有平台的
目前来说可以直接通过网页在线看,也可以生成APK、IPA应用文件在移动端安装,也可以在桌面通过exe加壳运行
实现的代码只有一份,可以跑基于WebView的任意平台。
如何实现无编程?
简单的来说用户可以通过一套软件,可以把具体的抽象设计给控件化,有点类似.net的控件一样,自动生成代码。
如何实现跨平台?
跨平台很简单就是通过web App技术就可以
如何实现?
其实最重要的2个方向我们已经确定了,那么我们怎么才能实现无编程快速应用开发?
我们只需要把用户想要操作的的行为告诉前端代码就就可以了
这里其实就是一个编程的传递了,传统的开发都是我们开发者引导用户行为,那么现在的的方式就是让制作者引导,而不是开发者处理了,我们开发者要做的一个事件就是,如何让编辑者的逻辑设计能够最终实现
用户的抽象行为是可以用数据描述的,我们可以把用户的行为写到数据库里面,然后前端代码通过读取数据库来获取这个行为,正好HTML5的Web Sql Database就能完全胜任这个工作的,那么我们现在整的设计原型就出来了:通过PPT抽象用户的设计写入到数据库,前端通过读取数据库还原用户的设计
我们可以看看设计者的一个编辑界面,基本office ppt 的扩展
ppt模版中多出了2个新的模块
通过ppt把记录用户行为并生成数据库
前端通过读取数据,通过H5+CSS3+JS这些技术来还原用户的行为
根据数据处理,比如音频(自动适配最合适的方法)
在线预览的效果
项目复杂吗
因为我只是前端的实现,不涉及其他语言,只针对我个人的理解。
整个前端目前总代码应该是超过了10万行,业务架构方面的代码应该有3-5万行左右
SVN的更新记录就架构这一部分是超过了1万的更新量
实现的功能
支持几乎所有支持CSS3的平台
支持各种分辨率、横竖模式自适应缩放
支持在线预览
支持翻页线性切换
支持非线性的直接切换
支持页面跳转
支持DOM与Canvas模式的独立与共存
支持14中事件编程与手势交互
支持上百种动画组合
支持视频与音频
支持路劲动画
支持css3 canvas的精灵动画
支持多层的视觉差效果
支持svg无损缩放
支持底层接口调用
支持脚本代码注入
支持用户自定义编程
还有什么不记得了懒得写了。。。
大家关心的问题来了:这样的前端项目,设计与实现上会涉及多少问题了?
我简单说一句:真的复杂,因为把逻辑交给了用户了,用户给可以一个对象上增加多个任意的事件、动作、动画、音频等等组合,每个组合之间还可以相互配合实现更多的动作动画
移动端的问题太多了,这么多年核心的架构重构了不下8次,我也累积了一堆的优化经验
我们可是单页面模拟多页面切换的,所以WebView只有一个,那么传统的都是通过网页跳转切换,我们只能通过左右滑动切换页面,那么意味着我们要模拟出多个页面来,其实目前也有swipe这样的插件,但是针对我们这样的模式swipe只能说是弱爆了。
如果有一个应用有500页,如果依次生成所有的页面,会很卡,可能还会闪退
移动端通过Web Sql Database获取数据,如果是通过sql查询1条数据查询要100毫秒的样子,那么我们一个页面有的数据量有时候大到了几百上千,这样的应用可想而已
把每一个模拟的页面看作一个容器,那么容器里面其实是有很多很多不同的对象的,可以有视频,可以有音频,可以有精灵,可有有各种交互,那么这些对象要如何触发,如何控制,如何销毁?
在我们每一次翻页的时候,其实都要涉及很多的问题,一个新的页面载入,一个当前页面的暂停,一个久页面的销毁,因为我是模拟,这需要控制不同页面的生命周期,每一个活动对象的状态控制
单页面应用,内存管理是一个最大的问题,因为不退出就不会销毁,所以越复杂的应用越要有一个好的架构
其实问题还有很多,这里就不一一列出了,我们通过phonegap打包的应用就有几百个,我们还有自己的应用平台、, 是基于这种模式开发的一种新的教学体验
针对这种大型的应用最重要的一个点,就是性能,我们优化的原则就是二八定律,从最消耗的地方着手
节点是生成与绘制
大数据的读取
那么我总结的优化与结构组织的方式有:
通过一次平铺所有的内容页是行不通的了,因为我们一个应用,而不是一个页面,我要已应用来认知,一个应用内部都是对象。
所以我们采用了动态算法,每次根据进来的位置动态生成2-3页,在滑动的时候全动态处理,那么我项目最大的一个优化点就是,采用动态算法模拟多线程模拟创建 + 细分任务颗粒度达到了最佳的优化目的,这个多线程不是传统上的定时器那么简单的
大数据的处理,其实最开始采用了空间换时间的方法,通过一次把数据库的数据取出来放到内存中的缓存表中,这样小数据量还行,大数据量的话应用几乎直接闪退,缓存是需要内存的,而且就算是哈希表,如果上千条在移动端也会被拉下来,具体参考我之前写过一篇文章
整个设计其实都是采用了分层结构,不同层处理管理自己的行为,这样涉及复杂交互的时候,只需要调用各自封装好的接口就可以了
每一个对象都是有生命的,所以就存在一个对象的管理,我们以页面为单位,里面有几十上百的对象,那么都需要控制管理,包括对象与对象之间的通讯与调用,这里我们会引入很多设计模式来处理
事件有二套,一套是基于用户编辑的自定义绑定,另一套是框架底层提供,设想下,如果一个对象不绑定事件,在它上面有手势移动就意味着不能翻页了,所以不同的事件会有不同的优先级的处理方案,这里也是参考了jQuery的事件机制
在切换页面的时候,就是一个非常复杂的逻辑了,因为是动态的就会涉及创建与销毁。所以就需要有一个控制器来管理整个事件的流程,一个页面创建,一个暂停,一个运行,一个销毁,每一个页面容器内部的对象都会有不同的动作处理
除此之外,我们还有一大堆插件,动画都可以选择最佳的实现,包括iframe、widget、svg、canvas、webgL这些都会有对应的适配器去自动选择
当然还有很多很多设计上的优化这里就不一一列举了,项目最复杂的地方,我觉得就是把逻辑完全交给了编辑者了,那么我就需要在各种不同的情况下根据数据分析出设计的的意图,并实现
可能有大部分人会看天书一样,不知所然,毕竟这个确实都是跟实际的项目经验有关系的,如果遇到了,可以参考
这个项目我架构这边的需求就不下200个,其实前端的架构水还是很深的
Integration of the latest technology point node/es6/gulp/webpack/rollup/eslint/karma and so on
development: Based on ES6
test: Based on the webpack+express+rollup+gulp build, there is a hot replacement function
release: Based on gulp+rollup single file package
test: Based on karma+mocha+chai
阅读(...) 评论()

我要回帖

更多关于 熟悉linux开发环境 的文章

 

随机推荐