我们经常说 iOS 整机体验要比 Android 好,这里有第三方软件的功劳(iOS 版本质量要高于 Android 版本质量),当然也归功于苹果对 iOS 的封闭系统的管控。应用想上 App Store,就得先过审核,不合规就给你打回来。
今天我们要说的,就是 iOS 和 Android 系统差异化的一个重要体现:StartingWindow,通俗点说,就是应用启动页。iOS 和 Android 都有 StartingWindow,但是表现却完全不一样。iOS 开发要求应用必须要有一个 StartingWindow,且必须是一张图片(iOS 开发可以说说是否支持定制 Layout),用户点击桌面图标启动应用,不会有任何延迟,会立即显示这个图片;Android 系统的 StartingWindow 虽然也是系统提供的,但是由于开放性,Android 允许开发者自己定制 StartingWindow、disable StartingWindow、透明化 StartingWindow。
2017 不知不觉已经走过,博客已经许久没有更新了,一个原因是越来越觉得自己的学识浅薄,怕写了技术误了大家,另一个原因是自己太懒了。鉴于上面两个原因,我决定此博客的更新,不再非要更新技术文章,一些我觉得有意义的事情、思考等,也会更新上来。一方面自己做个记录,如果能顺带给读者带来一点帮助,那自然是最好的(虽然没几个读者…)
2017 既然才刚刚过去,我觉得有必要把 2017 年里面我觉得体验很棒或者对工作生活很有帮助的东西推荐给大家,或许 2018 你会需要他们。推荐的内容包含了 App、硬件、书籍、器材等,需要说明的是,这些东西是我觉得 2017 年给我带来很大帮助的,适合我不一定适合你。话不多说,直接上内容吧!
一转眼就 2017 年了,算起来自己已经工作了快四年了,09年到威海上学,12年去上海实习,13年毕业后还是去了上海,14年进了珠海魅族,直到现在。
这博客从我毕业开始写东西,写写删删,也算是记录了一些东西,自己的工作内容也从 App 开发换到了系统 App 开发,在换到系统开发,也算是走了一圈,一些路程,记录下来,几年后再看看,怀念一下也是不错的。
这篇文章我记录了自己的博客、自己的工作、自己的工作内容、自己的工作习惯、还有对 2017 年的期望,有迷茫,也有奋斗。
17年已经过了 30% 了,希望还不算晚。
Android 官方在三月的某一天更新了一个新的设计规范,所谓设计规范就是告诉开发者和设计师要如何去设计和使用某一个组件。不过这次 Bottom navigation 的发布,让许多人大跌眼镜,毕竟 Bottom navigation 这样的组件,在之前的 MD 设计语言中可是只字未提,Android 开发者与 iOS 开发中最大的不同也是由于 Bottom navigation 是 iOS 应用的必备,而遵循 MD 设计规范的 Android 应用,则对 Bottom navigation 敬而远之。
本文是 Android Bottom navigation 的第二篇文章,主要介绍样式、行为与规格。
Android 官方在三月的某一天更新了一个新的设计规范,所谓设计规范就是告诉开发者和设计师要如何去设计和使用某一个组件。不过这次 Bottom navigation 的发布,让许多人大跌眼镜,毕竟 Bottom navigation 这样的组件,在之前的 MD 设计语言中可是只字未提,Android 开发者与 iOS 开发中最大的不同也是由于 Bottom navigation 是 iOS 应用的必备,而遵循 MD 设计规范的 Android 应用,则对 Bottom navigation 敬而远之。
本文是 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 图,从这里面的顺序来看 RenderThread 的流程。熟悉应用启动流程的话应该知道,只有当第一次 DrawFrame 完成之后,整个应用的界面才会显示在手机上,在这之前,用户看到的是应用的 StartingWindow 的界面。