面向企业定制化需求的移动应用平台：以Android端为例

移动办公，是企业协同产品的大势所趋。但在实际使用过程中，对于同一个产品，可能不同企业对于其定位都不太一样;另一方面，一个产品也难以完全符合不同企业的需求，此时就需要根据其诉求进行产品定制化。面对企业不同的个性化需求，解决思路往往也是不同的，这要求产品拥有一定的扩展能力，例如，最初通过打包配置项+后台参数配置+应用跳转的方式来进行自定义功能扩展;发展为支持通过内嵌一个扩展应用，如完成定制首页的效果;后续发展为支持扩展自定义轻应用、小程序等插件，如为应用实现某定制协议的NFC卡识别能力;再进一步发展为支持配置嵌入原生代码，如配置一个定制的原生首页或实现一个统计步数的后台服务等。

然而，扩展的灵活性，也会同时给产品带来更多的不确定性因素，即每个扩展应用都有让程序崩溃的可能性，导致问题的定位变得更困难。例如，公安行业中使用的是定制安全系统的手机，并且面对的是复杂的内网环境，一旦程序出现问题，其故障排查通常需要大费周章。在这种情况下，如果能对系统日志、网络请求、使用内存等各方面进行监控，将有利于准确寻找问题根源。

聆客企业协作平台(BingoLink，下简称“聆客”)是一款面向企业生态系统的云端协作与开放平台，可为企业开发者提供一站式的应用开发环境扩展和定制标准功能、集成和联通第三方应用并构建全新业务单元，通过敏捷开发和快速迭代帮助企业实现全面信息化。本文将主要从技术的角度对聆客Android端开发的扩展能力和监控能力进行介绍。

本期大咖 >>

谭智慧

品高云应用产品研发工程师，拥有多年丰富的移动化产品构建经验。目前主要负责聆客企业协作平台(BingoLink)的Android端研发工作，包括：操作系统新特性与兼容性的研究、产品体验和性能的优化、产品功能的持续迭代(如：消息点对点加密、语音视频聊天)等。

扩展能力

1. 聆客能利用打包平台的能力达到扩展的效果，为企业自由组合不同的个性化版本。首先，需要在代码中预留替换参数文件和资源文件夹，然后打包平台并依据不同企业的设置按照预设规则进行参数和资源替换，最后执行编译命令生成APK文件。这里用简单的流程图介绍一下打包平台中对于Android程序的执行流程：

•  界面配置： 聆客的UI支持颜色、图片、语言包以及界面的自由搭配。在Android的编译过程中，AAPT对于资源的生成会遵循项目的依赖关系，我们可以利用生成的这个规则对于资源重复的情况做一个优先级处理，使打包最终效果为：所有的资源项都将优先使用打包配置的资源，其次再使用内置的代码。

•  功能配置： 在功能配置方面，聆客使用INI格式进行定义，该格式的优点在于定义简单，便于打包人员或管理人员进行配置，降低人为造成的出错概率。参数除了支持自定义以外，还包含当前界面的变量，例如群组名片扩展的功能会传入当前群名片的ID，个人聊天扩展的功能菜单会传入当前聊天对象的ID。

2. 通过自定义开发的方式达到扩展的效果，结合上述的功能配置，可以在聆客预留的扩展点嵌入自定义功能开发。

• 聆客为开发者提供了H5、轻应用、小程序、原生应用多种不同APP类型的接入和扩展，除了管理应用的安装、更新和卸载外，还为接入应用提供了便捷的SSO单点登录集成以及大量的原生API调用。

• 支持Native的扩展，开发者除了可以用内置的API以外，还能对Native层进行自定义扩展，比如对轻应用自定义Plugin、对小程序自定义Module和Component，甚至在首页Tab内嵌一个自定义原生的Fragment。通过APP+Native的扩展，开发者可以实现各种不同需求的定制开发。

监控能力

监控接口请求

对主流的HTTP请求库关键函数进行Hook操作，可以对整个APP使用这些库发起的HTTP请求进行统一监控。这样做的优点是，除了能监控平台内发起的请求外，还能监控第三方开发者自己扩展的插件。

该能力主要是通过ASM修改字节码的方式实现的，通过自定义Gradle方式修改Dex生成的过程，在这个过程里找到需要替换的Class类，再找关键函数并对其注入监控的代码。

小技巧：注入代码里如果需要用到未公开的类，可以用Object代替。

监控全局日志

很多Android开发者都知道手机直接通过数据线连接就可以通过ADB查看Logcat日志，但在某些屏蔽了USB连接的操作系统，例如公安行业定制的安全系统里，是无法进行数据线操作的，这时如果程序出现Bug，即便拿到手机也难以排查问题，该如何解决?办法还是有的，在这个场景下我们就要绕过ADB能力，通过程序直接调用系统内置的Logcat命令 工具 收集日志，自己实现对日志的输出控制台和日志的收集。

小技巧：Logcat执行会包括其他APP产生的日志，而且该命令也没有过滤参数，不过我们可以发现每行日志都会包含进程ID这一规律，所以这里调用命令时可以通过使用Grep Pid进行过滤，只保留该应用的日志。

崩溃日志收集

有时，出现一些偶现或出现概率低的崩溃会很难定位，加上平台支持自定义的代码扩展也会增加崩溃的可能性，而且出现崩溃时上述的全局日志监控已经无法生效，因为Logcat的输出是异步的，出现崩溃意味着进程将停止运行。不过幸好系统的API为开发者提供了这个时机的扩展：通过Thread提供的能力，捕获所有线程中崩溃时出现的异常信息，平台可以在崩溃时保存当前时间、手机型号、堆栈信息等信息，只要程序下次启动时把崩溃日志再发回来，Bug就原形毕露了。

内存异常监控

相信不少开发者都碰到过OutOfMemory的情况，平台会增加内存溢出的可能性，但不仅平台自身面临着这种风险，上架的每一个应用都有内存泄露的风险，并且长时间打开应用不关闭还会有内存溢出的可能。当这种情况出现时，说明程序里所有代码都已经极为不稳定，每个对象的创建都有引起OutOfMemory崩溃的可能，此时上文提及的崩溃日志已经基本没什么作用。因为堆栈里显示的是最后一次申请空间达到上限抛出的，但这往往不是引起内存溢出的罪魁祸首，也许甚至还令人疑惑：这点小操作怎么可能就引起内存溢出呢?

那么，遇到这种情况该怎么办?

面对这种情况，聆客的解决办法是，基于上面的记录崩溃时机判断如果出现OutOfMemory异常，把这一刻的内存情况Dump保存下来，剩下的就是通过工具分析内存情况和享受解决Bug的过程了。

界面卡顿监控

偶然出现的操作卡顿现象，这种体验的优化是比较头疼的——因为没有错误日志，让人有种无从下手的感觉。聆客利用MainLoop类提供的能力，该类提供了一个日志回调的方法让开发者可以清楚知道主线程的调用过程，程序里通过把每次调用的开始时间和结束时间作比较，耗时大的即为卡顿，把本次主线程的堆栈信息记录下来，最后就可以根据卡顿时的堆栈信息来解决Bug了。

总结

综上，聆客企业协作平台的扩展能力能满足企业的定制化需求，让开发者实现更敏捷全能的开发;而监控能力则可以解决因集成应用多或扩展多样性所导致的程序不稳定引发的问题排查困难，有利于开发者解决应用故障。

随着聆客产品的持续发展，我们将不断对各种各样的用户痛点进行分析与解决，例如安全性方面的应用加固、本地数据安全、应用防篡改和网络防劫持等，还包括性能方面的消息数据量膨胀的优化、复杂布局结构的优化、应用启动速度优化以及节省流量和电量消耗等问题，敬请期待后续的专题技术分享。