Android抖动动画的实现与思考

大家好,我是光源。

在日常使用app或者玩游戏的过程中,我们经常可以看到某个view通过抖动来吸引用户注意,今天就来说说怎么实现这个动画。

具体需求是,实现一个抖动动画要求同时对大小、旋转角度进行更改且可定制

要实现动画,我们首先应该想到的是 Android 中动画相关的内容。

Android 中一共有三类动画:

  • View Animation
    又称补间动画,在 android.view.animation.Animation 类之下衍生了五个子类。
类名 作用
AlphaAnimation 渐变透明度
RotateAnimation 旋转
ScaleAnimation 尺寸缩放
TranslateAnimation 位置平移
AnimationSet 动画集合

​通过前四个类,基本可以解决大部分动画需求,再使用 AnimationSet 使动画具有组合的能力。

  • Drawable Animation
    又称逐帧动画,通过设置多个帧在一定时间内不断进行帧的变换形成动画的效果,类似 gif 图。通过 xml 中的 animation-list 标签定义动画,再在 java 代码中用 AnimationDrawable 类来进行控制。

  • Property Animation
    View Animation 虽然可以解决大部分动画,但还是有些无法实现,而 Drawable Animation 则太过费时费力,所以在 Android 3.0(API 11)引入了属性动画,属性动画实现原理就是修改控件的属性值实现的动画。具体实现又分为 ValueAnimator 和 ObjectAnimator,这里不展开。

回到需求本身,从需求上看,三种方式都可以实现(其实对最接近动画本质的逐帧动画而言,还真没有不能实现的动画 ),这里不妨三种方式都尝试一下(为方便代码展示,以下尽量使用java代码实现动画)。

Android朝花夕拾之Android权限最佳实践

前言

大家好,我是光源。

从 Android6.0 开始Android的权限模式有了一番更改,从安装时一股脑列给用户,到运行时动态申请权限。对于 Android开发者而言,这是一个重要的变更。

讨论这个问题之前,我们得先检查一下项目的 target version。如果是 23及以上,则必须得适配新权限模式;如果是 23之下,则还是统一在安装时全部申请权限——即便如此,使用Android 6.0及以上系统的用户还是可以在设置中去关闭你的某些权限。当权限被关闭时,不会导致你的应用直接崩溃,但是会导致你获取到的返回值为null 或者 0,这个是需要注意的地方。

以下是 Android 官网给出的最佳实践,草草翻译,有不妥之处还请斧正。

正文

app很容易用海量的权限请求淹没用户。如果用户发现 app 影响使用或者担忧 app 滥用用户个人信息,他们可能不再使用或者完全删除这个app。以下最佳实践能帮助你避免这种糟糕的用户体验。

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耗费的那点性能。

Fork me on GitHub