Bootloader是一个启动加载程序，负责系统硬件的初始化工作，也是刷机工作的第一道坎。大部分厂商采用了锁Bootloader的方式 来阻止用户刷机，用户如果想要刷第三方固件就必须对Bootloader进行解锁，由于Bootloader加密算法较为复杂，所以解锁就变成了一件困难事，部分厂商因用户不满最终妥协，提供了官方的解锁途径，比如HTC和索尼爱立信，用户需要到官方网站进行申请然后解锁，但解锁后会失去保修，而另外一部分厂商则不提供解锁，那么解锁Bootloader就变成了一件很复杂的事，虽然有些黑客通过内外相勾结的方式破解了Bootloader算法，但没有破解是绝对完美的，也有很多朋友的手机在解锁时变成了砖头。
如何判断Bootloader解锁呢？当Bootloader解锁后，启动手机会出现开锁图标，或者再次进入Bootloader界面有Unlock标志，就证明Bootloader顺利解锁。
Recovery是手机的工程模式，主要用来执行手机的复位和升级工作，大部分厂商都在手机中提供了进入Recovery的方法，所以用户可以在官方下载Update.zip升级包在Recovery下进行升级，这种方式也是我们俗称的卡刷，当然也有部分厂商不提供，比如中兴. 官方提供的Recovery一般来讲功能有限，而且尽可以进行Update升级包升级的操作，所以对于刷机的用户来讲官方的Recovery是没太大用 的，大家一般都会选择使用第三方的Recovery来代替官方的。对于Recovery的操作，每家厂商的机型都有所不同，但是都大同小异，手机上的物理 按键仅有几颗，所以Recovery的操作一般都是集中在开关机键、音量键或者确定键上。
在类UNIX系统中，root为超级用户，拥有系统的最高权限，如果我们把玩和使用分开算的话，那么玩Android手机的第一步就是获取root权限，只有有了系统的最高权限，我们才能在Android系 统中释放最大的能量，干一些用户权限完不成的事。关于刷机方面，root主要是为了获取权限后让手机能够顺利的刷入第三方的Recovery，各个手机也 都提供了各种不同的root方法，大体上可以分为两种，一种是临时root，而另一种是永久root，临时root会在系统重启后超级用户权限消失，而永久root不会。
Wipe是主清除、复位的意思，这个字眼也是刷机的朋友经常听到的，很多朋友都是按照刷机教程去做了，但并不知道做的目的，Wipe存在于手机的Recovery之中，默认系统提供了两个Wipe方式，第三方的Recovery可能提供了三个，其中一个为执行两个Wipe(用户数据和虚拟机缓存)，Wipe只是为了清除干净手机的用户数据以及虚拟机缓存，如果没有Wipe，可能会造成手机刷机后无法正常启动， 在启动界面出现死循环等状况，所以刷机的朋友应该养成双Wipe的好习惯。
有没有解锁?有没有第三方固件资源?手机版本型号?手机版本对应的基带和固件包?
目前的Android手机刷机大体分为两种刷机方式，线刷和卡刷，线刷指使用USB线作为刷机工具进行刷机，而卡刷则是把固件或者升级包拷贝到手机SD卡中进行刷机升级操作。线刷一般是官方所采取的升级方式，主要用来刷固件，如果手机故障造成无法开机等情况，我们可以考虑使用线刷来拯救手机，线刷一般需要刷机工具，也有和刷机包整合好的。
Android机型所谓刷机就是更换固件，那么固件的选择就尤为重要了，目前的固件总共可以分几大类：一个官方定制固件，也就是我们俗称的官方包、底包，刷过以后手机就回到了买时候的样子，刷官方固件需要注意，要对应自己手机的版本，不仅仅是型号问题，同时还有地区版本，不少朋友变砖都是因为错刷了地区版本导致的，刷固件一般都在Fastboot下进行，这是一个更为底层的刷机界面，需要用线刷。
第二类固件是使用官方固件改的民间固件，这类固件采用官方底包作为基础，进行优化，外观与官方固件类似，内部所应用到的程序也会不有太大变动， 此类固件依托官方驱动，可以达到很好的稳定性(当然也有修改内核或参数造成不稳定的情况)，并在官方固件上进行了精简，去掉了很多没必要的应用。
第三类固件是鼎鼎有名的CyanogenMod出品的固件，是我们俗称的CM，CM团队对于Android爱 好者贡献非常大，CM固件在Android源代码上进行制作，并在其中加入了大量新功能，比如DSP、主题等等，允许用户对一些系统级的设置进行修 改，CM团队也利用自身优势，编写了大量机型的驱动，让CM可以适配市面上绝大多数主流机型，使用CM作为基础进行改造的固件也相当制作，大部分为民间作品。目前CM主流的固件有CM7和CM9。
CM9界面样式 最后一类固件就是像MIUI和点心OS这样有着中国特色的固件，这些固件由固定团队制作，质量很有保障，固件对于中国人使用进行了大量优化，Android原生的应用也被改的“面目全非”，为了达到各机型适配的目的，这些固件大多使用了CM的底层代码，如果没有CM的贡献，那么这些固件只能是谷歌的Nexus系列才有福享用了。
刷机基本上可以分为几步，首先解锁手机的Bootloader，部分手机可略过此步。每个品牌，甚至是每个型号在这步操作上都有所不同，对于一些Bootloader锁得比较好的手机，大家还是谨慎为妙，比如摩托罗拉的Bootloader，虽然有非官方解锁，但由于破解不完美，造成了很多朋友的手机变砖。
解锁后的手机需要root，这一步相对比较简单，风险也相对较小，但由于网上各品牌、各型号、甚至是各版本的手机都有不同的root方法，所以在这里就不一一介绍了。
接下来我们需要往root了的手机内刷入第三方Recovery，目前采用的较主流的方法是使用ClockWorkMod Recovery+固件管理器(ROM Manager)的方法，可以直接在手机上安装固件管理器进行第三方ClockWorkMod Recovery安装或者连接数据线，在电脑端使用CMD命令行程序敲命令进行安装。
最后下载要刷的固件包，使用CWM Recovery进行安装，这里只要了解了自己的机型，下载了对应的包，那么刷机过程就比较简单了，在刷机时，大家需要注意刷包前双Wipe，清除虚拟机缓存与用户数据，以免造成无法开机的情况。
大多数机型的刷机步骤都是如此，因为原理相同，只不过会在界面操作或者进入Recovery方法等地方有所不同，只要我们在需要注意的环节多做些功课，手机变砖的可能性还是非常小的。 刷完进入新系统后，还会出现一些问题，比如没有信号，进入系统信息查看一下基带版本，如果未知，那么可以刷基带解决，类似问题还会有不少，比如使用了过高主频的内核而无法进入系统，我们都可以下载指定的内核或者基带在CWM Recovery下刷入。
由于各机型的刷机方法不同，所以在此我们没法一个个展现给大家，Android的刷机是门学问，但方法不同原理相同，本文的目的也是告诉大家刷机要谨慎，只要了解了刷机的关键点，刷机其实并不可怕，可怕的是盲目。在刷机之前一定要弄清楚自己是为什么刷机，不要盲目，哪怕是千元智能机刷成砖了也可惜了。
##Similarities between both the ROMs
##CyanogenMod 10.1 Pros
The customization options in AOKP ROM are just insane. Please take a deep breath before reading the list below.
Nightly builds can be a bit unstable, but then they are nightly builds. However, for some people this can be a deal breaker
##Conclusion
If after reading the above post, you are still confused, I would suggest you to simply try out both the ROMs. Also, keep in mind that the pros of one ROM automatically becomes the cons of another, and vice-versa. There is no difference in battery life between both the ROMs, since both the ROMs are generally based on a slightly modified stock kernel.
However, users may slight performance difference between both the ROMs on the same device. Ideally, there should not really be any performance difference between both the ROMs, since AOKP is based on CyanogenMod’s device tree. From the above comparison, it should be quite clear that the CyanogenMod team is no longer in the race to offer the most customizable custom ROM.
Instead, their goal is now to offer a ROM that behaves and looks like stock, but comes with some basic customization options. On the other hand, one of main goals of AOKP ROM is to offer its users the ability to customize each and every aspect of the Android OS running on their device.
固态硬盘（Solid State Disk、Solid State Drive，简称SSD）是一种以存储器作为永久性存储器的计算机存储设备。 虽然SSD已不是使用“碟”来记存数据，而是使用NAND Flash，但是人们依照命名习惯，仍然称为固态硬盘（Solid-State Disk）或固态驱动器（Solid-State Drive）。当然，SSD内也没有用来驱动（Drive）旋转的马达。
由于固态硬盘技术与传统硬盘技术不同，所以产生了不少新兴的存储器厂商。厂商只需使用闪存（NAND），再配合适当的控制芯片，就可以制造固态硬盘了。新一代的固态硬盘普遍采用SATA-3接口. 1
SSD固态硬盘价格更高，容量相对普通硬盘要低，相同容量的SSD比HDD的要贵一倍不止，但是读取速度要比HDD的快，抗震性能强，而且体积比HDD硬盘要小，发热量也要小的多，节能省电也是SSD的优势。
4K对齐是一种高级硬盘使用技术，用特殊方法将文件系统格式与硬盘物理层上进行契合，为提高硬盘寿命与高效率使用硬盘空间提供解决方案。因该技术将物理扇区与文件系统的每簇4096字节对齐而得名。2
4K对齐教程：http://diybbs.zol.com.cn/1/34028_1553.html
SATA是Serial ATA的缩写，即串行ATA。看维基知道,SATA接口是用来取代IDE接口的.SATA接口目前有三代 3
非官方民间称呼SATA2,SATA3,看维基百科上面还有一代Express版本的.
mSATA (mini-SATA)是迷你版本SATA接口
Google每年愚人节都会弄一系列的愚人游戏，去年整理的在这里，http://www.einverne.tk/2012/04/2012-april-fool-day-google.html
##Google Nose Google灵鼻子 Google Nose是一款能够告诉你气味的产品，在Google搜索中搜索关键词，在右边就会显示出闻一闻
搜索中新增气味查询功能
气味扑鼻：在打字、说话和触摸的基础上，新增一种感官体验。 您的互联网侍酒师：专家精心设计的知识面板，配有图片、说明和气味介绍。 左闻右嗅：Google 百味库由超过 1500 万个气味字节组成。 不闻不问：如果您不希望查询中出现某些内容，请启用安全搜索功能。
那是什么气味？
Google 灵鼻子Beta将新技术与现有技术相结合，可提供最敏锐的嗅觉体验： 街味嗅闻汽车已经嗅遍了数百万英里的空气，并将它们编入了索引。 Android 周边气味检测工具可通过全世界最敏感的移动操作系统收集气味。 SMELLCD™ 1.8+ 具有很高的分辨率，能精确地控制气味并将气味散播开来。
##Google Maps藏宝图 Google的街景拍摄团队在拍摄时偶然在海底发现一箱藏宝图
##Gmail Blue Everything is Blue
https://www.gmail.com/mail/help/intl/en/promos/blue/
##Google+Photo Emotion
https://plus.google.com/+ErikMurphyChutorian/posts/6cbXigttnUL
##YouTube寻找全球最佳视频
##Google Schmick
##Google Fiber Poles
##Google Apps提供Levity Algorithm
##Google Analytics提供来自国际空间站的访客信息
##Google 日语输入法发布
##Google Wallet Mobile ATM Google Wallet Mobile ATM 帮你随时随地从手机里获得现金 Link
This Jekyll introduction will outline specifically what Jekyll is and why you would want to use it. Directly following the intro we’ll learn exactly how Jekyll does what it does.
Jekyll is a parsing engine bundled as a ruby gem used to build static websites from dynamic components such as templates, partials, liquid code, markdown, etc. Jekyll is known as “a simple, blog aware, static site generator”.
This website is created with Jekyll. Other Jekyll websites.
Jekyll is a ruby gem you install on your local system.
Once there you can call jekyll --server on a directory and provided that directory
is setup in a way jekyll expects, it will do magic stuff like parse markdown/textile files,
compute categories, tags, permalinks, and construct your pages from layout templates and partials.
Once parsed, Jekyll stores the result in a self-contained static _site folder.
The intention here is that you can serve all contents in this folder statically from a plain static web-server.
You can think of Jekyll as a normalish dynamic blog but rather than parsing content, templates, and tags on each request, Jekyll does this once beforehand and caches the entire website in a folder for serving statically.
Jekyll is a parsing engine.
Jekyll does not come with any content nor does it have any templates or design elements. This is a common source of confusion when getting started. Jekyll does not come with anything you actually use or see on your website - you have to make it.
Jekyll is very minimalistic and very efficient. The most important thing to realize about Jekyll is that it creates a static representation of your website requiring only a static web-server. Traditional dynamic blogs like Wordpress require a database and server-side code. Heavily trafficked dynamic blogs must employ a caching layer that ultimately performs the same job Jekyll sets out to do; serve static content.
Therefore if you like to keep things simple and you prefer the command-line over an admin panel UI then give Jekyll a try.
Developers like Jekyll because we can write content like we write code:
The following is a complete but concise outline of exactly how Jekyll works.
Be aware that core concepts are introduced in rapid succession without code examples. This information is not intended to specifically teach you how to do anything, rather it is intended to give you the full picture relative to what is going on in Jekyll-world.
Learning these core concepts should help you avoid common frustrations and ultimately help you better understand the code examples contained throughout Jekyll-Bootstrap.
After installing jekyll you’ll need to format your website directory in a way jekyll expects. Jekyll-bootstrap conveniently provides the base directory format.
Jekyll expects your website directory to be laid out like so:
.
|-- _config.yml
|-- _includes
|-- _layouts
| |-- default.html
| |-- post.html
|-- _posts
| |-- 2011-10-25-open-source-is-good.markdown
| |-- 2011-04-26-hello-world.markdown
|-- _site
|-- index.html
|-- assets
|-- css
|-- style.css
|-- javascripts
_config.yml Stores configuration data.
_includes This folder is for partial views.
_layouts This folder is for the main templates your content will be inserted into. You can have different layouts for different pages or page sections.
_posts
This folder contains your dynamic content/posts.
the naming format is required to be @YEAR-MONTH-DATE-title.MARKUP@.
_site This is where the generated site will be placed once Jekyll is done transforming it.
assets This folder is not part of the standard jekyll structure. The assets folder represents any generic folder you happen to create in your root directory. Directories and files not properly formatted for jekyll will be left untouched for you to serve normally.
(read more: https://github.com/mojombo/jekyll/wiki/Usage)
Jekyll supports various configuration options that are fully outlined here: (https://github.com/mojombo/jekyll/wiki/Configuration)
Content in Jekyll is either a post or a page. These content “objects” get inserted into one or more templates to build the final output for its respective static-page.
Both posts and pages should be written in markdown, textile, or HTML and may also contain Liquid templating syntax. Both posts and pages can have meta-data assigned on a per-page basis such as title, url path, as well as arbitrary custom meta-data.
Creating a Post
Posts are created by properly formatting a file and placing it the _posts folder.
Formatting
A post must have a valid filename in the form YEAR-MONTH-DATE-title.MARKUP and be placed in the _posts directory.
If the data format is invalid Jekyll will not recognize the file as a post. The date and title are automatically parsed from the filename of the post file.
Additionally, each file must have YAML Front-Matter prepended to its content.
YAML Front-Matter is a valid YAML syntax specifying meta-data for the given file.
Order Ordering is an important part of Jekyll but it is hard to specify a custom ordering strategy. Only reverse chronological and chronological ordering is supported in Jekyll.
Since the date is hard-coded into the filename format, to change the order, you must change the dates in the filenames.
Tags Posts can have tags associated with them as part of their meta-data. Tags may be placed on posts by providing them in the post’s YAML front matter. You have access to the post-specific tags in the templates. These tags also get added to the sitewide collection.
Categories Posts may be categorized by providing one or more categories in the YAML front matter. Categories offer more significance over tags in that they can be reflected in the URL path to the given post. Note categories in Jekyll work in a specific way. If you define more than one category you are defining a category hierarchy “set”. Example:
---
title : Hello World
categories : [lessons, beginner]
---
This defines the category hierarchy “lessons/beginner”. Note this is one category node in Jekyll. You won’t find “lessons” and “beginner” as two separate categories unless you define them elsewhere as singular categories.
Creating a Page Pages are created by properly formatting a file and placing it anywhere in the root directory or subdirectories that do not start with an underscore.
Formatting
In order to register as a Jekyll page the file must contain YAML Front-Matter.
Registering a page means 1) that Jekyll will process the page and 2) that the page object will be available in the site.pages array for inclusion into your templates.
Categories and Tags Pages do not compute categories nor tags so defining them will have no effect.
Sub-Directories If pages are defined in sub-directories, the path to the page will be reflected in the url. Example:
.
|-- people
|-- bob
|-- essay.html
This page will be available at http://yourdomain.com/people/bob/essay.html
Recommended Pages
Templates are used to contain a page’s or post’s content.
All templates have access to a global site object variable: site as well as a page object variable: page.
The site variable holds all accessible content and metadata relative to the site.
The page variable holds accessible data for the given page or post being rendered at that point.
Create a Template
Templates are created by properly formatting a file and placing it in the _layouts directory.
Formatting Templates should be coded in HTML and contain YAML Front Matter. All templates can contain Liquid code to work with your site’s data.
Rending Page/Post Content in a Template
There is a special variable in all templates named : content.
The content variable holds the page/post content including any sub-template content previously defined.
Render the content variable wherever you want your main content to be injected into your template:
...
<body>
<div id="sidebar"> ... </div>
<div id="main">
{{content}}
</div>
</body>
...Sub-templates are exactly templates with the only difference being they define another “root” layout/template within their YAML Front Matter. This essentially means a template will render inside of another template.
In Jekyll you can define include files by placing them in the _includes folder.
Includes are NOT templates, rather they are just code snippets that get included into templates.
In this way, you can treat the code inside includes as if it was native to the parent template.
Any valid template code may be used in includes.
Templating is perhaps the most confusing and frustrating part of Jekyll. This is mainly due to the fact that Jekyll templates must use the Liquid Templating Language.
Liquid is a secure templating language developed by Shopify. Liquid is designed for end-users to be able to execute logic within template files without imposing any security risk on the hosting server.
Jekyll uses Liquid to generate the post content within the final page layout structure and as the primary interface for working with your site and post/page data.
GitHub uses Jekyll to power GitHub Pages. GitHub cannot afford to run arbitrary code on their servers so they lock developers down via Liquid.
The short story is liquid is not real code and its not intended to execute real code. The point being you can’t do jackshit in liquid that hasn’t been allowed explicitly by the implementation. What’s more you can only access data-structures that have been explicitly passed to the template.
In Jekyll’s case it is not possible to alter what is passed to Liquid without hacking the gem or running custom plugins. Both of which cannot be supported by GitHub Pages.
As a programmer - this is very frustrating.
But rather than look a gift horse in the mouth we are going to suck it up and view it as an opportunity to work around limitations and adopt client-side solutions when possible.
Aside My personal stance is to not invest time trying to hack liquid. It’s really unnecessary from a programmer’s perspective. That is to say if you have the ability to run custom plugins (i.e. run arbitrary ruby code) you are better off sticking with ruby. Toward that end I’ve built Mustache-with-Jekyll
Static assets are any file in the root or non-underscored subfolders that are not pages. That is they have no valid YAML Front Matter and are thus not treated as Jekyll Pages.
Static assets should be used for images, css, and javascript files.
Remember Jekyll is a processing engine. There are two main types of parsing in Jekyll.
And thus there are two main types of file formats needed for this parsing.
_layouts folder and contain your blogs templates. They should be made in HTML with the help of Liquid syntax.
Since include files are simply injected into templates they are essentially parsed as if they were native to the template.Arbitrary files and folders. Files that are not valid pages are treated as static content and pass through Jekyll untouched and reside on your blog in the exact structure and format they originally existed in.
We’ve outlined the need for valid formatting using YAML Front Matter. Templates, posts, and pages all need to provide valid YAML Front Matter even if the Matter is empty. This is the only way Jekyll knows you want the file processed.
YAML Front Matter must be prepended to the top of template/post/page files:
---
layout: post
category : pages
tags : [how-to, jekyll]
---
... contents ...
Three hyphens on a new line start the Front-Matter block and three hyphens on a new line end the block. The data inside the block must be valid YAML.
Configuration parameters for YAML Front-Matter is outlined here: A comprehensive explanation of YAML Front Matter
The layout parameter in the YAML Front Matter defines the template file for which the given post or template should be injected into.
If a template file specifies its own layout, it is effectively being used as a sub-template.
That is to say loading a post file into a template file that refers to another template file with work in the way you’d expect; as a nested sub-template.
Ultimately, Jekyll’s job is to generate a static representation of your website. The following is an outline of how that’s done:
Jekyll collects data. Jekyll scans the posts directory and collects all posts files as post objects. It then scans the layout assets and collects those and finally scans other directories in search of pages.
Jekyll computes data.
Jekyll takes these objects, computes metadata (permalinks, tags, categories, titles, dates) from them and constructs one
big site object that holds all the posts, pages, layouts, and respective metadata.
At this stage your site is one big computed ruby object.
Jekyll liquifies posts and templates. Next jekyll loops through each post file and converts (through markdown or textile) and liquifies the post inside of its respective layout(s). Once the post is parsed and liquified inside the the proper layout structure, the layout itself is “liquified”. Liquification is defined as follows: Jekyll initiates a Liquid template, and passes a simpler hash representation of the ruby site object as well as a simpler hash representation of the ruby post object. These simplified data structures are what you have access to in the templates.
Jekyll generates output. Finally the liquid templates are “rendered”, thereby processing any liquid syntax provided in the templates and saving the final, static representation of the file.
Notes.
Because Jekyll computes the entire site in one fell swoop, each template is given access to
a global site hash that contains useful data. It is this data that you’ll iterate through and format
using the Liquid tags and filters in order to render it onto a given page.
Remember, in Jekyll you are an end-user. Your API has only two components:
All the data objects available to you in the templates via Liquid are outlined in the API Section of Jekyll-Bootstrap. You can also read the original documentation here: https://github.com/mojombo/jekyll/wiki/Template-Data
I hope this paints a clearer picture of what Jekyll is doing and why it works the way it does. As noted, our main programming constraint is the fact that our API is limited to what is accessible via Liquid and Liquid only.
Jekyll-bootstrap is intended to provide helper methods and strategies aimed at making it more intuitive and easier to work with Jekyll =)
Thank you for reading this far.
Please take a look at or jump right into Usage if you’d like.