我们经常说 iOS 整机体验要比 Android 好,这里有第三方软件的功劳(iOS 版本质量要高于 Android 版本质量),当然也归功于苹果对 iOS 的封闭系统的管控。应用想上 App Store,就得先过审核,不合规就给你打回来。
今天我们要说的是系统在应用内容就绪前提供的启动过渡画面。Android 常称之为 StartingWindow,iOS 的对应概念是 Launch Screen;两者不能等同于应用启动后自己展示的广告 Activity 或业务首页。
我原先把 iOS 启动画面说成“必须是一张图片”,这里说错了:Xcode 6 发布说明明确记录 iOS 8 起支持 XIB/Storyboard 启动画面。它们帮助系统尽早给出反馈,但“点击后零延迟”不是可保证的时序。Android 的旧实现允许通过主题影响启动预览,也有禁用预览或透明窗口的路径;具体规则要看系统版本。
2017 不知不觉已经走过,博客已经许久没有更新了,一个原因是越来越觉得自己的学识浅薄,怕写了技术误了大家,另一个原因是自己太懒了。鉴于上面两个原因,我决定此博客的更新,不再非要更新技术文章,一些我觉得有意义的事情、思考等,也会更新上来。一方面自己做个记录,如果能顺带给读者带来一点帮助,那自然是最好的(虽然没几个读者…)
2017 既然才刚刚过去,我觉得有必要把 2017 年里面我觉得体验很棒或者对工作生活很有帮助的东西推荐给大家,或许 2018 你会需要他们。推荐的内容包含了 App、硬件、书籍、器材等,需要说明的是,这些东西是我觉得 2017 年给我带来很大帮助的,适合我不一定适合你。话不多说,直接上内容吧!
一转眼就 2017 年了,算起来自己已经工作了快四年了,09年到威海上学,12年去上海实习,13年毕业后还是去了上海,14年进了珠海魅族,直到现在。
这博客从我毕业开始写东西,写写删删,也算是记录了一些东西,自己的工作内容也从 App 开发换到了系统 App 开发,再换到系统开发,也算是走了一圈,一些路程,记录下来,几年后再看看,怀念一下也是不错的。
这篇文章我记录了自己的博客、自己的工作、自己的工作内容、自己的工作习惯、还有对 2017 年的期望,有迷茫,也有奋斗。
17年已经过了 30% 了,希望还不算晚。
Android 官方在 2016 年 3 月更新了 Bottom navigation 设计规范,所谓设计规范就是告诉开发者和设计师要如何去设计和使用某一个组件。不过这次 Bottom navigation 的发布,让许多人大跌眼镜,毕竟 Bottom navigation 这样的组件,在之前的 MD 设计语言中可是只字未提,当时 Android 与 iOS 常见的导航布局也有差异:iOS 应用常用底部标签栏,Android 的旧指南则建议避免这种布局。这是设计建议的变迁,不是两个平台的能力限制,也不是所有 iOS 应用都必须使用底栏。
本文是 Android Bottom navigation 的第二篇文章,主要介绍样式、行为与规格。
Android 官方在 2016 年 3 月更新了 Bottom navigation 设计规范,所谓设计规范就是告诉开发者和设计师要如何去设计和使用某一个组件。不过这次 Bottom navigation 的发布,让许多人大跌眼镜,毕竟 Bottom navigation 这样的组件,在之前的 MD 设计语言中可是只字未提,当时 Android 与 iOS 常见的导航布局也有差异:iOS 应用常用底部标签栏,Android 的旧指南则建议避免这种布局。这是设计建议的变迁,不是两个平台的能力限制,也不是所有 iOS 应用都必须使用底栏。
本文是 Android Bottom navigation 的第一篇文章,主要介绍 Bottom navigation 的使用,以及 Bottom navigation 小变迁。
之前有人在知乎提问:“怎么计算apk的启动时间?” :
利用python或者直接用adb命令怎么计算apk的启动时间呢?就是计算从点击图标到apk完全启动所花费的时间。比如,对游戏来说就是点击游戏图标到进入到登录界面的这段时间。
已知的两种方法貌似可以获取,但是感觉结果不准确:一种是,adb shell am start -w packagename/activity,这个可以得到两个值,ThisTime和TotalTime,不知道两个有什么区别,而且与实际启动时间不匹配,两者相加都可能比实际启动时间小(测试游戏的时候差别更大);另外一种是通过adb logcat的方式,感觉获取的结果也与实际有差别。
我和另外一个同事郭启发 针对两个方面进行了回答,不过毕竟知乎上看的人会比较少,所以我在征得他的同意之后,将这两个答案整理了一下,记录到博客中,一来算是一个小的总结,之后自己看得时候比较方便,二来给需要的同学一个更加方便的途径。
上一篇文章我们使用第三种方法来实现延迟加载。不过上一篇写的比较简单,只是讲解了如何去实现,这一篇就来讲一下为何要这么做,以及这么做后面的原理。
其中会涉及到一些 Android 中的比较重要的类,以及 Activity 生命周期中比较重要的几个函数。
其实这个其中的原理比较简单,不过要弄清楚其实现的过程,还是一件蛮好玩的事情,其中会用到一些工具,自己加调试代码等,一步一步下来,自己对 Activity 的启动的理解又深了一层,希望大家读完之后也会对大家有一定的帮助。
在 Android 开发中,应用启动速度是一个非常重要的点,应用启动优化也是一个非常重要的过程.对于应用启动优化,核心思想就是在启动过程中少做事情,具体实践的时候无非就是下面几种:
- 异步加载
- 延时加载
- 懒加载
不用一一去解释,做过启动优化的估计都使用过,本篇文章将详细讲解一下一种延时加载的实现以及其原理.
这种加载的实现很简单,但是其中的原理可能比较复杂,还涉及到Looper/Handler/MessageQueue/VSYNC等.以及其中碰到的一些问题,还会有一些我自己额外的思考.
前言
本篇文章是自己的一个学习笔记,记录了 Android 5.0 中 hwui 中的 RenderThread 的简单工作流程。由于是学习笔记,所以其中一些细节不会太详细,我只是将大概的流程走一遍,将其工作流标注出来,下次遇到问题的时候就可以知道去哪里查。
下图是我用 Systrace 抓取的应用启动时 RenderThread 第一次 Draw 的历史 Trace。它能帮助观察线程内的执行顺序,但 DrawFrame 区间结束不等于画面已显示:还需要核对 GPU 完成、缓冲区消费、合成和显示的时点。启动期间可能先看到 StartingWindow,它的退出也不能仅凭这段 CPU Trace 判断。