#include<stdio.h>
int main()
{
	int h1, m1, s1;
	int h2, m2, s2;
	int a, b, c;
	scanf("%d:%d:%d", &h1, &m1, &s1);
	scanf("%d:%d:%d", &h2, &m2, &s2);
	if (h1 * 3600 + m1 * 60 + s1 < h2 * 3600 + m2 * 60 + s2)
	{
		a = h2 - h1, b = m2 - m1, c = s2 - s1;
		if (c < 0)
		{
			c = 60 + c;
			b--;
		}
		if (b < 0)
		{
			b = b + 60;
			a--;
		}
	}
	else
	{
		a = h1 - h2, b = m1 - m2, c = s1 - s2;
		if (c < 0)
		{
			c = 60 + c;
			b--;
		}
		if (b < 0)
		{
			b = b + 60;
			a--;
		}
	}
	printf("%d:%02d:%02d", a, b, c);
}

在美国连续剧<24小时>中，CTU所使用的软件系统功能极其强大，下面列出第5季中出现过的系统，由于还没有看完，有新的系统将及时补充。
实时卫星红外图像显示，并可下载到PDA，jack在煤气站用这个方法定位恐怖分子的位置，基本一枪一个搞定。 
    
可随时获取各种建筑物的结构图，并且可将纸面图纸扫描后与数据库中已有的结构图进行比对，识别出建筑物实际名称和地理位置。jack利用该系统在机场和医院等地有效地打击了恐怖分子。 
    
可监听两人的手机通话，只要知道你的手机号就可以了。从片中看是利用卫星捕获手机信号实现的。 
    
可以搜索出某人在过去一段时间内的各种行为，如什么时候在哪家宾馆开过房，在哪家咖啡馆用信用卡消费过，和谁通过几次电话、乘坐过哪家航空公司飞机等等。 
    
只要知道你机器的IP地址，就可在CTU远程登录到你的机器上获取信息，加密通常无效，可以会被下载到CTU后被解密。Handerson家的机器就被这样处理过。 
    
可以远程传送软件给手机，将手机改造为可发射特定频率的遥控器来引爆自杀性恐怖分子身上的炸弹。 
    
可利用手机发送的照片进行人脸快速识别， 不少恐怖分子就是被jack照相后被识别出身份的。 
    
如果手机的电池板没有取下，就会被用于定位你的位置，即便你手机处于关机状态。以后说不定会在手机中加一个充电电容，可在开机时充电，即便取下电池板，任然可利用电容里的电发出信号来定位。那样就只好砸手机了。：-) 
    
可以将模糊的图象变得清晰的系统，诬陷jack刺杀palmer的录象中jack的面部就是这样被认出的。 
    
芯片自燃程序，加在芯片中后芯片在使用时会自燃而毁掉里面的信息。 德国情报人员就被jack用这招忽悠了一次。 
    
可在CTU获得国防部、CIA、FBI、国土安全部的各种信息，可通过正式渠道和非正式渠道两种方式。 
    
各种密码破解系统，恐怖分子的加密信息通常都会被解密出来。 
 这些系统显然不是基于windows开发的，大概是担心windows在关键时刻的崩溃会给外勤人员带来致命的危害，不是unix就是CTU专有的操作系统。
 
 

7:30：起床。英国威斯敏斯特大学的研究人员发现，那些在早上5:22―7:21 分起床的人，其血液中有一种能引起心脏病的物质含量较高，因此，在7:21之后起床对身体健康更加有益。

打开台灯。“一醒来，就将灯打开，这样将会重新调整体内的生物钟，调整睡眠和醒来模式。”拉夫堡大学睡眠研究中心教授吉姆·霍恩说。

喝一杯水。水是身体内成千上万化学反应得以进行的必需物质。早上喝一杯清水，可以补充晚上的缺水状态。 
7:30―8:00：在早饭之前刷牙。“在早饭之前刷牙可以防止牙齿的腐蚀，因为刷牙之后，可以在牙齿外面涂上一层含氟的保护层。要么，就等早饭之后半小时再刷牙。”英国牙齿协会健康和安全研究人员戈登·沃特金斯说。 

8:00―8:30：吃早饭。“早饭必须吃，因为它可以帮助你维持血糖水平的稳定。”伦敦大学国王学院营养师凯文·威尔伦说。早饭可以吃燕麦粥等，这类食物具有较低的血糖指数。

8:30―9:00：避免运动。来自布鲁奈尔大学的研究人员发现，在早晨进行锻炼的运动员更容易感染疾病，因为免疫系统在这个时间的功能最弱。步行上班。马萨诸塞州大学医学院的研究人员发现，每天走路的人，比那些久坐不运动的人患感冒病的几率低25%。 

9:30：开始一天中最困难的工作。纽约睡眠中心的研究人员发现，大部分人在每天醒来的一两个小时内头脑最清醒。 
10:30：让眼睛离开屏幕休息一下。如果你使用电脑工作，那么每工作一小时，就让眼睛休息3分钟。 
11:00：吃点水果。这是一种解决身体血糖下降的好方法。吃一个橙子或一些红色水果，这样做能同时补充体内的铁含量和维生素C含量。 
13:00：在面包上加一些豆类蔬菜。你需要一顿可口的午餐，并且能够缓慢地释放能量。“烘烤的豆类食品富含纤维素，番茄酱可以当作是蔬菜的一部分。”维伦博士说。

14:30―15:30：午休一小会儿。雅典的一所大学研究发现，那些每天中午午休30分钟或更长时间，每周至少午休3次的人，因心脏病死亡的几率会下降37%。

16:00：喝杯酸奶。这样做可以稳定血糖水平。在每天三餐之间喝些酸牛奶，有利于心脏健康。  
17:00―19:00：锻炼身体。根据体内的生物钟，这个时间是运动的最佳时间，舍菲尔德大学运动学医生瑞沃·尼克说。 
19:30：晚餐少吃点。晚饭吃太多，会引起血糖升高，并增加消化系统的负担，影响睡眠。晚饭应该多吃蔬菜，少吃富含卡路里和蛋白质的食物。吃饭时要细嚼慢咽。

21:45：看会电视。这个时间看会儿电视放松一下，有助于睡眠，但要注意，尽量不要躺在床上看电视，这会影响睡眠质量。 
23:00：洗个热水澡。“体温的适当降低有助于放松和睡眠。”拉夫堡大学睡眠研究中心吉姆·霍恩教授说。 
23:30：上床睡觉。如果你早上7点30起床，现在入睡可以保证你享受8小时充足的睡眠。

任何试图更改生物钟的行为，都将给身体留下莫名其妙的疾病，20、30年之后再后悔，已经来不及了。


一、晚上9-11点为免疫系统（淋巴）排毒时间，此段时间应安静或听音乐。 


二、晚间11-凌晨1点，肝的排毒，需在熟睡中进行。 


三、凌晨1-3点，胆的排毒，亦同。 


四、凌晨3-5点，肺的排毒。此即为何咳嗽的人在这段时间咳得最剧烈，因排毒动作已走到肺；不应用止咳药，以免抑制废积物的排除。 


五、凌晨5-7点，大肠的排毒，应上厕所排便。 


六、凌晨7-9点，小肠大量吸收营养的时段，应吃早餐。疗病者最好早吃，在６点半前，养生者在７点半前，不吃早餐者应改变习惯，即使拖到9、10点吃都比不吃好。 


七、半夜至凌晨4点为脊椎造血时段，必须熟睡，不宜熬夜。
   另外附人体24小时生物钟
    1时：大多数人已入眠数小时,度过了睡眠的各个阶段，进入了容易催醒的浅睡阶段。此时，人对痛觉特别敏感。

　　2时：除了肝脏外，体内的大部分器官工作节律极慢。肝脏利用这段较为安静的时间正加紧把代谢后的有毒、有害物质排出体外，这仿佛清洁工正在进行全面地清洁、大扫除。

　　3时：全身休息状态，骨骼、肌肉和关节完全放松。这时人体血压很低，脉搏和呼吸的频率也 很低。

　　4时：血压处于更低的状态，脑部的供血量极少。有不少患者和体质较差的人在这个时期容易导致死亡。但处在这个时期的健康人其听觉却很灵敏，稍有响动就会惊醒。 如果此时此刻急急忙忙起身会导致头晕症状。

　　5时：肾脏停止分泌工作。此时，人们经历了浅睡和深睡的阶段，如果这时起床很快就会精神饱满。

　　6时：血压升高，心率加快。

　　7时：人体免疫系统功能持别强。此时，如遇病毒或者病菌的侵袭，最有希望被抵抗住。人体的体温调节也处在较低的状态。

　　8时：肝内的有毒、有害物质全部清除，肝脏正处于休整状态。要严禁饮酒，否则会给肝脏带 来很大的负担。

　　9时：精神活动能力很高，可是机体对痛觉的反应降低，心脏可以开足马力进行有效的工作。

　　10时：精力充沛。此时此刻是人体一天中最佳状态，也是一天中最好的工作时间 。如果这时进行健身锻炼较易收到效果。

　　11时：心脏依旧努力工作，人体不会轻易感到疲劳。

　　12时：到了全身总动员的时刻，即刻减肥效果较好 ，如果您想那么做的话最好不要马上吃午饭，而把它推迟半小时或者一小时。

　　13时：肝脏休息，有一部分糖元进入血液，血糖值略微升高 。上半天的最佳工作时间即将过去，稍感到疲倦，需要调整休息。

　　14时：这是24小时中人体第二个情绪、体力的最低点，反应迟钝。最好打个盹，"充充电"。

　　15时：人体器官最为敏感时间，特别是嗅觉。

　　16时：血液中的糖分增加，医学上称为"饭后糖尿证"，不过那是短智的，不会造成疾病。由于紧张的工作学习，血糖含量就会很快下降。

　　17时：工作效率高，积极主动性也高。对健身者来说的训练量可以适当的增加。

　　18时：痛感又重新下降，神经活性降低。
    19时：血压增高，情绪不稳定。任何小事都会引起口角。
　　20时：体重达到一天中最大值，人体反 应异常迅速。司机们此时很少驱车外出，容易发生车祸。

　　21时：人体的记忆力处于全天最好的状态，此时读书、写字的兴趣性较高。
　　22时：血液中每立方米白血球从5000增加到8000，有时甚至高达12000，进行免疫"大扫除"。体温下降。

　　23时：人体进入休息状态，进行一天的恢复、调整工作。

　　24时：一昼夜中的最后一小时，如果22时就寝，现在该已进入甜美的梦乡。

原文地址：http://blog.csdn.net/onerain88/article/details/11713299/


一、当下移动设备的主流分辨率(数据来自“腾讯分析移动设备屏幕分辨率分析报告”)
1.1 iOS设备的分辨率主要有：
 

宽
高
宽高比
960
640
1.5
1136
640
1.775
1024
768
1.3333
2048
1536
1.3333

 
Android设备的分辨率则相对纷杂，主流的分辨率有：

宽
高
宽高比
800
480
1.6667
854
480
1.7792
1280
720
1.7778
960
540
1.7778
1280
800
1.6
960
640
1.5
1184
720
1.6444
1920
1080
1.7778





二、NGUI默认的多分辨率适配原则
NGUI本身按照“高度适配”的原则进行多分辨率下的UI适配，其默认的高度通过 UIRoot.manualHeight 设置。再配合使用 UIAnchor 便可实现一定程度的多分辨率适配。
 
其中，在Unity Editor下按照 UIRoot.manualHeight 设定的高度，编辑UI页面。这样，当UI页面在目标设备上显示时，NGUI按照目标设备的高度(targetHeight)来调整UIRoot节点的scale，以使整个UI页面适应目标设备的高度。比如manualHeight=400，而targetHeight=800，那么UIRoot的scale将被乘以2。所以，当目标设备的宽高比与所编辑页面的宽高比一致时，整个UI将完美显示；当目标设备宽高比小于所编辑的宽高比时，页面宽度将大于设备宽度，使得多出的部分无法显示；而当目标设备宽高比大于所编辑宽高比时，页面宽度小于设备宽度，设备两边将出现黑边。
 
而UIAnchor则是将整个页面分为TopLeft/Top/TopRight/Left/Center/Right/BottomLeft/Bottom/BottomRight九个区域，挂载了UIAnchor组件的节点都将按照设置自动停靠到相应的区域中。有了UIAnchor，上面的两个问题将被一定程度的解决：当目标设备宽高比小于编辑的宽高比时，由于UIAnchor的自动停靠功能，UI不会被裁切掉，但UI之间的左右间距将相应变小，便有可能出现UI重叠的问题；当目标设备宽高比大于所编辑宽高比时，UI之间的左右间距将变大，好在这样起码不会有UI被裁切或重叠。
 
看似我们只需要解决UI重叠的问题就搞定了。不过让我们再仔细想一下，一张铺满整个屏幕的UISprite不管是否使用UIAnchor，在目标设备宽高比更小时，sprite都会在横向上被裁切，而将目标设备宽高比更大时，sprite都不能铺满整个屏幕。
 
问题出来了：
1. 当目标设备宽高比更小时的UI重叠问题
2. 当目标设备宽高比更小时，全屏sprite被裁切问题
3. 当目标设备宽高比更大时，全屏sprite不能铺满整个屏幕的问题
 
 
三、解决问题
首先定义几个变量：
standard_width　　编辑页面的原始宽度
standard_height　　编辑页面的原始高度
device_width　　　　目标设备的宽度
device_height　　　　目标设备的高度
standard_aspect　　编辑页面的宽高比
device_aspect　　　　目标设备的宽高比
 
1. 目标设备宽高比更小时的UI重叠问题
　　当device_aspect小于standard_aspect时，UIRoot根据device_height调整其scale大小，因而使得设备宽度不足以显示整个页面。我们调整Camera.orthographicSize(仅适用2D GUI)，以足够显示页面的宽度。令
　　Camera.orthographicSize = standard_aspect / device_aspect;
即，改变了NGUI原有的“高度适配”原则，转为“宽度适配”，使得整个页面都得以显示，而由于UIAnchor的存在，UI的左右间距保持不变，但上下间距会变大。
该方法可以实现为一个MonoBehaviour脚本(UICameraAdjustor.cs)，挂载到UICamera同一个节点上，代码如下：
 


 1 using UnityEngine;
 2 using System.Collections;
 3 
 4 /// <summary>
 5 /// 根据设备的宽高比，调整camera.orthographicSize. 以保证UI在不同分辨率(宽高比)下的自适应
 6 /// 须与UIAnchor配合使用
 7 /// 将该脚本添加到UICamera同一节点上
 8 /// </summary>
 9 
10 [RequireComponent(typeof(UICamera))]
11 public class UICameraAdjustor : MonoBehaviour
12 {
13     float standard_width = 1024f;
14     float standard_height = 600f;
15     float device_width = 0f;
16     float device_height = 0f;
17 
18     void Awake()
19     {
20         device_width = Screen.width;
21         device_height = Screen.height;
22 
23         SetCameraSize();
24     }
25 
26     private void SetCameraSize()
27     {
28         float adjustor = 0f;
29         float standard_aspect = standard_width / standard_height;
30         float device_aspect = device_width / device_height;
31 
32         if (device_aspect < standard_aspect)
33         {
34             adjustor = standard_aspect / device_aspect;
35             camera.orthographicSize = adjustor;
36         }
37     }
38 }


 

总之，在使用该方法后，当device_aspect大于standard_aspect时，UI按照高度适配原则，UI的上下间距不变，左右间距变大；当device_aspect小于standard_aspect时，UI按照宽度适配原则，UI的左右间距不变，上下间距变大。
 
2. 目标设备宽高比更小时，全屏sprite被裁切问题
　　全屏背景的sprite被裁切可能在很多情况下不会成为什么问题，但在我们使用了解决问题1中的方法后，这里的“被裁切问题”就变为了同问题3类似的“不能铺满整个屏幕问题”。解决方法是放大sprite scale:
　　sprite.transform.localScale *= ( standard_aspect / device_aspect );
这样会使得sprite在横向上被裁切，宽高比不同必然的结果... 当然也可以选择只调整高度或宽度，只要能接受变形...
 
3. 目标设备宽高比更大时，全屏sprite不能铺满整个屏幕的问题
 　　同问题2，解决方法同样是放大sprite scale:
　　sprite.transform.localScale *= ( device_aspect / standard_aspect );
这样会使得sprite在纵向上被裁切。
 
问题2和3的解决方法相应脚本(UIBackgroundAjustor.cs)会在文章后面给出。
该脚本须挂载到sprite同一节点上，配合UIAnchor使用，可以选择是裁切方向。如UIAnchor停靠方式使用center，则sprite会被左右两边或上下裁切，若使用Top，则会左右裁切或下边裁切。
总之，全屏sprite会始终铺满整个屏幕，不会出现黑边。当device_aspect大于standard_aspect时，全屏sprite按照宽度适配，纵向裁切；当device_aspect小于standard_aspect时，按照高度适配，横向裁切。
 
四、优化
1. UI页面的制作尺寸按 1024 X 600
　　前面讲到主流分辨率的情况，其平均宽高比(除ipad2/3/4以外)大概为1.7，与主流的宽高比都不会偏差很大。即，在使用上面的多分辨率解决方法时，UI不会在纵向或横向上的间距过大，显得特别离谱。按照此宽高比，我们选择1024x600的尺寸来制作UI，并严格要求UI制作时，页面分为TopLeft/Top/TopRight/Left/Center/Right/BottomLeft/Bottom/BottomRight九个区域，以便挂载UIAnchor。
 
2. 全屏背景的制作按 1024 X 768
　　如果全屏背景图也按1024 x 600制作，在ipad2/3/4上就会有较大程度的放大。同时考虑到NGUI的打包atlas，使用2的幂次尺寸，高度600和768都将占用1024x1024的atlas。所以全屏背景在制作时，高度上做出一定的冗余尺寸，以使宽高比小于1.7时，高度上放大系数不会太大，避免图片严重失真。
　　加入冗余尺寸后的脚本(UIBackgroundAjustor.cs)如下：




 1 using UnityEngine;
 2 using System.Collections;
 3 
 4 /// <summary>
 5 /// 根据设备的宽高比，调整UISprite scale, 以保证全屏的背景图在不同分辨率(宽高比)下的自适应
 6 /// 将该脚本添加到UISprite同一节点上
 7 /// 须与UICameraAdjustor脚本配合使用
 8 /// </summary>
 9 
10 [RequireComponent(typeof(UISprite))]
11 public class UIBackgroundAdjustor : MonoBehaviour
12 {
13     float standard_width = 1024f;
14     float standard_height = 600f;
15     float device_width = 0f;
16     float device_height = 0f;
17 
18     void Awake()
19     {
20         device_width = Screen.width;
21         device_height = Screen.height;
22 
23         SetBackgroundSize();
24     }
25 
26     private void SetBackgroundSize()
27     {
28         UISprite m_back_sprite = GetComponent<UISprite>();
29 
30         if (m_back_sprite != null && UISprite.Type.Simple == m_back_sprite.type)
31         {
32             m_back_sprite.MakePixelPerfect();
33             float back_width = m_back_sprite.transform.localScale.x;
34             float back_height = m_back_sprite.transform.localScale.y;
35 
36             float standard_aspect = standard_width / standard_height;
37             float device_aspect = device_width / device_height;
38             float extend_aspect = 0f;
39             float scale = 0f;
40 
41             if (device_aspect > standard_aspect) //按宽度适配
42             {
43                 scale = device_aspect / standard_aspect;
44 
45                 extend_aspect = back_width / standard_width;
46             }
47             else //按高度适配
48             {
49                 scale = standard_aspect / device_aspect;
50 
51                 extend_aspect = back_height / standard_height;
52             }
53 
54             if (extend_aspect >= scale) //冗余尺寸足以适配，无须放大
55             {
56             }
57             else //冗余尺寸不足以适配，在此基础上放大
58             {
59                 scale /= extend_aspect;
60                 m_back_sprite.transform.localScale *= scale;
61             }
62         }
63     }
64 }


另外一个说法



NGUI在Unity3D游戏开发中非常常用，而NGUI对于每一个UI场景，都是以一个UIRoot为UI游戏对象树的根的，那么这个UIRoot是起什么作用的呢？

先简单看一下UIRoot中的基本属性



UIRoot游戏对象的属性只有4个，分别是缩放规则，手动高度，最小高度和最大高度

而正是这4个属性，将影响整个UI场景中整体的缩放比例，当设置好这4个属性之后，UIRoot游戏对象的相对缩放值(LocalScale)将会生成并且不能被直接修改（NGUI中很多属性都是不能直接被修改的，这种控制是在UIRoot脚本中，通过设置[ExecuteInEditMode]做到的，其相对缩放值是根据UIRoot的4个属性计算出来的），那么这4个属性分别是什么含义呢？

（吐槽一下，也许这里的用户体验并不足够友好，因为Manual Height和Minimum Height, Maximum Height并不会同时起作用，如果能做到在选择Scaling Style时动态的切换，使用者也许能更清楚它们之间的关系）



1.Scaling Style (缩放类型)

这是一个简单的枚举变量，包括三个枚举值



[csharp] view
 plaincopyprint?





public enum Scaling  

    {  

        PixelPerfect,  

        FixedSize,  

        FixedSizeOnMobiles,  

    }  
（FixedSize和FixedSizeOnMobiles类似，并且后者只添加了对ios和android平台的判断，所以前者可以替代后者使用）



这里只讨论PixelPerfect和FixedSize的区别，两者都是针对于所有在此UIRoot之下的UI组件而言的，也可以认为是在此UIRoot下，整个游戏屏幕的尺寸的缩放类型！



2.Manual Height和Minimum Height, Maximum Height (手动高度和最小高度，最大高度)

Manual Height和Minimum Height, Maximum Height不会同时对此UIRoot起作用，当选择Scaling Style为PixelPerfect时，我们需要设置Minimum Height, Maximum Height；而当Scaling Style为FixedSize或FixedSizeOnMobiles时，我们需要设置Manual Height。（这就是我前面吐槽的原因）



3.使用
（1）PexelPerfect和Minimum Height, Maximum Height

这个组合主要用于我们期望所有的UI纹理都“尽量”不进行缩放，所谓“尽量”的程度，则是取决于Minimum Height和Maximum Height，Minimum Height表示当设备分别率小于此设置值时，根据此设置值对UIRoot进行缩放；Maximum Height表示当设备分辨率大于此设置值时，根据此设置值对UIRoot进行缩放（UIRoot是UI游戏对象树的根，修改UIRoot的缩放，则会影响整棵UI树的缩放）
（2）FixedSize和Manul Height

这个组合主要用于我们期望所有的UI纹理都进行“合适”的缩放，所谓“合适”缩放的原则，则是根据Manual Height设置值，当设备分辨率的高度值不同于此设置值时，则根据其比例（即Manual Height / Screen Height）对整棵UI树的进行“等比”缩放（宽度的缩放比也是此比例值），这样，我们就可以做一套资源，在不同尺寸的分辨率最好的“不变形”的适配了
（3）交集

前面两组在什么情况下等同呢？

Manual Height == Minimum Height == Maximum Height 

推导过程，呵呵~~

具体可参考UIRoot中activeHeight属性和GetPixelSizeAdjustment的计算过程



4.这也许并不够

基于以上推到，当我们以1024x768为标准分辨率做一套UI资源（也就是选择FixedSize并且Manual Height=768），似乎可以满足百分之90以上的机型了，而为什么是1024x768呢？

既然我们已经容忍在除1024x768之外的其他设备上进行等比缩放了，那为什么不是960x640呢？

计算一下1024x768的宽高比=1.33，960x640的宽高比=1.5，这就是移动设备的分辨率比例的全部了吗？

当然不是，iphone5的比例就要大于1.5，还有各种奇葩的android设备呢，比如夏新的n828就是960x540，宽高比=1.78

那为什么以1024x768为标准呢？

因为1.33的宽高比，当我们的1024x768的资源到960x640的设备上时会有什么现象？

根据Manual Height / Screen Height的比例可知，我们需要缩放768 / 640 = 1.2倍，假设是一张1024x768的纹理，高度缩放1.2倍变为了640，宽度也要相应缩放1.2倍变为853（保证等比缩放不变形），也就是说1024x768的资源放到960x640上反而两边有了黑边，这是我们可以容忍的，我们可以做一个很大的背景或者拉伸，保证UI组件不变形即可，很多游戏都是这么做的，比如植物大战僵尸在iphone5和ipad上看到的背景视野并不一样大！

当放到夏新的机器上呢？

我们需要缩放768 / 540 = 1.4倍，宽度1024 / 1.4 = 731，这是可以的，只是看起来更怪一些，因为两边的黑边相对比例更大了（960 - 731=229的黑边区域）

而我表示android机器的分辨率奇葩到只有想不到，没有做不到的程度，也许宽高比1.7并不是终点，当遇到1.8之后，黑边的相对比例会更大。。。



5.问题又来了

假设我们的游戏类型更适合iphone手机玩，不太适合ipad，所以我希望能以960x640为标准做一套资源，可以吗？

我只能说不太可以，因为你要在设计UI组件的大小做限制了，为什么需要做限制？

假设我有一张纹理是960x640大小的，在iphone上铺满整屏，根据我们的设置（FixedSize和Manual Height=640），拿到1024x768的分辨率上，高度640 / 768 = 0.83，为了保证等比缩放，宽度960 / 0.83 = 1156，不幸的事情发生了，1156 > 1024，这个UI组件宽度超过了屏幕的宽度，被裁剪了。。。这是我们不能容忍的，或许你可以说我们尽量不做这种尺寸的UI，OK，你可以对UI尺寸加限制，但是当面对android那些奇葩的分辨率的时候，你会发现限制越来越大，这也许会让美术和策划疯掉！



6.解决方案

当我们花上一些时间去观察现在移动设备的分辨率时，虽然奇葩很多，但是还是有一些规律的，规律的在于宽高比而不在于具体尺寸，大体上划分一下宽高比在1.3,1.5,1.7的范围上的居多（基本是全部吧！）即便是再有1.2,1.8的比例也无妨。。。

NGUI为我们提供的方案只有以各种高度为衡量标准是不够的，我们应该加上一种以宽度为衡量标准的缩放类型

而对于UI资源的标准，我们选取960x640，宽高比为1.5

这样，当我们在兼容大于1.5的尺寸的时候，使用NGUI的现有方案；当我们在兼容小于1.5的尺寸的时候，使用以宽度为衡量标准

也就是说有一个类似Manual Width的属性，当小于1.5时，我们使用Manual Width / Screen Width得出整棵UI树的缩放比例！

这样做的好处是“黑边”区域不会太大，并且不需要对UI组件的大小做限制！