By Long Luo
下面列举一些收藏的资源，用于学习参考：
Long Luo Version0.1 Created at 2014/4/8 10:54:32 @Shenzhen, China. Long Luo Version0.2 Update at 2014/4/9 19:45:07 @Shenzhen, China.
By Long Luo
周星驰的电影《功夫》里面借火云邪神之口说出了一句至理名言：“天下武功，唯快不破”。
在移动互联网时代，同样如此，留给一个公司的窗口往往只有很短的时间，如何把握住这个时机，迅速开发出产品，成为至关重要的一环。相对传统互联网时代的PC产品，用户对移动端产品的容忍度更低。而一款移动应用在推出的时候可能只是接近完成的状态，这就需要通过快速的迭代开发来更新产品，不断完善产品来留住用户。同时，通过更新产品也能唤醒一些沉默用户，让一些原本下载了应用但使用次数非常少的用户给该应用多一次机会。
所以快速迭代成为移动互联网时代的一个重要生存法则。
上面说到，在时间窗口期内开发出产品是极端重要的，但是虽然基本功能我们实现了，但是开发出来的产品代码运行的效率怎么样呢？我们的App用户给用户的体验如何呢？
我们的App体验如此之差，导致大量的用户流失。这些迫使我们认识到性能优化是非常重要，某种程度上甚至超过了新功能的开发。
也验证了一句话：“别人有的我们也有，而且比他们的要好要快。”
做Android开发已经3年了，期间也开发了不少App了，最开始写App的时候，只追求迅速完成所需要的功能，后来随着对相关知识的熟悉，再回头看之前写的代码，也知道有哪些改进和优化的手段了。性能优化，一方面需要自身能力的提高，另外一方面，也需要有意识去学习优化技术，并应用于自身项目的开发中。
我们的Android App开发除了NDK之外，使用的都是Java语言，而Java语言是一种基于虚拟机JVM运行的语言，所以相比C/C++语言来说，效率是比较低的。Java需要占用大量内存来换取执行速度，而不定期的GC机制，直接导致Android界面的卡顿现象。
相比Apple的iOS，Android要面对无数不同的硬件组合，分辨率，驱动等，导致App质量参差不齐。
性能优化技术，简而言之，就是提高我们程序的性能，让我们的应用更快，更少使用CPU资源，更少使用内存。
性能优化是一个非常大的课题，在这里目前准备写8篇笔记来记录，提纲如下：
Long Luo Version0.1 Created at PM14:10 April 12th, 2014 @Shenzhen, China. Long Luo Version0.1 Completed at PM15:25 April 12th, 2014 @Shenzhen, China.
By Long Luo
从小到大，虽然玩过的游戏不少，但是从写程序开始，目前为此仅仅写过2个游戏。其一是2011年在MTK平台下写的贪食蛇，其二是2010年在嵌入式开发板上写过一个迷宫的游戏。第一个代码量大概有3000行左右，第二个有2000行左右。
这2个游戏都很简单，而且网上有很多现成的例子可供参考，因此难度也比较低。
这2天把拖延了好久的《Android应用开发揭秘》的游戏引擎的那一章看完了，收获还是很大，在此写一篇读书笔记。
关于Game Engine，我能想到的几个问题：
下面就来探讨几个问题：
游戏产业在全球来看是一个很大的产业，一款游戏大作包含了非常多的元素。游戏涉及到剧情、人物、任务、关卡、地图、画质、美术、音乐、网络等多种元素。开发一款游戏实际上需要耗费非常多的资源，据说North Star的《GTA V》耗资几亿美元。正因为如此，在开发项目过程中，尽可能复用之前项目成功的东西就非常重要。
一款游戏中，Game Engine直接控制着剧情、关卡、美工、音乐、操作等内容，将游戏的所有元素捆绑在一起。
一般来说，一款Game Engine需要包含以下模块：
———–分割线，以下是重要但较为独立的部分————- 6. UI 7. 音乐音效 8. 网络 9. 脚本（有些类型的游戏引擎需要脚本和逻辑的关联性非常强，有些脚本则比较独立）
Game Engine实际上有效的减少开发者编写程序时的冗余劳动，同时增强游戏的可移植性。
Engine就是游戏的框架，我们需要往框架中填充内容就可以形成一个游戏。
引擎，就是一系列的工具和生产链，像Unreal 3，Unity这样的成熟引擎，用起来非常方便，就是因为它的关卡/场景编辑器十分宜用，支持多种脚本语言。这类引擎运用恰当的话，理论上能将关卡调试和物件流水线的大部分工作从程序员那里完全移出。
游戏 = 引擎(程序) + 资源(图像、声音、动画等)目前的Game Engine的架构都是Model-View-Controller架构，逻辑和显示分开，由一个逻辑控制流来协调Client的请求和Server的行动。
消息循环->更新数据->绘制各节点 这是绘制的基本结构基本不会有大的改变。
各种引擎的变种很大部分是在游戏逻辑上的封装。脚本也好，直接写代码也好。比如较为古老的数据与函数分离，以C语言为代表。大行其道的类结构。以c++为代表。以及现在光环日耀的CBSE，基于组件的架构
By Long Luo
最近一个月在驾校学车，前2次去练车，总是不得要领，连曲线行驶开不好，被教练狂K。经历了当学渣的痛苦之后，痛定思痛，立志成为学霸。
我分析遇到的问题之后，得出我面临的几个问题：
清楚自己的问题就好办了，那就各个击破。
昨天去实际操作了半个小时，果然大有进展。
我学习新东西的时候，往往会学习下理论，就是搞清楚*为什么的问题，目的是为了做到理论和实践相结合，才能真正掌握一个东西。
首先目前的小汽车都是前置发动机前轮驱动的，之前我一直认为小汽车也是后驱的，这纠正了我的一个错误认识，简而言之，就是前轮带着汽车往前跑。
汽车前轮是转向轮，只有前轮才能改变方向，后轮是不能转变方向的，请看下面一张动态图：
汽车转弯时车轮状态：
我们在倒车和转弯各项操作的时候，就必须弄明白汽车转弯的机制和轨迹是什么？
上面这张图很直观的展示了汽车在转弯的时候车辆的旋转中心和前后轮的轨迹。
了解了理论知识，那么在倒车时应该注意些什么呢？
翻译 By Long Luo
原文链接：Introducing Smoothie
Pattrn UI 中的很大一部分是在滑动时从云端获取图片列表。所以我花了相当长的一段时间去调试，以获得滑动时的体验尽可能的流畅。在过去的几周里，我一直在试图解耦代码，完成了一个很小的库：Smoothie 。
Smoothie 提供了一个简单的 API 来异步加载 ListView/GridView 的项目，以和 UI 线程分离。它做了所有你所期望做的事情，加载项目变得可见，取消要求回收的 View 对应的项目等。但它所完成的还不止这些。
Smoothie是手势识别：在Fling手势时，它会必须发起加载项目请求；在滑动列表时，当你的手指按下时，将会启用增量加载项目请求。此外，它支持当前屏幕外项目预加载功能，当你滑动时，可以减少加载占位符类型的项目数。说穿来，Smoothie使用了一个支持可以阻塞队列动态优先执行的的线程池。在屏幕上滑动时，屏幕外即将可见的项目加载请求将动态的获取更高的优先级。
那么，怎么使用它呢？很简单：
首先在你的布局文件中增加一个 AsyncListView 或者 AsyncGridView ，只需要增加一个额外传递的方法到响应的父类中。
然后实现一个和你的应用程序加载和显示项目逻辑一致的 ItemLoader 。你将需要重写下面四种方法： getItemParams() , loadItem() , loadItemFromMemory() 以及 displayItem() 。
最后在 ItemLoader 中建一个 ItemManager ，同时把它和目标 AsyncListView 或者 AsyncGridView 关联起来。
在你的 ListView/GridView 控件需要异步加载时，考虑下把Smoothie作为你的轻量骨架。您可以轻松地连接您自己的图像加载/缓存框架在里面。例如，一个典型的示例应用， Android-BitmapCache 实现了 ItemLoader 使用一个简单的淡入淡出的动画来显示图像。
除了在代码中的 API 文档，还可以看看 App 示例，一边更好地了解如何使用该库。请记住， API 是不是最终版本哦。目前反响是非常好的！
Enjoy it:-)