前一段时间找了很久Github在Android端上的App，但是无果。同时为了验证个人开源的App框架App-Architecture，因此，花了一些时间编写了这个应用。另外个人相信针对拥有众多开发者的Github开发一个好的App是很有用的。

第193期

1. Avoiding cold starts on Android

第192期

1. What’s under the hood of the OkHttp’s cache?

第191期

1. 10 things you didn’t know about Android’s Service component

第190期

1. Fixing Memory Leaks in Android - OutOfMemoryError

第189期

1. Implementing video playback in a scrolled list

原文：https://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html

想像一下，你正在看一栋大楼的蓝图。建筑师为你准备了一份修建大楼的计划文档，那你从这些计划文档中能知道些什么呢？
如果你看的计划书是针对单个家庭住户的话，那么你可能会看到一个前门，一个通向客厅或者是餐厅的门厅。靠近饭厅很可能离厨房有一段很短的距离。也许厨房的旁边是扇子区，也可能是一个卧室。当你看着这些计划，你毫无疑问的就会想到你正在看的是一套房子。该架构就叫做“房子”。

或者，如果你在一座图书馆的架构时，在这个图书馆里，你很可能看到一个宏伟的入口，一个出入检查区域，阅读区，小型会议室和一排排用于放书的书架。这种架构就叫做“图书馆”。

因此，你的应用架构重点是什么呢？当你看到顶层的目录结构和在最高级别的包的源文件时，重点是医疗保健系统，或者是会计系统，或者是库存管理系统？还是Rails, 或者 Spring/Hibernate, 或者ASP呢？

功能介绍

使用文章介绍以及和Picasso的对比分析请参考Introduction to Glide, Image Loader Library for Android, recommended by Google

由于这篇文章使用glide的老版本，因此有些使用方法可能不太一致了。
本文基于github上Glide最新代码4.0.0版本做解析。
最基本的使用方式如下：

1
2
3
4
5
6

Glide.with(this)
                .asDrawable()
                .load("http://i6.topit.me/6/5d/45/1131907198420455d6o.jpg")
                .apply(fitCenterTransform(this))
                .apply(placeholderOf(R.drawable.skyblue_logo_wechatfavorite_checked))
                .into(imageView);

Glide使用了现在非常流行的流氏编码方式，方便了开发者的使用，简明、扼要。
接下来主要对上面这一段流氏操作做拆分。

App-Architecture是一个关于移动应用一整套架构的解决方案开源项目。主要目的是整合流行开发模式结合自己本人的工作经验形成的一整套App快速开发解决方案。本套解决方案的app工程和simple工程主要基于Android实现。framework工程实现了主要架构，主要目的是抛开平台相关性。

在许多软件编程任务中，你或多或少期待你的指令将会按照你已经写好的顺序，依次增量执行和完成。但在ReactiveX，很多指令可以通过“观察者”并行执行，其结果将以任意顺序被捕获。你定义了一种“可观察的形式“的检索和转换数据机制而不​​是调用方法，然后订阅观察者给它，每当之前定义好的机制已经准备好了，这些机制就会触发常设的哨兵去捕获并反馈结果。

这种方法的优点是，当你有一大堆的任务是不相互依赖，你就可以同时执行他们，而不是等待每一个来启动下一个前完成，这样你的整个任务包只需要花最长的任务时间。

有很多属于来描述异步编程和设计模型。本文将使用下列术语：一个观察者（observer）订阅可观察到的（Observable）。可观察到的（Observable）通过调用观察者的方法来发射项目或通知给它的所有观察者（observer）。

观察者有些时候也被称作是订阅者，观看者，响应者。因此这样的模式通常就叫做响应模式。

在很多存在UI操作的地方，UI上的操作不应该等待耗时执行程序的完成而阻塞。在一般编程模式下，都会采用异步线程+回调的方式完成这样的交互操作。不过当回调层次越来越多的时候，那代码可维护性将变得很麻烦。因此ReactiveX最出色的地方就是将多个操作过程按照自定义顺序组合完成最终结果，在每次一的操作中只需要关心业务逻辑本身的执行即可。

因文章很快被人转载到一些其他网站，所以本人在此声明：
转载请标明转载出处：http://frodoking.github.io/2015/07/19/java-concurrent-mechanism/

在一般性开发中，笔者经常看到很多同学在对待java并发开发模型中只会使用一些基础的方法。比如volatile，synchronized。像Lock和atomic这类高级并发包很多人并不经常使用。我想大部分原因都是来之于对原理的不属性导致的。在繁忙的开发工作中，又有谁会很准确的把握和使用正确的并发模型呢？

所以最近基于这个思想，本人打算把并发控制机制这部分整理成一篇文章。既是对自己掌握知识的一个回忆，也是希望这篇讲到的类容能帮助到大部分开发者。

并行程序开发不可避免地要涉及多线程、多任务的协作和数据共享等问题。在JDK中，提供了多种途径实现多线程间的并发控制。比如常用的：内部锁、重入锁、读写锁和信号量。

接触Android是从UI开始的，笔者第一份工作是在金山软件做WPS Office。当时开发主要是负责整个演示PPT这边的UI风格开发和维护，当时的开发要求非常严格。要求所有控件采用App的总体风格，不过尽管这样，一个上百人的开发团队。并不能保证所有的人都能做出一样的风格，总是会存在这里或者那里的细小差别。就拿简单的文本框来说，文字排版、大小、颜色、字体、内边距和外边距等等，在不同的层级中都是有不同的要求。如果稍不注意，在后面的调整中都很费劲。