iOS 开发 Objective-C

iOS 架构杂谈

2020-10-28  本文已影响0人  望穿秋水小作坊

一. 开篇

1. 一句话概括客户端其实大部分都在干些什么事情？
    ---------------     ---------------     ---------------     ---------------
    |             |     |             |     |             |     |             |
    | 调用网络API  | --> |   展现列表    | --> |  选择列表    | --> |   展现单页   |
    |             |     |             |     |             |     |             |
    ---------------     ---------------     ---------------     ---------------
           ^                                                            |
           |                                                            |
           |                                                            |
            ------------------------------------------------------------
2. APP确实主要做这些事情，但是支持这些事情的基础，就是做架构要考虑的事情。（举三个）
3. 详细一点说明架构在上面三件事情的作用？
4. 架构设计的方法
5. 什么样的架构叫好架构？
  1. 代码整齐，分类明确，没有 common，没有 core
  2. 不用文档，或很少文档，就能让业务方上手
  3. 思路和方法要统一，尽量不要多元
  4. 没有横向依赖，万不得已不出现跨层访问
  5. 对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件
  6. 易测试，易拓展
  7. 保持一定量的超前性
  8. 接口少，接口参数少
  9. 高性能
6. 我们常说的三层架构或四层架构通常指的是什么？
7. 为什么流行起来的是三层架构，而不是四层架构或者五层架构？
8. 三层架构和 MVC 之间是什么关系？

二. view 层的架构

1. 为什么说 view 层架构是最重要的？
2. ViewController 代码结构的规定
图片来源 https://casatwy.com/iosying-yong-jia-gou-tan-viewceng-de-zu-zhi-he-diao-yong-fang-an.html 
@interface CustomObject()
@property (nonatomic, strong) UILabel *label;
@end

@implement

#pragma mark - life cycle

- (void)viewDidLoad
{
    [super viewDidLoad];

    [self.view addSubview:self.label];

    [self layoutPageSubviews];
}

- (void)layoutPageSubviews {
     [self.label addConstraints:xxxConstraints];
}

#pragma mark - getters and setters

- (UILabel *)label
{
    if (_label == nil) {
        _label = [[UILabel alloc] init];
        _label.text = @"1234";
        _label.font = [UIFont systemFontOfSize:12];
        ... ...
    }
    return _label;
}
@end
3. 在 10 以上的团队中，使用 nib 和 代码写 View 哪种更优？

具有一定规模的团队化 iOS 开发（10 人以上）有以下几个特点：

  1. 同一份代码文件的作者会有很多，不同作者同时修改一份代码的情况也不少见。因此，用 Git 进行代码版本管理时出现 Conflict 的几率也比较大。
  2. 需要变换非常频繁，产品经理一时一个主意，为了完成需求二针对现有代码进行微调的情况，以及针对现有代码的 部分复用 的情况也比较多。
  3. 复杂界面元素、复杂动画场景的开发任务比较多。

综上所述：实现简单的东西，用Code一样简单，实现复杂的东西，Code比StoryBoard更简单。所以我更加提倡用code去画view而不是storyboard。

4. View 的布局采用什么方案？
5. 是否有必要让业务方统一派生 ViewController？

// todo

6. 关于 MVC，请描述 Model，View，Controller 各做什么事情？

M 应该做的事情：

  1. 给 ViewController 提供数据
  2. 提供 ViewController 存储数据提供接口

C 应该做的事情：

  1. 管理 View Container 的生命周期
  2. 负责生成所有 View 的实例，并放入 View Container
  3. 监听来自 View 与业务有关的事情，通过与 Model 的合作，来完成对应事件的业务。

V 应该做的事情：

  1. 响应与业务无关的事件，如因此引发动画效果，点击反馈效果等。
  2. 界面元素表达

二. 网络层的架构

1. 如何确保 API 的调用者是来自你自己的 APP，防止竞争对手爬你的 API？
2. 如何防止中间人攻击，比如运营商很喜欢往用户的 HTTP 请求里面塞广告？
3. 网络层的优化方案（针对链接建立环节的优化）？
网络层的优化方案

三. 本地数据持久化层的架构

1. NSUserDefault
2. keychain
3. 文件存储
4. 数据库存储
上一篇 下一篇

猜你喜欢

热点阅读