RISC汇编与中断向量表
摩尔定律让算力放缓,以前学习的都是32位的x86汇编,不得不说x86架构的指令集真的是历史包袱太重了,x86架构的不足在当代急需超强的算力的背景下越发明显,功耗大、通用寄存器数量少、计算机硬件利用率低、寻址范围小等问题凸显,难以跟上算力发展的速度。与此同时,ARM架构在移动互联网盛行的当下却开始焕发出别样的生命力。于是最近看了看ARM架构下的衍生RISC-V架构,顺便回顾一下计算机组成原理的相关内容。
摩尔定律让算力放缓,以前学习的都是32位的x86汇编,不得不说x86架构的指令集真的是历史包袱太重了,x86架构的不足在当代急需超强的算力的背景下越发明显,功耗大、通用寄存器数量少、计算机硬件利用率低、寻址范围小等问题凸显,难以跟上算力发展的速度。与此同时,ARM架构在移动互联网盛行的当下却开始焕发出别样的生命力。于是最近看了看ARM架构下的衍生RISC-V架构,顺便回顾一下计算机组成原理的相关内容。
在UI界面加载一张图片时很简单,然而如果需要加载多张较大的图像,事情就会变得更加复杂。在许多情况下(如ListView、RecyclerView或ViewPager等的组件),屏幕上的图片的总数伴随屏幕的滚动会大大增加,且基本上是无限的。为了使内存使用保持在稳定范围内,防止出现OOM,这些组件会在子 View划出屏幕后,对其进行资源回收,并重新显示新出现的图片,垃圾回收机制会释放掉不再显示的图片的内存空间。但是这样频繁地处理图片的加载和回收不利于操作的流畅性,而内存或者磁盘的Cache就会帮助解决这个问题,实现快速加载已加载的图片。在缓存上,主要有两种级别的Cache:LruCache和DiskLruCache,即内存缓存与磁盘缓存。我们就来借助内存缓存和磁盘缓存来实现一个简易的图片缓存框架。
RecyclerView是Android 5.0以后提出的新UI控件,可以用来代替传统的ListView。但是RecyclerView并不会完全替代ListView,因为两者的使用场景不一样。但是RecyclerView的出现会让很多开源项目被废弃,例如横向滚动的ListView, 横向滚动的GridView, 瀑布流控件,因为RecyclerView能够实现所有这些功能,这是由于RecyclerView对各个功能进行解耦,从而相对于ListView有更好的拓展性。本篇文章着重讲述RecyclerView的使用方式方式上,以及和ListView的对比。
EventBus是GreenRobot开发的Android和Java的开源库,使用发布者/订阅者模式进行解耦合。EventBus使组件之间的通信只需几行代码即可搞定,极度解耦并且简化了代码,消除依赖关系并加快应用程序开发。这里是EventBus的官网: https://greenrobot.org/eventbus/ 。在介绍EventBus的通信方法之前,首先会介绍常规的通信方法,比如说设置监听或者是使用广播等方式,以此来说明常规的方法都有其弊端,然后使用EventBus来完成组件之间的通信,通过案例体会EventBus在组件通信过程中的优势。

前面的文章介绍了自定义View的需要准备的基础知识,自定义View的属性获取、测量(Measure)过程,Measure过程是为了计算View的大小。本篇文章主要记载一下自定义View过程中的Layout过程,Layout过程用于计算View的位置。另外还有更关键的一步,那就是绘制(Draw)过程,一切都准备好了就需要开始绘制出我们的自定义View,后面会有一个绘制例子,在该示例中绘制了一个圆形且带有进度文字说明的进度条,通过这个示例切实感受一下自定义View的魅力。最后还有一个重点就是自定义View状态的存储与恢复。
很多时候系统自带的View组件并不能满足我们的需求,当我们需要特定的显示风格,处理特有的用户交互,封装一个高内聚的视图组件,就需要用到Android给我们提供的自定义View的能力。有了自定义View,我们可以针对特定的应用场景开发出适合该场景的View组件,比如自定义的下拉刷新组件,自定义的进度条组件等等。本片文章主要介绍自定义View的基础知识,为自定义View做充足的准备。
在前面一篇文章中 《流媒体协议之HLS》 介绍了什么是流媒体,什么是HLS以及分析了m3u8文件格式内容的含义。在本篇文章中更多的是实际操作,搭建一个流媒体服务,使用ffmpeg切割大的视频文件,使用ffmpeg切割大的视频文件并加密,使用ffmpeg整合视频片断,以及在代码中如何实现根据m3u8下载并解码对应的媒体文件。演示的环境是Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-62-generic x86_64)、nginx-1.19.6、gcc version 9.3.0、GNU Make 4.2.1O、OpenSSL 1.1.1f