工作学习笔记——6月

  这个月在工作中碰到的比较有意思的问题有以下几个：

1.ios代码签名机制

  没有系统学习过ios的开发，碰到keychain、证书、profile等问题时十分头大。在网上查阅了些相关信息，发现这块的东西还涉及公私钥等概念。

  按照我的理解，签名机制的作用，是保证客户机上的应用软件，确实是签名的作者写的，没有被恶意修改过。这里要用到非对称加密算法中的私钥加密、公钥解密的认证方式。可不可以使用md5等散列算法来保证软件没有被恶意修改呢？实际上就是这么干的，但是md5计算后的散列码需要使用非对称算法加密并传输。否则传输过程中md5码本身被修改了的话，这个保证就没有任何意义了。

  os x上的keychain就是用来管理公私钥的。证书则是指明签名过程中使用哪一对公私钥。Provisioning Profile这个东西则是证书、app、设备的结合体，三者都满足的话，app才能在设备上运行。

  这里只是简单谈一下自己的理解，也不一定正确。一个比较完整的，有详细操作步骤的说明可以看这里

  （译）iOS Code Signing: 解惑

   http://www.cnblogs.com/zilongshanren/archive/2011/08/30/2159086.html

2.ios retina、ipad适配

  仍然是没有系统学习的缘故，搞得想适配一下ios游戏时，也会碰到很多迷惑的概念。

  要想理解ios retina适配，一个绕不开的概念就是point vs pixel。pixel就是物理屏幕的像素数，point是ios系统特有的逻辑坐标单位。如果进行ios的native开发，程序中的坐标单位一般是point。根据设备屏幕的不同，一个point可能会对应不同的像素数（例如touch 3上两者是point:pixel=1:1，而touch4就是1:2）。这样，程序里统一用point，系统自动根据设备缩放到pixel，达到不同设备应用UI位置比例的一致性。但是如果使用缩放的方式的话，在retina屏（即point:pixel=1:2）上，图像就会因放大显得比较模糊。想达到优质的效果，就要给retina设备准备分辨率更高的图片。系统如果知道正在使用适合retina屏的图片的话，就不再进行放大，使用图片数据完全填充像素区域即可。

  那么系统如何知道使用的是高清图片呢？对于UIImage这类系统高级UI接口，系统会自动尝试使用图片名后带"@2x"的图片。但是像opengl es这种坐标系统、图片数据载入都与系统关系不大的模块来说，这种靠命名来自动适配的方式就不好使了。这时系统将选择权交给了开发者，如果开发者准备了高清纹理图片，那么开发者就要通知系统，给我准备一块够大的opengl缓冲区，我自己往上绘制高清纹理数据，你不要放大，直接用这个缓冲区的像素填充屏幕像素就好了。

  通知的方法是设置opengl所在的UIView下的contentScaleFactor属性。这个属性表示当前view里point和pixel的对应关系。如果没有准备高清纹理，那么这个值设为1.0，准备了的话就设为2.0。

  UIScreen里有个类似的属性scale，不过这个属性是系统根据设备自动设置的。系统会根据这个值以及UIView的contentScaleFactor，共同决定如何将UIView的内容映射到屏幕上去。

  对于retina屏，UIScreen::scale = 2.0，一个point对应屏幕上两个pixel，这时再看UIView的contentScaleFactor 属性：

  a.如果UIView::contentScaleFactor = 1.0，那么这个view一个point只有1个像素的内容，要映射到屏幕的话，需要放大2倍。

  b.如果UIView::contentScaleFactor = 2.0，那么这个view一个point有两个像素，直接填充到屏幕即可

  普通ipad与ipad retina之间的适配应该类似上面。但是itouch、iphone和ipad的适配却和上面没有关系。需要设置xcode的一个项目属性

Targeted Device Family，来决定ipad上面是否使用放大模式来显示itouch、iphone的app。

3.计算机时间

  在使用c库函数mktime时发现两个有意思的计算机历史问题以及几个关键时间点。

  mktime处理的有效时间范围是从1970年1月1日午夜到2038年1月18号，这两个日期之间相差的毫秒数是一个int32的正数范围（2^31），无效的日期会返回-1。2038年1月18号之后的日期可能会从1901年12月13日回卷（考虑整数的负数部分）。

  起始时间从1970年开始，据说是因为unix的兴起是在1970年代。

  mktime的输入参数是一个结构体，里面有一个字段表示年数，这个数字却是从1900年开始算的。网络上的一种说法是，这个结构体刚引入时，作者只给年数保留了两位数字的长度。为了历史兼容性的原因，变成了现在这种减去1900年的形式。

  至于多年前的千年虫讨论，跟这里貌似有一丝关系。早期的软件设计，年数也像上面那样，最初采用了两位数长度，到了2000年，正好溢出。

  mktime这类函数使用的UTC时间，仍然有溢出的bug存在，不过这个溢出时间，是在2038年。