@sammo

恰恰相反，私以为中小厂商才是小程序的主力。
你当然可以自己架起一个商城，搞自己的一套支付系统，我当然也买空间买域名搭博客搞得花里花哨，但就现在而言，更多时候公司会选择直接在淘宝、京东开店，个人会直接开公众号、直接写简书。即便觉得寄人篱下，会被绑架，也无可奈何，硬着头皮也得上，大多数人不会因为会被封店、被删文章放弃这样的巨大的入口。原因无它，因为自己折腾的话，根！本！没！流！量！现在如果看到一个东西想买，谁会去登录一个完全不认识的商城？看到好文章，除非博客质量高，不然的话真的懒得去保留地址。而在公众号、简书等可以随手点个关注，万一它有其他好东西呢，点个关注又不会怀孕。傍着大腿意味着挖掘更大用户黏性的可能。
内容为王，不是一味彰显独立、个性化的时候，先活下去才有资格谈被绑架不绑架。而这恰恰是刚起步的中小厂商所需要的。

@hst001
1.入口麻烦是个问题，不过 Android 可以通过添加桌面图标解决， iOS 或许可以通过 3D Touch 缓解？
2.这就是为什么觉得单任务可能会拖后腿，就目前打开公众号，回到聊天窗口各种直接回退，体验实在算不上良好。
3.流量这个问题估计不大，目前公众号基本必备，进行对接应该问题不大，更别说还有朋友圈这样庞大的社交体系。而且微信支付体验简直不要太好，想不通为何到现在微信官方都没有微店这样的战略，只要微信想做，流量导入到变现分分钟一条龙解决。

@xi_lin 0.0 用的就是 initWithValue ，不过这看起来不是创建了新的对象么。。。

@iYu 实测可以， initWithValue 的参数要求应该是可被序列化，每一层属性值都会被依次填充。。

@xi_lin Objective C 的好像没相关 api ？

@iYu 暂时只能用源 object 初始化一个新的进行保存了。。

@xiubin 囧~ 我们还是一起等其他 v 友的经验好了。。。

@xiubin 主要是原先的不少代码还是基于 MVC ，想要全局 vm push vm 就得大规模重构了。。。
所以跳转果然只能 hook 了么。。

顶一个~iDev 节点好冷清。。。

屌炸天！ Windows 下一直用 FSCapture ， Mac 下没趁手的一直用系统自带，期待 Mac 版！

@LINAICAI
C 并不和 VM 对应啊，其实更像是把业务逻辑部分从传统的 VM 中剥离出来，放入 DataManager ，而 VM 只对应 V ，有多少 V 就有多少 VM 。 DataManager 对应楼主的 Store ，但也确实多出来一堆 VM ，但这部分是可以复用的，个人认为值。不知道楼主的瘦 Model 中具体是怎样的，比如日期，如果存储的是 NSString 的话，那这个其实就是楼主的瘦 Model 了，只不过可能多了数据转换这一步。
举个栗子，一个 tableview 上每个 Cell 都显示着人名和生日，刚开始学 iOS 时是直接在 C 中获取，然后在 tableview 的代理方法处转换并绑定。但这转换和绑定部分是可以复用的。所以现在的做法是在 DataManager 中获取并，然后 VM 中自己转换， V 中进行绑定。比如 DM 中从 JSON 取来一系列{"name":"John", "birth":"1984-1-1"}，接着转成一系列 entity ：{NSString *name, NSDate *birth}。 VM 有自己的+viewModelWithEntity:，转换成一系列 VM ：{NSString *name, NSString *birthString}。这一系列 VM 就存在 DM 中的 VMs 数组。 tableview 代理处只需[cell bindDataWithViewModel:viewmodel]即可（此时的 V 是一个 Cell ）。这样 VM 和 V 拥有较高的复用性。甚至如果多处 tableview 都只是呈现列表， tableview 这一部分还可以进一步抽象封装成一个 baseTableViewController ，只留出 callback 。当然这是很传统的方法，只不过代码存放位置做了调整，应该不会像双向绑定那样有其他不确定性，比较好上手和过渡。

也试过用单例封装一些通用的数据请求逻辑和一些全局变量，可能和楼主的这个有些像。不过到了后边，密密麻麻一整片，看着也是累。估计拆分成 category 会明朗些。现在的做法是各个 DataManager 都继承于一个 BaseDataManager ，发现逻辑或数据其他 C 也用得上的就直接剪到基类去，应该比 category 好点。

这个没啥好办法啊， C 是最不能复用的那个了吧，所以其他能复用的一般都尽可能单独抽取出来了。能注意的是尽可能保持各处统一，比如楼主重复跳转到一个控制器这个，举个栗子，在多个地方点击头像跳转到用户详情页，额，不知道是不是这种跳转，假设是一回事儿，我的做法是下边这种，头像的 tappedBlock 类似这样：
```
UITabBarController *tabBarController = (UITabBarController)UIApplication.sharedApplication.delegate.window.rootViewController;
UINavigationController *nav = tabBarControler.selectedViewController;
XXUserViewController *userViewController = [XXUserViewController alloc] initWithUid:uid];
[nav pushViewControlleruserViewController:animated:YES];
```
这一段可以直接封装进头像控件。直接从切面取出 nav ，不用担心控件可能不是刚好处于 vc.view 需要顺着响应链去查找 nav 。当然这需要各个 Tab 都有个 RootNav 才能做到完全通用。跳转使用的是模态则直接让 tabBarController 来。

可能因为团队成员专写 iOS 的就我一只，老大负责疑难杂症和 review ，对具体代码过程没啥限制，项目也不大，所以想使用啥都可以试试。可以边写边改进哈哈。。

即便决定为 C 瘦身，分离出来的业务逻辑也总得有个去处。我的做法是每个 C 对应一个 DataManager ，同样继承于 NSObject ，在这层负责业务逻辑和存储，也就是合并 Service 层和 Store 层，拆分得过细的话 C 得来回对接也是累。 C 只负责动画、页面跳转等，不处理具体数据。
每个 V 对应一个 VM （ ViewModel ）层，但这个 VM 没像传统 MVVM 层一样处理业务逻辑，只存放视图所要表现的数据，以及负责把 Model 转换成表现数据（ NSDate 转成 NSString 等）。这样做的好处是复用性较好，换了 Model ，只需增加一个工厂+viewModelWithOtherModel 即可。此层的数据呈现既可以用传统方法 bindDataWithViewModel 和 V 进行数据绑定，也可以直接 KVO ，同推荐用一些轻量的第三方库，或者干脆直接上 ReactiveCocoa ，原生 KVO 实在繁琐，还得惦记着移除。 VM 层下还可以有多个子 VM 。
Model 层也和楼主一样是瘦 Model ，即 entity ，不负责相关业务逻辑。原始数据转 entity 这一类都在 DataManager 里做。 DataManager 和 C 的交互可以直接用 callback ，也可以斟酌用 RAC 包装成信号，获取更大灵活性。
就这样， C 持有 DataManager ， DataManager 获取数据并转换出（多个） ViewModel ， ViewModel 持有 entity ， ViewModel 和 V 绑定， DataManager 和 ViewModel 不持有任何 UI 元素，互不干扰，需要做单元测试等也方便。

@lingoerer 学习了。。请教下这种是不是得把所有 ViewModel 都放同一数组了，不同 Cell 连续存放倒还好办，如果是交叉着放还能用这办法吗？

用内建的好像有个 UISearchDisplayController ，不过好像也是封装了下 UISearchBar 和 UITableView 。。。一定要 UITextField 的话估计只能自己监视输入并实时刷新一个 tableview 了，自定义一个 Cell 是不是就能自己定制 UI 了？ 如果 tag list 是指横向的、有椭圆背景高亮的那种，估计得朝 UICollectionView 方向考虑而不是 UITableView 。。。没实现过，单纯一个猜想。。。

一直都是青花瓷抓出地址，迅雷下载回来再映射回去。。。

@Madeline 还真没去想过这几个本身里面是如何实现的，只知道直接拿来就用了。。以后会尝试着去了解内在可能的实现情况，和学习开源框架，感谢~~~

@anthonyeef 原来如此。眼界有限，暂时没找到其他好方法，麻烦也得上了。。。

@anthonyeef 水平有限，看不大懂，是不是 HTML 的某些格式特征不能用正则，得不到预期结果，所以使用正则来解析 HTML 不被建议？用得很少，侥幸没触发提问者遇到的坑。>_< 有啥其他好的替代方法吗？

@Madeline 非常感谢指点！
1.这个确实是问题，以后改正。
2.3.这点刷新了对 MVC 的认识啊，原先以为 View 就只是静悄悄的放那，所有动作都由 controller 来，这么一说倒确实觉得事件以 delegate 引出来更合理。其他未分离管理的 View 和 controller 能帮忙指出一两个吗？确实能感觉有些 View 单独拿出来没法给其他 controller 用，但细看好像代码是放两边啊，想再抽取无从下手。就着具体实例再琢磨琢磨看看能不能捋出点头绪。
4.这个可能是因为新手，做点改动又怕行不通还得倒回去，而且也是把注释当学习笔记用了，以后尽量注意。
关注架构方面用不用学设计模式？先前 iOS 刚学了一点就取瞄了几眼那本 21 种设计模式和一本 iOS 相关的设计模式，一头雾水，感觉离自己很远。学习开源框架记下。

基本素养已记上小本本，先以第二为目标慢慢努力靠近。
再次表示感谢！

@jswxcyq 共勉～ 年后应该好点，不过大形势估计不乐观。。。

@JohnShaw 0.0 大中枢派发自己偶尔也觉得别扭，但保留环这个在脑海中一点违和感也没有！果然一旦接受了这种设定……