Android 性能典范:拯救计划

前言

今天逛稀土时偶然看到hanks分享的一篇英文文章,粗略浏览便已觉得不错,因此翻译成中文,与君分享。

原文地址:Android Performance Patterns: Rescue tips

正文

现在的app到处都充斥着华丽的动画、复杂的转化还有自定义View,然而用户体验必须尽可能直观且类似。以下这些范例将会帮助你做出一个流畅的、快速响应的、甚至可能减少电量损耗的app,这些范例由一些可以提升整体应用表现的微优化组成。

记一件需要反省的事——如何实现webView内部跳转

起因

今天在做一个“WebView内部跳转”的小需求时,发现了一件比较诡异的事:项目中没有在 shouldOverrideUrlLoading中主动去用view.loadUrl逻辑处理,为何能够实现WebView内部跳转呢?

带着这个小疑惑,我去问了一个厉害的同事,他说道,只要shouldOverrideUrlLoading返回值为false,即可实现内部跳转。

听到这个我有些困扰,因为记忆中一直是需要手动去load新的url才能实现,否则就跳浏览器的。然后google了下,就搜到以下两个:

[shouldOverrideUrlLoading return method]

[WebViewClient shouldOverrideUrlLoading 常见错误用法]

我的内心是崩溃的。。

分析原因

我之所以会记错技术点,小原因有三:
1,我之前使用WebView都比较简单,没有去设置WebViewClient,所以会有链接跳转都交由系统处理的惯性思维;
2,在之前的项目中,接触到了系统对webView中的以http协议开头的处理,更加加深了“系统会主动去处理链接”的想法;
3,然后就是之前包括刚刚搜索了几次“webView 内部跳转”,都是说需要手动去调用view.loadUrl处理的博客。

try catch会影响性能么

前言

今天 code review 时发现某个同事的代码中存在滥用try catch的现象。其实这种行为我们也许都经历过,刚参加工作想尽量避免出现崩溃问题,因此不可避免得想在所有可能抛出异常的地方都try catch一下。

当然,这种行为肯定是不可取的。如果这样,那还不如所有逻辑都包在大大的try catch里好了。代码的是否具有高健壮性必然是代码是否高效优雅决定的。

当然,这个也引起我的思考,try catch会影响性能么?

结论

try catch不会影响性能。——严格意义上说是微乎其微。

这个结论的确很难让人接受,最起码与我的预估不大一样。

按照我的想法,当代码中出现的各种特性越多,轻量点的如enum,重一点的如“反射”,必然会增加更多的开销。

然而,从结果看,在没有抛出异常时,try catch的影响跟添加了一个 if else是同一个量级的。也就是说,我们完全可以忽视try catch耗费的那点性能。

Android中Serializable和Parcelable的对比

前言

对于Android开发者来说,序列化总是一个不能避免的问题。前有“使用enum实现单例模式可以自动序列化”的观点,后有“在Intent传输过程中使用Parcelable进行序列化可以减少性能损耗”的思考。

由此,我们很有必要找到应对各种场景的最佳实践。

本文中我们谈谈SerializableParcelable

结论

二话不说先说结论(就是这么直接干脆):序列化的数据仅需在内存中传输的,使用Parcelable;反之,如果需要持久化或者网络传输等等的,请使用Serializable

论述

Serializable相信大家不会陌生,从Java中就有这个接口存在。Serializable接口是一种标识接口,它的迷人之处在于,你只要让需要序列化的类实现该接口,Java便会对该类进行高效的序列化。

回望2015

今天是2016年处于工作时间内的第一个星期天——暂且忽略包含在元旦假期内的3号吧。每次跨越一个年头,第一个要头疼的就是每次写日期的时候不得不提醒一遍自己,现在是新的一年了。

以往的习惯,也是要写一写年度总结的,不过都是在农历新年的夜里、在爆竹声声辞旧岁的氛围中,写下一些文字发在自己的QQ空间里。

而今年,本来是不准备再写了的。一方面是身份的转变,似乎看清了一些东西,不必把事事都演化成习惯,让自己背负着前进;另一方面是有了一种明悟,生活之精彩,实在不是文字所能表达,强行给经历贴上一段似是而非的记录,反而局限了记忆中事物的万千变化。

但今天,突然想写点什么。

博客搭建在github上,形式不错,但是没有了一个固定的编辑器。恰巧注册了简书,就写在这里吧。既然提到了身份的转变,就以这点开始好了。

Fork me on GitHub