In order to get the current date,time,we can use 2 methods-either using the localtime of the desktop or using GMT(GREENWICH MEAN TIME)
//USING THE LOCAL TIME
//USIMG GMT Replace the above line
and since that gmtime is 5 hours 30 min. less than the India time,we have to add that much time to the gmtime time for the current india time
原文地址：http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2014/1012/1747.html
说明:录制手机屏幕,视频格式为mp4,存放到手机sd卡里，默认录制时间为180s
参数: –time-limit
说明:限制视频录制时间为10s,如果不限制,默认180s
参数: –size
Size classes是iOS8中新特性,有了它可以根据设备屏幕或者旋转状态来自定义app布局,在iOS8之前,开发者需要用多个Storyboards使用不同的UI布局来适配旋转状态及不同的设备。在这篇教程中我们主要看看在Xcode6中如何使用Size Classes来适配。
打开Xcode,新建项目选择Single View Application,Product Name填写iOS8SizeClassesTutorial,Organization Name和Organization Identifier根据自己填写,选择Swift语言
与Universal设备。
打开storyboard,在Xcode6中视图控制显示的为正方形,这是因为size class默认为Any width与And height。在storyboard给每个角落位置增加一个按钮,名称分别为"top-left,top-right, bottom-left and bottom-right".将ViewController背景颜色设置为Cyan,这时Storyboard看起来大致如下：
编译运行后,可以发现右边的2个按钮不见了,这是因为layout是为And-width和Any-height设计的。接下来,我们将按钮固定在每个角落上,选择top-left button,Ctrl+Drag方式拉到左边ViewController上并选择“Leading Space to Container Margin”（如下图）,这时按钮Button将会固定在left位置。
接下来,再按以上方式然后选择“Top Space to Top Layout Guide”，这时按钮Button则会固定在Top位置。
Apple从iOS 6加入了Auto Layout后开始就比较委婉的开始鼓励、建议开发者使用自适应布局，但是到目前为止，我感觉大多数开发者一直在回避这个问题，不管是不是由于历史原因造成的，至少他们在心底还坚守着固定布局的老传统思想。
随着iPhone6、iPhone6 Plus的到来，使用自适应布局更是迫在眉睫的事，固定布局的老传统思想脆弱的不堪一击。现在的iPhone有4种尺寸，如果算上iPad，现在Apple的iOS设备有5种尺寸。我们在准备使用自适应布局设计应用界面之前，可以把这5种尺寸划分为3种分辨率和屏幕方向，这样在设计时分类会更加清晰一些。
我们先来看一张自适应布局的效果图：
当你们学习完这篇文章后，你们应该会比较自如的使用 storyboard、constaints、size classes 这三个Apple在Xcode里提供的工具，去探索和构建巧妙的自适应布局。
Storyboards
在Xcode中，storyboard是一个可以让我们对应用界面进行可视化布局的工具，你首先可以在storyboard文件中看到一个或若干个iOS设备屏幕大小的布局区，然后你可以从组件库（Object Library）中拖拽组件到屏幕布局区中进行布局（比如按钮、图片、文本框、labels等），你还可以定义屏幕布局区之间的连接关系。
用Xcode的术语来说，人们可以看到、触碰到或以其他方式（按钮、图片、文本框、labels等）进行交互的用户界面被称为views。屏幕中包含和管理这些views的容器称为view controller。
当我们在storyboard中添加一个view controller后，我们所看到的并不是一个我们熟知的屏幕尺寸，而是一个600X600的正方形：
从上图我们可以很明显的看出，storyboard中显示的屏幕尺寸不是实际设备的尺寸。Apple这样做的目的是将屏幕尺寸进行了抽象化，也就是说你可以将这个正方形的屏幕看成iphone4的屏幕，也可以将它看成iphone6的屏幕。
模拟器的尺寸
当你习惯了600X600的屏幕后，你可能会用着很爽，但是有些时候，我们也需要将它改成实际的屏幕尺寸来设计一些东西。
我们可以很方便的在Xcode中改变view controller的模拟屏幕尺寸和屏幕方向：
布局约束
介绍布局约束的最好、最直观的方法就是向你们展示一个示例。
首先我们将storyboard中的屏幕布局区域的尺寸调整为iphone5s的尺寸，也就是4寸屏幕，然后添加两个正方形的view，并排放置在屏幕顶部，一个设置为蓝色，一个设置为粉色。
我们选择iPhone5s模拟器设备并编译运行应用，可以看到一蓝一粉这两个方块按照我们设定的那样杵在竖屏方向的屏幕上，没有问题。当我们把设备调整为横屏时，这两个方块像拥护党一样拥护着他们的坐标位置，所以在横屏的时候看着就不是那么完美：
这份文档是Google Java编程风格规范的完整定义。当且仅当一个Java源文件符合此文档中的规则， 我们才认为它符合Google的Java编程风格。
与其它的编程风格指南一样，这里所讨论的不仅仅是编码格式美不美观的问题， 同时也讨论一些约定及编码标准。然而，这份文档主要侧重于我们所普遍遵循的规则， 对于那些不是明确强制要求的，我们尽量避免提供意见。
在本文档中，除非另有说明：
@interface)本文档中的示例代码并不作为规范。也就是说，虽然示例代码是遵循Google编程风格，但并不意味着这是展现这些代码的唯一方式。 示例中的格式选择不应该被强制定为规则。
源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。
源文件编码格式为UTF-8。
除了行结束符序列，ASCII水平空格字符(0x20，即空格)是源文件中唯一允许出现的空白字符，这意味着：
对于具有特殊转义序列
的任何字符(\b, \t, \n, \f, \r, \“, \‘及)，我们使用它的转义序列，而不是相应的八进制(比如\012)或Unicode(比如\u000a)转义。
对于剩余的非ASCII字符，是使用实际的Unicode字符(比如∞)，还是使用等价的Unicode转义符(比如\u221e)，取决于哪个能让代码更易于阅读和理解。
Tip: 在使用Unicode转义符或是一些实际的Unicode字符时，建议做些注释给出解释，这有助于别人阅读和理解。 例如：
无论锤子还是茄子手机的不断冒出，Android系统的手机市场占有率目前来说还是最大的，因此基于Android开发的App数量也是很庞大的。 那么，如何能开发出更高性能的Android App？相信是软件开发公司以及广大程序员们头疼的一大难题。今天，就给大家提供几个提高Android App性能的技巧。
高效地利用线程
1.在后台取消一些线程中的动作
我们知道App运行过程中所有的操作都默认在主线程（UI线程）中进行的，这样App的响应速度就会受到影响。会导致程序陷入卡顿、死掉甚至会发生系统错误。
为 了加快响应速度，需要把费时的操作（比如网络请求、数据库操作或者复杂的计算）从主线程移动到一个单独的线程中。最高效的方式就是在类这一级完成 这项操作，可以使用AsyncTask或者IntentService来创建后台操作。如果选择使用IntentService，它会在需要的时候启动起 来，然后通过一个工作线程来处理请求（Intent）。
使用IntentService时需要注意以下几点限制：
从UI线程中移除费时操作这个方式还可以防止用户操作出现系统不响应（ANR）对话框。需要做的就是继承AsyncTask来创建一个后台工作线程，并实现doInBackground()方法。
还有一种方式就是自己创建一个Thread类或者HandlerThread类。需要注意这样也会使App变慢，因为默认的线程优先级和主线程的优先级是一样的，除非你明确设定线程的优先级。
3.在线程中初始化查询操作
当查询操作正在后台处理时，展示数据也不是即时的，但是你可以使用CursorLoader对象来加快速度，这个操作可以使Activity和用户之间的互动不受影响。
使用这个对象后，你的App会为ContentProvider初始化一个独立的后台线程进行查询，当查询结束后就会给调用查询的Activity返回结果。
4.其它需要注意的方面
如果应用很费电，请不要责怪用户卸载了你的应用。对于电池使用来说，主要费电情况如下：
更新数据时经常唤醒程序；
用EDGE或者3G来传递数据；
文本数据转换，进行非JIT正则表达式操作。 5.优化网络
如果没有网络连接，请让你的应用跳过网络操作；只在有网络连接并且无漫游的情况下更新数据；
选择兼容的数据格式，把含有文本数据和二进制数据的请求全部转化成二进制数据格式请求；
使用高效的转换工具，多考虑使用流式转换工具，少用树形的转换工具；
为了更快的用户体验，请减少重复访问服务器的操作；
如果可以的话，请使用framework的GZIP库来压缩文本数据以高效使用CPU资源。 6.优化应用在前端的工作
如果考虑使用wakelocks，尽量设置为最小的级别；
为了防止潜在的bug导致的电量消耗，请明确指定超时时间；
启用 android:keepScreenOn属性；
除了系统的GC操作，多考虑手动回收Java对象，比如XmlPullParserFactory和BitmapFactory。还有正则表达式的Matcher.reset(newString)操作、StringBuilder.setLength(0)操作；
要注意同步的问题，尽管在主线程中是安全的；
在Listview中要多采用重复利用策略；
如果允许的话多使用粗略的网络定位而不用GPS，对比一下GPS需要1mAh（25s * 140 mA），而一般网络只用0.1mAh（2s * 180mA）；
确保注销GPS的位置更新操作，因为这个更新操作在onPause()中也是会继续的。当所有的应用都注销了这个操作，用户可以在系统设置中重新启用GPS而不浪费电量；
请考虑在大量数理运算中使用低精度变量并在用DisplayMetrics进行DPI任务时缓存变量值； 7.优化工作在前台的应用
请确保service生命周期都是短暂的，因为每个进程都需要2MB的内存，而在前台程序需要内存时也会重新启动；
保持内存的使用量不要太大；
如果要应用每30分钟更新一次，请在设备处于唤醒状态下进行；
Service在pull或者sleep状态都是不好的，这就是为什么在服务结束时要使用AlarmManager或者配置属性stopSelf()的原因。 8.其它注意事项
在进行整体更新之前检查电池的状态和网络状态，等待最好的状态在进行大幅度装换操作；
让用户看到用电情况，比如更新周期，后台操作的时候； 实现低内存占用UI
9.找到布局显示问题
当 我们为布局单独创建UI的时候，就是在创建滥用内存的App，它在UI中会出现可恶的延时。要实现一个流畅的、低内存占用的UI，第一步就是搜索 你的应用找出潜在的瓶颈布局。使用Safe.ijiami和Android SDK/tools/中自带的Hierarchy Viewer Tool工具。
还有一个很好的工具就是Lint，它会扫描应用的源码去寻找可能存在的bug，并为控件结果进行优化。