平台系统维护不给出款怎么办 券商客户需要MAC版交易软件，怎么办？
专业出黑
点击轻松关注iPad以及MAC使用客群越来越大，部分投资者产生了使用iPad以及MAC进行投资交易的需求，面对投资者需求，只有部分券商有MAC版本或者让客户使用手机版本在iPad进行交易。甚至中小券商为了满足客户交易的基本需求，会让客户在同花顺、大智慧等第三方平台登录券商资金账号进行交易，导致好不容易吸引到自身平台的客户，又被迫回到第三方平台。面对这样的情况，按传统方式从无到有构建 Pad及 Mac应用，从设计成本、研发成本、测试成本、后期维护成本等各方面考虑，对于中小券商来讲投入实在太高。恒泰金融科技研究院对此进行了尝试，值得大家参考。
基于M1芯片迁移IOS-APP到Mac、Pad平台方案探索
01
新机会
2020年11月，苹果发布第一款为Mac设计的芯片，最大特点是底层系统指令集的统一，同一个APP应用将跨越手机、Pad、Mac电脑等多条产品线。在用户侧，将极大丰富 Pad 端和 Mac 电脑端应用场景，对于研发人员，也将不再是割裂的研发平台体系。
苹果转向自研芯片，使用M1系列的Mac产品线也将逐渐丰富起来。回看历史，苹果从到Intel过渡中已沉淀了丰富的经验，此次苹果提供了成熟且更低成本的过渡方案，过渡时间可能更短，苹果给出的预期时间是2年。
大家关心的券商在Pad、Mac上的应用场景和市场现状如何呢？
手机应用往往更适合展示交互轻量级、维度较少的信息，毕竟投资是个在信息层面熵很高的事情，尤其对于专业投资者、高净值人群以及机构来讲，大屏展示、多屏展示、信息丰富度、信息深度都有着明确的诉求，但这部分需求一直没有被很好地满足。市场虽然存在，但按传统方式从无到有构建 Pad及 Mac 应用，无论从设计成本、研发成本、测试成本、后期维护成本各方面对于券商来讲都是投入太高了、人群有限。
现已应用于 Pad、Mac平台的证券 App，除同花顺、东方财富、大智慧等少数几个互联网金融平台的App外，传统券商的应用屈指可数。但 M1 的到来带来了新的机会，超过80%的券商都推出了iOS平台的App，利用现有成熟的手机端研发积累，低成本构建出一个券商Mac端应用变得切实可行。
恒泰证券金科团队第一时间对M1平台进行了探索、开发、适配。此文意在将我们的有意义的点滴经验分享给同业以作参考。
02
四条路
为了实现大一统系统，苹果这次提供了成熟且更低成本的过渡方案，在最近几次的发布会中都做了精心准备，主要有如下四个方案。
●如果你拥有非自研的Mac应用，选择 2 转译方案
在macOS 11 Big Sur系统上，利用内置的 2技术，将x86架构的应用翻译成arm架构的应用，只有第一次下载x86应用时，会提醒用户安装 2，平时使用就不会和 2再产生交互，默默为我们工作。
通过 Mac 商店查找，之前拥有 Intel Mac 应用的券商，利用苹果自带的 2 转译技术在 Apple 平台下发布了应用。
●如果你拥有完全自研的Mac应用，选择通用方案
通用App成本最高，目前还没有证券类应用通过此方案适配，且该方案是苹果从 Intel 到 ARM 的过渡方案。需要构建即支持x86架构又支持ARM架构的应用，包含两套可执行代码文件，打包成一个通用应用。最大的问题在于应用依赖的三方库也需要支持双架构，往往三方依赖不能很好支持，这是需要我们慎重考虑的事情。
●如果你拥有iPad应用，选择Mac催化剂方案
开发者在iPad和macOS应用之间共享大部分代码，针对不同功能和使用场景进行一些特殊处理，适配不同平台上的交互差异。国内腾讯QQ基于iPad 版本通过催化剂方案预发布了macOS版本，用户体验与手机端很相似，丰富了mac端的用户体验，获得了不少好评。
●如果你仅拥有版本应用，同样选择Mac 催化剂方案
苹果Mac 催化剂项目是为iOS开发人员提供一种将应用引入Mac的方式，iPad应用比较与应用，操作和专属功能更靠近Mac, 所以苹果最初推广该方案与iPad应用中，对于 应用一边通过引入Mac 开发的 ，开发工具栏、触控条和菜单等Mac端控件，一边通过适配平台交互差异来完善用户体验。
03
中小券商何去何从
在没有 Intel 芯片应用、iPad 应用的情况下，基于券商已有应用，利用iOS技术，开发适配iPad和Mac的应用。
利用现存移动应用构建为什么如此重要呢，或者说重新构建 Mac、Pad 应用成本主要在哪里呢，首先，行情速度以及稳定性、交易链路稳定、高速是券商应用的命脉，相信大家无论在底层库、UI 库的健壮性建设、模块化建设甚至数据统计等方方面面都投入过大量的人力，经过时间的打磨才能够提供稳定可靠的服务，重建即便不考虑人力成本，但此前所有的技术风险几乎都要重新承担。迁移方案的优势就是能够将现有的积累沉淀，尤其是行情、交易相关内容，延展到Mac平台。同时保持Pad、Mac平台特有的交互与体验。
这里我们以九点半app为例，看一下代码量统计以及现有接口数量、涉及到的网络层复杂策略，大体就能想象出重建应用方案与迁移应用方案有着天壤之别。券商APP行情源多数是券商私有的行情服务，存在站点单一、灾备能力弱、更新换代慢、地域连接速度稳定性差别大等等问题，九点半APP为了提供更加稳定可靠、高速的行情，大刀阔斧的将全部行情业务，全部切换到了上证云行情，其中改造的业务涉及到行情列表、快照、分时线图、历史k线、分笔明细，、、板块、模拟盘等，切换过程中最大工作量是接口服务替换，共涉及接口54个，行情长连接上证云分为Tcp订阅和轮询模式，满足不同业务场景的需要。切换过程中其他难点诸如，股票类型对上证市场类型的转换，映射转换方案基于配置列表管理，复杂网络环境下如何适配各种SDK授权问题，由最初的硬编码优化为动态配置管理。大行情概念的业务总代码量行，涉及改造的修改量大约万行左右，历时三个月经过研发、测试、灰度、直到正式上线，可见此部分的投入对于重建一个新的客户端是难以接受的。再看交易类业务，更加复杂、风险也更高，经过长期的梳理，对重连机制的增补、智能网络的搭建、传输包的优化等等，都是难以再次投入建设的，我们再来看几张团队梳理的图片，对这个部分的认知会更加清晰。
交易相关链接及关系梳理：
重连机制顶层关系梳理：
中小券商中，部分有自研团队自建应用，部分与三方平台合作共建应用，而绝大多数是没有Mac 应用或 iPad 应用。恒泰金科团队也在寻找一条适合中小券商布局Pad、Mac应用的最佳路线。Mac催化剂方案给我们很大启发，开发者在 macOS 平台用 iOS 的 UIKit 框架开发应用。复用 应用的行情、交易服务以及数据模型，iPad、Mac 版应用需要关注的是基于平台差异的页面交互。
04
基于应用的适配之路
恒泰九点半iOS最初也只支持端，我们希望能最大程度复用有手机版开发测试的成果、被充分验证的技术积累以及业务积累。因此，在此次M1的开发适配中，我们主要解决如下问题：
●同时适配iPad、Mac，共用端项目代码
●基于组件化工程结构来完成整个适配
●组织业务页面布局关系，适配路由，在Mac、ipad、上提供差异化交互体验
●支持iPad ，支持Mac端自定义窗口size
●基于Mac ，开发Mac端鼠标、菜单等差异化功能
4-1 环境问题
由于M1芯片下周边工具存在一定不完备性，搭建研发环境是首先要面对的问题，系统升级、语言升级，每一次的变化升级也会对开发环境产生一定的影响，下面列举出m1开发遇到几个核心问题。
●安装异常
命令行执行
/bin/bash-c"$(curl-fsSL )"
如果出现无法连接的情况，需要检查一下DNS设置。添加114.114.114.114和8.8.8.8作为DNS服务器地址。安装好之后，会出现在/opt/目录，可以把可执行文件加入到PATH中，编辑~/.，添加：
PATH="$PATH:/opt//bin"
重启终端或者 ～/.之后，如果可以使用brew命令，则说明安装设置正确。
●安装异常
除了在中运行终端之外，安装一个与错误中未找到的符号有关的框架：
sudo gem ffi
完成此操作后，将按预期运行。
●模拟器编译工程失败
xxxx for iOS , but in file built for iOS, xxxxx for arm64
通过 启动 xcode 编译
●VPN无法访问，导致无法开展工作
代理设置，通过ssh隧道共享vpn网络
4-2 组件化
九点半 iOS 版本具备组件化的基础，也完成了部分业务组件化，我们很容易的利用现有能力支持了 M1 Mac 平台，也进一步完善了组件能力。
正如苹果对外公布，基于苹果芯片，iOS APP 可以无成本迁移到 M1 设备上。但我们希望为 Mac 版本开发适应于 Mac 的交互体验。这里我们在壳工程中新增 Mac 容器，完成相应的应用配置、启动管理，配合差异化业务功能，完成整个项目搭建，并运转在持续集成的整个项目工程中。
如果您的项目还没有考虑组件化，您还是可以在现有的工程下，来支持iPad、 Mac 上的产品交互特性，只是除了满足上面的要求，在工程管理、代码复用上您需要付出更多的努力。
4-3 基于应用程序创建Mac版本
打开Xcode项目，选择iOS ，在 Info中选择“Mac”复选框，我们的适配之路就开始了。
启用Mac支持后，对于不兼容的框架，我们可以手动排除这些框架，对于代码中引用的不适用于Mac的API，我们也可以通过条件编译块来进行隔离。
4-4 APP启动管理
从启动上分离Mac与iOS的代码和事件对我们来说是有意义的。我们可以在这时做一些差异化的默认配置，设置不同的APP首页，完成不同的功能和业务初始化。
这样，我们在壳工程，即可针对不同的平台进行差异化的启动管理，在M1、ipad、端上复用我们的组件。
我们可以根据[[ ] ] 来判断处理m1的设备（注意是iOS 14以上新增的方法），根据之前的方法 来判断当前是否在/iPad设备。
4-5 App
Mac 版本中，我们为 APP 开发了全新的容器，重新组织了业务表现，可以为 Mac 用户提供更多内容和信息。为此，我们的 APP 页面组织结构有了如图中的转变：
在九点半 iOS 客户端，APP 是以 作为 ，在 跳转查询时，基于 递归查找当前 的 。
Mac 版我们通常用工作区开布局和区分主要业务交互区。比如整个APP采用 Menu+ 布局，在同一个界面上，股票列表与股票详情的信息在同一个界面层级中展示。
同样的业务在 iOS 版本中，股票详情是股票列表的子集界面。
⬆️九点半 M1 与 版本对比（左图为 M1 mac 版。右图为 版）
这要求 除了支持系统默认的 push、 modal、 方式进行页面切换，还需要我们支持自定义容器切换。在兼容 view 展示时，也需要支持特定的容器场景。
解决的思路也比较简单，在不改变各个组件的业务代码前提下，我们在 中提供了自定义容器协议，维护了 r 与，在跳转时，查找到当前 ，并根据跳转方式，和当前 所支持的协议，找到真正要执行跳转行为的 ，然后触发跳转，并将 记录到 堆栈中。
4-6 数据安全
M1 把 iOS APP 带入 Mac，同时也带入了 iOS 的沙箱文件访问机制。相对于 iOS 设备相对封闭的文件管理，Mac 端用户可以更容易的访问文件目录。
虽然沙箱机制，APP 目录名被 ID 化，但如果 APP 文件本身管理不完善的话，用户仍可根据关键字等信息，查询出对应的文件内容并解读。采用文件加密、权限校验的数据库等持久化方案，重视客户端数据安全，也是我们需要解决的问题。
4-7 差异化功能支持
1.使用iPad多任务处理使APP的可调整大小
我们知道，Mac 的屏幕相对于我们的移动设备是比较大的，那么如何让我们的APP在Mac上可以自定义窗口尺寸，进而可以全屏展示呢。下面我们来谈谈这个问题。
info.plist里需要支持四个方向。
这里我们虽然描述了APP支持了四个方向，但其实在Mac上并没有设备方向变更的事件。可以通过ons来设置的最大最小尺寸：
用户可以通过鼠标在最大最小尺寸之间自由设置窗口尺寸；如果 与 相等，则当前窗口是固定尺寸大小，不可用通过鼠标修改窗口尺寸。
下图是九点半设置页面，用户可以通过鼠标控制整个试图的尺寸⬇️
2.尽量多的使用相对布局方案，避免使用指定frame尺寸的绝对布局方案
如果我们需要支持调整窗口尺寸，我们需要考虑APP视图size兼容适配问题。这个问题其实在ipad上已经碰到过，如果布局不依赖特定的分辨率的屏幕，并且基于安全区域适配全面屏，那适配工作将更容易。
彼时苹果推出了 特性，可以支持多个APP在iPad上同时使用，相应的，apple 提供了 、等方案。
3.利用Mac 来优化APP在Mac上的体验
Mac 提供了一种方式，可以在iOS项目中引入Mac开发的 ，这样，开发可以在项目中使用类似、、等API，开发工具栏、触控条和菜单相关的功能。
上面我们仅仅是列出了适配中遇到的个别场景，适配支持iPad、Mac上的应用不是放大版的，大屏展示、多屏展示、信息丰富度、信息深度都有着明确的诉求，需要产品、设计基于新平台带来的特性，设计符合iPad和Mac的用户交互体验。
05
其他三种方案的扩展
5-1 通用方案
通用App包含了两个版本的编译代码，一个版本用来在Apple 上运行，另外一个在Intel-based Mac上运行。运行时，系统会自动根据平台自动选择运行的版本。
●移植遇到的问题？
●硬件、架构的差异。
●依赖的第三方是否已提供通用版本库。
●解决方案
●构建通用版本的可执行程序类型。App、App 、Plug-ins、 、 。
● App如果支持插件模式，依赖通用版本的插件。
●定位硬件和架构差异，开发者做相应的修改。
5-2 2方案
原有Inter芯片开发的Mac版APP可以直接在 M1 设备上运行，苹果通过 2转译。是一个允许用户在Apple 平台运行包含指令的App的转换进程。所有64位x86应用，若以应用商店分发，则下载的便是已翻译版本；若在网络上下载安装，则在安装时翻译；若以拖拽形式安装，则在首次运行时翻译。
针对Apple 编译过的应用，用户可以自己以 2来运行，应用本体更新了arm64 版本，但是插件没有更新，用户可以选择以 2来启动。
无法转换下列程序：内核扩展( )、虚拟平台的虚拟机App。通过 2运行的App 在性能和运行速度无法保证和在Intel 芯片的Mac上一样。
5-3 Mac
2019 年的苹果 WWDC，宣布macOS 能运行上的应用了，并发布了Mac ，为开发者提供了将 iPad APP 引入 Mac。开发者需要重新编译应用，编译后的应用可以运行在Intel 芯片的Mac上。
Mac 所做的是确保和UIKit所使用一样的底层技术，并移植一部分UIKit组件到macOS中，实现了在macOS中运行应用的目的。
Mac 并没有明显的吸引应用开发者投入精力，因为直接移植的应用品质不佳，不能吸引更多消费者。
06
总结和展望
经过2个月的尝试和改造，恒泰九点半pad、mac版本主体迁移、建设工作已经完成，在这个过程中，如前文所述，对自身工程质量、工程结构、组件化完善是一次较好的自查、完善升级的过程。下一步针对Pad、Mac用户的交互习惯进行进一步的完善。
M1从芯片层为苹果系统硬件生态提供了基础，swift打通了跨平台的软件开发语言，加之 的在不同系统平台上的应用，未来跨终端、跨系统、跨设备的统一将是产品开发需要面对的主要课题。
07
参考资料
1)Apple (苹果芯片)从 DTK到M1 Mac的入门总结
2)关于 ( 2)和苹果的ARM架构迁移
3)【艾瑞咨询】2020年中国金融科技行业发展研究报告：曙光
%7B%%22%3A%年中国金融科技行业发展研究报告%22%7D&index=0&pid=
4) Apple ，苹果都做了什么？
5）m1解决环境问题部分内容
来源机构：恒泰证券金融科技研究院
