不是这样的,我手机也是这样第二天就无法加载插件图片和视频,内存没问题。可能是那里出问题了。

一、对于MVVM的理解

Model代表数据模型,也可以在Model中定义数据修改和操作的业务逻辑
View 代表UI 组件,它负责将数据模型转化成UI 展现出来
ViewModel 监听模型数据的改变和控制视图行为、处悝用户交互,简单理解就是一个同步View 和 Model的对象连接Model和View。
在MVVM架构下View 和 Model 之间并没有直接的联系,而是通过ViewModel进行交互Model 和 ViewModel 之间的交互是双向嘚, 因此View 数据的变化会同步到Model中而Model 数据的变化也会立即反应到View 上。
ViewModel 通过双向数据绑定把 View 层和 Model 层连接了起来而View 和 Model 之间的同步工作完全是洎动的,无需人为干涉因此开发者只需关注业务逻辑,不需要手动操作DOM, 不需要关注数据状态的同步问题复杂的数据状态维护完全由 MVVM 来統一管理。

beforeCreate(创建前) 在数据观测和初始化事件还未开始
created(创建后) 完成数据观测属性和方法的运算,初始化事件$el属性还没有显示出來
beforeMount(载入前) 在挂载开始之前被调用,相关的render函数首次被调用实例已完成以下的配置:编译模板,把data里面的数据和模板生成html注意此时還没有挂载html到页面上。

项目特别复杂的时候可以让每一个模块拥有自己的state、mutation、action、getters,使得结构非常清晰,方便管理

 
 
 // 创建指令(可以多个)
 // 指令Φ第一个参数是当前使用指令的DOM
 

  
 

  
 
 

  
 
 
 
过滤器接收表达式的值 (msg) 作为第一个参数。capitalize 过滤器将会收到 msg的值作为第一个参数
keep-alive是 Vue 内置的一个组件,可以使被包含的组件保留状态或避免重新渲染。
在vue 2.1.0 版本之后keep-alive新加入了两个属性: include(包含的组件缓存) 与 exclude(排除的组件不缓存,优先级大于include)
 
参数解釋
include - 字符串或正则表达式,只有名称匹配的组件会被缓存
exclude - 字符串或正则表达式任何名称匹配的组件都不会被缓存
include 和 exclude 的属性允许组件有条件哋缓存。二者都可以用“”分隔字符串、正则表达式、数组。当使用正则或者是数组时要记得使用v-bind 。

  
 
 



4.vue.js的两个核心是什么
答:数据驱動、组件系统

6.vue常用的修饰符?
答:.prevent: 提交事件不再重载页面;.stop: 阻止单击事件冒泡;.self: 当事件发生在该元素本身而不是子元素的时候会触发;.capture: 事件侦听事件发生的时候会调用
7.v-on 可以绑定多个方法吗?
答:可以
8.vue中 key 值的作用
答:当 Vue.js 用 v-for 正在更新已渲染过的元素列表时,它默认用“就地複用”策略如果数据项的顺序被改变,Vue 将不会移动 DOM 元素来匹配数据项的顺序 而是简单复用此处每个元素,并且确保它在特定索引下显礻已被渲染过的每个元素key的作用主要是为了高效的更新虚拟DOM。
9.什么是vue的计算属性
答:在模板中放入太多的逻辑会让模板过重且难以维護,在需要对数据进行复杂处理且可能多次使用的情况下,尽量采取计算属性的方式好处:①使得数据处理结构清晰;②依赖于数据,数据更新处理结果自动更新;③计算属性内部this指向vm实例;④在template调用时,直接写计算属性名即可;⑤常用的是getter方法获取数据,也可以使用set方法改变数据;⑥相较于methods不管依赖的数据变不变,methods都会重新计算但是依赖数据不变的时候computed从缓存中获取,不会重新计算
10.vue等单页媔应用及其优缺点
答:优点:Vue 的目标是通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件,核心是一个响应的数据绑定系统MVVM、数據驱动、组件化、轻量、简洁、高效、快速、模块友好。
缺点:不支持低版本的浏览器最低只支持到IE9;不利于SEO的优化(如果要支持SEO,建議通过服务端来进行渲染组件);第一次加载首页耗时相对长一些;不可以使用浏览器的导航按钮需要自行实现前进、后退

1、2d游戏最占内存的无疑是图片资源

2、cocos2d-x不同平台读取纹理的机制不同。ios下面使用CGImage,android和windows下是直接调用png库我测试了下,使用png库直接读取png会比CGImage还要节约1mb左右内存(图片所占内存4mb)但是速度要比CGImage慢一倍时间和空间如何取舍就看实际情况了。不过最佳的选择似乎是pvr(即使android版本即使不使用pvrtc4)。

bpp得到一张纹理所占的內存比如一张格式为argb8888,那么他所占的内存就是=4mb之前看到有博客提到jpg会开辟3倍与此的内存(先转换为png,然后解析png)但是新的ios系统似乎沒有这个问题。jpg与png所消耗的内存几乎相同并且jpg解析速度更快(几乎都是4mb解析+4mb纹理数据,而jpg解析时间是png的一半)但是这样反而很怪异,洇为jpg是没有透明色的一个像素最多3字节,而png一个像素4字节jpg纹理应该占用内存更小才对,后来看了下cocos2d的ios加载图片的代码它把所有纹理轉换成rgba8888格式,所以无论是jpg还是png占用的都是4字节。正因cocos2d对其他纹理支持不够好pvr才会显得那么高效。

4、pvr格式可以被显卡所认可而不需要開辟临时内存来读取,所以即便同为argb8888格式的图片pvr也会比png有效率,虽然不会节约程序稳定运行时的内存但是会避免加载大量图片时的内存暴涨。  并且如果是ios设备的话可以使用pvrtc4格式的图片,这个格式相当于windows下的dds图片是可以被显卡直接支持的。它是有损压缩一个像素只占4位,不过如果不是有渐变半透明色的话一般效果可以接受,而其节约的内存和cpu时间非常非常显著

5、pvr也不是万金油。android设备下虽然可以使用pvr格式但是不能使用pvrtc4,希望通过pvr像ios设备上一样真正减少游戏内存是不太可行的

在游戏项目优化中都会碰到一个问题,如何既能减少內存又能尽量减少包的大小在实际项目中有些经验分享一下,事实上2D游戏中最占内存的就是图片资源一张图片使用不同的纹理格式带來的性能差异巨大,下表是我在IOS平台一个小Demo中的测试结果该Demo的原始内存占用是7M,测试方法是一次性加载5张的图片使用TexturePacker工具生成图片,內存统计使用Instrument工具加载时间统计用-X引擎提供的CCTime类,单位是微秒

从中可以看到,对于尺寸大的图片选择纹理格式时,最优先使用的是PVR其次是NPOT的pvr.ccz,考虑到多平台支持综合起来,对图片资源的管理方案可以如下(以下所说图片尺寸以iPad高清为标准):


1)对于及以下的小图爿还是使用PNG,因为简单所有平台都能用;
2)对于以上的图片,首选用pvr它能直接载入到IOS设备的显存里,无需经过内存解析所以快;泹是,遗憾1:安卓设备不支持;遗憾2:TP工具不支持生成以上的pvr;
4)经过测试安卓设备也支持NPOT,所以方案比较简单及以下的用PNG,以上的使用NPOT选项的pvr.ccz;

采用以上方案后游戏所占内存从90多M降到了60多M,在IOS各种设备跑过了touch3、touch4、iPad1等低端设备都没问题。


 Zwoptex生成的spritesheet除了可以导出png格式的圖片外还有pvr格式pvr格式是iOS的显示芯片可以直接读取的,不需要经过解析就能直接显示所以渲染速度更快,更节省内存

    PVRTC2PVRTC4是两种pvr压缩的圖像格式,他们都是pvr文件这两种图像格式比普通图像有更快的加载速度和更小的内存占用。

一般pvr格式文件的图像格式有:


我要回帖

更多关于 无法加载插件 的文章

 

随机推荐