天晴日无风

燃烧了一颗恒星来相见


  • 首页

  • 分类

  • 关于

  • 归档

  • 标签

MVVM演进与实践

发表于 2020-06-18 | 分类于 android学习记录

前言

MVC, MVP, MVVM 三种架构思想, 我想每个开发者应该都或多或少接触过, 本篇主要阐述下个人对MVVM的理解, 以及其在Android工程中的应用和实践

阅读全文 »

Tinker源码解析-代码修复和资源修复

发表于 2020-04-21 | 分类于 源码解析

前言

对于Tinker的原理认识, 一直停留在粗放的认知层面上, 但是对于代码修复的细节原理, 关于资源修复原理, dex差分包的算法原理都没有亲自看一遍源码, 因此关于Tinker会分为两篇进行源码解读工作.

阅读全文 »

数据结构-LinkdHashMap

发表于 2019-12-17 | 分类于 源码解析

本系列主要是针对常用的几个数据结构的源码解析, 本篇主要是针对LinkedHashMap的源码解析, 本篇源码依赖于Android SDK -29版本

阅读全文 »

基于LiveData实现事件总线思路和方案

发表于 2019-09-20

前言

当前市面上, 比较常用的事件总线, 仍然是EventBus和RxBus, 早期我曾经写过EventBus源码解析,这两个框架不论是哪个, 开发者都需要去考虑生命周期的处理.而美团给出了个解决方案, 通过LiveData来实现自带生命周期感知能力的事件总线框架. 本篇我们自己撸一个事件总线框架.

阅读全文 »

AndroidQ适配手册

发表于 2019-09-04 | 分类于 日常开发踩坑记录

Android预计在今年Q3发布androidQ的最终版本, 8月份Android发布了Beta6版本, 距离Final Release也不远了, 针对Q的适配已经迫在眉睫!

针对Q的隐私权和行为变更, 我们主要焦点还是着重于, 针对于所有应用(不论targetSdkVersion是否为Q的应用)都有影响的变更上来看

阅读全文 »

基于KotlinMultiPlatform构建跨平台项目

发表于 2019-06-06 | 分类于 新框架学习

前言

当下市场上的跨端解决方案, 不管使用的是React Native, Flutter 还是Weex, 常见的项目组成是, 业务UI界面由上述框架解决, 而涉及不论是性能问题, 还是平台通用共享逻辑问题, 我们更侧重于原生开发, 而这一块我们必不可免需要至少两个原生开发同学通过沟通和开发统一Native层的功能逻辑, 而针对于这些原生通用代码, 现有常见的解决方案还是主要通过传统的C/C++来解决.

而现在, JetBrains的Kotlin/Native为我们提供了另外一个解决方案.

什么是Kotlin/Native

Kotlin/Native 是一种将 Kotlin 代码编译为无需虚拟机就可运行的原生二进制文件的技术。 它是一个基于 LLVM 的 Kotlin 编译器后端以及 Kotlin 标准库的原生实现。

阅读全文 »

深入了解TransformApi

发表于 2019-04-24 | 分类于 源码解析

前言

其实Transform API在一个android工程的打包流程中作用非常大, 像是我们熟知的混淆处理, 类文件转dex文件的处理, 都是通过Transform API去完成的.
本篇内容主要围绕Transform做展开:

  1. Transform API的使用及原理
  2. 字节码处理框架ASM使用技巧
  3. Transform API在应用工程上的使用摸索
    阅读全文 »

RxJava源码解析(三)-背压

发表于 2019-03-05 | 分类于 源码解析

什么是背压(Backpressure)?

我们来看下RxJava自身对其的解释

When the dataflow runs through asynchronous steps, each step may perform different things with different speed. To avoid overwhelming such steps, which usually would manifest itself as increased memory usage due to temporary buffering or the need for skipping/dropping data, a so-called backpressure is applied, which is a form of flow control where the steps can express how many items are they ready to process. This allows constraining the memory usage of the dataflows in situations where there is generally no way for a step to know how many items the upstream will send to it.

来祭出google翻译,

当数据流通过异步步骤时,每个步骤可以以不同的速度执行不同的操作。
为了避免压倒这些步骤,这些步骤通常表现为由于临时缓冲或需要跳过/丢弃数据而增加的内存使用量,所以应用所谓的背压,这是流量控制的一种形式,其中步骤可以表达多少
物品准备好了。
这允许在通常无法知道上游将向其发送多少项的步骤的情况下约束数据流的存储器使用。

简而言之, 当异步情况下, 上流(被观察者)发送数据过快, 而下流(消费者)无法及时处理数据, 导致缓存内存增大, 最终导致OOM, 这个时候, 背压就是为了处理这种情况.

阅读全文 »
12…4
天晴日无风

天晴日无风

开发笔记

30 日志
7 分类
17 标签
GitHub
© 2017 - 2020 天晴日无风
由 Hexo 强力驱动
主题 - NexT.Pisces