范佩西的头球，老罗的速度，我这个伪球迷也被震撼了!

Fragment在android的设计中变得越来越重要，它比Activity轻量，又具有自己的生存周期，加上默认的Fragment的backstack的支持，使的Fragment使用起来十分得心应手。

MVC模式是Mobile app遵循的基本设计模式，Model负责数据的表示，View负责数据的显示，Controller负责协调Model和View之间的工作。在Mobile App中，每一屏一般就是一个MVC，而具体到Android中，Fragment可以允许我们很好地将每一屏的逻辑包含在内，它负责内容（View）的生成，协调View和Model间的协作，基本上就是MVC中Controller的逻辑。下面情况 我们都可以用fragment：

• 界面的分屏显示，每一屏都是一个fragment来表示
• 与ViewPager配合使用，每一个page都作为一个Fragment来表示
• 在tablet上的布局中，对master-detail模式的app，导航与具体的信息显示可以由不同的fragment来表示。
• 在Navigation Drawer导航模式中，每一个导航都推荐设计为一个fragment

在Android4.2之前，Fragment不支持嵌套的布局，就是说Fragment内部不能再有子Fragment。在使用viewpager与fragment结合的时候，我们可以发现，如果viewpager放在一个fragment当中，而viewpager当中的每一个page又以一个fragment来实现，那么内部的fragment（每一个page）的生命周期就会发生混乱。

在Android4.2之后，系统添加了推nested Fragment的支持。如果要兼容之前的版本，建议使用Support Library v4。

好记性不如烂笔头，just for mark。

这一周在iOS开发者之间讨论的最多的话题应该就是apple在WWDC 2014上推出的Swift语言了，微博上充斥着各种对swift语言的讨论，更多的是很快的出现了很多swift语言的学习教程、示例。Swift一出来就这么火是必然的，不仅仅因为它是由Apple推出的语言，更多的是他会影响iOS和OSX开发者今后的工作：

• 对于大部分现有的app而言，Objc仍然会是主要的开发语言，但是或许在项目中我们需要引入Swift的一些元素，因此在未来一段时间内iOS和OSX的开发人员不得不同时融汇贯通两种语言。
• 对于新的iOS和OSX项目，会有不少开发者直接采用swift语言，毕竟现在看来，Swift是apple今后的方向。

从上面两点就可以看出，我们确实需要去学习Swift，今后在工作中必然会用到。但是我觉得我们需要理性的去看待一件新事物。

长久以来Android给人们的印象都是反应速度慢，不够流畅，这也是我之前对android的印象，在接触了Android4.4、从事了android的开发后，我觉得Android之所以给人们不够流畅的原因有以下几点：

• 与iOS不同的是，Android手机型号众多，配置更是各种各样，以我之前用的HTC手机为例，2012年出厂的手机装配了Android4.0的系统，但是系统的内存却只有512M，开机后app的可用内存只有可怜的360M，这种配置的手机怎么可能有好的表现，不卡才怪。而iOS的手机型号固定，配置起码都是1G的内存，运行流畅是必然的。
• Android市场对app的审核不如iOS严格，致使Android App的质量良莠不齐，很多开发者并没有对app进行足够的性能优化，成功如微博客户端，在滑动的时候仍不够流畅，其他的app质量可想而知。
• 最根本的一点是，Dalvik虚拟机在作怪。

大家都知道，Java为了达到跨平台的目的，在编译时将源代码转化为了字节码，Android的Dalvik虚拟机亦是如此，在我们运行app时，系统必须将字节码转换为机器码，然后运行，这种机制就是Dalvik使用的JIT（Just-in-time compilation）机制。在运行时才将字节码转化为机器码，这可以说是android app不够流畅的根本原因，因为我们无法消除将字节码转化为机器码的这部分时间。

Android4.4引入了ART，即Android Runtime，与Dalvik不同的是，ART在我们第一次安装app时，会自动将app转化为机器码，从而确保了app运行时的时间（去除了JIT compile的时间），因此开启ART后，android app流畅度会有一个不错的提升。但是目前，ART有如下问题：

• 某些app在ART下无法运行。这应该是针对一小部分app，因为我目前为止在我的手机上没有发现这个问题
• 由于在首次安装时需要将app转化为机器码，因此app的安装时间会有所增加。我在使用过程中也没有明显的感觉到这一点，可以说这点不会妨碍一般的用户。

可以说ART很好的解决了android不够流畅的问题，并且对于普通用户，并没有带来使用的负面影响，况且现在ART还在进一步的改进和开发当中，相信以后在流畅度，安装时间等各个方面会做的更好。 对于我们开发者，ART也带来了实际的好处。

相信很多开发者会遇到一个问题，就是在Android中，如果你的ViewGroup嵌套层次太多，那么很可能会遇到StackOverflowError这个运行时错误，产生这个错误的原因是由于View Hierarchy在绘制过程中，函数调用的深度超出了系统主线程的Stack frame。在Android4.4中，Dalvik的UI线程的Stack frame只有16K，过多的嵌套很容易造成StackOverflowError，而对于程序，很难从根本上解决这个问题（优化view hierarchy被认为是唯一可行的方法，但实用性却是有限的）。我在试验中发现，ART已经很好的解决了这个问题，即使view group的嵌套达到了60层，仍然不会出现在Dalvik中的crash。

由此可见，ART正在试图解决一些Dalvik中存在的性能等各个方面的问题，或许Android5.0的时候，ART能够成型，那Android必然会向前迈一大步，用户体验可以得到很大的改观（当然像之前说的HTC的那种奇葩配置的机器，永远不可能有好的流畅度）。

由于Android生态的多样性，各个生产商的Android都有很大的不同，我们应该通过比较来区分优劣，Android有自己的特点，包括Android App的设计原则都不同于iOS，作为Android用户，我们需要的不是iOS，而是Android自己的个性，Android的特色。越来越对Android充满信心，相信Android很快可以做的更好。

一直用公司的MAC开发Android，在将Nexus5连接到自己的Windows上时，发现ADT中无法找到Nexus5，adb devices命令也无法检测到设备，虽然设备能够以磁盘的方式显示在Windows Explorer中，但是似乎设备的驱动仍然没有正确的安装：

• 打开windows 设备管理器可以发现，Nexus5设备标识上有一黄色叹号，表示驱动没有正确安装
• 下载Nexus5 设备驱动，并解压至某一目录
• 在设备管理器中，右键点击设备，并更新驱动
• 选中刚才解压的目录，即可正确的安装驱动

Issue Fixed ：）

计算机应用可以说是少数国内与国外技术差别比较小的领域，主要原因是网络的帮助，使我们很方便的看到国外的技术文档与很多优秀的文章，但是很多时候国内的环境确实令人非常气愤，居然Android SDK网站都会被墙，以至于Android SDK Manager根本无法下载。解决方法是安装并打开goagent，并将SDK Manager的Proxy设置为127.0.0.1:8087。如果不知道goagent的话，那就好好搜索一下吧，国内的环境，基本上这个是必备的了。this is for test

C++11给我们提供了很多新的特性，相比于C++98，C++11在很多地方使用起来更加顺手，很多新的特性让C++变得更加让人喜欢，对编码人员更加友好，很多规则更加统一。在这些新的特性当中，有很多高级特性，比如关于模板的特性（个人真的很少在开发中用到）；也有很多确确实实方便了开发，而且使c++代码更加整洁、安全、快速的特性。在学习中总结一下，往往可以在使用过程中更加得心应手。

auto

c++11中auto关键字和c++98中有完全的不同，在c++11中，如果我们把变量声明为auto，那么编译器会自动根据上下文推断出变量的类型，因此在很多情况下，特别是类型比较长的时候，我们可以使用auto来使代码更加整洁：

1
2
3
4

vector<String> vec;
.....

auto iter = begin(v);//get iterator of vector,do not need to use vector<String>::iterator

1
2
3
4
5

	template<class T, class U> 
void multiply(const vector<T>& vt, const vector<U>& vu)
{
	auto tmp = vt[i]*vu[i];//here it's hard to decide type of tmp, auto saves us a lot
}

用户体验是用户在使用一款软件和系统时，对软件和系统能得到的最直观的感受，iOS一直因为良好的用户体验而受到大家的赞赏，流畅的操作和丰富的动画无疑给iOS的用户体验加了不少分。对于我们编程人员来说，iOS中提供了强大的Core Animation库，并封装了友好的API，使我们能够实现复杂的动画效果。

Core Animation提供了两种动画的类型，并封装成类CABasicAnimation和CAKeyframeAnimation，我们需要针对自己的目标来选择使用这两种类。动画的实现过程实际上就是在一定时间内连续播放一系列的视频帧，在iOS中要求60帧/秒，通常情况下，我们实现动画的做法是给出动画在一定时间内的关键帧，然后利用差值的方法得到关键帧之间的所有帧序列的状态。CABasicAnimation 和 CAKeyframeAnimation的最大区别就是

CABasicAnimation要求我们只能提供动画的第一帧和最后一帧，然后系统利用我们指定的插值方法，计算出整个动画的所有序列；
 而利用CAKeyframeAnimation我们可以给出动画过程中的多个关键帧，然后同样系统利用我们制定的插值方法，计算出连续的两个关键帧之间的所有序列，从而实现动画。 
 可以看到，利用CAKeyframeAnimation，我们对动画有更多的控制权，因此大多数比较复杂的动画也需要选用CAKeyframeAnimation。

我在demo中实现了两种动画效果，动画并不算复杂，但是却能很好的了解这两种动画类的使用，并且由于动画是作用在CALayer之上，因此CALayer的相关知识也是我们能够正确的使用Core Animation的基础，在例子中你也可以看到一些CALayer的属性，如anchor point，transform等是如何使用的。demo的效果如下：

作为一种面向对象的编程语言，类是我们使用C++时频繁使用的单位，由于C++语言的某些特性，与java、Objectivec等语言相比，C++在对多态的实现上有一些不同。java与ObjectiveC是通过runtime来实现多态的，即系统在运行时根据对象的类型来决定，而C++是通过编译时对象的类型来决定调用的函数（C++中的多态是通过指针与virtual 函数来是实现的）。我们先通过例子来看C++与ObjectiveC在多态方面的不同。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

//base class
@interface Shape : NSObject
- (void)draw;
@end

@implementation Shape
- (void)draw
{
    NSLog(@"Shape Draw");
}
@end

//derived class
@interface Rectangle : Shape
@end
@implementation Rectangle
- (void)draw
{
    NSLog(@"Rectangle Draw");
}
@end

//test
Shape* s = [[Shape alloc] init];
[s draw];//will call draw defined in shape
Shape* r = [[Rectangle alloc] init];
[r draw];//will call draw definied in rectangle

对应的类在C++中定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#include<iostream>
class Shape
{
public:
	Shape();
	~Shape();
	void draw(){ std::cout<<"Shape Draw"; }
};

class Rectangle :public Shape
{
public:
	void draw(){ std::cout << "Rectangle Draw"; }
};

//test
	Shape* s = new Shape;
	s->draw();//will call draw definied by Shape
	Shape* r = new Rectangle;
	r->draw();//will also call draw defined by Shape

这个例子可以看出来，在C++中，如果函数没有被声明为Virtual，那么通过指针是无法实现多态的。这种机制，带来了代码运行的效率，但是却给我们编码人员提出了更大的要求，我们不能单纯的凭感觉使用c++，使用c++需要我们同时进行思考，将一些必须考虑的内容时刻放在脑子里。

在移动App开发中，用户体验是我们在开发过程中必须考虑的问题，实时的相应用户的交互事件，是对一个App最基本的要求，因此程序的并行就显得尤其重要，因此在iOS中，程序的并行并不仅仅是为了加快某些操作的速度，更重要的我们是为了不要阻塞用户在主线程上的交互。iOS提供给我们不同级别的并行的接口，包括NSThread、Grand Central Dispatch（GCD）和NSOperationQueue，来满足我们在不同情形下的需要。

不同的api使用的复杂程度也不同，GCD和NSOperationQueue是建立在NSThread的基础之上，提供给了我们更加高层次的抽象，因此在使用中，我们应该尽量的使用GCD与NSOperationQueu，主要有一下原因：

• GCD和NSOperationQueue提供给了我们更加友好的接口，使用起来更加方便灵活
• GCD和NSOperationQueue仍然是以NSThread为基础来实现的，他们的本质是在系统中维护了一个线程池。当我们放入其中的任务被运行时，运行的单位仍然是线程池中的线程
• GCD和NSOperationQueue可以根据系统当前的繁忙状态来决定线程池中可以并发的线程数，这样可以防止过多的线程同时并发，导致系统性能的下降。

这里我主要是总结一下并行库的一些知识，还有一个小的Demo，展示了api的基本用法。

GCD是iOS提供的比较便捷的并行api，我们可以很方便的将包含我们操作的block放在GCD的dispatch queue当中，然后任务就会在线程池中运行。iOS提供给了我们五中不同优先级的dispatch queue，三种不同优先级的背景队列,主线程对应的main queue，以及一个用户IO 操作的背景队列。我们也可以通过系统提供的接口，自己创建新的dispatch queue。

源代码经过编译、连接转化为机器码，在运行时又由runtime加载入内存，因此编译器、连接器和runtime在某种程度上说是协同工作的。在编译过程中，编译器会首先将源代码中的每一个类转换为汇编代码，每一个类的不同的变量，方法等都会被放在汇编代码的不同段当中，然后再将汇编代码转化为机器语言即二进制。为了确保runtime能够对程序进行解析加载，编译器和runtime之间必须有某种约定，以实现runtime对类信息的加载。
例如对于如下的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#import <objc/Object.h>

@interface MySuperClass: Object {

}
-(void) myMessage1;
@end

@implementation MySuperClass
-(void) myMessage1 {

}
@end

@interface MyClass: MySuperClass {

}
-(void) myMessage2;
@end

@implementation MyClass
-(void) myMessage2 {

}
@end

int main() {

    return 0;
}