关于“新奥创”的一些文章

• 新奥创：多APP场景端到端的技术体系探索与突破
  • 对交易的述求的一致性。涉及全域的营销活动，支持面广、需求同步问题、考虑App迭代、长尾效应……
  • 火器时代：解决基础链路需求开发资源的单点瓶颈(开发资源)，同时通过实时性快速迭代业务需求，让业务需求做到想发就发，随时发随时生效。
  • 对新奥创的描述：

    • 是开发手淘基础链路消费者端需求的一个平台；

    • 是端到端的页面动态化解决方案；

    • 是无线时代在基础链路针由集中式到分布式研发的一体化方案。

  • 特性：开放/隔离性，实时性，全域性

    • 开放/隔离性：

      • 集中式由一个团队开发，到多业务并行自主开发的研发体系；
      • 引入DinamicX等页面动态化技术，业务方只需进行模板开发，加上新奥创的布局，数据叠加行为描述能力，配置出一个完整的页面渲染+行为的组件。增强Native的业务共建能力；
      • 与星环深度结合，提供基于业务身份的页面、组件、规则隔离能力，各业务互不干扰；与星环共同实现组件规则粒度的热发能力，提供实时发布能力；

    • 实时性：

      • 开发效率提升。需求覆盖度的提升(长尾效应)。新奥创的动态化支撑下，不再依赖发版，从支持新奥创能力的客户端版本开始覆盖消费者，给新业务至少带来额外10%的增量。

    • 全域性：

      • 阿里系App矩阵下的需求同步，基于容器化级数屏蔽了异构体系之间的差异，同一套模板，真正做到一次开发，全域生效(不同的端、不同的App) more >>

题目源头

这道题目是前些日子，面试阿里的时候，给的一道在线测评算法题

题目描述

1
2
3
4
5
6

大海中央的一座孤岛，上面本来没有老鼠。有一艘路过的船只在附近沉没了，船上 x 对 新出生的老鼠，顺着船只残骸漂流到小岛上。
1. 每两个月一次生产，每次出生 2对 老鼠 
2. 老鼠的寿命是 5个月，也就是说一辈子可以生产 2次
3. 这个岛上，每个月因为神秘原因，假如存在 3个月大的老鼠，会死去一对
 
问 n个月后，岛上有多少只老鼠 (假设存活率 100% )

解题思路

1

• 如果只看第一个条件，颇有一点斐波那契数列的样子。但是这个题目，老鼠不是单纯的生，还有死、意外死，还有生的限制

2

• 进一步，可以看到，这个题目似乎老鼠是有几个状态的：新生的老鼠，意外死亡，正常死亡的老鼠等
• 最开始在想，是不是可以存在几个状态转移方程，譬如fn=nx，n个月时该状态下的老鼠数量，多个状态转移与岛上的老鼠有什么关系，去寻找这种关系
• 但是，想了一会儿，发现这种思路，偏复杂，比如意外死亡是需要考虑老鼠的年龄的，并不是单纯的将现存的老鼠直接-1就可以的，必须是年龄到3个月的时候才可-1。那就说明，这种状态方程计算数目的时候，必须要引入老鼠的年龄的概念。
• 这里的动态转移方程：已经想到这个题目应该是可以利用动态规划的思想去解决的

3

• 从老鼠年龄的角度出发，记录不同的月份的老鼠的有多少只，岛上的老鼠数目，就是当前n个月，不同月份的老鼠数目和

出发点：isEqual和hash的关系

• 看到这个点，上网搜一下，首先出现的就是这篇文iOS开发 之 不要告诉我你真的懂isEqual与hash!
• 第一次看完了，确实出现了一些问号以及看了评论区的提问：isEqual和hash都重写了来得出这两者的关系？hash都有默认的实现了，为什么要重写？等等问题
• 本文，简单的做了下梳理，补充了些个人的白话理解，更通俗易懂些

==和isEqual

• ==

  • 基本类型，==，比较是否相等
  • 对象类型，==，只是比较对象地址即是否为同一对象

• 默认的isEqual实现，就是self==object

  • 对于自定义类，通常需要自行去重写isEqual方法。

• ==与isEqual的应用场景的区分在：

  • ==是比较对象地址
  • isEqual是比较对象，判等

• 为什么要重写isEqual？？？

  • 看上面描述的应用场景，可以看出，如果你想比较对象地址直接用==，isEqual的最佳实践通常是比较对象，判断对象是否相等，而系统默认的isEqual实现不能满足要求。这也是为什么isEqual有比较规范的写法，有所谓的最佳实践这一说
  • 判断对象是否相等：比如以下应用场景：一个Person对象，有creditId，身份证号码属性，如果new了两个对象，都是Person类型，creditId值也相等，那我们认为这两个对象是相等的。就需要去重写isEqual来实现该场景

• isEqual的重写思路(关心对象的内容(类型以及对象属性一致)):

  • 1、判断两指针地址，一致，返回YES；否则2
  • 2、判断指针指向对象是否为空以及对象类型是否相同。若有一个为空，或两者不是同类型对象 直接返回NO；否则3
  • 3、都不为空，且属于同类对象，而且对象的属性也相等，则返回YES
• 当然你也可以有isEqual其他的实现，视具体应用场景

本文梳理了如下一些问题

1. 关于Cocoapods
2. –verbose，–no-repo-update
3. pod install –verbose的过程
4. podfile 和 podspec
5. 看点CocoaPods源码
6. Podfile.lock 和 Manifest.lock
7. pod install 和 update的区别
8. 那些常见的目录&指令

• 期望用更简洁的话，做一些整理

关于Cocoapods

• 管理Xcode项目依赖库的工具

  项目依赖被详细写在Podfile的文件中，CocoaPods解决libraries之间的依赖关系、获取目标库的源码，并将它链接到Xcode workspace中来构建项目。最终目标是建立一个查找效率高效、更规范的第三方开源库生态环境

–verbose，–no-repo-update

• pod install/update –no-repo-update：默认情况下install/update时，会默认更新一次podspec索引，使用–no-repo可以禁止对其索引的更新（这里说的就是local spec）
• pod install/update –verbose：verbose表示显示详细的冗长的过程，没什么特殊的功能性的意义，只是把详细的过程列出来给你看，更有助于了解底层运行

podfile 和 podspec

• 高度定制所需要的三方库
• 描述文件，描述pod库的版本。描述一个库怎么被添加到工程中，支持：列出源文件、依赖库、编译选项和其他第三方库需要的配置。
  • 拿三方库举例，pod项目的podspec都托管在“https://github.com/CocoaPods/Specs”这个远程索引库
  • pod setup时，CocoaPods会将这些podspec索引文件更新到本地”~/.cocoapods/”目录下

pod install –verbose

• Analyzing dependencies：依赖解析
  • Inspecting targets to integrate：检查要集成的目标
  • Resolving dependencies of Podfile：解析Podfile-版本控制和冲突：Milinillo依赖解决算法
  • Comparing resolved specification to the sandbox manifest
• Downloading dependencies：下载依赖
  • 如下，installing是会下载到~/Library/Caches/CocoaPods/Pods/Release/…下，然后copy到当前工程的Pods目录下

    1 2 3 4 5 6 7

    -> Installing AFNetworking (2.5.4.1) > Copying AFNetworking from `/Users/username/Library/Caches/CocoaPods/Pods/Release/AFNetworking/2.5.4.1-313e5` to `Pods/AFNetworking` 也可能已存在，就是using -> Using AFNetworking (2.5.4.1)