移动办公，是企业协同产品的大势所趋。但在实际使用过程中，对于同一个产品，可能不同企业对于其定位都不太一样；另一方面，一个产品也难以完全符合不同企业的需求，此时就需要根据其诉求进行产品定制化。面对企业不同的个性化需求，解决思路往往也是不同的，这要求产品拥有一定的扩展能力，例如，最初通过打包配置项+后台参数配置+应用跳转的方式来进行自定义功能扩展；发展为支持通过内嵌一个扩展应用，如完成定制首页的效果；后续发展为支持扩展自定义Cordova、Weex等插件，如为应用实现某定制协议的NFC卡识别能力；再进一步发展为支持配置嵌入原生代码，如配置一个定制的原生首页或实现一个统计步数的后台服务等。联系品高云家的小表妹（ID：pingaoyunzzm）了解更多。
然而，扩展的灵活性，也会同时给产品带来更多的不确定性因素，即每个扩展应用都有让程序崩溃的可能性，导致问题的定位变得更困难。例如，公安行业中使用的是定制安全系统的手机，并且面对的是复杂的内网环境，一旦程序出现问题，其故障排查通常需要大费周章。在这种情况下，如果能对系统日志、网络请求、使用内存等各方面进行监控，将有利于准确寻找问题根源。
聆客企业协作平台（BingoLink，下简称“聆客”）是一款面向企业定制化需求的移动应用平台，该平台集成了应用统一认证、用户行为分析、社区分享等应用通用能力，同时还具备着更为强劲的扩展和监控能力。本文将主要从技术的角度对聆客Android端开发的扩展能力和监控能力进行介绍。
扩展能力
1. 聆客能利用打包平台的能力达到扩展的效果，为企业自由组合不同的个性化版本。首先，需要在代码中预留替换参数文件和资源文件夹，然后打包平台并依据不同企业的设置按照预设规则进行参数和资源替换，最后执行编译命令生成APK文件。这里用简单的流程图介绍一下打包平台中对于Android程序的执行流程：
界面配置：聆客的UI支持颜色、图片、语言包以及界面的自由搭配。在Android的编译过程中，AAPT（Android Asset Packaging Tool）对于资源的生成会遵循一个规则：当项目里不同的Module之间出现重复ResourceId时，APP层中的资源会覆盖Library层。我们可以利用这个规则，把需要替换的项放到APP层，这样能达到一个目的：所有的资源项都将优先使用打包配置的资源，其次再使用内置的代码。
功能配置：在功能配置方面，聆客使用INI格式进行定义，该格式的优点在于定义简单，便于打包人员或管理人员进行配置，降低人为造成的出错概率。参数除了支持自定义以外，还包含当前界面的变量，例如群组名片扩展的功能会传入当前群名片的ID，个人聊天扩展的功能菜单会传入当前聊天对象的ID。
2. 通过自定义开发的方式达到扩展的效果，结合上述的功能配置，可以在聆客预留的扩展点嵌入自定义功能开发。
聆客为开发者提供了H5、BT、Weex、原生应用多种不同APP类型的接入和扩展，除了管理应用的安装、更新和卸载外，还为接入应用提供了便捷的SSO单点登录集成以及大量的原生API调用。
支持Native的扩展，开发者除了可以用内置的API以外，还能对Native层进行自定义扩展，比如对Cordova自定义Plugin、对Weex自定义Module和Component，甚至在首页Tab内嵌一个自定义原生的Fragment。通过APP+Native的扩展，开发者可以实现各种不同需求的定制开发。
监控能力
监控接口请求
对主流的HTTP请求库关键函数进行Hook操作，可以对整个APP使用这些库发起的HTTP请求进行统一监控。这样做的优点是，除了能监控平台内发起的请求外，还能监控第三方开发者自己扩展的插件。联系品高云家的小表妹（ID：pingaoyunzzm）了解更多。
该能力主要是通过ASM修改字节码的方式实现的，首先要清楚的是，APK最终给Android虚拟机执行的是里面的DEX文件，而我们主要也是在生成DEX的过程中进行字节码的修改。首先，需要定义一个Gradle插件在Class转DEX过程时注册自定义的Transform，在Transform中根据类名寻找指定的类，最后通过实现ASM提供的抽象类ClassVisitor修改该指定类的字节码并注入要监控的代码逻辑。
小技巧：注入代码里如果需要用到未公开的类，可以用Object代替。
监控全局日志
很多Android开发者都知道手机直接通过数据线连接就可以通过ADB查看Logcat日志，但在某些屏蔽了USB连接的操作系统，例如公安行业定制的安全系统里，是无法进行数据线操作的，这时如果程序出现Bug，即便拿到手机也难以排查问题，该如何解决？办法还是有的，在这个场景下我们就要绕过ADB能力，通过Runtime提供的Exec函数直接调用Logcat命令工具收集日志，自己实现对日志的输出控制台和日志的收集。
小技巧：Logcat执行会包括其他APP产生的日志，而且该命令也没有过滤参数，不过我们可以发现每行日志都会包含进程ID这一规律，所以这里调用命令时可以通过使用Grep Pid进行过滤，只保留该应用的日志。
崩溃日志收集
有时，出现一些偶现或出现概率低的崩溃会很难定位，加上平台支持自定义的代码扩展也会增加崩溃的可能性，而且出现崩溃时上述的全局日志监控已经无法生效，因为Logcat的输出是异步的，出现崩溃意味着进程将停止运行。不过幸好系统的API为开发者提供了这个时机的扩展：通过UncaughtExceptionHandler接口，平台可以在崩溃时保存当前时间、手机型号、堆栈信息等信息，只要程序下次启动时把崩溃日志再发回来，Bug就原形毕露了。
内存异常监控
相信不少开发者都碰到过OutOfMemory的情况，平台会增加内存溢出的可能性，但不仅平台自身面临着这种风险，上架的每一个应用都有内存泄露的风险，并且长时间打开应用不关闭还会有内存溢出的可能。当这种情况出现时，说明程序里所有代码都已经极为不稳定，每个对象的创建都有引起OutOfMemory崩溃的可能，此时上文提及的崩溃日志已经基本没什么作用。因为堆栈里显示的是最后一次申请空间达到上限抛出的，但这往往不是引起内存溢出的罪魁祸首，也许甚至还令人疑惑：这点小操作怎么可能就引起内存溢出呢？
那么，遇到这种情况该怎么办？
面对这种情况，聆客的解决办法是，基于上面的记录崩溃时机判断如果出现OutOfMemory异常，把这一刻的内存情况通过程序Dump文件保存下来，再用Hprof-Conv工具转换MAT支持的格式，剩下的就是查看内存数据和享受解决Bug的过程了。
界面卡顿监控
偶然出现的操作卡顿现象，这种体验的优化是比较头疼的——因为没有错误日志，让人有种无从下手的感觉。聆客利用MainLoop的setMessageLogging函数，设置自定义的LogPrinter以接收主线程的调用日志，从日志里可以看出，每次界面交互都会产生一组Dispatching与Finished，这代表着每次界面交互的开始与结束。在这个基础上我们就可以加入监控逻辑，比如发现这个过程中耗时大于1秒的就判断为卡顿，再利用Thread.getStackTrace把当前卡顿时刻主线程的堆栈信息记录下来，最后就只需查看堆栈信息和解决Bug了。联系品高云家的小表妹（ID：pingaoyunzzm）了解更多。
总结
综上，聆客企业协作平台的扩展能力能满足企业的定制化需求，让开发者实现更敏捷全能的开发；而监控能力则可以解决因集成应用多或扩展多样性所导致的程序不稳定引发的问题排查困难，有利于开发者解决应用故障。
随着聆客产品的持续发展，我们将不断对各种各样的用户痛点进行分析与解决，例如安全性方面的应用加固、本地数据安全、应用防篡改和网络防劫持等，还包括性能方面的消息数据量膨胀的优化、复杂布局结构的优化、应用启动速度优化以及节省流量和电量消耗等问题，敬请期待后续的专题技术分享。
联系我们
如想了解更多品高云解决方案或索取产品文档，请联系品高云家的客服小表妹！添加她为好友，任何需求一键直达。
网友评论