浅谈hbuilder开发app后的优化 - (1)加速启动,优化体验
前言:
回顾以下,上一次我们了解了如何加速启动,制作一个"秒开"的假象,本着循序渐进的原则,这一次我将讲述一下进入主页面(以下用main代替)之后,我们该如何优化,本次内容比较枯燥,涉及比较多的理论部分，深入理解之后有利于main的优化,而main的优化往往是留住用户的重点,因为用户进入app后的第一次操作体验往往影响着用户的留存率。

(2)多webview?多div?选啥呢!
首先我们看看dcloud官方的建议:
使用View绘制标题栏,再用一个子webview作为main显示,需要底部tab再用一个webview作为底部栏监听操作事件即可。
从这一句话听起来似乎很正常，没有任何问题，是的，在一个简单的main来说，这样没任何问题，但是如果应用在多webview就出现问题了。
我们思考下，一般app都是<标题><内容区><底部>，这意味着如果采用dcloud官方建议的这种办法来说，在启动时候就创建了两个webview实例，而普遍的app均有3~4个选项卡，这意味着启动app的时候就创建了至少4~5个webview实例，对于性能中档以上的手机并没有压力，但是实际上依然会碰到很多手机性能低的用户，这时候我们就要好好考虑，多webview还是多div呢?

多webview?会遇到那些"坑"呢?
//> 1:OOM (Out Of Memory)
在webview中显示的图片过多,做webview切换动画的时候往往会遇到卡顿，动画不流畅,甚至切换后台重新切换回来后app就黑屏，然后呢?... 这不就挂了么?
设想一个场景，你开着app,点来点去,看到感兴趣的,不错,准备点收藏，结果有人发条微信,你点开一看，然后返回,app奔溃,oh shit!
这是一个真实的实例，我曾经接到一个app,做一个类似应用商店的产品,如果用多webview可以比较好的优化列表滚动流畅度，但是很多子页，再简单的使用了多webview之后，oom!结果app奔溃了，那么oom的话，到底是怎么引起的呢?
首先，图片加载过多，大图过多，页面dom树过度复杂均有可能，第二就是js部分，过多for，if嵌套，自调用，变量使用后没有释放(即便JS本身有着gc机制，但是js语法是十分灵活的,我们不能全部都丢给解释器去处理判断，尽量自己处理下,我相信win下使用C开发过应用程序的都有所体验吧)
【解决方法】OOM，自己多注意，这是码代码的时候就需要思考的。
//>2:动画卡顿，画面闪动
在没有OOM的情况下也会出现动画卡顿问题，一般情况下为页面太复杂，导致进行动画的时候不流畅，或者是一个页面隐藏后显示，页面会闪一下，甚至白屏。
【解决方法】动画卡顿可以采用View预先drawBitmap，然后先飘图再显示，页面显示不全大多数是因为硬件加速，一个隐藏部分忽然显示导致的，一般情况下可以采用这样：当前页面fade-out 目标页面zoom-fade-in，这部分不需要使用View绘制也可以达到流畅。因为默认情况下隐藏后我们的渲染引擎会暂停渲染页面，这就可以释放部分内存用于显示页面。
//>3:窗体错误
这个很奇特的,一个多webview的页面,分为父子webview,当其中一个子webview打开的子页面请求全屏后，重新返回会出现子webview错误，检测后发现webview居然已经不是main的子webview了。
【解决方法】无力相助

综合上面所说多webview大多情况下都是卡，占用内存。所以有些人就说那就全部用多div呗

多div?会遇到那些"坑"呢?
//> 1:进入main时卡顿
多div因为均存在一个子页面,webview开始加载的时候就会"同步"加载所有div,因此一个webview如果出现多div且各div的dom树均复杂的情况下，会出现进入main的时候一开始比较卡顿，之后才能正常操作
【解决方法】使用vue进行动态页面处理,vue本身会自带虚拟DOM,不论是复用div,页面动态增加删除div,vue的表示均比较良好，加一个plus.nativeUI.showWaiting 雪花滚动然用户觉得还在加载(要是内容实在很多就不要滚动了,滚久了你的app也可以滚了)，等待vue渲染完成事件响应之后再关闭雪花滚动
//>2.安卓低版本div无法滚动，IOS透传
众所周知安卓低版本无法进行div滚动,而IOS的div会出现透传问题。
【解决方法】改用mui本身带来的区域滚动组件(iscroll),结合Vue的话需要在渲染完成后重新初始化iscroll
//>3 安卓div区域滚动不流畅,太卡
div滚动本身就不如原生滚动流畅，这个无话可说
【解决方法】对应webview启动硬件加速，并且渲染模式改为allways(总是渲染,会消耗比较多的内存),尽量减少页面的图片量,以及图片大小，因为硬件层在同步绘制图片时候也会消耗比较多的内存。
//>4动画不流畅
没什么好说,切换动画不流畅
【解决方法】同上

综合上面所说，多div大多情况下就是不流畅，不流畅，不流畅，重要的事情说三遍。

那么都是那么扯淡，我们应该如何选择呢?我的考虑是两者结合！
多div不流畅但是占用内存少，多webview卡，但是滚动方面流畅，我们可以把两者结合起来，做一个占用内存少，不卡的app。

首先: main采用多div是种明智的选择，一般app首页都会加上轮播组件(slider),那么多webview切换的时候其实会因为slider的问题导致卡顿，但是div切换不会，因此可以采用多div切换作为main,这样切换过程不会卡顿(注意控制好dom树结构)

其次: 部分少点击的页面采用webview方式打开，因为少点击所以意味着平时极少出现其来占用内存(类似设置,签到中心,积分中心，反馈)，打开之后返回就关闭该webview实例，释放内存。

对于常用的页面，根据逻辑不同取舍，对于类似淘宝，京东商品详情页，朋友圈这类，应该采用webview方式打开，因为其加载图片过多，点击频率不高，可以达到流畅，并且占用内存比较少，用户执行返回之后清除页面图片以及数据，释放部分内存，且有利于下次重新载入此页面。
对于类似我的，消息列表，排行榜这类，应该采用div显示，因为其加载内容少，点击频率不高但是数据需要常驻内存，则直接采用div形式即可(什么? div不是没法滚动么，消息列表呢? 这个直接用ul+li就可以了,没有任何问题,在多个app上面使用过了)

上面这个就是大概的app一个大的考虑，至于细化到部分优化的，可以参考以下几点:

webview切换卡顿:
用view绘制目标webview，首先飘图，然后先隐藏当前webview，然后隐藏view，再显示目标webview，采用fade-in效果显示，这样有一个过度效果，用户体验比较好

webview动画pop-in卡顿
根据dcloud官方说明，pop-in和slide-in-right均有进行一个加速操作，但是pop-in是采用双窗口同时执行动画，而slide-in-right是单窗口，因此pop-in卡得时候，不妨尝试下slide-in-right

div切换卡顿
对于div切换卡顿其实本来就是这样，但是一般情况下我是采用css中的opacity控制显示与否，并且transtion控制动画效果，通过一个渐显渐隐的过程尽量减少用户的违和感(动画时间需要控制好)

沉浸式任务栏切换webview的时候因为窗口调整高度导致闪动
这个是我遇到一个网友问我的，对此我简单分析了下，传统的webview切换是这样的:

var wm = plus.webview.create("a.html","a");  
//监听wm loaded  
wm.show();

这样一个过程就意味是等wm加载完毕后就显示,但是这不意味着窗口高度调整好了！我们稍微修改下就可以完成这个处理

var wm = plus.webview.create("a.html","a");  
plus.nativeUI.showWaiting();

然后在a.html中这样处理

//监听当前wv loaded事件  
然后function里面写  
//>调整页面搞定代码  
plus.webview.show("a","fade-in",150,function(){  
    plus.navtiveUI.closeWaiting();  
})

其实iframe,div,webview均能作为tab 主要是切换里面一些细节做好处理就行了。
我相信很多人看起来一头雾水,然而懂的人自然明白如何操作,这仅仅是本人优化APP的一些方法，做出来分享而已，希望能给大家带来帮助。

javascript
初次使用Hbuilder时候，简直惊呆了，开发速度简直像开火箭般，原生代码android+IOS需要一个月的工作量，在Hbuilder上一周不到就解决了，简直不敢相信。
东西是做出来了，可是问题来了，ipa或apk安装文件解压，我嚓，，啥代码都能看到，这是在玩我么。。。
在网上查了各种资料，加密，混淆，基本用处不大，于是我在想，我请求的参数，请求的地址都能隐藏不就好了么，，
但是还有一个问题，随便使用一个HTTP抓包工具都能看到所有的东西，又郁闷了。。。。
最后一招，在所有的请求参数弄一个加密，从客户端到服务器都是密文，服务器再解密不就OK了么，想到这里就没发现又漏洞了。

请求地址，参数加密都放在原生代码完成，js调用方法获取，原生代码中可存相应的秘钥机制与服务器端对应校验，服务端也需要解密参数。

前端页面js可做代码混淆，Compress就行，其实也没多大必要，离线打包做好代码混淆，获取用第三方的一些加密工具，IOS的用原生代码还是比较安全的，常规破解应该难度大。

以上纯粹个人的搞法，目前我这样用的，目前来说没啥问题，安全性算是加固了一些，希望各位大神多多指点！

<div class="mui-scroll-wrapper mui-slider-indicator mui-segmented-control mui-segmented-control-inverted">  
    <div class="mui-scroll">  
        <img src="xxxxx"/>  
     </div>  
</div>

横向图片只显示一半，须将mui-segmented-control-inverted该div设置一定的高度，以及mui-scroll top设置0即可

/
客户反馈华为的手机扫描二维码出现卡死，不能打开以及奔溃等，以前原生APP的扫描没问题，于是拷贝代码过来直接使用。
/

    if(plus.os.name == "Android")  
    {  
        var main = plus.android.runtimeMainActivity();  
        var Intent = plus.android.importClass("android.content.Intent");  
        var PrintTagActivity = plus.android.importClass("com.demo.CaptureActivity");//自己写的二维码扫描页面  
        var intent = new Intent();  
        intent.setClassName(main, 'com.demo.CaptureActivity');  
        main.startActivityForResult(intent, 100);  
        main.onActivityResult = function(requestCode, resultCode, data) {    
            if('100' == requestCode) {  
                plus.android.importClass(data);  
                var bundle=data.getExtras();  
                plus.android.importClass(bundle);  
                var ewm_no = bundle.getString("Code");///获取二维码信息  
            }  
        };  
    }else  
    {  
        mui.openWindow({  
            url: 'scanBarcode.html',   
            show:{  
              autoShow:true  
            }  
        });  
    }  

很多人一看到标题估计都是说IOS8?哪来那么老的破机子。
目前iPhone5s以下的大多数用户都是维持IOS8以下的系统，而我所在的朋友圈很多人使用iPhone5和iPhone5s，因此这也就成了我比较关注的问题，废话少说，我们现在来看看那些css可能是无效的

width:calc(100vw - 50px)

IOS8以下以及安卓4.0以下不支持calc中含vw,vh单位,需要改为

width:-webkit-calc(100vw - 50px)

安卓2.3以下不支持calc，换成代码修改吧

display:flex;flex-warp:nowarp;

安卓2.3不支持flex,IOS8以下不支持，需要改为

display:-webkit-flex;-webkit-flex-warp:nowarp;

不过既然可以用flex,也有可能可以使用float结合margin实现,所以.... 不用我说了吧?

有些人可能认为自己的app不会有以上这些符合条件的设备打开,谁知道呢= = 我们还有过安卓2.3的用户,当然是安装不上的,但是除了app,我们是否需要微信网页，是否需要移动网页，这些问题在网页端都会出现的，所以见仁见智，详情可以百度css3浏览器支持一览，对了，上述符合条件的，也不支持动画效果... IOS7.1.2不支持组合动画效果，IOS8以上无问题。

前言:
我相信使用hbuilder的开发者,大多数是因为html5开发周期短,实现功能快而使用,当然使用混合开发我相信也是比较少的,至少目前我看到的比较少。那么在这种情况下，我简单的认为大多数开发者使用的是纯hbuilder作为开发环境，那么可优化空间便局限在html原生+plusSDK这儿，因此我仅仅是分享平时在开发中，个人采用的各种优化方法。

(1)加速启动,优化体验
首先我们回顾下打开app走的一个简单的流程:
1.手指点击

1. 载入Activity
2. 载入Splashscreen
3. 载入webview
4. 渲染页面
5. closeSplashscreen
6. 完成工作
   备注:
   Activity:安卓原生Activity
   Splashscreen:实则为一个View,称之为"启动页"
   webview:很多人简称“浏览器”
   至此我们思考下，如何进行处理比较好，这儿我给各位简单分析一下显示层级:
   Activity < webview < Splashscreen < plus.Native.View

那么加载速度呢?
Activity > Splashscreen = plus.Native.View > webview
从而我们可以看到,当启动Activity之后,随着Splashscreen会显示出来,其次就是plus.Native.View控件。
然而plus.Native.View控件的显示层级又高于Splashscreen,因此new plus.Native,View();ViewObject.show()之后,新建的View会显示在Splashscreen上面,这样我们就可以制造一个快速启动的假象。

题外话：<script src="html5plus://ready"></script>可以加速plusAPI生效,您知道了了么?对我来说是写在<meta charset="utf-8">下面,这样不会出现乱码问题,且不影响页面。

接下来，进入代码阶段:
1:我们需要在manifest.json中配置启动页的关闭方式:

 plus.NativeUI.showWaiting()  //显示雪花滚动,等待样式  
 var wm = plus.webview.create("main.html") //创建app主页面  
       wm.addEventListener("loaded",function(){  
             plus.webview.show(id,"none",0,function(){  
                    //此时关闭View和关闭雪花滚动  
                    plus.NativeUI.closeWaiting()  
             });  
       })

//等待webview加载完毕之后再显示
至此我们就可以制造一个快速启动的错觉，再利用雪花滚动的过程ajax同步加载数据，等待渲染完毕之后再载入wm
相对于上面这种显示方法，我个人比较常用的是将

        wm.addEventListener("loaded",function(){  
             plus.webview.show(id,"none",0,function(){  
                    //此时关闭View和关闭雪花滚动  
                    plus.NativeUI.closeWaiting()  
             });  
       })

放在main.html中,改为ajax请求完成，填充完内容之后在调用

              plus.webview.show(id,"none",0,function(){  
                    //此时关闭View和关闭雪花滚动  
                    plus.NativeUI.closeWaiting()  
             });

这样可以更直观的感觉滚动完雪花后加载的是一个完整页面。
但是记得ajax要加上timeout的处理。
如果使用vue的话，则需要在vue的Methods中进行页面填充处理
随后调用vue本身带的this.$nextTick监听是否渲染完毕,渲染完毕之后再关闭view和雪花滚动。

我相信很多人看起来一头雾水,然而懂的人自然明白如何操作,这仅仅是本人优化APP的一些方法，做出来分享而已，希望能给大家带来帮助。
后面再继续分享一些其他开发中遇到的问题以及一些优化的方法。

hcoder 一直致力于奉献高质量的视频教程，官网上 mui、h5 等免费教程播放量已经达到5万。
教程汇总
知识点 ： JavaScript 快速提高视频教程
实战： MUI、H5 APP 实战教程 - 仿《有道词典》
知识点 ： HBuilder 8.0.1 APP开发 - 新功能全接触
知识点 ： APP开发教程 - 启动动画
知识点 ： APP开发实例教程 - 窗口切换
知识点 ： 移动端图片剪裁、上传视频教程
知识点 ： app开发教程-用户注册、登录
实战 ： APP开发实战 - 新闻客户端
知识点 ： HTML 5 开发教程
知识点 ： mui 全套教程

免费教程地址
http://www.hcoder.net/course/index/cate/4

使用工具：OpenSSL，访问： http://slproweb.com/products/Win32OpenSSL.html 下载（如果链接打不开请自行百度下载）

安装好后进去安装目录，将附件中的批处理文件丢bin文件夹下，这里就不再重复cmd命令，直接批处理文件搞定。（批处理文件请先编辑修改你的OpenSSL访问路径，以及证书密码）

首先打开 MyRequest.bat 文件，生成 my.certSigningRequest 文件，用于上传到苹果开发者中心；

苹果开发者中心一步步下载.cer文件，重命名为 my.cer，放到bin目录，第二步点击 MyP12.bat 文件，就会生成 .p12文件，就是我们要的私钥证书了。

就是这么简单。

附送安卓证书在线秒钟生成工具： http://www.applicationloader.net/appuploader/keystore.php

附件：[批处理文件下载请点击此处].......

1、无内容标签闭合问题
我们都知道无内容标签比如<br>和<br />对于浏览器解析并无问题。
但从web标准规范来讲，<br />更多是XHTML的产物，而HTML并没这方面的规定。
近期百度了很多这方面的文章，发现<br>这样的写法更规范。
也就说无内容标签并不建议闭合。
文章出处：https://www.oschina.net/news/49775/html-tag-to-close-or-not-to-close

所以，HBuilder默认的代码块里，这些无内容标签的斜杠还有必要存在吗？

2、由于我们项目开发环境是GBK，所以HBuilder的代码编码我选择了GBK，但在这情况下，我发现一些配置文件，比如代码块配置文件打开中文字体都是乱码的。何解？

在HBUILDER中，配置好了BEECLOUD写好了代码，在支付时微信好使，选支付宝时，APP没有任何反应，没有报错也没有任何提示
对beecloud.js一点点跟踪，发现没取到支付宝这个支付类型，再一查，原来是在manifest.json中没有勾上支付宝一项，勾上就好了
不过话说回来了
不过对于beecloud来说，应当有个提示，而不是什么反应都没有，让用户以为出什么BUG了
对payChannel进行一下判断看是否是NULL，为Null返回个错误，或者在else if (payData.channel == 'UN_WEB')块后面加上else，返回一个错误信息，对用户或开发者来说都会友好很多

viewApi.back();

https://bbs.deepin.org/forum.php?mod=viewthread&tid=138355