viewui源码编译

⑴ android UI绘制之View绘制的工作原理

这是AndroidUI绘制流程分析的第二篇文章，主要分析界面中View是如何绘制到界面上的具体过程。

ViewRoot 对应于 ViewRootImpl 类，它是连接 WindowManager 和 DecorView 的纽带，View的三大流程均是通过 ViewRoot 来完成的。在 ActivityThread 中，当 Activity 对象被创建完毕后，会将 DecorView 添加到 Window 中,同时会创建 ViewRootImpl 对象，并将 ViewRootImpl 对象和 DecorView 建立关联。

measure 过程决定了 View 的宽/高， Measure 完成以后，可以通过 getMeasuredWidth 和 getMeasuredHeight 方法来获取 View 测量后的宽/高，在几乎所有的情况下，它等同于View的最终的宽/高，但是特殊情况除外。 Layout 过程决定了 View 的四个顶点的坐标和实际的宽/高，完成以后，可以通过 getTop、getBottom、getLeft 和 getRight 来拿到View的四个顶点的位置，可以通过 getWidth 和 getHeight 方法拿到View的最终宽/高。 Draw 过程决定了 View 的显示，只有 draw 方法完成后 View 的内容才能呈现在屏幕上。

DecorView 作为顶级 View ，一般情况下，它内部会包含一个竖直方向的 LinearLayout ，在这个 LinearLayout 里面有上下两个部分，上面是标题栏，下面是内容栏。在Activity中，我们通过 setContentView 所设置的布局文件其实就是被加到内容栏中的，而内容栏id为 content 。可以通过下面方法得到 content:ViewGroup content = findViewById(R.android.id.content) 。通过 content.getChildAt(0) 可以得到设置的 view 。 DecorView 其实是一个 FrameLayout , View 层的事件都先经过 DecorView ，然后才传递给我们的 View 。

MeasureSpec 代表一个32位的int值，高2位代表 SpecMode ,低30位代表 SpecSize , SpecMode 是指测量模式，而 SpecSize 是指在某种测量模式下的规格大小。
SpecMode 有三类，如下所示：

UNSPECIFIED

EXACTLY

AT_MOST

LayoutParams需要和父容器一起才能决定View的MeasureSpec，从而进一步决定View的宽/高。

对于顶级View，即DecorView和普通View来说，MeasureSpec的转换过程略有不同。对于DecorView，其MeasureSpec由窗口的尺寸和其自身的LayoutParams共同确定；

对于普通View，其MeasureSpec由父容器的MeasureSpec和自身的Layoutparams共同决定；

MeasureSpec一旦确定，onMeasure就可以确定View的测量宽/高。

小结一下

当子 View 的宽高采用 wrap_content 时，不管父容器的模式是精确模式还是最大模式，子 View 的模式总是最大模式+父容器的剩余空间。

View 的工作流程主要是指 measure 、 layout 、 draw 三大流程，即测量、布局、绘制。其中 measure 确定 View 的测量宽/高， layout 确定 view 的最终宽/高和四个顶点的位置，而 draw 则将 View 绘制在屏幕上。

measure 过程要分情况，如果只是一个原始的 view ，则通过 measure 方法就完成了其测量过程，如果是一个 ViewGroup ，除了完成自己的测量过程外，还会遍历调用所有子元素的 measure 方法，各个子元素再递归去执行这个流程。

如果是一个原始的 View，那么通过 measure 方法就完成了测量过程，在 measure 方法中会去调用 View 的 onMeasure 方法，View 类里面定义了 onMeasure 方法的默认实现:

先看一下 getSuggestedMinimumWidth 和 getSuggestedMinimumHeight 方法的源码：

可以看到， getMinimumWidth 方法获取的是 Drawable 的原始宽度。如果存在原始宽度（即满足 intrinsicWidth > 0），那么直接返回原始宽度即可；如果不存在原始宽度（即不满足 intrinsicWidth > 0），那么就返回 0。

接着看最重要的 getDefaultSize 方法：

如果 specMode 为 MeasureSpec.UNSPECIFIED 即未指定模式，那么返回由方法参数传递过来的尺寸作为 View 的测量宽度和高度；
如果 specMode 不是 MeasureSpec.UNSPECIFIED 即是最大模式或者精确模式，那么返回从 measureSpec 中取出的 specSize 作为 View 测量后的宽度和高度。

看一下刚才的表格：

当 specMode 为 EXACTLY 或者 AT_MOST 时，View 的布局参数为 wrap_content 或者 match_parent 时，给 View 的 specSize 都是 parentSize 。这会比建议的最小宽高要大。这是不符合我们的预期的。因为我们给 View 设置 wrap_content 是希望View的大小刚好可以包裹它的内容。

因此：

如果是一个 ViewGroup，除了完成自己的 measure 过程以外，还会遍历去调用所有子元素的 measure 方法，各个子元素再递归去执行 measure 过程。

ViewGroup 并没有重写 View 的 onMeasure 方法，但是它提供了 measureChildren、measureChild、measureChildWithMargins 这几个方法专门用于测量子元素。

如果是 View 的话，那么在它的 layout 方法中就确定了自身的位置（具体来说是通过 setFrame 方法来设定 View 的四个顶点的位置，即初始化 mLeft ， mRight ， mTop ， mBottom 这四个值）， layout 过程就结束了。

如果是 ViewGroup 的话，那么在它的 layout 方法中只是确定了 ViewGroup 自身的位置，要确定子元素的位置，就需要重写 onLayout 方法；在 onLayout 方法中，会调用子元素的 layout 方法，子元素在它的 layout 方法中确定自己的位置，这样一层一层地传递下去完成整个 View 树的 layout 过程。

layout 方法的作用是确定 View 本身的位置，即设定 View 的四个顶点的位置，这样就确定了 View 在父容器中的位置；
onLayout 方法的作用是父容器确定子元素的位置，这个方法在 View 中是空实现，因为 View 没有子元素了，在 ViewGroup 中则进行抽象化，它的子类必须实现这个方法。

1.绘制背景（ background.draw(canvas); ）；
2.绘制自己（ onDraw ）；
3.绘制 children（ dispatchDraw(canvas) ）；
4.绘制装饰（ onDrawScrollBars ）。

dispatchDraw 方法的调用是在 onDraw 方法之后，也就是说，总是先绘制自己再绘制子 View 。

对于 View 类来说， dispatchDraw 方法是空实现的，对于 ViewGroup 类来说， dispatchDraw 方法是有具体实现的。

通过 dispatchDraw 来传递的。 dispatchDraw 会遍历调用子元素的 draw 方法，如此 draw 事件就一层一层传递了下去。dispatchDraw 在 View 类中是空实现的，在 ViewGroup 类中是真正实现的。

如果一个 View 不需要绘制任何内容，那么就设置这个标记为 true，系统会进行进一步的优化。

当创建的自定义控件继承于 ViewGroup 并且不具备绘制功能时，就可以开启这个标记，便于系统进行后续的优化；当明确知道一个 ViewGroup 需要通过 onDraw 绘制内容时，需要关闭这个标记。

参考：《Android开发艺术探索》

⑵ uilayoutcontainerview 怎么用代码实现

写协议，用代理
或者在childcontroller里写Notification
关键是container里的viewcontroller不是用代码生成的，而是在storyboard里通过segue连接起来的，因此设置委托的时候对象也不是同一个。
如果childcontroller在父类里有实例，用KVO也可以监测值的变化
var newController = self.storyboard?.("RegisterController") as! RegisterController
let oldController = childViewControllers.last as! UIViewController

oldController.(nil)
addChildViewController(newController)
newController.view.frame = oldController.view.frame

//isAnimating = true
transitionFromViewController(oldController, toViewController: newController, ration: 0.1, options: UIViewAnimationOptions.TransitionNone, animations: nil, completion: { (finished) -> Void in
oldController.()
newController.didMoveToParentViewController(self)
//self.isAnimating = false
})

⑶ 如何纯代码给UICollectionView添加HeaderView和FooterView

collectionView和table基本用法一样但是header和footer，就找不到方法了
自己找了好久网上也没个人写的就一个写的是用storyBoard写的 对于纯代码的可能不怎么太理解。
自己摸索的做出来了。下面纯代码的步骤：<语文水平渣 没什么文采，但是技术点肯定会说明白的>
如果要给你的collectionView添加header和footer，他的数据源和代理是没有直接提供创建方法的，但是提供了一个两用的方法
[objc] view plain
<span style="font-size:14px;">- (UICollectionReusableView *)collectionView:(UICollectionView *)collectionView :(NSString *)kind atIndexPath:(NSIndexPath *)indexPath
</span>
如果要给你的collectionView添加header和footer步骤<本文只以header为例>
1.设置流水布局 ，需要在流水布局里设置header和footer的size
[objc] view plain
- (id)init
{
// UICollectionViewLayout;
UICollectionViewFlowLayout *flow = [[UICollectionViewFlowLayout alloc] init]; // 流水布局
[objc] view plain
[objc] view plain
<span style="white-space:pre"> </span>// 设置header的Size
<span style="color:#ff6666;"> flow.headerReferenceSize = CGSizeMake(320, 44);</span>
[objc] view plain
// 设置格子的宽高
flow.itemSize = CGSizeMake(75, 61);
// 设置列距
flow.minimumInteritemSpacing = 5;
// 设置行距离
// flow.minimumLineSpacing = 0;
// 设置整体内容和四周的边距
// top left bottom right
flow.sectionInset = UIEdgeInsetsMake(20, 2, 0, 2);
return [super initWithCollectionViewLayout:flow];
}
2. 创建UICollectionReusableView的子类UICollectionHeaderView，并创建其xib 设置xib的identifier为header
[objc] view plain
<span style="font-size:14px;">#import <UIKit/UIKit.h>
@interface UICollectionHeaderView : UICollectionReusableView
@end
</span>
3.在xib中添加你需要显示的控件，不要忘了class继承UICollectionHeaderView。
4.在collectionViewController 的viewDidLoad注册xib，方法和注册cell差不多 只不过方法名不一样
[objc] view plain
<span style="font-size:14px;">UINib *nib = [UINib nibWithNibName:@"WdViewCell" bundle:nil] ;
[self.collectionView registerNib:nib forCellWithReuseIdentifier:@"cell"];
[self.collectionView setBackgroundColor:[UIColor colorWithRed:240 green:240 blue:240 alpha:0.8]];
</span>
[objc] view plain
<span style="font-size:14px;">// 注册header的
UINib *header = [UINib nibWithNibName:@"UICollectionHeaderView" bundle:nil];
[self.collectionView registerNib:header forSupplementaryViewOfKind:<span style="color:#ff6666;"></span> withReuseIdentifier:@"header"];</span>
5.显示header
这个方法：kind标识你是header还是footer<可能还有其他的>header:,用个判断或者switch就可以选择你要显示什么类容了，创建header view的方法
[objc] view plain
<span style="font-size:14px;">// 设置每组的标题
- (UICollectionReusableView *)collectionView:(UICollectionView *)collectionView :(NSString *)kind atIndexPath:(NSIndexPath *)indexPath
{
if (kind == ) {
UICollectionHeaderView *headerView = [collectionView :kind withReuseIdentifier:@"header" forIndexPath:indexPath];
</span>
[objc] view plain
<span style="font-size:14px;">// 在这就可以设置header中子控件的数据了</span>
[objc] view plain
<span style="font-size:14px;"> return headerView;
}
else
{
return nil;
}
}</span>
这样就可以显示你的header了

⑷ 如何纯代码给UICollectionView添加HeaderView

UICollectionView主要用于瀑布流，由于一直接触较少，每次需要使用的时候都从网上翻阅资料，此次自己总结整理，以备不时之需。

collectionView和tableView最大的不同之处就是需要自定义cell,所以第一步自定义collectionViewCell

.h文件

#import <UIKit/UIKit.h>

@interface MyCollectionViewCell : UICollectionViewCell

@property (strong, nonatomic) UIImageView *topImage;

@property (strong, nonatomic) UILabel *botlabel;

@end

.m文件

#import "MyCollectionViewCell.h"

@implementation MyCollectionViewCell

- (id)initWithFrame:(CGRect)frame

{

self = [super initWithFrame:frame];

if (self)

{

_topImage = [[UIImageView alloc] initWithFrame:CGRectMake(10, 0, 70, 70)];

_topImage.backgroundColor = [UIColor redColor];

[self.contentView addSubview:_topImage];

_botlabel = [[UILabel alloc] initWithFrame:CGRectMake(10, 80, 70, 30)];

_botlabel.textAlignment = NSTextAlignmentCenter;

_botlabel.textColor = [UIColor blueColor];

_botlabel.font = [UIFont systemFontOfSize:15];

_botlabel.backgroundColor = [UIColor purpleColor];

[self.contentView addSubview:_botlabel];

}

return self;

}

@end

在viewController中实现collectionView的三个协议

UICollectionViewDataSource,UICollectionViewDelegate,

具体实例化步骤均在代码中有注释，如下

#import "CollectionViewController.h"

#import "MyCollectionViewCell.h"

@interface CollectionViewController ()<UICollectionViewDataSource,UICollectionViewDelegate,>

{

UICollectionView *mainCollectionView;

}

@end

@implementation CollectionViewController

- (void)viewDidLoad {

[super viewDidLoad];

// Do any additional setup after loading the view.

self.view.backgroundColor = [UIColor whiteColor];

//1.初始化layout

UICollectionViewFlowLayout *layout = [[UICollectionViewFlowLayout alloc] init];

//设置collectionView滚动方向

// [layout setScrollDirection:];

//设置headerView的尺寸大小

layout.headerReferenceSize = CGSizeMake(self.view.frame.size.width, 100);

//该方法也可以设置itemSize

layout.itemSize =CGSizeMake(110, 150);

//2.初始化collectionView

mainCollectionView = [[UICollectionView alloc成都软件开发公司http://www.yingtaow.com?initWithFrame:self.view.bounds collectionViewLayout:layout];

[self.view addSubview:mainCollectionView];

mainCollectionView.backgroundColor = [UIColor clearColor];

//3.注册collectionViewCell

//注意，此处的ReuseIdentifier 必须和 cellForItemAtIndexPath 方法中 一致 均为 cellId

[mainCollectionView registerClass:[MyCollectionViewCell class] forCellWithReuseIdentifier:@"cellId"];

//注册headerView 此处的ReuseIdentifier 必须和 cellForItemAtIndexPath 方法中 一致 均为reusableView

[mainCollectionView registerClass:[UICollectionReusableView class] forSupplementaryViewOfKind: withReuseIdentifier:@"reusableView"];

//4.设置代理

mainCollectionView.delegate = self;

mainCollectionView.dataSource = self;

}

#pragma mark collectionView代理方法

//返回section个数

- (NSInteger):(UICollectionView *)collectionView

{

return 3;

}

//每个section的item个数

- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section

{

return 9;

}

- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath

{

MyCollectionViewCell *cell = (MyCollectionViewCell *)[collectionView :@"cellId" forIndexPath:indexPath];

cell.botlabel.text = [NSString stringWithFormat:@"{%ld,%ld}",(long)indexPath.section,(long)indexPath.row];

cell.backgroundColor = [UIColor yellowColor];

return cell;

}

//设置每个item的尺寸

- (CGSize)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout *)collectionViewLayout sizeForItemAtIndexPath:(NSIndexPath *)indexPath

{

return CGSizeMake(90, 130);

}

//footer的size

//- (CGSize)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout *)collectionViewLayout :(NSInteger)section

//{

// return CGSizeMake(10, 10);

//}

//header的size

//- (CGSize)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout *)collectionViewLayout :(NSInteger)section

//{

// return CGSizeMake(10, 10);

//}

//设置每个item的UIEdgeInsets

- (UIEdgeInsets)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout *)collectionViewLayout insetForSectionAtIndex:(NSInteger)section

{

return UIEdgeInsetsMake(10, 10, 10, 10);

}

//设置每个item水平间距

- (CGFloat)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout *)collectionViewLayout :(NSInteger)section

{

return 10;

}

//设置每个item垂直间距

- (CGFloat)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout *)collectionViewLayout :(NSInteger)section

{

return 15;

}

//通过设置SupplementaryViewOfKind 来设置头部或者底部的view，其中 ReuseIdentifier 的值必须和 注册是填写的一致，本例都为 “reusableView”

- (UICollectionReusableView *)collectionView:(UICollectionView *)collectionView :(NSString *)kind atIndexPath:(NSIndexPath *)indexPath

{

UICollectionReusableView *headerView = [collectionView : withReuseIdentifier:@"reusableView" forIndexPath:indexPath];

headerView.backgroundColor =[UIColor grayColor];

UILabel *label = [[UILabel alloc] initWithFrame:headerView.bounds];

label.text = @"这是collectionView的头部";

label.font = [UIFont systemFontOfSize:20];

[headerView addSubview:label];

return headerView;

}

//点击item方法

- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath

{

MyCollectionViewCell *cell = (MyCollectionViewCell *)[collectionView cellForItemAtIndexPath:indexPath];

NSString *msg = cell.botlabel.text;

NSLog(@"%@",msg);

}

- (void)didReceiveMemoryWarning {

[super didReceiveMemoryWarning];

// Dispose of any resources that can be recreated.

}

/*

#pragma mark - Navigation

// In a storyboard-based application, you will often want to do a little preparation before navigation

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {

// Get the new view controller using [segue destinationViewController].

// Pass the selected object to the new view controller.

}

*/

@end

⑸ 为什么现在很火的uView UI框架免费开源呢

先理解什么是开源，一句话来说，开源指的是那些源代码或源设计可以被大众使用、修改发行的软件或设计体。一般来说，没有开源的基础技术是没有生命力的。所以作为一个开发者的来说，我非常欣赏、佩服uView UI作者易瑞文的思维和贡献的。

⑹ Android UI | View 的绘制流程详解

上一篇文章讲解了，从setContentView方法到了解View是如何绘制的： 传送门
在这篇博客讲述了， 在ViewRootImpl类中performTraversals方法中具体的绘制过程，其中里面就有 performMeasure()、performLayout()、performDraw() 三个方法的调用， 那么要了解View 的测量、布局、绘制，就分别跟这三个方法有关系。

先来看看performMeasure()方法的调用过程

先看performMeasure方法，这个方法有两个参数，都是通过getRootMeasureSpec()方法计算得到

这里有一个关键类MeasureSpec，在这里需要了解下这个类的原理。
这里要感谢 这位博主 ，他讲述的很清晰，我自己动手测算了，很容易理解。大概就是用一个数字通过高位记录Mode,地位记录size的方式，记录两个数据，都是通过一个掩码做位移运算得来。就是说这个变量（measureSpec）的值可以通过掩码分别得到测量mode 和 测量size。
继续查看performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);方法：

这里mView是DecorView对象，那么他调用的实际上是View的measure方法，查询DecorView和FrameLayout都没有measure方法，所以他调用的是View的measure方法

DecorView.onMeasure()方法如下：

FrameLayout.onMeasure方法如下：（这个方法里面都很重要）

我们先看 ， measureChildWithMargins 方法，

getChildMeasureSpec 方法内容如下：

那么假如我们写的布局根节点是LinearLayout，那么就会在执行到View.measure方法里面的onMeasure方法时，就会调用到LinearLayout.onMeasure方法，具体内容如下：

通过源码可以看到，还是会循环调用子View , 就这样循环递归的测量完最里面的一个view，这个过程中onMeasure方法可能会被多次执行。

还是从ViewRootImpl.performTraversals开始

这里跟measure 调用流程其实一样，DecorView和FrameLayout没有重写layout方法，所以调用的是View.layout方法，

由于当前对象是decorView，所以调用的是DecorView.onLayout方法：

FrameLayout.onLayout 方法如下：

继续查看 View.draw方法

在这个方法里面，所有重要的方法都在里面，onDraw、dispatchDraw 等等都在里面，我看了下这个方法里面都挺重要就没删减，也都能看得懂。

到此View的整个绘制流程就搞清楚了。

关于子view测量
1、不管父View是何模式，若子View有确切数值，则子View大小就是其本身大小，且mode是EXACTLY
2、若子View是match_parent，则模式与父View相同，且大小同父View（若父View是UNSPECIFIED，则子View大小为0）
3、若子View是wrap_content，则模式是AT_MOST，大小同父View，表示不可超过父View大小（若父View是UNSPECIFIED，则子View大小为0）

关于绘制流程
我们自定义的view，基本上只需要重写 onMeasure、onLayout、onDraw即可

⑺ 大牛们是怎么阅读 Android 系统源码的

如果只是想看看一些常用类的实现, 在Android包管理器里把源码下载下来, 随便一个IDE配好Source Code的path看就行.
但如果想深入的了解Android系统, 那么可以看下我的一些简单的总结.

知识
java
Java是AOSP的主要语言之一. 没得说, 必需熟练掌握.
熟练的Android App开发
Linux
Android基于Linux的, 并且AOSP的推荐编译环境是Ubuntu 12.04. 所以熟练的使用并了解Linux这个系统是必不可少的. 如果你想了解偏底层的代码, 那么必需了解基本的Linux环境下的程序开发. 如果再深入到驱动层, 那么Kernel相关的知识也要具备.
Make
AOSP使用Make系统进行编译. 了解基本的Makefile编写会让你更清晰了解AOSP这个庞大的项目是如何构建起来的.
Git
AOSP使用git+repo进行源码管理. 这应该是程序员必备技能吧.
C++
Android系统的一些性能敏感模块及第三方库是用C++实现的, 比如: Input系统, Chromium项目(WebView的底层实现).

硬件
流畅的国际网络
AOSP代码下载需要你拥有一个流畅的国际网络. 如果在下载代码这一步就失去耐心的话, 那你肯定没有耐心去看那乱糟糟的AOSP代码. 另外, 好程序员应该都会需要一个流畅的Google.
一台运行Ubuntu 12.04的PC.
如果只是阅读源码而不做太多修改的话, 其实不需要太高的配置.
一台Nexus设备
AOSP项目默认只支持Nexus系列设备. 没有也没关系, 你依然可以读代码. 但如果你想在大牛之路走的更远, 还是改改代码, 然后刷机调试看看吧.
高品质USB线
要刷机时线坏了, 没有更窝心的事儿了.
软件
Ubuntu 12.04
官方推荐, 没得选.
Oracle Java 1.6
注意不要用OpenJDK. 这是个坑, 官方文档虽然有写, 但还是单独提一下.
安装:
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java6-installer
sudo apt-get install oracle-java6-set-default

Eclipse
估计会有不少人吐槽, 为什么要用这个老古董. 其实原因很简单, 合适. 刚开始搞AOSP时, 为了找到效率最优的工具, 我尝试过Eclipse, IntelliJ IDEA, Vim+Ctags, Sublime Text+Ctags. 最终结果还是Eclipse. 主要优点有:
有语法分析 (快速准确的类, 方法跳转).
支持C++ (IntelliJ的C++支持做的太慢了).
嵌入了DDMS, View Hierarchy等调试工具.
为了提高效率, 花5分钟背下常用快捷键非常非常值得.
调整好你的classpath, 不要导入无用的代码. 因为AOSP项目代码实在是太多了. 当你还不需要看C++代码时, 不要为项目添加C++支持, 建索引过程会让你崩溃.
Intellij IDEA
开发App必备. 当你要调试系统的某个功能是, 常常需要迅速写出一个调试用App, 这个时候老旧的Eclipse就不好用了. Itellij IDEA的xml自动补全非常给力.
巨人的肩膀

这个一定要先读. 项目介绍, 代码下载, 环境搭建, 刷机方法, Eclipse配置都在这里. 这是一切的基础.

这个其实是给App开发者看的. 但是里面也有不少关于系统机制的介绍, 值得细读.

此老罗非彼老罗. 罗升阳老师的博客非常有营养, 基本可以作为指引你开始阅读AOSP源码的教程. 你可以按照博客的时间顺序一篇篇挑需要的看.但这个系列的博客有些问题:
早期的博客是基于旧版本的Android;
大量的代码流程追踪. 读文章时你一定要清楚你在看的东西在整个系统处于什么样的位置.

邓凡平老师也是为Android大牛, 博客同样很有营养. 但是不像罗升阳老师的那么系统. 更多的是一些技术点的深入探讨.

Android官方Issue列表. 我在开发过程中发现过一些奇怪的bug, 最后发现这里基本都有记录. 当然你可以提一些新的, 有没有人改就是另外一回事了.

一定要能流畅的使用这个工具. 大量的相关知识是没有人系统的总结的, 你需要自己搞定.
其它
代码组织
AOSP的编译单元不是和git项目一一对应的, 而是和Android.mk文件一一对应的. 善用mmm命令进行模块编译将节省你大量的时间.
Binder
这是Android最基础的进程间通讯. 在Application和System services之间大量使用. 你不仅要知道AIDL如何使用, 也要知道如何手写Binder接口. 这对你理解Android的Application和System services如何交互有非常重要的作用. Binder如何实现的倒不必着急看.
HAL
除非你对硬件特别感兴趣或者想去方案公司上班, 否则别花太多时间在这一层.
CyanogenMod
这是一个基于AOSP的第三方Rom. 从这个项目的wiki里你能学到很多AOSP官方没有告诉你的东西. 比如如何支持Nexus以外的设备.
DIA
这是一个Linux下画UML的工具, 能够帮你梳理看过的代码.
XDA

⑻ Android 重学系列 View的绘制流程(六) 硬件渲染(上)

本文开始聊聊Android中的硬件渲染。如果跟着我的文章顺序，从SF进程到App进程的绘制流程一直阅读，我们到这里已经有了一定的基础，可以试着进行横向比对如Chrome浏览器渲染流程，看看软件渲染，硬件渲染，SF合成都做了什么程度的优化。

先让我们回顾一下负责硬件渲染的主体对象ThreadedRenderer在整个绘制流程中做了哪几个步骤。

在硬件渲染的过程中，有一个很核心的对象RenderNode，作为每一个View绘制的节点对象。

当每一次进行准备进行绘制的时候，都会雷打不动执行如下三个步骤：

如果遇到什么问题欢迎来到 https://www.jianshu.com/p/c84bfa909810 下进行讨论

实际上整个硬件渲染的设计还是比较庞大。因此本文先聊聊ThreadedRender整个体系中主要对象的构造以及相关的原理。

首先来认识下面几个重要的对象有一个大体的印象。

在Java层中面向Framework中，只有这么多，下面是一一映射的简图。

能看到实际上RenderNode也会跟着View 树的构建同时一起构建整个显示层级。也是因此ThreadedRender也能以RenderNode为线索构建出一套和软件渲染一样的渲染流程。

仅仅这样？如果只是这么简单，知道我习惯的都知道，我喜欢把相关总结写在最后。如果把总揽写在正文开头是因为设计比较繁多。因为我们如果以流水线的形式进行剖析容易造成迷失细节的困境。

让我继续介绍一下，在硬件渲染中native层的核心对象。

如下是一个思维导图：

有这么一个大体印象后，就不容易迷失在源码中。我们先来把这些对象的实例化以及上面列举的ThreadedRenderer在ViewRootImpl中执行行为的顺序和大家来聊聊其原理，先来看看ThreadedRenderer的实例化。

当发现mSurfaceHolder为空的时候会调用如下函数：

而这个方法则调用如下的方法对ThreadedRenderer进行创建：

文件：/ frameworks / base / core / java / android / view / ThreadedRenderer.java

能不能创建的了ThreadedRenderer则决定于全局配置。如果ro.kernel.qemu的配置为0，说明支持OpenGL 则可以直接返回true。如果qemu.gles为-1说明不支持OpenGL es返回false，只能使用软件渲染。如果设置了qemu.gles并大于0，才能打开硬件渲染。

我们能看到ThreadedRenderer在初始化，做了三件事情：

关键是看1-3点中ThreadRenderer都做了什么。

文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp

能看到这里是直接实例化一个RootRenderNode对象，并把指针的地址直接返回。

能看到RootRenderNode继承了RenderNode对象，并且保存一个JavaVM也就是我们所说的Java虚拟机对象，一个java进程全局只有一个。同时通过getForThread方法，获取ThreadLocal中的Looper对象。这里实际上拿的就是UI线程的Looper。

在这个构造函数有一个mDisplayList十分重要，记住之后会频繁出现。接着来看看RenderNode的头文件：
文件：/ frameworks / base / libs / hwui / RenderNode.h

实际上我把几个重要的对象留下来：

文件：/ frameworks / base / core / java / android / view / RenderNode.java

能看到很简单，就是包裹一个native层的RenderNode返回一个Java层对应的对象开放Java层的操作API。

能看到这个过程生成了两个对象：

这个对象实际上让RenderProxy持有一个创建动画上下文的工厂。RenderProxy可以通过ContextFactoryImpl为每一个RenderNode创建一个动画执行对象的上下文AnimationContextBridge。

文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp

在这里有几个十分重要的对象被实例化，当然这几个对象在聊TextureView有聊过( SurfaceView和TextureView 源码浅析 )：

我们依次看看他们初始化都做了什么。

文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.cpp

能看到其实就是简单的调用RenderThread的构造函数进行实例化，并且返回对象的指针。

RenderThread是一个线程对象。先来看看其头文件继承的对象：
文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.h

其中RenderThread的中进行排队处理的任务队列实际上是来自ThreadBase的WorkQueue对象。

文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h

ThreadBase则是继承于Thread对象。当调用start方法时候其实就是调用Thread的run方法启动线程。

另一个更加关键的对象，就是实例化一个Looper对象到WorkQueue中。而直接实例化Looper实际上就是新建一个Looper。但是这个Looper并没有获取当先线程的Looper，这个Looper做什么的呢？下文就会揭晓。

WorkQueue把一个Looper的方法指针设置到其中，其作用可能是完成了某一件任务后唤醒Looper继续工作。

而start方法会启动Thread的run方法。而run方法最终会走到threadLoop方法中，至于是怎么走进来的，之后有机会会解剖虚拟机的源码线程篇章进行讲解。

在threadloop中关键的步骤有如下四个：

在这个过程中创建了几个核心对象：

另一个核心的方法就是，这个方法为WorkQueue的Looper注册了监听：

能看到在这个Looper中注册了对DisplayEventReceiver的监听，也就是Vsync信号的监听，回调方法为displayEventReceiverCallback。

我们暂时先对RenderThread的方法探索到这里，我们稍后继续看看回调后的逻辑。

文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h

能看到这里的逻辑很简单实际上就是调用Looper的pollOnce方法，阻塞Looper中的循环，直到Vsync的信号到来才会继续往下执行。详细的可以阅读我写的 Handler与相关系统调用的剖析 系列文章。

文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h

实际上调用的是WorkQueue的process方法。

文件：/ frameworks / base / libs / hwui / thread / WorkQueue.h

能看到这个过程中很简单，几乎和Message的loop的逻辑一致。如果Looper的阻塞打开了，则首先找到预计执行时间比当前时刻都大的WorkItem。并且从mWorkQueue移除，最后添加到toProcess中，并且执行每一个WorkItem的work方法。而每一个WorkItem其实就是通过从某一个压入方法添加到mWorkQueue中。

到这里，我们就明白了RenderThread中是如何消费渲染任务的。那么这些渲染任务又是哪里诞生呢？

上文聊到了在RenderThread中的Looper会监听Vsync信号，当信号回调后将会执行下面的回调。

能看到这个方法的核心实际上就是调用drainDisplayEventQueue方法，对ui渲染任务队列进行处理。

能到在这里mVsyncRequested设置为false，且mFrameCallbackTaskPending将会设置为true，并且调用queue的postAt的方法执行ui渲染方法。

还记得queue实际是是指WorkQueue，而WorkQueue的postAt方法实际实现如下：
/ frameworks / base / libs / hwui / thread / WorkQueue.h

情景带入，当一个Vsync信号达到Looper的监听者，此时就会通过WorkQueue的drainDisplayEventQueue 压入一个任务到队列中。

每一个默认的任务都是执行dispatchFrameCallback方法。这里的判断mWorkQueue中是否存在比当前时间更迟的时刻，并返回这个WorkItem。如果这个对象在头部needsWakeup为true，说明可以进行唤醒了。而mWakeFunc这个方法指针就是上面传下来：

把阻塞的Looper唤醒。当唤醒后就继续执行WorkQueue的process方法。也就是执行dispatchFrameCallbacks方法。

在这里执行了两个事情：

先添加到集合中，在上面提到过的threadLoop中，会执行如下逻辑：

如果大小不为0，则的把中的IFrameCallback全部迁移到mFrameCallbacks中。

而这个方法什么时候调用呢？稍后就会介绍。其实这部分的逻辑在TextureView的解析中提到过。

接下来将会初始化一个重要对象：

这个对象名字叫做画布的上下文，具体是什么上下文呢？我们现在就来看看其实例化方法。
文件：/ frameworks / base / libs / hwui / renderthread / CanvasContext.cpp

文件：/ device / generic / goldfish / init.ranchu.rc

在init.rc中默认是opengl，那么我们就来看看下面的逻辑：

首先实例化一个OpenGLPipeline管道，接着OpenGLPipeline作为参数实例化CanvasContext。

文件：/ frameworks / base / libs / hwui / renderthread / OpenGLPipeline.cpp

能看到在OpenGLPipeline中，实际上就是存储了RenderThread对象，以及RenderThread中的mEglManager。透过OpenGLPipeline来控制mEglManager进而进一步操作OpenGL。

做了如下操作：

文件：/ frameworks / base / libs / hwui / renderstate / RenderState.cpp

文件：/ frameworks / base / libs / hwui / renderthread / DrawFrameTask.cpp

实际上就是保存这三对象RenderThread；CanvasContext；RenderNode。

文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp

能看到实际上就是调用RenderProxy的setName方法给当前硬件渲染对象设置名字。

文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp

能看到在setName方法中，实际上就是调用RenderThread的WorkQueue，把一个任务队列设置进去，并且调用runSync执行。

能看到这个方法实际上也是调用post执行排队执行任务，不同的是，这里使用了线程的Future方式，阻塞了执行，等待CanvasContext的setName工作完毕。

⑼ 如何做好IOS View的布局

iOS 越来越人性化了，用户可以在设置-通用-辅助功能中动态调整字体大小了。你会发现所有 iOS 自带的APP的字体大小都变了，可惜我们开发的第三方APP依然是以前的字体。在 iOS 7 之后我们可以用 UIFont 的preferredFontForTextStyle: 类方法来指定一个样式，并让字体大小符合用户设定的字体大小。目前可供选择的有六种样式： UIFontTextStyleHeadline UIFontTextStyleBody UIFontTextStyleSubheadline UIFontTextStyleFootnote UIFontTextStyleCaption1 UIFontTextStyleCaption2 iOS会根据样式的用途来合理调整字体。 问题来了，诸如字体大小这种“动态类型”，我们需要对其进行动态的UI调整，否则总是觉得我们的界面怪怪的： 我们想要让Cell 的高度随着字体大小而作出调整： 总之，还会有其他动态因素导致我们需要修改布局。 解决方案 UITableView 有三种策略可以调节Cell（或者是Header和Footer）的高度： a.调节Height属性 b.通过委托方法tableView: heightForRowAtIndexPath: c.Cell的“自排列”（self-sizing） 前两种策略都是我们所熟悉的，后面将介绍第三种策略。UITableViewCell 和 UICollectionViewCell 都支持 self-sizing。 在 iOS 7 中，UITableViewDelegate新增了三个方法来满足用户设定Cell、Header和Footer预计高度的方法： - tableView:: - tableView:: - tableView:: 当然对应这三个方法 UITableView 也 estimatedRowHeight、estimatedSectionHeaderHeight 和 estimatedSectionFooterHeight 三个属性，局限性在于只能统一定义所有行和节的高度。 以 Cell 为例，iOS 会根据给出的预计高度来创建一个Cell，但等到真正要显示它的时候，iOS 8会在 self-sizing 计算得出新的 Size 并调整 table 的 contentSize 后，将 Cell 绘制显示出来。关键在于如何得出 Cell 新的 Size，iOS提供了两种方法： 自动布局 这个两年前推出的神器虽然在一开始表现不佳，但随着 Xcode 的越来越给力，在iOS7中自动布局俨然成了默认勾选的选项，通过设定一系列约束来使得我们的UI能够适应各种尺寸的屏幕。如果你有使用约束的经验，想必已经有了解决思路：向 Cell 的 contentView 添加约束。iOS 会先调用 UIView 的 systemLayoutSizeFittingSize: 方法来根据约束计算新的Size，如果你没实现约束，systemLayoutSizeFittingSize: 会接着调用sizeThatFits:方法。 人工代码 我们可以重写sizeThatFits:方法来自己定义新的Size，这样我们就不必学习约束相关的知识了。 下面我给出了一个用 Swift 语言写的 Demo-HardChoice ，使用自动布局来调整UITableViewCell的高度。我通过实现一个UITableViewCell的子类DynamicCell来实现自动布局，你可以再GitHub上下载源码： import UIKit class DynamicCell: UITableViewCell { required init(coder: NSCoder) { super.init(coder: coder) if textLabel != nil { textLabel.font = UIFont.preferredFontForTextStyle(UIFontTextStyleHeadline) textLabel.numberOfLines = 0 } if detailTextLabel != nil { detailTextLabel.font = UIFont.preferredFontForTextStyle(UIFontTextStyleBody) detailTextLabel.numberOfLines = 0 } } override func constraints() -> [AnyObject] { var constraints = [AnyObject]() if textLabel != nil { constraints.extend(constraintsForView(textLabel)) } if detailTextLabel != nil { constraints.extend(constraintsForView(detailTextLabel)) } constraints.append(NSLayoutConstraint(item: contentView, attribute: NSLayoutAttribute.Height, relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: contentView, attribute: NSLayoutAttribute.Height, multiplier: 0, constant: 44)) contentView.addConstraints(constraints) return constraints } func constraintsForView(view:UIView) -> [AnyObject]{ var constraints = [NSLayoutConstraint]() constraints.append(NSLayoutConstraint(item: view, attribute: NSLayoutAttribute.FirstBaseline, relatedBy: NSLayoutRelation.Equal, toItem: contentView, attribute: NSLayoutAttribute.Top, multiplier: 1.8, constant: 30.0)) constraints.append(NSLayoutConstraint(item: contentView, attribute: NSLayoutAttribute.Bottom, relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: view, attribute: NSLayoutAttribute.Baseline, multiplier: 1.3, constant: 8)) return constraints } } 上面的代码需要注意的是，Objective-C中的类在Swift中都可以被当做AnyObject，这在类型兼容问题上很管用。 别忘了在相应的 UITableViewController 中的 viewDidLoad 方法中加上： self.tableView.estimatedRowHeight = 44 自适应效果如下： UICollectionView UITableView 和 UICollectionView 都是 data-source 和 delegate 驱动的。UICollectionView 在此之上进行了进一步抽象。它将其子视图的位置，大小和外观的控制权委托给一个单独的布局对象。通过提供一个自定义布局对象，你几乎可以实现任何你能想象到的布局。布局继承自 UICollectionViewLayout 抽象基类。iOS 6 中以 UICollectionViewFlowLayout 类的形式提出了一个具体的布局实现。在 UICollectionViewFlowLayout 中，self-sizing 同样适用： 采用self-sizing后： UICollectionView 实现 self-sizing 不仅可以通过在 Cell 的 contentView 上加约束和重写 sizeThatFits: 方法，也能在 Cell 层面（以前都是在 contentSize 上进行 self-sizing）上做文章：重写 UICollectionReusableView 的: 方法来在 self-sizing 计算出 Size 之后再修改，这样就达到了对Cell布局属性（）的全面控制。 PS：: 方法默认调整Size属性来适应 self-sizing Cell，所以重写的时候需要先调用父类方法，再在返回的 对象上做你想要做的修改。 由此我们从最经典的 UICollectionViewLayout 强制计算属性（还记得 的一系列工厂方法么？）到使用 self-sizing 来根据我们需求调整属性中的Size，再到重写UICollectionReusableView（UICollectionViewCell也是继承于它）的 : 方法来从Cell层面对所有属性进行修改： 下面来说说如何在 UICollectionViewFlowLayout 实现 self-sizing： 首先，UICollectionViewFlowLayout 增加了estimatedItemSize 属性，这与 UITableView 中的 ”estimated...Height“ 很像（注意我用省略号囊括那三种属性），但毕竟 UICollectionView 中的 Item 都需要约束 Height 和 Width的，所以它是个 CGSIze，除了这点它与 UITableView 中的”estimated...Height“用法没区别。 其...没有其次，在 UICollectionView 中实现 self-sizing，只需给 estimatedItemSize 属性赋值（不能是 CGSizeZero ），一行代码足矣。 InvalidationContext 假如设备屏幕旋转，或者需要展示一些其妙的效果（比如 CoverFlow ），我们需要将当前的布局失效，并重新计算布局。当然每次计算都有一定的开销，所以我们应该谨慎的仅在我们需要的时候调用 invalidateLayout 方法来让布局失效。 在 iOS 6 时代，有的人会“聪明地”这样做： - (BOOL):(CGRect)newBounds { CGRect oldBounds = self.collectionView.bounds; if (CGRectGetWidth(newBounds) != CGRectGetWidth(oldBounds)) { return YES; } return NO; } 而 iOS 7 新加入的 类声明了在布局失效时布局的哪些部分需要被更新。当数据源变更时，invalidateEverything 和 invalidateDataSourceCounts 这两个只读 Bool 属性标记了UICollectionView 数据源“全部过期失效”和“Section和Item数量失效”，UICollectionView会将它们自动设定并提供给你。 你可以调用invalidateLayoutWithContext:方法并传入一个对象，这能优化布局的更新效率。 当你自定义一个 UICollectionViewLayout 子类时，你可以调用 invalidationContextClass 方法来返回一个你定义的 的子类，这样你的 Layout 子类在失效时会使用你自定义的InvalidationContext 子类来优化更新布局。 你还可以重写 : 方法，在实现自定义 Layout 时通过重写这个方法返回一个 InvalidationContext 对象。 综上所述都是 iOS 7 中新加入的内容，并且还可以应用在 UICollectionViewFlowLayout 中。在 iOS 8 中， 也被用在self-sizing cell上。 iOS8 中 新加入了三个方法使得我们可以更加细致精密地使某一行某一节Item（Cell）、Supplementary View 或 Decoration View 失效： invalidateItemsAtIndexPaths: :atIndexPaths: :atIndexPaths: 对应着添加了三个只读数组属性来标记上面那三种组件： invalidatedItemIndexPaths iOS自带的照片应用会将每一节照片的信息（时间、地点）停留显示在最顶部，实现这种将 Header 粘在顶端的功能其实就是将那个 Index 的 Supplementary View 失效，就这么简单。 新加入的 contentOffsetAdjustment 和 contentSizeAdjustment 属性可以让我们更新 CollectionView 的 content 的位移和尺寸。 此外 UICollectionViewLayout 还加入了一对儿方法来帮助我们使用self-sizing： :withOriginalAttributes: :withOriginalAttributes: 当一个self-sizing Cell发生属性发生变化时，第一个方法会被调用，它询问是否应该更新布局（即原布局失效），默认为NO；而第二个方法更细化的指明了哪些属性应该更新，需要调用父类的方法获得一个InvalidationContext 对象，然后对其做一些你想要的修改，最后返回。 试想，如果在你自定义的布局中，一个Cell的Size因为某种原因发生了变化（比如由于字体大小变化），其他的Cell会由于 self-sizing 而位置发生变化，你需要实现上面两个方法来让指定的Cell更新布局中的部分属性；别忘了整个 CollectionView 的 contentSize 和 contentOffset 因此也会发生变化，你需要给 contentOffsetAdjustment 和 contentSizeAdjustment 属性赋值。

⑽ 如何viewcontroller代码中设置自定义UIView的宽度或高度

1.设置UIView宽与高要设置frame.
2.要看自定义.要用静.
3.或者viewController 增加IBOutlet 链接自定义view获取frame属性知道高宽setFrame设置高宽