R语言有着很强大的画图功能。我们可以从下面的语句中得到
1、绘画函数
高级画图功能（创建一个新的图形）
低级绘图函数（在现有的图形上添加元素）
2、绘图参数介绍
高级绘图函数共同参数选项：
其它常用绘图参数（可以使用help(par)查看）
3、画图面板分割
在一个面板中画多张图
（1）、par中参数mfrow和mfcol
（2）、ayout函数
生成复杂的图形排列
（3）、其它函数
在一个面板中画多张图
4.图形保存
（1）输出到屏幕
windows, X11
（2）输出到文件
df , postscript , xfig, bitmap, pictex, cairo_pdf, svg, png, jpeg, bmp, tiff
通过菜单命令保存图形
这里主要介绍下在R语言中绘制地图的个人琢磨的思路。绘制地图步骤有三：你得需要绘制地图；（约等于废话）
你得有要绘制地图的地理信息，经纬度啊，边界啊等等；
你得利用2的数据在R中画出来。
以上步骤中，目前最关键的是2，一旦2的数据有了，在R中不就是把它们连起来嘛，这个对于R来说就是调戏它，就跟全民调戏小黄鸡一样。
R语言中绘制地图的思路也是由于2的获取方式不一样而分开的。
第一种思路：有一些R包中存储着常见地图的数据，比如maps包中存有世界地图、美国地图、美国各州郡地图、法国地图以及加拿大城市地图等，加载了这个包，就可以轻松愉快地绘制上述地图。mapdata包中存有中国地图的数据，但是比较旧了，这个数据，重庆还没有从四川分出来呢。
第二种思路：我先去一个地方所画图的地理数据，然后读入R进行绘制。比如由于mapdata中的中国地图比较久远了，谢老大的《终于搞定中国分省市地图》一文中就介绍了，先从国家基础地理信息中心中国各省市的地理数据，之后再绘制。后来肖凯老师又介绍googleVis包也可以按照这个思
概念： 所谓的 BitMap 算法就是用一个 bit 位来标记某个元素所对应的 value；
举例：
现有 40 亿个整数，当给定一个新的整数时，判断新的整数在这40亿个数字中是否存在，假设该架构下整形为4个字节；
其实这个问题的性能点有两方面：
假设 40E 个整数存储在磁盘中，也就是 40亿*4字节，约等于16GB。
假设系统运行内存为2GB，每次新来一个数字就循环加载 16GB 进入系统，和新的整数进行对比。
这种方法每次来一个新的数字进行判断时，因为内存不够用，每次都需要 8 次 i/O 操作，且数据量巨大（2GB），时间上会达到小时级别；
最久时间消耗：8次I/O + 40E次对比运算；
改进方法1，使用 8 个 2GB 运行内存的电脑加载 16GB 的数据，这样只需要并行加载，相当于只加载一次的时间，然后 8 台计算机对比新的整数，最后对结果进行汇总；
此时，因为 40E 个整数都已经被加载进入了内存，每来一个新的数字进行对比时，不需要再进行 I/O 操作，只需要在 8 台机器中并行对比即可；
最久时间消耗：1次I/O（一次性） + 40E/8 次对比运算；
上述两种方法的计算消耗比较高，接下来可以使用位图算法来针对计算消耗进行优化。
int 为 4 个字节，范围为：-2147483648 ~ 2147483647，也就是4294967296个数字。使用一个 bit 也就是一个二进制位来代表一个数字，那么需要 4294967296 / 8 /1024 / 1024 / 1024 约等于 0.5 GB(bit->byte->kb->m->gb)。
也就是说，如果使用内存中一个二进制位来代表一个数字，那么只需要开辟 0.5G 的内存就可以表示所有的整数，此时将 int 类型的内存消耗转化成了 BOOL 类型的内存消耗，所以内存消耗缩小了 32 倍。
I/O 消耗仍然无法避免，但是一个整数在内存中的占用小了 32 倍，只需要一台机器，且不用循环 I/O 了。在内存中开辟 0.5G 内存之后，只需要循环读取 40亿 个数字，然后再内存中对应的 bit 位进行标记，也就是标记为 1，最后根据指定的整数，取出内存中偏移地址的比特位的值，如果为 1 则表示存在，否则反之。此时，计算消耗为 1 次；
最久耗时：1次I/O（一次性） + 1次位运算；
用特定大小的内存空间来表示单个像素的色值，以逐行扫描的方式来来表示整张图片中所有的像素的色值；
在《计算机图形学基础第四版》中对 bitmap 的描述如下：
总结一下其观点，针对帧缓存（Frame Buffer）而言：
个人理解：其实，位图的概念已经没有那么拘泥于是否一定要使用 1 个比特位了。bitmap 的概念就是使用矩阵的方式来表示整体数据，以此来减少数据大小（算法）或则是实现某一目的（raster）。当然，严谨一点更好，所以 Frame Buffer 最好描述为 pixmap（像素图）；
从纯数学的角度，任何一个面都由无数个点组成。但从生理角度而言，人类的肉眼无法区分很小的点。所以在实际应用中，我们没有必要用无数个点来表示一张图片，甚至都没有必要使用足够多的点，只需要让点的个数和大小在人眼能区分的极限之上一点点就好了，如此就能在清晰度和节约内存之间达到平衡。
其一，是因为太多点，人眼也看不出来差别，这就是很多人觉得 2k、4k 好像和 1024*768 并没有太大差别的原因。
其二，使用无数点来表示一张图片是不可能的，使用很大数量的点是极其耗费资源的，性价比很低。
最终决定使用一定数量的点来表示一张图片，而这个点就是像素。而视频本质上时无数图片的连贯播放，因此像素成了图形科学的基础单位；
显示器成像基本上是逐行扫描，如图所示：
再根据上述的位图原理，位图算法可以极大节省空间或者是减少运算量。而像素的数量较多，假设有 1024*768 个像素点，像素点使用我们最常用的16 进制 RGB 来表示颜色，一个像素点有 256 * 256 * 256 种可能。假设一个 Int 类型占 4 字节，也就是 32 bit，那么一个像素点占用的内存空间就是：32 bit。而采用位图之后单个像素占用的存储空间为：8bit * 3 = 24 bit，节省的空间就是 24bit * 像素个数。
上述计算看上去节省的空间不大，甚至如果是 ARGB 的颜色，那么同样也是 32bit ，相比于使用 4 字节的 int 来存储，好像并没有太大优化，但是这里涉及到几个问题：
综上，所以最终采用位图的方式来表示像素点。
压缩会在后文中讨论，这里从色深就可以很直观的知道，8bit 的图片必定没有 32bit 的图片颜色丰富。
还需要补充一个概念：通道
一般 ARGB 颜色就是 4个通道，分别是 透明度、R、G、B，每个通道都使用一定的位数来表示，比如 ARGB_8888 就是 4 通道，每条通道 8 bit。比如 8bit 的灰度颜色，只有黑白，属于单通道。
安卓中，使用 Config 表示每个像素点对 ARGB 通道值的存储方案：
ARGB_8888：每个通道值采8bit来表示，每个像素点需要4字节的内存空间来存储数据。该方案图片质量是最高的，但是占用的内存也是最大的；
ARGB_4444：每个通道都是4位，每个像素占用2个字节，图片的失真比较严重。一般不用这种方案。
RGB_565：这种方案RGB通道值分别占5、6、5位，但是没有存储A通道值，所以不支持透明度。每个像素点占用2字节，是ARGB_8888方案的一半。
ALPHA_8：这种方案不支持颜色值，只存储透明度A通道值，使用场景特殊，比如设置遮盖效果等。
比较分析：一般我们在ARGB_8888方式和RGB_565方式中进行选取：不需要设置透明度时，比如拍摄的照片等，RGB_565是个节省内存空间的不错的选择；既要设置透明度，对图片质量要求又高，就用ARGB_8888；
iOS 中常见的颜色为三种：
上述三种颜色，在设置 bitmap context 中的颜色时，又分为不同参数设置：
cs：color space
bpp：bit per pixel
bpc：bit per component
常量的含义：
颜色布局：
图片的存储一般有两种形式：未加载进内存和加载进内存后；内存中都是以 bitmap 方式表达，非内存中，可以是 bitmap，也可以是各种压缩格式。其中，在内存中的 bitmap 格式称为实际大小；
特点：
特点：
图片格式一般有几种：
bitmap 的大小为：
size = width * height * bpp(bit per pixel)
平常我们见到的图片都是被压缩过后的图片，所以其大小会比 bitmap 格式的图片大小小很多；但是 PNG 格式的图片被加载进内存之后会被还原成全量 bitmap ，所以这也是很多重度使用图片的 app 的一个优化方向；
图元文件并不是矢量图，因为它存储的并不是矢量信息。
它存储的是你在绘图的时候调用了哪些操作。
如果是位图文件记录了你的画布上每一点的颜色的话，
图元文件就是纪录的你如何下笔的。
bitmap 最终数据，被加载到 frame buffer (显存)后，直接由显示器加载数据并最终显示到屏幕上；
