链家网移动端敏捷之术

郭晓铭

链家网移动端架构师

一枚成长中的程序媛 对复杂业务下的架构设计和研发效率提升有浓厚兴趣

愿始终做一个不端不装的技术人

内容摘要



业务现状



刀耕火种



开疆拓土



与时偕行



更进一步

业务现状

链家网移动端业务介绍



用户端



链家网

lianjia.com



业主端



经纪人 端



连接 * 数据 * 服务



买方服务 卖方服务

经纪人



二手房 新房 学区房 租房 地图找房 百科 …



估价 委托 钥匙托管 销售周报



房屋实堪 房源动态



…



房源管理 客源管理 签约



签后 商机获取 金融



…

链家网移动端业务特点



目标用户角色丰富

服务于房产领域的各个角色：用户、 业主、经纪人

业务和产品多元化

覆盖二手房、新房、租房、估价、业主委托、 钥匙托管、房源管理、客源管理等业务，包含 链家App，Link，新房Link，案场等多个App



业务地域范围广且差异性大

北京、天津、青岛、成都等17个城市，各个城 市的业务范围不同

线上业务需快速响应线下业务的部署

房产O2O平台，强调线上线下的配合

刀耕火种

业务简单

业务覆盖城市范围小

仅支持北京等少数城市

产品用户角色单一

产品仅服务于买方，卖方、经纪人角色非 目标用户

业务单一，未形成线上线下的闭环

早期仅支持二手房业务，且线上的浏览行为未 和线下的经纪人带看等行为打通

团队工作方式传统

团队规模小

iOS和Android端各2位，人员密切配合，不存 在业务线的分工

瀑布式开发

版本需求比较稳定，在开发过程中很少调整

手工打包上线

产品投放渠道较少，发版节奏平缓，测试和上线均靠 手工打包

架构简单



MVC架构

通用设计，学习和维护成本低

MVC架构功能划分清晰；不容易产 生误解，开发人员之间沟通无障碍



Model



对复杂业务不适应

业务逻辑变复杂时，Controller将变 得越来越大



View



Controller

开疆拓土

需求与挑战

地域性业务差异

支持北京、青岛、成都、南京等9个城市，各城市 支持的业务范围需根据公司战略随时调整

业务增多，内容型业务的形态多变

由单一二手房买卖业务增加到新房、租房、百科、问答 等业务群，且热点、百科等内容型业务的具体形态多变

人员增多，人均产出下降，代码质量堪忧

团队人员增长到3倍，技术水平参差不齐，规范缺失 ，项目质量缺乏保障

地域性业务差异

基于短链的配置化



服务端下发城市配置

配置信息包含业务入口icon、标题 、跳转短链，功能开关等

跳转短链注册表

保存短链pattern与页面的类别、类 参数名、短链参数名、默认参数值 、跳转方式等的对应信息

短链解析和页面跳转

使用注册表中的短链pattern做正则 匹配，根据匹配到的信息创建页面 并用对应的跳转方式打开



配置化



更统一

各个业务的解析和跳转逻辑由跳转 引擎统一处理

更灵活

城市配置由服务端下发，城市业务 范围的调整不依赖发版

扩展性更强

快速支持新增城市，且对新业务的 支持不影响旧功能

业务快速上线和调整

Hybrid App



Native



二手房 新房



租房



…



重点业务体验保证



H5



百科 热点



问答



…



内容型业务、运营活动

HLHybridBridge——统一交互方 案



HLWebViewController



UIWebView



1.webViewDidFinishLoad( )



2.registerBridge()



很小巧很清晰

不依赖第三方解决方案， 交互 流程更清晰，学习成本更低



3.setTitleViaBridge()



信息传递安全

通过Bridge注入参数信息，而 不是放在url里



4.actionShareViaBridge()



两端方案统一

iOS & Android采用统一方案 ， H5页面开发更加快速



iOS平台Native与H5交互时序图

项目质量缺乏保障

1% crash率

开发流程优化



代码规范形成

代码风格一致，提高可读性 ；统一的入口参数校验、异 常处理等，提高健壮性；



Code Review

同步开发人员对代码和设计

的理解；提前发现问题



敏捷开发模式

随时交付，提早反馈

收益（一）



0成本增加新城市



315年3月上线 条业务线

收益（二）



0.3% crash率



9千行代码bug数

与时偕行

需求与挑战

多个业务团队并行开发

随业务复杂性提升，链家App演变成为多 业务团队并行开发模式，需要相应架构支 撑

多个新产品需快速上线

计划推出Link、新房Link产品，需要能复 制已有功能快速上线

对接后端团队越来越多

沟通成本高，发版风险大；不同团队接口 数据格式差异大，客户端数据解析和校验 逻辑复杂

组件化



业务



IM



新房



二手



…



公共 模块



基础服务

网络 日志 CM

…



第三方库

crash监控 滤镜

工具类 …



通用UI

按钮 筛选框 VC基类

…



CM:Component Mediator



主工程

AppDelegate/Appli cation

Frameworks/jar包

Resources

…

组件间的相互调用

组件间的调用方案



IM



新房



二手



…



Component Mediator



IM 接口类



新房 接口类



二手 接口类



…



各组件之间相互独立，不直接调 用，而是通过中介者Component Mediator相互调用

Component Mediator按组件拆 分， 每部分为该组件支持的调用 方式

各组件针对组件间调用做相应接 口类。Component Mediator利 用反射机制调用该接口类的相应 方法

组件化过程中的风险控制



代码仓库分离

主工程代码、公共模块代码、以及 各业务组件代码仓库分离

权限控制

为单个业务团队配置公共模块代码 以及其他业务代码的只读权限

建立接口类的命名规范

对组件接口类名以及接口方法的命 名规范统一，降低开发成本



配置化



接口类的Code R接口e类vi出e错w的影响范围相对较大，

需要业务负责人对接口类做重点 review

小流量

Android端链家App iOS 端Link（企业应用）

热修复

紧急修复组件化过程中造成的线上 问题；每个补丁不允许超过1个版本

API团队引入



BE1 BE2 Client

Before



… BE1 BE2



沟通成本降低 发版风险降低 业务逻辑简化



API

Client

After



…

移动端与后端配合开发流程



PM



S1需求



S2需求



S3需求



S4需求



需求评审通过



需求评审通过



S1开发



S2开发



S3开发



后端RD+QA



QA测试通过



QA测试通过



中间层API+QA



S1接口

测试通过



S2接口

测试通过



S1 UI完成



S2 UI完成



UI



S*需求



S*n需求



S*开发



S*n开发



S3接口



S*接口



S3 UI



S* UI



S*n接口 S** UI



移动端RD/H5+QA



S1需求



S2需求



测试通过



S3需求



S*需求



产品发布



S1发版



S2发版



S3发版



S*发版

收益



2 1.5 0.1版本周期平均 周 Link app 用时



< % crash率



月注：Link app 代码规模10w+(不含第三方库

)

更进一步

未来展望

插件化

用户对产品功能做个性化定制；减少安 装包体积；降低发版成本

跨平台技术

最小的成本覆盖到两个平台，避免重复 开发

安全性

房屋交易环节的线上化

Q&A

Thanks!