标签归档：APP缓存

APP开发小技巧，如何提高APP页面加载速度，提升渲染能力？

发表于由

APP开发小技巧，如何提高APP页面加载速度，提升渲染能力？

　　UX性能优化就是至关重要，不好好学习如何进阶到二0K+的薪水啊?!

　　性能优化方面一直有所关注，但假设不去对自己所负责的项目进行一下回锅，实践实践，优化优化，总会有点“书上得来终觉浅”的感觉吧!

　　从最开始的CSS放到里面、js放到前面、使用雪碧图等，到后面的静态资源压缩、合并以及使用iconfont代替小图标，再到最近实践的gzip压缩、设置HTTP Header缓存字段…

　　gzip压缩、设置ETag等，早就在《高性能网站建设指南》那两本书中看过，但我一直认为这都是服务端小伙伴干得事，就没有如何留意过。

直到最近，对前服务端分离的理解越来越充分，对整个项目的部署越来越清晰，对项目里面的资源请求越来越清楚，才恍然意识到：前服务端分离了，这他妈就是UX自己干的事啊!!!

　　从以下几个方面来看一说自己实践过的优化方法：

　　➤ 浏览器渲染页面的过程

　　所谓优化，首先个要弄清楚的就是：优化什麽、从哪里优化。

UX做出来的页面是在浏览器里面呈现的，那浏览器是如何渲染这个页面的呢?遇到CSS、js静态资源，浏览器是如何处理的?具体的过程这里不再赘述，网络上资源一大堆，我自己之前也写过一篇，《网站性能优化—CRP》，算是谷歌文档的翻译版吧。

　　理解了浏览器渲染页面的过程，也就清楚了：CSS为ionic 打包app什麽要放到里面、js放到前面，以及js的异步加载(async、defer)等优化。

　　➤ 减少HTTP请求

　　CSS/JS 合并封装

　　小图标等用iconfont代替：作为单个DOM节点使用，能够设置大小、颜色等，非常便利。

个人意见UX来维护这个字体包，每次有新增的图标，让设计师给我们对应的svg文件即可，UX自己去 https://icomoon.io/ 这个网站，导入原来的selection.json文件，增量生成新的css，无比方便。

之前，我一直以为iconfont只能是单色的呢，其实也能够是多色的，svg里面多一些path而已，设计师会搞定的。

生成字体后，UX正常引用即可(引用的时候，多色字体会多一些标签)

　　使用base六四格式的图片：有些小图片，可能色彩比较复杂，这个时候再用iconfont就有点不合适了，此时能够将其转化为base六四格式(不能缓存)，直接嵌在src中，比如webpack的url-loader设置limit参数即可

　　使用雪碧图：设置背景图尺寸大小，感觉很麻烦，并且雪碧图的维护也不如何便利，好像使用率越来越低了，都被iconfont取代了

　　➤ 减少静态资源的体积

　　压缩静态资源：合并封装的js、css文件体积通常会比较大，一些图片也会比较大，这个时候必须要压缩处理。

前服务端分离项目，不论是gulp还是webpack，都有相应的工具包。

针对个别图片，有时候也能够单独拿出来处理，我个人经常使用这个网站 https://tinypng.com/ 在线压缩

　　编写高效率的CSS：涉及到代码层面的优化比较多也比较细，不同水平的技术人工写出来的肯定不同样，这里不做进一步的分析。

不过为什麽要把CSS拿出来看一说呢?是因为目前项目里面根本上都在使用CSS预处理器，Less、SaaS、Stylus等等，这导致了某些初级UX的滥用：嵌套五、六层，甚者能达到七、八层，吓死个人!嵌套那么深，影响浏览器查找选用器的速度不说，这也一定程度上产出了很多冗余的字节，这个要改、要揭示，通常意见嵌套三层即可。

关于编写高效率的CSS，推荐一篇文章，《Writing efficient CSS selectors》

　　后端开启gzip压缩：大招，最近刚知晓，真是太牛逼vue开发webapp了，通常的css、js文件能压缩六0、七0%，当然，这个比率能够设定的。

前服务端分离，假设UX部署用node、express作服务器的话，使用中间件compression即可开启gzip压缩：

　　// server.jsvar express = require(‘express’);var compress = require(‘compression’);var app = express();

　　app.use(compress());

　　对于通常的SPA项目，假设node服务器的作用比较轻松，比如只是做个接口转发之类的，很多人更倾向用Nginx作服务器，Nginx在转发接口、压缩、缓存等功能上更胜一筹。

但是，大部分UX对Nginx应该陌生一些，为了实践技术，用熟悉的node即可，真正的项目部署，有专业的实施人工来搞。

　　➤ 使用缓存

　　设置Http Header里面缓存相关的字段，做进一步的优化。

　　express里面也有对静态资源相关的设置，只但是平时没如何注意：

　　能够设置etag、maxAge等，进一步会有二00缓存和三0四缓存的区别：

　　二00 OK (from cache) 是浏览器

没有跟服务器确定，直接用了浏览器缓存;而 三0四 Not Modified 是浏览器和服务器多确定了一次缓存的有效性，然后再使用的缓存。

　　相关的讨论能够参考 知乎：阿里云存储怎么让浏览器始终以二00 (from cache)缓存图片?

　　➤ 内存溢出

　　这种优化因问题而异吧，最关键的是善于使用Google DevTools里面的Performance面板和Memory面板去分析、查找问题，进而找到优化的点。

　　内存溢出现在我只碰到过一次，同事用echarts画K线图，同事的js逻辑写的有问题，点击事件发生时canvas反复渲染，导致内存日益升高，在移动应用内，直接导致了移动应用闪退。

我重写了一下网页转app打包js逻辑，针对canvas做了一些优化，修复了这个bug。

　　现在对这块分析经验还不是很多，后续碰到问题再实践。

　　性能优化这块，都是一点一点接触的，项目中碰到了问题，然后去分析、优化，解决问题的同时，自己也收获了很多知识。

以上是我做UX使用过的优化方法，可能对于大牛来看，或许不值得的一提，不过对于小白来看应该还是有些许参考意义。

　　有些高级优化还没有实践到，比如划分主域，细节一点的无线滚动优化等，今后会继续学习。

APP开发小技巧，如何提高APP页面加载速度，提升渲染能力？

APP开发过程中技术需要特别注意的几个关于用户体验的地方？

发表于由

APP开发过程中技术需要特别注意的几个关于用户体验的地方？

　　移动应用制作和电脑程序制作截然不同，比如说：清理缓存等动作，在PC电脑中是个不起眼的小事，使用管家类html5 app产品一键就能清扫干净，但这在手机上并不是一件小事，是因为随着智能手机缩减了使用门槛，老人小孩都能用，不过他们对技术完全不懂，再者就是手机空间不足是天然瓶颈，不像电脑硬盘动辄1TB、二TB，国内八0%的手机空间不足四GB，小明认为假设那么小的空间再被垃圾文件浪费掉，实在是不应该，假设app制作没有研究这方面的问题，引起用户的手机卡顿，这个相当影响用户的体验，很容易被卸载，被用户所弃用。

下面就来谈谈移动应用制作影响用户体验的几点“不规范之处”。

　　1、移动应用卸载不干净

　　在苹果iOS官方上，一种App卸载后就被完全删除

干净，但安卓上大量的App软件在卸载之后是不干净的，容易残留许多文件。

尤其是视频类、音乐类等的移动应用残留文件更大，往往高达数百MB。

　　许多App制作为了方便自己获取文件，没有把移动应用产生的缓存文件放在规范的目录里，而是存放在SD卡的根目录中，这样缓存文件会越积越多。

vue 写app

　　二、移动应用制作的缓存不自动清理

　　以新闻客户端类手机软件制作举例，用户每次预览新闻后，总会留下大量的文字、照片或视频缓存，存放在SD卡中，缓存功能本是为了提升重复访问的速度和节省流量，但其实新闻有很强的时效性，昨天看过的新闻几乎不会再一次打开，这些缓存信息就一点儿价值都没有，占用了大量空间，用户不知道去哪里删除，这些移动应用也不自觉，均不会自动清理。

　　三、移动应用制作在后台频繁联网自动迭代

　　约有二0%的通用App即使不运行时也在后台启动联网，app制作之因此这样核心是提交产品及用户使用信息、获取广告、查询是否迭代等。

　　而每次移动应用迭代安装后，新的安装包却仍然留在了手机中，变成了无用垃圾文件，一样会造成用户手机的流量和空间无谓地消耗。

　　四、移动应用制作者诱导推广移动应用下载

　　在移动应用运营中，商家一般会通过一些手段来激励用户安装移动应用产品，这个时候就要掌握住宣传的尺度、和运用的方法，加入用户通过不恰当的诱导手段进行安装，并非用户本意，这么用户很有可能直接卸载移动应用产品。

　　一款成功的移动应用，必定要以用h5在线打包户体验为首要任务，假设制作出来的移动应用产品不以用户为主要，最终的成果必定留不住用户。

因此在制作移动应用之前，制作者要非常明白的进行规划，规划好移动应用产品怎样才能更好的为用户服务。