Sha*_*hal 26 objective-c storyboard xib ios
我的问题与我的标题建议略有不同.我和xib合作过.现在我正在尝试使用故事板.我的问题是,如果我们从另一个类中浏览一个类,那么StoryBoard可以为更好的内存管理带来好处.假设我们有2个ViewControllers:ViewControllerA和ViewControllerB.我们试图通过ViewControllerA - > ViewControllerB.现在,在Xib我们的方法如下;
ViewControllerB *VCB = [ [ViewControllerB alloc] init];
[self.navigationController pushViewController: VCB Animated: YES];
Run Code Online (Sandbox Code Playgroud)
故事板在哪里,
-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
if ([segue.identifier isEqualToString:@"Second"])
{
SecondViewController *objSecond = (SecondViewController*)[segue destinationViewController];
}
}
Run Code Online (Sandbox Code Playgroud)
而且,做
[self performSegueWithIdentifier:@"Second" sender:self];
Run Code Online (Sandbox Code Playgroud)
所以,我的问题是我们在Xib中分配我们的类,在storyBoard中我们不是.故事板中是否有任何内存分配优势?
Gio*_*Ath 38
我的观点是MUST use xibs
,如果他使用故事板,那么专业开发人员,但业余爱好者,编程新手,开发人员可能会受到帮助.
故事板
经过3年的单一故事板项目工作后,我可以说lot of disadvantages
:
1)即使是非常非常小的想法,它的构建也非常非常缓慢(其中的每个视图都必须重建).如果故事板变大,即使使用带有8或16 GB RAM的iMac也很难编辑.它甚至很难打开它.
2)没有可重用性.您无法立即将View/ViewController及其视图导入另一个项目.它将与其他ViewControllers,Views或Segues连接,这将使它像一个大的"不要触摸"的想法.
3)即使对于要添加或编辑的最小布局约束,项目变大也存在很多延迟,您永远不想触摸它.
4)如果通过自动添加故事板的单元格来使用单元格,则不能在两点中使用相同的单元格构建.
优点:
1)自动单元格(但这也是一个缺点,因为单元格不能像其他视图一样重复使用)
2)Segues等可以让人们从单一角度理解正在发生的事情.
Xibs:
1)完全便携.
2)打开/编辑/构建比变大的故事板快得多
结论:
如果你是一个业余爱好者开发者,他会为他的业务制作一个有趣的应用程序,你应该使用故事板,因为它更容易理解事物.但是,如果你是一名专业开发人员,你必须将xib用于VC,Cell等,因为这是使它们真正可重复使用和移植的唯一方法,以便为下一个项目获得这么多时间,或者甚至不得不做一点改变或再次构建故事板.
解释为什么xib对我来说更"可重用和可移植":编程中的东西必须保存在不同的模型,文件,实体,模块中.一个人必须至少依赖于另一件事,因为它可以获得
cod*_*cat 37
It is not to tell which one is the best. because which one is good to tell based on team requirement.
If you are a single developer, it is good to use storyboard because it consumes less time. If the team consists of many developers, use xib, otherwise, it is not easy to merge the modules/tasks.
xcode-using-storyboards-and-xibs-versus-creating-views-programmatically
Advantages:
You can quickly put together a UI
Straight-forward implementation for small apps with a minimal number of screens
You can have separate XIBs for different localizations (ie. languages or countries)
Great at laying out elements and visually spotting misalignments. It’s easy to make a slight adjustment to the layout
Disadvantages:
It’s difficult to merge conflicts when working in a team environment (hard to diff, merge and read)
Highly dynamic views are impossible to describe as a XIB
Performance wise, it’s slower than creating views through code because the xib needs to be read from the disk and analysed/parsed
XIBs lack customizations that you can do in code such as Quartz stuff (drop shadows, round corners)
Harder to debug (i.e. if you forget to make a connection in Interface Builder or make a wrong connection)
Advantages:
Storyboards are nice for apps with a small to medium amount of screens and the requirements for navigation is relatively straightforward between views
You can mock up the flow of an application without writing much, if any, code
Disadvantages:
Storyboards are not compatible with pre-iOS 5 so it makes supporting iOS 4.3 impossible
It’s hard to work in parallel in a team environment because everyone’s modifying the same file
Along the same lines, merging conflicted storyboards in GIT will be a pain
People have experienced bugs in Xcode with the usage of storyboards (eg. having to frequently flush the DerivedData folder because of inconsistencies)
比较XIB和storyBoard,StoryBoard很快.
但实际上在以编程方式完成整个项目时速度很快.
在故事板中,当我们编译所有storyBoard是归档到文件.然后unArchive运行应用程序.但是,在编程中,类仅在运行时分配.
归档时间: |
|
查看次数: |
24196 次 |
最近记录: |