普通跨端 VS Chameleon

正常业务代码重复实现

// 普通业务代码web 
if (业务逻辑判断A) {
  业务操作();
}
else if (业务逻辑判断B) {
  业务操作();
}
// 普通业务代码小程序 
if (业务逻辑判断A) {
  业务操作();
}
else if (业务逻辑判断B) {
  业务操作();
}

// 普通业务代码Objective-c 
if (业务逻辑判断A) {
  [XXX业务操作];
}
else if(业务逻辑判断B){ 
  [XXX业务操作];
}

一套代码运行多端合并

哇好牛逼，一套代码多端实现，开发效率显著提升

// 普通跨端框架，实现一套代码运行多端 
if (业务逻辑判断A) {
  业务操作();
} 
else if(业务逻辑判断B) {
  业务操作();
}

理想很美好，现实很骨感

遇到了产品差异化实现：“我希望web端下载APP，小程序不用下载”

// 普通跨端框架，实现一套代码运行多端 
if (业务逻辑判断A) {
  业务操作();
  if (ENV.小程序) {
    业务差异操作();
  }
  else if (ENV.web) {
    业务差异操作();
  }
  else if (ENV.端) {
    业务差异操作();
  }
}
else if (业务逻辑判断B) {
  业务操作(); 
  if(小程序) {
    业务差异操作();
  } 
  else if (web) {
    业务差异操作();
  } 
  else if (端) {
    业务差异操作();
  }
}

这就尴尬了，如果你觉得以上不复杂，假设有4、5个端呢，业务逻辑掺杂跨端逻辑，产品逻辑别打断，可读性差，需求变更，牵一发动全身，每个端都要测试，跨端代码效率变得适得其反。

Chameleon

Chameleon 将特有代码充分隔离，保证正常产品逻辑整体具有连续性，保障各端产品差异化模块的独立性、一致性、可读。 差异化产品修改不会影响其他端，各端底层接口调用不会影响其他端。

// Chameleon跨端设计遇到产品差异化的代码 
if (业务逻辑判断A) {
  业务操作();
  interface_foo(); // 产品多态接口 
}
else if (业务逻辑判断B) {
  业务操作();
  interface_foo2(); // 产品多态接口
}