关于前端的一些问题

            最近项目刚刚上线,到目前为止还算比较顺利,虽然中间磕磕绊绊的出现一些问题,但是也都一一解决。把相关的问题在这里做一个整理吧,也反思一些在项目中出现的问题进行如何解决。

            第一部分:H5页面兼容性

                在项目开始的时候,前端除了采用zepto之外,还考虑提升用户体验,引用了一个第三方的插件。整个项目测试的过程中,出现了两个问题:引用的第三方插件在部分安卓,ios上出现异常;弱网环境下js加载缓慢。

               该项目在正常情况下各项功能正常,但是在实际的应用中部分ios机型出现了异常,而且在弱网环境的应用场景下出现了一些问题。最后,通过测试决定不使用第三方插件,调用系统的控件,问题解决。

               总结:

               在H5项目中,因为实际的用户场景大部分是移动应用,而移动应用很多时候网络并不是总能保持稳定。这个时候,就充分的体现出在移动场景下,最重要的因素:兼容性和引用文件的大小。

              目前安卓的碎片化严重,甚至部分厂商进行自定义的系统修改,很多时候,会出现部分机型异常或者出现各种无法预计的问题。尤其在追求用户体验的过程中,不能舍本求末,必须在不影响用户使用的情况下,做到最优的程度。当出现一部分机型的用户无法正常使用的时候,通常需要考虑能否承担起损失这部分用户的风险。同样的在涉及到ios的时候,因为其系统的特殊性,也会出现一些因为兼容或则ios系统的机制不同而产生的问题,这些在开发的过程中都是需要充分考虑的因素。在该项目上线时,经过最后的取舍,总共4个引用js,平均大小不到20K,弱网情况下js加载缓慢的问题,也基本上得到解决。我对比了一下最新的jQuery Mobile,其单个文件就超过了100K,虽然在普通情况下问题不大,但是一旦出现极限应用场景,两者的体验还是能看出明显的差异。这也是大部分移动项目采用zepto优先jQuery Mobile的原因。


            第二部分:前端加密

                  在这个项目之前,所有做过的涉及移动端的项目都是简单的写业务逻辑,提供接口给APP端,具体的实现和请求由APP进行处理。在移动端发起的请求,在这种情况下,都由移动端负责加密和安全的问题。此次的H5项目因为是在APP内嵌H5的页面,因此从前端的页面展示和参数的传递都由服务端来进行控制,因此涉及到了平时没有特别重视的加密问题。

                  在进行项目开发的时候,具体的涉及到了两个比较重要的问题:1. 在进行请求发起的时候,因为没有调用系统的签名验证,导致请求没有安全过滤; 2. 在传递参数的时候,涉及到用户的敏感信息,没有做加密处理,导致用户信息明文传递。

                  首先是签名验证的问题,其实在该项目开始的时候,也比较仓促,开发的时间被压缩了很多,也并没有在开始种充分考虑到安全问题。在使用系统的签名验证过程中出现了一些问题。整个项目如果严格按照流程,应该是有两层签名验证的过程。第一层是H5页面加载进入首页的时候,需要对页面的参数和签名进行验证。第二层是在页面用户填好信息之后,发起请求的时候,调用系统签名对请求进行验证。本人在刚开始的时候,第一版就直接没有进行第一层的验证,导致的结果就是在除了APP内部,在外部也可以进行页面的访问,这样做,从严格的安全上来说是有隐患的。但是考虑到在以后业务经过正常的发展之后,还有可能将H5放到微信或者外部,这个地方也做了准备。如果需要的话,这第一层的校验则失去了必要。第二层签名验证的同时,还有一个用户敏感信息加密的问题。这里刚开始的时候,我并没有特别在意这个,只是进行了简单的转码和encode,但是这样的结果就是在传递的过程中还是有可能被拦截和修改参数,因此重新对信息进行了转码+二次加密。

                  总结:

                  项目正式上线的时候,加上了页面加载和请求发起两层签名校验,同时,前端采用了一个开源的js加密库----Crypto-js,用了其中的一种算法,对用户的敏感信息进行了加密。具体的加密和解密方法这里不做详细描述。但是表达一下个人的感言,crypto-js确实用起来很方便。也推荐大家以后如果在做项目的时候涉及到类似的需求,也可以试一试。另外知乎上曾经看到有人对前端是否需要加密的问题进行大肆的讨论,第一名的竟然是前端加密毫无意义的结论。我觉得吧,有些问题,不能一叶障目的去看待。本质上来说,给定一定的时间和资源,一切加密都是无效的,但是这里毕竟还涉及到一个解密成本的问题,如果真的都没有意义。那估计得等到量子计算机搞出来,或者P?=NP问题被解决之后吧。

            第三部分:关于接口调用

                  其实关于接口的调用没有太多可讲的东西,但是之前有做Restful Api,到了手头的这个项目似乎又回归了古老的模式。往深入的说,其实涉及的是计算机之间的通信,以及以什么样的角度来看待对计算资源的访问。以后有机会的话,再深入讲一讲个人关于计算资源的理解。

            第四部分:关于架构

                  架构这个东西,很多时候看上去都是很虚的。但是在实际的开发过程中,整个项目在开始时候的架构的设计直接关系到项目中后期开发的效率,项目运行效率,时间成本等方面。这里个人决定还是把这一部分单独提出来,另外形成一篇文章。这里不做赘述。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章